MySQL 主從同步故障速查：Slave_IO_Running=No / Slave_SQL_Running=No 兩大核心故障分類與標準化修復 SOP

故障分類總覽

方案一：強制重新同步 (適用於 I/O 故障、大量 SQL 錯誤、結構漂移)

# 1. Slave 停止複寫
STOP SLAVE;

# 2. Master 獲取最新位點
SHOW MASTER STATUS;
# 記錄 File, Position (如 mysql-bin.000020, 135617781)

# 3. Slave 重新指向
CHANGE MASTER TO
  MASTER_HOST='master_ip',
  MASTER_USER='repl',
  MASTER_PASSWORD='pass',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mysql-bin.000020',
  MASTER_LOG_POS=135617781;

# 4. 啟動複寫
START SLAVE;

# 5. 驗證
SHOW SLAVE STATUS\G
# Slave_IO_Running: Yes, Slave_SQL_Running: Yes, Seconds_Behind_Master: 0

風險：若 Master Binlog 已輪轉 (expire_logs_days)，指定位點可能不存在 → 需重新備份建立 Slave。
優點：徹底解決結構漂移、累積錯誤，狀態乾淨。

方案二：跳過錯誤計數器 (適用於單一/少量主鍵衝突 1062、非關鍵資料)

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;  -- 跳過 1 個事件組
START SLAVE;
# 觀察幾秒後再次 SHOW SLAVE STATUS
# 若仍報錯，重複執行 (記錄總跳過數，超過 5 次建議改方案一)

原理：跳過當前 Relay Log 中導致錯誤的事件組 (一個事務可能包含多個事件)。
嚴重警告：跳過導致主從資料不一致，必須事後 pt-table-checksum 校驗並 pt-table-sync 修復。

方案三：Relay Log 損壞重建 (SQL 線程報 "Could not parse relay log")

# 1. 獲取 SQL 線程已執行到的 Master 位點
SHOW SLAVE STATUS\G
# 記錄 Relay_Master_Log_File, Exec_Master_Log_Pos

# 2. 重新 CHANGE MASTER TO 指向該位點 (系統會丟棄舊 Relay Log 重新下載)
STOP SLAVE;
CHANGE MASTER TO
  MASTER_LOG_FILE='Relay_Master_Log_File值',
  MASTER_LOG_POS=Exec_Master_Log_Pos值;
START SLAVE;

進階修復工具：Percona Toolkit 標準化流程

# 1. 一致性校驗 (非阻塞、線上可執行)
pt-table-checksum --recurse=1 --databases=db1,db2 \
  h=master,u=repl,p=pass P=3306 \
  h=slave,u=repl,p=pass P=3306

# 2. 產生差異報告
pt-table-checksum --replicate=percona.checksums --report

# 3. 同步修復 (生成 REPLACE/INSERT/DELETE SQL，可先 --print 再 --execute)
pt-table-sync --sync-to-master h=slave,u=repl,p=pass --databases=db1 --print
pt-table-sync --sync-to-master h=slave,u=repl,p=pass --databases=db1 --execute

預防性架構建議

1. GTID + 半同步：rpl_semi_sync_master_enabled=1，Master 確認至少一 Slave 收到 Binlog 再 Commit，極大降低資料遺失。
2. read_only=1 + super_read_only=1：防止 Slave 誤寫入導致衝突。
3. skip_slave_start=1：啟動不自動複寫，給人工檢查窗口。
4. relay_log_recovery=1：Slave 重啟自動修復損壞 Relay Log。
5. 定期校驗：每日/每週 pt-table-checksum，發現不一致立即修復，避免雪球效應。
6. 監控告警：Seconds_Behind_Master > 300、Slave_IO_Running=No、Slave_SQL_Running=No 接入 Prometheus/Alertmanager → PagerDuty/企業微信/釘釘。

主從故障 90% 可預防。建立「部署標準化 → 監控全覆蓋 → 校驗常態化 → 演練機制化」四位一體體系，故障處理從「救火」轉為「按預案執行」。