[ 
https://issues.apache.org/jira/browse/CASSANDRA-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035453#comment-16035453
 ] 

Jay Zhuang commented on CASSANDRA-8119:
---------------------------------------

Basically to make sure the system could tolerate any one DC down.

For example, we have a cluster in 3 DCs (AZs in AWS), RF=3 in each DC (9 copies 
in total). The requirement is to make sure the system working fine and no data 
loss when one DC down.
{{local_quorum}} cannot guarantee no data loss if one DC down. {{each_quorum}} 
will cause requests fail after losing one DC. {{quorum}} is what we use right 
now, which requires 5 nodes alive and acknowledging the request. vs. 
{{quorum_quorum}} will only need 4.
And for {{quorum_one}}, there's no easy workaround but to reduce RF to 1 in 
each DC and use quorum. Which might be fine actually, if CL is one then RF=3 
might not be necessary.

[~rbfblk] we're very interested in this feature, please let me know if I could 
help. Or I could implement a {{quorum_quorum}} CL, it would be much easier to 
do.




> More Expressive Consistency Levels
> ----------------------------------
>
>                 Key: CASSANDRA-8119
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8119
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: CQL
>            Reporter: Tyler Hobbs
>             Fix For: 4.x
>
>
> For some multi-datacenter environments, the current set of consistency levels 
> are too restrictive.  For example, the following consistency requirements 
> cannot be expressed:
> * LOCAL_QUORUM in two specific DCs
> * LOCAL_QUORUM in the local DC plus LOCAL_QUORUM in at least one other DC
> * LOCAL_QUORUM in the local DC plus N remote replicas in any DC
> I propose that we add a new consistency level: CUSTOM.  In the v4 (or v5) 
> protocol, this would be accompanied by an additional map argument.  A map of 
> {DC: CL} or a map of {DC: int} is sufficient to cover the first example.  If 
> we accept a special keys to represent "any datacenter", the second case can 
> be handled.  A similar technique could be used for "any other nodes".
> I'm not in love with the special keys, so if anybody has ideas for something 
> more elegant, feel free to propose them.  The main idea is that we want to be 
> flexible enough to cover any reasonable consistency or durability 
> requirements.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to