Redis四Sentinel节点双故障后无法触发故障转移，如何自动更新节点数？

场景还原 #

我部署的Redis集群包含：

• 1主节点（M1）、3从节点（R2、R3、R4）
• 4个Sentinel节点（S1、S2、S3、S4），设置quorum=2

初始拓扑：

+----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |    |    | S3 |
+----+    |    +----+
          |
          |
       +----+
       | R4 |
       | S4 |
       +----+

当M1与S1同时进入odown状态后，Sentinel触发故障转移，集群更新为：

• 主节点切换为M2（原R2），剩余2个从节点（R3、R4）
• 3个可用Sentinel节点（S2、S3、S4）

新拓扑：

+----+
       | M2 |
       | S2 |
       +----+
          |
+----+    |    +----+
| R3 |----+----| R4 |
| S3 |         | S4 |
+----+         +----+

但当M2与S2再次同时进入odown状态时，故障转移未触发。排查发现：Sentinel仍以初始4个节点数计算多数票要求，当前仅2个可用节点无法满足授权条件。

根据Redis官方文档，核心原因：

• quorum仅用于确认主节点不可用的共识节点数；
• 故障转移需选举Sentinel领导者，且必须获得当前可用Sentinel节点的多数投票。

核心问题 #

首次故障导致S1下线后，如何让Sentinel自动刷新可用节点数，确保二次故障时能正常触发转移？

解决方案 #

1. 依赖Sentinel自动节点发现与清理机制 #

Sentinel会定期探测集群内其他Sentinel节点的状态，当节点进入odown/sdown状态后，会自动将其从可用节点列表中移除。需验证：

• 检查down-after-milliseconds参数（默认30000ms），确保节点下线能被及时探测；
• 在任意存活Sentinel节点执行命令，确认下线节点已被移除：

  SENTINEL SENTINELS <你的主节点名称>
  

  返回结果仅应包含当前可用的Sentinel节点（S2、S3、S4）。

2. 动态调整quorum参数适配当前集群规模 #

根据当前可用Sentinel节点数（3个），可动态更新quorum值，让故障检测的共识要求更合理：

SENTINEL SET <你的主节点名称> quorum 2

此命令无需重启Sentinel，设置后，仅需2个Sentinel达成共识即可标记主节点不可用，同时领导者选举仅需2票即可达成多数（3个节点的多数为2）。

3. 排查节点状态感知异常问题 #

若Sentinel仍以初始4个节点计算多数票，大概率是节点状态感知不一致：

• 执行命令查看当前主节点关联的Sentinel数量：

  SENTINEL MASTER <你的主节点名称>
  

  检查返回结果中的sentinel_count字段，确认是否为3；
• 排查网络连通性，确保所有存活的Sentinel节点都能一致确认S1已下线，避免网络分区导致的状态分歧。

4. 优化初始部署与自愈预案 #

• 初始部署时选择奇数个Sentinel节点（如3、5个），减少因节点下线导致无法达成多数票的概率；
• 配置监控告警，当Sentinel节点数低于阈值时自动补充节点，维持集群高可用能力。

内容的提问来源于stack exchange，提问作者TensorUI