How is the consistency level configured?
Consistency levels in Cassandra can be configured to manage availability versus data accuracy.
Consistency levels in Cassandra can be configured to manage availability versus data accuracy. Configure consistency for a session or per individual read or write operation. Withincqlsh, useCONSISTENCY, to set the consistency level for all queries in the currentcqlsh session. For programming client applications, set the consistency level using an appropriate driver. For example, using the Java driver, callQueryBuilder.insertInto withsetConsistencyLevel to set a per-insert consistency level.
The consistency level defaults toONE for all write and read operations.
Write consistency levels
This table describes the write consistency levels in strongest-to-weakest order.
| Level | Description | Usage |
|---|---|---|
ALL | A write must be written to the commit log and memtable on all replica nodes in the cluster for that partition. | Provides the highest consistency and the lowest availability of any other level. |
EACH_QUORUM | Strong consistency. A write must be written to thecommit log and memtable on a quorum of replica nodes ineachdatacenter. | Used in multiple datacenter clusters to strictly maintain consistency at the same level in each datacenter. For example, choose this level if you want a write to fail when a datacenter is down and theQUORUM cannot be reached on that datacenter. |
QUORUM | A write must be written to thecommit log and memtable on a quorum of replica nodes acrossall datacenters. | Used in either single or multiple datacenter clusters to maintain strong consistency across the cluster. Use if you can tolerate some level of failure. |
LOCAL_QUORUM | Strong consistency. A write must be written to thecommit log and memtable on a quorum of replica nodes in the same datacenter as thecoordinator. Avoids latency of inter-datacenter communication. | Used in multiple datacenter clusters with a rack-aware replica placement strategy, such asNetworkTopologyStrategy, and a properly configured snitch. Use to maintain consistency locally (within the single datacenter). Can be used with SimpleStrategy. |
ONE | A write must be written to thecommit log and memtable of at least one replica node. | Satisfies the needs of most users because consistency requirements are not stringent. |
TWO | A write must be written to thecommit log and memtable of at least two replica nodes. | Similar toONE. |
THREE | A write must be written to thecommit log and memtable of at least three replica nodes. | Similar toTWO. |
LOCAL_ONE | A write must be sent to, and successfully acknowledged by, at least one replica node in the local datacenter. | In a multiple datacenter clusters, a consistency level ofONE is often desirable, but cross-DC traffic is not.LOCAL_ONE accomplishes this. For security and quality reasons, you can use this consistency level in an offline datacenter to prevent automatic connection to online nodes in other datacenters if an offline node goes down. |
ANY | A write must be written to at least one node. If all replica nodes for the given partition key are down, the write can still succeed after ahinted handoff has been written. If all replica nodes are down at write time, anANY write is not readable until the replica nodes for that partition have recovered. | Provides low latency and a guarantee that a write never fails. Delivers the lowest consistency and highest availability. |
Read consistency levels
This table describes read consistency levels in strongest-to-weakest order.
| Level | Description | Usage |
|---|---|---|
ALL | Returns the record after all replicas have responded. The read operation will fail if a replica does not respond. | Provides the highest consistency of all levels and the lowest availability of all levels. |
EACH_QUORUM | Not supported for reads. | |
QUORUM | Returns the record after a quorum of replicas from alldatacenters has responded. | Used in either single or multiple datacenter clusters to maintain strong consistency across the cluster. Ensures strong consistency if you can tolerate some level of failure. |
LOCAL_QUORUM | Returns the record after a quorum of replicas in the current datacenter as thecoordinator has reported. Avoids latency of inter-datacenter communication. | Used in multiple datacenter clusters with a rack-aware replica placement strategy (NetworkTopologyStrategy) and a properly configured snitch. Fails when usingSimpleStrategy. |
ONE | Returns a response from the closest replica, as determined by thesnitch. By default, aread repair runs in the background to make the other replicas consistent. | Provides the highest availability of all the levels if you can tolerate a comparatively high probability of stale data being read. The replicas contacted for reads may not always have the most recent write. |
TWO | Returns the most recent data from two of the closest replicas. | Similar toONE. |
THREE | Returns the most recent data from three of the closest replicas. | Similar toTWO. |
LOCAL_ONE | Returns a response from the closest replica in the local datacenter. | Same usage as described in the table about write consistency levels. |
SERIAL | Allows reading the current (and possiblyuncommitted) state of data without proposing a new addition or update. If aSERIAL read finds an uncommitted transaction in progress, it will commit the transaction as part of the read. Similar to QUORUM. | To read the latest value of a column after a user has invoked alightweight transaction to write to the column, useSERIAL. Cassandra then checks the inflight lightweight transaction for updates and, if found, returns the latest data. |
LOCAL_SERIAL | Same asSERIAL, but confined to the datacenter. Similar to LOCAL_QUORUM. | Used to achievelinearizable consistency for lightweight transactions. |
How QUORUM is calculated
TheQUORUM level writes to the number of nodes that make up a quorum. A quorum is calculated, and then rounded down to a whole number, as follows:
quorum = (sum_of_replication_factors / 2) + 1The sum of all thereplication_factor settings for each datacenter is thesum_of_replication_factors.
sum_of_replication_factors = datacenter1_RF + datacenter2_RF + . . . + datacentern_RF- Using a replication factor of 3, a quorum is 2 nodes. The cluster can tolerate 1 replica down.
- Using a replication factor of 6, a quorum is 4. The cluster can tolerate 2 replicas down.
- In a two datacenter cluster where each datacenter has a replication factor of 3, a quorum is 4 nodes. The cluster can tolerate 2 replica nodes down.
- In a five datacenter cluster where two datacenters have a replication factor of 3 and three datacenters have a replication factor of 2, a quorum is 7 nodes.
The more datacenters, the higher number of replica nodes need to respond for a successful operation.
Similar toQUORUM, theLOCAL_QUORUM level is calculated based on the replication factor of the same datacenter as the coordinator node. That is, even if the cluster has more than one datacenter, the quorum is calculated only with local replica nodes.
InEACH_QUORUM, every datacenter in the cluster must reach a quorum based on that datacenter's replication factor in order for the write request to succeed. That is, for every datacenter in the cluster a quorum of replica nodes must respond to the coordinator node in order for the write request to succeed.
Configuring client consistency levels
You can use acqlsh command,CONSISTENCY, to set the consistency level for queries in the currentcqlsh session. For programming client applications, set the consistency level using an appropriate driver. For example, callQueryBuilder.insertInto with asetConsistencyLevel argument using the Java driver.