Redis における Sentinel フェイルオーバーの原理は何ですか?

Sentinel とは?

Sentinel は Redis の高可用性ソリューションです。以前に説明したマスター/スレーブ レプリケーションは高可用性の基礎ですが、純粋なマスター/スレーブ レプリケーションを完了するには手動介入が必要ですフェイルオーバー、Sentinel はこの問題を解決できます。マスター/スレーブ レプリケーションの場合、マスター ノードに障害が発生すると、Sentinel が自動的に障害を検出し、フェイルオーバーを完了して、真の Redis の高可用性を実現します。 Sentinel クラスターでは、Sentinel がすべての Redis サーバーと他の Sentinel ノードのステータスを監視し、障害を適時に検出して転送を完了することで、Redis の高可用性を確保します。

Sentinel クラスターの構築

Sentinel は本質的に Redis サービスですが、通常の Redis サービスとは異なる機能を提供します。 Sentinel は分散アーキテクチャです。Redis の高可用性を確保したい場合は、まず独自の高可用性を確保する必要があるため、Sentinel を構築する必要がある場合は、少なくとも 3 つのインスタンス、できれば奇数のインスタンスをデプロイする必要があります。後続のフェイルオーバーでは投票が関係するためです。

Sentinel 設定ファイルは、redis GitHub プロジェクトの下にダウンロードできます。プロジェクトの下に Sentinel.conf というファイルがあります。これを Sentinel 設定テンプレートとして使用できます。もちろん、redis を使用することもできます。 conf 設定ファイルに、センチネル関連の設定を追加するだけです。

Sentinel に関連する設定項目はそれほど多くありません。主に次の設定項目があります:

// 端口号，默认是 redis 实例+20000，所以我们沿用这个规则就好了 port 26379  // 是否守护进程运行 daemonize yes // 日志存放的位置，这个非常重要，通过日志可以查看故障转移的过程 logfile "26379.log"  // 监视一个名为 mymaster（自定义） 的 redis 主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， // 最后面的 2 代表着至少有两个哨兵认为主服务器出现故障才会进行故障转移，否则认定主服务未失效 sentinel monitor mymaster 127.0.0.1 6379 2  // 哨兵判断服务器失效的响应时间，超过这个时间未接收到服务器的回应，就认为该服务器失效了 sentinel down-after-milliseconds mymaster 30000  // 完成故障转移之后，最多多少个从服务器可以同时发起数据复制，数字越小，说明完成全部从服务数据复制的时间越长 // 数字越大，对主服务器的压力就变大了 sentinel parallel-syncs mymaster 1  // 故障转移超时时间 sentinel failover-timeout mymaster 180000

Sentinel インスタンスごとにポートとログファイルの設定が異なることを除き、他の設定項目は同じです. .構成を変更した後、./redis-sentinel Sentinel.conf コマンドを使用して Sentinel を起動できます。このコマンドは Redis インスタンスの起動に似ています。Sentinel も Redis インスタンスであるため、./redis- cli -p 26379 info Sentinel コマンドを実行して表示します。現在のセンチネル情報は次の図に示されています:

センチネル情報

質問: 方法マスター サーバーのみが構成されている場合、スレーブ サーバーと他のサーバーを検出する Sentinel ?

スレーブ サーバーの検出、Sentinel はマスター サーバーに問い合わせることでスレーブ サーバーの情報を取得できます。他の Sentinel ノードの検出については、パブリッシュおよびサブスクライブ機能であり、チャネル Sentinel:hello に情報を送信することによって実現されます。主に 2 つのステップがあります:

1. 各 Sentinel は、すべてのマスター サービスとスレーブ サーバーの Sentinel:hello チャネルにメッセージを送信します。パブリッシュおよびサブスクライブ機能を通じて 2 秒ごとに送信されます。メッセージには Sentinel IP アドレス、ポート番号、および実行 ID (runid)

2 が含まれます。各 Sentinel は、監視されているすべてのマスター サーバーおよびスレーブ サーバーの Sentinel:hello チャネルにサブスクライブします。それによって、これまでに出現したことのないセンチネルを探します（未知のセンチネルを探しています）。 Sentinel が新しい Sentinel を検出すると、Sentinel が認識し、同じプライマリ サーバーを監視している他のすべての Sentinel を保持するリストに新しい Sentinel が追加されます。

Sentinel フェイルオーバーの原則

フェイルオーバーはメインです。 Sentinel のジョブです。その背後にある実装ロジックも非常に複雑です。具体的な実装ロジックについては、関連する書籍を確認してください。Sentinel のフェイルオーバーについては、次の 3 つのポイントをまとめました。

1. リスニング サーバー

• Return PONG

• Return-LOADING

• Return-MASTERDOWN

2. 転送タスクを完了するためにセンチネル ノードを選出します。

• すべてのオンライン センチネルはリーダーとして選出される資格があり、これはすべてのセンチネルがリーダーになる機会があることを意味します。

• #Sentinel がマスター サーバーを主観的にオフラインとしてマークすると、Sentinel is-master-down-by-addr コマンドを他の Sentinel ノードに送信し、自分自身をリーダーとして設定するよう要求します

• コマンドを受信した Sentinel ノードは先着順のルールを採用し、他の Sentinel ノードの Sentinel is-master-down-by-addr コマンドに同意していない場合は、リクエストに同意しますが、そうでない場合は拒否されます

• Sentinel ノードが投票の半分以上を持っていることが判明した場合、そのノードがリーダーになります

##指定された時間内にセンチネル リーダーが選出されなかった場合は、センチネル リーダーが選出されるまでの一定期間後に再選出されます。

選出されたセンチネル リーダーは、残りのフェイルオーバー作業とフェイルオーバーを完了します。 3 つのステップ:

オフライン マスター サーバーのすべてのスレーブ サーバーの中からスレーブを選択し、マスター サーバーに変換します。新しいマスター サーバーを選択するためのルールは次のとおりです:

障害が発生したマスター サーバーの下にあるスレーブ サーバーのうち、主観的オフラインとしてマークされているスレーブ サーバー、切断されているか、PING コマンドへの最後の応答が 5 秒を超えている場合は除外されます。
障害が発生したマスター サーバー配下のスレーブ サーバーのうち、障害が発生したマスターに関連するスレーブ サーバーサーバー down-after オプションで指定された時間の 10 倍を超えて接続が切断されたスレーブ サーバーは排除されます。
上記 2 回の排除の後、残りのスレーブ サーバーは排除されます。最大のレプリケーション オフセットを持つスレーブ サーバーが新しいマスター サーバーになります。レプリケーション オフセットが利用できない場合、またはスレーブ サーバーのレプリケーション オフセットが同じ場合は、最小の実行 ID を持つスレーブ サーバーが新しいマスター サーバーになります。マスター サーバー
は、選択されたスレーブ サーバー上で、slaveof no one コマンドを実行し、それをマスター ノードにします。

新しいマスター サーバーが表示されたら、センチネル リーダーが行う必要がある次のステップは、他のスレーブ サーバーのレプリケーション ターゲットを変更することです。サーバー サーバーは、slaveof new_master port コマンドを他のスレーブ サーバーに送信することによって、新しいマスター サーバーを複製します。マスター サーバーをスレーブ サーバーとして設定

以上がRedis における Sentinel フェイルオーバーの原理は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。