You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Brandon Williams (JIRA)" <ji...@apache.org> on 2014/11/07 00:48:34 UTC

[jira] [Commented] (CASSANDRA-8274) Node fails to rejoin cluster on EC2 if private IP is changed

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

Brandon Williams commented on CASSANDRA-8274:
---------------------------------------------

bq. This appears to me to be the root cause of https://issues.apache.org/jira/browse/CASSANDRA-7292. Possibly https://issues.apache.org/jira/browse/CASSANDRA-8072

Neither, because I've repro'd it and don't use EC2.

> Node fails to rejoin cluster on EC2 if private IP is changed
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-8274
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8274
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Amazon EC2
>            Reporter: Joseph Clark
>
> Nodes in Amazon AWS EC2 Classic (not a VPC) may be assigned a new private IP if the node is stopped and then started again. In this case we have puppet update the configured listen_address to the new private IP. However, once the cassandra service starts, it is unable to communicate with the existing nodes(single region) and vice versa.
> 'nodetool status' shows that each node believes that it is 'UN' and the other node is 'DN'.
> 'nodetool gossipinfo' on the node that remained running shows the *old* private IP listed as the 'INTERNAL_IP' of the node that was stopped and restarted. 
> The situation is resolved by restarting the cassandra service on the node that remained running. Once it has restarted, the INTERNAL_IP is correctly updated to the new private IP. 'nodetool status' shows that both nodes are up and the cluster appears to function normally.
> This appears to me to be the root cause of https://issues.apache.org/jira/browse/CASSANDRA-7292. Possibly https://issues.apache.org/jira/browse/CASSANDRA-8072 as well, but I am not convinced they are actually duplicates.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)