You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeremiah Jordan (JIRA)" <ji...@apache.org> on 2017/11/01 13:25:00 UTC
[jira] [Commented] (CASSANDRA-10726) Read repair inserts should not
be blocking
[ https://issues.apache.org/jira/browse/CASSANDRA-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16234058#comment-16234058 ]
Jeremiah Jordan commented on CASSANDRA-10726:
---------------------------------------------
{quote}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?){quote}
I think the current default needs to stay the default (I was bitten by the original problem more than once in the 0.6/0.7 days), but giving advanced users the ability to disable that seems fine to me. +1 to those options.
> 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
> Priority: Major
> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org