恢复后核对清单是什么
恢复完成不等于交付完成。服务起来了只是第一步，数据是否完整、入口是否指向正确的一侧、复制关系是否重建、监控是否恢复正常，都要逐项确认后才能宣布结束。经验上，恢复事故里相当一部分不是恢复失败，而是恢复后没人做完整核对就放量。
基本信息
| 核对维度 | 进程与端口、数据完整性、复制关系、时间与证书、监控、连接入口、故障侧隔离 |
|---|---|
| 数据核对 | 行数与抽样校验和对比基线，异常立即暂停放量 |
| 入口核对 | VIP、DNS、负载均衡指向正确一侧，TTL 生效 |
| 收尾 | 恢复完成时间写入事故时间线，供复盘与 RTO 统计 |
典型使用场景
- 数据库整库恢复：核对行数与关键业务查询后再切回流量
- 切换演练收尾：确认备侧已接管全部写入与读取职责
- 故障侧修复后回切：确认原侧数据已追平再切回，避免回退到旧数据
- 单文件恢复：确认权限、属主与依赖文件一并正确，服务能正常加载
- 复制关系恢复：确认备库已重新挂回拓扑，避免长期单点运行
恢复后核对清单
恢复后核对清单
□ 服务进程/端口/健康检查全部正常
□ 数据核对：行数、抽样校验和、关键业务查询
□ 复制关系是否重建（备库已挂回拓扑）
□ 时间同步与证书有效期正常
□ 监控告警已恢复（探针正常，不再持续告警）
□ 连接入口（VIP/DNS/负载均衡）指向正确的一侧
□ 故障侧已隔离下线，防止带病回连
□ 业务方确认核心功能可用，宣布恢复完成核对项与失败后果
| 核对项 | 检查方式 | 漏检后果 |
|---|---|---|
| 数据完整性 | 行数对比、抽样校验和、关键业务查询 | 带缺失数据放量，业务侧出现无法追溯的账目差异 |
| 复制关系 | 查看复制线程与位点状态 | 备侧单点运行，再次故障时无副本可用 |
| 时间与证书 | 检查 NTP 状态与证书有效期 | 时钟偏差影响日志与比对，证书过期导致服务不可用 |
| 监控恢复 | 确认探针正常、告警已消除 | 故障期间告警疲劳掩盖新问题 |
| 入口指向 | 核对 VIP/DNS/负载均衡目标 | 流量仍打到故障侧，用户继续不可用 |
『服务起来了』与『业务可用』之间隔着数据与入口两道核对，两份清单都要走完，缺一项都不算恢复完成。
故障侧要先隔离观察：未确认修复就让它自动回连，旧数据节点会带着过期数据重新加入拓扑，造成新的不一致。