主从延迟过大需检查网络、从库性能、大事务及并行复制设置，操作步骤包括查看延迟状态、检查sql线程、启用并行复制或重建从库。同步报错如1062、1032可通过跳过错误、使用pt-table-checksum修复或启用idempotent模式处理。重建从库流程为停止复制、主库备份、导入从库并配置同步信息。日常应定期校验一致性以预防问题。
MySQL主从复制一旦出现故障，同步中断会影响数据一致性，特别是对于高并发或对数据实时性要求较高的业务来说，必须快速定位问题并恢复。以下是一些常见场景和实操建议，帮助你更高效地解决主从同步异常。
主从延迟过大，如何排查和恢复？
主从延迟是常见的复制问题之一，表现为从库的数据更新明显滞后于主库。首先需要确认延迟的来源：
- 网络不稳定：检查主从之间的网络带宽是否受限或有丢包。
- 从库性能瓶颈：比如CPU、IO压力大，导致SQL线程处理慢。
- 大事务未提交：一个长时间运行的事务会阻塞后续操作。
- 没有使用并行复制：MySQL 5.7+ 支持多线程复制，可以显著提升效率。
建议操作步骤：
使用
SHOW SLAVE STATUS\G查看Seconds_Behind_Master的值，确认延迟程度。-
检查是否有长时间运行的查询，通过
SHOW PROCESSLIST看SQL线程状态。
-
启用并行复制（按库、按事务），修改配置文件：
slave_parallel_type=LOGICAL_CLOCK slave_parallel_workers=4
对于严重延迟的情况，可考虑重建从库，用备份+binlog的方式重新同步。
主从同步报错，如1062、1032错误怎么处理？
在复制过程中，常见的错误包括重复键冲突（1062）、记录不存在（1032）等，通常是由于主从数据不一致导致。
典型场景：
- 主库插入一条唯一键记录，而从库已有相同键值。
- 主库执行了DELETE操作，但该记录在从库中不存在。
处理建议如下：
-
如果是测试环境或者允许少量数据丢失，可以跳过错误：
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;
更稳妥的做法是使用工具比对主从数据一致性，例如
pt-table-checksum和pt-table-sync来修复差异。在修复前务必做好数据备份，避免误操作导致更大问题。
日常运维中建议开启
slave_exec_mode=IDEMPOTENT，让从库忽略部分重复错误。
如何快速重建从库以恢复同步？
当主从差异较大，或多次出错难以修复时，重建从库是最直接有效的方法。
基本流程如下：
-
停止从库复制线程：
STOP SLAVE;
-
在主库进行逻辑备份（如使用mysqldump）：
mysqldump -h 主库地址 -u root -p --single-transaction --master-data=2 数据库名 > backup.sql
将备份导入从库，并解析
CHANGE MASTER TO的位置信息。-
配置从库指向主库，并启动复制：
CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl', MASTER_PASSWORD='密码', MASTER_LOG_FILE='binlog文件名', MASTER_LOG_POS=对应的位置号; START SLAVE;
注意：如果主库写入量很大，建议使用物理备份工具如 xtrabackup 来减少锁表时间。
基本上就这些。主从复制恢复的关键在于快速判断问题类型，选择合适的处理方式。日常维护中建议定期做主从一致性校验，提前发现潜在风险，避免故障发生时手忙脚乱。
