11.Redisセンチネル高可用性クラスタ

著者：中国石シャン

Redisのセンチネル高可用性クラスタ

センチネルはじめに

センチネル、中国名はセンチネルです。Sentinelは、主に以下の機能では、Redisのクラスタ構成で非常に重要な機関です。

• 監視クラスター：マスタとスレーブが正常に動作しているプロセスを監視する責任があるのRedis。
• メッセージ通知：Redisのインスタンスが失敗した場合は、管理者にアラーム通知としてメッセージを送信するための責任を見張り。
• フェイルオーバー：マスターノードハングした場合、自動的にスレーブノードに転送されます。
• コンフィギュレーション・センター：フェールオーバーが発生した場合、クライアントに新しいマスタアドレスをクライアントに通知します。

お互いが一緒に動作するようにとのRedisが配布され、それ自体をクラスタ化するための高可用性を実現SENTINEL、歩哨は、クラスタとして動作します。

• フェイルオーバー、マスターノードがダウンしたかどうかを判断するが、警備員のほとんどはそれに同意を必要としている、それが分散選挙の問題になります。
• 高可用性メカニズム自体の重要な一環として、フェールオーバーシステムは、単一のポイントがある場合ので、いくつかのセンチネルリンパ節ハング、センチネルクラスタがまだ、正常に動作することができたとしても、それは非常にピットの父になります。

センティネルのコア知識

• Sentinelはその堅牢性を確保するために、少なくとも3つのインスタンスが必要です。
• センチネル+は、展開アーキテクチャマスター・スレーブが保証データ損失ゼロではありませんRedisの唯一の高可用性のRedisクラスターを確保することができます。
• この複雑なデプロイメントのセンチネル+ Redisのマスター・スレーブ・アーキテクチャの場合、可能な限り、テスト環境と本番環境のように、我々は十分なテストや訓練を行いました。

センチネルクラスタはセンチネルセンチネルは、2つのインスタンス、定足数= 1を展開した場合にのみ、クラスタ2つの以上のノードを展開する必要があります。

+----+         +----+
| M1 |---------| R1 |
| S1 |         | S2 |
+----+         +----+

設定は  quorum=1長いマスターがダウンしているというセンチネルがあるとして、マスタダウン、S1、S2は、それを切り替えることができた場合、S1とS2センチネルながらフェイルオーバーを実行することを選択します。しかし同時にこれは警備員のほとんどが実行されている、である必要大半、です。

2 个哨兵，majority=2
3 个哨兵，majority=2
4 个哨兵，majority=2
5 个哨兵，majority=3
...

この時間はちょうどM1プロセス、センチネルS1通常動作ダウンしている場合、フェイルオーバーはOKです。別のマシンR1が存在するものの、全体の機械のダウンタイムM1とS1の動作場合、唯一のセンチネルは、その後、フェイルオーバーを可能にするいかなる大部分は、存在しないが、フェイルオーバ実行しません。

このような古典的な3-センチネルノードクラスタ：

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

コンフィギュレーション  quorum=2、機械が停止している場合M1は、その後、残りの3つのセンチネル2、S2及びS3がマスタがダウンしていることに同意することができる場合は、次の3つのセンチネル大部分は2であるが、次に、フェイルオーバーを実行することを選択し、実行中の残りの二つの警備員は、それがフェイルオーバーできるようにすることができます。

Sentinelは、スタンバイスイッチングデータ損失の問題をRedisの

データ損失の両方のケースとリードには

スタンバイ切替処理は、データが失われることがあります。

• によるデータ損失の非同期レプリケーション

マスター - >スレーブレプリケーションは非同期であるため、ので、いくつかのデータをスレーブにコピーされていないがあるかもしれない、それがダウンしたマスターは、その後、このデータの一部は失われます。

• 脳の分割によるデータ損失

言うことであるスプリットブレイン、突然、通常のネットワークの外に、マシンが他のスレーブに接続することはできませんが、実際にはマスターにも実行されているマスターマシン。このとき、センチネルは、マスターがダウンしていると思いますし、その後の選挙を回すかもしれない、他のスレーブスイッチがマスターになりました。今回は、クラスタは2つのマスター、いわゆるスプリットブレインを持つことになります。

このとき、スレーブは切り替えているが、マスターになりましたが、クライアントは新しいマスターへの切り替えに時間を過ごしましたが、また、古いマスターへの書き込みデータを継続していないことがあります。古いマスターが再び回復したときにそう、それは新しいマスターをハングアップするために奴隷のようになります、あなたのデータは、新しいマスタからのデータを再コピーし、クリアされます。このデータの一部が失われますので、新しいマスタデータ以降のクライアントは、書いていません。

データ損失の問題

次のとおりです。

分・スレーブ・ツー・書き込み1 
分-奴隷-MAX-ラグ10

表示，要求至少有 1 个 slave，数据复制和同步的延迟不能超过 10 秒。

如果说一旦所有的 slave，数据复制和同步的延迟都超过了 10 秒钟，那么这个时候，master 就不会再接收任何请求了。

• 减少异步复制数据的丢失

有了 min-slaves-max-lag 这个配置，就可以确保说，一旦 slave 复制数据和 ack 延时太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样可以把 master 宕机时由于部分数据未同步到 slave 导致的数据丢失降低的可控范围内。

• 减少脑裂的数据丢失

如果一个 master 出现了脑裂，跟其他 slave 丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的 slave 发送数据，而且 slave 超过 10 秒没有给自己 ack 消息，那么就直接拒绝客户端的写请求。因此在脑裂场景下，最多就丢失 10 秒的数据。

sdown 和 odown 转换机制

• sdown 是主观宕机，就一个哨兵如果自己觉得一个 master 宕机了，那么就是主观宕机
• odown 是客观宕机，如果 quorum 数量的哨兵都觉得一个 master 宕机了，那么就是客观宕机

sdown 达成的条件很简单，如果一个哨兵 ping 一个 master，超过了 is-master-down-after-milliseconds 指定的毫秒数之后，就主观认为 master 宕机了；如果一个哨兵在指定时间内，收到了 quorum 数量的其它哨兵也认为那个 master 是 sdown 的，那么就认为是 odown 了。

哨兵集群的自动发现机制

哨兵互相之间的发现，是通过 redis 的 pub/sub 系统实现的，每个哨兵都会往 __sentinel__:hello 这个 channel 里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在。

每隔两秒钟，每个哨兵都会往自己监控的某个 master+slaves 对应的 __sentinel__:hello channel 里发送一个消息，内容是自己的 host、ip 和 runid 还有对这个 master 的监控配置。

每个哨兵也会去监听自己监控的每个 master+slaves 对应的 __sentinel__:hello channel，然后去感知到同样在监听这个 master+slaves 的其他哨兵的存在。

每个哨兵还会跟其他哨兵交换对 master 的监控配置，互相进行监控配置的同步。

slave 配置的自动纠正

哨兵会负责自动纠正 slave 的一些配置，比如 slave 如果要成为潜在的 master 候选人，哨兵会确保 slave 复制现有 master 的数据；如果 slave 连接到了一个错误的 master 上，比如故障转移之后，那么哨兵会确保它们连接到正确的 master 上。

slave->master 选举算法

如果一个 master 被认为 odown 了，而且 majority 数量的哨兵都允许主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个 slave 来，会考虑 slave 的一些信息：

• 跟 master 断开连接的时长
• slave 优先级
• 复制 offset
• run id

如果一个 slave 跟 master 断开连接的时间已经超过了 down-after-milliseconds 的 10 倍，外加 master 宕机的时长，那么 slave 就被认为不适合选举为 master。

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下来会对 slave 进行排序：

• 按照 slave 优先级进行排序，slave priority 越低，优先级就越高。
• 如果 slave priority 相同，那么看 replica offset，哪个 slave 复制了越多的数据，offset 越靠后，优先级就越高。
• 上記2つの条件が同一である場合には、実行ID比較的小さいものスレーブを選択します。

定足数および過半数

スイッチオーバーを行うには歩哨、センチネルの最初のクォーラムに必要な数がodown考えるたびに、その後、センチネルを行うには、スイッチに選出され、センチネル歩哨の大半も、正式なハンドオーバーを実行するために許可する必要があります。

定足数<大部分、例えば5つのセンチネル、大部分が3である場合、定足数は、次の3つのセンチネルがハンドオーバ承認を行うことができ、2に設定されています。

しかし、定足数> =大多数の場合は、例えば5センチネルなど歩哨の承認定足数の数は、定足数は5である、あなたはスイッチングを実行するために5人の警備員を承認することに合意している必要がありますしている必要があります。

コンフィギュレーション・エポック

Sentinelは、マスター+スレーブは、モニターの対応する構成を監視しますRedisの。

センチネルを行うハンドオーバが数バージョン、バージョン番号あなたは一意である必要があります切り替えるたびに、新しいマスター（salve->マスター）の設定エポック、への切り替えから取得します。

最初に選出されたセンチネルスイッチに障害が発生した場合は、その後、他のセンチネルは、フェイルオーバー・タイムアウト時間を待つ、その後、新しいバージョン番号として、新しいコンフィギュレーション・エポックを取得します。この時点でスイッチを引き継ぐために進んでください。

コンフィギュレーション・伝播

Sentinelは、ハンドオーバを完了した後、独自のローカルマスター構成の最新世代に更新され、その後、同期の他のセンチネルには、によって前に言われている  pub/sub メッセージメカニズム。

メッセージのすべての種類は、新しいスイッチを完了するために、そう歩哨後、掲載してチャネルを介してに耳を傾けているので、ここではバージョン番号は、非常に重要である前に、新しいマスター構成は、新しいバージョン番号が続いています。他の歩哨は、そのマスター構成を更新するには、バージョン番号の大きさに基づいています。