[
https://issues.apache.org/jira/browse/CASSANDRA-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Clark updated CASSANDRA-8274:
------------------------------------
Description:
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.-
was:
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.
> 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)
