Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 12 May 2016 15:07:12 +0000 (UTC)
From: "Alex Petrov (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12729009.1406068960000.176026.1463065632941@Atlassian.JIRA>
In-Reply-To: <JIRA.12729009.1406068960000@Atlassian.JIRA>
References: <JIRA.12729009.1406068960000@Atlassian.JIRA> <JIRA.12729009.1406068960680@arcas>
Subject: [jira] [Commented] (CASSANDRA-7592) Ownership changes can violate
 consistency
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 12 May 2016 15:07:14 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-7592?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
15281588#comment-15281588 ]=20

Alex Petrov commented on CASSANDRA-7592:
----------------------------------------

This issue is also very much related to 9677, where [~jasobrown] proposes t=
o strongly consistent membership and ownership.=20

> Ownership changes can violate consistency
> -----------------------------------------
>
>                 Key: CASSANDRA-7592
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7592
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Richard Low
>            Assignee: Alex Petrov
>
> CASSANDRA-2434 goes a long way to avoiding consistency violations when gr=
owing a cluster. However, there is still a window when consistency can be v=
iolated when switching ownership of a range.
> Suppose you have replication factor 3 and all reads and writes at quorum.=
 The first part of the ring looks like this:
> Z: 0
> A: 100
> B: 200
> C: 300
> Choose two random coordinators, C1 and C2. Then you bootstrap node X at t=
oken 50.
> Consider the token range 0-50. Before bootstrap, this is stored on A, B, =
C. During bootstrap, writes go to X, A, B, C (and must succeed on 3) and re=
ads choose two from A, B, C. After bootstrap, the range is on X, A, B.
> When the bootstrap completes, suppose C1 processes the ownership change a=
t t1 and C2 at t4. Then the following can give an inconsistency:
> t1: C1 switches ownership.
> t2: C1 performs write, so sends write to X, A, B. A is busy and drops the=
 write, but it succeeds because X and B return.
> t3: C2 performs a read. It hasn=E2=80=99t done the switch and chooses A a=
nd C. Neither got the write at t2 so null is returned.
> t4: C2 switches ownership.
> This could be solved by continuing writes to the old replica for some tim=
e (maybe ring delay) after the ownership changes.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)