[
https://issues.apache.org/jira/browse/CASSANDRA-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201345#comment-14201345
]
Joseph Clark commented on CASSANDRA-8274:
-----------------------------------------
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1193)
at
org.apache.cassandra.service.StorageService.*prepareReplacementInfo*(StorageService.java:419)
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:650)
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1200)
at
org.apache.cassandra.service.StorageService.*checkForEndpointCollision*(StorageService.java:444)
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:655)
Slightly different :)
Even if they were the same, I believe that they are still separate issues. 7292
and this bug both involve starting a node that the cluster *already knows
about* as identified by the public lP. Another similarity between 7292 and this
bug, in my case at least and likely the original reporter as well, is that the
private IP/listen_address has been changed. As far as I can tell, 8072 occurs
with brand new nodes that aren't replacing another node in the cluster.
> 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)
