>Thanks Zhang. But, this again seems a little strange thing to do, since >one >(say R2) of the 2 close replicas (say R1,R2) might be down, resulting in a >read failure while there are still enough number of replicas (R1 and R3) >live to satisfy a read.
He means in the case where all 3 nodes are liveŠ.if a node is down, naturally it redirects to the other node and still succeeds because it found 2 nodes even with one node down(feel free to test this live though !!!!!) > >Thanks for the example Dean. This definitely clears things up when you >have >an overlap between the read and the write, and one comes after the other. >I'm still missing, how read repairs behave. Just extending your example >for >the following case: > >1. node1 = val1 node2 = val1 node3 = val1 > >2. You do a write operation (W1) with quorom of val=2 >node1 = val1 node2 = val2 node3 = val1 (write val2 is not complete yet) > >3. Now with a read (R1) from node1 and node2, a read repair will be >initiated that needs to write val2 on node 1. >node1 = val1; node2 = val2; node3 = val1 (read repair val2 is not >complete >yet) > >4. Say, in the meanwhile node 1 receives a write val 4; Read repair for R1 >now arrives at node 1 but sees a newer value val4. >node1 = val4; node2 = val2; node3 = val1 (write val4 is not complete, >read >repair val2 not complete) > >In this case, for read R1, the value val2 does not have a quorum. Would >read >R1 return val2 or val4 ? > At this point as Manu suggests, you need to look at the code but most likely what happens is they lock that row, receive the write in memory(ie. Not losing it) and return to client, caching it so as soon as read-repair is over, it will write that next value. Ie. Your client would receive val2 and val4 would be the value in the database right after you received val2. Ie. When a client interacts with cassandra and you have tons of writes to a row, val1, val2, val3, val4 in a short time period, just like a normal database, your client may get one of those 4 values depending on here the read gets inserted in the order of the writesŠsame as a normal RDBMS. The only thing you don't have is the atomic nature with other rows. NOTICE: they would not have to cache val4 very long, and if a newer write came in, they would just replace it with that newer val and cache that one instead so it would not be a queueŠbut this is all just a guessŠread the code if you really want to know. > > >Zhang, Manu wrote >> 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 > > > > > >-- >View this message in context: >http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/What-does >-ReadRepair-exactly-do-tp7583261p7583372.html >Sent from the cassandra-u...@incubator.apache.org mailing list archive at >Nabble.com.
