cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-7356) Add a more ops friendly replace_address flag
Date Thu, 12 Jun 2014 19:27:02 GMT

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

Brandon Williams updated CASSANDRA-7356:
----------------------------------------

    Attachment: 7356.txt

Patch to enable replace_address_first_boot that you can always pass and decides what to do
based on the system table's bootstrapped flag.  Also  disallows using replace_address with
a node that claims to already be bootstrapped, since that's a pretty idea.


> Add a more ops friendly replace_address flag
> --------------------------------------------
>
>                 Key: CASSANDRA-7356
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7356
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Richard Low
>            Assignee: Brandon Williams
>             Fix For: 1.2.17, 2.0.9
>
>         Attachments: 7356.txt
>
>
> Doing a host replacement with cassandra.replace_address works well, but it is operationally
difficult because the flag needs clearing once the replace is successful. Most people will
launch through some scripts so remembering to clear the flag is a pain. Forgetting means the
node won't come up on a restart.
> We should have a flag like cassandra.replace_address_first_boot that works the same as
auto_bootstrap/initial_token: it is totally ignored if the node has successfully bootstrapped
but on starting from a clean disk it will work as the existing cassandra.replace_address.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message