1. 引言

在現(xiàn)代數(shù)據(jù)庫架構中，主從復制（Master?Slave Replication）是實現(xiàn)讀寫分離、數(shù)據(jù)備份、高可用和故障轉移的基石。然而，許多開發(fā)者對復制的內部機制一知半解，尤其是半同步復制如何平衡性能與一致性。本文將帶你深入理解：

• 主從復制的核心組件（binlog、relay log、I/O線程、SQL線程）
• 配置主從復制的完整步驟
• 半同步復制的工作流程與超時降級機制
• 異步、半同步、全同步的對比與選型

通過流程圖和實戰(zhàn)案例，幫助你在生產環(huán)境中做出明智的選擇。

2. 主從復制核心架構

2.1 整體流程圖

2.2 核心組件

3. 主從復制配置步驟

3.1 主庫配置

編輯 my.cnf：

[mysqld]
server-id = 1                     # 唯一標識
log-bin = mysql-bin               # 開啟二進制日志
binlog_format = ROW               # 推薦 ROW 格式

創(chuàng)建復制賬號：

CREATE USER 'replica'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
FLUSH PRIVILEGES;

查看主庫狀態(tài)（記錄 File 和 Position）：

SHOW MASTER STATUS;

3.2 從庫配置

編輯 my.cnf：

[mysqld]
server-id = 2
relay-log = mysql-relay-bin
read_only = 1                     # 可選，防止從庫被寫入

執(zhí)行同步命令：

CHANGE MASTER TO
  MASTER_HOST = 'master_ip',
  MASTER_USER = 'replica',
  MASTER_PASSWORD = 'password',
  MASTER_LOG_FILE = 'mysql-bin.000001',
  MASTER_LOG_POS = 12345;
START SLAVE;

檢查同步狀態(tài)：

SHOW SLAVE STATUS\G

重點關注：

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes

4. 復制模式：異步、半同步、全同步

4.1 異步復制（默認）

主庫寫 binlog 后立即返回客戶端成功，不等待從庫確認。性能最高，但可能丟失數(shù)據(jù)（主庫宕機時未發(fā)送的 binlog 丟失）。

4.2 半同步復制

半同步復制在主庫提交事務前，至少等待一個從庫確認已收到 binlog（寫入 relay log）。這保證了至少一個從庫有完整的數(shù)據(jù)副本，大幅降低數(shù)據(jù)丟失風險。

工作流程

超時降級機制

如果從庫長時間不返回 ACK（如網(wǎng)絡故障），半同步復制會自動降級為異步復制，避免主庫阻塞。超時時間由參數(shù) rpl_semi_sync_master_timeout 控制（默認 10 秒）。降級后，主庫不再等待 ACK，恢復半同步需從庫重新連接并追趕數(shù)據(jù)。

配置半同步復制

主庫安裝插件并啟用：

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = 1;
SET GLOBAL rpl_semi_sync_master_timeout = 10000;  -- 10 秒

從庫安裝插件：

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

4.3 全同步復制

所有從庫確認收到 binlog 后才提交，數(shù)據(jù)一致性最強，但性能極差，極少使用。

4.4 模式對比

5. 半同步復制的超時降級詳細解析

當主庫等待 ACK 超過 rpl_semi_sync_master_timeout 后，會暫時關閉半同步模式，退化為異步復制。此時主庫的 Rpl_semi_sync_master_status 狀態(tài)變?yōu)?OFF。從庫恢復后，主庫會嘗試重新進入半同步模式。

為什么要降級？ 如果不降級，主庫將永遠阻塞，導致整個系統(tǒng)不可寫。降級機制保證了可用性優(yōu)先，同時盡可能保證一致性（降級期間仍有短暫數(shù)據(jù)丟失風險）。

監(jiān)控狀態(tài)

SHOW STATUS LIKE 'Rpl_semi_sync%';

• Rpl_semi_sync_master_status：當前是否為半同步
• Rpl_semi_sync_master_clients：活躍的半同步從庫數(shù)量
• Rpl_semi_sync_master_yes_tx：成功半同步的事務數(shù)
• Rpl_semi_sync_master_no_tx：降級為異步的事務數(shù)

6. 常見問題與最佳實踐

Q1：半同步復制下，從庫宕機會導致主庫不可用嗎？

不會。超時后自動降級為異步，主庫繼續(xù)服務，但在此期間數(shù)據(jù)一致性降低。

Q2：如何提升半同步復制的性能？

• 使用專用網(wǎng)絡減少延遲。
• 設置合理的 rpl_semi_sync_master_timeout（如 1~3 秒）。
• 確保至少一個從庫在本地機房（低延遲）。
• 監(jiān)控并優(yōu)化從庫重放速度（如開啟并行復制）。

Q3：半同步復制能保證完全不丟數(shù)據(jù)嗎？

不能。在降級為異步的時間窗口內，如果主庫宕機，尚未被從庫確認的事務仍可能丟失。真正的零丟失需要金融級的全同步或 Paxos/Raft 協(xié)議（如 MySQL Group Replication）。

Q4：配置半同步后，從庫需要額外注意什么？

從庫必須開啟 rpl_semi_sync_slave_enabled，并且 SHOW SLAVE STATUS 中的 Master_SSL_Allowed 不影響。

7. 總結

• 主從復制是 MySQL 高可用架構的底座。
• 異步復制性能最高，但存在數(shù)據(jù)丟失風險。
• 半同步復制在一致性與性能間取得平衡，通過超時降級機制避免了主庫阻塞。
• 關鍵參數(shù)：rpl_semi_sync_master_timeout、rpl_semi_sync_master_wait_point（可選 AFTER_SYNC 等）。
• 生產推薦：核心業(yè)務使用半同步復制 + 至少兩個從庫，并開啟監(jiān)控告警。

到此這篇關于深度解析MySQL中主從復制的詳細流程的文章就介紹到這了,更多相關MySQL主從復制內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論