[
https://issues.apache.org/jira/browse/CASSANDRA-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657382#comment-13657382
]
Brandon Williams commented on CASSANDRA-5565:
---------------------------------------------
I'm not sure what the problem is here. If you wiped the node and restarted it,
it would get new tokens and you'd have to removenode the old one, which would
still be around. After that, everything should be normal (though I'll note
CASSANDRA-5337 will ultimately be a superior way of doing this.) Also worth
noting you can, painfully, specify all the tokens to replace_token in a csv
list.
> Peer entry drops from system table silently when bootstrapping a node with an
> existing IP.
> ------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-5565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5565
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.4
> Reporter: Rick Branson
>
> It looks like CASSANDRA-5167 introduced a bit of a regression. I needed to
> rebuild the data on a malfunctioning node by rebootstrapping it. I did this
> by cleaning the host and restarting Cassandra. My plan was to remove the old
> hostID once it had successfully bootstrapped.
> No errors were encountered, but the old host ID of the node before the wipe
> was completely dropped from the peers table because they had the same IP
> address, and therefore the data ranges were moved around. This resulted in a
> large number of CL.ONE reads coming back empty.
> There might be a better approach to this rebootstrap process, but it seems
> like it's dangerous to just drop the peer from the table, especially without
> any kind of log message.
--
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
