Advanced8 min
Replica Recovery After Extended Failure
See a broker fall behind while it is offline and catch up before it rejoins the ISR.
A broker that restarts is a follower. It removes any entries that differ from the leader's log (using the leader epoch), fetches the records it missed, and is added back to the ISR only once it has fully caught up. The documentation says a replica must fully re-sync before it rejoins the ISR, even if it lost unflushed data in its crash.
The steps use the simulator and name the control to use. The outcomes they describe are what the simulator models; the sources below are what Apache documents.
Steps
0 of 4 steps completed
Verification
Every ISR is full again and consumers can read up to the final high watermark on every partition.
The interview angle
A restarted replica is not in the ISR until it has caught up. To watch followers catch up on a real cluster, the monitoring page lists the ReplicaFetcherManager MaxLag metric (kafka.server:type=ReplicaFetcherManager,name=MaxLag,clientId=Replica).
Sources
- Design (4.2 documentation) (opens in a new tab)
- Monitoring (4.2 documentation) (opens in a new tab)
- AbstractFetcherThread.scala (4.2 source) (opens in a new tab)
Checked against Kafka 4.2 documentation on 11 October 2026. Draft: not yet reviewed by a Kafka specialist, and releases move on, so confirm against the current documentation before you act on it.