cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul cannon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2434) range movements can violate consistency
Date Wed, 08 Feb 2012 04:17:00 GMT

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

paul cannon commented on CASSANDRA-2434:
----------------------------------------

So, I believe that the rules outlined above can still work without the "wait X seconds between
bootstrap operations" prereq, if a pretty simple extra step is added:

If any node learns about conflicting move operations, then some rules are applied to choose
which will be honored and which will return an error to its caller (if still possible).

Those rules are:
* A decom for node X beats a move or bootstrap for node X
* Two decoms for node X from coordinator nodes Y and Z: the coordinator with the higher token
wins
* Any other conflicts between move/bootstrap operations for the same node (which can arise
in certain partition situations) are easily resolved by latest VersionedValue.

This should guarantee convergence of TokenMetadata across any affected parts of a cluster.
                
> 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: paul cannon
>             Fix For: 1.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 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

        

Mime
View raw message