You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Mark Guzman (JIRA)" <ji...@apache.org> on 2011/09/10 05:03:10 UTC
[jira] [Created] (CASSANDRA-3172) Add CL.ANY_QUORUM to support
quorum requests with cross datacenter failover
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
Fix For: 1.1
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
[jira] [Commented] (CASSANDRA-3172) Add CL.ANY_QUORUM to support
quorum requests with cross datacenter failover
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102103#comment-13102103 ]
Jonathan Ellis commented on CASSANDRA-3172:
-------------------------------------------
But if you are switching between DCs you're already saying "I don't care very much about consistency after all."
> 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
[jira] [Updated] (CASSANDRA-3172) Add CL.ANY_QUORUM to support
quorum requests with cross datacenter failover
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-3172:
--------------------------------------
Priority: Minor (was: Major)
Fix Version/s: (was: 1.1)
The point of LOCAL_QUORUM is that is gives you read/write consistency within the datacenter. EACH_QUORUM gives you read/write consistency across all DCs (so you can write at EACH_QUORUM and read at LOCAL_QUORUM for instance). I don't see any reason to use ANY_QUORUM over just CL.TWO for instance.
> 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
[jira] [Resolved] (CASSANDRA-3172) Add CL.ANY_QUORUM to support
quorum requests with cross datacenter failover
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CASSANDRA-3172) Add CL.ANY_QUORUM to support
quorum requests with cross datacenter failover
Posted by "Mark Guzman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102068#comment-13102068 ]
Mark Guzman commented on CASSANDRA-3172:
----------------------------------------
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
[jira] [Issue Comment Edited] (CASSANDRA-3172) Add CL.ANY_QUORUM to
support quorum requests with cross datacenter failover
Posted by "Mark Guzman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102162#comment-13102162 ]
Mark Guzman edited comment on CASSANDRA-3172 at 9/10/11 10:15 PM:
------------------------------------------------------------------
The assumption I'm making is that if this occurs then reads most likely will occur from the same dc I've failed over to. Once I get back over to the original dc, the further belief is that the background replication between DCs will have at least propagated the write to some of the nodes. Enough to hopefully provide a consistent view. That's the intent. The details of how I get it to do that is up in the air. I may need to pin myself to the other DC for a period of time, it depends on the details of replication setup like {A:3, B:3, C:3}. My understanding is that the coordinator will contact a single node in the other DCs to replicate the write and that this will succeed over time even if the other DCs can not meet the same consistency requirements at the time of the original write. Is this correct?
was (Author: segy):
The assumption I'm making is that if this occurs then reads most likely will occur from the same dc I've failed over to. Once I get back over to the original dc, the further belief is that the background replication between DCs will have at least propagated the write to some of the nodes. Enough to hopefully provide a consistent view. That's the intent, the details of how I get it to do that is up in the air. I may need to pin myself to the other DC for a period of time, it depends on the details of replication setup like {A:3, B:3, C:3}. My understanding is that the coordinator will contact a single node in the other DCs to replicate the write and that this will succeed over time even if the other DCs can not meet the same consistency requirements at the time of the original write. Is this correct?
> 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
[jira] [Commented] (CASSANDRA-3172) Add CL.ANY_QUORUM to support
quorum requests with cross datacenter failover
Posted by "Mark Guzman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102162#comment-13102162 ]
Mark Guzman commented on CASSANDRA-3172:
----------------------------------------
The assumption I'm making is that if this occurs then reads most likely will occur from the same dc I've failed over to. Once I get back over to the original dc, the further belief is that the background replication between DCs will have at least propagated the write to some of the nodes. Enough to hopefully provide a consistent view. That's the intent, the details of how I get it to do that is up in the air. I may need to pin myself to the other DC for a period of time, it depends on the details of replication setup like {A:3, B:3, C:3}. My understanding is that the coordinator will contact a single node in the other DCs to replicate the write and that this will succeed over time even if the other DCs can not meet the same consistency requirements at the time of the original write. Is this correct?
> 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
[jira] [Issue Comment Edited] (CASSANDRA-3172) Add CL.ANY_QUORUM to
support quorum requests with cross datacenter failover
Posted by "Mark Guzman (JIRA)" <ji...@apache.org>.
[ 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