MySQL 半同步複制原理與架構詳解

MySQL 5.5 引入半同步複制作為異步與全同步的折中方案，確保「已提交事務至少存在於主庫與一台從庫」，兼顧數據安全與性能。本文系統梳理其定義、優缺點、核心特性、異常處理機制，為後續 5.7 增強版優化奠定基礎。

一、三種複制模式對比

二、半同步複制定義

主庫提交事務後，阻塞會話線程，直到：

1. 至少一台半同步從庫收到 binlog 事件
2. 從庫寫入 relay log 並 刷盤
3. 從庫回傳 ACK

或發生超時（rpl_semi_sync_master_timeout，預設 10 秒），自動降級為異步複制。

三、優缺點總結

優點

• 事務返回成功時，數據已落盤於主備兩機，大幅降低單點故障丟數據風險。
• 相比全同步，僅等待一台從庫，延遲可控；相比異步，數據安全性質變提升。

缺點

• 每個事務提交需額外等待「網絡傳輸 + 從庫刷盤」時間，TPS 受 RTT 影響。
• 高併發下，dump 線程串行發送+等待 ACK 成為瓶頸（5.7 已優化）。

四、核心特性

1. 雙向協商：從庫連接時宣告是否支援半同步；主庫僅在至少一台從庫啟用時生效。
2. 阻塞等待：提交線程在收到 ACK 或超時前處於阻塞狀態（5.7 引入 ACK Collector 線程解耦）。
3. 刷盤確認：從庫必須 sync_relay_log=1 才算真正落盤，防止 OS cache 丟失。
4. 全或無：主備任一端未啟用，自動退回異步模式。
5. 超時降級：超時自動關閉半同步，避免主庫掛起；從庫恢復後需手動或腳本重新啟用。

五、異常處理與「牆頭事務」問題

1. 從庫崩潰

主庫超時後自動降級異步，錯誤日誌記錄：Timeout waiting for reply of binlog ... Semi-sync replication switched OFF.

2. 主庫崩潰與牆頭事務

主庫崩潰時，可能存在「已在主庫提交、未傳至從庫」的事務：

• 客戶端未收到成功返回 → 視為失敗，重試即可。
• 若已收到成功返回，但從庫未收到 → 故障轉移至從庫時，數據不一致（「牆頭事務」）。

應對：建立主備校驗機制，故障轉移前比對 binlog position / GTID，必要時從主庫恢復補全。

六、小結

半同步複制以「可接受的性能代價」換取「雙副本落盤」的數據安全，是生產環境主流高可用架構的基石。MySQL 5.7 進一步通過異步化架構與可配置等待點，大幅提升了高併發場景下的可用性與靈活性。