TL;DR
Redis Sentinelがフェイルオーバー時に昇格させるレプリカを見つけられません。最もよくある原因は3つです：すべてのレプリカにslave-priority 0が設定されている、レプリカのレプリケーションオフセットが大幅に遅れている、またはレプリカが実際に接続されていない、のいずれかです。SENTINEL replicas <master-name>を実行して、どの状況に該当するか確認してください。
このエラーが発生する原因
マスターがダウンすると、Sentinelは既知のレプリカにスコアを付けて昇格候補を選びます。いずれかの適格性チェックでスコアが低すぎると、そのレプリカはスキップされます。
すべてのレプリカが失格になると、以下のエラーが発生します：
NOGOODSLAVE No suitable slave to promote
Sentinelはこれを/var/log/redis/sentinel.logに記録して処理を中止します。手動で介入するまで、クラスターはダウンしたままになります。
以下のいずれかの条件に該当するレプリカは失格となります：
- slave-priorityが0 — 昇格対象から明示的に除外されている
- レプリケーションラグが大きすぎる — オフセットがマスターの最後の既知位置から大幅に遅れている
- レプリカが切断されている — Sentinelが到達できないか、infoに
disconnectedと表示されている - レプリカがダウンしている — クラッシュしているか、いずれのSentinelノードからも到達できない
ステップ1：Sentinelの認識を確認する
他の手順の前にまずここから始めます。稼働中のいずれかのSentinelに接続してレプリカの一覧を取得します：
redis-cli -p 26379 SENTINEL replicas mymaster
各レプリカについて、確認すべきフィールドは以下のとおりです：
flags: slave
role-reported: slave
slave-priority: 100
replica-announced: 1
last-ok-ping-reply: 312
slave-repl-offset: 1048576
master-link-status: ok
問題を示す兆候：
slave-priority: 0→ 昇格対象から除外されている（修正1を参照）master-link-status: err→ レプリカがマスターと同期していない（修正3を参照）flags: disconnectedまたはflags: s_down→ Sentinelがこのレプリカを死亡とみなしているlast-ok-ping-replyが数千ミリ秒 → SentinelとレプリカのネットワークにProblemがある
修正1：slave-priorityが0に設定されている場合
プライオリティ0は「このレプリカを絶対に昇格させない」という明示的なシグナルです。バックアップやアナリティクス専用のノード——ライブトラフィックを受け付けさせたくないレプリカ——でよく使われます。問題が起きるのは、すべてのレプリカにこれが設定されている場合です。昇格させるものが誰もいなくなります。
各レプリカの現在のプライオリティを確認します：
redis-cli -h 192.168.1.11 -p 6380 CONFIG GET slave-priority
0が返ってきた場合、デフォルト値に変更します：
redis-cli -h 192.168.1.11 -p 6380 CONFIG SET slave-priority 100
この変更はすぐに有効になりますが、再起動後には失われます。そのレプリカの/etc/redis/redis.confに以下の行を追加して永続化します：
slave-priority 100
Redis 5.0以降では、どちらの名前も使用できます：
replica-priority 100
修正2：レプリカが遅れている場合
Sentinelにはmin-slaves-max-lag閾値があります（新しい設定ではmin-replicas-max-lagとも書かれます）。レプリケーションラグがこの秒数を超えたレプリカは失格となります。デフォルトは10秒です。
マスター上で現在の閾値を直接確認します：
redis-cli CONFIG GET min-replicas-max-lag
次に、レプリカの実際のラグを確認します：
redis-cli -h 192.168.1.11 -p 6380 INFO replication
master_last_io_seconds_agoを閾値と比較します。ラグが継続的に高い場合（例：30〜60秒）、2つの選択肢があります：
オプションA：根本原因を調査する間、Sentinelのラグ閾値を一時的に引き上げます：
redis-cli -p 26379 SENTINEL set mymaster min-slaves-max-lag 60
オプションB：レプリカが遅れている原因を修正します。よくある原因としては、マスターとレプリカ間のネットワーク飽和、大量の書き込み負荷下でのHDDの低速なディスクI/O、またはレプリカインスタンスのスペック不足などが挙げられます。ボトルネックを特定し、次のフェイルオーバーイベントの前にレプリカを追いつかせてください。
修正3：レプリカが切断されている場合
master-link-status: errは、障害発生前または発生中にレプリカがマスターとの接続を失ったことを意味します。マスターが死んでいる場合、そのマスターにレプリカを再接続することはできません——まず正常なノードに向けてください。
レプリカを特定のホストから強制同期させます：
redis-cli -h 192.168.1.11 -p 6380 REPLICAOF 192.168.1.10 6379
フェイルオーバーの途中でSentinelが勝者を選ばない場合、手動でトリガーします：
redis-cli -p 26379 SENTINEL failover mymaster
それでも失敗する場合、レプリカを自分で昇格させます：
# スタンドアロンマスターにする
redis-cli -h 192.168.1.11 -p 6380 REPLICAOF NO ONE
# 変更を確認する
redis-cli -h 192.168.1.11 -p 6380 INFO replication
次に、残りのレプリカを新しいマスターに向けます：
redis-cli -h 192.168.1.12 -p 6380 REPLICAOF 192.168.1.11 6380
修正4：Sentinelの状態が古い場合
Sentinelはレプリカを内部で追跡しており、廃止後のクリーンアップが常に行われるわけではありません。Sentinelに通知せずにレプリカを削除すると、そのゴーストエントリが残り続け——フェイルオーバーの判断に干渉します。強制リセットを実行します：
redis-cli -p 26379 SENTINEL RESET mymaster
すべてのSentinelノードでこれを実行します。内部状態を消去し、現在のトポロジーを最初から再学習します。数秒待ってから、リストがクリーンになっていることを確認します：
redis-cli -p 26379 SENTINEL replicas mymaster
修正の確認
修正を適用したら、テストを行います。次の実際の障害まで待って、修正が効かなかったことを知ることのないようにしてください。
手動フェイルオーバーをトリガーします：
redis-cli -p 26379 SENTINEL failover mymaster
別のターミナルでSentinelのログをリアルタイムに監視します：
tail -f /var/log/redis/sentinel.log
正常なフェイルオーバーでは、以下の行が順番に出力されます：
+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
新しいマスターが実際に応答していることを確認します：
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# 返り値: ["192.168.1.11", "6380"]
redis-cli -h 192.168.1.11 -p 6380 PING
# 返り値: PONG
本番環境での予防策
すべてのSentinel管理クラスターで、少なくとも2つの適格なレプリカ——つまりslave-priorityが0より大きいもの——を維持してください。適格なレプリカが1つだけでは、フェイルオーバー経路全体の単一障害点になります。
プライオリティ0のバックアップ専用レプリカを使用すること自体は問題ありません。ただし、万が一の際に引き継げるレプリカが少なくとも1つあることを確認してください。
適格なレプリカ数がゼロになった際に発火するアラートを追加します：
redis-cli -p 26379 SENTINEL replicas mymaster | grep -c 'slave-priority'
また、sentinel.confを監査してください——チームが見落としがちな値は以下のとおりです：
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
クォーラム2は、フェイルオーバーが開始される前に2つのSentinelがマスターのダウンに同意する必要があることを意味します。5秒のdown-after-millisecondsと60秒のfailover-timeoutは妥当な出発点です——ネットワーク遅延と許容できるダウンタイムに基づいて調整してください。