一、问题来源
这是一位朋友的问题，因为前期朋友设置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 :)
全文完。
</div>
