You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2010/12/04 00:22:10 UTC
[jira] Created: (CASSANDRA-1817) Dynamic Read Repair
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.
[jira] [Updated] (CASSANDRA-1817) Dynamic Read Repair
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1817:
--------------------------------------
Priority: Minor (was: Major)
Labels: ponies (was: )
> 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
> Priority: Minor
> Labels: ponies
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1817) Dynamic Read Repair
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974542#action_12974542 ]
Jonathan Ellis commented on CASSANDRA-1817:
-------------------------------------------
This could have a large impact on performance, though, and for a non-random workload you'd still be repairing the hot rows over and over.
I kind of think that for workloads where RR < 1.0 makes sense, it makes sense even when actual repairs are happening.
> 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.
[jira] Commented: (CASSANDRA-1817) Dynamic Read Repair
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ 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.