[
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401552#comment-16401552
]
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 list.
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: 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
