cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manu Zhang <>
Subject Re: What does ReadRepair exactly do?
Date Wed, 24 Oct 2012 14:26:23 GMT
And we don't send read request to all of the three replicas (R1, R2, R3) if
CL=QUOROM; just 2 of them depending on proximity

On Wed, Oct 24, 2012 at 10:20 PM, Hiller, Dean <> wrote:

> The user will meet the required consistency unless you encounter some kind
> of bug in cassandra.  You will either get the older value or the newer
> value. If you read quorum, and maybe a write CL=1 just happened, you may
> get the older or new value depending on if the node that received the
> write was involved.  If you read quorum and your wrote CL=QUOROM, then you
> may get the newer value or the older value depending on who gets their
> first so to speak.
> In your scenario, if the read repair read from R2 just before the write is
> applied, you get the old value.  If it read from R2 just after the write
> was applied, it gets the new value.  BOTH of these met the consistency
> constraint.  A better example to clear this up may be the following...  If
> you read a value at CL=QUOROM, and you have a write 20ms later, you get
> the old value, right?  And it met the consistency level, right?  NOW, what
> about if the write is 1ms later?  What if it the right is .00001ms later?
> It still met the consistency level, right?  If it is .00001ms before, you
> get the new value as it repairs first with the new node.
> It is just when programming, your read may get the newer value or older
> value and generally if you write the code in a way that works, this
> concept works out great in most cases(in some cases, you need to think a
> bit differently and solve it other ways).
> I hope that clears it up
> Later,
> Dean
> On 10/24/12 8:02 AM, "shankarpnsn" <> wrote:
> >Hiller, Dean wrote
> >> in general it is okay to get the older or newer value.  If you are
> >>reading
> >> 2 rows however instead of one, that may change.
> >
> >This is certainly interesting, as it could mean that the user could see a
> >value that never met the required consistency. For instance with 3
> >replicas
> ><R1,R2,R3> and a quorum consistency, assume that R1 is initiating a read
> >(becomes the coordinator) - notices a conflict with R2 (assume R1 has a
> >more
> >recent value) and initiates a read repair with its value. Meanwhile R2 and
> >R3 have seen two different writes with newer values than what was computed
> >by the read repair. If R1 were to respond back to the user with the value
> >that was computed at the time of read repair, wouldn't it be a value that
> >never met the consistency constraint? I was thinking if this should
> >trigger
> >another round of repair that tries to reach the consistency constraint
> >with
> >a newer value or time-out, which is the expected case when you don't meet
> >the required consistency. Please let me know if I'm missing something
> >here.
> >
> >
> >
> >--
> >View this message in context:
> >
> >-ReadRepair-exactly-do-tp7583261p7583366.html
> >Sent from the mailing list archive at
> >

View raw message