liveBook · Manning

Consistency level

As explained in ScyllaDB in Action

A selectable database setting that determines how many replicas or nodes must participate in an operation and what consistency it provides.

A consistency level is a per-query setting that decides how many nodes or replicas must respond before a ScyllaDB read or write succeeds. It lets an application trade availability against the chance of reading data that has not yet reached every replica. ONE needs one replica; ALL needs every replica; QUORUM needs a majority. Using the same quorum level for reads and writes prevents stale reads while still tolerating a node loss in a three-replica cluster. section 1.2.1 section 8.2.2

Choose a level according to the operation’s correctness and failure-tolerance needs:

  • Use ONE, or LOCAL_ONE, when keeping requests available matters more than always seeing the newest value. A responding replica can be behind a prior write. section 8.2.2
  • Use QUORUM or LOCAL_QUORUM when reads and writes need a majority of replicas. This provides a practical middle ground between correctness and availability. section 1.2.1 section 10.5.1
  • Use ALL only when every replica must respond; any unavailable replica makes the query fail. section 1.2.1
  • Use SERIAL when a read must obtain the latest value with ordered, linearizable behavior. ScyllaDB uses Paxos for this level. section 8.2.2
  • Use ANY only for writes that may be accepted through hinted handoff when replicas are unavailable. section 8.2.2

Testing a failed node

With three nodes and one stopped, a restaurant-review query succeeds at ONE because one healthy node can answer. It fails at ALL because every node is required. At QUORUM, it succeeds because two healthy nodes form a majority. Try this in cqlsh with `CONSISTENCY;`, then set `CONSISTENCY all;` or `CONSISTENCY quorum;` before running a SELECT. section 2.4.2

Set consistency in application code rather than treating it as a cluster-wide default. In the Python driver, assign `consistency_level` to a prepared statement to apply one choice to every execution, or bind it first and override the level for a particular request. LOCAL_QUORUM is a useful default when an application needs majority agreement within its datacenter. section 10.5 section 10.5.1

Table 8.1 Scylla supports many consistency-level choices for your queries to balance consistency and availability.
Consistency level
Required nodes to respond
ANY
Any node in the cluster can respond, even if it’s not a replica
ONE
A single replica
LOCAL_ONE
A single replica in the same datacenter
TWO
Two replicas
THREE
Three replicas
QUORUM
A majority of replicas
LOCAL_QUORUM
A majority of replicas in the same datacenter
EACH_QUORUM
A majority of replicas in every datacenter
SERIAL (used to get the latest data via Paxos)
A majority of replicas
LOCAL_SERIAL
A majority of replicas in the same datacenter
ALL
Every replica in the cluster

Compare the available levels by required responders, including local and multidatacenter quorum variants. section 8.2.2

How ScyllaDB in Action covers it

How deep it goes
Explains replica acknowledgments, quorum behavior, stale reads, SERIAL ordering, and driver-level configuration.
Examples
Demonstrates restaurant-review reads in cqlsh with a stopped node and Python prepared-statement overrides.
What you can do after
Operate/configure query consistency in cqlsh and Python driver statements for required correctness and fault tolerance.
How it connects
Connects replication factor, eventual consistency, quorum, CAP theorem, Paxos, hinted handoff, prepared statements, and bound statements.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of ScyllaDB in Action. The section links point to the parts of the book it draws on.