Redis Sentinel出现failover-abort-slave-timeout错误，主从切换失败求助

问题场景 #

单台服务器部署实例：7001为Master节点，7002、7003为Slave节点，7101、7102、7103为Sentinel节点。测试主节点故障时，Sentinel尝试故障切换但失败，出现failover-abort-slave-timeout错误，陷入循环重试，Slave节点无法晋升为Master。

关键日志分析 #

从Sentinel日志可见核心故障流程：

13795:X 10 Aug 2023 23:37:36.443 * +failover-state-send-slaveof-noone slave 127.0.0.1:7002 127.0.0.1 7002 @ mymaster 127.0.0.1 7001
13795:X 10 Aug 2023 23:37:36.543 * +failover-state-wait-promotion slave 127.0.0.1:7002 127.0.0.1 7002 @ mymaster 127.0.0.1 7001
13795:X 10 Aug 2023 23:39:36.589 # -failover-abort-slave-timeout master mymaster 127.0.0.1 7001

Sentinel成功选举leader、选中7002作为待晋升Slave，并发送slaveof noone命令，但等待Slave晋升确认超时，最终终止故障切换。

核心问题定位 #

从cluster nodes命令输出可见，当前节点采用Redis Cluster架构（而非传统主从复制），但同时部署了Sentinel监控：

[root@ip-172-31-14-169 redis-env]# redis-cli -c -p 7001 cluster nodes
ab72c65d95714772ba0261e5c1a79691ae84fa88 127.0.0.1:7001@17001 myself,master - 0 1691713101000 6 connected 0-16383
103be0fdbfaaba54fc11c779e80c8158f4728537 127.0.0.1:7003@17003 slave ab72c65d95714772ba0261e5c1a79691ae84fa88 0 1691713102605 6 connected
74a6d8b6f82ab2079569f8d0bba606e11a11c3fc 127.0.0.1:7002@17002 slave ab72c65d95714772ba0261e5c1a79691ae84fa88 0 1691713102000 6 connected

Redis Cluster自身具备完整的故障转移机制（由集群内节点通过Gossip协议选举新Master），Sentinel是为传统主从复制架构设计的监控工具，无法与Redis Cluster兼容，二者同时使用会导致故障切换逻辑冲突，引发超时错误。

排查与解决方案 #

方案1：移除Sentinel，使用Redis Cluster自带故障转移 #

Redis Cluster无需依赖Sentinel，集群会自动处理Master故障：

1. 停止所有Sentinel节点（7101、7102、7103）
2. 验证Cluster故障转移功能：手动停止7001节点，执行redis-cli -c -p 7002 cluster nodes，查看是否有Slave晋升为Master
3. 若Cluster故障转移未触发，检查Cluster配置：
   • 确保所有节点的cluster-enabled yes配置生效
   • 检查节点间通信端口（默认是服务端口+10000，如7001对应17001）是否正常开放
   • 确认集群quorum满足（至少半数以上Master节点在线）

方案2：放弃Redis Cluster，改用传统主从+Sentinel架构 #

若需使用Sentinel，需将节点改为传统主从复制模式：

1. 停止所有Redis节点（7001、7002、7003）和Sentinel节点
2. 修改每个Redis节点的配置文件，注释或删除cluster-enabled yes、cluster-config-file、cluster-node-timeout等Cluster相关配置
3. 重启7001节点，配置为Master
4. 重启7002、7003节点，执行slaveof 127.0.0.1 7001设置为Slave（或在配置文件中添加replicaof 127.0.0.1 7001）
5. 重启Sentinel节点，验证故障转移：停止7001节点，查看Sentinel日志是否成功将Slave晋升为Master

额外排查（若采用方案2后仍有问题） #

若传统主从+Sentinel架构下仍出现超时，需检查：

• Slave节点状态：执行redis-cli -p 7002 info replication，确认Slave已完成同步（master_link_status:up、slave_repl_offset与Master一致）
• Slave节点阻塞：执行redis-cli -p 7002 info stats查看latest_fork_usec，确认无持久化（RDB/AOF）阻塞；执行redis-cli -p 7002 slowlog get查看慢查询
• Sentinel与Slave通信：确保Slave节点的protected-mode no（已在配置中设置），且ACL权限允许Sentinel执行slaveof等命令（当前default用户拥有+@all权限，满足要求）
• 故障超时配置：若Slave同步数据量较大，可适当调大sentinel failover-timeout mymaster（默认180000ms），但优先解决阻塞问题

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