本文分享了一個資料庫參數錯誤配置導緻複制中斷的問題，以及對參數配置的建議。
作者：秦福朗
愛可生 DBA 團隊成員，負責項目日常問題處理及公司平台問題排查。熱愛網際網路，會攝影、懂廚藝，不會廚藝的 DBA 不是好司機，didi~
本文來源：原創投稿
- 愛可生開源社群出品，原創内容未經授權不得随意使用，轉載請聯系小編并注明來源。
前言
在日常的運維工作中，偶爾會遇到一些意想不到的線上問題，多數因為設定不當導緻故障。前段時間，DMP 資料庫運維平台 報錯主從複制 SQL 線程斷開，就是因為一個參數設定異常導緻的。本文分享一下當時的情況。
故障描述
DMP 收到告警 MySQL 從庫的 SQL 線程停止了工作，去從庫背景執行 show slave status\G：
可以看到 SQL 線程确實停止工作了，根據提示檢視 ： select * from performance_schema.replication_applier_status_by_worker;
報錯為：
Worker 1 failed executing transaction '44bbb836-19b4-11eb-aae3-98f2b315b1a5:216718523' at master log mysqlbin.000492, end_log_pos 533198991; Could not execute Delete_rows event on table cmbc_msearch.search_hotword_item; 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 mysqlbin.000492, end_log_pos 533198991
我們可以看到報錯資訊比較明顯，是 max_binlog_cache_size 參數設定出現了問題。
檢視主從的 max_binlog_cache_size 的大小，主庫為 10G，從庫為 10M。
原理描述
官方文檔了解 max_binlog_cache_size 參數：
binlog 是 MySQL 用來記錄所有修改資料庫資料的操作的二進制日志。在主從複制中，主庫會把自己的 binlog 傳輸給從庫，供從庫執行相同的操作，以保證資料的一緻性。而 max_binlog_cache_size 則是 MySQL 設定的最大 binlog 緩存大小。當事務過于複雜，多語句事務執行，需要寫入 binlog 的資料量超過了這個值時，就會出現上述錯誤。
此時還要注意另一個參數 binlog_cache_size，這個參數給每個用戶端配置設定用來存儲二進制日志的緩存，而 max_binlog_cache_size 則表示所有用戶端緩存使用的最大值。
問題解決
從庫為 10M 的曆史原因也追溯不到，但主從設定參數不一緻，且一個很大一個很小，是不合理的，也是導緻本文中報錯的主要因素。
max_binlog_cache_size 參數是可以通過線上動态修改的，現場解決方案，将從庫的該值調大：
mysql> set global max_binlog_cache_size=10240000000;
Query OK, 0 rows affected (0.00 sec)
然後再開啟主從複制，就正常了。
總結
在運維過程中，合理配置和及時調整參數是確定系統穩定性和性能優化的重要環節，在修改一些參數的時候要充分了解相關知識概念，并且要掌握複制叢集中相同參數的配置情況，確定合理合規修改，減少生産故障。
更多技術文章，請通路：https://opensource.actionsky.com/
關于 SQLE
愛可生開源社群的 SQLE 是一款面向資料庫使用者和管理者，支援多場景稽核，支援标準化上線流程，原生支援 MySQL 稽核且資料庫類型可擴充的 SQL 稽核工具。