🚨 Kafka Error Guide: 'InvalidReplicationFactorException' Larger Than Available Brokers

Exact Error Message

This error appears when you try to create a topic (or auto-create one) with a replication factor higher than the number of brokers Kafka can currently see. The CLI wraps it inside a “Cannot create topic” / “Error while executing topic command” message, but the root cause is the broker-side InvalidReplicationFactorException:

Error while executing topic command : Replication factor: 3 larger than available brokers: 1.
[2026-06-29 09:41:55,220] ERROR org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 3 larger than available brokers: 1.
	at kafka.admin.TopicCommand$AdminClientTopicService.createTopic(TopicCommand.scala:331)
	at kafka.admin.TopicCommand$.main(TopicCommand.scala:62)
Caused by: java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.InvalidReplicationFactorException: Unable to replicate the partition 3 time(s): The target replication factor of 3 cannot be reached because only 1 broker(s) are registered.
 (kafka.admin.TopicCommand$)

From a producer with topic auto-creation you may instead see:

org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 3 larger than available brokers: 1.

What the Error Means

Every Kafka partition is stored as a set of replicas spread across distinct brokers. The replication factor (RF) is how many copies of each partition Kafka maintains, and each replica must live on a separate broker — Kafka will not place two replicas of the same partition on one broker. So the maximum possible RF for any topic is exactly the number of live, registered brokers in the cluster.

When you request RF=3 but only 1 broker is registered, Kafka cannot satisfy the placement constraint and rejects the create with InvalidReplicationFactorException. The error is a hard invariant check, not a transient condition — retrying without changing RF or broker count will fail identically.

The same exception also covers RF=0 or a negative replication factor, since RF must be a positive integer no greater than the broker count.

Common Causes

1. RF greater than the number of brokers

The literal cause: you asked for more copies than there are brokers to hold them. RF=3 on a 2-broker cluster fails just as surely as on a 1-broker cluster.

2. Brokers are down, so the available count dropped

The cluster is sized for RF=3, but one or two brokers crashed or are mid-restart. The “available brokers” count Kafka uses is the number currently registered, so a topic create that worked yesterday fails today simply because fewer brokers are online.

3. Single-broker dev cluster with an RF=3 default

A common bite: default.replication.factor=3 (or auto-create defaults from a copied prod config) on a one-node dev or CI cluster. Any auto-created topic or producer-triggered topic fails immediately.

4. Confusing min.insync.replicas with replication factor

min.insync.replicas controls how many in-sync replicas must acknowledge a write for acks=all; it is not the RF. Setting min.insync.replicas=3 on a topic with RF less than 3 causes produce-time failures (NotEnoughReplicasException), and trying to “match” them by bumping RF above the broker count triggers this error. They are related but distinct knobs.

5. RF of zero or negative

A templated value that resolves to 0 or empty produces an invalid replication factor — partitions need at least one replica.

How to Reproduce the Error

On a single-broker cluster, request RF higher than 1:

# Single broker running on localhost:9092
kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic payments --partitions 3 --replication-factor 3

This fails instantly with Replication factor: 3 larger than available brokers: 1. You can reproduce the “brokers down” variant by stopping one node of a 3-broker cluster and creating a topic with RF=3 while only 2 are registered.

Diagnostic Commands

All commands here are read-only.

Count the brokers Kafka can actually reach — each line is one reachable broker:

kafka-broker-api-versions.sh --bootstrap-server localhost:9092 \
  | grep -c "id:"

1

Inspect an existing topic’s replication factor and replica placement:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --describe --topic payments

Topic: payments	PartitionCount: 3	ReplicationFactor: 1	Configs: min.insync.replicas=1
	Topic: payments	Partition: 0	Leader: 1	Replicas: 1	Isr: 1

Check the cluster-wide defaults that drive auto-creation:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --describe --entity-type brokers --entity-default \
  | grep -E "replication.factor|min.insync"

List the registered broker IDs. On a ZooKeeper-backed cluster:

zookeeper-shell.sh localhost:2181 ls /brokers/ids

[1]

On a KRaft cluster, the broker count comes from the metadata quorum — kafka-broker-api-versions.sh above is the portable way to count live brokers, and kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --status shows the controller state. Both ZooKeeper and KRaft enforce the same RF-vs-broker rule.

Confirm whether the failing create came from auto-creation or a manual command in the logs:

journalctl -u kafka --since "15 min ago" | grep -i InvalidReplicationFactor

Step-by-Step Resolution

Case A: You requested more replicas than you have brokers

Set the replication factor to a value no greater than the number of live brokers. On a single-broker dev cluster, use RF=1:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create --topic payments --partitions 3 --replication-factor 1

On a 3-broker cluster, RF=3 is appropriate. The rule is simply RF <= live broker count.

Case B: Brokers are down — bring them back

If the cluster is sized for RF=3 but the create fails because nodes are offline, the fix is to restore the brokers, not to lower RF for a production topic. Verify each node is registered:

kafka-broker-api-versions.sh --bootstrap-server localhost:9092 | grep -c "id:"

Once the expected number of brokers is registered, re-run the create with the intended RF.

Case C: Fix the cluster default for dev/CI

If auto-created topics keep failing on a small cluster, set a sane default so producers and tooling do not request RF=3. For a single-broker dev node, set default.replication.factor=1 (and offsets.topic.replication.factor=1, transaction.state.log.replication.factor=1 for the internal topics) in server.properties, then restart, or apply dynamically:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --entity-type brokers --entity-default \
  --add-config default.replication.factor=1

Case D: Align min.insync.replicas with RF

If your real intent was durability, make sure min.insync.replicas is less than or equal to the RF. A common production pattern is RF=3 with min.insync.replicas=2, which tolerates one broker loss while still requiring a quorum of acks:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --entity-type topics --entity-name payments \
  --add-config min.insync.replicas=2

Never set min.insync.replicas higher than the RF, and never set RF above the broker count to chase it.

Prevention and Best Practices

• Match RF to broker count by environment. Use RF=1 for single-node dev/CI and RF=3 for production clusters of three or more brokers. Keep environment-specific config rather than copying prod settings to a laptop.
• Set the internal-topic replication factors too. offsets.topic.replication.factor, transaction.state.log.replication.factor, and default.replication.factor all default to higher values in some distributions and will break a small cluster on first use.
• Use RF=3 with min.insync.replicas=2 in production. This survives a single broker failure while keeping durable acknowledged writes. Always require at least three brokers for this.
• Disable auto-topic-creation in production (auto.create.topics.enable=false) so topics are provisioned deliberately with correct RF, instead of producers triggering RF=default creates.
• Alert on registered broker count. A drop below your RF means new topic creation will fail; catch it before a deploy does. See more patterns in the Kafka guides.
• Validate RF and min.insync.replicas in provisioning code. Reject RF=0, negatives, RF above broker count, and min.insync.replicas > RF before calling the admin API.

Related Errors

• org.apache.kafka.common.errors.InvalidPartitionsException — requesting an invalid partition count (e.g. trying to decrease partitions), a frequent companion when scripting topic creation.
• org.apache.kafka.common.errors.NotEnoughReplicasException — produced at write time when fewer than min.insync.replicas are in sync for acks=all; the runtime symptom of a misaligned RF/min.insync pair.
• TopicExistsException — re-running a create against an existing topic.
• org.apache.kafka.common.errors.PolicyViolationException — a create.topic.policy plugin rejecting the requested replication or partition settings.

Frequently Asked Questions

Why can’t the replication factor exceed the number of brokers?

Each replica of a partition must live on a distinct broker — Kafka never co-locates two replicas of the same partition. So the maximum RF is exactly the number of live brokers. Requesting more is physically unsatisfiable, and Kafka rejects it immediately.

My topic worked before and now fails to create — what changed?

The “available brokers” count is the number currently registered. If one or more brokers crashed or are restarting, the live count dropped below your requested RF. Bring the brokers back online (verify with kafka-broker-api-versions.sh) rather than lowering RF for a production topic.

What is the difference between replication factor and min.insync.replicas?

RF is how many copies of each partition exist. min.insync.replicas is how many of those copies must be in sync to accept an acks=all write. min.insync.replicas must be less than or equal to RF; a typical durable setup is RF=3 with min.insync.replicas=2.

Does this error behave differently on KRaft versus ZooKeeper?

No. Both KRaft and ZooKeeper-based clusters enforce the same rule: RF cannot exceed the number of registered brokers. The only difference is where broker registration lives (the KRaft metadata quorum versus /brokers/ids in ZooKeeper). The fix is identical in both modes.

How should I set replication factor for a single-broker dev cluster?

Use RF=1 for the topic and for the internal topics (offsets.topic.replication.factor, transaction.state.log.replication.factor) and set default.replication.factor=1. This avoids the error entirely while you develop locally; switch to RF=3 only on clusters with three or more brokers.