組建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人羣的數量等 綜合權衡，如果須要能夠聯繫我：jinguanding# http://hotpu.cn

 

 

 

有不少架構師,仍是比較推崇使用基於DRBD架構的.　

若是是基於複製的 shared-nothing 架構，不作讀寫分離，多節點同時寫入，一定會衝突啊！

是否是筆誤呢？題主問題是MySQL Cluster 社區版本不支持InnoDB引擎，不是NDB，NDB引擎固然會支持了。

 

 

題主對mysq的高可用及集羣方式瞭解比較充分。應該說按照實際商用的場景來設計數據庫集羣架構，這樣纔是合理的。若是你追求完美的高可用，避免任何的單點故障，能夠在主從、主主同步的基礎上配合keepalived或是heartbeat，這二者作故障切換都很好用。高性能上，與其期望一套數據庫後端服務搞定全部業務，不如考慮不一樣業務的在不一樣服務器資源上的sharding，但其管理複雜度一定會增長，看你怎麼權衡管理性和性能方面。關於可擴展性，mysql代理（如阿里的amoeba）+mysql一主多從能夠考慮。總之沒有最好的方案，只有最合適的！

 

 

 

做者：jhh
連接：https://www.zhihu.com/question/21307639/answer/123316479
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

先介紹幾種方案

• 主從複製，包括一拖一的主從和一拖多的主從

高可用性 ：比較高

高可擴展性 ：無

高一致性 ：比較高

延遲性 ：比較小

併發性 ：無

事務性 ：無

吞吐率 ：比較高

數據丟失 ：不丟失

可切換 ：能夠切換

• 環形複製,包括兩個節點和多個節點造成的環形

高可用性 ：比較高

高可擴展性 ：無

高一致性 ：比較高

延遲性 ：比較小

併發性 ：無

事務性 ：無

吞吐率 ：比較高

數據丟失 ：不丟失

可切換 ：能夠切換

• 2PC：

高可用性 ： 很高

高可擴展性 ： 可擴展，不能大規模擴展，也無需大規模擴展

高一致性 ： 比較高

延遲性 ： 比較大

併發性 ： 比較小

事務性 ： 有

吞吐率 ： 比較小

數據丟失 ： 不丟失

可切換 ： 無關

• Paxos：元數據的高可用，併發度不高

高可用性 ： 很高

高可擴展性 ： 無關 可擴展，不能大規模擴展，也無需大規模擴展

高一致性 ： 很高

延遲性 ： 比較大

併發性 ： 比較小

事務性 ： 有

吞吐率 ： 比較小

數據丟失 ： 不丟失

可切換 ： 無關

以上純屬我的理解，若有異議，也是沒問題的；

另外按照master是否服務具體業務來分分佈式能夠分爲兩類：

1. master管理系統，而且全部請求經過master，很明顯master存在性能瓶頸
2. master管理系統，實際請求不經過master，請求分散均勻了

確定選方案2

基於這些方案的特色，如何設計一個牛逼滴分佈式系統 ？

這裏的牛逼包括

• 可大規模擴展：要求像hadoop那樣，至少幾百條臺沒問題
• 高可用：master須要高可用，節點也須要高可用，也就是說任何一個組件的一個實例或者部分實例掛了，都不會影響整個系統
• 高併發：普通機器單節點至少要支持幾千的併發度吧，若是擴展解決了，整個系統的併發其實也擴展的
• 數據一致性:分佈式系統，一致性可難了，儘可能保證吧，好比主從同步實現一致 ，或者使用兩階段2pc同時寫多個節點，或者使用像paxos一致性協議算法實現哈
• 事務性：分佈式系統，絕對的事務很難吧，哎，咱們就用2pc，3pc吧，儘可能保證哈
• 自動切換 ： 首先你得想自動切換的條件如何呢？ 好比主從同步，主掛了，我能夠自動切換到從，但是若是從數據和主不一樣步，可是業務要求很高，不容許這種狀況出現，那也只好停服維護啦。

好了 你能夠開始噴了 ， 怎麼可能。

paxos一致性協議，可用性很高，一致性很高，事務性很不錯 ， 那麼涉及到各類服務均可以用他，很是好。

master和metadata元數據採用paxos一致性協議，全部節點也採用paxos一致性協議 ， 客戶端保持這些信息。架構以下所示 ，master, metadata, node 都實現了paxos協議，也即經過paxos接口訪問

分佈式數據庫就是一個例子，貌似目前流行的數據庫都尚未支持paxos協議的，有誰能夠開發下。節點採用paxos的話，有個問題沒想清楚，paxos如何sql結合使用？另外節點的性能會受一點影響。下降一點要求吧，節點採用主主複製，或者環形複製吧。master檢查節點存活，而且作切換，通知客戶端。

架構以下所示 ，master, metadata,實現了paxos協議，也即經過paxos接口訪問;node的各個節點是複製關係，服務節點掛掉的時候，須要master檢測，而且作切換處理。

 

若是是分佈式系統，好比文件系統，或者本身開發的系統， 那節點能夠考慮用paxos協議哦。 每一個節點採用3個實例，或者你有資源，採用5個實例。

分佈式數據庫的sql實現

也是一個難點，即一個複雜的sql，如何實現？

 

•使用分庫分表的思想實現數據存儲
•使用mapred的思想實現sql計算


•將輸入sql通過詞法，語法，語義分析，集合表結構信息和數據分佈信息，生成包含多個階段(簡稱stage)的執行計劃，這些階段具備必定的依賴關係，造成多輸入單輸出的任務樹；
•每一個階段包括兩種sql，稱爲mapsql和redsql，另外每一個階段包括三個操做，map，數據洗牌和red；map和red分別執行mapsql和redsql；

子句的處理邏輯和處理順序 ：

1.union：分解每一個子句，單獨解析，造成平行關係
2.from：選擇表，能夠是選擇多張表，也但是join的狀況
3.join：from中若是包含join，就要考慮join的各類問題
4.where：單表，多表，join以後的where過濾條件
5.group：分組
6.select：選擇的列
7.distinct：去掉重複的行
8.having：聚合以後的過濾
9.order：將結果排序
10.limit offset：獲取最終結果的某些記錄
11.子查詢：遇到子查詢獨立解析，跟上層創建依賴關係

鏈接，包括內鏈接，左鏈接，右鏈接，半鏈接，外鏈接

以以下sql爲例：

某一註冊時間範圍內的用戶的全部登陸信息

select t1.u_id,t1.u_name,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id and t1.u_reg_dt>=? and t1.u_reg_dt<=?)

生成的執行計劃爲：

因爲是join，全部的表都要進行查詢操做，而且爲每張表打上本身的標籤，具體實施的時候能夠加個表名字字段，在全部存儲節點上執行

select u_id,u_name from tab_user_info t where u_reg_dt>=? and t1.u_reg_dt<=?

select u_id, login_product from tab_login_info t

執行完成以後，這種狀況下因爲須要按照u_id進行數據洗牌，考慮到u_id的惟一值比較多，因此各個存儲節點上須要按照u_id進行劃分，

例若有N個計算節點，那麼按照（最大u_id-最小u_id）/N平均劃分，將不一樣存儲節點上的同一範圍的u_id，劃分到同一個計算節點上

而後在計算節點上執行以下操做

select t1.u_id,t1.u_name,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id)

關於分佈式sql如何實現的問題，有不少未盡事宜。有興趣的能夠相互討論。歡迎切磋

 

 

 

 

幾點補充：

1.對於須要嚴格保證強一致的場合來講，至少在 MySQL 5.7 以前，DRBD 仍是有意義的。5.7 聽說能實現真同步複製，若真能實現，就再也不須要 DRBD 了。

2.網絡分區時的腦裂問題必須避免，應使用基於多數派的選舉算法來推選 Master。方案不少，好比用 ZooKeeper、etcd、Consul 等進行服務選舉，推選出 Master。

3.MHA 沒深刻了解過，但印象裏其 Master（Arbiter）節點貌似有單點問題？沒記錯的話此節點用於完成 MySQL 的主節點選舉工做，它本身不 HA 仍是有隱患。

 

 

 

MySQL大型分佈式集羣一、主要解決針對大型網站架構中持久化部分中，大量數據存儲以及高併發訪問所帶來是數據讀寫問題。分佈式是將一個業務拆分爲多個子業務，部署在不一樣的服務器上。集羣是同一個業務，部署在多個服務器上。

二、着重對數據切分作了細緻豐富的講解，從數據切分的原理出發，一步一步深刻理解數據的切分，經過深刻理解各類切分策略來設計和優化咱們的系統。這部分中咱們還用到了數據庫中間件和客戶端組件來進行數據的切分，讓廣大網友可以對數據的切分從理論到實戰都會有一個質的飛躍。

沒有人提到Atlas Atlas是由 Qihoo 360, Web平臺部基礎架構團隊開發維護的一個基於MySQL協議的數據中間層項目。它是在mysql-proxy 0.8.2版本的基礎上，對其進行了優化，增長了一些新的功能特性。360內部使用Atlas運行的mysql業務，天天承載的讀寫請求數達幾十億條。