[
https://issues.apache.org/jira/browse/CASSANDRA-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975473#action_12975473
]
Daniel Doubleday commented on CASSANDRA-982:
--------------------------------------------
{quote}we should respect DatabaseDescriptor.getConsistencyCheck and check the
other replicas asynchronously if it is enabled.{quote}
Ok - shame only that it is not possible to mix CL.ONE and CL.QUORUM access
then. You have to choose between:
- Consistent quorum read with full node access and eventual consistent reads
with RR, or
- Consistent quorum read with optimized access and CL.ONE reads that are
inconsistent until node repair
(We are using 2 keyspaces with RF = 3 and QUORUM and RF=2 and ONE and since
consistency check config is not per keyspace that wouldn't work anymore.)
One question though: How will that translate to 0.7? I understand that strong
reads don't look at RR probability at all?
> read repair on quorum consistencylevel
> --------------------------------------
>
> Key: CASSANDRA-982
> URL: https://issues.apache.org/jira/browse/CASSANDRA-982
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments:
> 0001-better-digest-checking-for-ReadResponseResolver.patch,
> 0002-quorum-only-read.txt, 982-resolve-digests-v2.txt
>
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> CASSANDRA-930 made read repair "fuzzy optional," but this only helps with
> ConsistencyLevel.ONE:
> - Quorum reads always send requests to all nodes
> - only the first Quorum's worth of responses get compared
> So what we'd like to do two changes:
> - only send read requests to the closest R live nodes
> - if read repair is enabled, also compare results from the other nodes in the
> background
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
