cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Branson (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5565) Peer entry drops from system table silently when bootstrapping a node with an existing IP.
Date Tue, 14 May 2013 16:11:18 GMT

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

Rick Branson edited comment on CASSANDRA-5565 at 5/14/13 4:11 PM:
------------------------------------------------------------------

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?
                
      was (Author: rbranson):
    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

Mime
View raw message