mysql參數max_binlog_cache_size設置不當引起的血案

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

一、 故障描述

收到告警，從庫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等參數有關，所以設置時要根據實際狀況調整，千萬不可無腦的跟風設置