Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 19 Feb 2014 21:06:25 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12503655.1302197035356.67269.1392843985531@arcas>
In-Reply-To: <JIRA.12503655.1302197035356@arcas>
References: <JIRA.12503655.1302197035356@arcas>
Subject: [jira] [Commented] (CASSANDRA-2434) range movements can violate
 consistency
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Tyler Hobbs commented on CASSANDRA-2434:
----------------------------------------

Thanks, Jake.

I strongly prefer to default to the strict/safe behavior and make the user supply a "force" option for non-strict behavior, like Nick and Paul agreed on above.  If the bootstrapping node cannot stream from the correct replica and the "force" option isn't set, it should abort the bootstrap with an error that describes the implications and mentions how to use the "force" option.

Additionally, I think your logic for picking the preferred replica could be greatly simplified.  Paul's 2434-3.patch.txt has a really simple version of this and also has the strict-by-default behavior.  It might be worthwhile to look at rebasing that patch as a start.

Paul mentioned this:

bq. Conversation on #cassandra-dev resulted in the conclusion that we'll fix this bug for range acquisition (bootstrap and move) now, and plan to allow the same looseness (non-strict mode, or whatever) for range egress (move and decom) in the future.

Looking at the irc logs, there wasn't a strong reason for this.  There's a lot of code overlap there, so it would be ideal to fix both types of operations at once.  Do you think you could take a stab at that?

> range movements can violate consistency
> ---------------------------------------
>
>                 Key: CASSANDRA-2434
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2434
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Peter Schuller
>            Assignee: T Jake Luciani
>             Fix For: 2.1
>
>         Attachments: 2434-3.patch.txt, 2434-testery.patch.txt
>
>
> My reading (a while ago) of the code indicates that there is no logic involved during bootstrapping that avoids consistency level violations. If I recall correctly it just grabs neighbors that are currently up.
> There are at least two issues I have with this behavior:
> * If I have a cluster where I have applications relying on QUORUM with RF=3, and bootstrapping complete based on only one node, I have just violated the supposedly guaranteed consistency semantics of the cluster.
> * Nodes can flap up and down at any time, so even if a human takes care to look at which nodes are up and things about it carefully before bootstrapping, there's no guarantee.
> A complication is that not only does it depend on use-case where this is an issue (if all you ever do you do at CL.ONE, it's fine); even in a cluster which is otherwise used for QUORUM operations you may wish to accept less-than-quorum nodes during bootstrap in various emergency situations.
> A potential easy fix is to have bootstrap take an argument which is the number of hosts to bootstrap from, or to assume QUORUM if none is given.
> (A related concern is bootstrapping across data centers. You may *want* to bootstrap to a local node and then do a repair to avoid sending loads of data across DC:s while still achieving consistency. Or even if you don't care about the consistency issues, I don't think there is currently a way to bootstrap from local nodes only.)
> Thoughts?


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)