cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleksandr Shulgin (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5836) Seed nodes should be able to bootstrap without manual intervention
Date Tue, 06 Mar 2018 09:59:00 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message