MySQL 主從不同步兩大解決方案：SQL_SLAVE_SKIP_COUNTER 跳過錯誤 vs 重做從庫完全同步

主從同步中斷診斷與兩種修復策略選型指南

現象：Slave_IO_Running: Yes、Slave_SQL_Running: No。SQL 線程因重放錯誤 (重複鍵、外鍵失敗、字元集、版本不兼容) 停止。修復策略取決於 資料一致性要求 與 主從差異程度。

方案一：跳過錯誤繼續同步 (適用：差異小、可容忍少量不一致)

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;  -- 跳過 1 個事件，視錯誤數量調整
START SLAVE;
SHOW SLAVE STATUS\G
-- 確認 Slave_SQL_Running: Yes

• 原理：跳過導致錯誤的 Binlog 事件 (通常是單條 DML)，直接執行後續事件。
• 風險：跳過的事件在從庫**不執行**，導致主從資料差異 (缺少該行插入/更新/刪除)。
• 適用：非核心表、統計表、日誌表、業務允許最終一致且可事後補償。
• 驗證：事後用 pt-table-checksum 校驗差異，必要時 pt-table-sync 修復。

方案二：重做從庫完全同步 (適用：差異大、強一致性要求、核心業務)

1. 主庫鎖表備份：
   FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS; 記錄 File、Position (或 GTID 模式記錄 Executed_Gtid_Set)。
   mysqldump --single-transaction --master-data=2 --all-databases > master_full.sql
UNLOCK TABLES;
2. 傳輸備份檔：scp master_full.sql slave_host:/tmp/
3. 從庫停止同步並導入：
   STOP SLAVE;
mysql < /tmp/master_full.sql
4. 重新配置同步點並啟動：
   傳統模式：
   CHANGE MASTER TO MASTER_HOST='...', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=3260;
   GTID 模式 (推薦)：
   CHANGE MASTER TO MASTER_HOST='...', MASTER_AUTO_POSITION=1;
START SLAVE;
5. 驗證：SHOW SLAVE STATUS\G 確認 Slave_IO_Running: Yes, Slave_SQL_Running: Yes, Seconds_Behind_Master: 0。

策略選型決策樹

主從不同步 (SQL_Running=No)
    │
    ├─ 核心業務表 / 強一致性要求 / 差異未知 / 近期無備份
    │   → 方案二：重做從庫 (最安全、最徹底)
    │
    └─ 非核心表 / 可容忍秒級不一致 / 已知單一錯誤 / 有近期備份可校驗
        → 方案一：跳過錯誤 (最快、無停機)
        │
        └─ 跳過後 pt-table-checksum 發現大量差異
            → 回退方案二

常見 SQL 線程錯誤類型與預防

運維最佳實踐

• 監控 Slave_*_Running、Seconds_Behind_Master、Last_SQL_Error 即時告警。
• 定期 (每日/每週) pt-table-checksum 主從一致性校驗。
• 備份在從庫執行，主庫專注寫入。
• 文件化故障處理 SOP，演練切換/重做流程。