高可用实验验收实践：故障矩阵与恢复证据
按单一故障逐项记录隔离、角色变化、事务核对和恢复时间，明确争议数据保全及旧主重新加入的边界。
验收准备与权限
本篇定义待执行的实验清单，没有实际切换成绩。每条拓扑单独安排隔离测试窗口，准备受保护凭据、可恢复备份、节点清单、故障回收方式和中止负责人。所有故障注入需明确范围与授权，不能将本文阅读或方案发布视为生产执行许可。先确认系统健康，未解决的容量、复制或时间同步异常会污染实验结论。
正常状态基线
记录权威主节点、复制方向、应用入口、长连接和测试流水。在已经核验身份的 PostgreSQL 测试连接中，下面 SQL 只读版本与恢复角色；它不会提升节点，也不能证明全局没有其他可写主节点。
SHOW server_version;
SELECT pg_is_in_recovery();对全部相关节点和入口取证，日志统一时间基准。测试客户端为每个操作保留唯一业务标识、发送时间和响应分类，凭据与真实数据不得混入报告。
逐项故障矩阵
先验证健康节点间的计划切换，再逐项评审单节点失效、复制中断、客户端旧连接及网络分区。PostgreSQL 另行检查 DCS 成员或多数不可用时的行为；Redis 检查 Sentinel 发现与授权条件；MySQL 核对提升流程和旧主写入隔离。每次只引入一种故障，恢复健康并重新确认基线后才开始下一项，不复制同一套切主命令跨数据库使用。
事务核对与时间线
记录故障开始、旧主隔离生效、新主可写、客户端稳定恢复和冗余重建完成的时间。业务确认提交、明确失败和结果不明的请求必须分别核对；连接中断后的事务不可无条件重放。MySQL 用 GTID 与业务抽样结合，PostgreSQL 保存时间线和 WAL 相关证据，Redis 结合复制与业务测试记录判断，不把三类位点直接互相比较。
将实测数据缺口和中断时间与事先批准的 RPO/RTO 对照。缺少流水、时间不一致或无法解释的重复写入都属于未通过，不能用“主节点已恢复”覆盖事务结果问题。
停止与权威恢复
发现双主迹象或超出数据丢失目标时立即停止故障注入，控制受影响写入口并保存两侧证据。由授权负责人确定可信权威，不能仅看哪个节点先启动。新主已经接受写入后不自动回切；旧主保持隔离，完成分叉分析，再按经批准的重同步或重建方案作为副本加入。重建前保留所需日志和争议数据，避免抹去核对依据。
独立备份与最终交接
在与原集群隔离的恢复环境验证备份，核对恢复点、数据抽样、必要扩展和应用可读性，不覆盖原实验数据。高可用副本同步成功不能代替该检查。最终报告逐项填写实际结果、残留缺口、恢复耗时和责任人；未执行项目保持待验证。生产接入前再次评审凭据、告警、接管流程与观察窗口。