apache/cassandra · error · UnavailableException

Cannot achieve consistency level {consistencyForConsensus} {

Error message

Cannot achieve consistency level {consistencyForConsensus} {sizeOfConsensusQuorum} > {sizeOfPoll()}

What it means

Before running a Paxos round, Cassandra checks that the number of live replicas able to participate in the poll is at least the required consensus quorum for the requested consistency level (SERIAL/QUORUM-equivalent). If the required quorum exceeds the live poll participants, it throws UnavailableException with this message.

Source

Thrown at src/java/org/apache/cassandra/service/paxos/Paxos.java:507

            return get(cfm, key.getToken(), consistency);
        }

        int sizeOfPoll()
        {
            return electorateLive.size();
        }

        InetAddressAndPort voter(int i)
        {
            return electorateLive.endpoint(i);
        }

        void assureSufficientLiveNodes(boolean isWrite) throws UnavailableException
        {
            if (sizeOfConsensusQuorum > sizeOfPoll())
            {
                mark(isWrite, m -> m.unavailables, consistencyForConsensus);
                throw new UnavailableException("Cannot achieve consistency level " + consistencyForConsensus + " " + sizeOfConsensusQuorum + " > " + sizeOfPoll(), consistencyForConsensus, sizeOfConsensusQuorum, sizeOfPoll());
            }
        }

        void assureSufficientLiveNodesForRepair() throws UnavailableException
        {
            if (sizeOfConsensusQuorum > sizeOfPoll())
            {
                throw UnavailableException.create(consistencyForConsensus, sizeOfConsensusQuorum, sizeOfPoll());
            }
        }

        int requiredFor(ConsistencyLevel consistency)
        {
            if (consistency == Paxos.nonSerial(consistencyForConsensus))
                return sizeOfConsensusQuorum;

            return consistency.blockForWrite(replicationStrategy(), pending);
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Restore availability: bring the down replicas back up or fix network connectivity (nodetool status)
  2. Temporarily reduce the consistency level of the LWT if the application tolerates it (e.g. LOCAL_SERIAL in the correct DC)
  3. Increase replication factor if quorum requirements are routinely too strict for the cluster size
  4. Retry after repair/restart completes; use LOCAL_SERIAL within a healthy DC rather than cross-DC SERIAL

Example fix

// before
stmt.setConsistencyLevel(ConsistencyLevel.SERIAL);
// after (single-DC app)
stmt.setConsistencyLevel(ConsistencyLevel.LOCAL_SERIAL);
Defensive patterns

Strategy: retry

Validate before calling

// check replica health before issuing serial ops
boolean healthy = session.execute("SELECT * FROM system.local").one() != null;
// and run nodetool status externally; require all RF replicas UP for SERIAL keys

Try / catch

try { session.execute(lwtWithSerial); }
catch (UnavailableException e) { /* replicas down: backoff, alert, or downgrade to LOCAL_SERIAL */ }

Prevention

When it happens

Trigger: A serial/consensus read or write (LWT or transactional query with SERIAL/LOCAL_SERIAL consistency) attempted while too many replicas of the partition are down/unreachable, so sizeOfPoll() < sizeOfConsensusQuorum for the chosen consistency level.

Common situations: Node(s) in the replica set down or being restarted during rolling maintenance; network partitions isolating replicas; RF too low for the requested consistency (e.g. RF=2 with QUORUM needing 2 and one node down); degraded datacenter in a multi-DC setup using SERIAL.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/0e6adb71bd292b36. Report an issue: GitHub.