1. 程式人生 > >MySQL叢集的幾種方案

MySQL叢集的幾種方案

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