跨机房异步复制不能直接当作容灾方案，因其不校验从库落盘、seconds_behind_master失真、主库崩溃即丢binlog；真容灾需叠加semi-sync+gtid+延迟从库+网络调优四层加固。
跨机房异步复制在 MySQL 8.0 中**不能直接当作容灾方案使用**——它默认不校验从库落盘、Seconds_Behind_Master 失真、主库崩溃即丢 binlog，本质是“伪容灾”。真要跨机房容灾，必须叠加 semi-sync + GTID + 延迟从库 + 网络调优四层加固。
为什么 Seconds_Behind_Master 在跨机房下完全不可信
这个值只对比主库写入时间戳和从库 SQL 线程执行时间戳，根本不包含网络传输耗时。跨机房 RTT 通常 20–80ms，而 TCP 重传可能卡住 IO 线程几十秒甚至更久——此时 Seconds_Behind_Master 却可能恒为 0。更危险的是：relay_log_space_limit 默认为 0，IO 线程堆积大量未读 relay log，进一步掩盖真实延迟。
- 不要用
SHOW SLAVE STATUS判断是否可切换 - 不要依赖
SELECT MASTER_POS_WAIT()（无 GTID 时不可靠） - 监控必须加
Rpl_semi_sync_master_no_tx/Rpl_semi_sync_master_yes_tx比值，持续升高说明 semi-sync 实际频繁退化
必须开启 rpl_semi_sync 并调优超时参数
semi-sync 不是开关一开就安全，关键在超时逻辑是否匹配你的网络抖动特征。设太短（如默认 10ms）会频繁退化为异步；设太长（如 5s）则主库写入阻塞严重，业务直接受损。
- 主库配置：
rpl_semi_sync_master_enabled = ON，rpl_semi_sync_master_timeout = 1000000（即 1 秒，单位微秒） - 从库配置：
rpl_semi_sync_slave_enabled = ON，且slave_net_timeout ≥ rpl_semi_sync_master_timeout / 1000000 + 1（主设 1s，从库至少设 2s） - 务必确认从库已加载插件：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'
GTID 是故障切换唯一可信依据
没有 GTID，你无法准确判断哪台从库执行到了哪个事务点。一旦主库宕机，靠 File 和 Position 手动比对几乎不可能在几十秒内完成，且极易出错。
- 主从必须统一开启：
gtid_mode = ON和enforce_gtid_consistency = ON - 切主前，用
SELECT WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS('xxx-yyy-zzz:12345')等待指定 GTID 执行完成，而不是等Seconds_Behind_Master = 0 - 至少部署一台
CHANGE MASTER TO MASTER_DELAY = 3600的延迟从库，它不参与 semi-sync，但能防止误删/误更新被立刻传播
网络层必须绕过默认 TCP 栈瓶颈
MySQL 复制走普通 TCP 连接，而跨机房链路丢包率常达 0.1%–1%。Linux 默认 tcp_retries2 = 15，单次重传最长等 15 分钟——IO 线程直接卡死，复制彻底停滞。
- 在复制专用网卡上启用
tcp_fastopen - 将
tcp_retries2调低至 6（对应约 13 秒超时），避免无限等待 - 禁用 Nagle 算法：
net.ipv4.tcp_nodelay = 1 - 不要复用业务网卡跑复制流量，隔离带宽和队列
真正跨机房容灾的难点不在配置，而在验证：你得定期模拟主库断电、网络分区、从库磁盘满等场景，观察 semi-sync 是否如期退化、延迟从库能否及时介入、GTID 切换是否原子完成。这些环节任何一个没压测过，上线就是赌运气。
