cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Zhuang (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8119) More Expressive Consistency Levels
Date Fri, 02 Jun 2017 21:28:04 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message