cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3219) Nodes started at the same time end up with the same token
Date Mon, 19 Sep 2011 15:02:09 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107882#comment-13107882
] 

Sylvain Lebresne commented on CASSANDRA-3219:
---------------------------------------------


bq. Further, the old behavior doesn't let you specify bootstrap/random

That would depend on what is definition of valid. In my opinion, picking random token is *always*
stupid, it will always result in crappy distribution (it just happens to be less stupid than
"auto" in the noboostrap case, which imho is and should remain the only reason we ever generate
random token). If you bootstrap, it means you have an existing cluster with data in it (I'm
not saying you *have to*, I'm saying this is why bootstrap is for and so should be the case
if you don't do something wrong). In such situation, I don't see why you would want to pick
a random token. If some people like to live on the edge, they can write a random token generator
and use that, but that we would want to expose an option, hence suggesting that this could
be something useful ...

bq. or nobootstrap/auto, both of which are valid things to do

Again, really depends on the definition of "valid". First, if you start two nodes at the same
time with that, you end up in this ticket situation. Sure the patch adds a "don't do it" comment
but it doesn't really fix it more than that. Second, noboostrap (when token selection is involved,
i.e, not a replace_token) is mainly useful to set up an initial cluster, that is when nodes
don't have data at all (otherwise you want to bootstrap the node). In that situation, auto
will likely don't do anything useful (it's a completely degenerated case for the algorithm).
That the nobootstrap/auto pair doesn't work correctly is actually the only reason I can come
up for us picking a random token in <= 0.8 versions.

Besides, when was the last time we had a user requesting to do one of boostrap/random or nobootstrap/auto,
or us recommanding anything else than 'pick your token yourself'?

bq. I don't see how this helps the situation Jake describes

I'm willing to bet that when Jake encountered that problem he was trying to set up an initial
cluster *before* having set up schemas and inserted some data. In that case, the second patch
would pick a random token so there wouldn't be problem.

The thing is, there is not too many way to create a Cassandra cluster. First you create a
cluster with n initial machines. For that you want to be in mode noboostrap/random (noboostrap/auto
doesn't really work too well with no data; and by noboostrap I don't really speak of the auto-boostrap=false
option, but more of not doing data streaming). Once you have data in the cluster, you want
to bootstrap and then auto is always less stupid than random (IMHO). Hence the rational for
the v2 patch.

bq. This is a non-starter

I find it weird to consider that a non-starter so rapidly when we all know that the very first
advise we give is to hand pick token and that it's unreasonable to use auto (let's not talk
about random) token in any real life situation (even the config file basically says it). But
I'm willing to consider that it's not the right time to discuss that and to discard that solution,
at least for now.


> Nodes started at the same time end up with the same token
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-3219
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3219
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 1.0.0
>            Reporter: T Jake Luciani
>            Assignee: Jonathan Ellis
>              Labels: bootstrap
>             Fix For: 1.0.0
>
>         Attachments: 3219.txt, 3219_v2.patch
>
>
> Since autoboostrap is defaulted to on when you start a cluster at once (http://screenr.com/5G6)
you can end up with nodes being assigned the same token.
> {code}
> INFO 17:34:55,688 Node /67.23.43.14 is now part of the cluster
>  INFO 17:34:55,698 InetAddress /67.23.43.14 is now UP
>  INFO 17:34:55,698 Nodes /67.23.43.14 and tjake2/67.23.43.15 have the same token 8823900603000512634329811229926543166.
 Ignoring /67.23.43.14
>  INFO 17:34:55,698 Node /98.129.220.182 is now part of the cluster
>  INFO 17:34:55,698 InetAddress /98.129.220.182 is now UP
>  INFO 17:34:55,698 Nodes /98.129.220.182 and tjake2/67.23.43.15 have the same token 8823900603000512634329811229926543166.
 Ignoring /98.129.220.182
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message