MySQL 参数“max_binlog_cache_size”太小致使SQL失败

今天，开发同事在发布一个SQL的时候失败后，找到我说报告了以下错误：

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

意思是多语句食物请求更大的max_binlog_cache_size，须要增长此参数值后再次尝试

这个时候接到报警说主从不一样步，SQL线程挂掉了

登录系统后查看主从状态后，果真和同事的这个SQL有关系

询问了一下同事的操做的SQL：

首先复制一张表，方式是：create table  table_B like table_A,而后使用insert into  table_B select * from table_A 

总共是四张表这样的而后只执行成功了一张表，后面就报了如上的错误

注意：使用like方式建立的表好处就是能够得到一张和源表同样的表结构索引和存储引擎等

           缺点就是建立的是一张空表，须要再次将数据插入到新表中

但这样的方式为什会形成一个从库复制中断呢？而另外的从库是正常的

缘由是这样的：复制中断的这个从库的角色是备份库，开启了binlog 且binlog格式是ROW，其余从库未开启binlog

mysql> show variables like 'binlog_format';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW   |

+---------------+-------+

row 格式的binlog的特色：在 row 模式下，全部的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。因此会形成binlog cache由于太小而中断

知道了错误缘由就好解决问题了：

首先增长这个参数的大小：set global max_binlog_cache_size=XXXXXXX  （这样重启系统后会失效）

而后启动复制进程 start slave； 

查看复制状态 show slave status\G

主从复制恢复正常

同事的SQL再次执行没有出现上述错误。