不能只靠mysqldump+rsync做异地灾备恢复，因其仅提供时间点快照、无后续变更保障，rpo不可控；且未校验压缩完整性易致演练失败；直接rsync运行中/var/lib/mysql必然失败，恢复后报tablespace缺失或启动失败。
异地恢复演练不是“把备份拷过去再启动”，而是验证整个灾备链路在真实故障下是否可用。核心结论：必须用主从复制链路做主通道，辅以 mysqldump 或 xtrabackup 逻辑/物理备份做兜底；直接 rsync /var/lib/mysql 在生产环境必然失败，恢复后大概率报 Tablespace is missing for table 或 MySQL 启动失败。
为什么不能只靠 mysqldump + rsync 做异地灾备恢复？
因为 mysqldump --single-transaction 生成的是某个时间点的快照，它不包含 dump 之后产生的任何变更。一旦主库在 dump 完成后、rsync 到异地前发生误删或崩溃，这部分数据就彻底丢失——RPO（恢复点目标）不可控。
- 中小库（mysqldump --single-transaction --routines --triggers --databases db1 db2 配合
FLUSH LOGS记录起始 binlog 位置，用于后续增量追平 - 大库（>100GB）必须用
xtrabackup或mydumper，否则单线程 dump 会卡死，且无法保证一致性 - 所有逻辑备份必须在异地存储前校验：
gunzip -t backup.sql.gz（gzip）或zstd -t backup.sql.zst（zstd），避免压缩损坏导致演练时才发现文件不可用
主从复制链路在异地演练中必须显式调优哪些参数？
跨机房网络存在 NAT 超时、偶发丢包，MySQL 默认复制参数扛不住。未调优时常见现象是 Seconds_Behind_Master 突然飙升到数万秒，IO 线程卡死不自动重连。
-
MASTER_HEARTBEAT_PERIOD = 30.0：强制主库每 30 秒发心跳，比默认 0（禁用心跳）早发现链路异常 -
slave_net_timeout = 60：将 IO 线程等待响应上限从默认 3600 秒砍到 60 秒，“快断快重连”，不傻等一小时 -
MASTER_RETRY_COUNT = 86400：允许一天内无限次重试，避免一次连接失败就永久中断 SQL 线程 - 绝对不要用
auto-reconnect：该参数已被 MySQL 官方弃用，且对复制线程完全无效
GTID 模式下异地恢复最易忽略的三个检查点
混合云环境（如阿里云主库 → 腾讯云从库）初始化时，server_id 和系统时间偏差哪怕只差 1 秒，都会导致 GTID 复制中断，错误日志却只显示模糊的 Could not parse relay log event entry。
- 执行
SELECT @@server_id确保主从值唯一，不能都为 1 或都为空 - 执行
SELECT UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(UTC_TIMESTAMP())核查主从与 UTC 偏差，>1 秒必须同步 NTP（尤其注意腾讯云 CVM 默认不启用 chrony） - 确认
gtid_mode=ON且enforce_gtid_consistency=ON同时生效，否则某些语句（如临时表+事务混用）会静默失败
真正难的不是命令怎么写，而是演练时敢不敢在从库上模拟删库、敢不敢手动 kill 主库进程、敢不敢拔网线测重连——这些操作暴露的才是配置盲区和文档断点。每次演练后，重点看三件事：恢复耗时是否在 RTO 内、GTID 集合是否连续、业务查询结果是否与主库最终一致。其余都是纸面功夫。
