[ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vijay updated CASSANDRA-957: ---------------------------- Attachment: 0003-making-bootstrap-sleep-longer.patch 0002-upport-for-hints-on-token-v3.patch 0001-support-for-replace-token-v3.patch Rebased.... with a better way to look for operator error. > 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-Token-Replace.patch, > 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.patch, > 0001-Support-token-replace.patch, 0001-support-for-replace-token-v3.patch, > 0002-Do-not-include-local-node-when-computing-workMap.patch, > 0002-Rework-Hints-to-be-on-token.patch, > 0002-Rework-Hints-to-be-on-token.patch, > 0002-upport-for-hints-on-token-v3.patch, > 0003-Make-HintedHandoff-More-reliable.patch, > 0003-Make-hints-More-reliable.patch, 0003-making-bootstrap-sleep-longer.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