[
https://issues.apache.org/jira/browse/CASSANDRA-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2324:
----------------------------------------
Attachment: 0001-Make-repair-operate-over-a-node-token-range.patch
Attached patch modify repair to operate on one token range at a time. Nodetool
repair schedule as many repair session than the node have ranges to perform a
full node repair. Note that this is more efficient than previously, since the
neighbors of the node will only do a validation compaction on the range they
have in common with the node coordinating the repair (instead of validating
everything).
This moreover makes it trivial to add an option to nodetool so that the node
only repair it's primary range. That way, you can repair a full cluster by
calling this operation on every node and there is no duplication of work. The
patch doesn't add this option yet though.
The patch is against trunk. Because the way we construct the merkleTree is
fundamentally different, the trees created by 0.7 cannot be compared to the
ones created with this patch. The strategy this patch adopts with respect to
talking to 0.7 nodes is this:
* If a 0.7 node asks for a merkleTree, since we are still able to do a full
compaction validation, we do it and answer with that.
* Since a 0.7 node cannot do a merkleTree that would be ok for us, we simply
exclude 0.7 nodes from the endpoints we ask merkleTree from.
I don't feel this is a trivially enough patch to go to the 0.7 branch.
> Repair transfers more data than necessary
> -----------------------------------------
>
> Key: CASSANDRA-2324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2324
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0
> Reporter: Brandon Williams
> Assignee: Sylvain Lebresne
> Fix For: 0.7.5
>
> Attachments: 0001-Make-repair-operate-over-a-node-token-range.patch
>
>
> To repro: 3 node cluster, stress.java 1M rows with -x KEYS and -l 2. The
> index is enough to make some mutations drop (about 20-30k total in my tests).
> Repair afterwards will repair a large amount of ranges the first time.
> However, each subsequent run will repair the same set of small ranges every
> time. INDEXED_RANGE_SLICE in stress never fully works. Counting rows with
> sstablekeys shows there are 2M rows total as expected, however when trying to
> count the indexed keys, I get exceptions like:
> {noformat}
> Exception in thread "main" java.io.IOException: Key out of order!
> DecoratedKey(101571366040797913119296586470838356016,
> 0707ab782c5b5029d28a5e6d508ef72f0222528b5e28da3b7787492679dc51b96f868e0746073e54bc173be927049d0f51e25a6a95b3268213b8969abf40cea7d7)
> > DecoratedKey(12639574763031545147067490818595764132,
> 0bc414be3093348a2ad389ed28f18f0cc9a044b2e98587848a0d289dae13ed0ad479c74654900eeffc6236)
> at
> org.apache.cassandra.tools.SSTableExport.enumeratekeys(SSTableExport.java:206)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:388)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
