Fix Redis Sentinel 'NOGOODSLAVE No suitable slave to promote' Failover Error

TL;DR

Redis Sentinel can't find a replica to promote during failover. The three most common causes: all replicas have slave-priority 0, replicas are too far behind in replication offset, or replicas aren't actually connected. Run SENTINEL replicas <master-name> to see exactly which condition you're hitting.

What Triggers This Error

When the master goes down, Sentinel scores its known replicas to pick a promotion candidate. Score too low on any eligibility check? That replica is skipped.

If every replica fails, you get:

NOGOODSLAVE No suitable slave to promote

Sentinel logs this in /var/log/redis/sentinel.log and aborts. Your cluster stays down until you intervene manually.

A replica gets disqualified if any of these are true:

• slave-priority is 0 — explicitly excluded from promotion
• Replication lag too high — offset is too far behind the master's last known position
• Replica is disconnected — Sentinel can't reach it or it shows disconnected in its info
• Replica is down — crashed or unreachable by any Sentinel node

Step 1: See What Sentinel Thinks

Start here before anything else. Connect to any running Sentinel and pull the replica list:

redis-cli -p 26379 SENTINEL replicas mymaster

For each replica, these are the fields that matter:

flags: slave
role-reported: slave
slave-priority: 100
replica-announced: 1
last-ok-ping-reply: 312
slave-repl-offset: 1048576
master-link-status: ok

Things that indicate trouble:

• slave-priority: 0 → excluded from promotion (see Fix 1)
• master-link-status: err → replica isn't syncing with master (see Fix 3)
• flags: disconnected or flags: s_down → Sentinel considers this replica dead
• last-ok-ping-reply in the thousands of ms → network problem between Sentinel and replica

Fix 1: slave-priority Is Set to 0

Priority 0 is a deliberate signal: "never promote this replica." It's common on nodes used only for backups or analytics — replicas you don't want taking live traffic. The problem hits when every replica has this set. Nobody's left to promote.

Check each replica's current priority:

redis-cli -h 192.168.1.11 -p 6380 CONFIG GET slave-priority

If it returns 0, bump it to the default:

redis-cli -h 192.168.1.11 -p 6380 CONFIG SET slave-priority 100

That change takes effect immediately but won't survive a restart. Persist it by adding this line to /etc/redis/redis.conf on that replica:

slave-priority 100

On Redis 5.0+, either name works:

replica-priority 100

Fix 2: Replica Is Lagging Behind

There's a min-slaves-max-lag threshold in Sentinel (also written as min-replicas-max-lag in newer configs). Any replica whose replication lag exceeds this many seconds gets disqualified. The default is 10 seconds.

Check the current threshold directly on the master:

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

Then check actual lag on the replica:

redis-cli -h 192.168.1.11 -p 6380 INFO replication

Compare master_last_io_seconds_ago against the threshold. If lag is consistently high — say, 30–60 seconds — you have two options:

Option A: Raise the lag threshold on Sentinel temporarily while you track down the root cause:

redis-cli -p 26379 SENTINEL set mymaster min-slaves-max-lag 60

Option B: Fix why the replica is lagging. Common culprits are network saturation between master and replica, slow disk I/O on HDDs under heavy write load, or an undersized replica instance. Find the bottleneck and let the replica catch up before the next failover event.

Fix 3: Replica Is Disconnected

master-link-status: err means the replica lost contact with the master before or during the outage. If the master is dead, you can't reconnect the replica to it — point it at a healthy node first.

Force the replica to sync from a specific host:

redis-cli -h 192.168.1.11 -p 6380 REPLICAOF 192.168.1.10 6379

Mid-failover and Sentinel still won't pick a winner? Trigger it manually:

redis-cli -p 26379 SENTINEL failover mymaster

Still failing? Promote the replica yourself:

# Make it a standalone master
redis-cli -h 192.168.1.11 -p 6380 REPLICAOF NO ONE

# Confirm it took
redis-cli -h 192.168.1.11 -p 6380 INFO replication

Then repoint remaining replicas at the new master:

redis-cli -h 192.168.1.12 -p 6380 REPLICAOF 192.168.1.11 6380

Fix 4: Stale Sentinel State

Sentinel tracks replicas internally, and it doesn't always clean up after decommissions. Remove a replica without telling Sentinel, and that ghost entry sticks around — interfering with failover decisions. Force a reset:

redis-cli -p 26379 SENTINEL RESET mymaster

Run this on every Sentinel node. It wipes the internal state and re-learns the current topology from scratch. Wait a few seconds, then verify the list is clean:

redis-cli -p 26379 SENTINEL replicas mymaster

Verifying the Fix

Once you've applied a fix, test it. Don't wait for the next real outage to find out it didn't work.

Trigger a manual failover:

redis-cli -p 26379 SENTINEL failover mymaster

Watch Sentinel's log live in a second terminal:

tail -f /var/log/redis/sentinel.log

A clean failover produces these lines in sequence:

+selected-slave slave 192.168.1.11:6380 @ mymaster 192.168.1.10 6379
+failover-state-send-slaveof-noone slave 192.168.1.11:6380 @ mymaster
+promoted-slave slave 192.168.1.11:6380 @ mymaster

Confirm the new master is actually responding:

redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# Returns: ["192.168.1.11", "6380"]

redis-cli -h 192.168.1.11 -p 6380 PING
# Returns: PONG

Preventing This in Production

Keep at least two eligible replicas — meaning slave-priority above 0 — in every Sentinel-managed cluster. One eligible replica is a single point of failure for your entire failover path.

Using a backup-only replica with priority 0 is fine. Just make sure at least one other replica can take over if things go sideways.

Add an alert that fires when the eligible replica count hits zero:

redis-cli -p 26379 SENTINEL replicas mymaster | grep -c 'slave-priority'

Also audit your sentinel.conf — these are the values that catch teams off guard most often:

sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel min-replicas-to-write 1
sentinel min-replicas-max-lag 10

The quorum of 2 means two Sentinels must agree the master is down before failover kicks off. The 5-second down-after-milliseconds and 60-second failover-timeout are reasonable starting points — tune them based on your network latency and how much downtime you can tolerate.