[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14957077#comment-14957077 ] Aleksey Yeschenko commented on CASSANDRA-9602: -- Committed to 3.0 as [cc2478d4ce5d0cabb150489ebec5cda1442bc174|https://github.com/apache/cassandra/commit/cc2478d4ce5d0cabb150489ebec5cda1442bc174] and merged with trunk, thank you. Added a short NEWS.txt entry on commit. > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Improvement >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.0.0 rc2 > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[
https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14947468#comment-14947468
]
Carl Yeksigian commented on CASSANDRA-9602:
---
The [2.2
docs|http://docs.datastax.com/en/cassandra/2.2/cassandra/dml/dmlConfigConsistency.html?scroll=dmlConfigConsistency__dml-config-read-consistency]
state that {{EACH_QUORUM}} is not supported for reads; the writes section
still references it.
Caching doesn't make sense for dcEndpoints; the endpoints are going to be
different for each token that we get and it has to include only the live
tokens, so there isn't much benefit to caching these values.
For selecting the endpoints, this code follows the same way we do things for
all of our other consistency levels, so that behavior is the same as we'd
expect from, for example, running a {{LOCAL_QUORUM}} in each DC.
I have added a
[dtest|https://github.com/carlyeks/cassandra-dtest/tree/each_quorum_read] to
the consistency_test.py.
> EACH_QUORUM READ support needed
> ---
>
> Key: CASSANDRA-9602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9602
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Scott Guminy
>Assignee: Carl Yeksigian
> Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> EACH_QUORUM consistency for READ should be added.
> This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not
> needed ever, however I have a use case where I need it. I think the decision
> made was incorrect. Here's why...
>
> My application has two key pieces:
>
> # *End user actions* which add/modify data in the system. End users
> typically access the application from only one Data Center and only see their
> own data
> # *Scheduled business logic tasks* which run from any node in any data
> center. These tasks process data added by the end users in an asynchronous
> way
>
> *End user actions must have the highest degree of availability.* Users must
> always be able to add data to the system. The data will be processed later.
> To support this, end user actions will use *LOCAL_QUORUM Read and Write
> Consistency*.
>
> Scheduled tasks don't need to have a high degree of availability but MUST
> operate on the most up to date data. *The tasks will run with EACH_QUORUM*
> to ensure that no matter how many data centers we have, we always READ the
> latest data. This approach allows us some amount of fault tolerance.
>
> The problem is that EACH_QUORUM is not a valid READ consistency level. This
> mean I have no alternative but to use ALL. ALL will work, but is not the
> best since it offers support for ZERO failures. I would prefer EACH_QUORUM
> since it can support some failures in each data center.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945782#comment-14945782 ] Ariel Weisberg commented on CASSANDRA-9602: --- What is the doc impact here? I looked at the [2.2 docs|http://docs.datastax.com/en/cassandra/2.2/cassandra/dml/dmlConfigConsistency.html] and it makes it seem like EACH_QUORUM for reads is already supported, but the code makes it look like it would throw InvalidRequestException? Do we need to have the 2.2 and earlier docs updated? How is this tested? I looked at consistency_test.py test and I don't think it tests combinations with EACH_QUORUM for reads. It looks like ConsistencyLevel is unit testable, but I don't see a test for the existing code. Could you add tests for the code that changed? [Is dcsEndpoints something worth caching in some way?|https://github.com/apache/cassandra/compare/trunk...carlyeks:ticket/9602#diff-6f46fd4f8a36f42512ae5f848aee033eR225] [What is the expected load balancing behavior here?|https://github.com/apache/cassandra/compare/trunk...carlyeks:ticket/9602#diff-6f46fd4f8a36f42512ae5f848aee033eR244] Is it (and should it) hit the same nodes in each DC every time? > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[
https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943818#comment-14943818
]
Daniel Cohen commented on CASSANDRA-9602:
-
[~oseiler]: [~stewartg] and I agree that we all want EACH_QUORUM reads.
I also agree that this was in fact never supported in Cassandra, and at the
very least the C* v2.0 documentation was a little confusing. Check out this
link to the OSS C* code:
https://git1-us-west.apache.org/repos/asf?p=cassandra.git;a=commitdiff;h=72199e23ec9d604449bef87733a32e1da9924437
In particular there is a comment regarding a change as of C* v1.1:
{quote}EACH_QUORUM ConsistencyLevel is only supported for writes and will now
+ throw an InvalidRequestException when used for reads. (Previous
+ versions would silently perform a LOCAL_QUORUM read instead.){quote}
> EACH_QUORUM READ support needed
> ---
>
> Key: CASSANDRA-9602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9602
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Scott Guminy
>Assignee: Carl Yeksigian
> Labels: client-impacting, doc-impacting
> Fix For: 3.x
>
>
> EACH_QUORUM consistency for READ should be added.
> This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not
> needed ever, however I have a use case where I need it. I think the decision
> made was incorrect. Here's why...
>
> My application has two key pieces:
>
> # *End user actions* which add/modify data in the system. End users
> typically access the application from only one Data Center and only see their
> own data
> # *Scheduled business logic tasks* which run from any node in any data
> center. These tasks process data added by the end users in an asynchronous
> way
>
> *End user actions must have the highest degree of availability.* Users must
> always be able to add data to the system. The data will be processed later.
> To support this, end user actions will use *LOCAL_QUORUM Read and Write
> Consistency*.
>
> Scheduled tasks don't need to have a high degree of availability but MUST
> operate on the most up to date data. *The tasks will run with EACH_QUORUM*
> to ensure that no matter how many data centers we have, we always READ the
> latest data. This approach allows us some amount of fault tolerance.
>
> The problem is that EACH_QUORUM is not a valid READ consistency level. This
> mean I have no alternative but to use ALL. ALL will work, but is not the
> best since it offers support for ZERO failures. I would prefer EACH_QUORUM
> since it can support some failures in each data center.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943807#comment-14943807 ] Oliver Seiler commented on CASSANDRA-9602: -- As the author of CASSANDRA-6970, I'm interested in this having a different outcome; I would still like EACH_QUORUM READs, as it would eliminate relying on CL=ALL in some places. I have a similar use-case as the reporter (doing CL=EACH_QUORUM writes is just out of the question for our environments...) > In (certain) versions 2.0 this was supported: It has never been supported, AFAIK; the docs for 2.0 are wrong, something I complained about a lot to whomever could stand my ranting (you get an error in 2.0 trying to run an EACH_QUORUM read). > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942242#comment-14942242 ] Gary Stewart commented on CASSANDRA-9602: - In (certain) versions 2.0 this was supported: http://docs.datastax.com/en/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html In version 2.1 it is now suddenly not supported. http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_config_consistency_c.html This is actually a breaking change in the upgrade path and will hurt clients especially when using it for multi-tenancy solutions. Our use-case is is very heavy writes where latency matters thus we choose CL=LOCAL_QUORUM and seriously few reads where latency does not matter thus we choose to use CL=EACH_QUORUM. This is the minimum to ensure strong consistency which we also need. Now, we are now forced to change to ALL with downgrading consistency. > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942244#comment-14942244 ] Gary Stewart commented on CASSANDRA-9602: - Related to https://issues.apache.org/jira/browse/CASSANDRA-6970 > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662554#comment-14662554 ] Aleksey Yeschenko commented on CASSANDRA-9602: -- This would require a new native protocol version, so probably won't make it to 3.0. EACH_QUORUM READ support needed --- Key: CASSANDRA-9602 URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 Project: Cassandra Issue Type: Improvement Reporter: Scott Guminy Assignee: Carl Yeksigian Labels: client-impacting, doc-impacting Fix For: 3.x EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made was incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14619094#comment-14619094 ] Michael Shuler commented on CASSANDRA-9602: --- The 2.0 branch is in maintenance and the latest released version is 2.0.16. The 2.1 branch, while relatively new, is also in maintenance. The 2.2 branch is up for a first release soon - RC1 has been out for a few weeks - RC2 is up for vote. I suppose it's possible this could go into 2.2, but that would be up to the developers. Basically, new features go into the development branch, trunk, which will become 3.0. This is a new CQL spec feature request, although it may be considered relatively minor. I can guarantee this won't go into a 2.0 release. EACH_QUORUM READ support needed --- Key: CASSANDRA-9602 URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 Project: Cassandra Issue Type: Improvement Reporter: Scott Guminy Assignee: Tyler Hobbs Fix For: 3.x EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made was incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14619137#comment-14619137 ] Scott Guminy commented on CASSANDRA-9602: - Thanks [~mshuler] what's the timeline for 3.0? EACH_QUORUM READ support needed --- Key: CASSANDRA-9602 URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 Project: Cassandra Issue Type: Improvement Reporter: Scott Guminy Assignee: Tyler Hobbs Fix For: 3.x EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made was incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14618947#comment-14618947 ] Scott Guminy commented on CASSANDRA-9602: - Ideally I'd like this in 2.0.15 since I have an immediate need for it there (in the next month). EACH_QUORUM READ support needed --- Key: CASSANDRA-9602 URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 Project: Cassandra Issue Type: Improvement Reporter: Scott Guminy Assignee: Tyler Hobbs Fix For: 3.x EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made was incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14618912#comment-14618912 ] Michael Shuler commented on CASSANDRA-9602: --- [~thobbs] could you discuss this as a possible improvement for READ at EACH_QUORUM? EACH_QUORUM READ support needed --- Key: CASSANDRA-9602 URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 Project: Cassandra Issue Type: Improvement Reporter: Scott Guminy Assignee: Tyler Hobbs Fix For: 3.x EACH_QUORUM consistency for READ should be added. This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not needed ever, however I have a use case where I need it. I think the decision made was incorrect. Here's why... My application has two key pieces: # *End user actions* which add/modify data in the system. End users typically access the application from only one Data Center and only see their own data # *Scheduled business logic tasks* which run from any node in any data center. These tasks process data added by the end users in an asynchronous way *End user actions must have the highest degree of availability.* Users must always be able to add data to the system. The data will be processed later. To support this, end user actions will use *LOCAL_QUORUM Read and Write Consistency*. Scheduled tasks don't need to have a high degree of availability but MUST operate on the most up to date data. *The tasks will run with EACH_QUORUM* to ensure that no matter how many data centers we have, we always READ the latest data. This approach allows us some amount of fault tolerance. The problem is that EACH_QUORUM is not a valid READ consistency level. This mean I have no alternative but to use ALL. ALL will work, but is not the best since it offers support for ZERO failures. I would prefer EACH_QUORUM since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
