【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 大小

【原因】

   此类报错和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“。

【如何解决】

 需要确保主备配置一样，然后尝试调大该参数的值。

2.2 slave 在主库找不到binlog文件 

 该错误发生在从库的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 主库空间问题，日志被截断

 该错误和主库的空间问题和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初始化的位置开始

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

 该问题也是和sync_binlog=n不等于1有关，多出现在主机异常crash ，比如磁盘损坏，raid 卡损坏，或者主机异常掉电导致binlog 未及时同步到磁盘。从库读取了主库binlog file中的不存在的binlog position ，一般比binlogfile 的end position 的值还要大。

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

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