同步失败应先查show slave status\g的slave_io_running、slave_sql_running、seconds_behind_master三字段：io为no是连接问题，sql为no是执行卡住，seconds_behind_master为null且sql停止需结合last_sql_error分析。
从库同步失败，先看 SHOW SLAVE STATUS\G 的关键字段
同步失败不是“黑盒”，MySQL 已经把线索全写在 SHOW SLAVE STATUS\G 里了。别急着重启或跳过错误，先盯住三个字段：Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master。
- 如果
Slave_IO_Running是No，说明从库根本连不上主库——问题在连接层，90% 是网络或权限； - 如果
Slave_SQL_Running是No，但 IO 线程正常，说明 binlog 拉下来了，但执行卡住了——常见于语句级冲突、主键重复、表结构不一致或 relay log 损坏； -
Seconds_Behind_Master为NULL且 SQL 线程停止，往往意味着 SQL 线程已崩溃，需要结合Last_SQL_Error和Last_SQL_Errno定位具体报错。
特别注意：Connecting 或 Reading from net 在 State 字段里挂太久（比如持续几十秒），基本可以判定是网络不通、防火墙拦截、或主库 max_connections 耗尽导致 dump 线程拒绝响应。
排查网络延迟：别只 ping，要测真实复制链路
单纯 ping 主库 IP 只能验证三层连通性，而 MySQL 复制走的是 TCP 3306 端口，且依赖稳定带宽和低丢包率。实际传输的是 binlog event 流，对抖动和重传更敏感。
- 用
iperf -c -p 3306（需服务端先启iperf -s -p 3306）测端到端吞吐和丢包，比 ping 更贴近真实负载； - 用
tcpdump -i any port 3306 -w mysql-replica.pcap抓包，过滤出从库 IP → 主库 IP 的 SYN/ACK 时延，确认是否存在 TCP 重传或 RST； - 检查主库
netstat -an | grep :3306 | grep ESTABLISHED | wc -l，若连接数接近max_connections，IO 线程会排队等待，表现为间歇性Connecting状态。
容易踩的坑：跨云厂商或跨机房部署时，没开 BBR 拥塞控制、MTU 不匹配（尤其用了 VXLAN 或隧道），会导致小包正常但大 binlog event 传输严重延迟甚至超时。
判断 binlog 是否损坏：从主库 mysqlbinlog 解析入手
从库报错如 Could not parse relay log event entry、log event entry corrupted 或 Relay log read failure，大概率是 relay log 或主库原始 binlog 损坏。但不能直接假设“从库磁盘坏了”，得先验证源头。
- 在主库上执行：
mysqlbinlog --base64-output=DECODE-ROWS -v <binlog> | head -n 100</binlog>，看能否正常解析前几条 event；若报错Failed to open file或unknown error，说明 binlog 文件本身已损坏； - 对比主库
SHOW MASTER STATUS中的File和Position，与从库SHOW SLAVE STATUS中的Master_Log_File和Read_Master_Log_Pos—— 若 position 差距极大且Seconds_Behind_Master不更新，可能是 IO 线程拉取中断后写入了截断的 relay log； - 从库 relay log 默认存在
relay_log配置路径下，用file /var/lib/mysql/relay-bin.000001确认是否为“data”类型，而非“empty”或“broken”；误删relay-log.info文件也会导致位置错乱，引发后续解析失败。
注意：mysqlbinlog 解析失败 ≠ 一定物理损坏，也可能是主从 MySQL 版本差异导致 event 格式不兼容（比如主库 8.0.33 启用了 binlog_transaction_compression，但从库 5.7 无法解压）。
快速恢复同步：跳过错误要谨慎，重建 relay log 更稳妥
当确认是单条语句错误（如主库误删从库有数据的记录），且业务允许短暂不一致时，可临时跳过；但若怀疑 relay log 损坏或位置错乱，强行 SET GLOBAL sql_slave_skip_counter = 1 可能导致后续所有事件偏移，越跳越错。
- 安全做法是：停掉从库
STOP SLAVE→ 清空 relay log（RESET SLAVE ALL）→ 手动指定主库当前 binlog 位置（CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy）→ 再启动； - 若主库 binlog 已被清理（
Purge Binary Logs），无法找到对应位置，则必须重新做一次全量同步（mysqldump或Percona XtraBackup）并重放； - 避免使用
slave_skip_errors全局配置，它会掩盖真正的问题，比如主键冲突可能源于从库被误写，而非单纯语句错误。
最常被忽略的一点：relay_log_recovery = ON 这个参数默认是关的。开启后，从库重启时会自动校验 relay log 完整性并重建损坏部分——上线前务必检查该配置，否则每次异常宕机都可能埋下同步断裂隐患。
