Redis哨兵: last node doesn't become master

Question

我正在尝试在 3 节点 Redis 集群中设置自动故障转移系统。我在每个节点上安装了 redis-sentinel (就像这个人: http://www.symantec.com/connect/blogs/configuring-redis-high-availability )。 只要我有两个或三个节点，一切都很好。问题是，每当只剩下一个节点并且它是从属节点时，它不会自动被选为主节点。仲裁设置为 1，因此最后一个节点检测到主节点的故障，但无法投票支持故障转移，因为没有多数。

为了克服这个(令人惊讶的)问题，我编写了一个小脚本，向其他节点询问其主节点，如果他们不回答，我将当前节点设置为主节点。该脚本在 redis-sentinel.conf 文件中作为通知脚本调用。然而……redis-sentinel服务一启动，这个配置就被“抹掉”了!如果我查看/etc 中的配置文件，“sentinel notification-script”行已经消失(redis-sentinel 重写了它的配置文件，所以为什么不呢)但是我编写的配置不再可用:

1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "x.x.x.x"
    5) "port"
    6) "6379"
    7) "runid"
    8) "somerunid"
    9) "flags"
   10) "master"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "395"
   17) "last-ping-reply"
   18) "395"
   19) "down-after-milliseconds"
   20) "30000"
   21) "info-refresh"
   22) "674"
   23) "role-reported"
   24) "master"
   25) "role-reported-time"
   26) "171302"
   27) "config-epoch"
   28) "0"
   29) "num-slaves"
   30) "1"
   31) "num-other-sentinels"
   32) "1"
   33) "quorum"
   34) "1"
   35) "failover-timeout"
   36) "180000"
   37) "parallel-syncs"
   38) "1"

这是sentinel-masters 命令的结果。唯一的问题是我之前将“down-after-milliseconds”设置为 5000，将“failover-timeout”设置为 10000 ...

不知道有没有人遇到过类似的情况？好吧，如果有人对正在发生的事情有一点了解，我会很高兴;)

Answer 1

这是不将哨兵放置在 Redis 实例节点上的原因。将它们视为监控代理。您不会将网站监视器放置在运行网站的同一节点上并期望捕获节点死亡。 Sentinel 的预期也是如此。

哨兵监控的正确途径是从客户端运行它们，如果这不可能或不可行，则从尽可能靠近客户端的专用节点运行它们。

正如 antirez 所说，你需要有足够的哨兵才能进行选举。有两种选举:1:决定新的 master 和 2:决定由哪个哨兵负责晋升。在您的场景中，您只有一个哨兵，但要选举一名哨兵来处理晋升，您的哨兵需要来自法定人数的哨兵投票。这个数字占所有看到的哨兵的大多数。就您而言，在选举进行之前需要两名哨兵进行投票。此法定人数不可配置，也不受法定人数设置的影响。这样做是为了减少多个主人的机会。

我还强烈建议不要将法定人数设置为少于哨兵的一半+1。这可能会导致你有两个主人的裂脑操作。或者就你的情况而言，你可以拥有三个。如果您的主服务器和两个从服务器之间失去了连接，但客户端仍然具有连接，那么您的设置可能会触发脑裂——从服务器被提升，新连接与该主服务器通信，而现有连接继续与原始连接通信。因此，您在两个可能相互冲突的母版中拥有有效数据。

那篇赛门铁克文章的作者只考虑了 Redis 守护进程的死亡，而不是节点的死亡。因此，它确实不是 HA 设置。