跨地域MySQL容灾需主从复制+离线备份+binlog同步：主库限私网/SSL，从库限定IP授权；调大超时参数；mysqldump校验归档；binlog实时推对象存储；切换前校验GTID一致性。
MySQL主从复制跨地域部署的网络与权限前提
异地备份容灾不能只靠定时导出 SQL 文件——那不是容灾，是延时极高的冷备。真正可用的方案必须依赖主从复制（CHANGE REPLICATION SOURCE TO）或 GTID 模式，但跨地域直连主库存在明显风险：公网 IP 暴露、网络抖动导致 Seconds_Behind_Master 持续飙升、SSL 配置缺失引发密码明文传输。
实操建议：
- 主库必须绑定私有网络出口（如阿里云 VPC 对等连接、AWS Transit Gateway），禁止直接开放
3306到公网；若只能走公网，务必启用require_secure_transport=ON并配置双向 SSL - 从库账号需显式授予
REPLICATION SLAVE权限，且 Host 不能写'%'，应限定为对端 NAT 网关或弹性公网 IP（如'203.205.128.45'） - 跨地域延迟通常 >100ms，需调大
slave_net_timeout（建议设为 60）和net_read_timeout（建议 30），否则频繁重连会触发IO_THREAD STOPPED
用 mysqldump + rsync 实现带校验的离线归档备份
主从复制解决的是实时性，但无法防范误删表、逻辑错误或 binlog 被覆盖。异地离线备份必须独立运行，且要能验证完整性——否则传到远端的可能是一堆损坏的 .sql 文件。
关键操作点：
- 使用
mysqldump --single-transaction --routines --triggers --databases db1 db2 > backup_$(date +%Y%m%d_%H%M%S).sql，避免锁表同时保留存储过程 - 生成校验值：执行完 dump 后立刻运行
sha256sum backup_*.sql > backup_*.sql.sha256，把 .sha256 文件和 .sql 一起传输 - 异地接收端用
rsync --partial --progress -e "ssh -o StrictHostKeyChecking=no" user@src:/path/backup_*.sql* /dst/，加--partial防断点续传失败 - 收到后必须校验：
sha256sum -c backup_*.sql.sha256，输出OK才算有效
binlog 跨区域实时同步到对象存储（如 AWS S3 / 阿里 OSS）
仅靠主从或 mysqldump，RPO（恢复点目标）仍可能达分钟级。把 binlog 推送到远端对象存储，配合定期全量备份，可将 RPO 压到秒级，且避免从库单点故障影响备份链路。
实施要点：
- 主库开启
log_bin = ON和expire_logs_days = 7（至少保留 7 天），确保 binlog 不被自动清理 - 用
mysqlbinlog --read-from-remote-server --host=master_ip --user=replica --password=xxx mysql-bin.000001拉取指定 binlog，配合cron每 30 秒轮询最新文件名（解析SHOW BINARY LOGS输出） - 上传前压缩：
gzip mysql-bin.000001，再用aws s3 cp mysql-bin.000001.gz s3://my-backup-bucket/binlogs/，注意设置生命周期策略自动清理 30 天前文件 - 远端恢复时，先找最近全量备份点，再按时间顺序应用对应 binlog（
mysqlbinlog --stop-datetime="2024-06-15 14:23:00" mysql-bin.000001 | mysql -u root -p）
切换脚本中容易忽略的 GTID 一致性检查
当主库宕机需切到异地从库时，很多人直接执行 STOP SLAVE; RESET SLAVE ALL; 就对外提供服务，结果发现新写入数据在原主库恢复后无法合并——根本原因是 GTID 集合不一致，SELECT @@global.gtid_executed 在两地已分叉。
切换前必须确认：
- 从库已追平：检查
SELECT SERVICE_STATE FROM performance_schema.replication_applier_status_by_coordinator;返回ON，且Retrieved_Gtid_Set等于Executed_Gtid_Set - 手动补漏：若发现
Retrieved_Gtid_Set有增量但未执行，用START SLAVE UNTIL SQL_AFTER_GTIDS = 'uuid:1-100'补齐 - 切主后立即在新主库执行
SET GLOBAL gtid_purged = 'uuid:1-100';（值来自原主库SELECT @@global.gtid_purged;），否则其他从库将拒绝接入
跨区域容灾最麻烦的从来不是技术实现，而是网络不可靠时的边界判断——比如主库短暂失联，是等它恢复，还是立刻切？这个决策逻辑没法全自动，得靠人工介入窗口和明确的超时阈值来兜底。
