cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2324) Repair transfers more data than necessary
Date Mon, 28 Mar 2011 14:00:06 GMT


Sylvain Lebresne commented on CASSANDRA-2324:

bq. couldn't we just take the interesection of the computed ranges w/ the range actually being

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:
>             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, 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" Key out of order! DecoratedKey(101571366040797913119296586470838356016,
> DecoratedKey(12639574763031545147067490818595764132, 0bc414be3093348a2ad389ed28f18f0cc9a044b2e98587848a0d289dae13ed0ad479c74654900eeffc6236)
>         at
>         at
> {noformat}

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message