Benoit Tellier created JAMES-3553:
-------------------------------------

             Summary: 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


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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to