Scenario 08.0.3 · Minority vs majority
Kafka network partition: the majority side keeps writing
With a producer and consumer running across a split, the majority side keeps advancing the high watermark while the isolated minority is frozen at the pre-split offset.
Run this scenario in the playgroundHealthy cluster. t+1.000s
Three brokers, RF=3, min.ISR=2, plus consumer c1 reading partition 0.
Open at this step: step 1, Healthy clusterO1,O2 committed, consumer caught up. t+5.000s
O1,O2 commit on all three (HW=2); c1 polls up to offset 2. Producer, consumer and replicas are all in sync.
Open at this step: step 2, O1,O2 committed, consumer caught upSplit: broker-2 elected, broker-1 frozen. t+8.000s
The network splits {broker-1} | {broker-2, broker-3}. The controller, still reachable from broker-2 and broker-3, elects broker-2 from the ISR; the isolated broker-1 is fenced and frozen at offset 2. No new writes yet, so the HW is still 2.
Open at this step: step 3, Split: broker-2 elected, broker-1 frozenMajority makes progress (HW=4). t+12.000s
O3,O4 commit on the majority ISR {broker-2, broker-3} and the HW advances to 4; c1 reads them. Meanwhile broker-1 is stuck at LEO 2 - availability follows the side that can reach the controller.
Open at this step: step 4, Majority makes progress (HW=4)Healed: minority catches up. t+16.000s
On heal, broker-1 fetches O3,O4 (LEO 2→4) and rejoins the ISR. The minority lost no committed data - it simply could not make progress while isolated.
Open at this step: step 5, Healed: minority catches upWhat you start with
The companion to the split-brain scenario, run with a producer and consumer active across the split so the asymmetry is visible. After two records commit on all three replicas, the network splits {broker-1} from {broker-2, broker-3}; the controller, still reachable from the majority side, elects a leader there that keeps committing, while the isolated broker is fenced and left with no leader.
Step by step
- Healthy cluster t+1.000s Three brokers, RF=3, min.ISR=2, plus consumer c1 reading partition 0. Open at this step: step 1, Healthy cluster
- O1,O2 committed, consumer caught up t+5.000s O1,O2 commit on all three (HW=2); c1 polls up to offset 2. Producer, consumer and replicas are all in sync. Open at this step: step 2, O1,O2 committed, consumer caught up
- Split: broker-2 elected, broker-1 frozen t+8.000s The network splits {broker-1} | {broker-2, broker-3}. The controller, still reachable from broker-2 and broker-3, elects broker-2 from the ISR; the isolated broker-1 is fenced and frozen at offset 2. No new writes yet, so the HW is still 2. Open at this step: step 3, Split: broker-2 elected, broker-1 frozen
- Majority makes progress (HW=4) t+12.000s O3,O4 commit on the majority ISR {broker-2, broker-3} and the HW advances to 4; c1 reads them. Meanwhile broker-1 is stuck at LEO 2 - availability follows the side that can reach the controller. Open at this step: step 4, Majority makes progress (HW=4)
- Healed: minority catches up t+16.000s On heal, broker-1 fetches O3,O4 (LEO 2→4) and rejoins the ISR. The minority lost no committed data - it simply could not make progress while isolated. Open at this step: step 5, Healed: minority catches up
The takeaway
Availability follows the side that can reach the controller and still meets min.insync.replicas - here the majority, which keeps advancing the high watermark and serving reads, while the isolated broker makes no progress until the partition heals and it catches up on what it missed.
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
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=08.0.3" title="Kafka Simulator: Minority vs majority" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/minority-vs-majority/">Kafka network partition: the majority side keeps writing</a></p>