MySQL 1864 主從報錯根因與秒級修復：slave_pending_jobs_size_max 閾值調大實戰

錯誤現象

Last_SQL_Errno: 1864
Last_SQL_Error: Cannot schedule event Update_rows, relay-log ... position ... to Worker thread because its size 8200 exceeds 1024 of slave_pending_jobs_size_max.

從庫多線程複制（slave_parallel_workers > 0）時，佇列中待應用事件超過 slave_pending_jobs_size_max（預設 16MB）導致 SQL 線程停止。

秒級修復（動態生效，無需重啟）

STOP SLAVE;
SET GLOBAL slave_pending_jobs_size_max = 20000000; -- 20MB，視業務調大
START SLAVE;

原理與調優建議

• 該參數控制 **每個 worker 佇列** 的最大內存佔用，單位字節。
• 主庫大事務（大批量 UPDATE/DELETE）產生的 Binlog 事件體積大，易觸發閾值。
• 必須大於主庫 max_allowed_packet，否則主庫能寫入的事件從庫卻無法接收。
• 內存充裕時可設 64MB~256MB，減少阻塞；監控 SHOW SLAVE STATUS\G 中 Slave_pending_jobs_size_max 實際使用情況。

故障復現步驟（驗證修復）

-- 從庫設置極小閾值
SET GLOBAL slave_parallel_workers=4;
SET GLOBAL slave_pending_jobs_size_max=1024;

-- 主庫製造大事務
SET GLOBAL max_binlog_cache_size=8388608000000;
BEGIN;
UPDATE erp_mkpf SET usnam='測試1864錯誤'; -- 7 萬行
COMMIT;

-- 觀察從庫報錯 1864，調大閾值後自動恢復

最佳實踐清單

1. 監控告警：Last_SQL_Errno=1864 立即通知。
2. 配置管理：將 slave_pending_jobs_size_max 納入 Puppet/Ansible 基線，建議 ≥ 64MB。
3. 主庫大事務拆分：避免單次修改超百萬行，分批提交。
4. 升級 MySQL 5.7+：引入 slave_pending_jobs_size_max 自動擴容機制，減少人工干預。