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再次執行沒有出現上述錯誤。