[ 
https://issues.apache.org/jira/browse/CASSANDRA-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16219254#comment-16219254
 ] 

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: https://issues.apache.org/jira/browse/CASSANDRA-10726
>             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
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to