MySQL主从复制不等于容灾，因网络中断、SQL报错、SET sql_log_bin=0、从库误写等会导致数据不一致；异地灾备须用pt-table-checksum校验内容一致性，且需验证切换流程与依赖配置。
MySQL主从复制本身不等于容灾
主从复制只是把主库的binlog重放一遍，它不保证从库和主库状态完全一致：网络中断、SQL线程报错、主库SET sql_log_bin=0绕过日志、从库read_only=0被误写……这些都会让从库“看起来在同步”，实际已偏离。异地从库如果只靠SHOW SLAVE STATUS里Seconds_Behind_Master = 0就认为可用，灾备演练时大概率失败。
异地从库做灾备演练前必须验证数据一致性
不能只看复制延迟，得确认数据内容是否真的一致。MySQL官方工具pt-table-checksum是目前最稳妥的选择，它通过分块校验+主从联查，能定位到具体表、具体行的差异。
- 必须在主库上运行，且主从都要开启
binlog_format = ROW，否则校验结果不可靠 - 避免在业务高峰跑全库校验，建议用
--databases限定关键库，或--tables指定核心表 - 校验后立刻用
pt-table-sync修复（但先在测试环境验证修复逻辑，线上慎用--execute） - 注意时区和字符集配置一致，否则
datetime字段或utf8mb4文本比对会误报
异地从库切换成新主库前的关键操作
灾备演练不是“停主库、启从库”那么简单。真实切换需要解决三个硬性依赖：
- 确保从库
relay_log_info_repository = TABLE且relay_log_recovery = ON，否则崩溃重启后可能丢掉未执行的中继日志 - 关闭从库的
read_only = 0后，必须手动清空gtid_executed（如果用GTID），或记录当前Exec_Master_Log_Pos并用CHANGE MASTER TO ... MASTER_LOG_POS显式定位，否则后续再挂回原主库容易错位 - 应用连接字符串里的
host和port要能快速切换，DNS缓存、连接池预热、事务超时设置都得提前压测，否则切完立刻出现大量Lock wait timeout exceeded
为什么异地延迟经常被低估
跨地域网络抖动、带宽限制、从库I/O能力弱于主库——这三者叠加会让Seconds_Behind_Master严重失真。比如主库批量写入10万行，从库单线程SQL线程解析慢，Seconds_Behind_Master可能显示2秒，但实际积压了3分钟的relay log没开始执行。
- 用
SHOW PROCESSLIST查从库SQL线程状态，如果是Waiting for dependent transaction to commit，说明正在等并行复制依赖，不是真快 - 监控
Relay_Log_Space增长趋势比Seconds_Behind_Master更反映真实积压 - 生产环境建议启用
slave_parallel_workers > 0，但要注意slave_parallel_type = LOGICAL_CLOCK在复杂事务下仍可能退化为单线程
异地灾备不是配好CHANGE MASTER TO就完事了，每次网络波动、每次DDL操作、每次参数调优，都可能悄悄破坏一致性。演练必须按真实故障路径走：断网→等超时→人工介入→校验→切换→回滚测试，少一个环节，上线那天就多一分不确定性。
