0

3 つの Redis インスタンス (1 つのマスターと 2 つのスレーブ) と 3 つの Sentinel インスタンスを含むアーキテクチャがあります。その前にHaProxyがあります。マスター Redis インスタンスがダウンするまで、すべてが正常に機能します。新しいマスターは、Sentinel によって適切に選択されます。ただし、古いマスター (現在はダウンしている) は、スレーブになるように再構成されていません。その結果、そのインスタンスが再び起動すると、短時間 (約 11 秒) の間 2 つのマスターが存在します。その後、起動されたインスタンスは適切にスレーブにダウングレードされます。

マスターがダウンすると、すぐにスレーブにダウングレードされるように機能するべきではありませんか? それを持って、再起したら即奴隷だ。(Redis 2.8 以降?) その CONFIG REWRITE 機能があるため、Redis インスタンスがダウンしているときに構成を変更できないことを私は知っています。

しばらくの間 2 つのマスターを持つことは私にとって問題です。なぜなら、HaProxy は 1 つのマスター Redis にリクエストを送信する代わりに、その短い期間、これら 2 つのマスター間の負荷分散を行うからです。

失敗したマスターをすぐにスレーブにダウングレードする方法はありますか?

明らかに、Sentinel タイムアウトを変更しました。

マスターがダウンした後の Sentinel および Redis インスタンスからのいくつかのログを次に示します。

センチネル

81358:X 23 Jan 22:12:03.088 # +sdown master redis-ha 127.0.0.1                       63797.0.0.1 26381 @ redis-ha 127.0.0.1 6379
81358:X 23 Jan 22:12:03.149 # +new-epoch 1
81358:X 23 Jan 22:12:03.149 # +vote-for-leader 6b5b5882443a1d738ab6849ecf4bc6b9b32ec142 1
81358:X 23 Jan 22:12:03.174 # +odown master redis-ha 127.0.0.1 6379 #quorum 3/2
81358:X 23 Jan 22:12:03.174 # Next failover delay: I will not start a failover before Sat Jan 23 22:12:09 2016
81358:X 23 Jan 22:12:04.265 # +config-update-from sentinel 127.0.0.1:26381 127.0.0.1 26381 @ redis-ha 127.0.0.1 6379
81358:X 23 Jan 22:12:04.265 # +switch-master redis-ha 127.0.0.1 6379 127.0.0.1 6381
81358:X 23 Jan 22:12:04.266 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ redis-ha 127.0.0.1 6381
81358:X 23 Jan 22:12:04.266 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ redis-ha 127.0.0.1 6381
81358:X 23 Jan 22:12:06.297 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ redis-ha 127.0.0.1 6381

レディス

81354:S 23 Jan 22:12:03.341 * MASTER <-> SLAVE sync started
81354:S 23 Jan 22:12:03.341 # Error condition on socket for SYNC: Connection refused
81354:S 23 Jan 22:12:04.265 * Discarding previously cached master state.
81354:S 23 Jan 22:12:04.265 * SLAVE OF 127.0.0.1:6381 enabled (user request from 'id=7 addr=127.0.0.1:57784 fd=10 name=sentinel-6b5b5882-cmd age=425 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=14 qbuf-free=32754 obl=36 oll=0 omem=0 events=rw cmd=exec')
81354:S 23 Jan 22:12:04.265 # CONFIG REWRITE executed with success.
81354:S 23 Jan 22:12:04.371 * Connecting to MASTER 127.0.0.1:6381
81354:S 23 Jan 22:12:04.371 * MASTER <-> SLAVE sync started
81354:S 23 Jan 22:12:04.371 * Non blocking connect for SYNC fired the event.
81354:S 23 Jan 22:12:04.371 * Master replied to PING, replication can continue...
81354:S 23 Jan 22:12:04.371 * Partial resynchronization not possible (no cached master)
81354:S 23 Jan 22:12:04.372 * Full resync from master: 07b3c8f64bbb9076d7e97799a53b8b290ecf470b:1
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: receiving 860 bytes from master
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: Flushing old data
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: Loading DB in memory
81354:S 23 Jan 22:12:04.467 * MASTER <-> SLAVE sync: Finished with success
4

3 に答える 3

0

Redis ノードがダウンした場合、回復すると、roleダウンする前と同じ状態で回復します。ping を実行できない場合、Sentinel はノードを再構成できません。そのため、ノードが復旧してから、Sentinel がそれを認識して再構成するまでに少し時間がかかります。これは、マルチマスター状態を説明しています。

Haproxy を使用するように設定されている場合、1 つの回避策は、プロセスを開始する前に Redis ノードの役割を再構成することです。redis.conf に SLAVEOF エントリがある限り、Redis はスレーブとして起動します。この回避策の主な問題は、ネットワーク パーティションのシナリオが解決されないことです。

それが役立つことを願っています。

于 2016-12-02T13:55:51.893 に答える