[
https://issues.apache.org/jira/browse/CASSANDRA-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974559#action_12974559
]
Stu Hood commented on CASSANDRA-1817:
-------------------------------------
> This could have a large impact on performance,
The level of dynamic read repair would actually make a really good metric for
inconsistency, so exposing it properly would be a requirement for this issue to
be a success. We wouldn't want to be varying the read repair chance inside of a
black box: the fact that it was happening more frequently would be an important
thing for the operator to know, since it might indicate problems with the
cluster and affect performance.
> I kind of think that for workloads where RR < 1.0 makes sense, it makes sense
> even when actual repairs are happening.
Then I would propose that 1) our current RR configurable become the cap for the
dynamic algorithm, 2) we add a hardcoded minimum chance of 1-5%, 3) we enable
dynamic read repair by default.
> Dynamic Read Repair
> -------------------
>
> Key: CASSANDRA-1817
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1817
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Fix For: 0.7.1
>
>
> Read repair could (temporarily) adjust its own frequency (from the baseline)
> based on the necessity of the repair for particular nodes. For example, a
> successful read repair (caused data to be repaired) should bump the frequency
> for the node that needed repair, with the goal that a node that has been
> offline for a while should trend toward 100% read repair while it is
> successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
