0

我正在尝试在大型 redis 舰队中使用哨兵进行故障转移（12 个哨兵，500 多个分片，每个分片一个主分片和一个从属分片）。我遇到了一个非常奇怪的问题，我的哨兵反复向某些 redis 节点发出命令 +fix-slave-config。我没有注意到这种情况发生在较小的规模上，因为它是值得的。

我注意到两个具体问题：

  1. +fix-slave-config 消息，如上所述
  2. sentinel.conf 显示某些奴隶有两个主人（他们应该只有一个）

处于启动状态的舰队有一个从节点 XXX.XXX.XXX.177 和一个主节点 XXX.XXX.XXX.244（它们一起构成舰队中的 shard 188）。在没有任何节点中断的情况下，从节点的主节点切换到 XXX.XXX.XXX.96（分片 188 的主节点），然后切换回来，然后切换。这是通过 ssh 进入从节点和主节点并检查 redis-cli 信息来验证的。所有 Redis 节点都以正确的配置启动。所有 Sentinel 节点在他们的 sentinel.conf 中都有正确的配置。当我在每次这些 slave->master 更改后查询它们时，每个 Sentinel 都有完全相同的 master 列表。

在我的 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 有两个 slave，而实际上它应该只有 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（适用于所有哨兵）——注意两个从站：

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

这就是我所说的“蚂蚁问题”：你有两个（或更多）豆荚（主+从）混合在一起。当您显示您的一个 pod 有多个从属设备时，您会指出这一点。

具体来说：

这是 SENTINEL MASTERS 命令的输出。奇怪的是 shard-188 有两个 slave，而实际上它应该只有 1 个。

你需要做的是：

  1. 通过以下方式从所有哨兵中删除这些部分（shard-188 和 shard-???）sentinel remove shard-NNN
  2. 把那些奴隶所在的吊舱带下来
  3. 正确配置它们（正确的slaveof命令/配置）
  4. 让他们重新上线
  5. 确保他们每个人只有一个正确的奴隶
  6. 通过将它们添加回 Sentinelssentinel monitor ...

现在从技术上讲，您可以使用该sentinel reset命令，但您将面临潜在的时间问题，因此将它们从 Sentinel 中删除是必经之路。或者，您可以保留主/从，并简单地重新配置从属。如果您走那条路线，请等待几分钟并检查从属列表，然后再进入第 6 步。

于 2015-11-09T17:49:58.383 回答