Redis Sentinel 故障转移怎么判断完成：主从角色、纪元与应用重连检查

Redis Sentinel 触发故障转移后，最容易判断错的地方就是把“某一个 Sentinel 觉得主节点连不上了”直接当成“业务已经切到新主节点跑了”。真正确定故障转移完成，至少要同时确认新主节点的角色、Sentinel 记录的主地址、全集群复制关系，还有上层业务应用的重连都全部恢复正常。

验收时不要只盯着 SDOWN。先确认是否形成 ODOWN，再确认新节点已经执行 REPLICAOF NO ONE 成为 master，最后用 switch-master 事件和应用连接日志完成闭环。

先把“发现故障”和“切换完成”分开

Sentinel 的状态至少要分成两层理解。SDOWN 表示某一个 Sentinel 在 is-master-down-after-milliseconds 时间内没有得到主节点的有效响应；当达到监控配置里的 quorum，并通过 Sentinel 之间的确认形成 ODOWN，才具备推动故障转移的条件。

因此，值班时看到 +sdown 只能说明“这台 Sentinel 看到异常”。继续看事件流里的 +odown、+try-failover、+elected-leader 和 failover-end，才知道流程有没有从观测进入选主、授权和收尾。

grep -E 'sdown|odown|try-failover|elected-leader|failover-end|switch-master' sentinel.log

遇到问题先别急着调整 quorum 参数。网络抖动、Sentinel 节点之间互相访问不通、主节点确实硬件宕机，都会让故障事件停在不同的中间状态。先把原始日志和对应时间线留存好，后面才能定位到底是故障发现慢、选举得票没过半，还是原有副本本身不具备提升成主节点的条件。

用三个命令确认新主到底是谁

故障转移结束后，从应用能访问的 Sentinel 地址查询监控对象。下面假设监控名为 mymaster，不要把示例地址直接当成生产地址。

redis-cli -h 127.0.0.1 -p 26379 SENTINEL get-master-addr-by-name mymaster
redis-cli -h 127.0.0.1 -p 26379 SENTINEL master mymaster
redis-cli -h 127.0.0.1 -p 26379 SENTINEL replicas mymaster

第一个命令用来获取应用最终应该连接的主节点地址；第二个命令查看主节点的 flags 标记、端口、纪元等核心监控信息；第三个命令确认旧主节点或者其余副本节点是否已经重新加入正确的复制拓扑。多台 Sentinel 查询到的结果应该在很短时间内完全一致，如果还是返回旧主地址，先检查 Sentinel 节点之间的消息发布机制和网络连通性。

在新主和候选副本上分别执行 ROLE，比只看进程列表可靠：

# 新主上应返回 master
redis-cli -h 10.0.0.12 -p 6379 ROLE

# 旧主恢复后应重新成为 replica，而不是继续独立写入
redis-cli -h 10.0.0.11 -p 6379 ROLE
redis-cli -h 10.0.0.11 -p 6379 INFO replication

ROLE 返回的第一项是当前角色。新主应为 master；恢复的旧主如果仍为 master，说明重挂尚未完成，继续让业务写入可能造成双主数据分叉。

配置纪元为什么是切换验收的硬证据

Sentinel 会为每一次故障转移分配全新的 configuration epoch，用这个值来给新的集群拓扑做版本排序。验证的时候可以把故障发生前后的监控输出放在一起对比：新主节点地址发生变更的同时，纪元号必须是向前递增的，而且所有 Sentinel 节点最终都应该上报同一个主节点地址。

redis-cli -h 127.0.0.1 -p 26379 SENTINEL master mymaster \
  | egrep 'name|ip|port|flags|config-epoch|num-slaves|num-other-sentinels'

不要把 master-replid 和 Sentinel 的 configuration epoch 混为一谈。前者属于复制身份，后者属于 Sentinel 对主节点配置版本的管理。两者都能帮助排障，但验收问题不同：一个看复制链路是否换代，一个看 Sentinel 对拓扑的判断是否已经收敛。

应用重连与写入验证要单独做

Redis 服务端层面切换完成，不代表上层业务的连接池已经找到了新主节点。客户端一般需要订阅 Sentinel 节点的消息、按监控配置的主名称获取最新主地址，同时自动处理旧连接上产生的读写错误。实际验证至少要写入一条全局唯一的测试数据，再从业务的正常读路径把这条数据查出来，不能只靠组件自带的健康检查接口就判定服务恢复。

redis-cli -h 10.0.0.12 -p 6379 SET failover:check:20260824 ok EX 120
redis-cli -h 10.0.0.12 -p 6379 GET failover:check:20260824

同时检查客户端日志里的连接目标地址和错误自动恢复的次数。如果客户端还在往旧主节点发请求，优先核对 Sentinel 配置的地址列表、监控主名称是否和服务端一致、连接池有没有缓存过期的旧地址，以及应用侧是不是把只读副本的配置误写成了主连接地址。

旧主恢复后的回归检查

旧主重新上线后，不要立刻把它加入写流量。先确认它已被 Sentinel 识别为副本，并且 master_link_status:up、复制偏移量持续接近新主。若部署使用 NAT 或容器端口映射，还要核对 Redis 对外发布的地址是否是客户端和 Sentinel 都能访问的逻辑地址。

redis-cli -h 10.0.0.11 -p 6379 INFO replication \
  | egrep 'role|master_host|master_port|master_link_status|master_sync_in_progress|slave_repl_offset'

等副本状态全部稳定、业务连续读写验证正常、所有 Sentinel 查询结果完全统一之后，再结束故障处理窗口。把这次切换对应的事件日志、新旧主地址、configuration epoch 和客户端恢复耗时都留存好，下次遇到同类问题就能快速区分是配置错误还是偶发的网络波动。

一份不容易漏项的收口清单

• 事件日志里能看到从 ODOWN 到 failover-end 的完整流转阶段，或者有明确的故障失败原因和回滚动作记录。
• 至少两台 Sentinel 节点查询到同一个新主节点地址，configuration epoch 已经更新为最新值。
• 新主的 ROLE 为 master，旧主恢复后为 replica，复制链路状态正常。
• 业务应用通过 Sentinel 重新建立主节点连接，真实场景的写入和读取操作全部正常。
• 不存在双主节点残留、旧地址缓存、错误端口或者 NAT 发布地址不匹配的问题。

相关问题

只有一个 Sentinel 报 SDOWN，需要立刻切换吗？

看到单节点上报 SDOWN 不需要马上操作。这只是单个 Sentinel 的局部观测结果，先核对其余 Sentinel 是不是也访问不到原主节点，以及预设的 quorum 数值是否满足条件。如果是单个 Sentinel 被网络隔离了，贸然手动改配置反而会把小范围网络问题扩大成非预期的主从切换。

看到 failover-end 就能让旧主重新接流量吗？

不能只看这个标记。failover-end 只能说明 Sentinel 完成了新主节点的提升流程，但旧主节点重新接入集群转为副本、复制数据追平、业务连接全部切换这些环节还是要单独做验证。旧主节点角色还没变成 replica 之前，不建议直接把全量写流量切回去。

为什么 Redis 进程都在线，业务仍然报连接错误？

进程存活只能代表对应端口能建立 TCP 连接，不能证明客户端已经拿到了最新的主节点地址。优先检查 Sentinel 配置的监控名、客户端订阅机制、连接池缓存逻辑和容器/NAT 的对外映射地址，通常比直接重启应用更快定位到根因。

总结

Redis Sentinel 故障转移的完成标准从来不是单条日志输出，而是一套可以交叉复核的证据链：多数节点达成故障共识、选举出来的新主获得全新纪元、新主自身角色标记正确、所有副本重新接入复制拓扑、业务侧通过 Sentinel 自动完成重连并验证真实读写。把这几个环节的结果都确认到位，故障处理窗口才算真正收口。