[
https://issues.apache.org/jira/browse/CASSANDRA-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416921#comment-13416921
]
Jonathan Ellis edited comment on CASSANDRA-4427 at 7/18/12 7:35 AM:
bq. I believe this simpler fix doesn't handle the case of boostrapping multiple
nodes into an existing cluster.
We've never tried to prevent this in the existing cluster case, except by
saying thou shalt space bootstraps apart two minutes, because the only way to
stop it is to drop the balanced token picking altogether. Adding bootstrap
in progress concept does nothing for this one way or the other.
bq. Namely, in that case, that will have a schema and so the node will have a
system table by the time it checks for it and we'll end up picking the same
token for multiple nodes.
This is exactly how it's supposed to work: if there's a schema, we use
existing cluster mode and pick a token to divide the range of the heaviest
node (and cross our fingers that the user is spacing things out enough between
node additions). If there's no schema, we use new cluster mode and pick a
random token.
Let the record show that back in CASSANDRA-3219 I said this was confusing
behavior and we should add explicit initial_token modes instead of trying to
make it magical. :)
was (Author: jbellis):
bq. I believe this simpler fix doesn't handle the case of boostrapping
multiple nodes into an existing cluster.
We've never tried to prevent this, except by saying thou shalt space
bootstraps apart two minutes, because the only way to stop it is to drop the
balanced token picking altogether. Adding bootstrap in progress concept
does nothing for this one way or the other.
bq. Namely, in that case, that will have a schema and so the node will have a
system table by the time it checks for it and we'll end up picking the same
token for multiple nodes.
This is exactly how it's supposed to work: if there's a schema, we use
existing cluster mode and pick a token to divide the range of the heaviest
node (and cross our fingers that the user is spacing things out enough between
node additions). If there's no schema, we use new cluster mode and pick a
random token.
Let the record show that back in CASSANDRA-3219 I said this was confusing
behavior and we should add explicit initial_token modes instead of trying to
make it magical. :)
Restarting a failed bootstrap instajoins the ring
-
Key: CASSANDRA-4427
URL: https://issues.apache.org/jira/browse/CASSANDRA-4427
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Brandon Williams
Assignee: Jonathan Ellis
Fix For: 1.0.11, 1.1.3
Attachments: 4427-v2.txt, 4427-v3.txt, 4427.txt
I think when we made auto_bootstrap = true the default, we broke the check
for the bootstrap flag, creating a dangerous situation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
