[
https://issues.apache.org/jira/browse/CASSANDRA-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657512#comment-13657512
]
Rick Branson commented on CASSANDRA-5565:
-----------------------------------------
That's exactly what I expected to occur. As soon as the node I wiped joined,
the tokens from it's previous incarnation were completely dropped from the
ring, causing the ranges to shift. Perhaps I'm improperly blaming
CASSANDRA-5167, but that was the result.
> 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
