こんにちは、ここに Redis シリーズの記事があります。この記事は [redis の基本] Sentinel、前のリンク: [redis] redis マスター/スレーブ レプリケーション_頑張って頑張って mlx のブログ - CSDN ブログ
目次
1 つのマスターと 2 つのスレーブで Redis インスタンスを開始し、センチネルを構成し、通常のマスター/スレーブ レプリケーションをデモンストレーションします。
Redis サーバーを手動でシャットダウンすると、シミュレートされたホストがハングアップします。
兵士の王はフェイルオーバーをオンにし、新しいマスターを選出します
老師は崇拝しており、老師は戻ってきたら説得しなければならない
コンセプト
簡単に言うと、監視員とはバックグラウンドでマスターホストに障害がないかを検査・監視し、障害が発生した場合には投票数に応じて特定のスレーブデータベースを新しいマスターデータベースに自動変換して継続する内部告発者です。外の世界に奉仕するために。
効果
Sentinel には主に次の 4 つの機能があります。
- マスタースレーブ監視
- マスター/スレーブ Redis ライブラリが正常に実行されているかどうかを監視する
- 通知
- Sentry はフェイルオーバー結果をクライアントに送信できます
- フェイルオーバー
- マスターが異常の場合、マスター/スレーブの切り替えが実行され、スレーブの 1 つが新しいマスターとして使用されます。
- 構成センター
- クライアントは、センチネルに接続することにより、現在の Redis サービスのマスター ノード アドレスを取得します。
Sentinel の主な機能を一言でまとめると次のとおりです。
1. マスターとスレーブを含む Redis の実行ステータスを監視する
2.マスターがダウンした場合、スレーブを新しいマスターに自動的に切り替えることができます。
Sentinelの使い方（事例デモ＋実践手順）
Redis センチネル アーキテクチャの事前説明
redis Sentry の役割を確認するための構成は次のとおりです。
- 3 センチネル
- クラスターを自動的に監視および保守します。データは保存せず、監視のみを行います。
- 1 マスター 2 スレーブ
- データの読み取りと保存用
- /myredis ディレクトリに Sentinel.conf を作成またはコピーします。
- まず、redis 解凍ディレクトリにあるデフォルトの Sentinel.conf ファイルの内容を確認します。
主要パラメータの設定
Sentinel ファイル パラメータ (リーダー)
バインド サービス リスニング アドレス (クライアント接続に使用) (デフォルトではローカル アドレス)
バックグラウンド デーモンとして実行するかどうかデーモン化 プロテクト
モード セキュリティ保護モード
ポート ポート
ログファイル ログ ファイル パス
pidfile pid ログ パス
dir 作業ディレクトリ
センチネル モニター <マスター> <redis-port> <クォーラム>
マスター クォームを監視対象に設定するということは、少なくとも数人の監視員が客観的にオフラインになることに同意し、障害移行の法定投票数に同意することを意味します。
ネットワークの信頼性が低いことはわかっています。センチネルは、ネットワークの輻輳によりマスター Redis が停止したと誤って認識することがあります。センチネル クラスター環境では、複数のセンチネルが相互に通信して、マスターが本当に停止しているかどうかを確認する必要があります。パラメータクォーラムは客観的なオフラインの基礎です。つまり、少なくともクォーラム監視員はマスターに障害があると信じているため、マスターはオフラインになりフェイルオーバーされます。場合によっては、センチネル ノードが独自のネットワーク上の理由でマスターに接続できない場合があり、現時点ではマスターに障害はないため、次のステップに進む前にマスターに問題があることを複数のセンチネルが同意する必要があるためです。ステップ操作により、公平性と高可用性が保証されます。
Sentinel auth-pass <master-name> <password> //パスワードを使用してマスターに接続します
//パスワードを介してホストに接続します。ホストがハングアップして再起動した後は、ホストがホストではなくなるため、ホスト内の構成ファイルであっても、これを構成する必要があることに注意してください。デフォルトではスレーブとして認識されますが、この時点で新しいホストにも接続する必要があります
この場合の一般的なファイル構成
次のセンチネル構成ファイルを構成します
センチネル26381.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111
センチネル26380.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111センチネル26379.conf
bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111Sentinel ファイルのその他の設定について
sentinel down-after-milliseconds <master-name> <milliseconds>：
指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel parallel-syncs <master-name> <nums>：
表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel failover-timeout <master-name> <milliseconds>：
故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel notification-script <master-name> <script-path> ：
配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script <master-name> <script-path>：
客户端重新配置主节点参数脚本1 つのマスターと 2 つのスレーブで Redis インスタンスを開始し、センチネルを構成し、通常のマスター/スレーブ レプリケーションをデモンストレーションします。
|
1
|
169 マシンに新しい redis6379.conf 構成ファイルを作成します。このケースに一致させるには、masterauth 項目のアクセス パスワードを 111111 に設定してください。
そうしないと、後でエラーが報告される可能性があります master_link_status:down
|
|
2
|
172 マシン上に新しい redis6380.conf 構成ファイルを作成し、<masterip> <masterport> のレプリカを設定します。
|
|
3
|
173 マシン上に新しい redis6381.conf 構成ファイルを作成し、<masterip> <masterport> のレプリカを設定します。
|
前の章で構成した 1 つのマスターと 2 つのスレーブに基づいて、ホストの redis6379.conf を変更する必要があります。
redis6379.conf
6379 は将来スレーブになる可能性があります。新しいホストにアクセスするにはパスワードを設定する必要があります。masterauth 項目のアクセス パスワードを 111111 に設定してください。
redis 6380.conf
特定の IP アドレスとパスワードは、地域の実際の状況に応じて変更する必要があります。
レディス 6381.conf
1 つのマスターと 2 つのスレーブを開始します
6379.conf
redis-server /myredis/redis6379.conf
redis-cli -a 111111 -p6379
6380.conf
redis-server /myredis/redis6380.conf
redis-cli -a 111111 -p 6380
6381.conf
redis-server /myredis/redis6381.conf
redis-cli -a 111111-p 6381
センチネルを開始する
redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinelセンチネル情報を見る
マスター/スレーブ レプリケーション情報を確認し、すべてが正常であることを確認します。
ホストがダウンしています。ログを確認してください
Redis サーバーを手動でシャットダウンすると、シミュレートされたホストがハングアップします。
マスターが電話を切った後、スレーブの変更を確認します
発生する可能性のある問題:
壊れたパイプに関するある説明:
|
壊れたパイプを知る
|
パイプとはパイプラインを意味し、パイプライン内にはデータ ストリーム (通常はファイルまたはネットワーク ソケットから読み取られたデータ) があります。
パイプが相手側から突然閉じられると、データは突然中断され、壊れます。
おそらくネットワークが切断されているか、相手側のプロセスがクラッシュした可能性があります
|
|
問題を解く
|
実際、例外が発生してもサーバーには大きな影響はありません。このエラーは、クライアントがプロセスを突然終了したことが原因である可能性があります
|
|
概要壊れたパイプ
|
この例外は、クライアントの読み取りがタイムアウトになり、接続が閉じられた場合です。このとき、サーバーはクライアントに
切断された接続がデータを書き込むときに、壊れたパイプ例外が発生します。
|
要約すると、マスターのハングアップはスレーブに一時的な影響を与えますが、この種の問題が発生してもパニックにならず、同じコマンドをもう一度入力してください。
引き続きコピー情報を表示します
6380
6381
6381 がホストになっていることがわかりました
設定ファイルを比較する
古いマスター vim redis6379.conf
redis6379 オフライン
vim redis6380.conf
新しいマスター vim redis6381.conf
私たちは次のような結論に達します。
- この記事の Sentinel26379.log、sentinel26380.log、および Sentinel26381.log は、運用中に動的に変更されます。
- マスター/スレーブ切り替えでは、redis###.conf ファイルの内容が自動的に変更されます
さらに、Sentinel では複数のマスターを 1 行に 1 つずつ監視できます。
Sentinel の運用プロセスと選択原則
マスター/スレーブ構成のマスターに障害が発生した場合、sentinel は元のマスターの作業を引き継ぐ新しいマスターを選択でき、マスター/スレーブ構成の他の Redis サーバーは自動的に新しいマスターをポイントしてデータを同期します。一般に、特定のセンチネルがマスターに接続できずに偶発的な切り替えが発生するのを防ぐために、奇数のセンチネルを使用することをお勧めします。
主観的なオフラインと客観的なオフライン
SDOWN主観オフライン
1. SDOWN は、単一のセンチネルが主観的に検出したマスターの状態であり、センチネルの観点からは、PING ハートビートの送信後、一定時間内に正当な応答が受信されない場合、SDOWN 条件 2 が満たされます
。 Sentinel 設定ファイルの -after-milliseconds は、主観的なオフラインを判定する時間の長さを設定します。
いわゆる主観的にダウン (Subjectively Down、SDOWN と呼ばれる) とは、単一の Sentinel インスタンスによってサーバーに対して行われたオフラインの判断を指します。つまり、単一の Sentinel がサービスがオフラインであると考えます (サブスクリプションができない可能性があります)。受信できない場合、両者間のネットワークが接続されていない場合など）。主観的オフラインとは、サーバーが PING コマンドに応答しない場合、または [sentinel down-after-milliseconds] で指定されたミリ秒以内にエラー メッセージを返した場合、Sentinel は主観的に (一方的に) マスターが使用不可であるとみなすことを意味します。 はい、 o (╥﹏╥)o
ミリ秒後のセンチネルダウン <マスター名> <タイムアウト>
現在のセンチネル インスタンスによってマスターが無効であるとみなされるまでの間隔時間を示します。この設定は、実際には主観的なオフラインの基礎となります。
マスターが Sentine に有効な情報を返さない期間は、マスターが主観的にオフラインであると見なされます。つまり、redis-servervr が長期間接続されなかった場合、redis-server は SDOWN 状態に入ったと考えられます。
ODOWN 目標がオフライン
ODOWN には一定数のセンチネルが必要であり、複数のセンチネルが合意に達して、マスターが客観的にダウンしているとみなすことができます。
4 つのパラメータの意味は次のとおりです。
masterName は、マスターとスレーブの組み合わせを識別する識別子です (センチネルのセットは、マスターとスレーブの組み合わせの複数のグループを監視できます)
パラメータ クォーラム は、オフラインの目的、つまり投票のクォーラム/クォーラムの基礎です。
これは、オフラインになってマスターをフェイルオーバーする前に、少なくともクォーラム監視員がマスターに障害があると判断することを意味します。場合によっては、センチネル ノードが独自のネットワークのせいでマスターに接続できないことがありますが、現時点ではマスターに障害はないため、次のステップに進む前にマスターに問題があることを複数のセンチネルが同意する必要があるためです。これにより、公平性と高可用性が保証されます。
選挙リーダーのセンチネル (センチネルから兵士の王を選択)
- マスター ノードが客観的にオフラインであると判断されると、各センチネル ノードがネゴシエートし、郡がリーダー センチネル ノードを選出し、リーダー ノードがフェイルオーバー (障害移行) を実行します。
- Raft アルゴリズムはリーダー ノードを選択します
マスター ノードを監視しているすべてのセンチネルがリーダーとして選出される可能性があります。選出に使用されるアルゴリズムは Raft アルゴリズムです。Raft アルゴリズムの基本的な考え方は先着順です。つまり、一連の選出で行われます。 、センチネルA はリーダーになるよう B にメッセージを送信します。B が他のセンチネルに同意していない場合は、A がリーダーになることに同意します。
ログの変更
兵士の王はフェイルオーバーをオンにし、新しいマスターを選出します
新しい領主が即位した
スレーブ候補が新しいマスターとなり、新しいマスター ルールを選択します。
残りのスレーブ ノードが正常であるという条件の下で、
redis.conf ファイル内で、最も高い優先順位を持つスレーブ ノードがスレーブ優先順位またはレプリカ優先順位 (数値が小さい方) になります。 、優先度が高くなります）
オフセット位置が最大のスレーブ ノード (ログ内のレコード数が最大の
スレーブ ノード) と実行 ID が最小のスレーブ ノード (つまり、辞書順の ASCII コード) をコピーします。
皇帝と廷臣がボスを再認識すると、役人全員が頭を下げた
選択したスレーブ ノードを新しいマスター ノードにするには、slaveof no one コマンドを実行し、他のノードをそのスレーブ ノードにするには、slaveof コマンドを使用します。Sentinel リーダーは、選択された新しいマスターに対して、slaveof no one 操作を実行し、それ
をマスター ノード
センチネル リーダーは他のスレーブにコマンドを送信し、残りのスレーブを新しいマスター ノードのスレーブにします。
老師は崇拝しており、老師は戻ってきたら説得しなければならない
以前にオフラインだった古いマスターを、新たに選出された新しいマスターのスレーブ ノードとして設定します。古いマスターが再びオンラインになると、新しいマスターのスレーブ ノードになります。センチネル リーダーは、元のマスターをスレーブに格下げして再開します。通常の仕事。
Sentinel の使用に関する提案
- 高可用性を確保するには、センチネル ノードの数は複数である必要があり、センチネル自体はクラスター化されている必要があります。
- センチネル ノードの数は奇数である必要があります
- 各センチネル ノードの構成は一貫している必要があります。
- センチネル ノードが Docker などのコンテナにデプロイされている場合は、正しいポート マッピングに注意してください。
- Sentinel クラスター + マスター/スレーブ レプリケーションはデータ損失ゼロを保証するものではありません