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!
