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" <shankarp...@gmail.com> 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: >http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/What-does >-ReadRepair-exactly-do-tp7583261p7583366.html >Sent from the cassandra-u...@incubator.apache.org mailing list archive at >Nabble.com.
