恢复靠清单而不是记忆
主从故障恢复真正容易出错的不是操作本身，而是顺序与遗漏。恢复时要按清单逐项核对：先确认当前谁是主库（以实际查询结果为准，不凭印象），再看各从库的复制状态与偏移量，确认没有出现双主，评估数据差异范围并定下补数方案，最后收尾：刷新客户端指向、确认告警恢复、记录复盘。
基本信息
| 拓扑确认 | 以复制状态查询与哨兵查询结果为准 |
|---|---|
| 数据核对 | 评估各副本偏移差异与需要补的范围 |
| 风险排查 | 确认没有两个实例同时被当作主库 |
| 收尾动作 | 客户端刷新、告警恢复、写复盘记录 |
| 执行要求 | 恢复动作尽量脚本化，可审计可回放 |
典型使用场景
- 主库故障切换完成后确认新拓扑是否符合预期
- 旧主库恢复上线后决定它以什么身份回归，避免双主
- 数据出现分叉需要评估差异范围并制定补数方案
- 业务仍在写旧地址导致「切换了但没生效」的慢故障
- 把一次真实故障的处置过程沉淀成可复用的操作步骤
核对命令
核对命令
redis-cli INFO replication # 当前角色、主从链路与偏移
redis-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster # 哨兵认可的主库地址
redis-cli -h <各实例> INFO replication | grep role # 逐台确认角色，排除双主
redis-cli -h <各实例> INFO replication | grep master_last_io_seconds_ago
redis-cli -h <新主库> DBSIZE # 数据量基线，与旧记录比对检查项与判据
| 检查项 | 命令或动作 | 合格判据 |
|---|---|---|
| 当前主库身份 | 哨兵查询与实例角色查询 | 两者一致，且只有一台报主 |
| 副本链路状态 | 复制状态查询 | 链路正常，无长期断连副本 |
| 偏移差异 | 复制偏移与落后秒数 | 差异可解释，补数方案明确 |
| 客户端指向 | 连接来源与目标地址排查 | 业务已写入新主库 |
| 告警状态 | 监控面板 | 相关告警已恢复或已确认关闭 |
恢复之后不要急着把旧主库直接挂回：先核对它的数据与当前主库的差异，否则分叉的数据可能被覆盖或带进线上。
忘记确认客户端是否已指向新主库，是「切换完成但业务仍报错」这类慢故障的常见成因，收尾阶段要专门确认。