Overview
Each leader election in the controller quorum increments the leader epoch, a monotonically increasing number; the monitoring page calls it the quorum epoch. Every quorum request carries an epoch, and a node that receives a request with an older epoch than its own rejects it with FENCED_LEADER_EPOCH, which fences a stale leader (a "zombie") after a re-election. In KRaft, brokers pull metadata from the active controller; the epoch check is how the quorum itself keeps an old leader from acting.
Analogy
Production tip
Check yourself
A quorum node receives a request carrying a leader epoch lower than the latest one it has seen. What does it do?
Sources
- KIP-595: A Raft Protocol for the Metadata Quorum (opens in a new tab)
- KRaft operations (4.2 documentation) (opens in a new tab)
- Monitoring (4.2 documentation) (opens in a new tab)
- Broker configs (4.2 documentation) (opens in a new tab)
- MetadataQuorumCommand.java (4.2 source) (opens in a new tab)
Checked against Kafka 4.2 documentation on Oct 2026. Draft: not yet reviewed by a Kafka specialist. Releases move on, so confirm against the current documentation before you act on a number.