cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Slater <>
Subject Re: read repair with consistency one
Date Sat, 21 Apr 2018 23:45:22 GMT
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.


On Sat, 21 Apr 2018 at 22:20 Grzegorz Pietrusza <>

> 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 <>:
>> 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 <>,
>> 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
>> #2
>> Regards
>> Grzegorz
> --

*Ben Slater*

*Chief Product Officer <>*

<>   <>

Read our latest technical blog posts here

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.

View raw message