【整理】組建 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 人群的數量等 綜合權衡。