MySQL主从同步出错后，须先通过SHOW SLAVE STATUS\G定位错误类型、线程状态及延迟，再按轻量跳过（仅限非关键错误）、pt-table-sync精准修复或重建从库三类路径处置，严禁盲目强制同步。
MySQL 主从同步出错后，不能简单“强制同步”，而是要根据错误类型、数据差异程度和业务一致性要求，选择安全、可逆的操作路径。核心原则是：先定位问题，再选方法，避免跳过关键事务导致数据永久不一致。
先查清错误原因和状态
登录从库执行：
SHOW SLAVE STATUS\G
重点关注三项：
- Slave_IO_Running 和 Slave_SQL_Running：必须都为 Yes 才算复制通道畅通
- Last_SQL_Error：直接显示失败语句及错误码（如 1062 主键冲突、1049 库不存在）
- Seconds_Behind_Master：非零或为 NULL 可能意味着 SQL 线程已停，需结合 Exec_Master_Log_Pos 与 Read_Master_Log_Pos 差值判断是否积压
轻量修复：跳过单条可确认无害的错误
适用于明确知道该事件不该在从库执行的场景（例如主库重复插入同一主键、从库已存在同名数据库）：
- 停复制：STOP SLAVE;
- 跳过当前错误事件：SET GLOBAL sql_slave_skip_counter = 1;
- 启复制：START SLAVE;
注意：GTID 模式下禁用此法，应改用 SET GTID_NEXT + 空事务方式；且跳过前务必确认主库该操作确实无需同步（比如 set sql_log_bin=0 的语句）。
精准修复：用 pt-table-checksum 校验并修复差异
当怀疑有隐藏数据不一致（如误写从库、binlog 格式不兼容），但又不想全量重建时，推荐 Percona Toolkit：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 主库运行校验：pt-table-checksum --no-check-binlog-encrypted --replicate=test.checksums
- 从库比对并生成修复语句（先预览）：pt-table-sync --replicate=test.checksums --print --sync-to-master
- 确认无误后执行修复：pt-table-sync --replicate=test.checksums --execute --sync-to-master
优势是只修差异行、不锁表、支持限速；前提是主从表结构、字符集、时间精度完全一致，且从库 read_only=ON。
彻底重建：重做主从全量同步
适用于 Seconds_Behind_Master 持续增长、Last_SQL_Error 频发、或已确认数据偏差较大（如从库被误删表、主库未开启 binlog）：
- 主库加读锁并记录位点：FLUSH TABLES WITH READ LOCK; → SHOW MASTER STATUS;
- 主库导出全量数据（含位点信息）：mysqldump -A --master-data=2 --single-transaction > full.sql
- 解锁主库：UNLOCK TABLES;
- 从库停复制、清空旧数据（可选）、导入备份：STOP SLAVE; → mysql
- 从备份中提取 CHANGE MASTER TO 语句（grep "CHANGE MASTER TO" full.sql），或手动执行：CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;
- 启动复制：START SLAVE;
整个过程需确保主库写入暂停窗口足够短，或安排在低峰期操作；若使用物理备份（如 xtrabackup），可进一步缩短停机时间。
