[
https://issues.apache.org/jira/browse/CASSANDRA-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747853#comment-13747853
]
Brandon Williams commented on CASSANDRA-5916:
---------------------------------------------
This isn't so much a problem with retrying the replace, as it is with the same
IP address (which won't at all currently.) The reason for this is that by using
the same IP address, the replacing node itself changes the HOST_ID, and then
can't find the old one. It's not just as simple as not advertising a new
HOST_ID either, by not having one but modifying STATUS we wipe out any existing
HOST_ID as well.
> gossip and tokenMetadata get hostId out of sync on failed replace_node
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-5916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5916
> Project: Cassandra
> Issue Type: Bug
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2.9
>
>
> If you try to replace_node an existing, live hostId, it will error out.
> However if you're using an existing IP to do this (as in, you chose the wrong
> uuid to replace on accident) then the newly generated hostId wipes out the
> old one in TMD, and when you do try to replace it replace_node will complain
> it does not exist. Examination of gossipinfo still shows the old hostId,
> however now you can't replace it either.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
