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

Jingsi Zhu commented on CASSANDRA-5571:
---------------------------------------

Hi, Jingsi Zhu is no longer at Facebook so this email address is no longer 
being monitored. If you need assistance, please contact another person who is 
currently at the company.

                
> Reject bootstrapping endpoints that are already in the ring with different 
> gossip data
> --------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5571
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5571
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Rick Branson
>            Assignee: Rick Branson
>
> The ring can be silently broken by improperly bootstrapping an endpoint that 
> has an existing entry in the gossip table. In the case where a node attempts 
> to bootstrap with the same IP address as an existing ring member, the old 
> token metadata is dropped without warning, resulting in range shifts for the 
> cluster.
> This isn't so bad for non-vnode cases where, in general, tokens are 
> explicitly assigned, and a bootstrap on the same token would result in no 
> range shifts. For vnode cases, the convention is to just let nodes come up by 
> selecting their own tokens, and a bootstrap will override the existing tokens 
> for that endpoint.
> While there are some other issues open for adding an explicit rebootstrap 
> feature for vnode cases, given the changes in operator habits for vnode 
> rings, it seems a bit too easy to make this happen. Even more undesirable is 
> the fact that it's basically silent.
> This is a proposal for checking for this exact case: bootstraps on endpoints 
> with existing ring entries that have different hostIDs and/or tokens should 
> be rejected with an error message describing what happened and how to 
> override the safety check. It looks like the override can be supported using 
> the existing "nodetool removenode -force".
> I can work up a patch for this.

--
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

Reply via email to