首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
您现在的位置: 程式碼之家 >> 數據庫知識 >  >> MySQL 資料庫 >> MySQL 綜合教學

MySQL 主從複製原理與實戰部署全解析

     編輯:MySQL 綜合教學

MySQL 複制架構核心機制

MySQL 的主從複製是基於二進制日誌(Binary Log,簡稱 Binlog)實現的高可用架構核心。整個複製過程涉及三個關鍵線程協同工作:主庫的 Binlog Dump 線程、從庫的 I/O 線程以及 SQL 線程。

複製流程詳解

MySQL 複制架構圖

  1. 主庫記錄變更:主庫將所有數據變更操作(INSERT、UPDATE、DELETE 等)順序寫入 Binlog。
  2. Dump 線程推送:當複製啟動時,主庫的 Dump 線程根據從庫 I/O 線程的請求,讀取 Binlog 事件並發送給從庫。
  3. I/O 線程寫入中繼日誌:從庫的 I/O 線程接收事件後,順序寫入本地的 Relay Log(中繼日誌)。
  4. SQL 線程重放執行:從庫的 SQL 線程讀取 Relay Log 中的事件,在從庫上重放執行,實現數據同步。

演進歷史:從雙線程到三線程

MySQL 4.0 之前僅採用雙線程模型(主從各一),從庫單線程同時負責接收和重放,易導致重放緩慢時阻塞接收。引入 Relay Log 後,接收與重放解耦,顯著提升穩定性與性能。

主從複製部署實戰步驟

1. 配置主從服務器參數

主庫配置 (my.cnf)

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

關鍵點:server-id 必須全局唯一(範圍 1~232-1)。若設為 0 或未顯式配置,MySQL 會自動改為 1,但未顯式配置時從庫 IO 線程會報錯 Misconfigured master - server_id was not set。

從庫配置 (my.cnf)

[mysqld]
server-id=2

從庫可選擇不開啟 Binlog;若開啟並需記錄重放事件,需設定 log_slave_updates=1。配置完成後重啟雙方服務。

2. 創建複製專用賬號

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

3. 獲取主庫一致性快照

使用 mysqldump 產生帶位置信息的備份:

# mysqldump --master-data=2 -R --single-transaction -A > 3306_20160815.sql

備份文件頭部包含關鍵同步座標:

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000016', MASTER_LOG_POS=120;

4. 從庫導入快照數據

# mysql < 3306_20160815.sql

5. 配置並啟動複製

mysql> CHANGE MASTER TO 
    MASTER_HOST='master_host',
    MASTER_USER='replication_user',
    MASTER_PASSWORD='replication_pass',
    MASTER_LOG_FILE='mysql-bin.000016',
    MASTER_LOG_POS=120;

執行後信息寫入 master.info 和 relay-log.info,並未立即連接。隨後啟動:

mysql> START SLAVE;

6. 驗證複製狀態

mysql> SHOW SLAVE STATUS\G

核心指標均為 Yes 即成功:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

MySQL 複制三大格式深度對比

Statement-Based Replication (SBR)

記錄原始 SQL 語句。MySQL 3.23 即引入。

  • 優點:Binlog 體積小,便於審計。
  • 缺點:UUID()、NOW() 等非確定性函數導致主從不一致;LIMIT 無 ORDER BY 時結果不可預測;INSERT ... SELECT 需更多行鎖;UDF 必須確保確定性。

Row-Based Replication (RBR)

MySQL 5.1 引入,記錄行級變更。

  • 優點:絕對安全,所有變更可復制;INSERT ... SELECT、自增列、無索引 UPDATE/DELETE 鎖更少。
  • 缺點:大量日誌(全表 DELETE 產生 N 條記錄),導致恢復慢、Binlog 鎖定久、磁盤/網路 IO 壓力大、從庫延遲增加;不校驗 Binlog;不推薦庫級過濾參數。

Mixed 模式

動態切換 SBR/RBR。MySQL 5.7.7 前默認 SBR,之後默認 RBR。遇 unsafe statements 自動切換 RBR。切換條件參考官方文檔。

複製核心文件解析

Relay Log(中繼日誌)

存儲從庫 I/O 線程接收的 Binlog 事件,格式同 Binlog,可用 mysqlbinlog 解析。參數 relay_log、relay_log_index 控制文件名。切換場景:Slave IO 線程啟動、FLUSH LOGS、達到 max_relay_log_size(默認 0,沿用 max_binlog_size)。SQL 線程重放完畢自動清理(受 relay_log_purge 控制)。

master.info

記錄主庫連接信息(主機、端口、用戶、密碼)及從庫已讀取的 Binlog 位置(對應 Master_Log_File、Read_Master_Log_Pos)。

relay-log.info

記錄 SQL 線程重放進度(對應 Relay_Master_Log_File、Exec_Master_Log_Pos),確保重啟後斷點續傳。

Crash-Safe Replication(崩潰安全複製)

傳統模式下,master.info/relay-log.info 異步刷盤,OS 崩潰導致內存數據丟失,重啟後重複執行。MySQL 5.6 引入兩參數解決:

  • master_info_repository=TABLE:信息存入 mysql.slave_master_info 表
  • relay_log_info_repository=TABLE:信息存入 mysql.slave_relay_log_info 表

雙參數設為 TABLE 後,相關操作納入事務,實現崩潰安全。

核心總結與最佳實踐

  1. 複製開銷主要來自 Binlog 寫入與 fsync 系統調用。
  2. 向後兼容:新版本 Binlog 包含新事件類型,可用新版作從庫。
  3. MySQL 複制本質是異步的。
  4. MySQL 5.6+ 支持延遲複製(master_delay 參數控制)。

參考資源

  1. MySQL 官方複製配置文檔
  2. 《MariaDB 原理與實現》
  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved