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再次执行没有出现上述错误。