🚨 Redis Error Guide: 'NOREPLICAS Not enough good replicas to write' — Restore Replica Health or Relax min-replicas

Overview

Redis rejects writes with NOREPLICAS when the primary is configured to require a minimum number of healthy, low-lag replicas before it will accept a write, and fewer than that number are currently connected and in sync. It is a durability guard: min-replicas-to-write (with min-replicas-max-lag) tells the primary “don’t acknowledge a write unless at least N replicas can receive it within M seconds.”

The literal error clients receive:

(error) NOREPLICAS Not enough good replicas to write.

This is the primary doing exactly what it was told. The write path is fine — what has failed is replica health: a replica disconnected, fell behind past min-replicas-max-lag, or the setting is simply stricter than the current topology can satisfy. Reads still work; only writes are blocked.

Symptoms

• Every write command (SET, LPUSH, HSET, INCR) fails with NOREPLICAS; reads succeed.
• INFO replication on the primary shows fewer connected_slaves than min-replicas-to-write, or replicas with high lag.
• The error appears suddenly after a replica restart, a network blip, or a failover.

redis-cli SET order:42 paid

(error) NOREPLICAS Not enough good replicas to write.

redis-cli CONFIG GET min-replicas-to-write
redis-cli CONFIG GET min-replicas-max-lag

1) "min-replicas-to-write"
2) "1"
1) "min-replicas-max-lag"
2) "10"

Common Root Causes

1. A replica disconnected

The only (or last) replica dropped its link to the primary, so connected_slaves fell below the threshold.

redis-cli INFO replication

# Replication
role:master
connected_slaves:0
min_slaves_good_slaves:0

2. Replicas are lagging past min-replicas-max-lag

The replicas are connected but their last ack is older than min-replicas-max-lag seconds (slow network, overloaded replica, big write burst), so they don’t count as “good.”

redis-cli INFO replication | grep -E 'slave[0-9]+:'

slave0:ip=10.0.0.7,port=6379,state=online,offset=884512,lag=14

lag=14 against min-replicas-max-lag:10 means this replica is not counted.

3. The setting is stricter than the topology

min-replicas-to-write is set to 2 but only one replica was ever deployed, so writes can never satisfy the rule.

4. Post-failover with no replicas yet

After a Sentinel/Cluster failover the new primary may have zero attached replicas until they re-point, temporarily blocking writes.

Diagnostic Workflow

Step 1: Read the guard settings

redis-cli CONFIG GET min-replicas-to-write
redis-cli CONFIG GET min-replicas-max-lag

Step 2: Count good replicas on the primary

redis-cli INFO replication | grep -E 'role|connected_slaves|min_slaves_good_slaves|slave[0-9]+:'

min_slaves_good_slaves is the number Redis currently considers healthy — compare it to min-replicas-to-write.

Step 3: Inspect each replica’s link and lag

# On each replica
redis-cli -h <replica> INFO replication | grep -E 'master_link_status|master_last_io_seconds_ago|master_sync_in_progress'

master_link_status:down
master_last_io_seconds_ago:37

master_link_status:down or a large master_last_io_seconds_ago explains a missing good replica.

Step 4: Check for replication buffer / network trouble

redis-cli INFO stats | grep -E 'sync_full|sync_partial_ok|sync_partial_err'
redis-cli INFO replication | grep -E 'repl_backlog_active|master_repl_offset'

Step 5: Read the logs for link drops

sudo journalctl -u redis-server --no-pager | grep -iE 'MASTER <-> REPLICA|link|sync|NOREPLICAS' | tail

Example Root Cause Analysis

At 02:10 every checkout write starts failing with NOREPLICAS. Reads are fine. CONFIG GET min-replicas-to-write returns 1 and min-replicas-max-lag returns 10. INFO replication on the primary shows connected_slaves:1 but min_slaves_good_slaves:0:

slave0:ip=10.0.0.7,port=6379,state=online,offset=771002,lag=22

The single replica is connected but lagging 22 seconds — past the 10-second min-replicas-max-lag, so it doesn’t count as good, and with the threshold at 1 the primary blocks writes. On the replica, master_last_io_seconds_ago is climbing and the box’s CPU is pinned by a heavy BGSAVE that stalled replication apply.

The immediate fix was to relieve the replica (the BGSAVE finished / was rescheduled), after which lag fell under 10 seconds, min_slaves_good_slaves returned to 1, and writes resumed:

redis-cli -h 10.0.0.7 INFO replication | grep -E 'master_link_status|lag'   # lag back < 10
redis-cli SET healthcheck ok                                                # write succeeds

Longer term a second replica was added so a single lagging replica can no longer block all writes, and replica hosts were sized so persistence forks don’t stall apply.

Prevention Best Practices

• Deploy at least one more replica than min-replicas-to-write requires, so a single replica hiccup doesn’t halt writes.
• Set min-replicas-max-lag realistically for your network and replica load — too tight makes healthy replicas flap out of the “good” count.
• Monitor min_slaves_good_slaves and per-replica lag/master_link_status, and alert before they cross the threshold.
• Keep replica hosts sized for the write rate and offload heavy persistence so apply lag stays low.
• Treat min-replicas-to-write as a durability/availability tradeoff: only require replicas you actually run.
• Feed INFO replication into the free incident assistant, and browse more Redis guides.

Quick Command Reference

# The guard and how many replicas count as good
redis-cli CONFIG GET min-replicas-to-write
redis-cli CONFIG GET min-replicas-max-lag
redis-cli INFO replication | grep -E 'connected_slaves|min_slaves_good_slaves|slave[0-9]+:'

# Per-replica link health (run on the replica)
redis-cli -h <replica> INFO replication | grep -E 'master_link_status|master_last_io_seconds_ago'

# Full/partial resync counters
redis-cli INFO stats | grep -E 'sync_full|sync_partial_ok|sync_partial_err'

# Relax the guard only if you accept weaker durability
redis-cli CONFIG SET min-replicas-to-write 0

Conclusion

NOREPLICAS Not enough good replicas to write means the primary’s durability guard can’t find enough healthy, low-lag replicas. The typical root causes are:

1. A replica disconnected, dropping connected_slaves below the threshold.
2. Replicas lagging past min-replicas-max-lag, so they don’t count as good.
3. A threshold stricter than the deployed topology.
4. A just-completed failover with no replicas attached yet.

Don’t reflexively set min-replicas-to-write 0 — that silently drops the durability you configured. Restore replica health (INFO replication, min_slaves_good_slaves, per-replica lag/master_link_status), add enough replicas to survive one failing, and only relax the guard as a deliberate durability decision.