MySQL 主從同步複制原理深度解析：三執行緒模型與 Binlog/Relay Log 流程

MySQL 主從同步複制原理深度解析：三執行緒模型與 Binlog/Relay Log 流程

MySQL Replication (主從複制) 採用**非同步**模式 (5.1.7+ 另支援半同步)，核心由**三個執行緒**協作完成：

• Master IO Thread (主庫)：負責讀取 Binlog 發送給 Slave。
• Slave IO Thread (從庫)：連接 Master、請求 Binlog、寫入本地 Relay Log。
• Slave SQL Thread (從庫)：讀取 Relay Log、解析 SQL、在從庫重放執行。

核心前提：Master 必須開啟 Binlog

[mysqld]
log-bin=mysql-bin
server-id=1

若無 Binlog，複制無法工作。

複制交互流程 (簡化版)

1. Master 執行交易 → 寫入 Binlog (循序寫入，群組提交)。
2. Slave IO Thread 連接 Master，請求指定 MASTER_LOG_FILE + MASTER_LOG_POS 之後的 Binlog。
3. Master IO Thread 讀取 Binlog 事件，回傳給 Slave (含事件內容、下一個 Binlog 檔名/位置)。
4. Slave IO Thread 將事件**順序寫入 Relay Log** (mysql-relay-bin.xxxxxx)，並更新 master.info 記錄下次請求座標。
5. Slave SQL Thread 檢測到 Relay Log 新增內容 → 解析還原 SQL → **在從庫按順序執行**。
6. 從庫資料與主庫最終一致 (非同步故存在毫秒~秒級延遲)。

關鍵檔案說明

重要特性與運維啟示

• 非即時同步：網路正常時也存在延遲，Seconds_Behind_Master 監控關鍵。
• 網路斷線自動追趕：Slave 重連後從 master.info 記錄位置繼續拉取。
• 從庫寫入極度危險：若從庫執行 DML 與 SQL Thread 重放衝突 → Slave_SQL_Running=No 停止複制，**嚴禁直接寫入從庫**。
• 雙主/環形拓撲：需設定 auto_increment_increment/offset 避免 ID 衝突，且業務邏輯保證無寫入衝突。

半同步複制 (5.1.7+ / 5.5+ 官方插件)

Master 至少收到**一個 Slave** 確認收到 Binlog (寫入 Relay Log) 才提交交易，降低主庫掛掉導致資料丟失風險，但增加延遲。配置：

-- Master
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled=1;

-- Slave
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_slave_enabled=1;