MySQL Slave_SQL_Running=No 同步故障診斷與修復全流程

故障現象識別

mysql> SHOW SLAVE STATUS\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1062
Last_Error: Error 'Duplicate entry ... for key PRIMARY' on query...
Seconds_Behind_Master: NULL

核心信號：IO 線程正常（接收 Binlog 無誤），SQL 線程停止（重放報錯），Seconds_Behind_Master=NULL 確認同步中斷。

常見根因分類

修復方案一：重新同步（數據一致性最高，耗時最長）

適用於：數據差異大、無法確定具體不一致範圍、可接受停寫窗口。

1. Master 記錄位點：

   mysql> FLUSH TABLES WITH READ LOCK;  -- 短暫阻塞寫入
   mysql> SHOW MASTER STATUS;
   +------------------+-----------+--------------+------------------+
   | File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
   +------------------+-----------+--------------+------------------+
   | mysql-bin.000020 | 135617781 |              |                  |
   +------------------+-----------+--------------+------------------+
   mysql> UNLOCK TABLES;

2. Master 全量備份（推薦 XtraBackup 熱備，或 mysqldump --single-transaction --master-data=2）
3. Slave 恢復備份並定位：

   -- Slave 停止復制
   STOP SLAVE;
   
   -- 恢復備份數據（略）
   
   -- 重新配置同步位點
   CHANGE MASTER TO
     MASTER_HOST='master_ip',
     MASTER_USER='repl_user',
     MASTER_PASSWORD='repl_pass',
     MASTER_PORT=3306,
     MASTER_LOG_FILE='mysql-bin.000020',
     MASTER_LOG_POS=135617781;
   
   -- 啟動復制
   START SLAVE;

4. 驗證：SHOW SLAVE STATUS\G 確認 Slave_SQL_Running: Yes、Seconds_Behind_Master: 0。

修復方案二：跳過錯誤事件（快速恢復，風險數據不一致）

適用於：明確知曉是單一事件錯誤（如偶發主鍵衝突）、業務可容忍少量數據差異、需秒級恢復。

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;  -- 跳過 1 個事件
START SLAVE;

風險警示：跳過事件會導致 Slave 數據與 Master 不一致。後續 Master 執行 DELETE/UPDATE 該行時，Slave 可能報錯 1032（行不存在）或產生邏輯差異。必須事後進行數據校驗修復（如 pt-table-checksum + pt-table-sync）。

修復方案三：就地修正數據後重試（精準修復，需分析具體 SQL）

1. 獲取報錯 SQL：SHOW SLAVE STATUS\G 中 Last_Error 含完整語句。
2. 在 Slave 手動執行修正：
   • 1062 主鍵衝突：DELETE FROM tbl WHERE pk=xxx; 再 START SLAVE;
   • 1032 行不存在：從 Master SELECT * FROM tbl WHERE pk=xxx; 導出插入 Slave，再 START SLAVE;
3. 若涉及多行/多表，編寫腳本批量修正。

進階診斷工具：pt-table-checksum & pt-table-sync

# 檢測主從數據一致性（在 Master 執行）
pt-table-checksum --recurse=1 --databases=db1,db2 \
  --user=repl --password=pass --host=master_ip

# 輸出差異表，在 Slave 上修復
pt-table-sync --execute --print --user=root --password=pass \
  h=master_ip,D=db1,t=tbl1 h=slave_ip,D=db1,t=tbl1

建議納入定期巡檢體系（每日/每週），異常即時告警修復。

預防體系建設

1. 嚴禁向 Slave 寫入業務數據：賬號權限隔離、只讀模式 super_read_only=ON (5.7+)。
2. 統一 Binlog 格式：Master/Slave 均設 binlog_format=ROW，減少非確定性函數導致的不一致。
3. GTID 模式復制：MySQL 5.6+ 啟用 gtid_mode=ON，自動定位位點，簡化故障恢復。
4. 監控告警覆蓋：Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master、Last_SQL_Errno 四大指標必監控。
5. 定期演練故障恢復：季度演練「主庫故障切換」、「Slave 重建」、「數據校驗修復」全流程。

總結決策樹

Slave_SQL_Running=No
    │
    ├─ Last_Errno=1062/1032/1051 且 業務可接受極小差異 且 需秒級恢復
    │     → 方案二：sql_slave_skip_counter=1 + 事後 pt-table-sync 修復
    │
    ├─ Last_Errno 系統級錯誤(1548/1071) 或 數據差異範圍未知
    │     → 方案一：重新全量同步（最安全）
    │
    └─ 明確知曉具體報錯 SQL 且 僅涉及少量行
          → 方案三：手動修正數據 + START SLAVE

核心原則：數據一致性 > 恢復速度。除非極端業務壓力，優先選擇重新同步或精準修正，跳過事件僅作應急臨時方案，且必須留存審計日志事後追蹤修復。