[
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387545#comment-16387545
]
Oleksandr Shulgin commented on CASSANDRA-5836:
----------------------------------------------
{quote}Nobody really seems to understand why it's not safe for a seed node to
bootstrap{quote}
I think the reasoning here is as follows: if seed nodes were allowed to
bootstrap, the very first seed node would need some mechanism to opt out (or it
will never be able to start). Such a mechanism is dangerous to have in the
first place, because it can fail and then you will allow a node to skip
bootstrap then it must not skip it.
But the above only holds in the context of the default {{auto_bootstrap=true}}
setting. If we require that it is set to {{false}} when deploying new
clusters/DCs, the problem goes away and we don't need a special case for the
very first node.
This way we also don't need the special case of seed nodes at all: the
bootstrap behavior can be controlled entirely by the {{auto_bootstrap}}
parameter value, regardless of the node's seed status. It then becomes *safer*
to bootstrap a seed node, than not, as with any other node, because it performs
more checks which can detect configuration problems and doesn't accept client
reads before it has fully joined the ring.
{quote}It's worth noting here that there is the case of SimpleStrategy in which
you wouldn't want auto_bootstrap=false (this affects auth, traces,
system_distributed). This is specifically why you would want every node to
bootstrap in a new DC (including seeds). The alternative is to get rid of
SimpleStrategy (or at least stop using it as a default).{quote}
The only case I see when {{SimpleStrategy}} can actually work with multiple DCs
is when you start multi-DC from scratch. The auth keyspace you will want to
change to use NTS and replicate to all DCs, but you might not care about the
other two non-local system keyspaces.
But are you referring here to a case where you would add a new DC to a cluster
with data already in the original DC and still using {{SimpleStrategy}},
[~KurtG]? To me that doesn't seem to be practical. Even if your data set is
so small that you can bootstrap the first node of the new DC w/o running out of
disk space, how do you make new seeds bootstrap? Or do you suggest to add all
nodes as non-seeds first and then do a rolling restart to indicate the seeds?
Any reason why would you want to go this way instead of the proper {{nodetool
rebuild}}?
> 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
