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

回答：

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

1. 首先反對大家做讀寫分離，關於這方面的原因解釋太多次數（增加技術複雜度、可能導致讀到落後的資料等），只說一點：99.8%的業務場景沒有必要做讀寫分離，只要做好資料庫設計優化 和配置合適正確的主機即可。

2.Keepalived+MySQL --確實有腦裂的問題，還無法做到準確判斷mysqld是否HANG的情況；

3.DRBD+Heartbeat+MySQL --同樣有腦裂的問題，還無法做到準確判斷mysqld是否HANG的情況，且DRDB是不需要的，增加反而會出問題；

3.MySQL Proxy -- 不錯的專案，可惜官方半途夭折了，不建議用，無法高可用，是一個寫分離；

4.MySQL Cluster -- 社群版本不支援NDB是錯誤的言論，商用案例確實不多，主要是跟其業務場景要求有關係、這幾年發展有點亂不過現在已經上正規了、對網路要求高；

5.MySQL + MHA -- 可以解決腦裂的問題，需要的IP多，小叢集是可以的，但是管理大的就麻煩，其次MySQL + MMM 的話且坑很多，有MHA就沒必要採用MMM

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

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