☰

当主服务器宕机时，Redis Sentinel 不会采取行动

tag-icon • tag-icon redis redis-sentinel
当主服务器宕机时，Redis Sentinel 不会采取行动

我正在尝试在 3 个节点上设置 Redis/Sentinel 设置，每个节点运行一个 redis 实例和一个 sentinel 实例。但是，当主机发生故障时，其余的 sentinel 只是坐在那里什么也不做，然后决定将每个从机设置为其自身的从机，这当然接近最糟糕的做法。

设置详情如下：

节点为10.66.5.3、10.66.5.4、10.66.5.5。

默认情况下，.3节点是主节点（在安装时），所有其他节点在文件中都有相应的条目/etc/redis/redis.conf：slaveof 10.66.5.3 6379。其余部分redis.conf未经修改。

哨兵的起始配置如下：

daemonize no
sentinel monitor myapp 10.66.5.3 6379 2
sentinel down-after-milliseconds myapp 5000
sentinel failover-timeout myapp 15000
sentinel parallel-syncs myapp 1

注意：我让upstart守护进程处理服务，这就是守护进程标志关闭的原因。配置文件可由其各自的守护进程写入，因此 sentinel 可以（并且确实）更新其配置文件，这没有问题。

只要所有节点都处于活动状态，设置就可以正常工作。在主节点上注册某些内容将传播到从节点，依此类推。

现在，当我选择关闭（shutdown -h now）Redis 主服务器并留出一些时间让仲裁发生时，结果的情况是：

  • 节点.4被设置为其 IP 地址的从属（10.66.5.4）
  • 节点.5设置为127.0.1.1

哨兵们来回反复尝试选举一些东西，但显然在其中一个哨兵崩溃后，它们无法正常通信。它们还不断检测到自己已关闭，并出现其他荒谬的事情。

1744:X 12 May 17:02:32.453 # -odown master myapp 127.0.1.1 6379
1744:X 12 May 17:02:33.517 # +odown master myapp 127.0.1.1 6379 #quorum 2/2
1744:X 12 May 17:02:38.139 # +sdown slave 10.66.5.5:6379 10.66.5.5 6379 @ myapp 127.0.1.1 6379
1744:X 12 May 17:02:38.358 # +sdown slave 10.66.5.4:6379 10.66.5.4 6379 @ myapp 127.0.1.1 6379
1744:X 12 May 17:02:42.970 # -sdown slave 10.66.5.5:6379 10.66.5.5 6379 @ myapp 127.0.1.1 6379
1744:X 12 May 17:02:43.203 # -sdown slave 10.66.5.4:6379 10.66.5.4 6379 @ myapp 127.0.1.1 6379
1744:X 12 May 17:02:43.230 * -dup-sentinel master myapp 127.0.1.1 6379 #duplicate of 127.0.0.1:26379 or 3369dfeed7f6e970c4620b3689741b47ba5d9972
1744:X 12 May 17:02:43.230 * +sentinel sentinel 127.0.0.1:26379 127.0.0.1 26379 @ myapp 127.0.1.1 6379
1744:X 12 May 17:02:43.280 # -odown master myapp 127.0.1.1 6379
1744:X 12 May 17:02:43.313 * -dup-sentinel master myapp 127.0.1.1 6379 #duplicate of 10.66.5.4:26379 or 3369dfeed7f6e970c4620b3689741b47ba5d9972
1744:X 12 May 17:02:43.313 * +sentinel sentinel 10.66.5.4:26379 10.66.5.4 26379 @ myapp 127.0.1.1 6379
1744:X 12 May 17:02:44.123 # +new-epoch 24
1744:X 12 May 17:02:44.125 # +vote-for-leader 3369dfeed7f6e970c4620b3689741b47ba5d9972 24
1744:X 12 May 17:02:44.409 # +odown master myapp 127.0.1.1 6379 #quorum 2/2

正在运行：

  • Ubuntu 14.04
  • Redis 3.0.0

我不太清楚那里发生了什么，而且我几乎没有主意。

答案1

我不在 PC 附近进行测试，但由于只剩下两个哨兵节点，所以无法打破平局。

如果你只是杀死 redis (并保持 sentinel 运行) 会起作用吗？如果是这样，那就是你的问题。

答案2

redis 服务器必须监听本机的 IP，而不是 0.0.0.0。否则 sentinels 可能会将 127.0.0.1 作为本机 IP 之一并进行传播，这显然是错误的。

相关内容