Skip to content
Kafka Is Fun
ProducerProducers using acks=all

NOT_ENOUGH_REPLICAS (NotEnoughReplicasException)

Checked against Kafka 4.2 · Oct 2026Community draft, not yet reviewed by a Kafka specialist

What it means

A producer using acks=all wrote to a partition whose in-sync replica set has fewer members than min.insync.replicas. The protocol's error table describes it as "Messages are rejected since there are fewer in-sync replicas than required." NOT_ENOUGH_REPLICAS_AFTER_APPEND is the case where the low ISR size was discovered after the message was already appended to the log. Its Javadoc notes that producer retries will cause duplicates.

Quick answer

Find out which replicas dropped out of the ISR and bring them back. Do not lower min.insync.replicas just to make the error go away, unless you accept that an acknowledged write may be on fewer replicas than you intended.

Likely causes, most common first

  1. A broker is down or a follower has fallen behind

    How to confirm

    Compare Replicas and Isr for the affected partitions. The under-min-isr option lists the partitions whose ISR count is less than the configured minimum.

    confirm
    kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders
kafka-topics.sh --bootstrap-server localhost:9092 --describe --under-min-isr-partitions

    Fix

    Restart or repair the broker, or remove whatever slows the follower. The leader removes a follower from the ISR if it has not sent fetch requests, or has not consumed up to the leader's log end offset, for replica.lag.time.max.ms (30000 by default). The monitoring page notes that when a broker comes back, the ISR is expanded once its replicas are fully caught up.

  2. min.insync.replicas equals the replication factor

    How to confirm

    With replication.factor=3 and min.insync.replicas=3, losing any one replica blocks every acks=all write. Check the topic's own configuration, which overrides the broker default.

    confirm
    kafka-configs.sh --bootstrap-server localhost:9092 --describe --entity-type topics --entity-name orders

    Fix

    The documentation calls a replication factor of 3, min.insync.replicas of 2 and acks=all the typical durable setup: it keeps accepting writes with one replica down. Changing it is a durability decision, so make it on purpose.

  3. The topic has fewer replicas than you assumed

    How to confirm

    A topic with replication.factor=1 can never satisfy min.insync.replicas=2. The Replicas column of the describe output shows how many copies each partition has. A topic created automatically gets default.replication.factor, which is 1 by default, and auto.create.topics.enable is true by default.

    Fix

    Increase the replication factor by adding the extra replicas in a reassignment file and running kafka-reassign-partitions.sh with --execute, as the operations documentation describes. To stop topics from appearing with the wrong settings, set default.replication.factor and turn off auto.create.topics.enable.

See it happen

Trigger NOT_ENOUGH_REPLICAS

Opens the simulator with this exercise already running. About 6 minutes.

Reproduce in the simulator

Sources

Every claim above comes from these Apache pages, as of Kafka 4.2. If a page does not say it, this entry does not.

Was this helpful?

Report an issue (opens GitHub in a new tab)

Back to all errors