Scenario 03.3.3 · Change replication factor live
Increase the replication factor of an existing Kafka topic
Raising RF reassigns the partition with an extra replica; the new copy back-fills the log and joins the ISR.
Run this scenario in the playgroundRF=2 · two copies on brokers 1 & 2. t+1.800s
The topic's replication factor is 2: the partition has replicas on brokers 1 and 2 (both in-sync). broker-3 holds no copy.
Open at this step: step 1, RF=2 · two copies on brokers 1 & 2RF raised to 3 · broker-3 assigned and back-filling. t+3.200s
Changing the replication factor to 3 reassigns the partition with a third replica (broker-3). It starts empty and fetches the existing records - present in the replica set, but not yet in the ISR.
Open at this step: step 2, RF raised to 3 · broker-3 assigned and back-fillingbroker-3 caught up · ISR {1,2,3}. t+4.000s
broker-3 finished back-filling, caught up to the leader, and joined the ISR. The partition now has three in-sync copies. (Real Kafka performs this as a partition reassignment.)
Open at this step: step 3, broker-3 caught up · ISR {1,2,3}What you start with
A topic’s replication factor is not fixed for life - it is changed by a partition reassignment that adds or drops replicas. This partition starts at RF=2; after a few records, RF is raised to 3, assigning broker-3 as a new, initially-empty replica.
Step by step
- RF=2 · two copies on brokers 1 & 2 t+1.800s The topic's replication factor is 2: the partition has replicas on brokers 1 and 2 (both in-sync). broker-3 holds no copy. Open at this step: step 1, RF=2 · two copies on brokers 1 & 2
- RF raised to 3 · broker-3 assigned and back-filling t+3.200s Changing the replication factor to 3 reassigns the partition with a third replica (broker-3). It starts empty and fetches the existing records - present in the replica set, but not yet in the ISR. Open at this step: step 2, RF raised to 3 · broker-3 assigned and back-filling
- broker-3 caught up · ISR {1,2,3} t+4.000s broker-3 finished back-filling, caught up to the leader, and joined the ISR. The partition now has three in-sync copies. (Real Kafka performs this as a partition reassignment.) Open at this step: step 3, broker-3 caught up · ISR {1,2,3}
The takeaway
The new replica back-fills the existing log, catches up, and joins the ISR, leaving the partition with three in-sync copies - replication factor is increased online with no downtime.
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.3" title="Kafka Simulator: Change replication factor live" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/change-replication-factor/">Increase the replication factor of an existing Kafka topic</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 broker.rack: rack-aware replica placement
- Kafka rack-aware reassignment after adding a rack