[TOC］

redisセンチネルモード

redisのセンチネルモードは、複数のredisサーバーを管理するために使用されます。主に以下の3つの機能が実装されています：

• モニタリング: Sentinelは、redisのマスターとスレーブが正しく動作しているかを常にチェックします。
• アラート: Sentinelは、監視しているredisサーバーの1つに問題がある場合、管理者や他のプログラムにAPI経由で自動通知を送信できます。
• 自動フェイルオーバー: マスタが正常に機能しなくなると、Sentinelは自動フェイルオーバー操作を開始し、障害が発生したマスタのスレーブの1つをアップグレードして、他のスレーブに新しいマスタのデータをレプリケートさせます。クライアントが古いマスタに接続しようとすると、クラスタは新しいマスタのアドレスをクライアントに返し、クラスタが障害が発生したマスタを新しいマスタに置き換えることができます。

Redis Sentinelは分散システムで、クラスタ内でSentinelの複数のインスタンスを実行できます。これらのインスタンスはストリーミングプロトコルを使用して、マスターがオフラインかどうかの情報を受け取ります。投票プロトコルを使用して、自動フェイルオーバーを実行するかどうかを決定し、どのスレーブを新しいマスタとして選択するかを決定します。

redisSentinelの起動

redis Sentinelは、コンパイルするとredis-sentinelという1つの実行ファイルになりますが、実際には特別なモードで動いているredisサーバーに過ぎません。redis-serverを使ってSentinelを起動するには、-sentinel引数を与えます。

Sentinelプログラムはコンパイルされたsrcファイルにあり、redis-sentinelという名前のプログラムです。

redis-serverプログラムでは、Sentinelモードで動作するRedisサーバーを以下のコマンドで起動できます：

redis-server /path/to/sentinel.conf --sentinel

== Sentinelを起動するには、コンフィギュレーション・ファイルを作成する必要があります。 Sentinelは、コンフィギュレーション・ファイルを使ってSentinelの状態を保存し、再起動時に、保存されたコンフィギュレーション情報に基づいて状態の復元を行います。==

適切な構成ファイルを指定せずにSentinelを起動した場合、または指定された構成ファイルが書き込み可能でない場合、Sentinelは起動を拒否します。

redisSentinelの構成

完全な設定ファイルは、github のサンプル構成ファイル見ることができます。

monitor

完全なドキュメント

このコンフィギュレーションは、IP 127.0.0.1とポート6379を持つmymasterという名前のredis-masterを監視するようにSentinelに指示します。少なくとも2つのSentinelが、このマスターを失敗したと判断することに同意する必要があります。

ただし、サーバーの障害に同意するようにいくつのSentinelを設定しても、所定の構成エポックを確保して自動フェイルオーバーを開始するには、Sentinelがシステム内のSentinelの過半数によってサポートされる必要があることに注意してください（==ハーフ＆ハーフルール==）。

言い換えれば、少数のSentinelプロセスしか機能していない場合、Sentinelは自動フェイルオーバーを実行できません。

オフライン待機時間

完全なドキュメント

Sentinelにmymasterをオフラインとみなすように設定するには、mymasterが30,000ミリ秒以内に応答しないことが必要で、その時点でSentinelはmymasterをオフラインとみなすことができます。

Sentinelが送信したPINGコマンドに対して、サーバーが所定のミリ秒数以内に応答を返さないか、エラーを返した場合、Sentinelはそのサーバーを主観的にオフラインとしてマークします。

十分な数のSentinelがすべてサーバーを主観的にオフラインとマークした後に初めて、サーバーは客観的にオフラインとマークされ、その時点でフェイルオーバーが実行されます。

サーバーを客観的にオフラインとしてマークするために必要なSentinelsの数は、プライマリサーバーへの設定によって決まります。

自動フェイルオーバー・タイムアウト

完全なドキュメント

Sentinelが自動フェイルオーバーの実行を開始することを決定すると、クロックが開始され、指定された時間内にフェイルオーバーが完了しない場合は、自動フェイルオーバーがタイムアウトしたと見なされます。

自動フェイルオーバーがタイムアウトした場合、Sentinelはマイグレーションのターゲットスレーブを再選択し、マイグレーションをやり直します。マイグレーションをやり直すには、時間のカウントを再度開始します。

masterデータを同期するスレーブの数

完全なドキュメント

フェイルオーバーの実行と同時に新しいマスタ・サーバに同期できるスレーブ・サーバの最大数を指定します。

マスターが転送されるため、すべてのスレーブはマスターからデータをコピーする必要があります。コピーの際、新しいRDBファイルをロードする必要があるため、ある程度のタイムラグが発生します。

簡単に言うと、この値は、フェイルオーバー後に何台のスレーブが一時的に利用できない状態になるかを設定するものです。

値を大きく設定すると、利用できないスレーブが増え、信頼性が低下します。

この値を1に設定することで、一度に1つのスレーブ・サーバーだけがコマンド要求を処理できない状態になるようにできます。

一般的に、センチネルを構成するにはこの4つの構成で十分です。

例

これが組織図です。

まず、docker環境にredisのインスタンスを複数作成します。

次に、githubにあるsentinel.confコピーします。

実行可能コンフィギュレーション

その他のパラメータにはデフォルト値が使用されます。

センチネル開始

docker run -v /redis/sentinel.conf:/usr/local/etc/redis/sentinel.conf --name=sentinel_1_A redis redis-server /usr/local/etc/redis/sentinel.conf --sentinel

書き込み禁止

Sentinelは状態をsentinel.confに保存する必要があるので、各センチネルは別々のconfファイルで設定する必要があります。

マンデート

設定ファイルの変更を忘れないでください。

ここで示されたコンフィギュレーション・ファイルはOKで、バックグラウンド・メソッドを使用して開始できます。

docker run -d -p 379 -v /redis/sentinel_1_A.conf:/usr/local/etc/redis/sentinel.conf --name=sentinel_1_A redis redis-server /usr/local/etc/redis/sentinel.conf --sentinel
docker run -d -p 379 -v /redis/sentinel_1_B.conf:/usr/local/etc/redis/sentinel.conf --name=sentinel_1_B redis redis-server /usr/local/etc/redis/sentinel.conf --sentinel
docker run -d -p 379 -v /redis/sentinel_2.conf:/usr/local/etc/redis/sentinel.conf --name=sentinel_2 redis redis-server /usr/local/etc/redis/sentinel.conf --sentinel

次に、マスターとスレーブのレプリケーションを設定します。

スレーブ2

スレーブ2_B

スレーブ_1_A

スレーブ_1_B

次に、sentinel_1_Aに接続して、どのマスタを監視しているかを確認します。

センチネル_1_Bも同じ。

sentinel_2 もアクセスできます。

主観的ダウンラインと客観的ダウンライン

Sentinel for redisでは、下線には2つの概念があります：

• 主観的オフラインとは、redis上の1つのSentinelによるオフライン判断を指します。
• SENTINEL is-master-down-by-addr客観的なダウンとは、複数のSentinelインスタンスが同じredisに対してSDOWN判定を行い、指定されたマスターがダウンしているかどうかをコマンド経由で他のSentinelに尋ね、最終的にダウンしているとみなすことを意味します。

PINGコマンドを送ったSentinelに対して、master-down-after-millisecondsオプションで指定された時間内に有効な応答を返さなかった場合、Sentinelはサーバーを主観的にダウンとマークします。

PINGコマンドに対するサーバーからの有効な応答は、以下の3つのうちの1つです：

• +PONG
• LOADINGエラーが返されます。
• MASTERDOWNエラーが返されます。

サーバーが上記の3つ以外の応答を返した場合、または指定された時間内にPINGコマンドに応答しなかった場合、Sentinelはサーバーからの応答を無効と見なします。

サーバが主観的にダウンしたとSentinelにフラグを立てられるには、master-down-after-millisecondsミリ秒以内に無効な応答を返し続けなければならないことに注意してください。

たとえば、master-down-after-millisecondsオプションの値が30000ミリ秒の場合、29秒ごとに少なくとも1つの有効な応答を返す限り、サーバーは正常とみなされます。

他のタイプのRedisインスタンスでは、Sentinelはオフラインと判断する前にネゴシエートする必要がないため、スレーブサーバや他のSentinelが客観的なオフライン条件に達することはありません。

Sentinelがマスターサーバーが客観的なオフライン状態になったことを発見するたびに、そのSentinelは他のSentinelによって、故障したマスターサーバーの自動フェイルオーバーを実行するように選ばれるかもしれません。

ゴシッププロトコル

もしセンチネルが他のセンチネルから所定の時間枠内にマスターサーバーがオフラインであるという十分な数の報告を受けた場合、センチネルはマスターサーバーのステータスを主観的オフラインから客観的オフラインに変更します。 他のセンチネルがマスターサーバーがオフラインであることを報告しなくなった場合、客観的オフラインステータスは削除されます。

Sentinel定期的な操作

• 各センチネルは、マスター、スレーブ、およびそのインスタンスが知っている他のセンチネルインスタンスに、1秒に1回の割合でPINGコマンドを送信します。
• PINGコマンドに対する最後の有効なリプライから、down-after-millisecondsオプションで指定された値よりも多くの時間が経過した場合、インスタンスは主観的にダウンしているとSentinelによってフラグが立てられます。 有効な応答は +PONG、-LOADING、または -MASTERDOWN です。
• マスターサーバーが主観的にオフラインとマークされた場合、マスターサーバーを監視しているすべてのセンチネルは、マスターサーバーが確かに主観的にオフライン状態であることを1秒に1回の割合で確認する必要があります。
• マスターサーバーが主観的にオフラインとマークされ、指定された時間内に十分な数のセンチネルがこの判断に同意した場合、マスターサーバーは客観的にオフラインとマークされます。
• 通常、各センチネルは、10秒に1回の割合で、センチネルに知られているすべてのマスターとスレーブにINFOコマンドを送信します。 マスターサーバーがSentinelによって客観的にオフラインとマークされると、Sentinelは10秒に1回ではなく、1秒に1回、オフラインのマスターサーバーのすべてのスレーブサーバーにINFOコマンドを送信します。
• マスターサーバーの客観的オフラインステータスは、十分な数のセンチネルがマスターサーバーがオフラインになったことに同意しなかったときに解除されます。 マスターサーバーの主観的なオフラインステータスは、マスターサーバーが再びセンチネルのPINGコマンドに有効な応答を返したときに解除されます。

Sentinelとスレーブの自動検出

センチネルは他の複数のセンチネルと接続することができ、各センチネルは互いの稼働状況を確認し、情報を交換することができます。

Sentinelは、チャンネル sentinel:helloにメッセージを送ることによって達成される公開と購読機能を通して、同じマスターサーバーをモニターしている他のSentinelを自動的に発見することができるからです。

同様に、マスターサーバーの下にあるすべてのスレーブを手動でリストアップする必要はありません。

• 各センチネルは、センチネルのIPアドレス、ポート番号、およびランタイムIDを含むメッセージを、2秒ごとに、パブリッシュおよびサブスクライブ機能を介して、それが監視するすべてのマスターおよびスレーブサーバーの sentinel:helloチャネルに送信します。
• 各センチネルは、それが監視しているすべてのマスターとスレーブの sentinel:helloチャンネルを購読し、未見のセンチネルを探します。 Sentinelが新しいSentinelを発見すると、同じマスターサーバーをモニターしているSentinelに知られている他のすべてのSentinelのリストに新しいSentinelを追加します。
• Sentinelが送るメッセージには、マスターサーバーの完全な現在の構成も含まれます。 Sentinelが他のSentinelから送られたものより古いマスターサーバー構成を含んでいる場合、そのSentinelは直ちに新しい構成にアップグレードされます。
• 新しいセンチネルをモニターされたマスターサーバーのリストに追加するとき、Sentinelはまず、リストに追加したいセンチネルと同じランタイムIDまたはアドレスを持つセンチネルがすでに含まれているかどうかをチェックします。もし含まれていれば、Sentinelは新しいセンチネルを追加する前に、同じランタイムIDまたはアドレスを持つ既存のセンチネルを削除します。もしそうであれば、Sentinelは新しいSentinelを追加する前に、同じランIDまたはアドレスを持つSentinelをリストから削除します。

SentinelスクリプトのAPIは

デフォルトでは、SentinelはTCPポート26379を使用します。

SentinelはRedisプロトコル形式のコマンドリクエストを受け付けるので、redis-cliや他のRedisクライアントを使ってSentinelと通信できます。

センチネルとのコミュニケーションには2つの方法があります：

• 最初の方法は、監視しているRedisサーバーの現在の状態や、Sentinelが他のSentinelについて知っていることなどを照会るために、直接コマンドを送信することです。
• Sentinelは、フェイルオーバー操作が実行されたとき、または監視対象サーバーが主観的または客観的にオフラインと判断されたときにメッセージを送信します。

Sentinel

以下は、Sentinelが受け付けるコマンドの一覧です：

• PING サーバーが読み取り専用のスクリプトを実行している場合、スクリプトは強制終了され、サーバーは通常の状態に戻ります。

• SENTINEL masters : 監視しているすべてのマスターサーバーと、それらのマスターサーバーの現在のステータスを一覧表示します。

  

• SENTINEL slaves : 指定されたマスター・サーバーのすべてのスレーブと、それらのスレーブの現在のステータスを一覧表示します。

  

• SENTINEL get-master-addr-by-name ： 指定された名前のマスター・サーバーの IP アドレスとポート番号を返します。 マスタ・サーバがフェイルオーバー操作中の場合、またはマスタ・サーバのフェイルオーバー操作が完了した場合、このコマンドは新しいマスタ・サーバのIPアドレスとポート番号を返します。

  

• SENTINEL reset : 名前が指定されたパターンに一致するマスターサーバーをすべてリセットします。 patternパラメータはGlobスタイルのパターンです。 リセット操作は、進行中のフェイルオーバーを含むマスターサーバーの現在の状態を明確にし、現在検出され関連付けられているマスターサーバーのすべてのスレーブとSentinelを削除します。

• SENTINELフェイルオーバー：プライマリサーバーに障害が発生した場合、他のSentinelsに助言を求めることなく、強制的に自動フェイルオーバーを開始します。

パブリッシュ/サブスクライブ

クライアントは、Sentinelをサブスクリプション専用のRedisサーバと考えることができます。このサーバにメッセージを送信するために PUBLISH コマンドを使用することはできませんが、イベントに関するアラートを取得するために指定されたチャネルをサブスクライブするために SUBSCRIBE コマンドまたは PSUBSCRIBE コマンドを使用することができます。

チャンネルは、チャンネルと同じ名前のイベントを受け取ることができます。 たとえば、+sdownという名前のチャンネルは、すべてのインスタンスが主観的なダウン状態になるイベントを受け取ることができます。

すべてのイベント情報は、PSUBSCRIBE *コマンドを実行することで受信できます。

最初の英単語はチャンネル/イベントの名前で、残りはデータのフォーマットです。

なお、インスタンス詳細という言葉がフォーマットに含まれている場合、チャネルから返される情報には、対象のインスタンスを識別するための以下の情報が含まれていることを意味します：

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

の内容はマスター・サーバーを指定するために使用されます。 これらの内容はオプションで、@の内容で指定されたインスタンスがマスター・サーバーでない場合にのみ使用されます。

• +reset-master : マスターサーバーがリセットされました。
• +新しいスレーブが認識され、Sentinelに関連付けられました。
• +failover-detected : 別のSentinelがフェイルオーバー操作を開始したか、スレーブサーバーがマスターサーバーに変換されました。
• +slave-reconf-sent（+slave-reconf-sent）：リード・センチネルがインスタンスに SLAVEOF コマンドを送信し、インスタンスの新しいマスター・サーバーをセットアップしました。
• +slave-reconf-inprog : インスタンスは指定されたマスターのスレーブとして自身をセットアップしている最中ですが、対応する同期プロセスはまだ不完全です。
• +slave-reconf-done : スレーブ・サーバーは、新しいマスター・サーバーとの同期を正常に完了しました。
• --dup-sentinel : 指定されたマスターサーバーを監視していた1つ以上のセンチネルが再発により削除されました -- これはセンチネルインスタンスが再起動されたときに発生します。
• +sentinel : 指定されたマスターサーバーを監視する新しいセンチネルが特定され、追加されました。
• +sdown : 指定されたインスタンスは現在、主観的なダウン状態にあります。
• -sdown : 指定されたインスタンスはもはや主観的なダウン状態にはありません。
• +odown : 指定されたインスタンスは客観的にダウンした状態になります。
• -odown : 指定されたインスタンスはもはや客観的なダウン状態ではありません。
• +new-epoch : 現在のエポックが更新されました。
• +try-failover : 新しいフェイルオーバー操作が進行中で、ほとんどのSentinelsによって選択されるのを待っています。
• +elected-leader : 指定されたエポックの選挙に勝利し、フェイルオーバー動作の準備完了。
• +failover-state-select-slave : フェイルオーバー操作は現在select-slave状態です -- Sentinelはマスターにアップグレードできるスレーブを探しています。
• no-good-slave : Sentinelの操作でアップグレードに適したスレーブが見つかりませんでした。Sentinelは、一定時間後に再度アップグレードに適したスレーブを探すか、フェイルオーバー操作を中止します。
• selected-slave : Sentinelは正常にアップグレードに適したスレーブを見つけました。
• failover-state-send-slaveof-noone : Sentinelは指定されたスレーブサーバをマスターサーバにアップグレード中で、アップグレード機能が完了するのを待っています。
• failover-end-for-timeout : タイムアウトによりフェイルオーバーは中断されますが、最終的にすべてのスレーブサーバは新しいマスターサーバのレプリケーションを開始します。
• failover-end : フェイルオーバー操作は正常に完了しました。すべてのスレーブ サーバが新しいマスタ サーバのレプリケーションを開始しました。
• +switch-master : 設定変更、マスターサーバーのIPとアドレスが変更されました。 これはほとんどの外部ユーザーが興味を持つ情報です。
• +tilt サーバーが読み取り専用のスクリプトを実行している場合、スクリプトは強制終了され、サーバーは通常の状態に戻ります。
• -tilt サーバーが読み取り専用のスクリプトを実行している場合、スクリプトは強制終了され、サーバーは通常の状態に戻ります。

master_1の手動シャットダウン

少し待ってください：

フェイルオーバーの開始

Dockerのため、転送に成功しませんでした。なぜなのか分かりませんが、コンテナを再起動しました。

移籍が実際に行われたことが判明します。

6379番ポートがスレーブに、6380番ポートがマスターになりました。

その後、元のmaster_1情報リンクを使用し続けます。

6379は読み取り専用スレーブになったため、書き込みはできません。

フェイルオーバー

フェイルオーバー操作は、以下のステップで構成されます：

• メインサーバーが客観的なオフライン状態になっていたことが判明しました。
• ペアの現在のバージョンがインクリメントされ、このバージョンでの選出を試みます。
• エレクションに失敗した場合は、設定されたフェイルオーバー・タイムアウトの2倍後にエレクションを再試行します。 エレクションが成功した場合は、以下の手順を実行します。
• スレーブサーバを選び、マスターサーバにアップグレードします。
• 選択したスレーブサーバーにSLAVEOF NO ONEコマンドを送信し、マスターサーバーに変換します。
• パブリッシュとサブスクライブの機能により、更新されたコンフィギュレーションは他のすべてのSentinelに伝搬され、Sentinelは自身のコンフィギュレーションを更新します。
• ダウンしたマスターサーバーのスレーブに SLAVEOF コマンドを送信し、新しいマスターサーバーをレプリケートするように指示します。
• リードSentinelは、すべてのスレーブサーバが新しいマスタサーバのレプリケーションを開始したときに、フェイルオーバー操作を終了します。

Redisインスタンスが再設定されるたびに（マスタ、スレーブ、または別のマスタのスレーブとして設定されるかにかかわらず）、Sentinelは再設定されたインスタンスにCONFIG REWRITEコマンドを再設定されたインスタンスに送信し、ハードドライブ上にコンフィギュレーションが永続化されるようにします。

Sentinelは以下のルールを使用して新しいマスターサーバーを選択します：

• オフライン、切断、または PING コマンドに対する最後の応答が5秒以上であると主観的にマークされた障害マスタ配下のスレーブは除外されます。
• down-afterオプションで指定された時間の10倍以上、障害が発生したマスタから切断されたマスタ配下のスレーブは除外されます。
• レプリケーション・オフセットがない場合、またはスレーブのレプリケーション・オフセットが同じ場合は、ランタイムIDが最も小さいスレーブが新しいマスター・サーバーになります。

一貫性の特徴

センチネル自動フェイルオーバーは、ラフトアルゴリズムを使用してリーダーのセンチネルを選出し、特定のリリースに1つだけリーダーが作成されるようにします。

つまり、同じリリースで2人のセンチネルがリーダーに選ばれることはなく、各センチネルは同じリリースで1人のリーダーにしか投票しません。

コンフィギュレーションの高いバージョンは低いバージョンよりも常に好ましいので、各センチネルは積極的に自分のコンフィギュレーションを新しいバージョンに置き換えます。

簡単に言うと、Sentinelのコンフィギュレーションをバージョン番号のあるステートとして考えてください。 状態は、最後に書かれたものが勝つように、他のすべてのSentinelに伝搬されます。

例えば、ネットワークが分割された場合、センチネルは古いコンフィギュレーションを含むかもしれず、そのセンチネルが他のセンチネルからコンフィギュレーションの新しいバージョンを受け取ると、センチネルはそれ自身のコンフィギュレーションを更新します。

ネットワークが分割されても一貫性を維持したい場合は、min-slaves-to-writeオプションを使用して、接続されているスレーブ・インスタンスの数が所定の数より少ない場合にマスター・サーバーが書き込みを実行しないようにし、Redisマスターまたはスレーブを実行している各マシンでRedis Sentinelプロセスを実行する必要があります。

Sentinel 状態の永続化

Sentinelの状態は、Sentinel設定ファイル内に永続化されます。

Sentinelが新しいコンフィギュレーションを受け取るたびに、またはリードSentinelがマスターサーバーのために新しいコンフィギュレーションを作成するたびに、コンフィギュレーションはコンフィギュレーションエポックと一緒にディスクに保存されます。

これは、Sentinelプロセスを停止して再起動しても安全であることを意味します。

sentinel_1_Bをシャットダウンし、sentinel.confファイルを見てください。

非フェイルオーバーシナリオにおけるインスタンスの再構成

Sentinelは、自動化されたフェイルオーバー操作が進行中でなくても、常に監視対象のインスタンスの上に現在の構成を設定しようとします。 特に

• 現在のコンフィギュレーションにもよりますが、スレーブがマスターと宣言されると、元のマスターに代わって新しいマスターとなり、元のマスターのすべてのスレーブのレプリカとなります。 間違ったマスターに接続されているスレーブは、正しいマスターを複製するように再設定されます。

しかし、これらの条件が満たされた後も、センチネルは他のセンチネルから構成の更新を確実に受信するために、インスタンスが古い構成で不必要にインスタンスを再構成しないように、インスタンスが再構成するのに十分な時間を待ちます。

TILT

たとえば、インスタンスが利用可能かどうかを判断するために、Sentinelはそのインスタンスに対応する最後のPINGコマンドの時刻を記録し、その時刻と現在の時刻を比較して、そのインスタンスがSentinelとの通信に成功してからの時間を確認します。

しかし、コンピュータの時間機能に障害が発生したり、コンピュータが非常に混雑していたり、何らかの理由でプロセスがブロックされていたりすると、Sentinelも失敗することがあります。

TILTモードは特別な保護モードです。Sentinelは、システムに何か問題があると認識すると、TILTモードに入ります。

Sentinelの時間割り込み機能はデフォルトで1秒間に10回実行されるため、時間割り込 み機能の実行間隔は約100ミリ秒になります。 Sentinel のアプローチは、最後の時間割り込みの実行時間を記録し、現在の時間割り込み の実行時間と比較することです：

• 2つの呼び出し時間の差が負、または非常に大きい場合、センチネルはTILTモードに入ります。
• SentinelがすでにTILTモードにある場合、SentinelがTILTモードを終了するのを遅らせる時間。

しかし、センチネルがTILTモードに入ると、すべてのターゲットを監視し続けます：

• もはやフェイルオーバーなどのオペレーションは実行されません。
• インスタンスがこのセンチネルにSENTINEL is-master-down-by-addrコマンドを送ると、センチネルは負の値を返します。

TILTが30秒間正常に維持できれば、SentinelはTILTモードを終了します。

BUSY状態の処理

Redisは、Luaスクリプトが指定された制限時間を超えて実行されると、-BUSYエラーを返します。

これが発生すると、Sentinelは コマンドをサーバーに送信してフェイルオーバー操作を実行しようとします。 サーバーが読み取り専用のスクリプトを実行している場合、スクリプトは強制終了され、サーバーは通常の状態に戻ります。