这个报错网上搜索了一下,大部分是由于MySQL意外关闭或强制重启造成的binlog文件事务点读取异常造成的主从同步报错
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the last event was read from '/mysqlLog/aldb2/logs/mysql-bin.000105' at 112415826, the last byte read was read from '/mysqlLog/aldb2/logs/mysql-bin.000105' at 112415845.'
网上有对这种问题进行的解释:
http://www.itpub.net/thread-1778154-1-1.html
1)就是主库的主机宕机了,从库再次启动时,出现错误,这个在sync_binlog=0的情况,很容易出现。
原因: sync_binlog=0时 ,master binlog文件的flush log buffer(这个buffer是由于binlog文件的os buffer) 到disk是依赖于OS本身的,但Slave IO 线程在读取master dump 线程的位置,一般是直接读取log buffer的,
这个位置,可能远远大于,binlog文件实际大小。 所以当主机宕机后,binlog buffer未刷盘,当Master主机再次启动后,此时从库的binlog pos已经比实际的binlog文件大小还大了。
处理方法:如果innodb_flush_log_at_trx_commint=1的话,这一般对主从不会有影响的,直接做change master to到当下一个binlog。
如果是其他值2或0,可能有点小差别。
有人说重新change就可以,我通过mysqlbinlog 查看报错时的binlog文件最后的几个事务,也尝试change最后几个事务的点,但未成功。
后来按照一个网友的方法
1、flush log;
2、show master status \G
3、change master on 'master新binlog文件'
问题解决,但最后mysqlbinlog检查主库上一个binlog文件最后的几个事务是否完成,保证数据一致
这个对于MySQL5.5的半同步复制进行的说明也不错:
http://wubolu.iteye.com/blog/721131
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· 三行代码完成国际化适配,妙~啊~
· .NET Core 中如何实现缓存的预热?
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?