Not enough replicas: get Kafka writes flowing again
Producers are being rejected because the in-sync replica set shrank below min.insync.replicas. Find the partitions, bring replicas back, and do not loosen durability before you have a copy of the data.
What the error means
org.apache.kafka.common.errors.NotEnoughReplicasException:
Messages are rejected since there are fewer in-sync replicas than required.
Kafka raises the not enough replicas error when a producer sends with
acks=all to a partition whose in-sync replica set (ISR) has shrunk below
the topic's min.insync.replicas. The broker rejects the write instead of
accepting it with weaker durability than you configured.
The error is the guardrail, not the disease. With the common setup of
replication factor 3 and min.insync.replicas=2, seeing it means two of the
three replicas are already unavailable or lagging — you are one failure away
from losing the partition's only copy.
How to fix Kafka not enough replicas errors
Work the steps in order. The goal is to restore the ISR, not to silence the producer.
1. Find the affected partitions.
kafka-topics.sh --bootstrap-server kafka:9092 \
--describe --under-min-isr-partitions
Every partition listed is rejecting acks=all writes right now. Compare
with --under-replicated-partitions to see how wide the degradation is.
2. Find out why replicas left the ISR. Look at the broker IDs missing
from the Isr column and check those brokers first.
| Symptom | Likely cause | Action |
|---|---|---|
| One broker missing from every ISR it belongs to | Broker down or restarting | Restart the broker; replicas rejoin the ISR automatically once caught up |
| Followers on a live broker keep dropping out | Follower lagging past replica.lag.time.max.ms — saturated disk, network, or an overloaded broker | Fix the bottleneck; watch the fetcher lag until the ISR is stable |
| Error on one topic only, cluster healthy | min.insync.replicas set higher than the topic's replication factor | Raise the replication factor or correct the setting — this combination can never accept acks=all writes |
| Error fires during a rolling restart or upgrade | Restarts outpacing ISR recovery | Pause the roll; wait for UnderMinIsrPartitionCount to return to 0 before the next broker |
3. Confirm recovery. The kafka.server:type=ReplicaManager,name=UnderMinIsrPartitionCount
metric returning to 0 means every partition can accept acks=all writes
again. Producers with retries enabled resume on their own — the error is
retriable.
Before you loosen anything, take a backup
The tempting mid-incident fixes all trade away durability. Lowering
min.insync.replicas to 1 lets writes land on a single replica. Switching
producers to acks=1 does the same from the client side. Enabling unclean
leader election can discard committed records outright.
There is a safer order of operations, because min.insync.replicas only
gates produce requests — reads are unaffected. A backup job is a consumer,
so you can copy the partition data out of the cluster while writes are
blocked. Take the snapshot first; loosen settings second, if you still need
to.
- backup.yaml
- Run and verify
mode: backup
backup_id: "isr-incident-snapshot"
source:
bootstrap_servers:
- broker-1.prod.kafka:9092
- broker-2.prod.kafka:9092
topics:
include:
- "orders"
- "payments"
storage:
backend: s3
bucket: my-kafka-backups
region: us-west-2
prefix: backups/incidents
backup:
compression: zstd
include_offset_headers: true # Preserve offsets for consumer repositioning
kafka-backup backup --config backup.yaml
kafka-backup validate --path s3://my-kafka-backups/backups/incidents \
--backup-id isr-incident-snapshot --deep
Every key above is documented in the configuration reference. With the snapshot verified, even the worst case — losing the last in-sync replica — has a recovery floor.
After the incident
Set the durability floor deliberately: replication factor 3 with
min.insync.replicas=2 tolerates one failure without blocking writes. How
the ISR works and why the floor matters is covered in the
in-sync replicas guide, and the
under-replicated partitions guide
shows the alert ladder that catches shrinking ISRs before producers fail.
Keep a scheduled backup running so the next time this guardrail fires, the
data already has an independent copy — the
disaster recovery use case shows that setup.
Frequently asked questions
What does NotEnoughReplicasException mean in Kafka?
A producer using acks=all wrote to a partition whose in-sync replica set is smaller than min.insync.replicas. The broker rejects the write to protect durability. With replication factor 3 and min.insync.replicas=2, it means two of three replicas are unavailable or lagging.
How do I find which partitions are below min.insync.replicas?
Run kafka-topics.sh --describe --under-min-isr-partitions against the cluster. It lists every partition currently rejecting acks=all writes. The UnderMinIsrPartitionCount metric on kafka.server:type=ReplicaManager tracks the same condition for alerting.
Should I lower min.insync.replicas to fix the error?
Only as a last resort, and only after copying the data out. Lowering the setting to 1 restores writes but lets them land on a single replica, so one more failure loses data. Fix the replicas first; if you must loosen the floor, take a verified backup before you do.
What is the difference between NotEnoughReplicas and NotEnoughReplicasAfterAppend?
NotEnoughReplicas means the write was rejected before being appended anywhere. NotEnoughReplicasAfterAppend means the leader appended the record but could not replicate it to enough followers. Both are retriable; the second can produce duplicates on retry unless the producer is idempotent.
Does the not enough replicas error affect consumers too?
No. min.insync.replicas only gates produce requests with acks=all. Consumers keep reading committed records, which is also why a backup job can still copy data out of the cluster during the incident.
Ready to protect your Kafka data?
Take your first backup in minutes with the open source CLI, or talk to us about Enterprise features like encryption, RBAC, and audit logging.