Mysql集羣方案簡介

Mysql集羣方案簡介

集羣的好處

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

集羣要考慮的風險

• 網絡分裂：羣集還可能由於網絡故障而拆分爲多個部分，每部分內的節點相互連接，但各部分之間的節點失去連接。
• 腦裂：導致數據庫節點彼此獨立運行的集羣故障稱爲“腦裂”。這種情況可能導致數據不一致，並且無法修復，例如當兩個數據庫節點獨立更新同一表上的同一行時。

大致有6種方案

• mysql官方提供的方案
  • MySQL Replication
  • MySQL Fabirc
  • MySQL Cluster
• 第三方方案
  • MMM (Master Replication Manager for MySQL)
• 依託硬件的方案
  • 心跳檢測+SAN共享存儲
  • 心跳檢測+DRDB磁盤複製

mysql官方提供的方案

方案1：MySQL Replication

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

主從複製是通過重放binlog實現主庫數據的異步複製。即當主庫執行了一條sql命令，那麼在從庫同樣的執行一遍，從而達到主從複製的效果。

MySQL Replication是一主多從的結構，主要目的是實現數據的多點備份（沒有故障自動轉移和負載均衡）。

相比於單個的mysql，一主多從下的優勢如下：

• 1.讀寫分離，負載均衡

  如果讓後臺讀操作連接從數據庫，讓寫操作連接主數據庫，能起到讀寫分離的作用，這個時候多個從數據庫可以做負載均衡。

• 2.熱備份
  可以在某個從數據庫中暫時中斷複製進程，來備份數據，從而不影響主數據的對外服務（如果在master上執行backup，需要讓master處於readonly狀態，這也意味這所有的write請求需要阻塞）。

就各個集羣方案來說，其優勢爲：

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

其劣勢爲：

• 從庫要從binlog獲取數據並重放，這肯定與主庫寫入數據存在時間延遲，因此從庫的數據總是要滯後主庫。
• 對主庫與從庫之間的網絡延遲要求較高，若網絡延遲太高，將加重上述的滯後，造成最終數據的不一致。
• 單點故障問題：單一的主節點掛了，將不能對外提供寫服務。

方案2：MySQL Fabirc

mysql官方提供的，這是在MySQL Replication的基礎上，增加了故障檢測與轉移，自動數據分片功能。

不過依舊是一主多從的結構

MySQL Fabirc只有一個主節點，區別是當該主節點掛了以後，會從從節點中選擇一個來當主節點。

就各個集羣方案來說，其優勢爲：

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

其劣勢爲：

• 從庫要從binlog獲取數據並重放，這肯定與主庫寫入數據存在時間延遲，因此從庫的數據總是要滯後主庫。
• 對主庫與從庫之間的網絡延遲要求較高，若網絡延遲太高，將加重上述的滯後，造成最終數據的不一致。
• 事務及查詢只支持在同一個分片內，事務中更新的數據不能跨分片，查詢語句返回的數據也不能跨分片。
• 節點故障恢復30秒或更長（採用InnoDB存儲引擎的都這樣）。

分片：分片可以簡單定義爲將大數據庫分佈到多個物理節點上的一個分區方案。每一個分區包含數據庫的某一部分，稱爲一個片

分區：分區則是把一張表的數據分成 N 多個區塊，這些區塊可以在同一個磁盤上，也可以在不同的磁盤上。

方案3：MySQL Cluster

mysql官方提供的，多主多從結構

就各個集羣方案來說，其優勢爲：

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

其劣勢爲：

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

第三方方案

方案4：MMM (Master Replication Manager for MySQL)

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：心跳檢測+SAN共享存儲

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

就各個集羣方案來說，其優勢爲：

• 保證數據的強一致性；
• 與mysql解耦，不會由於mysql的邏輯錯誤發生數據不一致的情況；

其劣勢爲：

• SAN價格昂貴；

方案6：心跳檢測+DRDB磁盤複製

DRDB：這是linux內核板塊實現的快級別的同步複製技術。

通過各主機之間的網絡，複製對方磁盤的內容。

當客戶將數據寫入本地磁盤時，還會將數據發送到網絡中另一臺主機的磁盤上，這樣的本地主機(主節點)與遠程主機(備節點)的數據即可以保證明時同步。

就各個集羣方案來說，其優勢爲：

• 相比於SAN儲存網絡，價格低廉；
• 保證數據的強一致性；
• 與mysql解耦，不會由於mysql的邏輯錯誤發生數據不一致的情況；

其劣勢爲：

• 對io性能影響較大；
• 從庫不提供讀操作；