Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 2 Sep 2011 20:41:10 +0000 (UTC)
From: "Vijay (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <2070319399.12409.1314996070282.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CASSANDRA-957) convenience workflow for replacing
 dead node
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vijay updated CASSANDRA-957:
----------------------------

    Attachment: 0001-support-token-replace-v7.patch

Yeah sorry for the oversight on onRestart() but markAsDead() is intentional otherwise the if the node is coming with the same IP even though we dont markAsAlive we will see the traffic flowing though it as it is because of the gossip hence we make sure we dont do that until it is marked alive.... 

> 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, 0001-support-token-replace-v6.patch, 0001-support-token-replace-v7.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-hints-on-token-than-ip-v6.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