Overview
Under normal conditions each partition has a single leader and zero or more followers. All writes go to the leader. Reads normally go to the leader too, but followers can serve them (replica.selector.class, KIP-392), and followers replicate by fetching from the leader. When a leader fails, the controller elects a new one. If the ISR is not empty it selects one of its members. With Eligible Leader Replicas (ELR, KIP-966, enabled by default on new clusters from Kafka 4.1) it can then select an unfenced ELR member, and otherwise the last known leader if it is unfenced. unclean.leader.election.enable (false by default) allows replicas outside the ISR to be elected as a last resort, even though doing so may result in data loss. Without an eligible replica, the partition stays unavailable until one is back.
Key configuration
unclean.leader.election.enable=false — default; when true, replicas outside the ISR can be elected as a last resort, which may lose data
leader.imbalance.check.interval.seconds=300 — how often the controller runs the partition rebalance checkProduction tip
Check yourself
Which setting allows a replica outside the ISR to be elected leader as a last resort, even though this may lose data?
Sources
- Design (4.2 documentation) (opens in a new tab)
- Eligible Leader Replicas (4.2 documentation) (opens in a new tab)
- KIP-966: Eligible Leader Replicas (opens in a new tab)
- KIP-392: Allow consumers to fetch from closest replica (opens in a new tab)
- Broker configs (4.2 documentation) (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.