Error 1236 通常意味著 Binlog 損壞或位點不存在。本文記錄 Master Binlog 損壞時的兩種修復路徑：完全重建 vs 跳過壞檔 + 校驗修補。

錯誤現場

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

Slave 尋找 mysql-bin.003583 位點 45997491，但 Master 該檔案已損壞 (僅 4 bytes 可讀)。

策略一：全部 Slave 重建 (最安全、零資料遺失)

1. Master 執行 FLUSH TABLES WITH READ LOCK → mysqldump --single-transaction --master-data=2 --all-databases > full.sql → UNLOCK TABLES。
2. 傳輸 full.sql 至各 Slave，SOURCE full.sql 還原。
3. CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=157; (從 dump 註釋取得)。
4. START SLAVE 驗證 Seconds_Behind_Master=0。

策略二：跳過壞 Binlog + pt-table-sync 修補 (快速恢復服務、接受短暫不一致)

-- 在每個 Slave 上執行
STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.003584', MASTER_LOG_POS=4;
START SLAVE;
-- 觀察 SHOW SLAVE STATUS\G 確認 Slave_IO_Running=Yes, Slave_SQL_Running=Yes

隨後對核心業務表執行一致性校驗與修補：

# 安裝 Percona Toolkit
apt-get install percona-toolkit

# 檢查不一致
pt-table-checksum h=master_ip,u=repl,p=pass --databases=core_db --tables=core_tbl

# 修補 (僅同步差異)
pt-table-sync --execute h=master_ip,u=repl,p=pass h=slave_ip,u=repl,p=pass --databases=core_db --tables=core_tbl

Root Cause 分析與預防

• 磁碟故障 / 檔案系統錯誤 → RAID 監控、SMART 巡檢、定期 mysqlbinlog 校驗。
• Crash 寫入中斷 → sync_binlog=1、innodb_flush_log_at_trx_commit=1 雙 1 配置。
• Binlog 過期自動清理 → expire_logs_days 設足夠保留天數，配合備份策略。

決策建議

場景	推薦策略
核心金融/交易庫，容忍零不一致	策略一：全量重建
非核心/快取/日誌庫，需分鐘級恢復	策略二：跳過 + pt-table-sync
多 Slave 同時報 1236	確認 Master Binlog 損壞，必須在 Master 層面解決

建立「Binlog 完整性巡檢 + 定期全備 + pt-toolkit 就緒」三層防線，從容應對 1236。