[
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16399485#comment-16399485
]
Kurt Greaves commented on CASSANDRA-5836:
-----------------------------------------
bq. I believe it would be still required to set it to false, unless you want to
replace this recommendation with running TRUNCATE system.available_ranges
post-bootstrap on every node of the new DC. Otherwise, nodetool rebuild is not
going to do anything because the new nodes would think that they already have
all the data due to bootstrap. Or am I missing something?
{{system.available_ranges}} works off keyspaces, so rebuild will still work
fine as long as you didn't add RF before provisioning the DC (e.g you didn't
bootstrap the NTS keyspaces). It's not really a big deal either way.
bq. At the same time, new cluster startup process can be arbitrarily complex
No, it can't. That's not a good introduction to Cassandra. Cassandra is hard
enough to use as it is, and we really shouldn't be making operations more
complex. Software exists to make things easier for humans; we shouldn't shy
away from complexity just because it makes the code harder to understand. That
defeats the purpose of writing code in the first place. I still think this is a
really bad idea and having this all handled in the code is a much better
solution. Far more logical to be able to say that "All nodes will respect the
auto_bootstrap setting regardless of their configuration". The only caveat is
that the first node won't bootstrap, but to users this is irrelevant and they
don't need to know about it. To users it's all the same to them as
bootstrapping when there are no other nodes is a no-op.
> 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: [email protected]
For additional commands, e-mail: [email protected]
