Scenario 03.3.1 · Rack-aware placement
Kafka broker.rack: rack-aware replica placement
broker.rack spreads replicas across racks; a whole rack can fail and partitions stay available.
Run this scenario in the playgroundSix-broker cluster ready - rack-aware assignment spreads each partition across rack-a / rack-b / rack-c. t+0.000s
Six brokers over three racks (2 per rack), broker.rack set. Rack-aware assignment places each partition's 3 replicas in three DIFFERENT racks - no rack ever holds two copies of the same partition.
Open at this step: step 1, Six-broker cluster ready - rack-aware assignment spreads each partition across rack-a / rack-b / rack-cRecord O1 produced and replicated across all three racks. t+5.000s
O1 commits with acks=all: the leader and both followers sit in different racks, so every rack now holds a copy of the record.
Open at this step: step 2, Record O1 produced and replicated across all three racksbroker-5 and broker-6 (whole rack-c) dead - leaders elected on surviving replicas, ISR ≥ 2 on every partition. t+8.000s
A whole-rack outage: both rack-c brokers die at once. Because placement was rack-aware, every partition loses exactly ONE replica - leaders re-elect on the survivors and the ISR holds at 2 = min.insync.replicas everywhere.
Open at this step: step 3, broker-5 and broker-6 (whole rack-c) dead - leaders elected on surviving replicas, ISR ≥ 2 on every partitionRecord O2 produced after rack-c failure - acks=all succeeds with 2 in-sync replicas. t+10.500s
O2 still commits: with 2 in-sync replicas per partition, acks=all + min.insync.replicas=2 stays satisfiable despite the lost rack - durability against a correlated rack/AZ failure.
Open at this step: step 4, Record O2 produced after rack-c failure - acks=all succeeds with 2 in-sync replicasWhat you start with
When broker.rack is set, Kafka spreads a partition’s replicas across racks so no single rack holds them all. This cluster places three replicas over three racks; an entire rack (two brokers) is then killed to show the partition staying available.
Step by step
- Six-broker cluster ready - rack-aware assignment spreads each partition across rack-a / rack-b / rack-c t+0.000s Six brokers over three racks (2 per rack), broker.rack set. Rack-aware assignment places each partition's 3 replicas in three DIFFERENT racks - no rack ever holds two copies of the same partition. Open at this step: step 1, Six-broker cluster ready - rack-aware assignment spreads each partition across rack-a / rack-b / rack-c
- Record O1 produced and replicated across all three racks t+5.000s O1 commits with acks=all: the leader and both followers sit in different racks, so every rack now holds a copy of the record. Open at this step: step 2, Record O1 produced and replicated across all three racks
- broker-5 and broker-6 (whole rack-c) dead - leaders elected on surviving replicas, ISR ≥ 2 on every partition t+8.000s A whole-rack outage: both rack-c brokers die at once. Because placement was rack-aware, every partition loses exactly ONE replica - leaders re-elect on the survivors and the ISR holds at 2 = min.insync.replicas everywhere. Open at this step: step 3, broker-5 and broker-6 (whole rack-c) dead - leaders elected on surviving replicas, ISR ≥ 2 on every partition
- Record O2 produced after rack-c failure - acks=all succeeds with 2 in-sync replicas t+10.500s O2 still commits: with 2 in-sync replicas per partition, acks=all + min.insync.replicas=2 stays satisfiable despite the lost rack - durability against a correlated rack/AZ failure. Open at this step: step 4, Record O2 produced after rack-c failure - acks=all succeeds with 2 in-sync replicas
The takeaway
Rack-aware placement spreads each partition over min(#racks, RF) racks - here one replica per rack - so a full rack (or availability-zone) outage still leaves enough in-sync copies for the partition to keep serving.
Configs in this scenario
-
broker.The rack or availability zone of the broker; when a topic is created, the replicas of each partition are spread across racks so one rack failing cannot take every copy.rack -
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.3.1" title="Kafka Simulator: Rack-aware placement" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/rack-aware-placement/">Kafka broker.rack: rack-aware replica placement</a></p>Further reading
More in Replication
- Kafka ISR (in-sync replicas): how replicas leave and rejoin
- min.insync.replicas with acks=all: when Kafka refuses writes
- 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 rack-aware reassignment after adding a rack
- Increase the replication factor of an existing Kafka topic