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 Fri, 16 Mar 2018 07:45:00 GMT


Oleksandr Shulgin commented on CASSANDRA-5836:

{quote}That was always a datastax recommendation so I don't know where it came from. As I'm
sure you're aware, the Cassandra docs are quite sparse in the operations area, but all of
this should be documented properly.{quote}

Given the above comment from [~jjordan], the only reason I can still see to use {{auto_bootstrap=false}}
is to make new token allocation algorithm work on the new DC.  I would then also strongly
argue for following the DSE exampe and deprecating {{allocate_tokens_for_keyspace}} option,
exactly because this one requires you to add your new DC to your NTS data keyspace before
starting the nodes there.  The allocator depends solely on the local DC replication factor,
it doesn't need the keyspace to be replicated initially to the new nodes.

{quote}It's literally that it's irrelevant what the first node does. If auto_bootstrap is
true for the first node, it's a no-op, if it's false, it's a defined no-op. The first node
still respects auto_bootstrap, but the result is the same for either true or false. This is
always going to be the case.{quote}

I'm fully aware of that.  The problem is how to make sure that a node starting up *correctly*
assumes that it is the very first one.

{quote}The first node would be defined as a node that only has itself as a seed, and no existing
knowledge of any other node in the cluster.{quote}

OK, but this implies that you have to start the very first node differently from the rest
of the cluster.  If you want to have 3 seed nodes, what you do currently is just list all
of them in configuration and deploy nodes one by one, starting with the seeds, with identical
config and you're done.

With your proposed approach, there are two extra steps:
1. Deploy the very first seed node with a different config, i.e. only itself in the seeds
2. After other seeds nodes are there (or all nodes are there), restart the first node with
the complete seeds list.

So that already makes startup more complicated than it is currently.  And don't forget the
pluggable seeds providers: how (reliably) is this going to work together?

{quote}it's the fact that things get implemented without documentation{quote}

But this is exactly what I mean.  If it's because of attitude or not is just my judgement,
so let's set that aside.

My point is: by spending time on writing decent documentation (preferably, before starting
on the code!) it could be possible to avoid certain implementation pitfalls.  In some extreme
cases, like the aforementioned token allocation option, it would become obvious that the implementation
and the very name of the option is wrong: it should be about replication factor and not at
all about keyspace name.

> 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