[
https://issues.apache.org/jira/browse/CASSANDRA-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16392587#comment-16392587
]
Oleksandr Shulgin commented on CASSANDRA-5836:
----------------------------------------------
{quote}If N>RF it becomes less likely that you'll have one replica in each DC
for every range.{quote}
Without defining {{N}} it's hard for me to say what you mean here. Maybe we
should move this part of discussion off the ticket? :)
{quote}nodetool rebuild should probably avoid rebuilding SimpleStrategy
keyspaces and you shouldn't get an error for them.{quote}
That would be nice.
{quote}Bootstrapping SimpleStrategy across DC's is still relevant as long as
SimpleStrategy exists.{quote}
To clarify we are not talking about significant amount of data, i.e.
user-defined keyspaces here? I would assume that if we teach nodetool rebuild
to ignore SimpleStrategy keyspaces, they could be cheaply spread to new DC by
running a repair targeted at these small system keyspaces only.
{quote}with my patch we could forget about the instructions telling people to
set auto_bootstrap=false when adding a new DC.{quote}
Hold on, how is this going to work at all? If the first node in new DC is
going to bootstrap (let's assume seeds are allowed to bootstrap) it will own
the whole token ring at first, so it will have to stream in all the data that
exists in the source DC, times the RF(s) of new DC. Even if the new node
doesn't die a horrible death in the process, you won't be able to add another
node to the cluster until this is finished. And even after that, adding the
next node to new DC will take ~50% of ownership from the first one, so you will
need to run cleanup on the first one in the end, etc. for the rest of the new
nodes.
It is totally unpractical to add new DC this way, so I firmly believe that
{{auto_bootstrap=false}} is here to stay for new DCs.
{quote}1. You still need code to handle the case where a seed starts with
auto_bootstrap=true but it's a new cluster.{quote}
I would prefer this just to fail with some helpful error message. Because:
{quote}You could potentially know when to fail by checking your seeds list and
seeing if you are the only seed (then create a cluster, else fail). But I still
don't see this as terribly necessary.{quote}
... I have doubts that any of these checks can be made really bullet-proof.
{quote}2. Seems a bit silly to have a new cluster procedure where the first
step is to "set this to false in the yaml... because we said so". Especially
when we can avoid that situation.{quote}
Well, we have this for adding new DCs, so not really that silly. It also
doesn't have to be "we said so", for me the explanation is simple: the first
seed node will fail the bootstrap otherwise, because there is no other nodes to
bootstrap from yet.
{quote}Note that when I say special case I mean a special case in the code, not
for the user. My patch (maybe with some tweaks) should be able to decide
automatically every case where a seed should bootstrap versus when it
shouldn't. If we can do that in the code, there's no reason to worry about
changing any procedures or behaviours, and we don't need to worry about
explaining the intricacies of why a seed can't bootstrap.{quote}
Again, I have serious doubts about all this automatic corner case detection.
As I've said before I'm totally fine with making initial cluster set up a
little bit more involved, if that makes operations on the clusters in
production more reliable.
> 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: [email protected]
For additional commands, e-mail: [email protected]
