The "NOREPLICAS Not enough good replicas to write" error occurs when a Redis master instance rejects write operations because insufficient replicas are available or synchronized. This is a replication safety feature that prevents data loss.
This error is triggered by Redis's data safety mechanism when writing to a replicated Redis deployment. The master instance maintains a minimum replica threshold (configured via min-replicas-to-write and min-replicas-max-lag) to ensure data durability. When the number of synchronized replicas falls below the required threshold, or when connected replicas have excessive replication lag, the master refuses new write operations and returns the NOREPLICAS error. This protects against split-brain scenarios and limits the window of potential data loss. Without this safeguard, writes could be accepted by the master but lost if it crashes before replicating them to surviving replicas.
Connect to your Redis master and inspect the replication status to identify disconnected or lagged replicas:
redis-cli -h <master-host> -p <master-port> INFO replicationLook for:
- role:master - Confirms you are on the master
- connected_slaves - Number of currently connected replicas
- slave0, slave1, etc. - Details for each replica including offset and lag
If connected_slaves is less than your min-replicas-to-write setting, that is your problem.
Check if replicas can reach the master and authenticate properly:
# On each replica, verify it can connect to the master
redis-cli -h <master-host> -p <master-port> PING
# Check the replica's replication status
redis-cli -h <replica-host> -p <replica-port> INFO replicationLook for master_link_status:up on replicas. If it shows down, the replica cannot sync.
If replicas fail to authenticate:
- Verify AUTH credentials are identical on master and replicas
- Check that masterauth is set correctly in replica config
To recover write access immediately while investigating, reduce the minimum replica threshold (use with caution):
redis-cli -h <master-host> -p <master-port> CONFIG SET min-replicas-to-write 0This disables the replica requirement temporarily. Writes will be accepted even if replicas are down, but you lose replication safety.
After fixing underlying issues, restore the setting:
redis-cli -h <master-host> -p <master-port> CONFIG SET min-replicas-to-write 1For persistence, update redis.conf:
min-replicas-to-write 1
min-replicas-max-lag 10Once you have reduced the replica requirement, address the root cause:
For disconnected replicas:
- Restart the replica instance with the redis-cli SHUTDOWN command, then start it again
- Verify network connectivity between master and replica
- Check firewall rules allowing TCP communication on the Redis port
For replicas with excessive lag:
- Check replica resource usage (CPU, memory, disk I/O) - upgrade if necessary
- Verify network bandwidth between master and replicas
- Reduce master write load if possible
- Increase min-replicas-max-lag if brief lag spikes are acceptable:
redis-cli -h <master-host> CONFIG SET min-replicas-max-lag 20Once all replicas are healthy and connected:
# Verify all replicas are in sync
redis-cli -h <master-host> -p <master-port> INFO replication
# Set appropriate thresholds for your deployment
# Require at least 1 replica with lag <= 10 seconds
redis-cli -h <master-host> CONFIG SET min-replicas-to-write 1
redis-cli -h <master-host> CONFIG SET min-replicas-max-lag 10
# For Kubernetes deployments with multiple replicas:
redis-cli -h <master-host> CONFIG SET min-replicas-to-write 2
redis-cli -h <master-host> CONFIG SET min-replicas-max-lag 10Persist these settings in your redis.conf or ConfigMap.
Configuration Details:
- min-replicas-to-write (formerly min-slaves-to-write): Number of replicas that must acknowledge writes. Default: 0 (disabled).
- min-replicas-max-lag (formerly min-slaves-max-lag): Maximum replication lag in seconds. Default: 10 seconds.
Kubernetes/Container Deployments:
In Kubernetes with Redis Helm charts, NOREPLICAS errors often occur during node recycling when replicas are temporarily unavailable. Solutions include:
- Setting min-replicas-to-write 0 if write availability is more important than replication safety
- Using pod disruption budgets to ensure at least one replica is always running
- Increasing timeouts and lag thresholds during infrastructure maintenance windows
AWS ElastiCache:
If using AWS ElastiCache for Redis, check the "Replication" tab in the console to see replica health and sync status. Ensure automatic failover is configured if you want master promotion during outages.
Large Datasets:
With very large datasets (50GB+), initial replication sync can take many seconds. Increase min-replicas-max-lag accordingly or temporarily disable the check during initial setup.
ERR fsync error
How to fix "ERR fsync error" in Redis
CLUSTERDOWN The cluster is down
How to fix 'CLUSTERDOWN The cluster is down' in Redis
ERR Job for redis-server.service failed because a timeout was exceeded
Job for redis-server.service failed because a timeout was exceeded
ERR Unbalanced XREAD list of streams
How to fix "ERR Unbalanced XREAD list" in Redis
ERR syntax error
How to fix "ERR syntax error" in Redis