Determines the number of replicas on which the write must succeed before returning an acknowledgment to the client application.
Valid Values
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10
Behavior
If set to 0 (any), a write must succeed on at least one node. Even if all replica nodes for the given partition key are down, the write can succeed after a hinted handoff has been written. This setting provides the lowest consistency and highest availability.
If set to 1 (one), a write must succeed on at least one replica node.
If set to 2 (two), a write must succeed on at least two replica nodes.
If set to 3 (three), a write must succeed on at least three replica nodes.
If set to 4 (quorum), a write must succeed on a quorum of replica nodes.
If set to 5 (all), a write must succeed on all replica nodes in the cluster for that partition key. This setting provides the highest consistency and lowest availability.
If set to 6 (local_quorum), a write must succeed on a quorum of replica nodes in the same data center as the coordinator node. This setting avoids latency of inter-data center communication.
If set to 7 (each_quorum), a write must succeed on a quorum of replica nodes across a data center.
(Cassandra 2.x only) If set to 8 (serial), the driver prevents unconditional updates to achieve linearizable consistency for lightweight transactions.
(Cassandra 2.x only) If set to 9 (local_serial), the driver prevents unconditional updates to achieve linearizable consistency for lightweight transactions within the data center.
If set to 10 (local_one), a write must succeed on at least one replica node in the local data center.
Notes
An update operation can result in a consistency level error if the server does not support the WriteConsistency value specified.
Refer to Apache Cassandra documentation for more information about configuring consistency levels, including usage scenarios.
An update operation can result in a consistency level error if the server does not support the WriteConsistency value specified.