[jira] [Comment Edited] (CASSANDRA-4427) Restarting a failed bootstrap instajoins the ring

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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