cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-2324) Repair transfers more data than necessary
Date Fri, 01 Apr 2011 15:01:07 GMT

     [ 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

Mime
View raw message