🚨 Redis Error Guide: 'NOGOODSLAVE No suitable replica to promote' — Fix Sentinel Failover

Overview

Redis Sentinel reports NOGOODSLAVE No suitable replica to promote when a master has failed (or was told to fail over) but Sentinel cannot find a replica healthy enough to promote. Sentinel filters candidates by connection state, replication freshness, and replica-priority; if none pass, the failover aborts and the master stays down.

The literal message you see (from SENTINEL FAILOVER or the Sentinel log):

(error) NOGOODSLAVE No suitable replica to promote

This is Sentinel refusing to promote a bad candidate rather than risk data loss or a split brain. The root cause is always on the replica side: they are disconnected, too far behind, explicitly excluded (replica-priority 0), or unreachable from Sentinel.

Symptoms

• A manual SENTINEL FAILOVER <master> returns NOGOODSLAVE.
• Automatic failover never completes; the master remains +sdown/+odown in Sentinel.
• SENTINEL replicas <master> shows replicas flagged disconnected or with large offset lag.

redis-cli -p 26379 SENTINEL FAILOVER mymaster

(error) NOGOODSLAVE No suitable replica to promote

Common Root Causes

1. All replicas are disconnected

Sentinel will not promote a replica it currently sees as disconnected.

redis-cli -p 26379 SENTINEL replicas mymaster | grep -A2 flags

flags
s_down,slave,disconnected

2. Replica priority is 0 (excluded from election)

A replica with replica-priority 0 is permanently ineligible to be promoted.

redis-cli -p 6380 CONFIG GET replica-priority

1) "replica-priority"
2) "0"

3. Replicas are too far behind (stale)

Replicas whose last valid replication was too long ago exceed Sentinel’s freshness threshold (10 * down-after-milliseconds).

redis-cli -p 6380 INFO replication | grep -E 'master_link_status|slave_repl_offset'

4. Sentinel cannot reach the replicas / no quorum

Network partition or misconfigured Sentinel means it cannot confirm a replica’s health.

redis-cli -p 26379 SENTINEL master mymaster | grep -A1 num-slaves

How to diagnose

Step 1: List what Sentinel sees for each replica

redis-cli -p 26379 SENTINEL replicas mymaster

Look at flags (want slave without s_down/disconnected), master-link-status, and the replication offset.

Step 2: Check each replica’s link to the master

redis-cli -p 6380 INFO replication | grep -E 'role|master_link_status|master_last_io_seconds_ago'

role:slave
master_link_status:down
master_last_io_seconds_ago:212

down or a large master_last_io_seconds_ago disqualifies the replica.

Step 3: Check replica-priority on every candidate

for p in 6380 6381; do echo "== $p =="; redis-cli -p $p CONFIG GET replica-priority; done

Any 0 there cannot be promoted.

Step 4: Read the Sentinel log for the abort reason

sudo journalctl -u redis-sentinel --no-pager | grep -iE 'failover|no-good-slave|selected-slave|not enough' | tail

Fixes

Restore replica connectivity to the master

Fix the network/auth so master_link_status:up, then Sentinel can select it.

redis-cli -p 6380 INFO replication | grep master_link_status   # want: up

Make at least one replica eligible

Set a non-zero priority (lower number = higher promotion preference):

redis-cli -p 6380 CONFIG SET replica-priority 100
redis-cli -p 6380 CONFIG REWRITE

Let replicas catch up before retrying

Wait until replication offsets converge, then retry the failover:

redis-cli -p 26379 SENTINEL FAILOVER mymaster

Verify Sentinel quorum and reachability

Ensure enough Sentinels agree and can see the replicas:

redis-cli -p 26379 SENTINEL ckquorum mymaster

OK 3 usable Sentinels. Quorum and failover authorization can be reached

What to watch out for

• replica-priority 0 is a deliberate “never promote me” flag (common for backup/analytics replicas). If every replica has it, no failover is ever possible — keep at least one promotable.
• Sentinel’s freshness filter is derived from down-after-milliseconds; overly aggressive timeouts can disqualify healthy-but-slightly-lagged replicas.
• After you fix connectivity, give Sentinel a few seconds to re-classify the replica before retrying SENTINEL FAILOVER.
• NOGOODSLAVE protects you from promoting a stale node — do not work around it by forcing promotion on a replica that is far behind.

Related

• Redis Error: ‘NOREPLICAS Not enough good replicas to write’
• Redis Error: ‘MASTERDOWN Link with MASTER is down’
• Redis Error: replica stuck in a full resync loop

Paste the Sentinel log into the free incident assistant, and browse more Redis guides.