Hi Tobias READ2 will not be blocked by READ repair of READ1.
Regards Manish On Tue, Aug 11, 2020 at 6:02 PM Tobias Eriksson <tobias.eriks...@qvantel.com> wrote: > Thanx Erick, > > Perhaps this is super obvious but I need a confirmation as you say “…not > subsequent reads for other data unrelated to the read being repaired…” > > But this is subsequent reads to the _*same*_ partition key > > So to be more explicit > > READ 1 with Local Quorum : SELECT * FROM products WHERE id = ABC123 > > READ 2 with Local One : SELECT * FROM products WHERE id = ABC123 > > > > Would read (2) be blocked by the READ REPAIR that was done by read (1) > > As I understand that the read repair is working not on the whole table but > on the partition key it had problems with > > > > -Tobias > > > > > > *From: *Erick Ramirez <erick.rami...@datastax.com> > *Reply to: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Date: *Tuesday, 11 August 2020 at 11:26 > *To: *"user@cassandra.apache.org" <user@cassandra.apache.org> > *Subject: *Re: Why a READ REPAIR ? > > > > If a READ triggers a READ REPAIR, and then if we do an additional READ > would then that BLOCK until the “first” READ REPAIR would be done ? > > -Tobias > > > > Not all read repairs are blocking RRs (aka foreground RRs). There are also > background RRs which by definition are non-blocking because they happen in > the background. > > > > In response to your question, the "additional read" is not blocked. In a > blocking RR, if there is a mismatch in the data returned to the coordinator > from the replicas involved in the query (determined by the read consistency > level) then the coordinator sends a repair to the out-of-sync replica in > the foreground before sending the result back to the client so the read is > blocked until the RR is completed. To reiterate, only the read involved in > the RR is blocked -- not subsequent reads for other data unrelated to the > read being repaired. Cheers! > > >
