MySQL 主從複制 Error 1236 故障診斷與修復實戰

MySQL 主從複制遇到 Error 1236 通常意味著二進制日誌損壞或位置異常。本文記錄一次 Master 端 Binlog 損壞的完整排查與修復過程，提供可落地的操作指南。

一、錯誤現象

Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:
Client requested master to start replication from impossible position
the first event 'mysql-bin.003583' at 45997491,
the last event read from './mysql-bin.003583' at 4,
the last byte read from './mysql-bin.003583' at 4

關鍵信號：impossible position、first event ... at 45997491 與 last event ... at 4 位置倒掛，表明 Binlog 文件內部結構已損壞。

二、現場確認

1. Slave 狀態檢查

mysql> SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.003583
Read_Master_Log_Pos: 45997491
Relay_Master_Log_File: mysql-bin.003361
Slave_IO_Running: No
Slave_SQL_Running: Yes

Slave 試圖從 mysql-bin.003583 的 45997491 位置讀取，但該文件實際大小僅 4 字節，明顯不匹配。

2. 定位損壞源頭

• Slave 端 /var/lib/mysql/mysql-bin.003583 不存在 → 排除 Slave Binlog 損壞。
• Master 端執行 mysqlbinlog /var/lib/mysql/mysql-bin.003583 報錯 Error in Log_event::read_log_event() → 確認為 Master Binlog 損壞。

三、修復策略對比

四、實施「跳過損壞 Binlog」方案步驟

1. 停止複制： STOP SLAVE;
2. 指向下一個完整 Binlog：

   CHANGE MASTER TO
     MASTER_LOG_FILE = 'mysql-bin.003584',
     MASTER_LOG_POS = 4;  -- 或 0，均指向文件開頭

3. 啟動複制： START SLAVE;
4. 驗證狀態： SHOW SLAVE STATUS\G 確認 Slave_IO_Running: Yes。
5. 數據一致性修補： 使用 pt-table-sync（Percona Toolkit）對核心業務表做單向同步：

   pt-table-sync --execute h=MasterIP,u=sync_user,p=xxx,h=SlaveIP,u=sync_user,p=xxx --databases db_name --tables core_table

五、事後預防

• 啟用 sync_binlog=1 確保每次事務提交刷盤，減少崩潰導致的 Binlog 截斷。
• 配置 binlog_expire_logs_seconds 定期清理舊日誌，避免磁盤滿導致寫入中斷。
• 部署監控告警：Seconds_Behind_Master、Slave_IO_Running 異常即時通知。
• 定期演練 pt-table-checksum + pt-table-sync 全量一致性校驗。

Master Binlog 損壞屬於較罕見但影響面極大的故障。掌握「跳過損壞段 + 關鍵表同步」的組合拳，能在最小化業務影響的前提下快速恢復複制鏈路。