深入MySQL--深入解析binlog_error_action参数
一、问题描述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)
**** Hidden Message ***** ooooooooooooooooooo
页:
[1]