組建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；