【问题标题】:Redis Sentinel master not downgraded to slave immediatelyRedis Sentinel master 没有立即降级为 slave
【发布时间】:2016-04-30 09:10:09
【问题描述】:

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

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

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

有什么办法可以立即将故障的master降级为slave?

显然,我更改了 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

Redis

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

【问题讨论】:

  • 这不是编程问题,而是系统/服务器管理员问题。 Serverfault 是问这个的地方。
  • 确实如此。我将其移至 Serverfault。
  • @Damian 你找到解决问题的方法了吗?我也面临同样的问题。

标签: redis sentinel redis-sentinel


【解决方案1】:

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

+投票给领导 xxxxxxxxxxxxxxxxxxxxxxxx8989 10495
下一次故障转移延迟:我不会在 2019 年 8 月 2 日星期五 23:23:44 之前启动故障转移

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

SENTINEL RESET *

或

哨兵重置我的主人

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

【讨论】:

    【解决方案2】:

    如果 Redis 节点发生故障,当/如果它恢复时,它将以与故障之前相同的 role 恢复。如果无法 ping 节点,Sentinel 将无法重新配置节点。因此,从节点恢复到 Sentinel 确认并重新配置它之间有一段短暂的时间。这解释了多主状态。

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

    希望对您有所帮助。

    【讨论】:

      【解决方案3】:

      如果使用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 秒,则不会添加节点

      【讨论】:

        猜你喜欢
        • 2016-09-28
        • 2020-08-30
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-12-17
        • 2017-08-06
        • 1970-01-01
        • 2018-07-09
        相关资源
        最近更新 更多