真正能落地的MySQL容灾演练手册核心是每步经得起掐表、故障注入和审计追问；须明确RTO/RPO数值、绑定业务与容灾等级、标注测量方式、区分自动/人工环节、固化回退路径、分层验证一致性，并如实记录非预期行为与绕过操作。
政企系统里，一份“写得漂亮但没人敢执行”的容灾演练手册，比没有还危险。真正能落地的MySQL容灾演练手册，核心不是模板多工整、流程多完整，而是每一步都经得起现场掐表、故障注入和审计追问——尤其在两地三中心达标验收前，审计最常卡住的点，是“你写的切换步骤，有没有人在真实数据库上跑过三遍？”
演练目标必须绑定RTO/RPO数值，不能只写“快速恢复”
“快速恢复”是模糊表述，验收时直接被否。手册开头就要明确本次演练针对哪类业务、对应哪级容灾等级，并把指标拆解到具体操作环节：
-
RTO=4分钟：从触发切换指令开始，到应用连上新主库并返回首条健康检查响应，全程≤240秒；其中DB切换本身≤90秒，DNS/服务发现刷新≤60秒，应用重连与连接池重建≤90秒 -
RPO=0：同城双中心间必须启用同步复制（如MGR单主或Percona XtraDB Cluster），异地中心允许异步，但需在手册中注明“异地RPO=15秒”，并附上show slave status\G中Seconds_Behind_Master的监控阈值告警逻辑 - 所有时间指标必须标注测量方式——是运维手动掐表？还是通过
pt-heartbeat脚本自动采集？审计会调取原始日志
切换步骤要区分“自动执行”和“人工确认”，且标注超时动作
很多手册把MHA或Orchestrator的自动切换流程写成黑盒，实际演练时一旦master_ip没及时更新或VIP漂移失败，整个流程就卡死。必须拆开写清边界：
- 自动环节（无需人工干预）：
orchestrator-client -c promote -a mysql-prod-01执行后，等待orchestrator返回Success: promoted，超时30秒未返回则终止并触发人工介入 - 人工确认环节（必须签字留痕）：执行
SELECT @@server_id, @@read_only;验证新主库状态；用mysqldump --single-transaction --skip-lock-tables对关键表抽样导出，比对checksum table结果；这些操作必须在手册中预留签名栏和时间戳位置 - 失败回退路径必须写死：比如“若新主库
Seconds_Behind_Master > 0持续超过60秒，则立即执行CHANGE MASTER TO MASTER_HOST='原主库IP'并重启SQL线程”，不能只写“视情况回滚”
数据一致性验证不能只靠pt-table-checksum
工具报“0 diff”不等于业务数据可用。政企场景下，一致性验证必须分层设计：
- 基础层：用
pt-table-checksum校验全库，但需限定--chunk-size=1000避免长事务阻塞，且结果必须保存到独立审计库（不能只存在临时表） - 业务层：选取3–5个核心交易流水表（如
order_info、account_balance），执行SELECT COUNT(*), SUM(amount) FROM ... WHERE create_time > '2026-10-15 08:00:00';，对比新旧主库结果；这个SQL必须固化在手册附录里，不能现场手写 - 逻辑层：模拟一笔真实业务（如社保缴费登记），在切换前插入测试记录，切换后检查该记录是否在新主库可查、关联状态机是否推进、下游Kafka消息是否补发——这步最容易被跳过，却是审计必查项
演练记录必须包含“非预期行为”和“绕过操作”
合格的手册不是只记录“按计划完成”，更要诚实记录所有偏离：
- 如果因
max_connections不足导致应用重连失败，手册里要写明：“第2次演练中，因新主库max_connections=300低于原主库500，导致23个服务实例连接超时；已修正为max_connections=600并加入基线配置检查项” - 如果某次用了
SET GLOBAL read_only=OFF强行修复，必须注明：“此操作绕过高可用管控策略，仅限本次应急，后续已通过orchestrator权限白名单机制封禁” - 所有“绕过”都要对应到配置变更单编号（如
CFG-20261015-087）和CMDB快照时间点，审计会交叉核验
真正难的不是写清楚“怎么做”，而是写清楚“做错时怎么收场”——政企容灾演练的底线，从来不是一次完美切换，而是在任何分支路径下，都有可追溯、可复现、可担责的动作闭环。
