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. リスニング サーバー

#各 Sentinel ノードは、ハートビート検出のために 1 秒ごとにマスター ノード、スレーブ ノード、および他の Sentinel ノードに ping コマンドを送信し、サーバーのステータスを判断します。

ノードはそれに応じて Sentinel にも応答します。これらの応答のうち、次の 3 つの応答は有効な応答です:

• Return PONG

• Return-LOADING

• Return-MASTERDOWN

ノードがセンチネル構成で設定されたミリ秒後のマスターダウン状態にある場合file オプションの値内で、一度でも有効な応答がない場合、Sentinel はサーバーをオフラインとしてマークします。この種のオフラインを主観的オフラインと呼びます。これは、このセンチネルだけがサーバーがオフラインであると認識していることを意味します。

主観的にオフラインであるサーバーがメイン サーバーである場合、メイン サーバーが本当にオフラインであるかどうかを確認するために、センチネルは、同じくメイン サーバーを監視している他のセンチネルに、彼らも同様にオフラインであると考えているかどうかを確認します。メイン サーバーはオフライン状態になります。十分な数の Sentinel がメイン サーバーがオフラインであると判断すると、Sentinel はメイン サーバーが客観的にオフラインであると判断します。これは実際にオフラインであり、フェイルオーバー操作を実行します。

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

障害転送はすべてのセンチネルが同時に完了するのではなく、センチネル ノードをリーダーとして選出してこれを完了します。したがって、メインサーバーが客観的にオフラインとしてマークされている場合、センチネルはフェイルオーバー作業を完了するために Raft アルゴリズムを通じてリーダーを選出します。 Redis はセンチネル リーダー選挙を実施します

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

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

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

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

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

3. フェイルオーバーを完了する新しいマスター サーバーを選出します

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

(1) 新しいマスター サーバーの選択

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

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

(2) 他のスレーブ サーバーのレプリケーション ターゲットを変更する

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

フェイルオーバー操作で最後に行うことは、オフラインのマスター サーバーを新しいマスター サービスのスレーブ サーバーとして設定し、それを監視してコマンドを実行することです。新しいマスター ノードをコピーします。

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