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 异地灾备恢复就很容易演变成一次高风险的人工抢修过程。
