引言

MySQL主从复制是高可用架构中常用的数据同步方案，但在实际运维中可能会遇到各种同步异常问题。其中，Error_code 1872 是较为常见的错误之一，通常表现为从库复制中断、事务数量不匹配等问题。

问题现象

在MySQL主从环境中，执行 SHOW SLAVE STATUS\G   命令时出现错误提示，错误代码为 1872 。
查看MySQL错误日志，通常会看到类似以下信息：

 [ERROR] Slave SQL for channel '': ... Error_code: 1872

该错误表明主库与从库在复制过程中事务数量不一致，导致数据同步中断。

问题原因

Error_code 1872 通常发生在以下场景：

•  从库服务器意外重启 ，导致中继日志信息结构初始化失败。

•  主从事务数量不匹配 ，多线程复制过程中校验机制发现不一致，主动中断复制以保障数据一致性。

解决方案

1. 删除现有复制链路

在从库上执行以下命令，清除当前的复制配置和中继日志：

RESET SLAVE;

作用说明 ：

•  删除 slave_master_info   和 slave_relay_log_info   表中的数据。

•  清除所有relay log文件，并重新生成新的 relay log。

•  注意 ：该操作不会影响 gtid_executed   或 gtid_purged   的值。

2. 重新配置主从链路

使用 CHANGE MASTER TO   命令重新指定主库信息（请根据实际环境替换参数）：

CHANGE MASTER TO
MASTER_HOST='10.0.0.50',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;

参数说明 ：

•  MASTER_HOST ：主库IP地址

•  MASTER_USER / MASTER_PASSWORD ：复制账户信息

•  MASTER_AUTO_POSITION=1 ：启用GTID自动定位模式

3. 启动复制并验证状态

启动从库复制进程：

START SLAVE;

查看复制状态，确认是否恢复正常：

SHOW SLAVE STATUS\G;

关键字段检查 ：

•  Slave_IO_Running   和 Slave_SQL_Running   应为 Yes

•  Last_Error   字段应为空

•  Seconds_Behind_Master   应逐渐趋近于0

注意事项

生产环境操作前 ，建议先备份从库数据，并在低峰期执行。

若从库数据与主库差异较大，建议先通过备份恢复数据，再重新配置复制。

定期检查主从延迟和错误日志，提前预防类似问题。

总结

Error_code 1872 通常是由从库重启或事务不一致引起的复制中断问题。通过 RESET SLAVE   清除异常状态并重新配置主从链路，可以快速恢复同步。建议在日常运维中加强监控，及时发现并处理主从异常，确保数据库高可用。