[ https://issues.apache.org/jira/browse/CASSANDRA-12485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429273#comment-15429273 ]
Achal Shah commented on CASSANDRA-12485: ---------------------------------------- Hi, I'm interested in working on this task - from my reading of it, it seems like checking {code}DatabaseDescriptor::getReplaceTokens{code} to ensure there are no replace tokens in the {code}StorageService::isReplacing{code} method should suffice - is that correct? Please correct me if I'm wrong; I haven't had a lot of experience with Cassandra internals. > Always require replace_address to replace existing token > -------------------------------------------------------- > > Key: CASSANDRA-12485 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12485 > 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 scenarios. > 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 (v6.3.4#6332)