MySQL 主從複寫原理深度解析：三線程協作、非同步風險與演進歷程

MySQL Replication 採用非同步複寫架構，透過三條線程協作實現資料同步。理解其運作流程、延遲來源、資料遺失風險，是架構高可用、排查主從延遲的基礎。

一、架構總覽：三線程模型

二、複寫完整流程 (Step-by-Step)

1. Slave IO Thread 連接 Master，發送 COM_BINLOG_DUMP，攜帶 MASTER_LOG_FILE、MASTER_LOG_POS (來自 master.info)，請求後續事件。
2. Master Binlog Dump Thread 依位點讀取 binlog，回傳事件 + 當前 binlog 檔名/位點。
3. Slave IO Thread 依序寫入 Relay Log (mysql-relay-bin.xxxxxx)，並更新 master.info (記錄下次請求位點)。
4. Slave SQL Thread 偵測到 Relay Log 新增內容，解析事件還原為原始 SQL，在 Slave 執行，更新 relay-log.info。

結果：Master 執行什麼 SQL，Slave 就重放什麼 SQL，最終資料一致 (最終一致性)。

三、為什麼從單線程演進為雙線程？

早期版本 Slave 單線程同時負責「拉取 binlog → 解析 → 重放」，存在兩大痛點：

1. 效能瓶頸：串行流程導致複寫延遲大，高寫入場景下 Slave 跟不上 Master。
2. 資料遺失風險放大：若 Slave 解析/重放緩慢，Master 產生大量新 binlog 尚未傳輸；此時 Master 存儲故障，這段 binlog 永久遺失。單線程模型下「拉取」與「重放」共用時間窗口，風險期更長。

Yahoo! 工程師 Jeremy Zawodny 提出雙線程改進，MySQL 後續版本採納：

• IO Thread 專職「拉取 + 寫 Relay Log」——極快、幾乎無阻塞。
• SQL Thread 專職「解析 + 重放」——可並行優化 (後續多線程複寫)。
• 解耦後，「拉取」幾乎即時完成，縮短「Master 故障導致 binlog 未傳到 Slave」的風險窗口。

四、非同步複寫的固有風險

即使雙線程，本質仍為非同步：

• Master 不等待 Slave 確認即回應 Client Commit 成功。
• Master 宕機時，已 Commit 但未傳至 Slave 的 binlog 事件**永久遺失**。
• Slave 延遲 (Seconds_Behind_Master) 取決於：網路延遲、SQL Thread 重放速度、大交易、DDL 鎖表、無索引更新掃表等。

五、關鍵檔案與位點持久化

MySQL 5.6+ 可設定 master_info_repository=TABLE、relay_log_info_repository=TABLE 存入 mysql.slave_master_info、mysql.slave_relay_log_info 表，支援交易性更新，崩潰更安全。

六、延伸：半同步複寫、GTID、多線程複寫、Group Replication

• 半同步複寫：Master 等待至少一個 Slave 收到 binlog 並寫入 Relay Log (可配置等待 flush 到磁碟) 才 Commit 返回，大幅降低遺失風險。
• GTID (Global Transaction ID)：5.6+ 引入，用 UUID:NUMBER 全域唯一標識交易，簡化故障轉移、跳過錯誤交易、多源複寫。
• 多線程複寫 (MTS)：5.6 基於 Database 平行、5.7 基於邏輯時鐘 (Logical Clock) 平行、8.0 基於 Write Set 並行，大幅提升 SQL Thread 吞吐。
• Group Replication / InnoDB Cluster：基於 Paxos 協議的多主同步複寫，提供強一致性、自動故障轉移，是 MySQL 8.0 企業級 HA 方案核心。

掌握三線程協作流程、非同步本質、位點持久化機制，是進階學習半同步、GTID、MTS、Group Replication 的基石。生產環境務必監控 Seconds_Behind_Master、Slave_IO_Running/Slave_SQL_Running、Relay Log 空間佔用。