You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2010/03/30 06:10:27 UTC

[jira] Resolved: (CASSANDRA-928) Use Read Repair for smaller Anti Entropy repairs

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

Jonathan Ellis resolved CASSANDRA-928.
--------------------------------------

    Resolution: Won't Fix

CASSANDRA-930 will at the very least complicate this, and CASSANDRA-579 will mitigate the pain of the sstable approach.  So on second thought, I think you're right and this feature isn't worth the effort.

> Use Read Repair for smaller Anti Entropy repairs
> ------------------------------------------------
>
>                 Key: CASSANDRA-928
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-928
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Stu Hood
>            Priority: Minor
>
> Repairs triggered by AntiEntropyService currently always use the 'streaming' package, which involves the creation of at least one new SSTable on the destination of the repair.
> For lighter weight repairs when less of a column family is out of sync, it would be great to be able to conditionally use read-repair. Range commands do not currently perform read-repairs, so the majority of the work for this ticket will involve implementing read repair for RangeCommand.
> The AntiEntropyService.Differencer class has methods for calculating the percentage difference between two trees, so once it is possible to do a range read repair, that option can be plugged in and a threshold chosen.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.