MySQL 主從複製延遲與數據不一致修復：原理、排查與不停主庫恢復實戰

面試高頻題：描述 MySQL Replication 實現原理，如何在不停主庫的情況下恢復數據不一致的 Slave？ 本文拆解「基於 Binlog 的單線程異步複製」核心機制，給出標準修復流程與工具化方案。

複製核心原理：三線程協作模型

• Master IO Thread：讀取本地 Binlog 發送給 Slave。
• Slave IO Thread：連接 Master，請求 Binlog，寫入本地 Relay Log。
• Slave SQL Thread：讀取 Relay Log，解析並重放事務。

關鍵特性：異步、單線程重放（5.6 前）、Binlog 格式（STATEMENT/ROW/MIXED）影響一致性。

複製流程四步走

1. Slave IO Thread 請求：CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy 指定起始位點。
2. Master IO Thread 讀取發送：返回 Binlog 事件 + 新位點（文件名 + Position）。
3. Slave IO Thread 寫入 Relay Log：追加寫入，更新 master.info 記錄下次請求位點。
4. Slave SQL Thread 重放：解析 Relay Log 為可執行 SQL，在 Slave 執行。

不停主庫修復不一致 Slave：標準操作流程

場景：Slave 數據漂移、報錯停止、或需重新同步

-- 1. 主庫：獲取當前 Binlog 位點（加鎖保證一致性快照）
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000015 |  123456  |              |                  |
+------------------+----------+--------------+------------------+
-- 記錄 File + Position，隨即 UNLOCK TABLES（或用 mysqldump --master-data=2 獲取）

-- 2. 從庫：停止複製、重新定位、啟動
mysql> STOP SLAVE;
mysql> CHANGE MASTER TO 
    MASTER_HOST='master_ip',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='repl_pass',
    MASTER_LOG_FILE='mysql-bin.000015',
    MASTER_LOG_POS=123456;
mysql> START SLAVE;

-- 3. 驗證
mysql> SHOW SLAVE STATUS\G
-- 關鍵指標：Slave_IO_Running=Yes, Slave_SQL_Running=Yes, Seconds_Behind_Master=0

進階修復方案對比

延遲監控與預警關鍵指標

• Seconds_Behind_Master：SQL Thread 落後 Master 的秒數（不準，受長事務影響）。
• Relay_Log_Space：Relay Log 總大小，暴增說明 SQL Thread 卡頓。
• Exec_Master_Log_Pos vs Read_Master_Log_Pos：重放位點 vs 接收位點，差距大 = 延遲。
• 建議部署 Prometheus + mysqld_exporter + Grafana 監控儀表盤。

最佳實踐建議

1. 主庫啟用 GTID（5.6+），簡化故障轉移與重新同步。
2. 從庫啟用 log_slave_updates，支援級聯複製與備份。
3. 關鍵業務採用半同步複製（rpl_semi_sync），降低數據丟失風險。
4. 定期執行 pt-table-checksum 發現隱性不一致。
5. 文檔化修復 SOP，含聯繫人、備份位置、驗證腳本，讓新人也能獨立處理。

掌握複製原理與修復 SOP，是 DBA 從「會用」進階到「敢用、善用」的分水嶺。