真正可用的跨区域容灾必须满足实时数据同步能力+独立可验证备份；常见错误是误将mysqldump冷备当容灾，导致rpo数小时、无法应对逻辑错误；需结合私网主从复制、binlog实时推送至对象存储并校验、gtid一致性验证三重保障。
MySQL跨区域容灾不能只靠mysqldump定时导出
直接用mysqldump生成SQL文件再rsync到异地，不是容灾，是冷备。RPO（恢复点目标）动辄数小时，且无法应对误删、逻辑错误、SQL注入导致的数据污染。真正可用的跨区域容灾必须满足两个前提：实时数据同步能力 + 独立于主从链路的可验证备份。
实操中常见错误是把mysqldump脚本塞进crontab就以为万事大吉——结果某次网络抖动导致dump中途失败，生成的.sql文件末尾截断，但校验脚本没跑，备份文件照常上传；等真出事才发现恢复出来的库缺了半张表。
- 全量备份必须带
--single-transaction（InnoDB）或--lock-all-tables（MyISAM），否则可能产生不一致快照 - 每次dump后立刻执行
sha256sum backup_*.sql > backup_*.sql.sha256，且.sha256文件必须和.sql一起传输 - 异地接收端必须运行
sha256sum -c backup_*.sql.sha256，输出OK才算有效，不能只看文件大小或mtime
主从复制跨地域部署必须关闭公网直连
用CHANGE REPLICATION SOURCE TO拉起跨地域从库时，若主库3306端口直接暴露在公网，等于把账号密码、binlog内容全摊开——中间人劫持、暴力爆破、SSL未启用导致明文传输都是真实风险。更隐蔽的问题是网络延迟波动引发Seconds_Behind_Master持续飙升甚至IO线程自动STOP。
正确做法是切断公网通路，改走云厂商提供的私网通道：
- 阿里云用户必须配置VPC对等连接或云企业网CEN，主库绑定私网IP，禁止安全组放行0.0.0.0/0的3306
- AWS用户应使用Transit Gateway + PrivateLink，避免EC2弹性公网IP参与复制链路
- 从库账号授权语句必须写死IP：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'203.205.128.45'，严禁用'repl'@'%' - 调大超时参数：
slave_net_timeout=60、net_read_timeout=30，防止频繁重连触发IO线程中断
binlog实时推送到对象存储才能压低RPO到秒级
仅靠主从复制，一旦从库宕机或网络中断，binlog就断在本地，RPO立即退化为上次全备时间点。把binlog同步到远端对象存储（如AWS S3、阿里OSS），相当于给复制链路加了一条“逃生通道”：即使整个从库集群不可用，也能从S3拉取最新binlog做PITR（基于时间点恢复）。
关键不在“推”，而在“可控”和“可验”：
- 用
mysqlbinlog --read-from-remote-server配合cron每30秒拉一次新binlog，重命名规则含server_id+timestamp，避免覆盖 - 上传前生成
.sha256并存为S3元数据（x-amz-meta-sha256），接收端用aws s3api head-object校验后再下载 - 务必开启S3版本控制与对象锁（
ObjectLockEnabled=Enabled），防勒索软件篡改或误删 - 不要依赖
expire_logs_days自动清理，binlog保留策略应独立配置，建议至少保留7天
演练时最容易忽略GTID一致性校验
切换前只查SHOW REPLICA STATUS\G看到Seconds_Behind_Master: 0就切，是高频事故原因。GTID模式下，从库可能已追平位点，但Executed_Gtid_Set和主库Retrieved_Gtid_Set不一致——比如主库被人工跳过事务、或从库执行了SET GTID_NEXT伪指令，此时强制提升为新主库会导致后续复制断裂。
真实演练中必须跑这三步：
- 在从库执行
SELECT @@global.gtid_executed = (SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'gtid_executed')确认自身GTID集合完整 - 对比主库
SELECT @@global.gtid_executed和从库SELECT Retrieved_Gtid_Set FROM performance_schema.replication_connection_status，二者必须完全相等 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v抽查S3上最新binlog头尾，确认GTID_LOG_EVENT连续无gap
GTID不一致问题不会在日常监控里报警，只有切换那一刻才爆发——而那时已没有回滚窗口。
