多圖文，詳細介紹mysql各個集羣方案

目錄

• 多圖文，詳細介紹mysql各個集羣方案
  • 一，mysql原廠出品
  • 二，mysql第三方優化
  • 三，依託硬件配合
  • 四，其它

多圖文，詳細介紹mysql各個集羣方案

集羣的好處

• 高可用性：故障檢測及遷移，多節點備份。
• 可伸縮性：新增數據庫節點便利，方便擴容。
• 負載均衡：切換某服務訪問某節點，分攤單個節點的數據庫壓力。

集羣要考慮的風險

• 網絡分裂：羣集還可能因爲網絡故障而拆分爲多個部分，每部份內的節點相互鏈接，但各部分之間的節點失去鏈接。
• 腦裂：致使數據庫節點彼此獨立運行的集羣故障稱爲「腦裂」。這種狀況可能致使數據不一致，而且沒法修復，例如當兩個數據庫節點獨立更新同一表上的同一行時。

@

一，mysql原廠出品

1，MySQL Replication

mysql複製（MySQL Replication），是mysql自帶的功能。

原理簡介：

主從複製是經過重放binlog實現主庫數據的異步複製。即當主庫執行了一條sql命令，那麼在從庫一樣的執行一遍，從而達到主從複製的效果。在這個過程當中，master對數據的寫操做記入二進制日誌文件中(binlog)，生成一個 log dump 線程，用來給從庫的 i/o線程傳binlog。而從庫的i/o線程去請求主庫的binlog，並將獲得的binlog日誌寫到中繼日誌（relaylog）中，從庫的sql線程，會讀取relaylog文件中的日誌，並解析成具體操做，經過主從的操做一致，而達到最終數據一致。

MySQL Replication一主多從的結構，主要目的是實現數據的多點備份（沒有故障自動轉移和負載均衡）。相比於單個的mysql，一主多從下的優點以下：

• 若是讓後臺讀操做鏈接從數據庫，讓寫操做鏈接主數據庫，能起到讀寫分離的做用，這個時候多個從數據庫能夠作負載均衡。
• 能夠在某個從數據庫中暫時中斷複製進程，來備份數據，從而不影響主數據的對外服務（若是在master上執行backup，須要讓master處於readonly狀態，這也意味這全部的write請求須要阻塞）。

就各個集羣方案來講，其優點爲：

• 主從複製是mysql自帶的，無需藉助第三方。
• 數據被刪除，能夠從binlog日誌中恢復。
• 配置較爲簡單方便。

其劣勢爲：

• 從庫要從binlog獲取數據並重放，這確定與主庫寫入數據存在時間延遲，所以從庫的數據老是要滯後主庫。
• 對主庫與從庫之間的網絡延遲要求較高，若網絡延遲過高，將加劇上述的滯後，形成最終數據的不一致。
• 單一的主節點掛了，將不能對外提供寫服務。

2，MySQL Fabirc

mysql織物（MySQL Fabirc），是mysql官方提供的。

這是在MySQL Replication的基礎上，增長了故障檢測與轉移，自動數據分片功能。不過依舊是一主多從的結構，MySQL Fabirc只有一個主節點，區別是當該主節點掛了之後，會從從節點中選擇一個來當主節點。

就各個集羣方案來講，其優點爲：

• mysql官方提供的工具，無需第三方插件。
• 數據被刪除，能夠從binlog日誌中恢復。
• 主節點掛了之後，可以自動從從節點中選擇一個來當主節點，不影響持續對外提供寫服務。

其劣勢爲：

• 從庫要從binlog獲取數據並重放，這確定與主庫寫入數據存在時間延遲，所以從庫的數據老是要滯後主庫。
• 對主庫與從庫之間的網絡延遲要求較高，若網絡延遲過高，將加劇上述的滯後，形成最終數據的不一致。
• 2014年5月推出的產品，數據庫資歷較淺，應用案例很少，網上各類資料相對較少。
• 事務及查詢只支持在同一個分片內，事務中更新的數據不能跨分片，查詢語句返回的數據也不能跨分片。
• 節點故障恢復30秒或更長（採用InnoDB存儲引擎的都這樣）。

3，MySQL Cluster

mysql集羣（MySQL Cluster）也是mysql官方提供的。

MySQL Cluster是多主多從結構的

就各個集羣方案來講，其優點爲：

• mysql官方提供的工具，無需第三方插件。
• 高可用性優秀，99.999%的可用性，能夠自動切分數據，能跨節點冗餘數據（其數據集並非存儲某個特定的MySQL實例上，而是被分佈在多個Data Nodes中，即一個table的數據可能被分散在多個物理節點上，任何數據都會在多個Data Nodes上冗餘備份。任何一個數據變動操做，都將在一組Data Nodes上同步，以保證數據的一致性）。
• 可伸縮性優秀，能自動切分數據，方便數據庫的水平拓展。
• 負載均衡優秀，可同時用於讀操做、寫操做都都密集的應用，也可使用SQL和NOSQL接口訪問數據。
• 多個主節點，沒有單點故障的問題，節點故障恢復一般小於1秒。

其劣勢爲：

• 架構模式和原理很複雜。
• 只能使用存儲引擎 NDB ，與日常使用的InnoDB 有不少明顯的差距。好比在事務（其事務隔離級別只支持Read Committed，即一個事務在提交前，查詢不到在事務內所作的修改），外鍵（雖然最新的NDB 存儲引擎已經支持外鍵，但性能有問題，由於外鍵所關聯的記錄可能在別的分片節點），表限制上的不一樣，可能會致使平常開發出現意外。點擊查看具體差距比較
• 做爲分佈式的數據庫系統，各個節點之間存在大量的數據通信，好比全部訪問都是須要通過超過一個節點（至少有一個 SQL Node和一個 NDB Node）才能完成，所以對節點之間的內部互聯網絡帶寬要求高。
• Data Node數據會被儘可能放在內存中，對內存要求大，並且重啓的時候，數據節點將數據load到內存須要很長時間。

官方的三兄弟的區別對好比下圖所示；

二，mysql第三方優化

4，MMM

MMM是在MySQL Replication的基礎上，對其進行優化。

MMM（Master Replication Manager for MySQL）是雙主多從結構，這是Google的開源項目，使用Perl語言來對MySQL Replication作擴展，提供一套支持雙主故障切換和雙主平常管理的腳本程序，主要用來監控mysql主主複製並作失敗轉移。

注意：這裏的雙主節點，雖然叫作雙主複製，可是業務上同一時刻只容許對一個主進行寫入，另外一臺備選主上提供部分讀服務，以加速在主主切換時刻備選主的預熱。

就各個集羣方案來講，其優點爲：

• 自動的主主Failover切換，通常3s之內切換備機。
• 多個從節點讀的負載均衡。

其劣勢爲：

• 沒法徹底保證數據的一致性。如主1掛了，MMM monitor已經切換到主2上來了，而若此時雙主複製中，主2數據落後於主1（即還未徹底複製完畢），那麼此時的主2已經成爲主節點，對外提供寫服務，從而致使數據不一。
• 因爲是使用虛擬IP浮動技術，相似Keepalived，故RIP（真實IP）要和VIP（虛擬IP）在同一網段。若是是在不一樣網段也能夠，須要用到虛擬路由技術。可是絕對要在同一個IDC機房，不可跨IDC機房組建集羣。

5，MHA

MHA是在MySQL Replication的基礎上，對其進行優化。

MHA（Master High Availability）是多主多從結構，這是日本DeNA公司的youshimaton開發，主要提供更多的主節點，可是缺乏VIP（虛擬IP），須要配合keepalived等一塊兒使用。

要搭建MHA，要求一個複製集羣中必須最少有三臺數據庫服務器，一主二從，即一臺充當master，一臺充當備用master，另一臺充當從庫。

就各個集羣方案來講，其優點爲：

• 能夠進行故障的自動檢測和轉移
• 具有自動數據補償能力，在主庫異常崩潰時可以最大程度的保證數據的一致性。

其劣勢爲：

• MHA架構實現讀寫分離，最佳實踐是在應用開發設計時提早規劃讀寫分離事宜，在使用時設置兩個鏈接池，即讀鏈接池與寫鏈接池，也能夠選擇折中方案即引入SQL Proxy。但不管如何都須要改動代碼；

• 關於讀負載均衡可使用F五、LVS、HAPROXY或者SQL Proxy等工具，只要能實現負載均衡、故障檢查及備升級爲主後的讀寫剝離功能便可，建議使用LVS

6，Galera Cluster

Galera Cluster是由Codership開發的MySQL多主結構集羣，這些主節點互爲其它節點的從節點。不一樣於MySQL原生的主從異步複製，Galera採用的是多主同步複製，並針對同步複製過程當中，會大機率出現的事務衝突和死鎖進行優化，就是複製不基於官方binlog而是Galera複製插件，重寫了wsrep api。

異步複製中，主庫將數據更新傳播給從庫後當即提交事務，而不論從庫是否成功讀取或重放數據變化。這種狀況下，在主庫事務提交後的短期內，主從庫數據並不一致。

同步複製時，主庫的單個更新事務須要在全部從庫上同步 更新。換句話說，當主庫提交事務時，集羣中全部節點的數據保持一致。

對於讀操做，從每一個節點讀取到的數據都是相同的。對於寫操做，當數據寫入某一節點後，集羣會將其同步到其它節點。

就各個集羣方案來講，其優點爲：

• 多主多活下，可對任一節點進行讀寫操做，就算某個節點掛了，也不影響其它的節點的讀寫，都不須要作故障切換操做，也不會中斷整個集羣對外提供的服務。
• 拓展性優秀，新增節點會自動拉取在線節點的數據（當有新節點加入時，集羣會選擇出一個Donor Node爲新節點提供數據），最終集羣全部節點數據一致，而不須要手動備份恢復。

其劣勢爲：

• 能作到數據的強一致性，毫無疑問，也是以犧牲性能爲代價。

三，依託硬件配合

不一樣主機的數據同步再也不依賴於MySQL的原生複製功能，而是經過同步磁盤數據，來保證數據的一致性。

而後處理故障的方式是藉助Heartbeat，它監控和管理各個節點間鏈接的網絡，並監控集羣服務，當節點出現故障或者服務不可用時，自動在其餘節點啓動集羣服務。

7，heartbeat+SAN

SAN：共享存儲，主庫從庫用的一個存儲。SAN的概念是容許存儲設施和解決器（服務器）之間創建直接的高速鏈接，經過這種鏈接實現數據的集中式存儲。

就各個集羣方案來講，其優點爲：

• 保證數據的強一致性；

• 與mysql解耦，不會因爲mysql的邏輯錯誤發生數據不一致的狀況；

其劣勢爲：

• SAN價格昂貴；

8，heartbeat+DRDB

DRDB：這是linux內核板塊實現的快級別的同步複製技術。經過各主機之間的網絡，複製對方磁盤的內容。當客戶將數據寫入本地磁盤時，還會將數據發送到網絡中另外一臺主機的磁盤上，這樣的本地主機(主節點)與遠程主機(備節點)的數據便可以保證實時同步。

就各個集羣方案來講，其優點爲：

• 相比於SAN儲存網絡，價格低廉；

• 保證數據的強一致性；

• 與mysql解耦，不會因爲mysql的邏輯錯誤發生數據不一致的狀況；

其劣勢爲：

• 對io性能影響較大；

• 從庫不提供讀操做；

四，其它

9，Zookeeper + proxy

Zookeeper使用分佈式算法保證集羣數據的一致性，使用zookeeper能夠有效的保證proxy的高可用性，能夠較好的避免網絡分區現象的產生。

就各個集羣方案來講，其優點爲：

• 擴展性較好，能夠擴展爲大規模集羣。

缺其劣勢爲：

• 搭建Zookeeper 集羣，在配置一套代理，整個系統的邏輯變得更加複雜。

10，Paxos

分佈式一致性算法，Paxos 算法處理的問題是一個分佈式系統如何就某個值（決議）達成一致。這個算法被認爲是同類算法中最有效的。Paxos與MySQL相結合能夠實如今分佈式的MySQL數據的強一致性。