Redis Centinelアーキテクチャの原理の詳細(四)

前言
前のRedis Sentinelアーキテクチャの原理の詳細(3)では、redis哨兵クラスタにおけるsentinelのリーダーがどのように選挙されるか、redis主従の中の新しいmasterがどのように選択されるかを紹介し、ここでは、Sentinelクラスタのquorumとmajority、configuration epoch、およびRedis Sentinelが発生する可能性のある問題と解決方法を皆さんと一緒に学習します.
Sentineクラスタのquorumとmajority
quorumはsentinelです.confで手動で構成された場合、デフォルトは2であり、quorum数以上のsentinelがmasterの主観的なラインオフを考えている場合にのみ、sentinelクラスタがmasterの客観的なラインオフを考えていることを意味します.

# sentinel monitor [master-name] [master-ip] [master-port] [quorum] 
sentinel monitor mymaster 127.0.0.1 6379 2

sentinelクラスタがフェイルオーバを実行する際にleaderを選択する必要がある場合、majorityに関連します.majorityはsentinelクラスタの大部分のsentinelノードの個数を表し、max(quorum, majority)以上のノードがあるsentinelノードに投票してこそ、sentinelノードがleaderであることを確定することができます.majorityの計算方法は:num(sentinels) / 2 + 1、例えば:
2ノードのsentinelクラスタのmajorityが2 3ノードのsentinelクラスタのmajorityが2 4ノードのsentinelクラスタのmajorityが3 5ノードのsentinelクラスタのmajorityが3
したがってsentinelクラスタのノード数は少なくとも3つであり、ノード数が2の場合、1つのsentinelノードがダウンタイムした場合、残りの1つのノードは自分をleaderにすることはできない.2つのノードのsentinelクラスタのmajorityは2であるため、このとき2つのノードが残りのノードに投票しなくても、leaderを選択することができず、フェイルオーバができない.またquorumの値を<=majorityに設定すると、sentinelクラスタの残りのノードがmajority数を満たすとしてもquorum数を満たすことができない可能性がありますが、leaderを選択することができず、フェイルオーバもできません.
configuration epoch
configuration epochは現在のredis主従アーキテクチャの構成バージョン番号であり、sentinelクラスタ選挙リーダーでもフェイルオーバでも各sentinelノードに求められるconfiguration epochは同じであり、sentinel is-master-down-by-addrコマンドには現在の構成バージョン番号というパラメータが必要であり、選挙リーダー過程で今回の選挙に失敗すれば次の選挙を行うと構成バージョン番号が更新され、すなわち,選挙のたびに新しいconfiguration epochに対応し,フェイルオーバの過程においても各sentinelノードに同じconfiguration epochを使用することが要求される.フェイルオーバに成功すると、sentinel leaderは生成された最新のmaster構成を更新し、configuration epochも更新し、他のsentinelノードに同期します.これにより、sentinelクラスタに保存されているmaster、slave構成が最新であることが保証され、clientが要求すると最新の構成情報が得られます.
Redis Centinelで発生する可能性のある問題
redis sentinelは、2つの理由でデータが完全に失われないことを保証できません.

非同期レプリケーションによるデータ損失master->slaveのレプリケーションは非同期であるため、一部のデータがslaveにレプリケーションされていない可能性があり、masterはダウンタイムになり、このときこのデータは失われます.

redisサービス脳裂によるデータ損失脳裂、すなわち、あるmasterが存在する機器が突然ネットワーク障害を起こし、他のslave機器と接続できないが、実際にはmasterが稼働している.この時、哨兵はmasterがダウンしたと思って選挙を開き、他のslaveをmasterに切り替えたかもしれない.この時、クラスタには2つのmaster、いわゆる脳裂がある.このとき,あるslaveがmasterに切り替わったが,clientはまだ新しいmasterに切り替わる暇がなく,古いmasterに書き続けたデータが失われた.古いマスターが再び復元されると、slaveとして新しいマスターに掛けられ、自分のデータが空になり、新しいマスターからデータがコピーされます.

redisは、2つの構成パラメータを提供し、できるだけ少ないデータを失うことができます.

min-slaves-to-write 1
min-slaves-max-lag 10

最初のパラメータは、masterが少なくとも1つのslaveを正常にコピーする必要があることを示します.そうしないと、書き込み要求が拒否され、masterが可用性を失います.正常なレプリケーションと異常なレプリケーションは何ですか?これは2番目のパラメータによって制御され、その単位は秒であり、10 sがノードからのフィードバックを受信しなければ、ノードからの同期が正常ではないことを意味する.これにより、masterダウンタイム中のデータ損失を制御可能な範囲に低減できます.
redis-2.6バージョンはredis sentinel v 1バージョンを提供していますが、機能性と丈夫性に問題があります.redis sentinelを使用するには、2.8以上のバージョン、つまりv 2バージョンのredis sentinelを使用することをお勧めします.
まとめ
ここではsentinelクラスタにおけるquorumとmajorityパラメータの具体的な構成意義,configuration epochバージョン番号構成について学習した.redis哨兵はデータが絶対に失われないことを保証することができず、主従非同期複製過程のデータがタイムリーに同期していないか、ネットワーク要因による新しいmasterノードの選挙による脳裂などの問題が発生している.そのため、redis哨兵を選んで高可用性を実現する際には、リスクを最小限に抑える方法を考慮する必要があります.