Scenario 03.1.2 · min.ISR boundary
min.insync.replicas with acks=all: when Kafka refuses writes
acks=all commits at ISR == min.insync.replicas, then fails one replica below.
Run this scenario in the playgroundCluster ready - RF=3, min.ISR=2. t+0.000s
Open at this step: step 1, Cluster ready - RF=3, min.ISR=2O1 committed with full ISR (3). t+3.050s
Open at this step: step 2, O1 committed with full ISR (3)broker-3 down - ISR shrinks to 2. t+6.050s
ISR is now exactly min.insync.replicas.
Open at this step: step 3, broker-3 down - ISR shrinks to 2O2 still commits at the boundary (ISR == 2). t+8.200s
Open at this step: step 4, O2 still commits at the boundary (ISR == 2)broker-2 down - ISR shrinks to 1. t+11.050s
ISR is now below min.insync.replicas.
Open at this step: step 5, broker-2 down - ISR shrinks to 1O3 blocked - NotEnoughReplicas. t+13.200s
acks=all needs 2 in-sync replicas; only 1 remains.
Open at this step: step 6, O3 blocked - NotEnoughReplicasWhat you start with
With acks=all, a write only commits when at least min.insync.replicas copies are in-sync. Starting from a 3-replica partition with min.ISR=2, brokers are failed one at a time so the ISR crosses that boundary while a producer keeps writing.
Step by step
- Cluster ready - RF=3, min.ISR=2 t+0.000s Open at this step: step 1, Cluster ready - RF=3, min.ISR=2
- O1 committed with full ISR (3) t+3.050s Open at this step: step 2, O1 committed with full ISR (3)
- broker-3 down - ISR shrinks to 2 t+6.050s ISR is now exactly min.insync.replicas. Open at this step: step 3, broker-3 down - ISR shrinks to 2
- O2 still commits at the boundary (ISR == 2) t+8.200s Open at this step: step 4, O2 still commits at the boundary (ISR == 2)
- broker-2 down - ISR shrinks to 1 t+11.050s ISR is now below min.insync.replicas. Open at this step: step 5, broker-2 down - ISR shrinks to 1
- O3 blocked - NotEnoughReplicas t+13.200s acks=all needs 2 in-sync replicas; only 1 remains. Open at this step: step 6, O3 blocked - NotEnoughReplicas
The takeaway
Once the ISR falls below min.insync.replicas the leader rejects acks=all writes with NOT_ENOUGH_REPLICAS - min.ISR trades availability for the guarantee that every acked record sits on at least that many replicas.
Configs in this scenario
-
acksHow many replicas must have a write before the producer counts it as sent: 0 (none), 1 (the leader only) or all (every in-sync replica, the default, and required for idempotence). How acks works -
min.The fewest in-sync replicas, leader included, that must have a write for an acks=all produce to succeed (default 1); with fewer in the ISR the leader rejects the write with NOT_ENOUGH_REPLICAS. How min.insync.replicas worksinsync. replicas
Embed this scenario
Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.
<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=03.1.2" title="Kafka Simulator: min.ISR boundary" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/min-isr-boundary/">min.insync.replicas with acks=all: when Kafka refuses writes</a></p>Further reading
Troubleshooting
More in Replication
- Kafka ISR (in-sync replicas): how replicas leave and rejoin
- Kafka slow follower: replica.lag.time.max.ms and the ISR
- Kafka high watermark pinned by a slow in-sync replica
- Losing two Kafka brokers with min.insync.replicas=2
- Kafka preferred leader election after a rack failure
- Kafka unclean.leader.election.enable: offline or data loss
- Kafka unclean leader election: permanent loss of acked data
- Kafka log truncation when an old leader returns
- Kafka broker.rack: rack-aware replica placement
- Kafka rack-aware reassignment after adding a rack
- Increase the replication factor of an existing Kafka topic