cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Schuller (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-2338) C* needs a LOCAL_QUORUM_PLUS_ONE_REMOTE consistency level
Date Wed, 16 Mar 2011 08:25:29 GMT


Peter Schuller commented on CASSANDRA-2338:

I think this highlights even better than CASSANDRA-2013 that there is at least interest (if
not need) to be able to specify with finer granularity what your requirements are. One can
probably come up with a list of 15 cases and suddenly ConsistencyLevel is a huge beast. A
few seemingly reasonable/realistic situations I can think of:

* Your situation, except there are 3 DC:s, 2 of which are production and one analysis. Now
* You may want the reverse of requiring additional replicas; e.g., "reads shall never try
to go beyond the local DC; I prefer failures/timeouts)"
* Maybe you one one replicate per DC, but no QUOROM in each.

It would be a bigger API change, and a more invasive code change. The simplest way to do this
I can think of, is to allow the passing of a "ReplicaSelectionPolicy" (for lack of a better
word right now) which allows you to specify, globally and on a per-dc level (assuming dc:s
are named):

(1) How many replicates are *allowed* to be consulted.
(2) How many replicas are *required* to be consulted.

(1) would be of interest for reads, and (2) for both reads and writes.

Is this complete overkill?

> C* needs a LOCAL_QUORUM_PLUS_ONE_REMOTE consistency level
> ---------------------------------------------------------
>                 Key: CASSANDRA-2338
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Matthew F. Dennis
>            Priority: Minor
> for cases where people want to run C* across multiple DCs for disaster recovery et cetera
where normal operations only happen in the first DC (e.g. no writes/reads happen in the remove
DC under normal operation) neither LOCAL_QUORUM or EACH_QUORUM really suffices.  
> Consider the case with RF of DC1:3 DC2:2
> LOCAL_QUORUM doesn't provide any guarantee that data is in the remote DC.
> EACH_QUORUM requires that both nodes in the remote DC are up.
> It would be useful in some situations to be able to specify a LOCAL_QUORUM (for local
consistency) + "at least one remote" for durability/disaster proofing.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message