[
https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vijay updated CASSANDRA-957:
----------------------------
Attachment: 0002-hints-on-token-than-ip-v5.patch
0001-support-token-replace-v5.patch
• Looks like some tests are failing with these patches applied.
Want to look into that?
Fixed somehow this got missed from v1 to v4...
• Can you revert the logging change in gossiper for when a node
restarts? You changed it to, 'logger.info("Node {} has been restarted...",
ep);' which isn't particularly more informative. The old logging statement
allowed you
to easily grep for 'UP' in the logs.
Done!
• Can we only sleep for BROADCAST_INTERVAL if we are actually
replacing a token? No reason to add extra sleeping to the normal bootstrap case.
If we do that we will not be able to check the update interval because all the
messages will be within the delay interval…. sleeping little more will make
allow us to identify the node isAlive or not (if in case the replacing node
with a different IP is alive) - Plz check EndpointState(HeartBeatState
initialHbState)
• Nitpick: you added some random whitespace throughout those 2
patches at the ends of lines. Can we remove that when you fix the above.
Not sure where you see it.
> convenience workflow for replacing dead node
> --------------------------------------------
>
> Key: CASSANDRA-957
> URL: https://issues.apache.org/jira/browse/CASSANDRA-957
> Project: Cassandra
> Issue Type: Wish
> Components: Core, Tools
> Affects Versions: 0.8.2
> Reporter: Jonathan Ellis
> Assignee: Vijay
> Fix For: 1.0
>
> Attachments:
> 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch,
> 0001-support-for-replace-token-v3.patch, 0001-support-token-replace-v4.patch,
> 0001-support-token-replace-v5.patch,
> 0002-Do-not-include-local-node-when-computing-workMap.patch,
> 0002-hints-on-token-than-ip-v4.patch, 0002-hints-on-token-than-ip-v5.patch,
> 0002-upport-for-hints-on-token-v3.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Replacing a dead node with a new one is a common operation, but "nodetool
> removetoken" followed by bootstrap is inefficient (re-replicating data first
> to the remaining nodes, then to the new one) and manually bootstrapping to a
> token "just less than" the old one's, followed by "nodetool removetoken" is
> slightly painful and prone to manual errors.
> First question: how would you expose this in our tool ecosystem? It needs to
> be a startup-time option to the new node, so it can't be nodetool, and
> messing with the config xml definitely takes the "convenience" out. A
> one-off -DreplaceToken=XXY argument?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
