[
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
