MySQL主从复制出现1236错误怎么解决？教你快速定位修复

1. 问题现象

初始状态：Slave_IO_Running: No，Slave_SQL_Running: Yes

核心报错：

Last_IO_Error: Got fatal error 1236 ... 'Client requested source to start replication from position > file size'

含义：

从库请求的起始同步位点（Position）大于主库对应二进制日志文件的实际大小。

2. 根因分析

通过对比主从信息，精准定位了问题：

结论：

MASTER_LOG_POS=886 是当初执行 CHANGE MASTER 时手误填写的错误值，导致从库试图读取不存在的字节位置，I/O 线程报错中断。

3. 解决方案与调整过程

初次尝试（方案一）：直接执行 CHANGE MASTER TO ... MASTER_LOG_POS=157，但错误依旧。

根本解决（彻底重置）：在从库执行了更彻底的重置操作，清除了旧的中继日志和缓存信息，并重新指向主库当前正确的位点。

STOP SLAVE;
RESET SLAVE;      -- 清除旧的 master 信息
RESET SLAVE ALL;  -- 清除所有中继日志，彻底清理环境
CHANGE MASTER TO ... MASTER_LOG_POS=157; -- 重新配置正确位点
START SLAVE;

4. 最终结果

• Slave_IO_Running: Yes：I/O 线程成功连接主库并读取日志。
• Slave_SQL_Running: Yes：SQL 线程正常回放日志。
• Read_Master_Log_Pos: 157：从库已从正确的位置开始同步，Last_IO_Error 已清空，复制恢复正常。

5. 核心经验与要点

• 错误 1236 的指向性：该报错基本锁定为位点（Position）填写错误或主库 binlog 已被清理。
• 排查关键：通过 SHOW SLAVE STATUS 获取从库请求的位点，通过主库 SHOW BINARY LOGS 获取文件实际大小，对比即可确诊。
• 重置技巧：当 CHANGE MASTER 无法生效时，务必使用 RESET SLAVE ALL 彻底清空从库的复制环境再重试，避免旧缓存干扰。
• 数据一致性提醒：本次因主库刚初始化（无业务数据），直接跳转位点安全可行。若主库已有大量业务数据，位点丢失时必须使用 mysqldump 重导数据重新搭建，否则会导致数据冲突。
• 日常维护：后续定期关注 Seconds_Behind_Master 字段，确保延迟为 0，保持同步健康。

6. 总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。