redis三哨兵为何只有一个哨兵起作用？

redis配置的是一主两从三哨兵，如果在保证三个哨兵都在的情况下，那么当master停了后，是可以正常把从换成主的，但是如果把主上的哨兵服务与redis服务停掉后（主上的哨兵服务是最先启动的），现在就剩两个哨兵，两个从的redis服务的时候，哨兵无法把从升级为主，是哨兵哪里没配置对吗？如下是哨兵的配置文件情况（三台哨兵都是如此配置，主要就是指定了master的Ip和端口）

在Redis Sentinel（哨兵）架构中，通常会配置多个哨兵来监控Redis主从节点的状态，并在主节点故障时进行自动故障转移。但是，您提到的情况只有一个哨兵起作用，可能是由于以下原因之一：

配置错误：检查您的哨兵配置是否正确。确保所有的哨兵实例都在正确的端口上监听，并且它们之间能够相互通信。还需要确保哨兵的配置文件中指定了正确的主节点地址和端口。

网络问题：哨兵之间的网络连接可能存在问题，导致其他哨兵无法检测到主节点的状态。请确保哨兵之间的网络连接是可靠的，并且没有被防火墙或其他网络设备所阻塞。

主节点不可达：如果只有一个哨兵起作用，可能是因为其他哨兵无法访问主节点。请确保主节点处于可达状态，并且其他哨兵能够连接到主节点的地址和端口。

故障转移已完成：如果在主节点故障后，只有一个哨兵起作用，可能是因为其他哨兵已经完成了故障转移，并将一个新的主节点选举出来。在这种情况下，其他哨兵可能会进入静默状态，不再参与后续的故障转移。

基于new bing部分指引作答：
根据你提供的信息，我无法确定具体的问题，但是我可以给出一些常见的原因和建议来解决问题。

首先，请确保你的哨兵配置文件中的以下几个关键配置项是正确的：

1、sentinel monitor ：确保每个哨兵节点的配置文件中，monitor 配置项指定的、和与主节点的信息一致。是指在主节点失效时需要达成一致的最小哨兵数量。

2、sentinel down-after-milliseconds ：确保每个哨兵节点的配置文件中，down-after-milliseconds 配置项指定的与主节点的信息一致。这个配置项指定了哨兵判定主节点失效的时间阈值。

3、sentinel parallel-syncs ：确保每个哨兵节点的配置文件中，parallel-syncs 配置项指定的与主节点的信息一致。这个配置项指定了哨兵执行故障转移时可以同时同步的从节点数量。

其次，请确保以下几点：

1、确认所有的哨兵节点都已正确启动。你可以通过查看哨兵节点的日志文件来确认是否有任何错误或异常信息。

2、检查网络连接是否正常。确保所有节点之间可以互相通信，并且主节点和哨兵节点之间的通信没有被防火墙或其他网络配置所阻塞。

3、检查每个哨兵节点的状态。你可以使用 Redis 命令行客户端连接到每个哨兵节点，并执行 SENTINEL MASTER 命令来查看主节点的状态信息。确保每个哨兵节点都能够正确识别主节点的状态。

4、检查主节点是否设置了 slave-priority。如果在主节点的配置中设置了 slave-priority，确保其值不为 0，因为这会阻止从节点升级为主节点。

根据你提供的配置文件，哨兵配置似乎没有明显的问题。但是，在只有两个哨兵和两个从节点的情况下，哨兵可能无法将从节点升级为主节点。这是因为哨兵执行故障转移时需要达成一致的最小哨兵数量（即 quorum）。

在你的配置文件中，sentinel monitor mymaster 172.16.2.60 6389 2 指定了一个 quorum 值为 2。这意味着至少需要有两个哨兵节点达成一致才能进行故障转移。但是，如果只有两个哨兵节点处于活动状态，无法达到 quorum 的要求，故障转移将无法执行。

解决此问题的一种方法是将 quorum 的值设置为 1，以便在只剩下两个哨兵节点时也能执行故障转移。在每个哨兵的配置文件中，将 sentinel monitor 行修改为：

sentinel monitor mymaster 172.16.2.60 6389 1

这样，只需要一个活动的哨兵节点即可执行故障转移。请记住，这将带来更高的风险，因为如果哨兵节点发生故障或网络分区，可能会导致错误的故障转移。

另外，请确保你的哨兵节点的日志文件中没有任何错误或异常信息，以便进一步排查问题。

参考 https://blog.csdn.net/weixin_38568503/article/details/124411426

参考 https://blog.csdn.net/qq_24631211/article/details/108680894

这有个类似的问题, 你可以参考下: https://ask.csdn.net/questions/7663724
除此之外, 这篇博客: redis高可用方案总结中的我的方案总结：这个方案有点是redis官方的，功能性、稳定性都可以。在我们的场景中主要是以查询数据为主，3台机器3个地址端口都可以查，在查数据的过程中可以分别查这三台机器，查到一台上面有就可以，三台机器上的数据是一致的。写数据的频次可能没那么高，写数据只能往master机器上面写（往salve机器上写不进去），如果出现master机器坏掉了，会自动出现新的master，问题就是ip地址会变，那么写数据时候ip地址也会变，每天要更新数据写的时候我觉得也可以用读的那种方法，三台依次都写一下。然后定期检查三台机器的状态就可以实现高可用，数据稳定了。部分也许能够解决你的问题, 你可以仔细阅读以下内容或跳转源博客中阅读: