cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10726) Read repair inserts should not be blocking
Date Wed, 25 Oct 2017 18:32:00 GMT


Aleksey Yeschenko commented on CASSANDRA-10726:

I've been thinking more about this, in particular in context of deprecating/removing {{read_repair_chance}}
and {{dclocal_read_repair_chance}} options. The question I asked myself was: what kind of
tuning do we want for read repair, once those two are gone?

And I'm leaning towards these three settings:
1. Perform blocking RR (current default, left default)
2. Write hints instead of sending RR mutations, and let hint delivery repair the inconsistency,
in a manner decoupled from the original read request
3. Do nothing, for those who rely on regular repair for one reason or another (thinking TWCS,
DTCS users?)

Any opinions?

> Read repair inserts should not be blocking
> ------------------------------------------
>                 Key: CASSANDRA-10726
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Coordination
>            Reporter: Richard Low
>            Assignee: Xiaolong Jiang
>             Fix For: 4.x
> Today, if there’s a digest mismatch in a foreground read repair, the insert to update
out of date replicas is blocking. This means, if it fails, the read fails with a timeout.
If a node is dropping writes (maybe it is overloaded or the mutation stage is backed up for
some other reason), all reads to a replica set could fail. Further, replicas dropping writes
get more out of sync so will require more read repair.
> The comment on the code for why the writes are blocking is:
> {code}
> // wait for the repair writes to be acknowledged, to minimize impact on any replica that's
> // behind on writes in case the out-of-sync row is read multiple times in quick succession
> {code}
> but the bad side effect is that reads timeout. Either the writes should not be blocking
or we should return success for the read even if the write times out.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message