[
https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3172.
---------------------------------------
Resolution: Won't Fix
ANY_QUORUM is far from likely to be (entirely) consistent since as soon as
enough local nodes recover, reads will prefer that instead.
More fundamentally, you're overcomplicating things. If you're okay with reads
occasionally not being 100% (locally) consistent, then use CL.ONE (or TWO if
you want to guarantee redundancy on writes). If you're not, then stick with
LOCAL_QUORUM.
> Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
> ---------------------------------------------------------------------------
>
> Key: CASSANDRA-3172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3172
> Project: Cassandra
> Issue Type: Improvement
> Components: API, Core
> Reporter: Mark Guzman
> Priority: Minor
>
> Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would
> operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the
> coordinator would use its knowledge to select the "fastest/closest" node in
> another datacenter to attempt another LOCAL_QUORUM in. This would allow for
> simple reliable cross datacenter failover without putting the intelligence in
> the client. The client is intrinsically at a disadvantage since it doesn't
> have a current full picture of the rings.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
