日常運維中的坑真是防不勝防，不一小心就遇到別人給你挖的坑。最近又遇到經驗不足的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等參數有關，因此設置時要根據實際情況調整，千萬不可無腦的跟風設置