cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Bailey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-957) convenience workflow for replacing dead node
Date Thu, 25 Aug 2011 22:18:31 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091364#comment-13091364
] 

Nick Bailey commented on CASSANDRA-957:
---------------------------------------

The hint rework looks good. The only comment I have there is that it would be nice if the
logging statements for sending hints creating hints indicated the ip as well as the token.
Even though it's stored by token it would be nice to immediately see the ip in the log without
having to look it up.

I'm also unsure about the reasoning behind the last patch. Why increase the initial sleep
in joinTokenRing?

> 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

        

Mime
View raw message