Scenario 07.2.1 · Live config changes
Change Kafka min.insync.replicas at runtime, no restart
Raising min.insync.replicas at runtime immediately changes whether the next acks=all produce can commit - no restart.
Run this scenario in the playgroundTopic created · min.ISR=2. t+0.000s
A fresh RF=3 topic with all three replicas in sync. min.insync.replicas=2 sets the durability floor: an acks=all write needs at least 2 in-sync replicas to commit. See it from the CLI: `kafka-topics --bootstrap-server localhost:9092 --describe --topic orders` (bin/kafka-topics.sh in the Apache Kafka download).
Open at this step: step 1, Topic created · min.ISR=2O1 commits - ISR=3. t+3.500s
p1 writes O1 with acks=all. All three replicas hold it, so the high watermark advances to 1 and the producer is acked - the healthy baseline before anything changes.
Open at this step: step 2, O1 commits - ISR=3broker-3 down - ISR shrinks to 2. t+7.000s
broker-3 is killed. Its replica drops out of the ISR, which shrinks from 3 to 2 - exactly at the min.insync.replicas floor, so the partition is still writable.
Open at this step: step 3, broker-3 down - ISR shrinks to 2O2 still commits - ISR=2 = min.ISR. t+8.500s
O2 is produced. The ISR (2) still meets min.insync.replicas (2), so it commits and the high watermark reaches 2. The shrunk ISR is at the edge, but not over it.
Open at this step: step 4, O2 still commits - ISR=2 = min.ISRconfig_change: min.ISR 2 → 3. t+10.500s
A live config_change raises min.insync.replicas from 2 to 3. No broker moves and no data changes - only the topic's durability bar. The new value applies immediately, with no restart. Make the change yourself: `kafka-configs --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name orders --add-config min.insync.replicas=3`.
Open at this step: step 5, config_change: min.ISR 2 → 3O3 rejected - ISR=2 < min.ISR=3. t+12.500s
O3 is produced - and rejected with NOT_ENOUGH_REPLICAS. The ISR is still 2, but the floor is now 3, so the leader can no longer satisfy acks=all. The high watermark stays at 2: the live config change alone flipped this write from success to failure.
Open at this step: step 6, O3 rejected - ISR=2 < min.ISR=3What you start with
Most topic configs are not fixed at creation - an operator can change them at runtime and the cluster reacts on the very next request. A healthy RF=3 topic commits a record, broker-3 dies and the ISR shrinks to 2 (still exactly at the min.insync.replicas floor, so the next record still commits), then a live config_change raises min.insync.replicas to 3. No broker moves, but the durability bar is now above the current ISR - so the very next acks=all produce is rejected with NOT_ENOUGH_REPLICAS.
Step by step
- Topic created · min.ISR=2 t+0.000s A fresh RF=3 topic with all three replicas in sync. min.insync.replicas=2 sets the durability floor: an acks=all write needs at least 2 in-sync replicas to commit. See it from the CLI: `kafka-topics --bootstrap-server localhost:9092 --describe --topic orders` (bin/kafka-topics.sh in the Apache Kafka download). Open at this step: step 1, Topic created · min.ISR=2
- O1 commits - ISR=3 t+3.500s p1 writes O1 with acks=all. All three replicas hold it, so the high watermark advances to 1 and the producer is acked - the healthy baseline before anything changes. Open at this step: step 2, O1 commits - ISR=3
- broker-3 down - ISR shrinks to 2 t+7.000s broker-3 is killed. Its replica drops out of the ISR, which shrinks from 3 to 2 - exactly at the min.insync.replicas floor, so the partition is still writable. Open at this step: step 3, broker-3 down - ISR shrinks to 2
- O2 still commits - ISR=2 = min.ISR t+8.500s O2 is produced. The ISR (2) still meets min.insync.replicas (2), so it commits and the high watermark reaches 2. The shrunk ISR is at the edge, but not over it. Open at this step: step 4, O2 still commits - ISR=2 = min.ISR
- config_change: min.ISR 2 → 3 t+10.500s A live config_change raises min.insync.replicas from 2 to 3. No broker moves and no data changes - only the topic's durability bar. The new value applies immediately, with no restart. Make the change yourself: `kafka-configs --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name orders --add-config min.insync.replicas=3`. Open at this step: step 5, config_change: min.ISR 2 → 3
- O3 rejected - ISR=2 < min.ISR=3 t+12.500s O3 is produced - and rejected with NOT_ENOUGH_REPLICAS. The ISR is still 2, but the floor is now 3, so the leader can no longer satisfy acks=all. The high watermark stays at 2: the live config change alone flipped this write from success to failure. Open at this step: step 6, O3 rejected - ISR=2 < min.ISR=3
The takeaway
Topic config changes take effect immediately against live state with no restart - raising min.insync.replicas above the current ISR can start rejecting producers on the spot.
Configs in this scenario
-
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 -
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
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=07.2.1" title="Kafka Simulator: Live config changes" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/live-config-changes/">Change Kafka min.insync.replicas at runtime, no restart</a></p>