主从复制跨机房必须禁用公网直连，主库3306端口严禁暴露公网；应绑定私有网络出口或启用require_secure_transport=ON+双向SSL，从库账号Host限定具体IP并授REPLICATION SLAVE权限，调大slave_net_timeout=60和net_read_timeout=30，mysqldump备份需带sha256校验，binlog须实时推送至对象存储，GTID切换前必须校验gtid_executed与gtid_purged一致性。
主从复制跨机房必须禁用公网直连
直接把主库 3306 端口暴露在公网，是异地容灾最常见也最危险的起点。它不光带来 Seconds_Behind_Master 持续飙升、SSL 缺失导致密码明文传输等风险，更可能因一次端口扫描就触发安全审计告警甚至被主动封禁。
实操建议：
- 主库必须绑定私有网络出口——例如阿里云 VPC 对等连接、AWS Transit Gateway，或通过专线网关中转；若实在只能走公网，务必在
my.cnf中启用require_secure_transport=ON并配好双向 SSL 证书 - 从库账号创建时，
Host字段绝不能写'%'，应限定为对端 NAT 网关 IP 或弹性公网 IP（如'203.205.128.45'），并显式授予REPLICATION SLAVE权限 - 跨地域网络延迟通常 >100ms，需调大两个关键超时参数：
slave_net_timeout=60（默认 60 秒已够，但建议显式设）、net_read_timeout=30（默认 30 秒，防止频繁重连导致IO_THREAD STOPPED）
mysqldump 离线备份必须带校验且独立运行
仅靠主从复制不是容灾，是延时极高的冷备。误删表、逻辑错误、binlog 被覆盖后，从库照样跟着错，此时离线备份才是最后一道防线。
实操建议：
- 使用
mysqldump --single-transaction --routines --triggers --databases db1 db2导出，避免锁表同时保留存储过程和触发器 - 导出完成后立刻执行
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 实时推送到对象存储才能压低 RPO
主从复制解决实时性，但 RPO 仍可能达分钟级；mysqldump 解决一致性，但恢复窗口长。真正把 RPO 压到秒级，得靠 binlog 实时落远端对象存储（如 AWS S3 / 阿里 OSS），且这条链路要独立于从库存在。
实操建议：
- 主库必须显式设置
expire_logs_days=7（或按业务 RPO 要求定），写入[mysqld]段并重启生效；否则磁盘满时 MySQL 强制 purge，会导致恢复链断裂 -
log_bin必须指向独立目录（如/data/mysql/binlog/），避免与数据文件混放；确认mysql用户对该目录有读权限（ls -ld /data/mysql/binlog/应显示 owner 是 mysql 且含 r-x） - 同步前执行
mysql -e "FLUSH LOGS;"，强制生成新 binlog；同步命令必须带--delete --checksum --partial，缺一不可 - 完整命令示例：
rsync -avz --delete --checksum --partial --progress /data/mysql/binlog/ user@backup-server:/backup/binlog/
GTID 切换前必须校验一致性
跨机房主从切换不是 stop slave + reset master 那么简单。如果主从 GTID 集不一致，强行提升从库为主库会导致后续 binlog 解析失败、数据跳变甚至主键冲突。
实操建议：
- 切换前先在从库执行
SELECT @@global.gtid_executed;和SELECT @@global.gtid_purged;，对比主库对应值是否完全一致 - 若不一致，不能直接
START SLAVE或CHANGE REPLICATION SOURCE TO，需先用SET GLOBAL gtid_purged = '...'补齐缺失集（注意：该操作不可逆，必须确认 purged 集已在目标端归档） - 切换后立即在新主库执行
SHOW MASTER STATUS;，记录新File和Position，供下游从库重新接入 - 所有应用连接串必须更新，DNS 或配置中心需支持秒级生效，避免旧连接继续打到原主库（此时它已是只读状态）
跨机房容灾最易被忽略的不是技术细节，而是“一致性验证”这个动作本身——很多人写了脚本自动切换，却忘了加一行 SELECT @@global.gtid_executed 校验。一旦跳过这步，故障恢复就变成故障扩散。
