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.
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.
Connect to your Sentinel instance and query the master status to see how many replicas Sentinel recognizes:
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL masters
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL slaves mymasterLook 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.
Ensure all expected Redis replica instances are actually running and accessible:
# 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.
Connect to each replica and verify it is properly replicating from the master:
redis-cli -h <replica-host> -p <replica-port> INFO replicationLook 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:
# Check network connectivity
ping <master-host>
# Verify AUTH if configured
redis-cli -h <replica-host> -p <replica-port> -a <password> PINGCheck the slave-priority setting on each replica. A priority of 0 prevents failover promotion:
redis-cli -h <replica-host> -p <replica-port> CONFIG GET slave-priorityIf the result is 0, set it to a normal value like 100:
redis-cli -h <replica-host> -p <replica-port> CONFIG SET slave-priority 100For persistence across restarts, update the replica's redis.conf file:
slave-priority 100Then restart the replica to apply the change.
If your Redis deployment uses passwords, ensure Sentinel is configured with the correct credentials:
Check your sentinel.conf for the sentinel auth-pass directive:
sentinel auth-pass mymaster <password>Verify the password matches the master and all replicas' requirepass settings:
redis-cli -h <replica-host> -p <replica-port> -a <password> CONFIG GET requirepassIf passwords don't match, update them and restart Sentinel and replicas:
# 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> PINGOnce replicas are running, reachable, and have priority > 0, attempt failover again:
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL failover mymasterMonitor the failover progress:
redis-cli -h <sentinel-host> -p <sentinel-port> SENTINEL mastersWait 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.
If replicas became slaves of each other or the replication chain is broken, reset them to properly replicate from the master:
# 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 replicationRepeat for all replicas. Then verify all show master_link_status:up and have identical slave_repl_offset values.
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.
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