現象：Slave 狀態正常卻數據停滯

某日發現 Slave Seconds_Behind_Master 持續增長，但 Slave_IO_Running、Slave_SQL_Running 均為 Yes。重啟後延遲歸零，但隔天再次發生。排查 Master 狀態正常，Binlog 位點持續推進。

深入 Binlog 發現真兇

用 mysqlbinlog --base64-output=decode-rows -v 解析 Relay Log，發現單次 DELETE 操作產生 70 萬行變更，導致單個 Binlog Event 超過 max_allowed_packet 限制。Slave I/O 線程讀取時觸發錯誤：

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:
'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master'

根因分析

• MySQL 協議以「包」為單位傳輸，max_allowed_packet 控制單包大小上限（預設 4MB/64MB 視版本）。
• 大事務（大量刪除/更新、巨型 BLOB/TEXT）會產生超大 Event，超過限制導致 I/O 線程中斷，SQL 線程因無新 Relay Log 而空轉，表面狀態仍為 Yes。
• 行基礎復制下，單行變更即生成一個 Event，大批量操作極易超標。

解決方案

緊急修復（線上無需重啟）

STOP SLAVE;
SET GLOBAL max_allowed_packet = 1073741824; -- 1GB，視業務調整
START SLAVE;

同步恢復後，手動清理 Slave 殘留數據。

長期預防

1. 拆分大事務：分批刪除/更新，每批 5000~10000 行，間隔 SLEEP(0.1)。
2. 調大雙端參數：Master/Slave 同步設定 max_allowed_packet=1G，slave_max_allowed_packet（5.6+）同步調大。
3. 監控告警：監控 Slave_IO_Running、Last_IO_Error、Binlog 事件大小分佈。

知識延伸：max_allowed_packet 影響面

• 客戶端發送超大 SQL 會報「Lost connection to MySQL server during query」。
• mysqldump、mysqlbinlog 等工具亦受限，需加 --max-allowed-packet 參數。
• 5.7.8+ 引入 slave_max_allowed_packet 專門控制 Slave 接收上限，預設 1GB，建議與 Master 保持一致。

總結

「Slave 狀態全 Yes 卻不同步」是典型的 max_allowed_packet 受限信號。大事務拆分與參數同步調大是標準解法，切勿盲目跳過事務（SQL_SLAVE_SKIP_COUNTER）導致數據不一致。