主从复制作为MySQL高可用架构的基石，在运行过程中难免会遇到各种故障问题。本文 大致 地梳理 了一部分 主从复制中常见的IO线程和SQL线程故障，并提供诊断与处理 方法 ，帮助 大家 快速定位并解决问题。

一、监控与状态诊断

主从复制的健康状况监控是故障排查的第一步，通过 show slave status\G   命令可以获取关键状态信息：

# mysql -S /tmp/mysql3308.sock -e "show slave status \G"

关键状态参数解析：

•  Slave_IO_Running : IO线程运行状态（YES/NO/Connecting）

•  Slave_SQL_Running : SQL线程运行状态（YES/NO）

•  Last_IO_Errno : IO线程错误代码（如2003、1045、1040等）

•  Last_IO_Error : IO线程详细错误信息

•  Last_SQL_Errno : SQL线程错误代码（如1008、1007、1032等）

•  Last_SQL_Error : SQL线程详细错误信息

二、IO 线程故障分析与处理

1. 连接主库失败

常见原因：

•  连接信息错误（用户名、密码、IP、端口）

•  主库无法访问（网络中断、主库宕机、防火墙阻挡）

•  连接数达到上限

  解决方案：

  -- 调整最大连接数
  set global max_connections=1000;
  -- 检查并修正连接信息
  CHANGE MASTER TO
  MASTER_HOST='正确=IP',
  MASTER_USER='repl',
  MASTER_PASSWORD='正确密码',
  MASTER_PORT=3306;

2. Server_ID 或 Server_UUID 冲突

当主从节点的server_id或server_uuid相同时，复制会因标识冲突而失败。

解决方法：

-- 修改从库的server_id
set global server_id=1051;

确保每个MySQL实例的server_id全局唯一。

3. 请求主库日志失败

可能由于主库二进制日志损坏或丢失导致从库无法获取日志。

解决方法：主从重构

mysql> stop slave;
-- 清空从库复制信息
mysql> reset slave all;
-- 重新配置主从关系
mysql> CHANGE MASTER TO
  MASTER_HOST='10.0.0.52',
  MASTER_USER='repl',
  MASTER_PASSWORD='密码',
  MASTER_PORT=3306,
  master_auto_position = 1;
mysql> start slave;
mysql> show slave status\G;

三、SQL 线程故障分析与处理

SQL线程负责回放relay log中的事件，故障通常与数据一致性相关。

1. Relay Log 损坏

解决方法一：全量重建

备份主库数据（使用mysqldump、XtraBackup或Clone Plugin），恢复到从库后重新建立复制关系。

解决方法二：基于位置点重建

找到SQL线程停止的relay log位置，定位主库对应的binlog位置，然后基于位置重建。

mysql> stop slave;
mysql> CHANGE MASTER TO
  MASTER_HOST='10.0.0.51',
  MASTER_USER='repl',
  MASTER_PASSWORD='123',
  MASTER_PORT=3307,
  MASTER_LOG_FILE='mysql-bin.000011',
  MASTER_LOG_POS=193,
  MASTER_CONNECT_RETRY=10;
mysql> start slave;

2. SQL 执行错误

常见原因：

配置不一致 ：操作系统平台、MySQL版本、参数设置、SQL_MODE不同

对象不存在 ：尝试修改不存在的库、表或用户

对象已存在 ：创建已存在的对象导致约束冲突

根本原因 ：从库被直接写入，导致数据不一致。

解决方案：

方法一：跳过指定错误（谨慎使用）

mysql> stop slave;
-- 将同步指针向下移动一个事件
mysql> set global sql_slave_skip_counter = 1;
mysql> start slave;

方法二：配置文件跳过特定错误（不推荐）

# /etc/my.cnf
slave-skip-errors = 1032,1062,1007

常见错误代码：

•  1007：对象已存在

•  1032：无法执行DML（行不存在）

•  1062：主键或唯一约束冲突

方法三：GTID模式下的错误处理

查看监控信息:show slave status\G; 报错如下：

从库操作

mysql> stop slave;
-- 注入空事务
mysql> set gtid_next='befef0d5-3560-11ec-88ce-000c29f624c7:5';
mysql> begin;commit;
mysql> set gtid_next='AUTOMATIC';
mysql> start slave;

四、SQL线程故障规避方法

从库只读设置 ：启用 read_only 和 super_read_only 参数，防止误写入

读写分离中间件 ：使用MyCat、ProxySQL等中间件，规范读写路径

避免双主结构 ：考虑使用PXC、MGR等多主方案替代传统主从

定期数据校验 ：使用Percona Toolkit等工具定期检查主从数据一致性

版本与环境统一 ：确保主从节点的MySQL版本、配置参数一致

总结

MySQL主从复制故障的排查需要系统性的思维： 先监控定位，再分类处理 。IO线程问题多与连接和日志获取相关，而SQL线程问题则多源于数据不一致。通过标准化处理流程和预防措施，可以显著提高主从复制的稳定性和可靠性。