cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Licata (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-12485) Always require replace_address to replace existing token
Date Fri, 23 Sep 2016 19:20:20 GMT


Christopher Licata  commented on CASSANDRA-12485:

 You should add a new check on {{StorageService.checkForEndpointCollision}}, similar to the
{{isSafeForStartup}} ... \[it\] should check if there are live nodes with the same tokens
as the new node and prevent bootstrap in this case.
So it seems as though the new {{containsTokensOfLiveOwners}} \(still working on the name\)
method in {{Gossiper}} should simply grab the current node's token list with {{StorageService.getTokens()}}
and then iterate through the {{liveEndpoints}} and do something like a {{Collections.disjoint}}
to see if there are any common elements in any of the lists.  

Does that seem correct? 

> Always require replace_address to replace existing token
> --------------------------------------------------------
>                 Key: CASSANDRA-12485
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Distributed Metadata
>            Reporter: Paulo Motta
>            Priority: Minor
>              Labels: lhf
> CASSANDRA-10134 prevented replace an existing node unless {{\-Dcassandra.replace_address}}
or {{\-Dcassandra.allow_unsafe_replace=true}} is specified.
> We should extend this behavior to tokens, preventing a node from joining the ring if
another node with the same token already existing in the ring, unless {{\-Dcassandra.replace_address}}
or {{\-Dcassandra.allow_unsafe_replace=true}} is specified in order to avoid catastrophic
> One scenario where this can easily happen is if you replace a node with another node
with a different IP, and after some time you restart the original node by mistake. The original
node will then take over the tokens of the replaced node (since it has a newer gossip generation).

This message was sent by Atlassian JIRA

View raw message