MMM vs MHA：大眾點評 MySQL 高可用架構選型與踩坑實錄

為什麼需要 HA 方案？

• Master 宕機（硬體故障、OS 崩潰）。
• Master 維護（大表 DDL、記憶體更換等物理操作）。

無工具手動切換流程（痛點）

1. 告警通知 DBA。
2. 確認並 Kill 舊 Master。
3. 從 Slave 中找最新資料節點作候選 Master。
4. 各 Slave 執行 CHANGE MASTER TO 指向新 Master。
5. 修改應用配置指向新 Master IP 並重啟。

全流程耗時長、人為失誤率高、不可接受。

MMM (Master-Master Replication Manager) 在點評的應用與坑

• 雙 Master 互為備援，VIP 漂移實現故障轉移。
• 踩過的坑：mmm_monitor 誤判導致 VIP 震盪、複製延遲檢測閾值難調、寫入衝突處理機制弱、網路分區時腦裂風險。
• 填坑手段：加強監控邏輯、引入外部仲裁、限制雙寫業務、完善故障演練。

MHA (Master High Availability) 引入與優勢

• 單 Master 多 Slave 架構，自動故障轉移（通常 10-30 秒）。
• 核心優勢：基於 Relay Log 差異補全、支援線上切換、對應用透明、Perl 實現輕量易擴展。
• 點評改進：整合 CMDB 自動發現拓撲、加入備庫延遲強制檢查、切換前自動備份 Binlog、切換後自動驗證資料一致性。

選型抉擇

點評最終選擇 MHA 作為主流 HA 方案，MMM 逐步淘汰。

資源連結

• PPT 下載：https://pan.baidu.com/s/1mg3G2MW
• 大會連結：https://meeting.zhdba.com/2014dtcc

1. 上一篇文章： libmysqld 嵌入式 MySQL 伺服器庫：原理、編譯與限制
2. 下一篇文章： Debian LNMP 環境搭建實戰：Nginx + MySQL + PHP 7 完整配置

MySQL 綜合教學

B 樹與 B+ 樹原理及在 MySQL 索引中的應用深度解析

B 樹與 B+ 樹原理及在 MySQL 索引中的應用深度解析

MySQL 連接池中斷導致事務未回滾、資料被鎖定問題分析

架構背景 App → LoadBalancer (LB) →

MySQL mysqldump 全量備份與 Binlog 增量結合實戰流程

環境準備 # 環境變數配置（或使用完整路徑） export

MySQL 大數據量導入最佳實踐：mysqldump 直連、phpMyAdmin 限制突破與參數調優

MySQL 大數據量導入最佳實踐：mysqldump 直連、