MySQL异地灾备恢复方案设计与实施指南

MySQL异地灾备恢复方案必须先明确 RTO 与 RPO，不能只依赖 CHANGE REPLICATION SOURCE TO 完成切换；还需要校验 GTID 一致性、关闭 relay_log_purge、解析 relay log 补齐事务，并在切换后安全重建复制拓扑。

设计 MySQL 异地灾备恢复方案时，不能只关注“是否能恢复”，更要提前定义清楚 RTO（要求秒级恢复还是分钟级恢复）与 RPO（是否允许事务丢失）。在跨地域容灾场景下，单纯依靠 CHANGE REPLICATION SOURCE TO 再将从库提升为主库，往往会在真实故障中失效，因为网络抖动、GTID 不一致、binlog 缺失、复制权限异常等问题通常会同时出现。

恢复前必须验证 GTID 一致性

当异地主从复制经过公网或远距离专线时，Seconds_Behind_Master 经常并不能准确反映延迟情况，例如卡在 Retrieved_Gtid_Set 与 Executed_Gtid_Set 不一致的状态。这种情况下，如果直接执行 STOP SLA VE; RESET SLA VE ALL; 然后切主，就很可能把尚未真正执行完成的事务直接跳过，导致数据不一致。

• 必须使用 SELECT * FROM performance_schema.replication_applier_status_by_coordinator; 检查实际已经应用的 GTID 范围
• 对比主库的 SELECT @@GLOBAL.GTID_EXECUTED; 与从库的 SELECT * FROM mysql.gtid_executed;，确认两边差集为空
• 如果存在 gap，应优先通过 mysqlbinlog --base64-output=DECODE-ROWS -v 解析缺失的 binlog 并手工回放，而不是直接强制跳过事务

切换时禁用自动清空 relay log 的行为

通常情况下，执行STOP SLA VE命令可能触发 relay log 清理。但在 MySQL 异地灾备恢复过程中，relay log 往往是唯一可用、承载“最后几秒关键数据”的重要介质。尤其是在主库已经不可访问、从库的IO_THREAD停止而SQL_THREAD仍在继续追赶时，relay log 中很可能仍保存着尚未应用完成的重要事务。

• 切换前执行 SET GLOBAL relay_log_purge = OFF;，避免 relay log 被自动删除
• 检查 SHOW SLA VE STATUSG 中的 Relay_Log_File 和 Relay_Log_Pos，记录当前复制位点
• 如需人工补救，可通过 mysqlbinlog relay-log-file | mysql -u root -p 补全剩余事务

从库提升为主库后，必须重置复制拓扑

原主库恢复后如果直接重新加入集群，极有可能因为自增 ID 冲突、GTID 重复或 binlog 位点混乱而导致复制中断。问题的关键并不是“能不能接回”，而是“如何安全地接回并恢复拓扑”。

• 在新主库上执行 RESET MASTER;（仅适用于确认原主库永久下线的场景）或 SET GLOBAL GTID_PURGED = 'xxx';（用于保留原主库已执行的 GTID 集合）
• 原主库恢复后，不能继续沿用旧的 CHANGE REPLICATION SOURCE TO 配置，必须先 RESET SLA VE ALL;，再根据新主库的 SHOW MASTER STATUS 输出重新配置复制关系
• 如果使用 auto_increment_increment/auto_increment_offset 实现多活避让，切换后还要核对新主库的 offset 设置是否与原架构一致，否则业务写入时可能发生主键冲突

真正困难的部分，不是命令本身如何执行，而是每次切换前能否快速判断：当前从库的 relay log 是否完整、GTID 是否能够对齐、业务表中是否残留未提交的 XA 事务。如果这些关键细节没有提前压测，也没有形成标准化检查清单，那么 MySQL 异地灾备恢复就很容易演变成一次高风险的人工抢修过程。