想定されるシナリオRedisの高可用性（HA）構成のトラブルシューティングを行っており、表面上はすべて安定しているように見えます。しかし、Sentinelノードに対してマスターのアドレスを照会した瞬間、システムから拒否されます。IPを返す代わりに、CLIは驚くほどぶっきらぼうなエラーを返します。
127.0.0.1:26379> SENTINEL get-master-addr-by-name production-cluster
(error) IDONTKNOW No such master with that name
Sentinelはここで言葉通りの意味を伝えています。このエラーは、コマンドで指定したマスター名が、Sentinelプロセスが現在アクティブメモリに保持している名前と一致しない場合に発生します。
不一致箇所の特定IDONTKNOW というレスポンスは、指定した文字列がシステムにとって「未知」であることを意味します。設定がどこで食い違っているのかを突き止める方法は以下の通りです。
1. 監視対象マスターの確認まずは、Sentinelが実際に何を監視しているのかを確認することから始めましょう。SENTINEL masters コマンドが信頼できる情報源です。このコマンドは、その特定のノードが現在追跡しているすべてのマスターグループをリストアップします。
127.0.0.1:26379> SENTINEL masters
出力結果の name フィールドを確認してください。アプリ側では production-cluster を期待しているのに、マスター名がまだ mymaster（Redisのデフォルト）のままになっていることがよくあります。prod_cluster と prod-cluster のような、わずかなタイポ（打ち間違い）であっても接続は切断されます。
2. sentinel.conf ファイルの検査もし masters コマンドが空のリストを返した場合、設定が正しく読み込まれていません。設定ファイル（通常は /etc/redis/sentinel.conf）を開き、監視設定の行を探します。
# 形式: sentinel monitor <マスター名> <ip> <ポート> <クォーラム>
sentinel monitor redis-main 10.0.0.15 6379 2
この行がないか、先頭に # が付いてコメントアウトされている場合、Sentinelはそのマスターを完全に無視します。その結果、照会するたびに IDONTKNOW エラーが発生します。
3. 大文字と小文字の区別Redis Sentinelの名前は大文字と小文字を区別します。設定で prod_db と定義されているのに PROD_DB で照会すると失敗します。また、設定ファイルを手動で編集した場合は、末尾の目に見えないスペースにも注意してください。古いバージョンの Redis では、名前の後のスペースを文字列の一部として扱うことがあります。
エラーの修正方法不一致の原因を特定したら、次の3つのアプローチのいずれかを使用して解決します。
方法 A: クエリ側を更新するもし SENTINEL masters の結果、マスター名が mymaster であることが判明したなら、最も早い修正方法はアプリケーションの環境変数を更新することです。コードを既存の設定に合わせます。
# これは失敗します
SENTINEL get-master-addr-by-name redis-prod
# これは動作します（実際の設定に合わせる）
SENTINEL get-master-addr-by-name mymaster
方法 B: マスターを動的に登録するマスターの不足を修正するためにサービスを再起動する必要はありません。CLIを使用して、新しいマスターグループの監視を開始するようSentinelにリアルタイムで指示できます。これは、ダウンタイムなしでノードを追加する場合に便利です。
127.0.0.1:26379> SENTINEL MONITOR production-db 10.0.0.20 6379 2
これを実行すると、通常 Sentinel は自身の設定ファイルを自動的に書き換えます。ただし、再起動後も変更が保持されるよう、後で手動で sentinel.conf を確認して、変更が永続化されているか確認する習慣をつけるのが良いでしょう。
方法 C: 設定ファイルを修正する設定ファイル内の名前が明らかに間違っている場合は、それを修正してサービスを再起動します。これが、クラスター内のすべてのノードの同期を保つための最もクリーンな方法です。
# 設定を編集
sudo nano /etc/redis/sentinel.conf
# 行を更新:
sentinel monitor production-db 10.0.0.20 6379 2
# サービスを再起動
sudo systemctl restart redis-sentinel
検証特定のマスター名の詳細をリクエストして、修正を確認します。エラーではなく、詳細なキーと値のリストが表示されるはずです。
127.0.0.1:26379> SENTINEL master production-db
もし flags フィールドに master と表示されていれば、ノードは正常です。最後に、アドレス解決コマンドを実行して、アプリケーションがIPを見つけられることを確認します。
127.0.0.1:26379> SENTINEL get-master-addr-by-name production-db
1) "10.0.0.20"
2) "6379"