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.