[ https://issues.apache.org/jira/browse/CASSANDRA-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12892142#action_12892142 ]
Brandon Williams commented on CASSANDRA-1316: --------------------------------------------- Updated json files illustrate one possible scenario: nodes 1 and 2 have a column, and node 3 has the column tombstoned with the same timestamp. It looks like tombstones aren't taking precedence. > Read repair does not always work correctly > ------------------------------------------ > > Key: CASSANDRA-1316 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1316 > Project: Cassandra > Issue Type: Bug > Components: Core > Affects Versions: 0.4 > Reporter: Brandon Williams > Fix For: 0.6.4 > > Attachments: cassandra-1.json, cassandra-2.json, cassandra-3.json > > > Read repair does not always work. At the least, we allow violation of the > CL.ALL contract. To reproduce, create a three node cluster with RF=3, and > json2sstable one of the attached json files on each node. This creates a row > whose key is 'test' with 9 columns, but only 3 columns are on each machine. > If you get_count this row in quick succession at CL.ALL, sometimes you will > receive a count of 6, sometimes 9. After the ReadRepairManager has sent the > repairs, you will always get 9, which is the desired behavior. > I have another data set obtained in the wild which never fully repairs for > some reason, but it's a bit large to attach (600ish columns per machine.) > I'm still trying to figure out why RR isn't working on this set, but I always > get different results when reading at any CL including ALL, no matter how > long I wait or how many reads I do. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.