Redis哨兵の詳細
4917 ワード
1哨兵の役割
哨兵はredisクラスタアーキテクチャにおいて非常に重要なコンポーネントであり、主な機能は以下の通りである.クラスタモニタリング:redis masterとslaveプロセスが正常に動作するかどうかをモニタリングする.メッセージ通知:redisインスタンスに障害がある場合、哨兵は管理者3にメッセージを送信する責任を負う.フェイルオーバ:master nodeがオフの場合、slave nodeに自動的に移行します.コンフィギュレーションセンター:フェイルオーバが発生した場合、クライアントに新しいmasterアドレスを通知します.
2哨兵の核心知識が故障して移転した時、1つのmaster nodeがダウンタイムだと判断し、大部分の哨兵が同意しなければならない.分布式選挙の問題 に関連している.哨兵は少なくとも3つの実例を必要とし、自分の丈夫性を保証する 哨兵+redis主従の配置アーキテクチャは、データのゼロ損失を保証することはなく、redisクラスタの高可用性 しか保証できない.
3 sdownとodown sdownとodownの2つの失敗状態 sdownは主観的なダウンタイムで、一人の哨兵が自分でmasterがダウンタイムだと思ったら、主観的なダウンタイム です. odownは客観的なダウンタイムであり、quorumの数の哨兵がmasterダウンタイムを感じている場合は、客観的なダウンタイム です. sdownが達成した条件:1人の歩哨が1つのmasterをpingし、is-master-down-after-millisecondsが指定したミリ秒数を超えた後、masterがダウンしたと主観的に考えられる odownが達成した条件:1人の哨兵が指定時間内にquorum指定数を受け取った他の哨兵もそのmasterがsdownだと思っていたらodownだと思っていたが、客観的にmasterがダウンしたと思っていた 4 quorumとmajority quorum:odownの最低哨兵数を確認 majority:主従切替を許可する最低の哨兵数 毎回1人の哨兵が主備切替を行うには、まずquorum数の哨兵がodownと判断し、それから1人の哨兵を選出して切替を行う必要があります.この哨兵はmajority哨兵の許可を得なければ、 を正式に実行できません. quorum=majorityであれば、5人の哨兵、quorumが5であれば、5人の哨兵が授権に同意しなければ を実行できません.
5なぜ哨兵は少なくとも3つのノードを持っているのか
哨兵集団は2つ以上のノードを配置しなければならない.哨兵クラスタに2つの哨兵インスタンスしか配置されていない場合、そのmajorityは2(2のmajority=2、3のmajority=2、5のmajority=3、4のmajority=2)であり、そのうちの1つがダウンした場合、majority>=2という条件を満たすことができず、masterが故障した場合でも主従切替ができない.
6脳裂およびredisデータ消失
メインスタンバイ切替のプロセスでは、データロス(1)非同期レプリケーションによるデータロスを招く可能性があります.master->slaveのレプリケーションは非同期であるため、一部のデータがslaveにレプリケートされていない可能性があります.masterはダウンタイムになります.このとき、これらのデータの一部が失われます(2)脳裂によるデータロス脳裂、つまり、あるmasterのあるマシンが突然正常なネットワークから離れ、他のslaveマシンと接続できません.しかし実際にはmasterが稼働している場合、哨兵はmasterがダウンしたと思って選挙を開き、他のslaveをmasterに切り替えている可能性があります.このとき、クラスタには2つのmaster、いわゆる脳裂があります.このとき、あるslaveがマスターに切り替わったものの、クライアントがまだ新しいマスターに切り替わっていない可能性があり、また古いマスターへの継続書き込みデータも失われている可能性があるため、古いマスターが再び復元されると、新しいマスターにslaveとして掛けられ、自分のデータが空になり、新しいマスターからデータがコピーされ直す
7データ損失を最小限に抑える方法
次の2つの構成は、非同期レプリケーションと脳クラックによるデータ損失を低減します.
解釈:少なくとも1つのslaveが要求され、データのコピーと同期の遅延は10秒を超えてはならない.もしすべてのslaveがデータのコピーと同期の遅延が10秒を超えたら、masterはもう何の要求も受信しない(1)非同期のコピーのデータ損失を減らすmin-slaves-max-lagという構成があれば、slaveのコピーデータとackの遅延が長すぎると保証できる.masterダウンタイム後に損失する可能性のあるデータが多すぎると判断した場合、書き込み要求を拒否することで、masterダウン時に一部のデータがslaveに同期していないため、データ損失が減少する制御可能な範囲内(2)脳クラックのデータ損失を減少させることができる.1つのmasterに脳クラックが発生し、他のslaveと接続が失われた場合、上記の2つの構成は、指定された数のslaveにデータを送信し続けることができなければ、またslaveが10秒を超えて自分にackメッセージを与えていない場合は、クライアントの書き込み要求を直接拒否することで、脳裂後の古いマスターはclientの新しいデータを受け入れず、データ損失を回避する上での構成が確保され、いずれかのslaveと接続を失い、10秒後にslaveが自分にackを与えていないことに気づいたら、新しい書き込み要求を拒否するため、脳裂シーンでは、最大10秒のデータが失われる
8哨兵集団の自動発見メカニズム
歩哨同士の発見は、redisのpub/subシステムによって実現され、各歩哨はsentinel:helloというchannelにメッセージを送信し、このとき他の歩哨はすべてこのメッセージを消費することができ、他の歩哨の存在を2秒ごとに感知し、各歩哨は自分が監視しているあるmaster+slaves対応のsentinel:hello channelにメッセージを送信し、内容は自分のhost、ipとrunidはまた、このmasterの監視配置各哨兵も自分が監視している各master+slavesに対応するsentinel:hello channelを監視し、同じようにこのmaster+slavesを監視している他の哨兵の存在を感知し、各哨兵は他の哨兵とmasterの監視配置を交換し、互いに監視配置の同期を行う
9 slave構成の自動修正
哨兵はslaveのいくつかの配置を自動的に修正する責任を負います.例えば、slaveが潜在的なmaster候補になるには、哨兵はslaveが既存のmasterのデータをコピーしていることを確保します.slaveが誤ったマスターに接続されている場合、例えばフェイルオーバ後、哨兵は正しいマスターに接続されていることを確認します.
10 master選挙アルゴリズム
マスターがodownとみなされ、majority哨兵がプライマリ・スタンバイの切り替えを許可すると、ある哨兵がプライマリ・スタンバイの切り替え操作を実行し、まずslaveを選択します.選挙の時にslaveのいくつかの情報を考慮します:(1)masterと接続を切断する時間長(2)slave優先度(3)offset(4)run idをコピーするもし1つのslaveがmasterと接続を切断してすでにdown-after-millisecondsの10倍を超えて、masterがダウンタイムする時間長を加えるならば、slaveはmasterに選挙するのに適していないと考えられて、計算式は以下の通りです:
次にslaveをソートします(1)slave優先度に従ってソートします.slave priorityが低いほど優先度が高くなります(2)slave priorityが同じであればreplica offsetを見て、どのslaveが多くのデータをコピーしているかを見て、offsetが後ろにあるほど優先度が高くなります(3)上記の2つの条件が同じであればrun idが小さいslaveを選択します.
11 configuration epoch
歩哨はredis master+slaveを監視し、対応する監視の配置が切替を実行する歩哨は、切替する新しいmaster(salve->master)からconfiguration epochを得る.これがversion号であり、切替するたびにversion号が唯一でなければならない.最初に選挙された歩哨の切替が失敗した場合、他の歩哨はfailover-timeout時間を待つ.その後、切り替えを続行すると、新しいバージョン番号として新しいconfiguration epochが再取得されます.
12 configuraiton伝播
哨兵が切替を完了すると、自分のローカルで更新して最新のmaster構成を生成し、他の哨兵に同期します.つまり、pub/subメッセージメカニズムを通じて、ここの前のversion番号が重要です.様々なメッセージは1つのchannelで公開され、傍受されているので、1人の哨兵が新しい切替を完了した後、新しいマスター構成は、新しいバージョン番号に従う他の哨兵がバージョン番号の大きさに応じて自分のマスター構成を更新します.
哨兵はredisクラスタアーキテクチャにおいて非常に重要なコンポーネントであり、主な機能は以下の通りである.クラスタモニタリング:redis masterとslaveプロセスが正常に動作するかどうかをモニタリングする.メッセージ通知:redisインスタンスに障害がある場合、哨兵は管理者3にメッセージを送信する責任を負う.フェイルオーバ:master nodeがオフの場合、slave nodeに自動的に移行します.コンフィギュレーションセンター:フェイルオーバが発生した場合、クライアントに新しいmasterアドレスを通知します.
2哨兵の核心知識
3 sdownとodown
5なぜ哨兵は少なくとも3つのノードを持っているのか
哨兵集団は2つ以上のノードを配置しなければならない.哨兵クラスタに2つの哨兵インスタンスしか配置されていない場合、そのmajorityは2(2のmajority=2、3のmajority=2、5のmajority=3、4のmajority=2)であり、そのうちの1つがダウンした場合、majority>=2という条件を満たすことができず、masterが故障した場合でも主従切替ができない.
6脳裂およびredisデータ消失
メインスタンバイ切替のプロセスでは、データロス(1)非同期レプリケーションによるデータロスを招く可能性があります.master->slaveのレプリケーションは非同期であるため、一部のデータがslaveにレプリケートされていない可能性があります.masterはダウンタイムになります.このとき、これらのデータの一部が失われます(2)脳裂によるデータロス脳裂、つまり、あるmasterのあるマシンが突然正常なネットワークから離れ、他のslaveマシンと接続できません.しかし実際にはmasterが稼働している場合、哨兵はmasterがダウンしたと思って選挙を開き、他のslaveをmasterに切り替えている可能性があります.このとき、クラスタには2つのmaster、いわゆる脳裂があります.このとき、あるslaveがマスターに切り替わったものの、クライアントがまだ新しいマスターに切り替わっていない可能性があり、また古いマスターへの継続書き込みデータも失われている可能性があるため、古いマスターが再び復元されると、新しいマスターにslaveとして掛けられ、自分のデータが空になり、新しいマスターからデータがコピーされ直す
7データ損失を最小限に抑える方法
次の2つの構成は、非同期レプリケーションと脳クラックによるデータ損失を低減します.
min-slaves-to-write 1
min-slaves-max-lag 10解釈:少なくとも1つのslaveが要求され、データのコピーと同期の遅延は10秒を超えてはならない.もしすべてのslaveがデータのコピーと同期の遅延が10秒を超えたら、masterはもう何の要求も受信しない(1)非同期のコピーのデータ損失を減らすmin-slaves-max-lagという構成があれば、slaveのコピーデータとackの遅延が長すぎると保証できる.masterダウンタイム後に損失する可能性のあるデータが多すぎると判断した場合、書き込み要求を拒否することで、masterダウン時に一部のデータがslaveに同期していないため、データ損失が減少する制御可能な範囲内(2)脳クラックのデータ損失を減少させることができる.1つのmasterに脳クラックが発生し、他のslaveと接続が失われた場合、上記の2つの構成は、指定された数のslaveにデータを送信し続けることができなければ、またslaveが10秒を超えて自分にackメッセージを与えていない場合は、クライアントの書き込み要求を直接拒否することで、脳裂後の古いマスターはclientの新しいデータを受け入れず、データ損失を回避する上での構成が確保され、いずれかのslaveと接続を失い、10秒後にslaveが自分にackを与えていないことに気づいたら、新しい書き込み要求を拒否するため、脳裂シーンでは、最大10秒のデータが失われる
8哨兵集団の自動発見メカニズム
歩哨同士の発見は、redisのpub/subシステムによって実現され、各歩哨はsentinel:helloというchannelにメッセージを送信し、このとき他の歩哨はすべてこのメッセージを消費することができ、他の歩哨の存在を2秒ごとに感知し、各歩哨は自分が監視しているあるmaster+slaves対応のsentinel:hello channelにメッセージを送信し、内容は自分のhost、ipとrunidはまた、このmasterの監視配置各哨兵も自分が監視している各master+slavesに対応するsentinel:hello channelを監視し、同じようにこのmaster+slavesを監視している他の哨兵の存在を感知し、各哨兵は他の哨兵とmasterの監視配置を交換し、互いに監視配置の同期を行う
9 slave構成の自動修正
哨兵はslaveのいくつかの配置を自動的に修正する責任を負います.例えば、slaveが潜在的なmaster候補になるには、哨兵はslaveが既存のmasterのデータをコピーしていることを確保します.slaveが誤ったマスターに接続されている場合、例えばフェイルオーバ後、哨兵は正しいマスターに接続されていることを確認します.
10 master選挙アルゴリズム
マスターがodownとみなされ、majority哨兵がプライマリ・スタンバイの切り替えを許可すると、ある哨兵がプライマリ・スタンバイの切り替え操作を実行し、まずslaveを選択します.選挙の時にslaveのいくつかの情報を考慮します:(1)masterと接続を切断する時間長(2)slave優先度(3)offset(4)run idをコピーするもし1つの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を選択します.
11 configuration epoch
歩哨はredis master+slaveを監視し、対応する監視の配置が切替を実行する歩哨は、切替する新しいmaster(salve->master)からconfiguration epochを得る.これがversion号であり、切替するたびにversion号が唯一でなければならない.最初に選挙された歩哨の切替が失敗した場合、他の歩哨はfailover-timeout時間を待つ.その後、切り替えを続行すると、新しいバージョン番号として新しいconfiguration epochが再取得されます.
12 configuraiton伝播
哨兵が切替を完了すると、自分のローカルで更新して最新のmaster構成を生成し、他の哨兵に同期します.つまり、pub/subメッセージメカニズムを通じて、ここの前のversion番号が重要です.様々なメッセージは1つのchannelで公開され、傍受されているので、1人の哨兵が新しい切替を完了した後、新しいマスター構成は、新しいバージョン番号に従う他の哨兵がバージョン番号の大きさに応じて自分のマスター構成を更新します.