【MySQL】Got fatal error 1236原因和解决方法-阿里云开发者社区

开发者社区> 数据库> 正文

【MySQL】Got fatal error 1236原因和解决方法

简介:
一 前言
  MySQL 的主从复制作为一项高可用特性,用于将主库的数据同步到从库,在维护主从复制数据库集群的时候,作为专职的MySQL DBA,笔者相信大多数人都会遇到Got fatal error 1236 from master when reading data from binary log” 这类的报错/报警。本文整理了常见的几种 error 1236 报错,并给出相应的解决方法,有所不足之处,当然也希望各位读者朋友指正。


二 常见的error 1236 报错
2.1 logevent超过max_allowed_packet 大小


Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the start event position from 'mysql-bin.006730' at 290066246, the last event was read from '/u01/my3309/log/mysql-bin.006730 

原因
   此类报错和max_allowed_packet相关。首先max_allowed_packet控制着主从复制过程中,一个语句产生的二进制binlog event大小,它的值必须是1024的倍数 。出现此类错误的常见原因是
 1 该参数在主备库的配置大小不一样,主库的配置值大于从库的配置值。 从主库传递到备库的binlog event大小超过了主库或者备库的max_allowed_packet大小。
 2 主库有大量数据写入时,比如在主库上执行 laod data,insert into .... select 语句,产生大事务。
当主库向从库传递一个比从库的max_allowed_packet 大的packet ,从库接收该packet失败,并报 “log event entry exceeded max_allowed_packet“。
如何解决
 需要确保主备配置一样,然后尝试调大该参数的值。


set global max_allowed_packet =1*1024*1024*1024;
 
stop slave;

start slave 

另外,5.6 版本中的 slave_max_allowed_packet_size 参数控制slave 可以接收的最大的packet 大小,该值通常大于而且可以覆盖 max_allowed_packet 的配置, 进而减少由于上面的问题导致主从复制中断。

2.2 slave 在主库找不到binlog文件
 


Got fatal error 1236 from master when reading data from binary log: 

原因
 该错误发生在从库的io进程从主库拉取日志时,发现主库的mysql_bin.index文件中第一个文件不存在。出现此类报错可能是由于你的slave 由于某种原因停止了好长一段是时间,当你重启slave 复制的时候,在主库上找不到相应的binlog ,会报此类错误。或者是由于某些设置主库上的binlog被删除了,导致从库获取不到对应的binglog file。
如何解决
 1 为了避免数据丢失,需要重新搭建slave 。
 2 注意主库binlog的清理策略,选择基于时间过期的删除方式还是基于空间利用率的删除方式。
  不要使用rm -fr 命令删除binlog file,这样不会同步修改mysql_bin.index 记录的binlog 条目。在删除binlog的时候确保主库保留了从库 show slave status 的Relay_Master_Log_File对应的binlog file。

2.3 主库空间问题,
日志被截断



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 start event position from 'mysql-bin.006730' at 290066434, the last event was read from '/u01/my3309/log/mysql-bin.006730 

原因
 该错误和主库的空间问题和sync_binlog配置有关,当主库 sync_binlog=N不等于1且磁盘空间满时,MySQL每写N次binary log,系统才会同步到磁盘,但是由于存储日志的磁盘空间满而导致MySQL 没有将日志完全写入磁盘,binlog event被截断。slave 读取该binlog file时就会报错"binlog truncated in the middle of event;"
 当sync_binlog 的默认值是0,像操作系统刷其他文件的机制一样,MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。
 当sync_binlog =N (N>0) ,MySQL 在每写 N次 二进制日志binary log时,会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。

如何解决
 在从库重新指向到主库下一个可用的binlog file 并且从binlog file初始化的位置开始


stop slave;
 
change master to master_log_file='mysql-bin.006731', master_log_pos=4;

start slave; 

2.4 主库异常断电,从库读取错误的position


120611 20:39:38 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 
 
120611 20:39:38 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236

120611 20:39:38 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000143', position 664526789 

【原因】
 该问题也是和sync_binlog=N不等于1有关,多出现在主机异常crash ,比如磁盘损坏,raid 卡损坏,或者主机异常掉电导致binlog 未及时同步到磁盘。从库读取了主库binlog file中的不存在的binlog position ,一般比binlogfile 的end position 的值还要大。
如何解决
1 在从库重新指向到主库下一个可用的binlog file 并且从binlog file初始化的位置开始


stop slave;
 
change master to master_log_file='mysql-bin.000144', master_log_pos=4;

start slave; 

2 主备库设置 sync_binlog=1,但是设置为1的时候,会带来性能下降。 



版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章