You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Bill Hathaway (JIRA)" <ji...@apache.org> on 2013/06/20 23:53:20 UTC

[jira] [Commented] (CASSANDRA-5608) "Primary range" repair still isn't quite NTS-aware

    [ https://issues.apache.org/jira/browse/CASSANDRA-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689730#comment-13689730 ] 

Bill Hathaway commented on CASSANDRA-5608:
------------------------------------------

If we are using the standard token assignment strategy of +1 for each new datacenter, when running repair -pr on any data center not the primary one (that starts with first node token=0), we can see it running a repair for a range of 1, versus the normal huge range on the primary data center.


Example on 1.1.10 from primary data center (huge range)
2013-05-26 09:07:07,728 [AntiEntropySessions:7] INFO AntiEntropyService [repair #a42df6e0-c5e3-11e2-0000-dad4ff6f95da] new session: will sync /172.20.248.95 on range (106338239662793269832304564822427566081,127605887595351923798765477786913079296] for UnitTestKeyspace.[CF1,CF2,CF3]

Example on 1.1.10 from secondary data center (range of 1)
2013-06-20 19:11:39,238 [AntiEntropySessions:23] INFO AntiEntropyService [repair #3c031150-d9dd-11e2-0000-b258590872ff] new session: will sync /172.20.156.220 on range (148873535527910577765226390751398592512,148873535527910577765226390751398592513] for UnitTestKeyspace.[CF1,CF2,CF3]

                
> "Primary range" repair still isn't quite NTS-aware
> --------------------------------------------------
>
>                 Key: CASSANDRA-5608
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5608
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 1.2.5
>            Reporter: Jonathan Ellis
>
> Consider the case of a four node cluster, with nodes A and C in DC1, and nodes B and D in DC2.  TokenMetadata will break this into ranges of (A-B], (B-C], (C-D], (D-A].
> If we have a single copy of a keyspace stored in DC1 only (none in DC2), then the current code correctly calculates that node A is responsible for ranges (C-D], (D-A].
> But, if we add a copy in DC2, then we only calculate (D-A] as primary range.  This is a bug; we should not care what copies are in other datacenters, when computing what to repair in the local one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira