[ 
https://issues.apache.org/jira/browse/CASSANDRA-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-2590:
--------------------------------------

             Reviewer: jbellis
    Affects Version/s:     (was: 0.7.5)
                           (was: 0.8 beta 1)
        Fix Version/s: 0.8.1
                       0.7.7

> row delete breaks read repair 
> ------------------------------
>
>                 Key: CASSANDRA-2590
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2590
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Aaron Morton
>            Assignee: Aaron Morton
>            Priority: Minor
>             Fix For: 0.7.7, 0.8.1
>
>         Attachments: 0001-2590-v3.patch, 
> 0001-cf-resolve-test-and-possible-solution-for-read-repai.patch, 2590-v2.txt
>
>
> 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: http://www.atlassian.com/software/jira

Reply via email to