多圖文,詳細介紹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_lgx211

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到內存需要很長時間。

官方的三兄弟的區別對比如下圖所示;

官方三兄弟對比圖_lgx211

二,mysql第三方優化

4,MMM

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

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

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

就各個集羣方案來說,其優勢爲:

  • 自動的主主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_lgx211

就各個集羣方案來說,其優勢爲:

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

其劣勢爲:

  • MHA架構實現讀寫分離,最佳實踐是在應用開發設計時提前規劃讀寫分離事宜,在使用時設置兩個連接池,即讀連接池與寫連接池,也可以選擇折中方案即引入SQL Proxy。但無論如何都需要改動代碼;

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

6,Galera Cluster

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

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

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

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

MHA_lgx211

就各個集羣方案來說,其優勢爲:

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

其劣勢爲:

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

三,依託硬件配合

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

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

7,heartbeat+SAN

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

heartbeat+SAN_lgx211
就各個集羣方案來說,其優勢爲:

  • 保證數據的強一致性;

  • 與mysql解耦,不會由於mysql的邏輯錯誤發生數據不一致的情況;

其劣勢爲:

  • SAN價格昂貴;
8,heartbeat+DRDB

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

heartbeat+DRDB_lgx211
就各個集羣方案來說,其優勢爲:

  • 相比於SAN儲存網絡,價格低廉;

  • 保證數據的強一致性;

  • 與mysql解耦,不會由於mysql的邏輯錯誤發生數據不一致的情況;

其劣勢爲:

  • 對io性能影響較大;

  • 從庫不提供讀操作;

四,其它

9,Zookeeper + proxy

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

Zookeeper + proxy_lgx211
就各個集羣方案來說,其優勢爲:

  • 擴展性較好,可以擴展爲大規模集羣。

缺其劣勢爲:

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

分佈式一致性算法,Paxos 算法處理的問題是一個分佈式系統如何就某個值(決議)達成一致。這個算法被認爲是同類算法中最有效的。Paxos與MySQL相結合可以實現在分佈式的MySQL數據的強一致性。

Paxos_lgx211

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章