cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleksandr Shulgin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5836) Seed nodes should be able to bootstrap without manual intervention
Date Fri, 09 Mar 2018 08:43:01 GMT

    [ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message