[jira] [Commented] (JAMES-3553) Cassandra: disable read_repair_chance & read_repair_chance

["Benoit Tellier (Jira)" <se...@james.apache.org>]

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

Benoit Tellier commented on JAMES-3553:
---------------------------------------

https://thelastpickle.com/blog/2021/01/12/get_rid_of_repair_repair_chance.html is a nice article of The Last Pickle giving that very advice.

> Cassandra: disable read_repair_chance & read_repair_chance
> ----------------------------------------------------------
>
>                 Key: JAMES-3553
>                 URL: https://issues.apache.org/jira/browse/JAMES-3553
>             Project: James Server
>          Issue Type: Improvement
>          Components: cassandra
>    Affects Versions: 3.6.0
>            Reporter: Benoit Tellier
>            Priority: Major
>
> https://issues.apache.org/jira/browse/CASSANDRA-13910
> # most inconsistencies are actually fixed by hints in practice; and in the case where a node stay dead for a long time so that hints ends up timing-out, you really should repair the node when it comes back (if not simply re-bootstrapping it).  Read-repair probably don't fix _that_ much stuff in the first place.
> # again, read-repair do happen without those options kicking in. If you do reads at {{QUORUM}}, inconsistencies will eventually get read-repaired all the same.  Just a tiny bit less quickly.
> # I suspect almost everyone use a low "chance" for those options at best (because the extra resources consumption is real), so at the end of the day, it's up to chance how much faster this fixes inconsistencies.
> Looking at some production table settings (example):
> {code:java}
> CREATE TABLE ....blobsinbucket (
>     bucket text,
>     id text,
>     position int,
>     PRIMARY KEY ((bucket, id), position)
> ) WITH CLUSTERING ORDER BY (position ASC)
> ...
>     AND dclocal_read_repair_chance = 0.1
> ...
>     AND read_repair_chance = 0.0
>     AND speculative_retry = '99PERCENTILE';
> {code}
> We can see that we still have dclocal_read_repair_chance.
> We should likely disable dclocal_read_repair_chance by default at table creation time...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org