Oleksandr Shulgin commented on CASSANDRA-5836:

{quote}Nobody really seems to understand why it's not safe for a seed node to 

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 

> 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

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to