MySQL 主从复制线程停止并不是普通的“短暂卡顿”，而是真实存在的复制故障，排查时应优先根据 Last_IO_Error 和 Last_SQL_Error 来定位根因：I/O 线程停止通常与网络异常、复制权限不足、server_uuid 冲突或 binlog 缺失有关；SQL 线程停止则常见于唯一键冲突、记录不存在、死锁或表结构不一致；如果这两个字段都为空，那么大概率是复制元数据损坏，需要通过 RESET SLA VE ALL 进行清理和重建。
MySQL 主从复制线程停止绝不是“偶发延迟”这么简单，而是明确的异常告警——只要出现 Sla ve_IO_Running: No 或 Sla ve_SQL_Running: No，就说明复制链路已经中断，必须及时人工排查和处理。很多人第一反应是直接执行 START SLA VE，但这种做法通常无法真正解决问题。正确思路是先确认到底是哪个线程停止，再结合报错信息分析具体原因。
看 Last_IO_Error 和 Last_SQL_Error 字段
这是排查 MySQL 主从复制中断最直接、最关键的入口，错误详情通常已经写在 SHOW SLA VE STATUSG 的输出结果中，不能忽略。
Last_IO_Error非空，表示 I/O 线程在连接主库或读取 binlog 时失败：常见原因包括网络不通、主库复制账号权限不足、server_uuid冲突、主库 binlog 被 purge 删除，或者复制位点无效Last_SQL_Error非空，表示 SQL 线程在回放 relay log 时发生报错：典型问题如ERROR 1062（唯一键冲突）、ERROR 1032（找不到记录）、ERROR 1205（死锁）、主从表结构不一致，或语句中包含从库不支持的函数- 如果两个字段都为空，但线程状态却是
No，那么极有可能是复制元数据文件损坏，例如master.info、relay-log.info出现异常，此时需要通过RESET SLA VE ALL清理后重新配置复制
确认线程卡在哪个位置
仅仅看到线程停止还远远不够，还必须进一步确认复制卡住的具体位置，否则无法判断应该跳过事务、重置位点，还是直接重搭从库。
- I/O 线程卡点可先查看
Master_Host、Master_Port是否可正常连接，再核对Master_Log_File和Read_Master_Log_Pos—— 这代表从库当前“准备读取”的主库 binlog 位置 - SQL 线程卡点则重点查看
Relay_Master_Log_File和Exec_Master_Log_Pos—— 这表示从库“最后成功执行”的主库 binlog 坐标 - 可借助
mysqlbinlog --base64-output=decode-rows -v /path/to/binlog.000001 | grep -A 5 -B 5 "Exec_Master_Log_Pos值"反查对应的原始 SQL 或 row event，用来确认该事务是否确实无法重放 - 在 GTID 模式下，应重点比对
Retrieved_Gtid_Set和Executed_Gtid_Set的差集，差多少就意味着当前缺失多少事务
区分 I/O 停和 SQL 停的修复路径
I/O 线程停止和 SQL 线程停止的故障性质完全不同，排查方法和修复路径也不一样，不能混在一起处理，否则很容易把问题扩大。
- I/O 停（
Sla ve_IO_Running: No）：优先检查telnet 主库IP 3306是否连通、主库上的复制账号权限是否正确（如SELECT user, host FROM mysql.user WHERE replication sla ve）、以及从库/var/lib/mysql/auto.cnf中的server-uuid是否与主库重复 - SQL 停（
Sla ve_SQL_Running: No）：不要直接使用sql_sla ve_skip_counter强行跳过，尤其在 GTID 模式下通常并不生效；更稳妥的方式是通过SET GTID_NEXT='xxx-xxx'配合空事务进行绕过，或者直接导出主库一致性快照后重建从库 - 如果
Seconds_Behind_Master为NULL，同时Sla ve_SQL_Running_State显示Waiting for gtid event from coordinator，这通常属于正常等待状态，并不一定表示复制卡死——此时应继续观察 GTID 集合差值是否持续增长
重做从库前必须清空 gtid_purged
这是 MySQL 主从重建过程中最容易被忽略、却又非常关键的细节。即使已经执行过 RESET SLA VE ALL，gtid_purged 中原有的历史记录依然会被保留。
- 如果导入新数据后直接执行
START SLA VE，MySQL 可能会判断这些 GTID 对应的事务“已经执行过”，从而跳过后续事件，最终导致复制立即停止或状态异常 - 正确做法是：导入 dump 完成后，先执行
SET GLOBAL gtid_purged = '新值'（也就是 dump 文件开头SET @@GLOBAL.gtid_purged那一行的内容），然后再执行START SLA VE - 如果导出的 dump 没有带
--set-gtid-purged=ON，则需要手动到主库执行SHOW MASTER STATUS，获取Executed_Gtid_Set后再进行赋值
