[
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.
