一个参数引起的MySQL从库宕机血案

Part1:max_binlog_cache_size

max_binlog_cache_size 表示的是binlog 能够使用的最大cache 内存大小

当我们执行多语句事务的时候 所有session的使用的内存超过max_binlog_cache_size的值时

就会报错：“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”

Part2:为什么它能引起宕机

Warning:警告1

max_binlog_cache_size在主从设置不一致的情况下，主库参数值大于从库参数值，在主库进行大事务操作时，主库顺利进行，从库因max_binlog_cache_size值低于该事物所需，从库会抛出“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”错误号为1197。

Warning:警告2

max_binlog_cache_size在主从参数设置一样的情况下，主库执行大事务操作，如主库提示需提高该参数以顺利执行SQL，但DBA只调整了主库的max_binlog_cache_size而忘记调整从库的max_binlog_cache_size，则同样从库会爆出1197错误，导致主从不同步。

Part3:该设置值为多少

具体值设置为多少，不能纸上谈兵，还需要看公司的具体业务以及硬件内存大小，这里除了不设置该值使用默认值（默认值很大）以外，个人推荐值为4G，基本已经足够应付大部分场合，但无论是否指定该值，在对大表进行操作时，都需注意上述的警告内容，避免该值设置不合理引起从库无法执行报1197的问题。具体命令如下：

set global max_binlog_cache_size =4294967296;

——总结——

该值为动态参数，可以随时利用上述命令进行调整，所以别忘记将该参数加入到my.cnf中以防止重启数据库后失效。由于笔者的水平有限，编写时间也很仓促，文中难免会出现一些错误或者不准确的地方，不妥之处恳请读者批评指正。