redisはどのようにして高可用性を実現できますか?歩哨多核心底層解析
主従モードで、哨兵モードをオンにします
1、哨兵の紹介
sentinel、中国語名は哨兵です
哨兵はredisクラスタアーキテクチャにおいて非常に重要なコンポーネントであり、主な機能は以下の通りである.
(1)クラスタモニタリング、redis masterとslaveプロセスが正常に動作しているかどうかをモニタリングする(2)メッセージ通知、あるredisインスタンスに障害がある場合、哨兵は管理者(3)にアラーム通知としてメッセージを送信し、master nodeがオフになった場合、slave node上(4)構成センターに自動的に移行し、障害移行が発生した場合、clientクライアントに新しいmasterアドレスを通知する
歩哨自体も分布式で、歩哨集団として運行し、互いに協力して仕事をしている.
(1)フェイルオーバの場合、1つのmaster nodeがダウンしていると判断し、大部分の哨兵が同意しなければならない.分布式選挙の問題にかかわる(2)一部の哨兵ノードが切れても、哨兵クラスタは正常に動作する.高可用性メカニズムの重要な構成部分であるフェイルオーバシステム自体が単点であれば、お父さんになるからだ.
現在はsentinel 2バージョンが採用されており、sentinel 2はsentinel 1に比べて多くのコードを書き換え、主にフェイルオーバのメカニズムとアルゴリズムをより丈夫で簡単にする.
2、哨兵の核心知識
(1)哨兵は少なくとも3つの実例を必要とし、自分の頑丈性を保証する(2)哨兵+redis主従の配置アーキテクチャは、データのゼロ損失を保証することはなく、redisクラスタの高可用性を保証するしかない(3)哨兵+redis主従のこのような複雑な配置アーキテクチャに対して、できるだけテスト環境と生産環境で、十分なテストと訓練を行う
3、なぜredis哨兵集団は2つのノードだけで正常に動作しないのですか?
哨兵集団は2つ以上のノードを配置しなければならない.
哨兵集団に哨兵インスタンスが2つしか配置されていない場合quorum=1
±—+ ±—+ | M1 |---------| R1 | | S1 | | S2 | ±—+ ±—+
Configuration: quorum = 1
masterダウンタイム、s 1とs 2のうち1人の哨兵がmasterダウンタイムであれば切替可能と考え、同時にs 1とs 2の中で1人の哨兵を選出して故障移転を実行する
同時にこの場合、majority、つまり大多数の歩哨が運行している必要があり、2人の歩哨のmajorityは2(2のmajority=2、3のmajority=2、5のmajority=3、4のmajority=2)で、2人の歩哨が運行しているので、フェイルオーバーを許可することができます
しかし、M 1とS 1全体がダウンした場合、哨兵は1人しかいません.この場合、majorityはフェイルオーバを許可しません.もう1台のマシンにはR 1がありますが、フェイルオーバは実行されません.
4、経典の3ノード歩哨集団
±—+ | ±—+ | R2 |----±—| R3 | | S2 | | S3 | ±—+ ±—+
Configuration: quorum = 2,majority
M 1がダウンした場合、3人の哨兵が2人残っており、S 2とS 3はマスターがダウンしたと一致して認識し、1人を選出してフェイルオーバを実行することができる.
同時に3人の歩哨のmajorityは2なので、残りの2人の歩哨が運行していて、フェイルオーバーが許されます
2両データ消失の場合
(1)非同期レプリケーションによるデータ損失
マスター->slaveのレプリケーションは非同期なので、一部のデータがslaveにレプリケートされていない場合、マスターはダウンタイムになり、データの一部が失われる可能性があります.
(2)脳裂によるデータ消失
脳裂、つまり、あるマスターがいたマシンが突然正常なネットワークから離れ、他のslaveマシンと接続できなくなったが、実際にはマスターが稼働している.
この時、哨兵はmasterがダウンしたと思って選挙を開き、他のslaveをmasterに切り替えたかもしれない.
このとき,クラスタには2つのmaster,すなわちいわゆる脳裂がある.
このとき、あるslaveがマスターに切り替わったが、クライアントが新しいマスターに切り替わっていない可能性があり、古いマスターに書き続けたデータも失われている可能性がある
そのため古いマスターが再び復元されると、slaveとして新しいマスターに掛けられ、自分のデータが空になり、新しいマスターからデータがコピーされます.
非同期レプリケーションと脳クラックによるデータ損失の解決
min-slaves-to-write 1 min-slaves-max-lag 10
少なくとも1つのslaveが必要であり、データのコピーと同期の遅延は10秒を超えてはならない.
すべてのslaveでデータのコピーと同期の遅延が10秒を超えると、masterはリクエストを受信しません.
上記の2つの構成は、非同期レプリケーションと脳クラックによるデータ損失を低減することができます.
(1)非同期レプリケーションによるデータ損失の低減
min-slaves-max-lagという構成があれば、slaveレプリケーションデータとackの遅延が長すぎると、masterダウンタイム後に損失する可能性のあるデータが多すぎると判断した場合、書き込み要求を拒否することで、masterダウンタイムにおけるslaveに一部のデータが同期していないため、データ損失が低減する制御可能な範囲内であることを確認できます.
(2)脳裂のデータロスを減らす
1つのmasterに脳裂が発生し、他のslaveと接続が失われた場合、上記の2つの構成は、指定された数のslaveにデータを送信し続けることができず、slaveが10秒以上自分のackメッセージを送信していない場合、クライアントの書き込み要求を直接拒否することを保証することができます.
このように脳裂後の古いmasterはclientの新しいデータを受け入れず、データの損失を避けることができます.
上記の構成では、いずれかのslaveと接続が失われ、10秒後にslaveが自分にackを与えていないことに気づいたら、新しい書き込み要求を拒否します.
そのため、脳裂のシーンでは、最大10秒のデータが失われます.
2哨兵マルチコア下層解析
1、sdownとodown変換メカニズム
sdownとodownの2つの失敗状態
sdownは主観的なダウンタイムで、一人の哨兵が自分でmasterがダウンタイムになったと思ったら、それは主観的なダウンタイムです.
ODownは客観的なダウンタイムであり、quorumの数の哨兵がmasterダウンタイムを感じている場合は、客観的なダウンタイムです.
sdownの達成条件は簡単で、1人の哨兵が1つのmasterをpingして、is-master-down-after-millisecondsが指定したミリ秒数を超えた後、主観的にmasterがダウンしたと思っています
sdownからodownへの変換の条件は簡単で、1人の哨兵が指定時間内にquorum指定数を受け取った他の哨兵もそのmasterがsdownだと思っているならば、odownだと思って、客観的にmasterがダウンしたと思っています
2、歩哨集団の自動発見メカニズム
歩哨同士の発見は、redisのpub/subシステムによって実現され、各歩哨は_sentinel__:helloというchannelからメッセージが送られ、他のすべての哨兵がこのメッセージを消費し、他の哨兵の存在を感知することができます.
2秒ごとに、各哨兵は自分が監視しているmaster+slavesに対応しています.sentinel__:hello channelでは、自分のhost、ip、runid、そしてこのmasterの監視構成に関するメッセージが送信されます.
各哨兵も自分の監視する各master+slavesの対応を監視します_sentinel__:hello channel、そして同じmaster+slavesを傍受している他の哨兵の存在を感知します
各哨兵は他の哨兵とmasterの監視配置を交換し、互いに監視配置の同期を行う.
3、slave配置の自動修正
哨兵はslaveのいくつかの配置を自動的に修正する責任を負います.例えば、slaveが潜在的なmaster候補になるには、哨兵はslaveが既存のmasterのデータをコピーしていることを確保します.slaveが誤ったマスターに接続されている場合、例えばフェイルオーバ後、哨兵は正しいマスターに接続されていることを確認します.
4、slave->master選挙アルゴリズム
マスターがodownとみなされ、majority哨兵がホスト切替を許可すると、ある哨兵がホスト切替操作を実行し、まずslaveを選択します.
slaveの情報を考慮します
(1)masterとの接続切断時間(2)slave優先度(3)offset(4)run idのコピー
slaveとmasterの接続がdown-after-millisecondsの10倍を超え、masterのダウンタイムが長くなった場合、slaveはmasterに選挙するのに適していないと考えられます.
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
次にslaveをソートします
(1)slave優先度に従ってソートし、slave priorityが低いほど優先度が高くなる(2)slave priorityが同じであれば、replica offsetを見て、どのslaveがより多くのデータをコピーしたか、offsetが近いほど優先度が高くなる(3)上記の2つの条件が同じであれば、run idが比較的小さいslaveを選択する
5、quorumとmajority
毎回1人の哨兵が主備を切り替えなければならない.まずquorum数の哨兵がodownと思って、それから1人の哨兵を選んで切り替えなければならない.この哨兵はmajority哨兵の許可を得なければ、正式に切り替えを実行できない.
quorumしかし、quorum>=majorityの場合、5人の哨兵、quorumは5人の哨兵のように、quorumの数の哨兵が許可しなければならない.5人の哨兵が許可に同意しなければ、切り替えを実行できない.
6、configuration epoch
歩哨は1セットのredis master+slaveに対して監視を行って、相応の監視の配置があります
切り替えを実行する哨兵は、切り替える新しいmaster(salve->master)からconfiguration epochを得ます.これがversion番号で、切り替えるたびにversion番号が唯一でなければなりません.
最初に選挙された哨兵の切り替えに失敗した場合、他の哨兵はfailover-timeout時間を待ってから切り替えを続行し、新しいconfiguration epochを新しいversion号として再取得します.
7、configuraiton伝播
哨兵が切替を完了すると、自分のローカル更新で最新のmaster構成が生成され、他の哨兵に同期します.
ここでは以前のversion号が重要でした.様々なニュースは1つのchannelを通じて発表され、傍受されていたので、1人の哨兵が新しい切り替えを完了した後、新しいmaster配置は新しいversion号についています.
他の哨兵はバージョン番号の大きさに応じて自分のマスター配置を更新しています
1、哨兵の紹介
sentinel、中国語名は哨兵です
哨兵はredisクラスタアーキテクチャにおいて非常に重要なコンポーネントであり、主な機能は以下の通りである.
(1)クラスタモニタリング、redis masterとslaveプロセスが正常に動作しているかどうかをモニタリングする(2)メッセージ通知、あるredisインスタンスに障害がある場合、哨兵は管理者(3)にアラーム通知としてメッセージを送信し、master nodeがオフになった場合、slave node上(4)構成センターに自動的に移行し、障害移行が発生した場合、clientクライアントに新しいmasterアドレスを通知する
歩哨自体も分布式で、歩哨集団として運行し、互いに協力して仕事をしている.
(1)フェイルオーバの場合、1つのmaster nodeがダウンしていると判断し、大部分の哨兵が同意しなければならない.分布式選挙の問題にかかわる(2)一部の哨兵ノードが切れても、哨兵クラスタは正常に動作する.高可用性メカニズムの重要な構成部分であるフェイルオーバシステム自体が単点であれば、お父さんになるからだ.
現在はsentinel 2バージョンが採用されており、sentinel 2はsentinel 1に比べて多くのコードを書き換え、主にフェイルオーバのメカニズムとアルゴリズムをより丈夫で簡単にする.
2、哨兵の核心知識
(1)哨兵は少なくとも3つの実例を必要とし、自分の頑丈性を保証する(2)哨兵+redis主従の配置アーキテクチャは、データのゼロ損失を保証することはなく、redisクラスタの高可用性を保証するしかない(3)哨兵+redis主従のこのような複雑な配置アーキテクチャに対して、できるだけテスト環境と生産環境で、十分なテストと訓練を行う
3、なぜredis哨兵集団は2つのノードだけで正常に動作しないのですか?
哨兵集団は2つ以上のノードを配置しなければならない.
哨兵集団に哨兵インスタンスが2つしか配置されていない場合quorum=1
±—+ ±—+ | M1 |---------| R1 | | S1 | | S2 | ±—+ ±—+
Configuration: quorum = 1
masterダウンタイム、s 1とs 2のうち1人の哨兵がmasterダウンタイムであれば切替可能と考え、同時にs 1とs 2の中で1人の哨兵を選出して故障移転を実行する
同時にこの場合、majority、つまり大多数の歩哨が運行している必要があり、2人の歩哨のmajorityは2(2のmajority=2、3のmajority=2、5のmajority=3、4のmajority=2)で、2人の歩哨が運行しているので、フェイルオーバーを許可することができます
しかし、M 1とS 1全体がダウンした場合、哨兵は1人しかいません.この場合、majorityはフェイルオーバを許可しません.もう1台のマシンにはR 1がありますが、フェイルオーバは実行されません.
4、経典の3ノード歩哨集団
+----+
| M1 |
| S1 |
+----+
|
±—+ | ±—+ | R2 |----±—| R3 | | S2 | | S3 | ±—+ ±—+
Configuration: quorum = 2,majority
M 1がダウンした場合、3人の哨兵が2人残っており、S 2とS 3はマスターがダウンしたと一致して認識し、1人を選出してフェイルオーバを実行することができる.
同時に3人の歩哨のmajorityは2なので、残りの2人の歩哨が運行していて、フェイルオーバーが許されます
2両データ消失の場合
(1)非同期レプリケーションによるデータ損失
マスター->slaveのレプリケーションは非同期なので、一部のデータがslaveにレプリケートされていない場合、マスターはダウンタイムになり、データの一部が失われる可能性があります.
(2)脳裂によるデータ消失
脳裂、つまり、あるマスターがいたマシンが突然正常なネットワークから離れ、他のslaveマシンと接続できなくなったが、実際にはマスターが稼働している.
この時、哨兵はmasterがダウンしたと思って選挙を開き、他のslaveをmasterに切り替えたかもしれない.
このとき,クラスタには2つのmaster,すなわちいわゆる脳裂がある.
このとき、あるslaveがマスターに切り替わったが、クライアントが新しいマスターに切り替わっていない可能性があり、古いマスターに書き続けたデータも失われている可能性がある
そのため古いマスターが再び復元されると、slaveとして新しいマスターに掛けられ、自分のデータが空になり、新しいマスターからデータがコピーされます.
非同期レプリケーションと脳クラックによるデータ損失の解決
min-slaves-to-write 1 min-slaves-max-lag 10
少なくとも1つのslaveが必要であり、データのコピーと同期の遅延は10秒を超えてはならない.
すべてのslaveでデータのコピーと同期の遅延が10秒を超えると、masterはリクエストを受信しません.
上記の2つの構成は、非同期レプリケーションと脳クラックによるデータ損失を低減することができます.
(1)非同期レプリケーションによるデータ損失の低減
min-slaves-max-lagという構成があれば、slaveレプリケーションデータとackの遅延が長すぎると、masterダウンタイム後に損失する可能性のあるデータが多すぎると判断した場合、書き込み要求を拒否することで、masterダウンタイムにおけるslaveに一部のデータが同期していないため、データ損失が低減する制御可能な範囲内であることを確認できます.
(2)脳裂のデータロスを減らす
1つのmasterに脳裂が発生し、他のslaveと接続が失われた場合、上記の2つの構成は、指定された数のslaveにデータを送信し続けることができず、slaveが10秒以上自分のackメッセージを送信していない場合、クライアントの書き込み要求を直接拒否することを保証することができます.
このように脳裂後の古いmasterはclientの新しいデータを受け入れず、データの損失を避けることができます.
上記の構成では、いずれかのslaveと接続が失われ、10秒後にslaveが自分にackを与えていないことに気づいたら、新しい書き込み要求を拒否します.
そのため、脳裂のシーンでは、最大10秒のデータが失われます.
2哨兵マルチコア下層解析
1、sdownとodown変換メカニズム
sdownとodownの2つの失敗状態
sdownは主観的なダウンタイムで、一人の哨兵が自分でmasterがダウンタイムになったと思ったら、それは主観的なダウンタイムです.
ODownは客観的なダウンタイムであり、quorumの数の哨兵がmasterダウンタイムを感じている場合は、客観的なダウンタイムです.
sdownの達成条件は簡単で、1人の哨兵が1つのmasterをpingして、is-master-down-after-millisecondsが指定したミリ秒数を超えた後、主観的にmasterがダウンしたと思っています
sdownからodownへの変換の条件は簡単で、1人の哨兵が指定時間内にquorum指定数を受け取った他の哨兵もそのmasterがsdownだと思っているならば、odownだと思って、客観的にmasterがダウンしたと思っています
2、歩哨集団の自動発見メカニズム
歩哨同士の発見は、redisのpub/subシステムによって実現され、各歩哨は_sentinel__:helloというchannelからメッセージが送られ、他のすべての哨兵がこのメッセージを消費し、他の哨兵の存在を感知することができます.
2秒ごとに、各哨兵は自分が監視しているmaster+slavesに対応しています.sentinel__:hello channelでは、自分のhost、ip、runid、そしてこのmasterの監視構成に関するメッセージが送信されます.
各哨兵も自分の監視する各master+slavesの対応を監視します_sentinel__:hello channel、そして同じmaster+slavesを傍受している他の哨兵の存在を感知します
各哨兵は他の哨兵とmasterの監視配置を交換し、互いに監視配置の同期を行う.
3、slave配置の自動修正
哨兵はslaveのいくつかの配置を自動的に修正する責任を負います.例えば、slaveが潜在的なmaster候補になるには、哨兵はslaveが既存のmasterのデータをコピーしていることを確保します.slaveが誤ったマスターに接続されている場合、例えばフェイルオーバ後、哨兵は正しいマスターに接続されていることを確認します.
4、slave->master選挙アルゴリズム
マスターがodownとみなされ、majority哨兵がホスト切替を許可すると、ある哨兵がホスト切替操作を実行し、まずslaveを選択します.
slaveの情報を考慮します
(1)masterとの接続切断時間(2)slave優先度(3)offset(4)run idのコピー
slaveとmasterの接続がdown-after-millisecondsの10倍を超え、masterのダウンタイムが長くなった場合、slaveはmasterに選挙するのに適していないと考えられます.
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
次にslaveをソートします
(1)slave優先度に従ってソートし、slave priorityが低いほど優先度が高くなる(2)slave priorityが同じであれば、replica offsetを見て、どのslaveがより多くのデータをコピーしたか、offsetが近いほど優先度が高くなる(3)上記の2つの条件が同じであれば、run idが比較的小さいslaveを選択する
5、quorumとmajority
毎回1人の哨兵が主備を切り替えなければならない.まずquorum数の哨兵がodownと思って、それから1人の哨兵を選んで切り替えなければならない.この哨兵はmajority哨兵の許可を得なければ、正式に切り替えを実行できない.
quorum
6、configuration epoch
歩哨は1セットのredis master+slaveに対して監視を行って、相応の監視の配置があります
切り替えを実行する哨兵は、切り替える新しいmaster(salve->master)からconfiguration epochを得ます.これがversion番号で、切り替えるたびにversion番号が唯一でなければなりません.
最初に選挙された哨兵の切り替えに失敗した場合、他の哨兵はfailover-timeout時間を待ってから切り替えを続行し、新しいconfiguration epochを新しいversion号として再取得します.
7、configuraiton伝播
哨兵が切替を完了すると、自分のローカル更新で最新のmaster構成が生成され、他の哨兵に同期します.
ここでは以前のversion号が重要でした.様々なニュースは1つのchannelを通じて発表され、傍受されていたので、1人の哨兵が新しい切り替えを完了した後、新しいmaster配置は新しいversion号についています.
他の哨兵はバージョン番号の大きさに応じて自分のマスター配置を更新しています