You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Brandon Williams (JIRA)" <ji...@apache.org> on 2011/07/20 03:18:57 UTC

[jira] [Updated] (CASSANDRA-2825) Auto bootstrapping the 4th node in a 4 node cluster doesn't work, when no token explicitly assigned in config.

     [ https://issues.apache.org/jira/browse/CASSANDRA-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brandon Williams updated CASSANDRA-2825:
----------------------------------------

    Attachment: 2825.txt

Patch to exclude the system ks from key sampling when choosing a token, and assert that the token is not our own.

What was happening is that when 0's range was split, it didn't have more than 3 keys, so it used the midpoint.  When 85070591730234615865843651857942052864 split, it did have enough keys (in the system ks) and it sampled 61078635599166706937511052402724559481.  After this, 61078635599166706937511052402724559481 had the highest load and when it sampled it also arrived at 61078635599166706937511052402724559481 since it was using the system ks.

This patches forces using the midpoint method when there is no data other than the system ks, which is the right thing to do since the system ks data is never moved.

> Auto bootstrapping the 4th node in a 4 node cluster doesn't work, when no token explicitly assigned in config.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-2825
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2825
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.8.0, 0.8.1
>            Reporter: Michael Allen
>            Assignee: Brandon Williams
>             Fix For: 0.8.2
>
>         Attachments: 2825.txt
>
>
> This was done in sequence.  A, B, C, and D.  Node A with token 0 explicitly set in config.  The rest with auto_bootstrap: true and no token explicitly assigned.  B and C work as expected. D ends up stealing C's token.  
> from system.log on C:
> INFO [GossipStage:1] 2011-06-24 16:40:41,947 Gossiper.java (line 638) Node /10.171.47.226 is now part of the cluster
> INFO [GossipStage:1] 2011-06-24 16:40:41,947 Gossiper.java (line 606) InetAddress /10.171.47.226 is now UP
> INFO [GossipStage:1] 2011-06-24 16:42:09,432 StorageService.java (line 769) Nodes /10.171.47.226 and /10.171.55.77 have the same token 61078635599166706937511052402724559481.  /10.171.47.226 is the new owner
> WARN [GossipStage:1] 2011-06-24 16:42:09,432 TokenMetadata.java (line 120) Token 61078635599166706937511052402724559481 changing ownership from /10.171.55.77 to /10.171.47.226

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira