一、问题描述

8月14日收到报警，有一台MySQL主从同步停止了，遂登录slave通过show slave status\G
查看错误原因，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

二、排查过程

slave IO线程报告1236错误应该都不陌生，根据经验来说，以往出现1236的原因大多是因为从库还没有同步master的binlog时，master的binlog就被purge了或者说slave上GTID_PURGED
比主库多等等。

但是从这次的错误来看是主库的binlog并没有写入完整，应该是被截断了，另外比较友好的提示是让我们检查主库的磁盘空间。

那么根据错误提示，我们登录主库查看磁盘空间，果然binlog所在的目录磁盘空间利用率已经达到100%了。查看主库错误日志显示如下：

到这里已经基本可以确定就是我们猜测的原因了，主库空间不足导致binlog被截断。

三、处理过程

3.1 恢复mysql登录

此时通过mysql客户端登录到MySQL已经处于hang住的状态了，于是我找到对应实例所在的binlog目录，手动删除了一些已经应用过的binlog才可以正常登录到MySQL。

查看参数设置：

root@localhost 21:54:  [(none)]> show global variables like '%binlog_error_action%';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| binlog_error_action | IGNORE_ERROR |
+---------------------+--------------+
1 row in set (0.00 sec)

果然是设置了binlog_error_action
为IGNORE_ERROR

参数解释

Controls what happens when the server encounters an error such as not being able to write to, flush or synchronize the binary log, which can cause the master's binary log to become inconsistent and replication slaves to lose synchronization.

This variable defaults to ABORT_SERVER, which makes the server halt logging and shut down whenever it encounters such an error with the binary log. On restart, recovery proceeds as in the case of an unexpected server halt (see Section 17.4.2, “Handling an Unexpected Halt of a Replication Slave”).

When binlog_error_action is set to IGNORE_ERROR, if the server encounters such an error it continues the ongoing transaction, logs the error then halts logging, and continues performing updates. To resume binary logging log_bin must be enabled again, which requires a server restart. This setting provides backward compatibility with older versions of MySQL.

• 大体意思就是参数binlog_error_action
  控制的是当binlog写入/flush或者同步的时候出现问题，mysql server怎么处理，有可能会导致主从不一致的情况。

• 默认情况下为ABORT_SERVER
  ，也就是当binlog出现问题的时候master无法写入并且自杀宕机。重新启动时，恢复过程与服务器意外宕机时一样。

• 如果binlog_error_action
  设置为IGNORE_ERROR
  ，如果binlog出现问题，它将继续进行事务，记录到错误日志，然后关闭binlog，并继续执行更新。要恢复记录binlog，必须再次启用log_bin，也就是说需要重新启动MySQL。

看到了这里，我的内心其实是崩溃的，也就是说，主从很有可能已经不一致了，需要进行一致性校验。

3.2 恢复主从复制

假如需要进行一致性校验，首先必须要恢复主从复制，所以当务之急就是先恢复主从同步。通过位点Relay_Master_Log_File
和Exec_Master_Log_Pos
定位到上一次同步的位点，解析binlog发现到整个文件末尾，有ROLLBACK * added by mysqlbinlog */;
，也就是说binlog还未写完整，MySQL自动添加了ROLLBACK。

那么我把slave的同步位点直接指定到下个文件的开头即可。change master完成以后，主从开始恢复复制，但没一会儿以后就开始大量报1062错误，解析了binlog发现是master进行了INSERT插入，slave上存在对应主键的数据。为了快速解决1062错误，我开始拿出之前写的主从复制错误自动处理的工具，发现由于INSERT是放在一个事务里处理的，工具并没法自动处理，略显尴尬。

这个时候，还是老老实实先用pt-slave-restart先跳过错误再说吧。

 pt-slave-restart --error-numbers=1062 -h localhost -uroot -a -S /data/3307/mysqld.sock

经过一段时间的同步以后，复制已经正常了，那么接下去需要做的就是主从一致性校验，和主从同步修复了

3.3 一致性校验和同步

一致性校验

 pt-table-checksum h=masterip,u=user,p=password,P=3307 --nocheck-replication-filters --replicate=pecona.checksums \
--no-check-binlog-format --recursion-method dsn=h=slaveip,D=test,t=dsns --chunk-time=2 >> /tmp/checksum.log

校验完成以后查看结果，DIFF列果然出现了很多不一致的chunk

主从修复
本以为可以直接指定库进行同步，但是多次尝试都报错无法连接（这里有知道的同学可以指点我一下），直接指定同步表的方式是正常的（可以断定到mysql的连接是OK的）。所以就手动列出需要同步的表，通过shell的方式循环进行单表同步。

四、总结

• 由于该库是大数据的库，数据量比较多，所以整个处理时间比较长，尤其是一致性校验和主从修复的部分

• 个人对于参数binlog_error_action
  之前没有太多的关注，由于是大数据的库设置为IGNORE_ERROR
  也是可以理解的，主要业务都在master上，不能因为无法写入binlog影响业务写入。

• 第三点也是最重要的一点是该事故出现的原因是因为

• 刚到新公司，监控没有通知到位，也没有及时处理空间告警的问题

• 大数据进行了批量写入，瞬间binlog增长过快

• 为了避免以后出现此类问题，监控告警必须做到位，及时处理（顺便再说一下到新公司以后花了很多时间在数据库空间问题处理上。。。）。

• 该库没有开启GTID，位点同步的方式处理起来还是比较麻烦的，并且MySQL版本是5.6还不能在线直接开启GTID，以后得择机升级到5.7开启GTID，同时也能大幅改善主从延迟的问题。

PS：个人开通语雀博客了，本文同步更新语雀，阅读原文 访问 语雀：

https://www.yuque.com/xuchenliang/vv5eyi/about-binlog_error_action