ホームページ  >  記事  >  データベース  >  Redis Sentry モードを追加する理由

Redis Sentry モードを追加する理由

silencement
silencementオリジナル
2019-06-06 14:38:283477ブラウズ

Redis Sentry モードを追加する理由

Redis Sentinel の概要

Sentinel プロセスは、Redis クラスター内のマスター サーバーの動作ステータスを監視するために使用されます。サーバー障害が発生した場合、マスターサーバーとスレーブサーバーを切り替えてシステムの高可用性を確保できます。これは Redis バージョン 2.6 に統合されました。Redis のセンチネルモードはバージョン 2.8 から安定しました。一般に、運用環境では Redis バージョン 2.8 以降を使用することをお勧めします。 Sentinel は分散システムです。アーキテクチャ内で複数の Sentinel プロセスを実行できます。これらのプロセスはゴシップ プロトコルを使用してマスター サーバーがオフラインかどうかに関する情報を受信し、投票プロトコル (合意プロトコル) を使用して自動フェイルオーバーを実行するかどうか、およびどのスレーブにフェイルオーバーを実行するかを決定します。新しいマスターとして選択します。各 Sentinel プロセスは、他の Sentinel、マスター、およびスレーブに定期的にメッセージを送信して、相手が「生存」しているかどうかを確認します。指定された設定時間 (設定可能) 内に相手が応答を受信して​​いないことが判明した場合、一時的に相手がオフラインになったと思うことは、いわゆる「主観的にダウンしていると信じる」ことであり、英語名は Subjective Down、略して SDOWN です。主観的なダウンタイムがある場合は、客観的なダウンタイムも存在する必要があります。 「Sentinelグループ」内のほとんどのSentinelプロセスがMasterサーバー上でSDOWN判定を行い、SENTINEL is-master-down-by-addrコマンドで相互に通信する場合、このようにMasterサーバーはオフラインと判定されます。 「客観的ダウンタイム」、英語名は Objectively Down、略して ODOWN です。特定の投票アルゴリズムを通じて、残りのスレーブ サーバー ノードの 1 つがマスター サーバー ノードに昇格するように選択され、関連する構成が自動的に変更され、フェイルオーバーが有効になります。

Sentinel には別の実行可能ファイル redis-sentinel がありますが、実際には特別なモードで実行されている単なる Redis サーバーです。通常の Redis サーバーを起動するときに、指定された - を渡すことができます。 -sentinel オプションを指定して Sentinel を起動します。センチネルのいくつかのデザインアイデアは動物園の飼育員と非常に似ています。

Sentinel クラスターは相互に通信し、Redis ノードのステータスを伝達し、対応する判断を下して処理します。ここでの主観的なオフライン ステータスと客観的なオフライン ステータスは、より重要なステータスです。フェイルオーバーを実行するかどうかを決定します。これは、指定されたチャネル情報をサブスクライブし、サーバーに障害が発生したときに管理者に通知することによって行われます。クライアントは、Sentinel をサブスクリプション機能のみを提供する Redis サーバーとみなすことができます。このサーバーにメッセージを送信するために PUBLISH コマンドを使用することはできません。情報は送信されますが、 SUBSCRIBE コマンドまたは PSUBSCRIBE コマンドを使用して、特定のチャネルに登録することで、対応するイベント リマインダーを取得できます。チャネルは、チャネルと同じ名前のイベントを受信できます。たとえば、sdown という名前のチャネルは、すべてのインスタンスが主観的オフライン (SDOWN) 状態になるとイベントを受信できます。

Sentinel プロセスの役割:

1. 監視: Sentinel はマスターとスレーブが正常に動作しているかどうかを常にチェックします。

2. 通知: 監視対象の Redis ノードで問題が発生した場合、センチネルは API を通じて管理者または他のアプリケーションに通知を送信できます。

3. 自動フェイルオーバー: マスターが正常に動作しない場合、Sentinel は自動フェイルオーバー操作を開始します。障害が発生したマスターのスレーブの 1 つを新しいマスターにアップグレードし、障害が発生したマスターの他のスレーブをアップグレードします。新しいマスターをコピーするためのマスター変更。クライアントが障害が発生したマスターに接続しようとすると、クラスターは新しいマスターのアドレスもクライアントに返すため、クラスターは現在のマスターを使用して障害が発生したマスターを置き換えることができます。マスターサーバーとスレーブサーバーが切り替わると、マスターの redis.conf、スレーブの redis.conf、および Sentinel.conf 設定ファイルの内容がそれに応じて変更されます。つまり、マスターの redis.conf 設定には、slaveof の余分な行が存在します。ファイルの設定に応じて、sentinel.conf の監視対象が変更されます

以上がRedis Sentry モードを追加する理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。