MySQL中常見的高可用架構部署方案有哪些

MySQL 中的叢集部署方案

前言

這裡來聊聊，MySQL 中常用的部署方案。

MySQL Replication

MySQL Replication 是官方提供的主從同步方案，用於將一個 MySQL 的實例同步到另一個實例中。 Replication 為確保資料安全做了重要的保證，是目前運用最廣的 MySQL 容災方案。 Replication 以兩個或以上的實例建構了 MySQL 主從複製集群，提供單點寫入，多點讀取的服務，實現了讀的 scale out。

上面的栗子，一個主庫(M)，三個從庫(S)，透過replication，Master 產生event 的binlog，然後發給slave，Slave 將event 寫入relaylog，然後將其提交到自身資料庫中，實現主從資料同步。

對於資料庫之上的業務層來說，基於MySQL 的主從複製集群，單點寫入Master ,在event 同步到Slave 後，讀邏輯可以從任何一個Slave 讀取數據，以讀寫入分離的方式，大幅降低Master 的運作負載，同時提升了Slave 的資源利用。

優點：

1、透過讀寫分離實現橫向擴展的能力，寫入和更新操作在來源伺服器上進行，從伺服器中進行資料的讀取操作，透過增大從伺服器的個數，能夠極大的增強資料庫的讀取能力；

2、資料安全，因為副本可以暫停複製過程，所以可以在副本上運行備份服務而不會破壞相應的來源數據；

3、方便進行數據分析，可以在寫庫中創建實時數據，數據的分析操作在從庫中進行，不會影響到源數據庫的性能；

#實現原理

在主從複製中，從庫利用主庫上的binlog 進行重播，實現主從同步，複製的過程中蛀主要使用到了dump thread，I/O thread，sql thread 這三個線程。

IO thread: 在從庫執行start slave 語句時創建，負責連接主庫，請求binlog，接收binlog 並寫入relay-log；

dump thread：用於主庫同步binlog 給從庫，負責回應從IO thread 的請求。主庫會為每個從庫的連接建立一個dump thread，然後同步binlog 給從庫；

sql thread：讀取relay log 執行命令實作從庫資料的更新。

來看下複製的流程：

1、主庫收到更新指令，執行更新操作，產生binlog;

2、從庫在主從之間建立長連線；

3、主庫dump_thread 從本機讀取binlog 傳送剛給從庫；

4、從主庫取得到binlog 後儲存到本機，成為relay log（中繼日誌）；

5、sql_thread 執行緒讀取relay log 解析、執行指令更新資料。

不過 MySQL Replication 有個嚴重的缺點就是主從同步延遲。

因為資料是進行主從同步的，那麼就會遇到主從同步延遲的情況。

為什麼會出現主從延遲？

1、從庫機器的效能比主庫差；

2、從庫的壓力大；

大量查詢放在從庫上，可能會導致從庫上耗費了大量的CPU 資源，進而影響了同步速度，造成主從延遲。

3、大事務的執行；

有事務產生的時候，主庫必須要等待事務完成之後才能寫入到binlog，假定執行的事務是一個非常大的資料插入，這些資料傳輸到從庫，從庫同步這些資料也需要一定的時間，就會導致從節點出現資料延遲。

4、從庫的複製能力較差；

當從庫的複製能力低於主庫時，主庫寫入壓力較大時可能會導致從庫出現長時間數據延遲。

如何解決？

1、最佳化業務邏輯，避免出現多執行緒大事務的並發場景；

2、提高從庫的機器效能，減少主庫寫binlog 和從庫讀binlog 的效率差;

3、保證主庫和從庫的網路連接，避免網路延遲導致的binlog 傳輸延遲；

4、強行讀取主庫；

5、配合semi-sync 半同步複製；

semi-sync 半同步複製

MySQL 有三種同步模式，分別是：

1、非同步複製：MySQL 中預設的複製是異步的，主庫在執行完客戶端提交的事務後會立即將結果傳回給客戶端，並不關心從庫是否已經接收並且處理。存在問題就是，如果主庫的日誌沒有及時同步到從庫，然後主庫宕機了，這時候執行故障轉移，在從庫衝選主，可能會存在選出的主庫中資料不完整；

2、全同步複製：指當主庫執行完一個事務，並且等到所有從庫也執行完成這個事務的時候，主庫在提交事務，並且返回資料給客戶端。因為要等待所有從庫都同步到主庫中的數據才返回數據，所以能夠保證主從數據的一致性，但是數據庫的性能必然受到影響；

3、半同步複製：是介於全同步和全異步同步的一種，主庫至少需要等待一個從庫接收並寫入到Relay Log 檔案即可，主庫不需要等待所有從庫到主庫返回ACK。主庫收到 ACK ，標識這個事務完成，回傳資料給客戶端。

MySQL 中預設的複製是異步的，所以主函式庫和從函式庫的同步會存在一定的延遲，更重要的是非同步複製也可能造成資料的遺失。全同步複製的效能又太差了，所以從 MySQL 5.5 開始，MySQL 以插件的形式支援 semi-sync 半同步複製。

半同步複製潛在的問題

在傳統的半同步複製中，主庫寫資料到 binlog，並且執行 commit 提交交易後，會一直等待一個從庫的 ACK。從庫會在寫入 Relay Log 後，將資料落盤，然後回覆主庫 ACK，主庫收到這個 ACK 才能給客戶端事務完成的確認。

這樣會存在問題就是，主庫已經將該事務的commit 儲存到了引擎層，應用程式已經可以看到資料的變化了，只是在等待從庫的返回，如果此時主庫宕機，可能從庫還沒有寫入Relay Log，就會發生主從庫資料不一致。

為了解決這個問題，MySQL 5.7 引入了增強半同步複製。主庫寫入資料到binlog 後，就開始等待從庫的應答ACK，直到至少一個從庫寫入Relay Log 後，並將資料落盤，然後傳回主庫ACK，通知主庫可以進行commit 操作，然後主庫再將事務提交到事務引擎，應用此時才能看到資料的變化。

不過看下來增強半同步複製，在同步給從庫之後，因為自己的資料還沒提交，然後宕機了，主庫中也是會存在資料的遺失，不過應該想到的是，這時候主庫宕機了，是會重新在從庫中選主的，這樣新選出的主庫資料是沒有發生遺失的。

MySQL Group Replication

MySQL Group Replication 群組複製，又稱為 MGR。是 Oracle MySQL 於 2016 年 12 月發布 MySQL 5.7.17 推出的一個全新高可用和高擴充的解決方案。

引入複製組主要是為了解決傳統非同步複製和半同步複製可能產生資料不一致的問題。

MGR 由若干節點共同組成一個複製組，一個事務的提交，必須經過組內大多數節點 (N / 2 1) 決議並通過，才能得以提交。

當客戶端發起更新事務時，該事務先在本地執行，執行完成之後就要發起對事務的提交操作。需要在實際提交之前，將所產生的複製寫集廣播給其他成員進行複製。群組中的成員只有在接收到事務廣播時，才能全部接收或全部不接收，因為事務是原子性廣播。如果群組中的所有成員收到了該廣播訊息(事務)，那麼他們會按照先前發送事務的相同順序收到該廣播訊息。因此，所有的組成員都會按照相同的順序接收事務的寫集，並為該事務建立全域順序。因此，所有的組成員都會按照相同的順序接收事務的寫集，並為該事務建立全域順序。

在不同群組成員並發執行的事務可能存在衝突。衝突是透過檢查和比較兩個不同並發事務的 write set 來驗證的，這個過程稱為認證。在認證期間，衝突檢測在行級別執行的：如果在不同組成員上執行的兩個並發事務更新了同一行數據，則存在衝突。根據衝突認證檢測機制判斷，依照順序，第一次提交的會正常執行，第二次提交的事務會在事務發起的原始組成員上執行回滾,，組中的其他成員對該事務執行刪除。如果兩個事務經常發生衝突，那麼最好將這兩個事務放在同一個組成員中執行，這樣它們在本地鎖管理器的協調下將都有機會提交成功，而不至於因為處在兩個不同的組員中由於衝突認證而導致其中一個事務被頻繁回滾。

最終，所有群組內成員以相同的順序接收同一組事務。為了確保組內資料的強一致性，組內成員需要按照相同的順序進行相同的修改操作。

有以下的幾個特性：

1、避免腦裂：MGR 中不會出現腦裂的現象；

2、資料一致性保障：MGR 的冗餘能力很好，能夠保證Binlog Event 至少被複製到超過一半的成員上，只要同時宕機的成員不超過半數便不會導致資料遺失。 MGR也保證只要Binlog Event 沒有被傳輸到半數以上的成員，本地成員不會將事務的Binlog Event 寫入Binlog 檔案和提交事務，從而保證宕機的伺服器上不會有組內在線成員上不存在的資料。因此，當機的伺服器重新啟動後，不再需要特殊的處理就可以加入群組；

3、多節點寫入支援：多寫模式下支援叢集中的所有節點都可以寫入。

群組複製的應用場景

1、彈性複製：需要非常靈活的複製基礎設施的環境，其中MySQL Server的數量必須動態增加或減少，並且在增加或減少Server的過程中，對業務的副作用盡可能少。例如，雲端資料庫服務；

2、高可用分片：分片是實現寫入擴充的一種流行方法。基於組複製實現的高可用分片，其中每個分片都會映射到一個複製組上（邏輯上需要一一對應，但在物理上，一個複製組可以承載多個分片）；

3、替代主從複製：在某些情況下，使用一個主庫會造成單點爭用。在一些場景下，將資料同時寫入群組中多個成員，能為應用程式帶來更好的可擴展性

4、自治系統：可以利用群組複製內建的自動故障轉移、數據在不同組成員之間的原子廣播和最終資料一致性的特性來實現一些運維自動化。

InnoDB Cluster

InnoDB Cluster 是官方提供的高可用方案,是MySQL 的一種高可用性(HA)解決方案，它透過使用MySQL Group Replication 來實現資料的自動複製和高可用性，InnoDB Cluster 通常包含下面三個關鍵元件：

1、MySQL Shell: 它是MySQL 的高階管理用戶端;

2、MySQL Server 和MGR，讓一組MySQL 實例能夠提供高可用性，對於MGR，Innodb Cluster 提供了一種更容易編程的方式來處理MGR;

3、MySQL Router，一種輕量級中間件，主要進行路由請求，將客戶端傳送過來的請求路由到不同的MySQL 伺服器節點。

MySQL Server 基於 MySQL Group Replication 構建，提供自動成員管理，容錯，自動故障轉移動能等。 InnoDB Cluster 通常以單主模式運行，一個讀寫實例和多個只讀實例。不過也可以選用多主模式。

優點：

1、高可用性：透過MySQL Group Replication，InnoDB Cluster 能夠實現資料在叢集中的自動複製，從而保證資料的可用性；

2、簡單易用：InnoDB Cluster 提供了一個簡單易用的管理介面，使得管理員可以快速部署和管理叢集；

3.全自動故障轉移: InnoDB Cluster 能夠自動偵測和診斷故障，並進行必要的故障轉移，使得資料可以繼續可用。

缺點：

1、複雜性：InnoDB Cluster 的部署和管理比較複雜，需要對MySQL 的工作原理有一定的了解；

2、效能影響：由於自動複製和高可用性的要求，InnoDB Cluster 可能對MySQL 的效能造成一定的影響；

3、限制：InnoDB Cluster 的功能對於一些特殊的應用場景可能不夠靈活，需要更多的客製化。

InnoDB ClusterSet

MySQL InnoDB ClusterSet 透過將主InnoDB Cluster 與其在備用位置（例如不同資料中心）的一個或多個副本連結起來，為InnoDB Cluster 部署提供容災能力。

InnoDB ClusterSet 使用專用的 ClusterSet 複製通道自動管理從主叢集到副本叢集的複製。如果主集群因資料中心損壞或網路連線遺失而變得無法使用，使用者可以啟動副本叢集以恢復服務的可用性。

InnoDB ClusterSet 的特性：

#1、主叢集和副本叢集之間的緊急故障轉移可以由管理員透過MySQL Shell，使用AdminAPI 進行操作；

2、InnoDB ClusterSet 部署中可以擁有的副本叢集的數量沒有定義的限制；

3、非同步複製通道將交易從主集群複製到副本集群。 clusterset_replication 在InnoDB ClusterSet 建立過程中，在每個叢集上都設定了名為ClusterSet 的複製通道，當叢集是副本時，它使用該通道從主叢集複製事務。底層群組複製技術管理通道並確保複製始終在主集群的主伺服器（作為發送方）和副本集群的主伺服器（作為接收方）之間進行；

4、每個InnoDB ClusterSet 集群，只有主集群能夠接收寫入請求，大多數的讀取請求流量也會被路由到主集群，不過也可以指定讀取請求到其他的集群；

InnoDB ClusterSet 的限制：

1、InnoDB ClusterSet 只支援非同步複製，不能使用半同步複製，無法避免非同步複製的缺陷：資料延遲、資料一致性等；

2、InnoDB Cluster Set只支援單主模式的Cluster實例，不支援多主模式。即只能包含一個讀寫主集群, 所有副本集群都是唯讀的, 不允許具有多個主集群的雙活設置，因為在集群發生故障時無法保證數據一致性；

3 、已有的InnoDB Cluster 不能用作InnoDB ClusterSet 部署中的副本叢集。為了建立一個新的 InnoDB 集群，副本集群必須從單一伺服器實例啟動

4、只支援 MySQL 8.0。

InnoDB ReplicaSet

InnoDB ReplicaSet 是MySQL 團隊在2020 年推出的產品，用來幫助使用者快速部署和管理主從複製，在資料庫層仍然使用的是主從複製技術。

InnoDB ReplicaSet 由單一主節點和多個輔助節點（傳統上稱為 MySQL 複製來源和副本）組成。

與 InnoDB cluster 類似, MySQL Router 支援針對InnoDB ReplicaSet 的引導, 這表示可以自動設定MySQL Router 以使用InnoDB ReplicaSet, 而無需手動設定檔. 這使得InnoDB ReplicaSet 成為一種快速簡便的方法, 可以啟動和運行MySQL 複製和MySQL Router, 非常適合擴展讀取, 並在不需要InnoDB 叢集提供高可用性的用例中提供手動故障轉移功能。

InnoDB ReplicaSet 的限制：

1、沒有自動故障轉移，在主節點不可用的情況下，需要使用AdminAPI 手動觸發故障轉移，然後才能再次進行任何變更。但是，輔助實例仍可用於讀取；

2、由於意外停止或不可用，無法防止部分資料遺失：在意外停止時未完成的交易可能會遺失；

#3 、在意外退出或不可用後無法防止不一致。如果手動故障轉移提升了一個輔助實例，而前一個主實例仍然可用，例如，由於網路分區，裂腦情況可能會導致資料不一致；

4、InnoDB ReplicaSet 不支援多主模式。允許寫入所有成員的經典複製拓撲無法保證資料一致性；

5、讀取橫向擴展是有限的。 InnoDB ReplicaSet 是基於非同步複製，因此無法像 Group Replication 那樣調整流量控制；

6、一個 ReplicaSet 最多由一個主實例組成。支援一個或多個輔助。儘管可以加入到 ReplicaSet 的輔助節點的數量沒有限制，但連接到 ReplicaSet 的每個 MySQL Router 都必須監視每個執行個體。因此，一個 ReplicaSet 中加入的實例越多，監控就越多。

使用 InnoDB ReplicaSets 的主要原因是你有更好的寫入效能。使用 InnoDB ReplicaSets 的另一個原因是它們允許在不穩定或慢速網路上部署，而 InnoDB Cluster 則不允許。

MMM

MMM（Master-Master replication manager for MySQL）是一套支援雙主故障切換和雙主日常管理的腳本程式。 MMM 使用 Perl 語言開發，主要用來監控和管理 MySQL Master-Master（雙主）複製，可以說是 MySQL 主主複製管理器​​。

雙主模式，業務上同一時刻只能一個主庫進行資料的寫入。另一個主備庫，會在主伺服器失效時，進行主備切換與故障轉移。

MMM 中是透過一個 VIP(虛擬 IP) 的機制來確保叢集的高可用的。整個叢集中，在主節點會提供一個 VIP 位址來提供資料讀寫服務，當發生故障的時候，VIP 就會從原來的主節點便宜到其他節點，由其他節點提供服務。

MMM無法完全的保證資料一致性，所以適用於對資料的一致性要求不是很高的場景。 （因為主備上的資料不一定是最新的，可能還沒從函式庫的新。解決方法：開啟半同步）。

MMM 的優缺點

優點：高可用性，擴展性好，出現故障自動切換，對於主主同步，在同一時間只提供一台資料庫寫入操作，確保資料的一致性。

缺點：無法完全保資料的一致性，建議採用半同步複製方式，減少失敗的機率；目前 MMM 社群已經缺少維護，不支援基於 GTID 的複製。

適用場景：

MMM的適用場景為資料庫存取量大，業務成長快，並且能實現讀寫分離的場景。

MHA

Master High Availability Manager and Tools for MySQL，簡稱 MHA 。這是一套優秀的高可用軟體，用於在 MySQL 高可用性環境下進行故障切換和主從提升。

這個工具專門用來監控主庫的狀態，當發現master 節點故障的時候，會自動提升其中擁有新資料的slave 節點成為新的master 節點，在此期間,MHA 會透過其他從節點獲取額外的資訊來避免資料一致性問題。 MHA還提供了一個在線切換Master-Slave節點的功能，可以根據需要進行切換。 MHA可在30秒內實現故障轉移，同時最大程度確保資料一致性。

MHA 由兩個部分組成；

MHA Manager（管理節點）和MHA Node（資料節點）。

MHA Manager 可以單獨部署在一台獨立的機器上管理多個 master-slave 集群，也可以部署在一台 slave節點上。 MHA Node 運行在每台MySQL 伺服器上，MHA Manager 會定時偵測叢集中的master 節點，當master 發生故障時，它可以自動將最新資料的slave 提升為新的master，然後將所有其他的slave 重新指向新的master。

整個故障轉移過程對應用程式完全透明。

在 MHA 自動故障切換過程中，MHA 試圖從宕機的主伺服器上最大限度的保存二進位日誌，最大程度的保證資料的不遺失，但這並不總是可行的。例如，主伺服器硬體故障或無法透過 ssh 訪問，MHA 沒法保存二進位日誌，只進行故障轉移而遺失了最新的資料。

使用 MySQL 5.5 開始找支援的半同步複製，可以大幅降低資料遺失的風險。 MHA可以與半同步複製結合。如果只有一個 slave 已經收到了最新的二進位日誌，MHA 可以將最新的二進位日誌套用到其他所有的 slave 伺服器上，因此可以確保所有節點的資料一致性。

目前MHA 主要支援一主多從的架構，要搭建MHA,要求一個複製集群中必須最少有三台資料庫伺服器，一主二從，即一台master，一台充當備用master，另外一台充當從庫，因為至少需要三台伺服器。

MHA 工作原理摘要如下：

1、從宕機崩潰的master 儲存二進位日誌事件（binlog events）；

2、辨識最新更新的slave；

3、套用差異的中繼日誌(relay log) 到其他slave;

#4、套用從master保存的二進位日誌事件(binlog events);

##5、提升一個slave 為新master；

6、使用其他的slave 連接新的master 進行複製。

優點：

1、可以支援基於GTID 的複製模式；

#2、MHA 在進行故障轉移時更不易產生資料遺失；

3.同一個監控節點可以監控多個叢集。

缺點：

1、需要編寫腳本或利用第三方工具來實現Vip 的設定；

2、MHA 啟動後只會監控主資料庫；

3、需要基於SSH 免認證配置，有一定的安全隱患。

Galera Cluster

Galera Cluster 是由Codership 開發的MySQL多主集群，包含在MariaDB 中，同時支援Percona xtradb、MySQL，是一個易於使用的高可用解決方案，在資料完整性、可擴展性和高效能方面都有可接受的表現。

本身俱有 multi-master 特性，支援多點寫入，Galera Cluster 中每個實例都是對等的，互為主從。當客戶端讀寫資料的時候，可以選擇任一 MySQL 實例，對於讀取操作，每個實例讀取到的資料都是相同的。對於寫入操作，當資料寫入某一節點後，叢集會將其同步到其它節點。這種架構不共享任何數據，是一種高冗餘架構。

主要功能

1、同步複製；

2、真正的multi-master，也就是所有節點可以同時讀寫資料庫；

3、自動的節點成員控制，失效節點自動被清除；

4、新節點加入資料自動複製；

5、真正的平行複製，行級；

6、使用者可以直接連結集群，使用感受上與MySQL 完全一致。

優勢

1、資料一致：同步複製保證了整個叢集的資料一致性，無論何時在任何節點執行相同的select查詢，結果都一樣；

2、高可用性：由於所有節點數據一致，單一節點崩潰不需要執行複雜耗時的故障切換，也不會造成遺失資料或停止服務；

3、效能改進：同步複製允許在叢集中的所有節點上並行執行事務，從而提高讀寫效能；

4、更小的客戶端延遲；

5、同時具有讀取和寫入的擴展能力。

分析下原理

Galera Cluster 中主要用到了同步複製，主庫中的單一更新事務需要在所有從庫中同步更新，當主庫提交事務，集群中的所有節點資料保持一致。

非同步複製，主庫將資料更新傳播給從庫後立即提交事務，而不論從庫是否成功讀取或重播資料變化，所以非同步複製會存在短暫的，主從資料同步不一致的情況出現。

不過同步複製的缺點也是很明顯的，同步複製協定通常使用兩階段提交或分散式鎖協調不同節點的操作，也及時說節點越多需要協調的節點也就越多，那麼事務衝突和死鎖的機率也會隨之增加。

我們知道MGR 群組複製的引入也是為了解決傳統非同步複製和半同步複製可能產生資料不一致的問題，MGR 中的群組複製，基於Paxos 協議，原則上事務的提交，主要大多數節點ACK 就可以提交了。

Galera Cluster 中的同步需要同步資料到所有節點，保證所有節點都成功。基於專有通訊組系統 GCommon ,所有節點都必須有 ACK。

Galera 複製是一種基於驗證的複製，基於驗證的複製使用通訊和排序技術實現同步複製，透過廣播並發事務之間建立的全域總序來協調事務提交。簡單的講就是事務必須以相同的順序應用於所有實例。

事務現在本地執行，然後發送的其他節點做衝突驗證，沒有衝突的時候所有節點提交事務，否則在所有節點回滾。

當客戶端發出commit 命令時，在實際提交之前，對資料所做的更改都會收集到一個寫集合中，寫集合中包含事務資訊和所更改行的主鍵，資料庫將寫集傳送到其它節點。

節點以寫入集中的主鍵與目前節點中未完成事務的所有寫集的主鍵比較，確定節點是否可以提交事務，同時滿足下面三個條件會被任務存在衝突，驗證失敗：

1、兩個交易來自不同節點；

2、兩個事務包含相同的主鍵；

3、舊事務對新事務不可見，即舊事務未提交完成。新舊事務的劃定依賴於全域事務總序，即 GTID。

每個節點獨立進行驗證，如果驗證失敗，節點將刪除寫集並回滾原始事務，所有節點都會執行相同的操作。所有節點都按照相同順序接收事務，導致它們都做出相同的結果決定，要么全部成功，要么全部失敗。成功後自然就提交了，所有的節點又會重新達到資料一致的狀態。節點之間不交換「是否衝突」的訊息，各節點獨立非同步處理事務。

MySQL Cluster

MySQL Cluster 是一個高度可擴展的，相容於ACID 交易的即時資料庫，基於分散式架構不存在單點故障，MySQL Cluster 支援自動水平擴容，並且能做自動的讀寫負載平衡。

MySQL Cluster 使用了一個叫做 NDB 的記憶體儲存引擎來整合多個 MySQL 實例，提供一個統一的服務叢集。

NDB是採用不共享的Sharding-Nothing架構的記憶體儲存引擎。 Sarding-Nothing 指的是每個節點有獨立的處理器，磁碟和內存，節點之間沒有共享資源完全獨立互不干擾，節點之間通過告訴網絡組在一起，每個節點相當於一個小型的數據庫，儲存部分資料。這種架構的好處是可以利用節點的分佈性並行處理數據，調高整體的效能，還有就是有很高的水平擴展效能，只需要增加節點就能增加資料的處理能力。

MySql Cluster 中包含三種節點，分別是管理節點(NDB Management Server)、資料節點(Data Nodes)和SQL查詢節點( SQL Nodes) 。

SQL Nodes 是應用程式的接口，像普通的 mysqld 服務一樣，接受使用者的 SQL 輸入，執行並傳回結果。 Data Nodes 是資料儲存節點，NDB Management Server 用來管理叢集中的每個 node。

其中資料節點會儲存叢集中的資料分區和分區的副本，來看下MySql Cluster 是如何對資料進行分片的操作的，首先來了解下下面幾個概念

節點群組（Node Group）： 一組資料節點的集合。節點組的個數=節點數/ 副本數；

例如有群集中4 個節點，副本數為2（對應NoOfReplicas 的設定），那麼節點組個數為2 。

另外，在可用性方面，資料的副本在群組內交叉分配，一個節點群組內只有要一台機器可用，就可以保證整個叢集的資料完整性，實現服務的整體可用。

分區（Partition）：MySql Cluster 是一個分散式的儲存系統，資料依照分割區分割成多份儲存在各資料節點中，分割個數由系統自動計算，分區數= 資料節點數/ LDM 執行緒數;

副本（Replica）：分區資料的備份，有幾個分區就有幾個副本，為了避免單點，保證MySql Cluster 叢集的高可用，原始資料對應的分區和副本通常會保存在不同的主機上，在一個節點群組內進行交叉備份。

栗如，上面的例子，有四個資料節點（使用ndbd），副本數為2的集群，節點組被分成2組（4/2 ），資料分為4個分區，資料分配情況如下:

分區0（Partition 0）保存在節點組0（Node Group 0）中，分區資料(主副本— Primary Replica)保存在節點1(node 1) 中，備份資料(備份副本，Backup Replica)保存在節點2(node 2) 中；

分區1（Partition 1）保存在節點組1（Node Group 1）中，分區資料(主副本— Primary Replica)保存在節點3(node 3) 中，備份資料(備份副本，Backup Replica)保存在節點4(node 4) 中；

分區2（ Partition 2）保存在節點組0（Node Group 0）中，分區資料(主副本— Primary Replica)保存在節點2(node 2) 中，備份資料(備份副本，Backup Replica)保存在節點1(node 1) 中；

分區3（Partition 2）保存在節點組1（Node Group 1）中，分區資料(主副本— Primary Replica)保存在節點4(node 4) 中，備份數據(備份副本，Backup Replica)保存在節點3(node 3) 中；

這樣，對於一張表的一個Partition 來說，在整個集群有兩份數據，並分佈在兩個獨立的Node 上，實作了資料容災。同時，每次對一個 Partition 的寫入操作，都會在兩個 Replica 上呈現，如果 Primary Replica 異常，那麼 Backup Replica 可以立即提供服務，實現資料的高可用。

mysql cluster 的優點

1、99.999％的高可用性；

2、快速的自動失效切換；

# 3.靈活的分散式體系結構，沒有單點故障；

4、高吞吐量和低延遲；

5、可擴充性強，支援線上擴容。

mysql cluster 的缺點

1、有許多限制，例如：不支援外鍵，資料行不能超過8K（不包括BLOB和text中的資料） ;

2、部署、管理、配置很複雜；

3、佔用磁碟空間大，記憶體大；

4、備份和還原不方便；

5、重啟的時候，資料節點將資料load 到記憶體需要很長時間。

MySQL Fabric

MySQL Fabric 會組織多個MySQL 資料庫，將大的資料分散到多個資料庫中，也就是資料分片(Data Shard ),同時同一個分片資料庫中又是一個主從結構，Fabric 會挑選合適的庫作為主庫，當主庫掛掉的時候，又會重新在從庫中選出一個主庫。

MySQL Fabric 的特點：

1、高可用；

2、使用資料分片的橫向功能。

MySQL Fabric-aware 連接器將從MySQL Fabric 取得的路由資訊儲存到快取中，然後憑藉該資訊將交易或查詢傳送給正確的MySQL伺服器.

同時，每一個分片組，可以又多個一個伺服器組成，構成主從結構，當主庫掛掉的時候，又會重新在從庫中選出一個主庫。保證節點的高可用。

HA Group 保證存取指定HA Group 的資料總是可用的，同時其基礎的資料複製是基於MySQL Replication 實現的。

缺點

交易及查詢只支援在同一個分片內，交易中更新的資料不能跨分片，查詢語句傳回的資料也不能跨分片。

以上是MySQL中常見的高可用架構部署方案有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！