cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11427) Range slice queries CL > ONE trigger read-repair of purgeable tombstones
Date Tue, 05 Apr 2016 14:07:25 GMT


Sylvain Lebresne commented on CASSANDRA-11427:

The patch works but it has 2 small inefficiencies:
# it purges on the coordinator, but there is no point for purgeable tombstones to leave the
replicas in the first place.
# single partition queries already do that filtering on replicas (in {{ColumnFamilyStore.getColumnFamily(QueryFilter)}}),
and since {{scheduleRepairs()}} is shared by single partition and range queries, that adds
unecessary work for single partition ones.
Overall, I think it would be better (and actually slightly easier) to just call {{removeDeletedCF}}
in {{ColumnFamilyStore.filter(AbstractScanIterator, ExtendedFilter)}}.

But I would also note that:
# 3.0 is not affected
# this only concerns partition and range tombstones, so this is imo a fairly minor efficiency
problem, not a correction issue. So in particular, this doesn't met the "critical issues only"
bar for 2.1.

So that I wonder if it's worth taking any risk just for 2.2. Not too opposed to it though
if someone cares deeply.

> Range slice queries CL > ONE trigger read-repair of purgeable tombstones
> ------------------------------------------------------------------------
>                 Key: CASSANDRA-11427
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>             Fix For: 2.1.x, 2.2.x
>         Attachments: 11427-2.1.patch
> Range queries will trigger read repairs for purgeable tombstones on hosts that already
compacted given tombstones. Clusters with periodical jobs for scanning data ranges will likely
see tombstones ressurected through RRs just to have them compacted again later at the destination
> Executing range queries (e.g. for reading token ranges) will compare the actual data
instead of using digests when executed with CL > ONE. Responses will be consolidated by
{{RangeSliceResponseResolver.Reducer}}, where the result of {{RowDataResolver.resolveSuperset}}
is used as the reference version for the results. {{RowDataResolver.scheduleRepairs}} will
then send the superset to all nodes that returned a different result before. 
> Unfortunately this does also involve cases where the superset is just made up of purgeable
tombstone(s) that already have been compacted on the other nodes. In this case a read-repair
will be triggered for transfering the purgeable tombstones to all other nodes nodes that returned
an empty result.
> The issue can be reproduced with the provided dtest or manually using the following steps:
> {noformat}
> create keyspace test1 with replication = { 'class' : 'SimpleStrategy', 'replication_factor'
: 2 };
> use test1;
> create table test1 ( a text, b text, primary key(a, b) ) WITH compaction = {'class':
'SizeTieredCompactionStrategy', 'enabled': 'false'} AND dclocal_read_repair_chance = 0 AND
gc_grace_seconds = 0;
> delete from test1 where a = 'a';
> {noformat}
> {noformat}
> ccm flush;
> ccm node2 compact;
> {noformat}
> {noformat}
> use test1;
> consistency all;
> tracing on;
> select * from test1;
> {noformat}

This message was sent by Atlassian JIRA

View raw message