[ https://issues.apache.org/jira/browse/CASSANDRA-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657165#comment-13657165 ]
Rick Branson commented on CASSANDRA-5565: ----------------------------------------- After thinking about this a bit, I think the right approach is to have the rest of the cluster reject nodes that try to connect with an existing broadcast address and a different hostID / token set. I tried to think through the various scenarios, and I can't think of any legitimate reason you'd need to do this. An ERROR-level log should be spit out on the nodes that rejected the connection with something like: "/{IP} attempted to join with different host ID / token(s). If this is intentional, please use 'nodetool removenode {hostID}' to safely remove the previous host ID from the cluster." I can work up a patch for this if others think this is a solid approach. Maybe we also need a -force option on nodetool removenode to provide access to the previous behavior? > Peer entry drops from system table silently when bootstrapping a node with an > existing IP. > ------------------------------------------------------------------------------------------ > > Key: CASSANDRA-5565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5565 > Project: Cassandra > Issue Type: Bug > Components: Core > Affects Versions: 1.2.4 > Reporter: Rick Branson > > It looks like CASSANDRA-5167 introduced a bit of a regression. I needed to > rebuild the data on a malfunctioning node by rebootstrapping it. I did this > by cleaning the host and restarting Cassandra. My plan was to remove the old > hostID once it had successfully bootstrapped. > No errors were encountered, but the old host ID of the node before the wipe > was completely dropped from the peers table because they had the same IP > address, and therefore the data ranges were moved around. This resulted in a > large number of CL.ONE reads coming back empty. > There might be a better approach to this rebootstrap process, but it seems > like it's dangerous to just drop the peer from the table, especially without > any kind of log message. -- 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