MySQL 5.0 主從復制核心原理（一）：架構模型、三線程協作、Binlog/Relay Log 生命周期

前言

MySQL 復制自 3.23.15 引入，採用經典的 單向異步復制 架構。本文深度解析 核心概念、三線程協作模型、Binlog/Relay Log 文件管理、進程狀態機、狀態文件持久化，構建對復制機制的系統性認知。

一、復制核心概念與優勢

架構角色

• Master (主庫)：接收所有寫入，生成 Binlog
• Slave (從庫)：拉取 Binlog，重放 SQL，可級聯為下一級 Master

單向復制三大優勢

1. 高可用備援：Master 故障可提升 Slave 切換
2. 讀寫分離擴展：SELECT 分流至 Slave，Master 專注寫入
3. 無影響備份：對 Slave 執行 FLUSH TABLES WITH READ LOCK + 拷貝，Master 業務零干擾

⚠️ 核心約束：所有同步更新必須在 Master 執行，雙邊寫入將導致數據發散。

二、復制實現機制概覽

前置條件

• Master 必須啟用 --log-bin（Binlog）
• Slave 數據初始狀態 = Master 啟用 Binlog 時刻的快照

數據初始化方式

1. LOAD DATA FROM MASTER（4.0+，僅 MyISAM，需全局讀鎖，~1MB/s）
2. mysqldump --master-data + 導入（通用，較慢）
3. 物理拷貝（xtrabackup、LVM 快照、cp -r）+ 記錄 Binlog 位點

斷線重連機制

• Slave 記錄自身 Relay Log 執行位點（relay-log.info）
• Master 無感知 Slave 數量/狀態
• 斷線後按 --master-connect-retry（默認 60s）定期重試

三、三線程協作模型（核心）

MySQL 4.0.2+ 採用 1 Master 線程 + 2 Slave 線程 解耦讀取與執行：

解耦帶來的關鍵收益

1. 讀取不阻塞於執行：SQL Thread 慢不影響 I/O Thread 續拉 Binlog
2. 斷點續傳：Slave 重啟後，I/O Thread 已拉取完 Binlog 存入 Relay Log，SQL Thread 直接續執行
3. Master 可清理 Binlog：Slave 本地有完整 Relay Log，無需回源

進程狀態機詳解（診斷利器）

Master Binlog Dump 線程狀態

• Sending binlog event to slave：正常發送中
• Finished reading one binlog; switching to next binlog：輪轉
• Has sent all binlog to slave; waiting for binlog to be updated：空閒等待新寫入
• Waiting to finalize termination：停止中

Slave I/O 線程狀態

• Connecting to master / Checking master version / Registering slave on master / Requesting binlog dump：建連階段
• Waiting for master to send event：正常等待（Master 閒置時長時間）
• Queueing master event to the relay log：寫入 Relay Log
• Waiting to reconnect after a failed binlog dump request：重試間隔中
• Waiting for the slave SQL thread to free enough relay log space：relay_log_space_limit 觸發背壓

Slave SQL 線程狀態

• Reading event from the relay log：正常讀取
• Has read all relay log; waiting for the slave I/O thread to update it：追上進度，等待新事件
• Waiting for slave mutex on exit：停止中
• 直接顯示 SQL 語句：正在執行該語句

四、Relay Log 與狀態文件管理

文件命名與輪轉

• 默認名：host_name-relay-bin.nnnnnn（4.0+ 6 位序號，舊版 3 位）
• 索引文件：host_name-relay-bin.index
• 可通過 --relay-log、--relay-log-index 自定義路徑

創建新 Relay Log 觸發條件

1. Slave 啟動，I/O Thread 首次啟動（5.0 每次 I/O 啟動都新建）
2. FLUSH LOGS / mysqladmin flush-logs（4.0.14+）
3. 當前文件超過 max_relay_log_size（>0）或 max_binlog_size（=0 或舊版）

自動清理機制

• SQL Thread 讀完並執行完事件 → 自動刪除該 Relay Log
• 無顯式刪除命令，完全由 SQL Thread 驅動

兩大狀態文件（持久化斷點）

備份 Slave 時必備份：數據目錄 + 兩狀態文件 + Relay Log + SQL_LOAD-* 臨時文件（LOAD DATA INFILE 斷點續傳）。

五、版本演進關鍵節點

• 3.23.15：引入單向復制，單線程模型（I/O+SQL 合一），無 Relay Log
• 4.0.2：引入三線程模型 + Relay Log，解耦讀執
• 4.0.14：FLUSH LOGS 輪轉 Relay Log；復制 FOREIGN_KEY_CHECKS
• 4.1.1：SSL 復制；DDL/維護命令入 Binlog；master.info 增加 SSL 字段
• 5.0：Binlog 格式再升級；每次 I/O 啟動新建 Relay Log

六、監控與診斷實戰命令

# Master 端
SHOW PROCESSLIST\G  -- 關注 Binlog Dump 線程 State
SHOW MASTER STATUS; -- 當前 Binlog 文件/位點

# Slave 端
SHOW SLAVE STATUS\G -- 核心：Slave_IO_Running, Slave_SQL_Running, Seconds_Behind_Master
SHOW PROCESSLIST\G  -- 關注 I/O、SQL 線程 State
SHOW RELAYLOG EVENTS; -- 解析 Relay Log 內容（類似 mysqlbinlog）

總結

MySQL 復制的靈魂在於 Binlog 為源、Relay Log 為緩衝、三線程解耦讀執、狀態文件持久化斷點。理解這套機制，即可從容應對：搭建新 Slave、診斷同步延遲/卡頓、設計故障切換腳本、規劃跨版本升級、排查數據不一致 等所有復制運維場景。