How to fix NOGOODSLAVE no-good-slave in Redis

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 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.

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 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:

# Check network connectivity
ping <master-host>

# Verify AUTH if configured
redis-cli -h <replica-host> -p <replica-port> -a <password> PING

Check 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-priority

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

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

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

slave-priority 100

Then 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 requirepass

If 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> PING

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

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

Monitor the failover progress:

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.

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 replication

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