[
https://issues.apache.org/jira/browse/CASSANDRA-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17049553#comment-17049553
]
Jeremiah Jordan commented on CASSANDRA-10726:
---------------------------------------------
In 3.11 you should set both read_repair_chance and dc_local_read_repair_chance
to 0 on all your tables.
bq. Our application scale is increasing day by day and replicas are not
up-to-date when required.
Not sure what you expect this change to fix there. If such things are common
on your cluster, then you will want to investigate the performance issues
further and try to resolve them. This change means your application will no
longer be trying to wait for the replicas to be up to date before the read
returns. As per the description of this ticket, this is helpful if some "bad
thing" is happening to make writes fail, and you don't want that to interfere
with reads. So it will help with transient issues. If this is a common issue
in your cluster, then you have some work to do. You might try the #cassandra
slack channel, the users mailing list, or some consulting to help you with the
persistent issue.
> 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: Legacy/Coordination
> Reporter: Richard Low
> Assignee: Blake Eggleston
> Priority: Normal
> Fix For: 4.0
>
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
