MGR修改max_binlog_cache_size参数导致异常

作者:高鹏(网名八怪),《深入理解MySQL主从原理32讲》系列的作者。
系列链接:https://www.jianshu.com/nb/43148932

一、问题来源

这是一位朋友的问题,因为前期朋友设置max_binlog_cache_size为8m,后面在线进行了修改了本参数,但是结果导致整个3节点的MGR集群除了primary节点其他两个second节点均掉线。大概的日志如下:

二、使用binlog cache的大概流程

这也是我以前写过的一个过程。

  • 开启读写事务。

  • 执行‘DML’语句,在‘DML’语句第一次执行的时候会分配内存空间给binlog cache缓冲区。

  • 执行‘DML’语句期间生成的Event不断写入到binlog cache缓冲区。

  • 如果binlog cache缓冲区已经写满了,则将binlog cache缓冲区的数据写入到binlog cache临时文件,同时清空binlog cache缓冲区,这个临时文件名以ML开头。

  • 事务提交,binlog cache缓冲区和binlog cache临时文件数据全部写入到binary log中进行固化,释放binlog cache缓冲区和binlog cache临时文件。但是注意此时binlog cache缓冲区的内存空间留用供下次事务使用,但是binlog cache临时文件被截断为0,保留文件描述符。其实也就是IO_CACHE结构保留,并且保留IO_CACHE中分配的内存空间和临时文件文件描述符。

  • 断开连接,这个过程会释放IO_CACHE同时释放其持有的binlog cache缓冲区内存以及持有的binlog cache临时文件。

三、max_binlog_cache_size参数的作用

这部分也是我以前记录过的。

max_binlog_cache_size:修改需要使用set global进行修改,定义了binlog cache临时文件的最大容量。如果某个事务的Event总量大于了(max_binlog_cache_size+binlog_cache_size)的大小那么将会报错,如下:

ERROR 1197 (HY000): Multi-statement transaction required more than
'max_binlog_cache_size' bytes of storage; increase this mysqld variable
and try again

我们在函数_my_b_write可以看到如下代码:

if (pos_in_file+info->buffer_length > info->end_of_file) //判断binlog cache临时文件的位置加上本次需要写盘的数据大于info->end_of_file的大小则抛错
  {
    errno=EFBIG;
    set_my_errno(EFBIG);
    return info->error = -1;
  }

其中info->end_of_file的大小正是来自于我们的参数max_binlog_cache_size。

四、分析问题

从second节点的报错来看,是applier线程应用的事务超过了max_binlog_cache_size设置的大小,但是朋友已经修改了其大小,并且主库并没有报这个错误。
我们知道MGR applier线程从启动MGR的那一刻开始就不会停止,类似的master-slave的sql线程也是一样,我们修改参数是通过set global修改的参数,但是实际上在对于MGR的applier线程并不会生效。
但是对于主库来讲,我们修改参数后只要重启应用重新连接那么参数就生效了,这个时候实际上primary session的max_binlog_cache_size和second applier的max_binlog_cache_size并不一致,一旦有主库做一个稍大的事务,如果这个事务的binlog大于以前设置的值,主库虽然能成功,但是备节点就会由于applier线程的max_binlog_cache_size过小而导致备节点脱离整个集群。
对于这一点我们可以通过debug MySQL的sql线程进行验证。

五、验证

这里我们使用master-slave来进行验证,我们对sql线程进行debug。如下,

  • 当前配置

  • sql线程

  • 修改参数

  • 主库执行一个事务,从库执行
    我们可以查看sql线程binlog cache的IO CACHE的信息如下:

可以看到这个值还是老值。

  • 重启后sql线程后,主库再做一个事务观察

很明显我们刚才修改的值重启sql线程后才生效。
因此故障原因得到证明。

Enjoy MySQL :)

全文完。

叶老师的「MySQL核心优化」大课已升级到MySQL 8.0,扫码开启MySQL 8.0修行之旅吧

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值