我试图在大型redis舰队中使用哨兵进行故障转移(12个哨兵，500多个碎片，每个主和一个从)。我遇到了一个非常奇怪的问题，我的哨兵反复发出命令+fix-slave-config到某些redis节点。我没有注意到这种情况在更小的范围内发生，不管它的价值。
我注意到两个特别的问题:
- +fix-slave-config消息，如上所述
- sentinel.conf显示某些slave有两个master(它们应该只有一个)
处于启动状态的舰队有一个从节点XXX.XXX.XXX。177 . xxx . xxx . xxx . xxx(它们一起构成了舰队中的分片188)。在不中断任何节点的情况下，从节点的主节点切换为XXX.XXX.XXX.96(master for shard 188)，然后返回，然后返回。这可以通过ssh进入从节点和主节点并检查redis-cli info来验证。所有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有两个奴隶，而实际上它应该只有1个。输出结果与XXX.XXX.XXX. xxx . xxx。
情况1)XXX.XXX.XXX. xxx。是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. xxx。是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 ...
这就是我所说的"蚂蚁问题":你有两个(或更多)pod(主+从)混合在一起。当您显示您的一个pod有多个从属时，您可以指出这一点。
专:以下是SENTINEL MASTERS命令的输出。奇怪的是是说shard-188有两个slave，而实际上应该只有1个。
你需要做的是:
- 通过
sentinel remove shard-NNN从所有哨兵中移除这些部分(shard-188和shard-??) - 把那些奴隶所在的pod带下来
- 正确配置它们(正确的
slaveof命令/配置) - 让他们重新上线
- 确保它们各自只有一个正确的从机
- 通过
sentinel monitor ...将它们添加回哨兵
现在从技术上讲，您可以使用sentinel reset命令，但您将面临潜在的时间问题，因此从哨兵中删除它们是可靠的路线。您也可以选择让主/从服务器处于启动状态，并简单地重新配置从服务器。如果采用这种方法，请等待几分钟，在进入步骤6之前检查slave清单。