cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3901) write endpoints are not treated correctly, breaking consistency guarantees
Date Thu, 27 Sep 2012 04:49:09 GMT


Jonathan Ellis commented on CASSANDRA-3901:

bq. The main issue is that when streaming, you have to be streaming from the node that you're
replacing for a particular range

Right, that part IS CASSANDRA-2434.  Here's my very first comment over there:

bq. ISTM the easiest fix is to always stream from the node that will be removed from the replicas
for each range, unless given permission from the operator to choose a replica that is closer
/ less dead.
> write endpoints are not treated correctly, breaking consistency guarantees
> --------------------------------------------------------------------------
>                 Key: CASSANDRA-3901
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Peter Schuller
>            Assignee: Peter Schuller
> I had a nagging feeling this was the case ever since I started wanting CASSANDRA-3833
and thinking about hot to handle the association between nodes in the read set and nodes in
the write set.
> I may be wrong (please point me in the direct direction if so), but I see no code anywhere
that tries to (1) apply consistency level to currently normal endpoints only, and (2) "connect"
a given read endpoint with a future write endpoint such that they are tied together for consistency
purposes (parts of these concerns probably is covered by CASSANDRA-2434 but that ticket is
more general).
> To be more clear about the problem: Suppose we have a ring of nodes, with a single node
bootstrapping. Now, for a given row key suppose reads are served by A, B and C while writes
are to go to A, B, C and D. In other words, D is the node bootstrapping. Suppose RF is 3 and
A,B,C,D is ring order. There are a few things required for correct behavior:
> * Writes acked by D must never be treated as sufficient to satisfy consistency level
since until it is part of the read set it does not count towards CL on reads.
> * Writes acked by B must *not* be treated as sufficient to satisfy consistency level
*unless* the same write is *also* acked by D, because once D enters the ring, B will no longer
be counting towards CL on reads. The only alternative is to make the read succeed and disallow
D from entering the ring.
> We don't seem to be handling this at all (and it becomes more complicated with arbitrary

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message