---
title: "Kafka rack-aware reassignment after adding a rack"
description: "With two racks, RF=3 puts two replicas in one rack. A broker joins rack-c, and a rack-aware reassignment spreads each Kafka partition across all three racks."
url: https://monedula.dev/kafka-simulator/scenarios/rack-rebalance/
---

# Kafka rack-aware reassignment after adding a rack

Scenario 03.3.2 · Rack rebalance. Replication · Advanced · about 3 min · Apache Kafka 4.3.

With only 2 racks, RF=3 must put 2 replicas in one rack; add a 3rd rack and rack-aware reassignment spreads them.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2

## What you start with

With only two racks, a 3-replica partition must place two copies in one rack, leaving it exposed if that rack fails. Here a third rack is added and each partition is reassigned rack-aware so its replicas spread across all three.

## Step by step

1. **Cluster ready** (t+0.000s): Four brokers across 2 racks (rack-a × 2, rack-b × 2). With RF=3 and only two racks, every partition must put 2 replicas in one rack. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=0)
2. **Record O1 committed** (t+6.000s): O1 acknowledged by the leader (acks=all). All 3 ISR replicas in sync. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=1)
3. **broker-5 joined rack-c** (t+9.000s): A fifth broker joins in rack-c. No partitions yet - each partition still clumps 2 replicas in one rack. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=2)
4. **Partition 0 reassigning** (t+12.050s): reassign_rack_aware fires for partition 0: one rack-a or rack-b replica is replaced by broker-5 (rack-c). New replica is catching up. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=3)
5. **Partition 0 rebalanced** (t+12.600s): Partition 0 ISR reconverged. Replicas now span rack-a, rack-b, and rack-c. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=4)
6. **Partition 1 reassigning** (t+16.050s): reassign_rack_aware fires for partition 1. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=5)
7. **Partition 1 rebalanced** (t+16.600s): Partition 1 ISR reconverged across all 3 racks. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=6)
8. **Partition 2 reassigning** (t+20.050s): reassign_rack_aware fires for partition 2. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=7)
9. **All partitions rebalanced** (t+20.600s): Every orders partition now has one replica in each of rack-a, rack-b, and rack-c. ISR is full on all partitions. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=03.3.2&t=8)

## The takeaway

Adding capacity does not automatically rebalance existing partitions - a rack-aware reassignment is what redistributes replicas to restore per-rack fault tolerance.

## Configs in this scenario

- [`acks`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_acks): How 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](https://monedula.dev/kafka-simulator/configs/acks/)

## Further reading

- [Apache Kafka documentation](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_broker.rack)