[
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392115#comment-16392115
]
Kurt Greaves commented on CASSANDRA-5836:
-----------------------------------------
bq. Hm, I've tested the procedure quite a number of times and every time I
forgot to change the replication to NTS or to extend the replication to the new
DC I was getting a complaint from nodetool rebuild.
If N>RF it becomes less likely that you'll have one replica in each DC for
every range. But it's irrelevant anyway, {{nodetool rebuild}} should probably
avoid rebuilding SimpleStrategy keyspaces and you shouldn't get an error for
them. Bootstrapping SimpleStrategy across DC's is still relevant as long as
SimpleStrategy exists. The only solutions here are either to (1) remove
SimpleStrategy, (2) bootstrap new nodes within a new DC, or (3) disallow
addition of a DC when SimpleStrategy is being used. 1 is hard + unreasonable
and 3 is just unreasonable. 2 makes the most sense, and with my patch we could
forget about the instructions telling people to set auto_bootstrap=false when
adding a new DC.
bq. Do you mean it is more common to see the error with a small cluster or
other way round: more common that it will work with a small cluster?
It's more common that people do this with small clusters and it works/they
don't realise that they didn't change to NTS.
Well that makes sense. But there's a few issues:
# You still need code to handle the case where a seed starts with
auto_bootstrap=true but it's a new cluster. You could potentially know when to
fail by checking your seeds list and seeing if you are the only seed (then
create a cluster, else fail). But I still don't see this as terribly necessary.
# Seems a bit silly to have a new cluster procedure where the first step is to
"set this to false in the yaml... because we said so". Especially when we can
avoid that situation.
Note that when I say special case I mean a special case in the code, not for
the user. My patch (maybe with some tweaks) should be able to decide
automatically every case where a seed should bootstrap versus when it
shouldn't. If we can do that in the code, there's no reason to worry about
changing any procedures or behaviours, and we don't need to worry about
explaining the intricacies of why a seed can't bootstrap.
> Seed nodes should be able to bootstrap without manual intervention
> ------------------------------------------------------------------
>
> Key: CASSANDRA-5836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5836
> Project: Cassandra
> Issue Type: Bug
> Reporter: Bill Hathaway
> Priority: Minor
>
> The current logic doesn't allow a seed node to be bootstrapped. If a user
> wants to bootstrap a node configured as a seed (for example to replace a seed
> node via replace_token), they first need to remove the node's own IP from the
> seed list, and then start the bootstrap process. This seems like an
> unnecessary step since a node never uses itself as a seed.
> I think it would be a better experience if the logic was changed to allow a
> seed node to bootstrap without manual intervention when there are other seed
> nodes up in a ring.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
