[
https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102068#comment-13102068
]
Mark Guzman edited comment on CASSANDRA-3172 at 9/10/11 4:01 PM:
-----------------------------------------------------------------
CL.TWO doesn't give you consistency depending on the RF right? This is pushing
an operation I would be doing on the client up to the server. If I receive an
UnavailableException, I would retry with another datacenter. My intent is to
move that logic into the coordinator where we can remove the round trip for the
UnavailableException and make smarter choices about what dc to try next.
Given datacenters A, B and C with A being my local DC. I'd want to write/read
from DC A if possible, if we don't have enough nodes to form a quorum within
that DC I'd want to bounce to the next DC always favoring a quorum based on RF
instead of falling back to CL.TWO or CL.ONE which don't offer similar
consistency behavior.
Versus LOCAL_QUORUM and EACH_QUORUM, local will fail if we can't meet the
quorum requirements in the dc rendering an UnavailableException. Each casts a
wider net and fails if any dc doesn't meet the quorum requirements. So in this
specific case both would fail because the local quorum would be unavailable.
was (Author: segy):
CL.TWO doesn't give you consistency depending on the RF right? This is
pushing an operation I would be doing on the client up to the server. If I
receive an UnavailableException, I would retry with another datacenter. My
intent is to move that logic into the coordinator where we can remove the round
trip for the UnavailableException and make smarter choices about what dc to try
next.
Given datacenters A, B and C with A being my local DC. I'd want to write/read
from DC A if possible, if we don't have enough nodes to form a quorum within
that DC I'd want to bounce to the next DC always favoring a quorum based on RF
instead of falling back to CL.TWO or CL.ONE which don't offer similar
consistency behavior.
> 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
