cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2434) range movements can violate consistency
Date Wed, 30 Apr 2014 21:57:19 GMT

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

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

+1 overall, with a few minor nitpicks on the dtest:

You can replace that string-building loop with:
{noformat}
tl = " ".join(str(t) for t in tokens[0][:8])
{noformat}

There's also a leftover line: {{#assert 1 == 0}}

Don't forget to mark the new tests with a {{@since('2.1')}} decorator.

> 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 beta2
>
>         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.2#6252)

Mime
View raw message