I haven't checked the code to make sure this is still the case but last time I checked: - For any read, if an inconsistency between replicas is detected then this inconsistency will be repaired. This obviously wouldn’t apply with CL=ONE because you’re not reading multiple replicas to find inconsistencies. - If read_repair_chance or dc_local_read_repair_chance are >0 then extra replicas are checked as part of the query for the % of queries specified by the chance setting. Again, if inconsistencies are found, they are repaired. I expect this mechanism would still apply for CL=ONE.
Cheers Ben On Sat, 21 Apr 2018 at 22:20 Grzegorz Pietrusza <gpietru...@gmail.com> wrote: > I haven't asked about "regular" repairs. I just wanted to know how read > repair behaves in my configuration (or is it doing anything at all). > > 2018-04-21 14:04 GMT+02:00 Rahul Singh <rahul.xavier.si...@gmail.com>: > >> Read repairs are one anti-entropy measure. Continuous repairs is another. >> If you do repairs via Reaper or your own method it will resolve your >> discrepencies. >> >> On Apr 21, 2018, 3:16 AM -0400, Grzegorz Pietrusza <gpietru...@gmail.com>, >> wrote: >> >> Hi all >> >> I'm a bit confused with how read repair works in my case, which is: >> - multiple DCs with RF 1 (NetworkTopologyStrategy) >> - reads with consistency ONE >> >> >> The article #1 says that read repair in fact runs RF reads for some >> percent of the requests. Let's say I have read_repair_chance = 0.1. Does >> it mean that 10% of requests will be read in all DCs (digest) and processed >> in a background? >> >> On the other hand article #2 says that for consistency ONE read repair is >> not performed. Does it mean that in my case read repair does not work at >> all? Is there any way to enable read repair across DCs and stay will >> consistency ONE for reads? >> >> >> #1 https://www.datastax.com/dev/blog/common-mistakes-and-misconceptions >> #2 >> https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsRepairNodesReadRepair.html >> >> Regards >> Grzegorz >> >> > -- *Ben Slater* *Chief Product Officer <https://www.instaclustr.com/>* <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr> <https://www.linkedin.com/company/instaclustr> Read our latest technical blog posts here <https://www.instaclustr.com/blog/>. This email has been sent on behalf of Instaclustr Pty. Limited (Australia) and Instaclustr Inc (USA). This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message.