ERROR 1197 (HY000): Multi-statement transaction required more than ‘max_binlog_cache_size‘ bytes of

max_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

日常运维中的坑真是防不胜防，不一小心就遇到别人给你挖的坑。其中把max_binlog_cache_size设置的只有2G，而MySQL早已将此参数的默认值调整的很大了（18446744073709547520），实在没想通为何有人会如此修改。

故障描述一：

突然收到告警，MySQL其中一个从库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事务。

  故障处理二
处理过程倒是非常简单，该参数可以动态修改，因此直接调整主库及从库的值。因为也确实没必要还原为默认值，毕竟达不到那么大，因此，先将其设置为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等参数有关，因此设置时要根据实际情况调整，千万不可无脑的跟风设置

slave

show variables like '%binlog_%size%';

 show status like 'binlog_%';

Binlog_cache_disk_use表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数

Binlog_cache_use  表示 用binlog_cache_size缓存的次数

当对应的Binlog_cache_disk_use 值比较大的时候 我们可以考虑适当的调高 binlog_cache_size 对应的值;

运行情况Binlog_cache_use 表示binlog_cache内存方式被用上了多少次，Binlog_cache_disk_use表示binlog_cache临时文件方式被用上了多少次。

Binlog_cache_disk_use现在等于0，表示内存cache是够用的，从来不需要使用到临时文件。如果没有long_transaction的话，觉得64M是偏大的。

注意点：

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

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

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

b.设置太大的话，会比较消耗内存资源;设置太小又会使用到临时文件即disk

 

master

show status like 'binlog_%';

主备设置不一致导致主库写binlog成功，备库在恢复relog的时候同样记录binlog，但是主备cache大小设置不同，所以导致了上边的问题。

主备参数的一致性很重要！！！！

修复

root@(none) 10:08:49>stop slave;
Query OK, 0 rows affected, 1 warning (0.02 sec)
root@(none) 10:08:32>set global max_binlog_cache_size= 42949672960;         
Query OK, 0 rows affected (0.00 sec)
root@(none) 10:08:49>start slave;
Query OK, 0 rows affected, 1 warning (0.02 sec)

max_binlog_cache_size

如果事务需要内存超过此字节数，服务器生成如下错误ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage;max_binlog_cache_size最低值是4096，最大可能值为16EB（艾字节）。推荐的最大值为4GB ;因为目前的MySQL当二进制日志位置大于4GB时并不生效。

Note:

Prior to MySQL 5.6.7, 64-bit Windows platforms truncated the stored value for this variable to 4G, even when it was set to a greater value (Bug #13961678).

在MySQL 5.6 ，会话对于max_binlog_cache_size的感知依赖于binlog_cache_size系统变量;换句话说，改变其值只会影响后续新建会话。

max_binlog_size

如果写二进制日志导致当前日志文件大小超过了这个变量的值时，服务器旋转二进制日志（关闭当前的文件，并打开下一个） 。的最小值为4096字节。最大值和默认值是1GB 。

事务是以块为单位写入二进制日志的，因此它不会被拆分在几个二进制日志。如果你有大的交易，你可能会看到比max_binlog_size较大的二进制日志文件。

如果max_relay_log_size为0，max_binlog_size的值会被应用到中继日志。

max_binlog_stmt_cache_size

如果一个事务中的非事务性的语句需要大于这个数量的更多的内存，服务器会产生报错。最低值是4096 ，在32位平台最大和默认值是4GB。在64位平台最大和默认值是416EB（艾字节）。

Note

Prior to MySQL 5.6.7, 64-bit Windows platforms truncated the stored value for this variable to 4G, even when it was set to a greater value (Bug #13961678).

max_binlog_cache_size针对事务语句，max_binlog_stmt_cache_size针对非事务语句，当我们发现Binlog_cache_disk_use或者Binlog_stmt_cache_disk_use比较大时就需要考虑增大cache的大小

事务性语句&非事务性语句

在事务性语句执行过程中，服务器将会进行额外的处理，在服务器执行时多个事务是并行执行的，为了把他们的记录在一起，需要引入事务缓存的概念。在事务完成被提交的时候一同刷新到二进制日志。 对于非事务性语句的处理。遵循以下3条规则：

1. 如果非事务性语句被标记为事务性，那么将被写入事务缓冲。
2. 如果没有标记为事务性语句，而且事务缓存中没有，那么直接写入二进制日志。
3. 如果没有标记为事务性语句，但是事务缓存中有，那么写入事务缓冲。

注意如果在一个事务中有非事务性语句，那么将会利用规则2，优先将该影响非事务表语句直接写入二进制日志。

如果一切正常，当事务中执行事务语句（DML）的时候，所以这些语句形成的event都会被记录到缓存里面，等到commit事务以后，这个缓存的数据会立即被刷入磁盘上的binlog文件里面，之后通过slave请求发送到slave，在slave重复执行。

顺便提一下，mysql的binlog里面的事务都是相互独立按顺序排列的。

现在开始假设意外的发生。

正常意外一：事务执行中rollback了。

如果在一个事务中，所有执行的语句都是在innodb表上执行（对于多个事务引擎如tokudb等并用尚未测试），直接执行rollback，会导致mysql直接清除缓存，不会写入任何event记录到binlog。

正常意外二：事务执行中使用了非事务表（myisam），然后rollback了。

在一个事务中，即有事务表，也有非事务表，如果正常执行，则没有任何问题，当如果在非事务表上的修改执行了，复制设置为statement的时候，binlog会把所有执行的event全部记录下来写入日志，包括事务与非事务语句，然后在最后面加上rollback。如果复制格式设置为row，那么所有事务表相关的数据都会被清理掉，而非事务表上的数据会被标记为已提交事务写入binlog。

正常意外三：事务执行顺序如下：事务语句1－》非事务语句2－》save point －》事务语句3 －》 rollback to savepoint －》 事务语句4 －》提交

对于上面的情况，statement情况下，所有执行的语句包括savepoint与rollback都会按顺序被记录到binlog。row情况下，非事务语句与事务语句是分别记录到binlog中，非事务执行event会全部被记录，事务执行event会连带savepoint与rollback都记录下来。

正常意外四：事务执行顺序如下：事务语句1-》savepoint－》非事务语句2-》事务语句3-》rollback to savepoint－》事务语句4 －》 commit

同上。

异常意外一：master正常提交了，但是在slave执行失败了。

master执行完成，提交之后，slave接收到relay然后执行，执行期间由于意外原因失败了。这个时候，statement格式下，mysql会重新回到事务begin处重新执行，如果再次失败的话就会报错。row模式下情况类似，区别在于，如果是包含非事务表执行的事务，非事务表上的event不会被重新执行。

总结：Max_binlog_cache_size

Max_binlog_cache_size: 默认值是18446744073709547520，这个值很大，够我们使用的了。此参数和binlog_cache_size相对应，是所代表的是binlog能够使用的最大cache内存大小。

当我们执行多语句事务的时候，max_binlog_cache_size如果不够大的话，系统可能会报出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的错误。

Max_binlog_size: 1073741824=1G  binlog的最大值，一般设置为512M或1G,一般不能超过1G;

该大小并不能非常严格控制Binlog大小，尤其是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候，系统为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进入当前日志，直到该事务结束。

这一点和Oracle的Redo日志有点不一样，因为Oracle的Redo日志所记录的是数据文件的物理位置的变化，而且里面同时记录了Redo和Undo相关的信息，所以同一个事务是否在一个日志中对Oracle来说并不关键。

而MySQL在Binlog中所记录的是数据库逻辑变化信息，MySQL称之为Event，实际上就是带来数据库变化的DML之类的Query语句。

sync_binlog：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。

而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看，

对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。