cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Goffinet (JIRA)" <>
Subject [jira] Updated: (CASSANDRA-957) convenience workflow for replacing dead node
Date Wed, 02 Feb 2011 22:55:29 GMT


Chris Goffinet updated CASSANDRA-957:

    Attachment: 0002-Do-not-include-local-node-when-computing-workMap.patch

Found when testing using RF=2 that there is a chance that the local node could be included
in the workMap, and be the first node ordered by proximity. workMap uses the first node from
the list as a source. This would cause sending Bootstrap stream sessions to itself.

> convenience workflow for replacing dead node
> --------------------------------------------
>                 Key: CASSANDRA-957
>                 URL:
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Core, Tools
>            Reporter: Jonathan Ellis
>            Assignee: Chris Goffinet
>             Fix For: 0.8
>         Attachments: 0001-Support-bringing-back-a-node-to-the-cluster-that-exi.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:


View raw message