liveBook · Manning

Quorum loss

As explained in ScyllaDB in Action

Quorum loss is a condition in which an operation cannot obtain the required responses from enough replicas to satisfy its consistency requirement.

Quorum loss occurs when enough replicas are unavailable that ScyllaDB cannot satisfy a requested consistency level. A sizable share of requests may then fail until quorum is restored. section 11.3.3 section 11.4

Reduce the chance of quorum loss during cluster operations:

  • Automate procedures so safety checks replace manual decisions. section 11.3.3 section 11.4
  • Take one node offline at a time; removing more nodes increases the risk. section 11.3.3
  • Validate each node’s health before continuing with a cluster-wide operation. section 11.3.3

Restoring service

If infrastructure failure takes enough nodes offline, restore those nodes or otherwise bring the cluster back to quorum. Requests can then succeed at their desired consistency level again. If unsafe maintenance caused the outage, improve automation and perform subsequent changes sequentially. section 11.3.3 section 11.4

How ScyllaDB in Action covers it

How deep it goes
Defines the failure condition and gives recovery and prevention procedures without detailing quorum mathematics.
Examples
Uses nodes taken offline, infrastructure failures, sequential maintenance, health validation, and restoring quorum as operational examples.
What it assumes
Assumes familiarity with ScyllaDB nodes and consistency levels while explaining the operational consequence of unavailable replicas.
What you can do after
Operate/configure ScyllaDB more safely by restoring unavailable nodes and sequencing maintenance with health checks.
How it connects
Connects tunable consistency levels, replicas, cluster topology, monitoring, automation, and infrastructure failures.

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.