Redis Sentinel未将副本晋升为新主节点问题求助

从你提供的日志片段-failover-abort-no-good-slave master mymaster A 6379可以明确：哨兵集群无法找到符合条件的从节点来晋升为新主节点，以下是具体排查和解决步骤：

核心排查方向 #

1. 验证从节点同步状态 #

登录从节点B/C，执行以下命令检查复制状态：

redis-cli -h <从节点IP> info replication

重点关注：

• master_link_status：必须为up，说明从节点与主节点A在停止前处于正常连接状态
• slave_repl_offset：需与主节点A的master_repl_offset一致或差距极小，避免因同步延迟过高被哨兵判定为不合格
• slave_priority：默认值为100，若设为0，哨兵会直接跳过该从节点（0表示该从节点不参与主节点选举）

2. 检查哨兵关键配置参数 #

打开哨兵配置文件（通常为sentinel.conf），核对以下参数：

• sentinel quorum mymaster <数值>：该值需小于哨兵集群总数量（建议3个哨兵时设为2），确保故障判定的有效性
• sentinel min-slaves-max-lag mymaster <毫秒>：默认10秒，若从节点同步延迟超过该值，会被视为不合格。可适当调大（如60000）以兼容网络波动
• sentinel down-after-milliseconds mymaster <毫秒>：默认30秒，需确保该值大于主节点正常重启的时间，避免误判故障

3. 确认从节点与哨兵的网络连通性 #

• 检查从节点的防火墙规则，确保6379端口对所有哨兵节点开放
• 在哨兵节点上执行telnet <从节点IP> 6379或redis-cli -h <从节点IP> ping，验证连通性

4. 排查哨兵集群数量 #

单哨兵节点故障转移的可靠性极低，建议部署至少3个独立的哨兵节点，确保故障判定和 Leader 选举的一致性

修复操作步骤 #

1. 临时重启主节点A，待从节点B/C完成同步（通过info replication确认状态正常）
2. 若从节点slave_priority为0，执行以下命令修改并持久化：

redis-cli -h <从节点IP> config set slave-priority 100
redis-cli -h <从节点IP> config rewrite

3. 调整哨兵配置中的min-slaves-max-lag参数，保存后重启哨兵服务：

# 编辑配置文件，修改参数
sed -i 's/sentinel min-slaves-max-lag mymaster.*/sentinel min-slaves-max-lag mymaster 60000/' /etc/redis/sentinel.conf
# 重启哨兵
systemctl restart redis-sentinel

4. 再次停止主节点A，实时监控哨兵日志，查看从节点选举过程

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