Redis - 配置哨兵以在主服务器关闭时选择从服务器答案

【问题标题】：Redis - configure sentinel to elect slave if master shutdownRedis - 配置哨兵以在主服务器关闭时选择从服务器
【发布时间】：2015-10-12 12:36:45
【问题描述】：

您好，我已经创建了一个由 3 个 aws 实例组成的哨兵集群 Redis，我已经将哨兵配置为具有 HA Redis 集群并可以工作，但是如果我模拟主服务器崩溃（主实例关闭），哨兵安装在从服务器上，找不到master的哨兵，选举失败。我的哨兵配置是：

sentinel monitor master ip-master 6379 2
sentinel down-after-milliseconds master 5000
sentinel failover-timeout master 10000
sentinel parallel-syncs master 1

所有实例都使用相同的文件

【问题讨论】：

很清楚你的布局是什么。您是否有：a) 3 个节点，每个节点都带有哨兵，一个带有主控，另一个带有从属？ b) 1 个主节点，3 个从属节点，每个节点也在运行哨兵？ c) 别的？如果您在与主节点相同的节点上运行哨兵，您如何模拟故障 - 通过停止节点、在主节点上使用调试命令、停止 redis 进程或其他方式？你检查过哨兵的日志吗？他们说了什么？
我有 1 个主节点和 2 个从节点（总共 3 个服务器），在每个节点上安装了相同的配置文件。为了模拟故障转移，我尝试了两种方式，a）关闭主服务器上的 redis 服务（选举工作）b）物理关闭主服务器，haltcommand（选举不起作用）

标签： redis redis-sentinel

【解决方案1】：

在与主节点相同的节点上运行哨兵并尝试触发故障转移时会出现问题。尝试在 master 上不运行 Sentinel。最终，这意味着不在与 Redis 实例相同的节点上运行 Sentinel。

在您的情况下，您的死节点模拟显示了为什么您不应在与 Redis 相同的节点上运行 Sentinel：如果节点死亡，您将失去一个哨兵。从理论上讲，它应该仍然有效，但正如您和其他人所看到的那样，它不一定有效。我有一些理论为什么，但我还没有证实它们。

从某种意义上说，Sentinel 部分是一个监控系统。无论如何，在与被监控的相同节点上运行监控解决方案通常是不可取的，因此无论如何您都应该使用节点外哨兵。由于 Sentinel 资源高效，因此您不一定需要专用机器或大型虚拟机。实际上，如果您有一组静态的应用程序服务器（您的客户端代码在其中运行），您应该在那里运行 Sentinel，记住您需要最少 3 个和 50%+1 的法定人数。

【讨论】：

但是如果在node外安装sentinel，如何制作sentinel的配置文件呢？自动发现工作是因为slave的sentinel调用master，如果slave节点上没有安装sentinel，master怎么知道谁是slave？
主人通过与 Sentinel 交谈知道谁是奴隶，但通过什么客户端连接到它并发出同步命令。您以完全相同的方式配置 Sentinel - 将其指向主 IP:PORT。哨兵通过询问主人来解决剩下的问题。
Ops，对不起...你是对的，那么在其他3台不是redis实例的机器上安装sentinel就足够了
正是如此。并确保“旧”哨兵消失。 ;) 理想情况下，您希望它们与您的客户端代码位于同一网络上，因为它会测试访问路由。但最终它们可以在 Redis 节点以外的任何地方，只要它们可以连接到 Redis 实例。
到客户端是不可能的，因为它们在自动缩放组中，并且不断地被销毁和重新创建。我安装到其他网络实例。谢谢

【解决方案2】：

最近的redis版本引入了“protected-mode”选项，默认为yes。

将protected-mode设置为yes，redis实例，没有设置密码将不允许远程客户端执行命令。

这也会影响哨兵主控选举。

尝试在哨兵中设置“protected-mode no”。这将允许他们互相交谈。

【讨论】：

【解决方案3】：

如果您不想将保护模式设置为否。你最好在 redis.conf 中设置 masterauth myredis 并在 sentinel.conf 中使用 sentinel auth-pass mymaster myredis

【讨论】：