How to fix NOGOODSLAVE no-good-slave in Redis

RedisADVANCEDHIGHUpdated Dec 29, 2025· 171 views

The "NOGOODSLAVE No good slave available for failover" error occurs in Redis Sentinel when attempting a failover but no healthy replica instances are available to promote to master. This typically happens when all replicas are offline, lagging, or unreachable.

Quick fix

Fixes NOGOODSLAVE

redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL masters
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL slaves mymaster
  1. Check Sentinel status and replica availability
  2. Verify replica instances are running
  3. Check replica replication status
  4. Verify replica slave-priority is not 0
redis — error
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL masters
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL slaves mymaster
NOGOODSLAVE no-good-slave

What this error means

This error is triggered by Redis Sentinel during a manual or automatic failover operation when it cannot find a suitable replica to promote to master. Sentinel requires at least one replica that meets the failover criteria: the replica must be reachable, have acceptable replication lag, have a priority greater than 0, and be capable of becoming a new master. When Sentinel initiates a failover (either automatically after detecting master failure or via the SENTINEL failover command), it scans all connected replicas to identify candidates for promotion. If no replicas meet the criteria, the failover is aborted with the NOGOODSLAVE error, leaving your Redis deployment without a master and blocking all client operations.

Typical symptoms

  • Failover attempts fail with the error message "NOGOODSLAVE No suitable slave to promote" or "NOGOODSLAVE No good slave available for failover"
  • Manual SENTINEL failover command returns the error instead of promoting a replica
  • After master failure, Sentinel cannot automatically promote any replica to master
  • All client connections drop because no writable master is available
  • Replicas show as disconnected or offline in Sentinel status output
  • Replication shows 0 connected slaves when running INFO replication on the master

Common causes

  1. All replica instances are offline, crashed, or have exited unexpectedly
  2. Network connectivity between Sentinel and replicas is broken or firewall rules block communication
  3. All replicas have slave-priority set to 0, which explicitly disqualifies them from failover promotion
  4. Replica authentication fails due to incorrect or mismatched passwords configured via masterauth
  5. All replicas have excessive replication lag exceeding acceptable thresholds during failover evaluation
  6. Sentinel leader election failed or the elected sentinel cannot reach and communicate with replicas
  7. Replicas became slaves of each other or formed a broken replication chain instead of replicating from the master

How to fix "NOGOODSLAVE no-good-slave"

1Check Sentinel status and replica availability

Connect to your Sentinel instance and query the master status to see how many replicas Sentinel recognizes:

bash
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL masters
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL slaves mymaster

Look for the num-slaves field in the output. If it shows 0, no replicas are visible to Sentinel. Also check each replica's status field - it should show ok or disconnected.

If replicas show as disconnected, they are unreachable from Sentinel and cannot be promoted.

2Verify replica instances are running

Ensure all expected Redis replica instances are actually running and accessible:

bash
# Check if each replica is running
redis-cli -h <replica1-host> -p <replica-port> PING
redis-cli -h <replica2-host> -p <replica-port> PING

# If PING fails, the replica is either down or unreachable
# Restart any failed replicas:
systemctl restart redis-server
# OR if using Docker:
docker restart <replica-container>

If a replica is down, start or restart it. If it fails to start, check its logs for configuration or disk space errors.

3Check replica replication status

Connect to each replica and verify it is properly replicating from the master:

bash
redis-cli -h <replica-host> -p <replica-port> INFO replication

Look for:
- role:slave - Confirms this is a replica
- master_link_status:up - Replica is connected to the master
- master_replid and slave_repl_offset - Replication is progressing

If master_link_status:down, the replica lost connection to the master. Verify network connectivity and authentication:

bash
# Check network connectivity
ping <master-host>

# Verify AUTH if configured
redis-cli -h <replica-host> -p <replica-port> -a <password> PING
4Verify replica slave-priority is not 0

Check the slave-priority setting on each replica. A priority of 0 prevents failover promotion:

bash
redis-cli -h <replica-host> -p <replica-port> CONFIG GET slave-priority

If the result is 0, set it to a normal value like 100:

bash
redis-cli -h <replica-host> -p <replica-port> CONFIG SET slave-priority 100

For persistence across restarts, update the replica's redis.conf file:

bash
slave-priority 100

Then restart the replica to apply the change.

5Verify Sentinel can authenticate with replicas

If your Redis deployment uses passwords, ensure Sentinel is configured with the correct credentials:

Check your sentinel.conf for the sentinel auth-pass directive:

bash
sentinel auth-pass mymaster <password>

Verify the password matches the master and all replicas' requirepass settings:

bash
redis-cli -h <replica-host> -p <replica-port> -a <password> CONFIG GET requirepass

If passwords don't match, update them and restart Sentinel and replicas:

bash
# Update sentinel.conf and restart Sentinel
systemctl restart redis-sentinel

# Verify all replicas can authenticate
redis-cli -h <replica-host> -p <replica-port> -a <password> PING
6Attempt manual failover after repairs

Once replicas are running, reachable, and have priority > 0, attempt failover again:

bash
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL failover mymaster

Monitor the failover progress:

bash
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL masters

Wait for the master state to change from failover to ok. If NOGOODSLAVE error appears again, review the error logs on Sentinel and all replicas for additional clues.

7Reset a broken replication chain if needed

If replicas became slaves of each other or the replication chain is broken, reset them to properly replicate from the master:

bash
# On each replica, break replication
redis-cli -h <replica-host> -p <replica-port> SLAVEOF NO ONE

# Wait a few seconds for Sentinel to detect the change
sleep 3

# Then restore replication to the master
redis-cli -h <replica-host> -p <replica-port> SLAVEOF <master-host> <master-port>

# Wait for sync to complete
redis-cli -h <replica-host> -p <replica-port> INFO replication

Repeat for all replicas. Then verify all show master_link_status:up and have identical slave_repl_offset values.

Advanced notes

Failover Configuration:
Redis Sentinel evaluates replicas for promotion based on:
- Reachability (Sentinel must be able to contact the replica)
- slave-priority setting (must be > 0)
- Replication lag (replica offset should be close to master)
- Configuration state (no conflicting cluster or other settings)

Master-Slave Replication Chain Issues:
If Sentinel elects a new master but other sentinels fail to update their configuration, they may send conflicting SLAVEOF commands. This causes:
- Both instances becoming slaves of each other (circular replication)
- New master being marked +ODOWN (master down)
- Subsequent NOGOODSLAVE errors on retry

Solution: Manually break replication with SLAVEOF NO ONE, wait for Sentinel to stabilize, then restart replication to the proper master.

Kubernetes Deployments:
When using Redis Operator or Helm charts, check that:
- All replica pods are scheduled and running (not pending or CrashLoopBackOff)
- Sentinel can reach replica pods via DNS names (e.g., redis-replica-0.redis-headless.default.svc)
- NetworkPolicy rules allow Sentinel → Replica communication
- Replica priority is configured in the Redis custom resource

High Quorum Sentinel Setups:
Setting Sentinel quorum too high (e.g., quorum 3 with only 2 sentinels) or slave-priority 0 on all replicas will consistently cause NOGOODSLAVE errors. Verify sentinel-config or sentinel.conf has appropriate values for your deployment size.

Frequently asked questions

What does "NOGOODSLAVE" mean?
This error is triggered by Redis Sentinel during a manual or automatic failover operation when it cannot find a suitable replica to promote to master. Sentinel requires at least one replica that meets the failover criteria: the replica must be reachable, have acceptable replication lag, have a priority greater than 0, and be capable of becoming a new master. When Sentinel initiates a failover (either automatically after detecting master failure or via the SENTINEL failover command), it scans all connected replicas to identify candidates for promotion.
How do I fix "NOGOODSLAVE"?
The "NOGOODSLAVE No good slave available for failover" error occurs in Redis Sentinel when attempting a failover but no healthy replica instances are available to promote to master. This typically happens when all replicas are offline, lagging, or unreachable.
What causes "NOGOODSLAVE"?
All replica instances are offline, crashed, or have exited unexpectedly Network connectivity between Sentinel and replicas is broken or firewall rules block communication All replicas have slave-priority set to 0, which explicitly disqualifies them from failover promotion
Is the "NOGOODSLAVE" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading