Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <1246892099.1260280158121.JavaMail.jira@brutus>
Date: Tue, 8 Dec 2009 13:49:18 +0000 (UTC)
From: "Jaakko Laine (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Commented: (CASSANDRA-564) Provide recoverability when a
 node dies and it is impossible to get the same IP.
In-Reply-To: <715836272.1258659219630.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jaakko Laine commented on CASSANDRA-564:
----------------------------------------

I think we can do with existing STATE_LEFT gossip state, just use the kind of tuple mentioned earlier as an application state. If STATE_LEFT was a result of normal leave, just do the same thing as now. If it was a result of remove token command, the nodes affected by range changes, get the data from other replicas to restore replica count. Decommissioning could be left as it is, since it is a case of node gracefully leaving and handing over its data to other nodes. Remove token is to signal to other nodes that this node is no loger in service, so please restore replica count to what it should be.

This latter functionality could be used together with Gossiper to have the cluster automatically maintain replica count (automatically joust a node ouf ot cluster and restore replica count after certain period of time). Don't know if this kind of functionality would be needed, but having such self-repair would be nice at least on paper.


> Provide recoverability when a node dies and it is impossible to get the same IP.
> --------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-564
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-564
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Anthony Molinaro
>            Priority: Minor
>             Fix For: 0.5
>
>
> From the descriptions on the mailing list, when a node dies permanently from hardware or other failure and you need to replace it, it must have the same IP.  For people running in cloud environments, this is often times impossible.  So it would be very useful if there was a way to replace a node with a new node without requiring the same IP.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.