Got fatal error 1236 from master when reading data from binary log: ‘Slave can not handle replicatio...

本文介绍了如何通过禁用Binlog_checksum解决MySQL5.5到5.6主-主复制过程中出现的复制错误问题。当从较新版本复制到较旧版本时,由于binlog_checksum默认值的不同,可能导致复制失败。文章提供了具体的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

原文:

Disabling Binlog_checksum for MySQL 5.5/5.6 Master-master Replication
Replicating from a newer major version to an older major version in MySQL (for example a 5.6 master and a 5.5 replica) is generally not recommended, but when upgrading a master-master replication topology it’s hard to avoid this scenario entirely. We ended up in this situation last week when upgrading the passive master of an active-passive master-master pair from 5.5 to 5.6. The primary replication flow was going from the active master (5.5) to the passive master (5.6) with no errors, but pt-heartbeat was running on the passive master, which led to a replication failure with this error on the active master:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Slave can not handle replication events with the checksum that master is configured to log; the first event ‘bin-log.002648’ at 4, the last event read from ‘/var/lib/mysqllogs/bin-log.002648’ at 120, the last byte read from ‘/var/lib/mysqllogs/bin-log.002648’ at 120.’
Why did this happen? Starting in MySQL 5.6.6, the new binlog_checksum option defaults to CRC32. Since that option did not exist in MySQL 5.5, the replica can’t handle the checksums coming from the master. Therefore I recommend setting binlog_checksum=NONE in my.cnf as part of the upgrade process for a master-master setup to avoid this error.
My fix was to run this on the passive master:
1
set global binlog_checksum='NONE';
Then I added this to my.cnf so it would survive a restart:

1
binlog_checksum=NONE
After that change was made I examined the binary log to confirm that it did not include anything other than pt-heartbeat activity, and then executed CHANGE MASTER on the active master to skip the checksummed events.
Once the other master is upgraded I can go back and consider changing binlog_checksum to CRC32.
Apr 29th, 2014
MySQL
Comments
Posted by Ike Walker


翻译:


禁用Binlog_checksum MySQL 5.5/5.6 -主复制

从新的主要版本复制到一个年长的主要版本在MySQL中(例如5.6大师和一个5.5副本)通常不推荐,但是当升级-主复制拓扑ita€™年代很难完全避免这种情况。 在这种情况下我们最终上周升级主被动的被动主-主副从5.5到5.6。 主复制流从活跃的主人(5.5)的被动大师(5.6),没有错误,但是pt-heartbeat是运行在被动的主人,导致复制失败与主动掌握这个错误:

Last_IO_Error:有致命错误1236从二进制日志读取数据时从主:一个€˜奴隶不能处理复制事件的校验和主配置日志;第一个事件€˜bin-log。 002648一个€™4,最后一个事件读取€˜/ var / lib / mysqllogs / bin-log。 002648一个€™120岁的最后一个字节读取€˜/ var / lib / mysqllogs / bin-log。 002648一个€™在120.€™

为什么会这样? 从MySQL 5.6.6,新的binlog_checksum选择默认值CRC32。 自该选项不存在在MySQL 5.5中,复制品迦南€™t处理来自大师的校验和。 因此我建议设置binlog_checksum =没有作为在my . cnf中所做的升级过程-主设置以避免这个错误。

我的修复是运行这个被动的主人:

1
set global binlog_checksum='NONE';

然后我添加了所以在my . cnf中所做生存一个重启:

1
binlog_checksum=NONE

改变后我检查了二进制日志来确认它不包括任何pt-heartbeat活动,然后执行修改主在活动的主人跳过校验和事件。

一旦其他大师升级我可以回去考虑改变binlog_checksumCRC32。 


原文:

http://mechanics.flite.com/blog/2014/04/29/disabling-binlog-checksum-for-mysql-5-dot-5-slash-5-dot-6-master-master-replication/


### 回答1: 这是一个 MySQL 错误,表示在从二进制日志读取数据出现了严重错误 1236,原因是找不到二进制日志索引文件中的第一个日志文件名。建议检查日志文件和索引是否存在以及是否有读取权限,如果有必要可以尝试重建日志文件和索引。 ### 回答2: MySQL数据库出现“got fatal error 1236 from master when reading data from binary log: 'could not find first log file name in binary log index file'”这个错误,一般是由于MySQL的主从复制机制出了问题而引起的。 这个错误通常出现在MySQL主从复制过程中,因为主库的binary log文件找不到导致从库无法继续进行复制操作,从而导致复制过程被中断。 造成这种错误的原因很多,在MySQL主从复制的过程中,可能会由于网络问题、磁盘故障、权限设置不当等多种原因导致需要复制的binary log文件丢失或者找不到,从而引起这个问题的出现。 对于这个错误,可以尝试以下几种常见的解决方法: 1. 查找丢失的binary log文件和索引文件,将其复制到从库中对应的位置。 2. 检查从库的权限和配置是否正确,确保从库可以读取主库的binary log。 3. 确保MySQL版本在主从库之间一致。 4. 尝试重新启动MySQL服务,并检查MySQL日志文件是否有其他错误信息。 总的来说,出现这个错误需要仔细排查问题,找到出现问题的原因并及解决。只有在解决了这个问题之后,才能恢复MySQL主从复制的正常运行,保证数据的正确性。 ### 回答3: 这个错误提示表明在从二进制日志读取数据,主服务器出现了致命错误1236,并且无法在二进制日志索引文件中找到第一个日志文件的名称。可能的原因是二进制日志索引文件已损坏或被删除,或者日志文件已被清除导致不匹配。 解决此问题的方法是: 1.检查二进制日志索引文件 运行“show binary logs”命令,查看二进制日志文件的名称和位置。查看索引文件是否存在,如果不存在,则尝试恢复或重新创建该文件。如果该文件存在,但因某些原因包含不正确或损坏的数据,则可能需要手动编辑它来更新正确的文件名称和位置。 2.查找缺失的日志文件 如果主服务器无法找到第一个日志文件的名称,则可能是因为该文件已被删除或移动。在主数据库日志目录中检查缺失的日志文件,如果找到,请将它们移回原始位置。如果日志文件已经丢失,则可能需要从备份中恢复丢失的数据。 3.重启主服务器 有,重启主服务器可以清除潜在的错误状态,从而解决此问题。在重启前,建议停止从服务器上的复制进程,并确保所有活动连接都已关闭。 总之,当出现“从主服务器读取二进制日志发生致命错误1236”的错误,您需要检查二进制日志索引文件和缺失的日志文件,并尝试修复或恢复它们,或者从备份中恢复缺失的数据。如果问题仍然存在,请重启主服务器并查看错误日志获取更多信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值