[
https://issues.apache.org/jira/browse/CASSANDRA-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885653#action_12885653
]
Nick Bailey commented on CASSANDRA-1216:
----------------------------------------
It seems like this should follow a pattern similar to decommissioning a node.
* If nodeA has removeToken called on it, it becomes responsible for nodeB, the
node to remove
* nodeA sets the MOVE_STATE of nodeB to STATE_REMOVING
* This is gossipped throughout the ring.
* Nodes see this change and fetch any ranges they are becoming responsible for
** After this is complete they will need to notify nodeA somehow that this is
complete
* Once nodeA sees all replications have finished, change state of nodeB to
STATE_REMOVED
* All nodes then remove nodeB from their ring.
> removetoken drops node from ring before re-replicating its data is finished
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-1216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1216
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Nick Bailey
> Fix For: 0.7
>
>
> this means that if something goes wrong during the re-replication (e.g. a
> source node is restarted) there is (a) no indication that anything has gone
> wrong and (b) no way to restart the process (other than the Big Hammer of
> running repair)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
