cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2590) row delete breaks read repair
Date Tue, 03 May 2011 21:21:03 GMT


Jonathan Ellis commented on CASSANDRA-2590:

So the problem is that something in repair isn't calling removeDeleted?  That's the approach
we normally take; it's like your ensureRelevant, but it doesn't mutate the original copy (which
is important since the original might be part of a cache).  Here's your test modified to use

    public void testEnsureRelevant()
        ColumnFamily cf1 = ColumnFamily.create("Keyspace1", "Standard1");
        cf1.addColumn(column("one", "A", 0));

        ColumnFamily cf2 = ColumnFamily.create("Keyspace1", "Standard1");
        cf2.delete((int) (System.currentTimeMillis() / 1000), 1);

        assert cf2.getColumnCount() == 1;
        ColumnFamily cleaned = ColumnFamilyStore.removeDeleted(cf2, Integer.MAX_VALUE);
        assert cleaned == null;

> row delete breaks read repair 
> ------------------------------
>                 Key: CASSANDRA-2590
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.5, 0.8 beta 1
>            Reporter: Aaron Morton
>            Assignee: Aaron Morton
>            Priority: Minor
>         Attachments: 0001-cf-resolve-test-and-possible-solution-for-read-repai.patch
> related to CASSANDRA-2589 
> Working at CL ALL can get inconsistent reads after row deletion. Reproduced on the 0.7
and 0.8 source. 
> Steps to reproduce:
> # two node cluster with rf 2 and HH turned off
> # insert rows via cli 
> # flush both nodes 
> # shutdown node 1
> # connect to node 2 via cli and delete one row
> # bring up node 1
> # connect to node 1 via cli and issue get with CL ALL 
> # first get returns the deleted row, second get returns zero rows.
> RowRepairResolver.resolveSuperSet() resolves a local CF with the old row columns, and
the remote CF which is marked for deletion. CF.resolve() does not pay attention to the deletion
flags and the resolved CF has both markedForDeletion set and a column with a lower timestamp.
The return from resolveSuperSet() is used as the return for the read without checking if the
cols are relevant. 
> Also when RowRepairResolver.mabeScheduleRepairs() runs it sends two mutations. Node 1
is given the row level deletation, and Node 2 is given a mutation to write the old (and now
deleted) column from node 2. I have some log traces for this if needed. 
> A quick fix is to check for relevant columns in the RowRepairResolver, will attach shortly.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message