0

我有一个包含三个 Redis 实例（一个主实例和两个从属实例）和三个 Sentinel 实例的架构。在它前面有一个 HaProxy。在主 Redis 实例关闭之前一切正常。Sentinel 正确选择了新主人。但是，旧的主服务器（现在已关闭）没有重新配置为从服务器。结果，当该实例再次启动时，我在短时间内（大约 11 秒）有两个主人。在那之后，该实例被正确降级为从属。

它不应该这样工作吗，当主人倒下时，它会立即降级为奴隶？有了这个，当它再次启动时，它会立即成为奴隶。我知道（从 Redis 2.8 开始？）有 CONFIG REWRITE 功能，因此当 Redis 实例关闭时无法修改配置。

在一段时间内拥有两个 master 对我来说是个问题，因为 HaProxy 在很短的时间内不是向一个 master Redis 发送请求，而是在这两个 master 之间进行负载平衡。

有什么办法可以立即将失败的主设备降级为从设备？

显然，我更改了 Sentinel 超时。

以下是 master 宕机后来自 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

2

当我想使用 sentinel 在 redis-cluster 中切换 master 时，我也遇到了同样的错误。

+vote-for-leader xxxxxxxxxxxxxxxxxxxxxxxx8989 10495
下一次故障转移延迟：我不会在 2019 年 8 月 2 日星期五 23:23:44 之前启动故障转移

重置哨兵后。集群按预期工作

SENTINEL RESET *

或者

哨兵重置 mymaster

在所有哨兵服务器中运行上述命令。

于 2019-08-02T18:28:00.510 回答
0

如果 Redis 节点宕机，当/如果它恢复时，它将恢复role到宕机前的状态。如果 Sentinel 无法 ping 节点，则无法重新配置节点。因此，从节点恢复到 Sentinel 确认并重新配置它之间有一段短暂的时间。这解释了多主机状态。

如果您打算使用 Haproxy，一种解决方法是在启动进程之前重新配置 Redis 节点的角色。只要 redis.conf 中有 SLAVEOF 条目，Redis 就会作为从属设备启动。此解决方法的主要问题是它不能解决网络分区方案。

希望有帮助。

于 2016-12-02T13:55:51.893 回答
0

如果使用HAProxy您可以尝试查询uptime_in_seconds 如下内容：

backend redis
    mode tcp
    balance first
    timeout queue 5s
    default-server check inter 1s fall 2 rise 2 maxconn 100
    option tcp-check
    tcp-check connect
    tcp-check send AUTH\ <secret>\r\n
    tcp-check expect string +OK
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    tcp-check send info\ replication\r\n
    tcp-check expect string role:master
    tcp-check send info\ server\r\n
    tcp-check expect rstring uptime_in_seconds:\d{2,}
    tcp-check send QUIT\r\n
    tcp-check expect string +OK
    server redis-1 10.0.0.10:9736
    server redis-2 10.0.0.20:9736
    server redis-3 10.0.0.30:9736

注意：

  tcp-check expect rstring uptime_in_seconds:\d{2,}

如果正常运行时间不 > 10 秒，则不会添加节点

于 2021-07-23T21:45:39.573 回答