Redis Clausterクラスタの主は切り替えられたピットとピットを踏んでから埋めます。
プロジェクトの原因でRedis Clausterを採用しました。3主3従、1台のホスト1主1従、クラスター情報は以下の通りです。
10.135.255.72：20011>cluster nodes
7 b 662 b 36489 a 6240 a 21 d 1 cf 7 b 04 b 84019254 b 63 10.135.255.74：20012 slate 85 c 78164 a 4465 f 22466 cab 226 c 68 f 0 157239581903 connected
61c 3 e 1 a 640 e 71f 4801 d 850 c 901 dd 33 f 0 b 4 f 6876 d 10.135.255.73:20012 slaave 8 e 3491125 e 10533958 dd 750 d 0 b 0 a 4 d 90 1572392300 connected
85 c 78164 a 448 fb 9965 e 22447429 a 56 cab 226 c 68 f 10.135.255.73:20011 master-0 157239581999 connected 5461-10922
8 e 3491125 e 10333958 dd 752 ee 0 d 0 a 410 d 2 d 90 10.135.255.72:20011 myself、master-0 connected 0-5460
92 eadfb 6 a cbd 0 db 74 a 8 b 8860286 a 7 f 63 abce140 e 10.135.255.74:20011 master-0 157239581799 connected 10923-6383
7084 c 1 d 7950 b 83 abc 1 e 4419500 e 1 c 24 a 9 fa108 e 7 10.135.255.72:20012 slate 92 eadfb 6 a cbd 0 db 8860286 a 7 f 63 abce140 e 0 1572391499 connected
Redis Clausterは運転してから、主従関係の自動切換がよく発生します。例えば、10.135.255.74：20012はmasterになります。10.135.255.73：20011はslaveになります。そうすると、10.135.255.74：20011と10.135.255.74：20012はダブルマスターになります。このように、もし10.135.255.74のホストマシンが発生したら、マスター2は使えなくなります。cluster down（ps：redis clusterの半分以上のmasterが故障してcluster downを招きます）を招きます。この問題はプロジェクトチームが長い間悩んでいますが、根本的な原因が見つからないです。
その後、何度も資料を調べましたが、redis.co nfのクラスタノードのタイムアウト時定数cluster-node-timeoutの構成は2000（2秒）です。ここでは、このパラメータの役割を簡単に説明します。
一、ノード失効検査
1.クラスタでは、あるノードが他のノードにPINGコマンドを送信したが、対象ノードが所与のタイミングでPINGコマンドの返信を返していない場合、コマンドを送信するノードは、対象ノードをPFAILとしてマークする。
ノードの返信を待つ時間制限はノードタイムアウト時間制限といい、ノードオプションです。
二、クラスタ状態検出
クラスタが構成変化が発生するたびに（おそらく、ハッシュスロット更新であり、あるノードが失効状態に入るかもしれない）、クラスタ内の各ノードは、その知っているノードをスキャンする（scan）。
設定が完了すると、クラスタは二つの状態の中の一つになります。
FAIL：クラスタが正常に動作しなくなり、クラスタ内のノードが失効状態に入ると、クラスタはコマンド要求を処理できなくなり、各コマンド要求に対して、クラスタノードはエラー応答を返す。
OK：クラスタは正常に動作し、全部の16384個のスロットノードを処理します。FAIL状態としてマークされているものは一つもありません。
ノードから選挙する
あるマスタノードがFAIL状態に入ると、このマスタノードがノードから一つ以上存在すると、その中の一つはノードからマスタノードにアップグレードされ、他はノードからこの新しいマスタノードのコピーを開始する。
実際の生産使用過程では、ネットワークの時間遅延またはCusterの一部のノードが持続化しているため、AOF書き換え、Master-slavieの同期データなどの時間のかかる動作は、ノード検出のタイムアウト（>20000 ms）を発生し、ノード検出が鋭敏すぎることを避けるために、複数の調整実践を経て、本プロジェクトの実際の生産環境において、cluster-node-timeoutを12000 msに調整した後に、比較的に安定していて、主が自動的に切り替わることが容易ではありません。本当のmaterノードの本体のあたご機の後で、slaaveは迅速に主に選挙することができて、redis clusterが利用できることを保証します。
補足：一回のRedisを覚えて、主に故障を切り替えて解決します。
問題の説明:
仮想マシンには主二が三哨兵から配置されています。本体のあたごは自動的に1台がマシンからホストに切り替わりました。再起動前のホストは新しいホストに接続できませんでした。
解決方法：
確認したところ、古いホストは新しいスレーブマシンに接続するパスワードが設定されていませんでした。
次の中に接続パスワードを設定して、再度redisサービスを再開します。
再起動後、本体の接続状態が正常に表示され、問題が解決されます。
以上は個人の経験ですので、参考にしていただければと思います。間違いがあったり、完全に考えていないところがあれば、教えてください。
10.135.255.72：20011>cluster nodes
7 b 662 b 36489 a 6240 a 21 d 1 cf 7 b 04 b 84019254 b 63 10.135.255.74：20012 slate 85 c 78164 a 4465 f 22466 cab 226 c 68 f 0 157239581903 connected
61c 3 e 1 a 640 e 71f 4801 d 850 c 901 dd 33 f 0 b 4 f 6876 d 10.135.255.73:20012 slaave 8 e 3491125 e 10533958 dd 750 d 0 b 0 a 4 d 90 1572392300 connected
85 c 78164 a 448 fb 9965 e 22447429 a 56 cab 226 c 68 f 10.135.255.73:20011 master-0 157239581999 connected 5461-10922
8 e 3491125 e 10333958 dd 752 ee 0 d 0 a 410 d 2 d 90 10.135.255.72:20011 myself、master-0 connected 0-5460
92 eadfb 6 a cbd 0 db 74 a 8 b 8860286 a 7 f 63 abce140 e 10.135.255.74:20011 master-0 157239581799 connected 10923-6383
7084 c 1 d 7950 b 83 abc 1 e 4419500 e 1 c 24 a 9 fa108 e 7 10.135.255.72:20012 slate 92 eadfb 6 a cbd 0 db 8860286 a 7 f 63 abce140 e 0 1572391499 connected
Redis Clausterは運転してから、主従関係の自動切換がよく発生します。例えば、10.135.255.74：20012はmasterになります。10.135.255.73：20011はslaveになります。そうすると、10.135.255.74：20011と10.135.255.74：20012はダブルマスターになります。このように、もし10.135.255.74のホストマシンが発生したら、マスター2は使えなくなります。cluster down（ps：redis clusterの半分以上のmasterが故障してcluster downを招きます）を招きます。この問題はプロジェクトチームが長い間悩んでいますが、根本的な原因が見つからないです。
その後、何度も資料を調べましたが、redis.co nfのクラスタノードのタイムアウト時定数cluster-node-timeoutの構成は2000（2秒）です。ここでは、このパラメータの役割を簡単に説明します。
一、ノード失効検査
1.クラスタでは、あるノードが他のノードにPINGコマンドを送信したが、対象ノードが所与のタイミングでPINGコマンドの返信を返していない場合、コマンドを送信するノードは、対象ノードをPFAILとしてマークする。
ノードの返信を待つ時間制限はノードタイムアウト時間制限といい、ノードオプションです。
二、クラスタ状態検出
クラスタが構成変化が発生するたびに（おそらく、ハッシュスロット更新であり、あるノードが失効状態に入るかもしれない）、クラスタ内の各ノードは、その知っているノードをスキャンする（scan）。
設定が完了すると、クラスタは二つの状態の中の一つになります。
FAIL：クラスタが正常に動作しなくなり、クラスタ内のノードが失効状態に入ると、クラスタはコマンド要求を処理できなくなり、各コマンド要求に対して、クラスタノードはエラー応答を返す。
OK：クラスタは正常に動作し、全部の16384個のスロットノードを処理します。FAIL状態としてマークされているものは一つもありません。
ノードから選挙する
あるマスタノードがFAIL状態に入ると、このマスタノードがノードから一つ以上存在すると、その中の一つはノードからマスタノードにアップグレードされ、他はノードからこの新しいマスタノードのコピーを開始する。
実際の生産使用過程では、ネットワークの時間遅延またはCusterの一部のノードが持続化しているため、AOF書き換え、Master-slavieの同期データなどの時間のかかる動作は、ノード検出のタイムアウト（>20000 ms）を発生し、ノード検出が鋭敏すぎることを避けるために、複数の調整実践を経て、本プロジェクトの実際の生産環境において、cluster-node-timeoutを12000 msに調整した後に、比較的に安定していて、主が自動的に切り替わることが容易ではありません。本当のmaterノードの本体のあたご機の後で、slaaveは迅速に主に選挙することができて、redis clusterが利用できることを保証します。
補足：一回のRedisを覚えて、主に故障を切り替えて解決します。
問題の説明:
仮想マシンには主二が三哨兵から配置されています。本体のあたごは自動的に1台がマシンからホストに切り替わりました。再起動前のホストは新しいホストに接続できませんでした。
解決方法：
確認したところ、古いホストは新しいスレーブマシンに接続するパスワードが設定されていませんでした。
次の中に接続パスワードを設定して、再度redisサービスを再開します。
再起動後、本体の接続状態が正常に表示され、問題が解決されます。
以上は個人の経験ですので、参考にしていただければと思います。間違いがあったり、完全に考えていないところがあれば、教えてください。