我正在尝试在3节点redis群集中设置自动故障转移系统。我在每个节点上安装了redis-sentinel（就像这个人一样：http://www.symantec.com/connect/blogs/configuring-redis-high-availability）。 只要我有两个或三个节点，一切都很好。问题是，只要剩下的onte节点和它是一个slave，它就不会自动被选为master。仲裁设置为1，因此最后一个节点检测到主节点的odown但不能为故障转移投票，因为没有多数。
为了克服这个（令人惊讶的）问题，我写了一个小脚本，询问其他节点的主人，如果他们没有回答，我将当前节点设置为主节点。此脚本在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 ......
我不知道是否有人见过类似的东西？好吧，如果有人对发生的事情有一点了解，我会很高兴;）
答案 0 :(得分：3)
这是不将您的哨兵放在redis实例节点上的原因。将它们视为监控代理。您不会将您的网站监视器放在运行您的网站的同一节点上，并期望捕获节点死亡。预期与Sentinel相同。
前哨监控的正确途径是理想情况下从客户端运行它们，如果这是不可行或不可行的，那么从专用节点尽可能靠近客户端。
正如反犹太人所说，你需要有足够的哨兵参加选举。有两个选举：1：决定新的主人和2：决定哪个哨兵处理晋升。在您的方案中，您只有一个哨兵，但要选择一个哨兵来处理促销，您的哨兵需要法定人数的哨兵投票。这个数字是所有哨兵中的大多数。在你的情况下，它需要两个哨兵投票才能举行选举。此仲裁号码不可配置且不受仲裁设置的影响。这是为了减少多个主人的机会。
我还强烈建议不要将法定人数设定为少于你哨兵的一半+ 1。这可能导致大脑分裂，你有两个主人。或者在你的情况下你可以有三个。如果您的主服务器和两个从服务器之间的连接断开但客户端仍然具有连接性，则您的设置可能会触发分裂大脑 - 其中一个从属服务器被提升，新的连接与该主服务器通信，而现有服务器继续与原始服务器通信。因此，您在两个主人中拥有可能相互冲突的有效数据。
该赛门铁克文章的作者只考虑Redis守护程序死亡，而不是节点。因此，它确实不是HA设置。
答案 1 :(得分：2)
仲裁仅用于达到ODOWN状态，从而触发故障转移。对于实际发生的故障转移，奴隶必须以多数票投票，因此单个节点不能被选举。如果您有这样的要求，并且您并不关心只有大多数方能够在您的群集中继续（这意味着如果客户端与拥有主服务器的少数群体进行分区，则少数群体中的未绑定数据丢失），也可以在你的客户端机器中添加标记，这样，Sentinels的总数例如是5，即使两个Redis节点关闭，唯一的剩余节点加上两个运行客户端的标记也足以获得大部分不幸的是，Sentinel文档不够完整，无法解释这些内容。有所有信息可以使图片正确，但没有更快的阅读/部署的例子。