0

大規模な redis フリート (12 個のセンチネル、それぞれ 1 つのマスターと 1 つのスレーブの 500 以上のシャード) でフェールオーバーにセンチネルを使用しようとしています。センチネルがコマンド +fix-slave-config を特定の redis ノードに繰り返し発行するという非常に奇妙な問題に遭遇しています。それだけの価値があるため、これが小規模で起こっていることに気づきませんでした。

2 つの特定の問題に気付きました。

  1. +上で述べたように、fix-slave-config メッセージ
  2. sentinel.conf は、特定のスレーブが 2 つのマスターを持つことを示しています (マスターは 1 つだけであるべきです)。

初期状態のフリートには、特定のスレーブ ノード XXX.XXX.XXX.177 とマスター XXX.XXX.XXX.244 があります (これらを合わせて、フリート内のシャード 188 を構成します)。ノードの停止がなければ、スレーブのマスターは XXX.XXX.XXX.96 (シャード 188 のマスター) に切り替えられ、その後切り替えられます。これは、スレーブ ノードとマスター ノードに SSH で接続し、redis-cli 情報を確認することで確認できます。すべての Redis ノードが正しい構成で開始されました。Sentinel ノードはすべて、sentinel.conf に正しい構成がありました。各 Sentinel には、これらのスレーブからマスターへの変更のたびにクエリを実行すると、まったく同じマスターのリストがあります。

私の 12 の歩哨全体で、次のログが記録されます。毎分、+fix-slave-config メッセージが送信されます。

Sentinel #8: 20096:X 22 Oct 01:41:49.793 * +fix-slave-config slave XXX.XXX.XXX.177:6379 XXX.XXX.XXX.177 6379 @ shard-188 XXX.XXX.XXX.96 6379
Sentinel #1: 9832:X 22 Oct 01:42:50.795 * +fix-slave-config slave XXX.XXX.XXX.177:6379 XXX.XXX.XXX.177 6379 @ shard-172 XXX.XXX.XXX.244 6379
Sentinel #6: 20528:X 22 Oct 01:43:52.458 * +fix-slave-config slave XXX.XXX.XXX.177:6379 XXX.XXX.XXX.177 6379 @ shard-188 XXX.XXX.XXX.96 6379
Sentinel #10: 20650:X 22 Oct 01:43:52.464 * +fix-slave-config slave XXX.XXX.XXX.177:6379 XXX.XXX.XXX.177 6379 @ shard-188 XXX.XXX.XXX.96 6379
Sentinel #2: 20838:X 22 Oct 01:44:53.489 * +fix-slave-config slave XXX.XXX.XXX.177:6379 XXX.XXX.XXX.177 6379 @ shard-172 XXX.XXX.XXX.244 6379

SENTINEL MASTERS コマンドの出力を次に示します。奇妙なことに、shard-188 には 2 つのスレーブがありますが、実際には 1 つしかないはずです。XXX.XXX.XXX.177 が shard-172 と shard-182 の下にある場合、出力は同じに見えます。

ケース 1) XXX.XXX.XXX.244 が XXX.XXX.XXX.177 のマスター

183)  1) "name"
      2) "shard-172"
      3) "ip"
      4) "XXX.XXX.XXX.244"
      5) "port"
      6) "6379"
      7) "runid"
      8) "ca02da1f0002a25a880e6765aed306b1857ae2f7"
      9) "flags"
     10) "master"
     11) "pending-commands"
     12) "0"
     13) "last-ping-sent"
     14) "0"
     15) "last-ok-ping-reply"
     16) "14"
     17) "last-ping-reply"
     18) "14"
     19) "down-after-milliseconds"
     20) "30000"
     21) "info-refresh"
     22) "5636"
     23) "role-reported"
     24) "master"
     25) "role-reported-time"
     26) "17154406"
     27) "config-epoch"
     28) "0"
     29) "num-slaves"
     30) "1"
     31) "num-other-sentinels"
     32) "12"
     33) "quorum"
     34) "7"
     35) "failover-timeout"
     36) "60000"
     37) "parallel-syncs"
     38) "1"
72)  1) "name"
      2) "shard-188"
      3) "ip"
      4) "XXX.XXX.XXX.96"
      5) "port"
      6) "6379"
      7) "runid"
      8) "95cd3a457ef71fc91ff1a1c5a6d5d4496b266167"
      9) "flags"
     10) "master"
     11) "pending-commands"
     12) "0"
     13) "last-ping-sent"
     14) "0"
     15) "last-ok-ping-reply"
     16) "927"
     17) "last-ping-reply"
     18) "927"
     19) "down-after-milliseconds"
     20) "30000"
     21) "info-refresh"
     22) "5333"
     23) "role-reported"
     24) "master"
     25) "role-reported-time"
     26) "17154312"
     27) "config-epoch"
     28) "0"
     29) "num-slaves"
     30) "2"
     31) "num-other-sentinels"
     32) "12"
     33) "quorum"
     34) "7"
     35) "failover-timeout"
     36) "60000"
     37) "parallel-syncs"
     38) "1"

ケース 2) XXX.XXX.XXX.96 が XXX.XXX.XXX.177 のマスター

79)  1) "name"
      2) "shard-172"
      3) "ip"
      4) "XXX.XXX.XXX.244"
      5) "port"
      6) "6379"
      7) "runid"
      8) "ca02da1f0002a25a880e6765aed306b1857ae2f7"
      9) "flags"
     10) "master"
     11) "pending-commands"
     12) "0"
     13) "last-ping-sent"
     14) "0"
     15) "last-ok-ping-reply"
     16) "1012"
     17) "last-ping-reply"
     18) "1012"
     19) "down-after-milliseconds"
     20) "30000"
     21) "info-refresh"
     22) "1261"
     23) "role-reported"
     24) "master"
     25) "role-reported-time"
     26) "17059720"
     27) "config-epoch"
     28) "0"
     29) "num-slaves"
     30) "1"
     31) "num-other-sentinels"
     32) "12"
     33) "quorum"
     34) "7"
     35) "failover-timeout"
     36) "60000"
     37) "parallel-syncs"
     38) "1"
273)  1) "name"
      2) "shard-188"
      3) "ip"
      4) "XXX.XXX.XXX.96"
      5) "port"
      6) "6379"
      7) "runid"
      8) "95cd3a457ef71fc91ff1a1c5a6d5d4496b266167"
      9) "flags"
     10) "master"
     11) "pending-commands"
     12) "0"
     13) "last-ping-sent"
     14) "0"
     15) "last-ok-ping-reply"
     16) "886"
     17) "last-ping-reply"
     18) "886"
     19) "down-after-milliseconds"
     20) "30000"
     21) "info-refresh"
     22) "5762"
     23) "role-reported"
     24) "master"
     25) "role-reported-time"
     26) "17059758"
     27) "config-epoch"
     28) "0"
     29) "num-slaves"
     30) "2"
     31) "num-other-sentinels"
     32) "12"
     33) "quorum"
     34) "7"
     35) "failover-timeout"
     36) "60000"
     37) "parallel-syncs"
     38) "1"

各センチネルの開始時の sentinel.conf は

maxclients 20000
loglevel notice
logfile "/home/redis/logs/sentinel.log"
sentinel monitor shard-172 redis-b-172  7
sentinel down-after-milliseconds shard-172 30000
sentinel failover-timeout shard-172 60000
sentinel parallel-syncs shard-172 1
....
sentinel monitor shard-188 redis-b-188  7
sentinel down-after-milliseconds shard-188 30000
sentinel failover-timeout shard-188 60000
sentinel parallel-syncs shard-188 1

数分後に結果として得られる sentinel.conf (すべてのセンチネル) を次に示します。2 つのスレーブに注意してください。

sentinel monitor shard-172 XXX.XXX.XXX.244 6379 7
sentinel failover-timeout shard-172 60000
sentinel config-epoch shard-172 0
sentinel leader-epoch shard-172 0
sentinel known-slave shard-172 XXX.XXX.XXX.177 6379 <--- True slave of shard-172
sentinel known-sentinel shard-172 ...
...
sentinel monitor shard-188 XXX.XXX.XXX.96 6379 7
sentinel failover-timeout shard-188 60000
sentinel config-epoch shard-188 0
sentinel leader-epoch shard-188 0
sentinel known-slave shard-188 XXX.XXX.XXX.194 6379 <--- True slave of shard-188
sentinel known-slave shard-188 XXX.XXX.XXX.177 6379
sentinel known-sentinel shard-188 ...
4

1 に答える 1

0

これは、私が「アリの問題」と呼んでいるものです。2 つ (またはそれ以上) のポッド (マスター + スレーブ) が混在しています。これは、ポッドの 1 つに複数のスレーブがあることを示すときに示します。

具体的には：

SENTINEL MASTERS コマンドの出力を次に示します。奇妙なことに、shard-188 には 2 つのスレーブがありますが、実際には 1 つしかないはずです。

あなたがする必要があるのは：

  1. これらのパーツ (shard-188 と shard-???) をすべてのセンチネルから削除します。sentinel remove shard-NNN
  2. それらのスレーブが入っているポッドをダウンさせます
  3. それらを正しく構成します（適切なslaveofコマンド/構成）
  4. それらをオンラインに戻す
  5. それぞれが正しいスレーブを 1 つだけ持っていることを確認します
  6. 経由でそれらを Sentinels に戻します。sentinel monitor ...

技術的にはコマンドを使用できますが、sentinel reset潜在的なタイミングの問題に直面する可能性があるため、Sentinel からそれらを削除することが確実な方法です。必要に応じて、マスター/スレーブをそのままにして、スレーブを適切に再構成することができます。そのルートに進む場合は、数分待ってから、手順 6 に進む前にスレーブ リストを確認してください。

于 2015-11-09T17:49:58.383 に答える