mysql参数max_binlog_cache_size设置不当引起的血案

平常运维中的坑真是防不胜防，不一当心就遇到别人给你挖的坑。最近又遇到经验不足的DBA不知道从哪拷贝的配置文件（听说是当时参加某培训机构视频培训是资料里的模板，真的是误人子弟呀），其中把max_binlog_cache_size设置的只有2G，而MySQL早已将此参数的默认值调整的很大了（18446744073709547520），实在没想通为什么有人会如此修改。

一、 故障描述

收到告警，从库SQL线程中止，查看日志，其中的错误内容以下：

[ERROR] Slave SQL for channel '': Worker 1 failed executing transaction '370e03bf-aa09-11e9-9bd3-e4434b2aa008:248804226' at master log , end_log_pos 2149953254; Could not execute Update_rows event on table dbname.tbname; Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again, Error_code: 1197; handler error HA_ERR_RBR_LOGGING_FAILED; the event's master log FIRST, end_log_pos 2149953254, Error_code: 1197

提示的很明显，max_binlog_cache_size参数的值小了。

引起此问题的主库执行了几个很大的事务，且从库开启了并行复制，所以须要更大的max_binlog_cache_size来处理innodb事务。

2 、故障处理

处理过程却是很是简单，该参数能够动态修改，所以直接调整主库及从库的值。由于也确实不必还原为默认值，毕竟达不到那么大，所以，先将其设置为40GB

mysql> set  global max_binlog_cache_size=40*1024*1024*1024;
Query OK, 0 rows affected (0.00 sec)

注意：

1)  主库及从库均进行调整

2)  动态修改后配置文件也须要修改，以避免重启后有还原回去了

3)  max_binlog_cache_size参数与binlog_cache_size以及Binlog_cache_use等参数有关，所以设置时要根据实际状况调整，千万不可无脑的跟风设置