---
title: "NotEnoughReplicasException in Kafka: causes and fixes"
description: "Why a Kafka producer with acks=all gets NOT_ENOUGH_REPLICAS when the ISR shrinks below min.insync.replicas, and how to fix it without giving up durability."
url: https://monedula.dev/kafka-simulator/troubleshooting/not-enough-replicas/
---

# NotEnoughReplicasException (NOT_ENOUGH_REPLICAS)

Kafka error · NOT_ENOUGH_REPLICAS · retriable.

Exception: `org.apache.kafka.common.errors.NotEnoughReplicasException`

## Quick answer

The partition has fewer in-sync replicas than its min.insync.replicas, so the leader refuses acks=all writes instead of acknowledging data that too few brokers hold. Bring the missing replicas back into the ISR; lower min.insync.replicas only as a deliberate durability trade-off.

## What it means

With acks=all a write succeeds only once every replica in the in-sync replica set (ISR) has it, and the topic setting min.insync.replicas is the smallest ISR the leader accepts such a write with. The leader checks the ISR size before it appends: below the minimum it rejects the batch with NOT_ENOUGH_REPLICAS (error code 19) and writes nothing. The broker message gives the numbers, for example "The size of the current ISR : 1 is insufficient to satisfy the min.isr requirement of 2 for partition orders-0, ...". NotEnoughReplicasException extends RetriableException, so the producer logs a warning per attempt ("Got error produce response ... retrying ... Error: NOT_ENOUGH_REPLICAS") and retries with backoff until delivery.timeout.ms (default 2 minutes) runs out. Only then does the send fail, with this exception or with a TimeoutException ("Expiring N record(s)") if the batch expired while waiting for its next attempt. A relative, NOT_ENOUGH_REPLICAS_AFTER_APPEND (code 20), means the ISR shrank after the leader had already appended the batch, so a retry from a non-idempotent producer can write a duplicate. Writes with acks=0 or acks=1 are not checked against min.insync.replicas.

## Likely causes, most common first

1. **A broker is down or a follower fell behind.** A follower that has not caught up to the leader's log end within replica.lag.time.max.ms (default 30 seconds) is removed from the ISR, and a stopped broker leaves every ISR it was in. With replication factor 3 and min.insync.replicas 2, one missing replica is tolerated; a second one blocks acks=all writes on that partition.
2. **Several replicas failed together.** Brokers that share a rack, power feed or availability zone fail as a unit. If too many of a partition's replicas share one failure domain, a single outage takes the ISR below the minimum: with replication factor 4 split over two racks and min.insync.replicas 3, losing either rack is enough.
3. **min.insync.replicas leaves no headroom.** With replication factor 3 and min.insync.replicas 3, any single replica restart, including a routine rolling restart, blocks acks=all writes. The same happens when someone raises the minimum on a live topic with kafka-configs.sh; topic configs change without a broker restart.
4. **The topic has fewer replicas than the minimum.** A topic whose replication factor is below min.insync.replicas can never take an acks=all write, and one whose replication factor equals it fails on the first lost replica. Check topics auto-created with a low default.replication.factor against a broker-wide minimum of 2.

## How to fix it

- List the affected partitions with kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-min-isr-partitions, compare each partition's Isr with its Replicas, and restart or repair the brokers that are missing.
- Watch the broker metrics UnderMinIsrPartitionCount, AtMinIsrPartitionCount and IsrShrinksPerSec (kafka.server:type=ReplicaManager); a partition at its minimum is one failure away from this error.
- If followers are alive but lagging, look at their disk, network and replication throughput before changing replica.lag.time.max.ms.
- Spread replicas over failure domains: set broker.rack on every broker so replicas of a partition land on different racks, and size min.insync.replicas so that losing one rack or zone still leaves enough in-sync replicas.
- If the topic really must accept writes with fewer copies, lower it per topic, for example from 3 to 2 with kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders --alter --add-config min.insync.replicas=2, and record the durability you are giving up.

## What not to do

- Switching producers to acks=1 or lowering min.insync.replicas cluster-wide to make the error disappear: both trade durability for availability without fixing the missing replicas.
- Raising delivery.timeout.ms or retries instead of fixing the ISR: the producer only waits longer before it fails.

## Does the client retry it?

Yes. The Kafka client treats this error as retriable and retries the request until delivery.timeout.ms runs out.

## Configs involved

- [`min.insync.replicas`](https://kafka.apache.org/43/configuration/topic-configs/#topicconfigs_min.insync.replicas): 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.
- [`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).
- [`replica.lag.time.max.ms`](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_replica.lag.time.max.ms): How long a follower may go without fetching, or without catching up to the end of the leader log, before the leader removes it from the ISR (default 30000, 30 seconds).
- [`default.replication.factor`](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_default.replication.factor): The replication factor of topics created automatically or without one (default 1); production clusters usually set 3.
- [`broker.rack`](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_broker.rack): 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.
- [`retries`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_retries): How many times the producer sends a batch again after a transient error (default 2147483647, so in practice delivery.timeout.ms ends the retrying); idempotence needs it above 0.
- [`delivery.timeout.ms`](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_delivery.timeout.ms): The upper bound on reporting success or failure after send() returns, covering the wait in a batch, the wait for the acknowledgement and every retry (default 120000, 2 minutes); it should be at least request.timeout.ms plus linger.ms.

## Reproduce it in the simulator

- [Kafka acks=0 vs acks=1 vs acks=all on a degraded ISR](https://monedula.dev/kafka-simulator/scenarios/acks-tradeoff/) (acks trade-off): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=01.1.3&t=3)
- [Kafka idempotent producer: retrying NOT_ENOUGH_REPLICAS](https://monedula.dev/kafka-simulator/scenarios/idempotence-retry/) (Idempotence retry): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=01.3.1&t=2)
- [min.insync.replicas with acks=all: when Kafka refuses writes](https://monedula.dev/kafka-simulator/scenarios/min-isr-boundary/) (min.ISR boundary): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=03.1.2&t=5)
- [Change Kafka min.insync.replicas at runtime, no restart](https://monedula.dev/kafka-simulator/scenarios/live-config-changes/) (Live config changes): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=07.2.1&t=5)
- [Kafka NOT_ENOUGH_REPLICAS: brokers failing one by one](https://monedula.dev/kafka-simulator/scenarios/cascading-isr-loss/) (Cascading failure: losing the ISR one by one): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=08.0.4&t=7)
- [Kafka rack failure: why RF=4 on two racks refuses writes](https://monedula.dev/kafka-simulator/scenarios/correlated-rack-failure/) (Correlated failure: a whole rack goes down): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=08.0.6&t=3)
- [Confluent MRC observer promotion: losing the Kafka leader DC](https://monedula.dev/kafka-simulator/scenarios/observer-promotion-reachable-leader/) (Observer promotion needs a reachable leader): [open at the moment it happens](https://monedula.dev/kafka-simulator/playground/?scenario=10.1.4&t=6)

## Sources

- [Apache Kafka 4.3: topic config min.insync.replicas](https://kafka.apache.org/43/configuration/topic-configs/#topicconfigs_min.insync.replicas)
- [Apache Kafka 4.3: producer config acks](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_acks)
- [Apache Kafka 4.3: broker config replica.lag.time.max.ms](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_replica.lag.time.max.ms)
- [Apache Kafka 4.3 Javadoc: NotEnoughReplicasException](https://kafka.apache.org/43/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasException.html)
- [Apache Kafka 4.3.0 source: Errors.java (NOT_ENOUGH_REPLICAS, code 19)](https://github.com/apache/kafka/blob/4.3.0/clients/src/main/java/org/apache/kafka/common/protocol/Errors.java)
- [Apache Kafka 4.3.0 source: Partition.scala (the min.isr check before append)](https://github.com/apache/kafka/blob/4.3.0/core/src/main/scala/kafka/cluster/Partition.scala)
- [Apache Kafka 4.3.0 source: TopicCommand.java (--under-min-isr-partitions)](https://github.com/apache/kafka/blob/4.3.0/tools/src/main/java/org/apache/kafka/tools/TopicCommand.java)
- [Apache Kafka 4.3: monitoring (ReplicaManager metrics)](https://kafka.apache.org/43/operations/monitoring/)
- [Apache Kafka 4.3: balancing replicas across racks](https://kafka.apache.org/43/operations/basic-kafka-operations/#balancing-replicas-across-racks)

## Related

- [TimeoutException in Kafka producers: causes and fixes](https://monedula.dev/kafka-simulator/troubleshooting/producer-timeout-exception/)
- [Kafka under-replicated partitions: causes and fixes](https://monedula.dev/kafka-simulator/troubleshooting/under-replicated-partitions/)
- [Kafka offline partitions with no leader: causes and fixes](https://monedula.dev/kafka-simulator/troubleshooting/offline-partitions-no-leader/)