[
https://issues.apache.org/jira/browse/CASSANDRA-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012062#comment-13012062
]
Sylvain Lebresne commented on CASSANDRA-2324:
---------------------------------------------
bq. couldn't we just take the interesection of the computed ranges w/ the range
actually being repaired?
We do that. But the problem is: you're node A and you receive a merkle tree
from B that in particular says that for the range [0..10] the hash is x. And on
[0..10] your has is x'. The problem is when [0..10] is partly one of your
range, partly not. For instance it can be that you're a replica for [8..10] but
not at all for [0..8].
This is due to the fact that the ranges for which the hashes are computed are
computed without concern for actual node ranges. So now you know there is some
inconsistency on [0..10] but it may just be that B is responsible for [0..8]
and have data for it (and we don't since we are not in charge of that).
In that case, the code do take the intersection of [0..10] with the local range
and will stream only [8..10]. But it's still useless.
> 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
>
>
> 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
