日常運維中的坑真是防不勝防，不一小心就遇到別人給你挖的坑。最近又遇到經驗不足的DBA不知道從哪拷貝的配置文件（據說是當時參加某培訓機構視頻培訓是資料里的模板，真的是誤人子弟呀），其中把max_binlog_cache_size設置的只有2G，而MySQL早已將此參數的預設值調整的很大了（18446744073709547520），實在沒想通為何有人會如此修改。

1、 故障描述

收到告警，從庫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事務。

2 、故障處理

處理過程倒是非常簡單，該參數可以動態修改，因此直接調整主庫及從庫的值。因為也確實沒必要還原為預設值，畢竟達不到那麼大，因此，先將其設置為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等參數有關，因此設置時要根據實際情況調整，千萬不可無腦的跟風設置