[
https://issues.apache.org/jira/browse/CASSANDRA-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852103#action_12852103
]
Jonathan Ellis commented on CASSANDRA-930:
------------------------------------------
Turns out (I'd forgotten) we already have
DatabaseDescriptor.getConsistencyCheck to control turning it off entirely.
This is exposed in as config variable DoConsistencyChecksBoolean, but this is
undocumented in our sample config file.
So what we want to do is add a double to CFMetaData recording a chance from 0
to 1 of doing the repair, parse this from the config file, and change the bool
check to a randomized one against this double.
(Remember keyspace <=> table in the source, and you can get the CF from a
ReadCommand via the QueryPath.)
> make RR chance configurable
> ---------------------------
>
> Key: CASSANDRA-930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-930
> Project: Cassandra
> Issue Type: Wish
> Components: Core
> Reporter: Jonathan Ellis
> Priority: Minor
> Fix For: 0.8
>
>
> Read load increases linearly with replication factor. While this can be
> mitigated by simply adding machines, it would also be nice to be able to
> configure on a per-CF basis the chance of performing a read repair, so that
> particularly heavily read CFs could have a chance of (say) 10% and
> seldom-used ones could continue to repair every time, i.e., chance of 100%.
> Thus, the "hot keys get repaired before waiting for anti-entropy to kick in"
> property gets preserved, but you might see a few more reads serving old
> values than before.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
