MySQL 5.1 主從同步 Relay Log 讀取失敗錯誤排查與修復實戰

MySQL 5.1 主從同步 Relay Log 讀取失敗錯誤排查與修復

MySQL 5.1 複製機制相對脆弱，Relay log read failure: Could not parse relay log event entry 是典型故障。本文通過實戰案例，詳解錯誤成因判斷、基於 Exec_Master_Log_Pos 的精準重同步修復流程，並給出版本升級建議。

錯誤現場還原

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.118
Master_Log_File: mysql-bin.005121
Read_Master_Log_Pos: 64337286
Relay_Log_File: relay-bin.003995
Relay_Log_Pos: 18446697137031827760  -- 異常巨大，疑似損壞
Relay_Master_Log_File: mysql-bin.005121
Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1594
Last_Error: Relay log read failure: Could not parse relay log event entry...
Exec_Master_Log_Pos: 4
Seconds_Behind_Master: NULL

關鍵判斷：Slave_SQL_Running: No + Relay_Log_Pos 異常 → **Relay Log 損壞** (而非 Master Binlog 損壞)。

修復核心邏輯：定位同步點 → 重新同步

利用 Relay_Master_Log_File (主庫 Binlog 文件) 和 Exec_Master_Log_Pos (已執行位置) 精準定位：

-- 1. 停止複製線程
STOP SLAVE;

-- 2. 重新指定主庫 Binlog 位置 (以 Relay_Master_Log_File 為準)
CHANGE MASTER TO
  MASTER_LOG_FILE='mysql-bin.005121',
  MASTER_LOG_POS=4;

-- 3. 啟動複製
START SLAVE;

-- 4. 驗證
SHOW SLAVE STATUS\G;

原理：丟棄損壞的本地 Relay Log，從主庫對應位置重新拉取 Binlog 重建 Relay Log，實現「無損重同步」。

完整排查與修復流程圖

1. 確認錯誤類型：Last_Errno=1594 + Relay log read failure → Relay Log 損壞概率 >90%。
2. 檢查主庫 Binlog 完整性 (可選)：

   mysqlbinlog /path/to/mysql-bin.005121 | head -20

   若主庫 Binlog 也損壞，需從備份恢復主庫或重搭主從。
3. 記錄關鍵坐標：Relay_Master_Log_File、Exec_Master_Log_Pos。
4. 執行 CHANGE MASTER TO 重同步 (見上)。
5. 觀察 Seconds_Behind_Master 歸零 確認追上主庫。

進階：Relay Log 過大導致磁盤爆滿的清理流程

若因網路抖動導致 Relay Log 堆積，需協同主從清理：

-- 主庫：鎖表刷新獲取最新坐標
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;  -- 記錄 File, Position
UNLOCK TABLES;

-- 從庫：停止 SQL 線程
STOP SLAVE SQL_THREAD;
-- 等待 IO 線程追上 (Relay_Log_Space 穩定)
-- 更新從庫同步坐標
CHANGE MASTER TO MASTER_LOG_FILE='新文件', MASTER_LOG_POS=新位置;
START SLAVE SQL_THREAD;

版本升級強烈建議

• MySQL 5.1.36 及以下存在嚴重複製 Bug (如 Relay_Log_Pos 溢出、GTID 缺失、Binlog 校驗缺陷)。
• 最低升級至 5.1.40 或 5.1.37sp1，修復核心複製穩定性問題。
• 最佳路徑：遷移至 MySQL 5.7/8.0 或 MariaDB 10.6+，獲得 GTID、並行複製、崩潰安全複製等現代特性。

日常運維預防清單

1. 監控 Slave_IO_Running/Slave_SQL_Running 雙 YES。
2. 監控 Seconds_Behind_Master 非 NULL 且 < 300 秒。
3. 定期 mysqlbinlog 校驗主從 Binlog 完整性。
4. 啟用 relay_log_recovery=ON (5.6+) 啟動時自動修復 Relay Log。
5. 磁盤預留 20% 以上空間，防止 Relay Log 寫滿損壞。

總結

MySQL 5.1 Relay Log 損壞修復核心是「拋棄本地損壞 Relay Log，從主庫權威 Binlog 重拉」。掌握 Relay_Master_Log_File + Exec_Master_Log_Pos 定位法，配合版本升級與監控體系，可將複製故障恢復時間從小時級壓縮至分鐘級。