【整理】組建MySQL叢集的幾種方案

金官丁 在 知乎 上的回答。 

組建 MySQL 叢集的幾種方案 

• LVS+Keepalived+MySQL（有腦裂問題？但似乎很多人推薦這個）
• DRBD+Heartbeat+MySQL（有一臺機器空餘？Heartbeat 切換時間較長？有腦裂問題？）
• MySQL Proxy（不夠成熟與穩定？使用了 Lua？是不是用了他做分表則可以不用更改客戶端邏輯？）
• MySQL Cluster （社群版不支援 INNODB 引擎？商用案例不足？）
• MySQL + MHA （如果配上非同步複製，似乎是不錯的選擇，又和問題？）
• MySQL + MMM （似乎反映有很多問題，未實踐過，誰能給個說法）

回答： 

不管哪種方案都是有其場景限制或說規模限制，以及優缺點的。 

• 首先反對大家做讀寫分離，關於這方面的原因解釋太多次數（增加技術複雜度、可能導致讀到落後的資料等），只說一點：99.8% 的業務場景沒有必要做讀寫分離，只要做好資料庫設計優化和配置合適正確的主機即可；
• Keepalived+MySQL — 確實有腦裂的問題，還無法做到準確判斷 mysqld 是否 HANG 的情況；
• DRBD+Heartbeat+MySQL — 同樣有腦裂的問題，還無法做到準確判斷 mysqld 是否 HANG 的情況，且 DRDB 是不需要的，增加反而會出問題；
• MySQL Proxy — 不錯的專案，可惜官方半途夭折了，不建議用，無法高可用，是一個寫分離；
• MySQL Cluster — 社群版本不支援 NDB 是錯誤的言論，商用案例確實不多，主要是跟其業務場景要求有關係、這幾年發展有點亂不過現在已經上正規了、對網路要求高；
• MySQL + MHA — 可以解決腦裂的問題，需要的 IP 多，小叢集是可以的，但是管理大的就麻煩，其次 MySQL + MMM 的話且坑很多，有 MHA就沒必要採用 MMM。

建議： 

• 若是雙主複製的模式，不用做資料拆分，那麼就可以選擇 MHA 或 Keepalive 或 heartbeat；
• 若是雙主複製，還做了資料的拆分，則可以考慮採用 Cobar；
• 若是雙主複製+Slave，還做了資料的拆分，需要讀寫分類，可以考慮 Amoeba；

上述所有的內容都要依據公司內部的業務場景、資料量、訪問量、併發量、高可用的要求、DBA 人群的數量等 綜合權衡。