Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 6 Nov 2014 23:59:35 +0000 (UTC)
From: "Joseph Clark (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12753560.1415317375000.440231.1415318375848@Atlassian.JIRA>
In-Reply-To: <JIRA.12753560.1415317375000@Atlassian.JIRA>
References: <JIRA.12753560.1415317375000@Atlassian.JIRA>
 <JIRA.12753560.1415317375463@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-8274) Node fails to rejoin
 cluster on EC2 if private IP is changed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Joseph Clark edited comment on CASSANDRA-8274 at 11/6/14 11:59 PM:
-------------------------------------------------------------------

7292 and 8072 have different stack traces[edit: though admittedly I'm unsure if this is just a result of different versions]. Which did you reproduce?


was (Author: jw.clark):
7292 and 8072 have different stack traces. Which did you reproduce?

> 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)