Cassandra LOCAL_QUORUM
Solution 1
The write will be successful after the coordinator received acknowledgement from 2 nodes from the same DC of the coordinator.
Using LOCAL_QUORUM for both reads and write will get you strong consistency, provided the same DC will be used for both reads and write, and just for this DC.
Solution 2
The previous answer is correct: "The write will be successful after the coordinator received acknowledgement from 2 nodes from the same DC of the coordinator." It is the same for reads.
The Quorum is always calculated by N/2+1 (N being the replication factor), having a local_quorum avoids the latency of the other data center.
As far as I understand, with a RF of 2 and LOCAL_QUORUM you have better local consistency but no availability in case of partition: if one single node drops, all writes and reads will fail for the range tokens of that node and its replica.
Therefore I recommend a RF of 3 if you intend to use Quorum. For 2 replica you should better use ONE.
Comments
-
JDesuv about 2 years
I'm having trouble understanding / finding information about how various quorums are calculated in cassandra.
Let's say I have a 16 node cluster using Network Topology Strategy across 2 data centers. The replication factor is 2 in each datacenter (DC1: 2, DC2: 2).
In this example, if I write using a LOCAL_QUORUM, I will write the data to 4 nodes (2 in each data center) but when will the acknowledgement happen? After 2 nodes in 1 data center are written?
In addition, to maintain strong read consistency, I need Write nodes + read nodes > replication factor. In the above example, if both reads and writes were LOCAL_QUORUM, I would have 2 + 2 which would not guarantee strong read consistency. Am I understanding this correctly? What level would I need then to ensure strong read consistency?
The goal here is to ensure that if a data center fails, reads/writes can continue while minimizing latency.
-
JDesuv almost 9 yearsHow would I change this to be able to read from both data centers and maintain strong consistency?
-
Stefan Podkowinski almost 9 yearsUse EACH_QUORUM instead.
-
Jeff Jirsa almost 9 yearsUse EACH_QUORUM on write, there is no EACH_QUORUM on read, as LOCAL_QUORUM on read is sufficient. Alternatively, in your environment, writing and reading with QUORUM does approximately the same thing, but will tolerate a single node failure (with RF=2 in each DC, if any replica is down, then you can't meet the quorum for that DC - however, cluster wide quorum is any 3 of the 4 replicas, probably does what you need).
-
Loic almost 9 yearsMore: People often confuse hints implication with CL and availability. example: 2 nodes alive on 3, the node down is serving tokens for 1/2 of the data (because RF of 2), so half of write queries and read queries would fail with consistency QUORUM. If you want a RF of 2 and extreme availability you should change the CL to ONE or ANY so your queries will succeed. Alternatively you may change your RF to 3 to solve the quorum issue. Cf. datastax.com/dev/blog/modern-hinted-handoff and official documentation: docs.datastax.com/en/cassandra/2.0/cassandra/dml/….