MySQL 中的集群部署方案

前言

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

MySQL Replication

MySQL Replication 是官方提供的主從同步方案，用于將一個 MySQL 的實例同步到另一個實例中。Replication 為保證數(shù)據(jù)安全做了重要的保證，是目前運用最廣的 MySQL 容災方案。Replication 用兩個或以上的實例搭建了 MySQL 主從復制集群，提供單點寫入，多點讀取的服務，實現(xiàn)了讀的 scale out。

上面的栗子，一個主庫(M)，三個從庫(S)，通過 replication，Master 生成 event 的 binlog，然后發(fā)給 slave，Slave 將 event 寫入 relaylog，然后將其提交到自身數(shù)據(jù)庫中，實現(xiàn)主從數(shù)據(jù)同步。

對于數(shù)據(jù)庫之上的業(yè)務層來說，基于 MySQL 的主從復制集群，單點寫入 Master ,在 event 同步到 Slave 后，讀邏輯可以從任何一個 Slave 讀取數(shù)據(jù)，以讀寫分離的方式，大大降低 Master 的運行負載，同時提升了 Slave 的資源利用。

優(yōu)點：

1、通過讀寫分離實現(xiàn)橫向擴展的能力，寫入和更新操作在源服務器上進行，從服務器中進行數(shù)據(jù)的讀取操作，通過增大從服務器的個數(shù)，能夠極大的增強數(shù)據(jù)庫的讀取能力；

2、數(shù)據(jù)安全，因為副本可以暫停復制過程，所以可以在副本上運行備份服務而不會破壞相應的源數(shù)據(jù)；

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

實現(xiàn)原理

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

IO thread: 在從庫執(zhí)行 start slave 語句時創(chuàng)建，負責連接主庫，請求 binlog，接收 binlog 并寫入 relay-log；

dump thread：用于主庫同步 binlog 給從庫，負責響應從 IO thread 的請求。主庫會給每個從庫的連接創(chuàng)建一個 dump thread，然后同步 binlog 給從庫；

sql thread：讀取 relay log 執(zhí)行命令實現(xiàn)從庫數(shù)據(jù)的更新。

來看下復制的流程：

1、主庫收到更新命令，執(zhí)行更新操作，生成 binlog;

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

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

4、從庫從主庫獲取到 binlog 后存儲到本地，成為 relay log（中繼日志）；

5、sql_thread 線程讀取 relay log 解析、執(zhí)行命令更新數(shù)據(jù)。

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

因為數(shù)據(jù)是進行主從同步的，那么就會遇到主從同步延遲的情況。

為什么會出現(xiàn)主從延遲？

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

2、從庫的壓力大；

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

3、大事務的執(zhí)行；

有事務產(chǎn)生的時候，主庫必須要等待事務完成之后才能寫入到 binlog，假定執(zhí)行的事務是一個非常大的數(shù)據(jù)插入，這些數(shù)據(jù)傳輸?shù)綇膸?，從庫同步這些數(shù)據(jù)也需要一定的時間，就會導致從節(jié)點出現(xiàn)數(shù)據(jù)延遲。

4、從庫的復制能力較差；

如果從庫的復制能力，低于主庫，那么在主庫寫入壓力很大的情況下，就會造成從庫長時間數(shù)據(jù)延遲的情況出現(xiàn)。

如何解決？

1、優(yōu)化業(yè)務邏輯，避免出現(xiàn)多線程大事務的并發(fā)場景；

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

3、保證主庫和從庫的網(wǎng)絡連接，避免出現(xiàn)網(wǎng)絡延遲導致的 binlog 傳輸延遲；

4、強行讀主庫；

5、配合 semi-sync 半同步復制；

semi-sync 半同步復制

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

1、異步復制：MySQL 中默認的復制是異步的，主庫在執(zhí)行完客戶端提交的事務后會立即將結(jié)果返回給客戶端，并不關(guān)心從庫是否已經(jīng)接收并且處理。存在問題就是，如果主庫的日志沒有及時同步到從庫，然后主庫宕機了，這時候執(zhí)行故障轉(zhuǎn)移，在從庫沖選主，可能會存在選出的主庫中數(shù)據(jù)不完整；

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

3、半同步復制：是介于全同步和全異步同步的一種，主庫至少需要等待一個從庫接收并寫入到 Relay Log 文件即可，主庫不需要等待所有從庫給主庫返回 ACK。主庫收到 ACK ，標識這個事務完成，返回數(shù)據(jù)給客戶端。

MySQL 中默認的復制是異步的，所以主庫和從庫的同步會存在一定的延遲，更重要的是異步復制還可能引起數(shù)據(jù)的丟失。全同步復制的性能又太差了，所以從 MySQL 5.5 開始，MySQL 以插件的形式支持 semi-sync 半同步復制。

半同步復制潛在的問題

在傳統(tǒng)的半同步復制中，主庫寫數(shù)據(jù)到 binlog，并且執(zhí)行 commit 提交事務后，會一直等待一個從庫的 ACK。從庫會在寫入 Relay Log 后，將數(shù)據(jù)落盤，然后回復給主庫 ACK，主庫收到這個 ACK 才能給客戶端事務完成的確認。

這樣會存在問題就是，主庫已經(jīng)將該事務的 commit 存儲到了引擎層，應用已經(jīng)可以看到數(shù)據(jù)的變化了，只是在等待從庫的返回，如果此時主庫宕機，可能從庫還沒有寫入 Relay Log，就會發(fā)生主從庫數(shù)據(jù)不一致。

為了解決這個問題，MySQL 5.7 引入了增強半同步復制。主庫寫入數(shù)據(jù)到 binlog 后，就開始等待從庫的應答 ACK，直到至少一個從庫寫入 Relay Log 后，并將數(shù)據(jù)落盤，然后返回給主庫 ACK，通知主庫可以進行 commit 操作，然后主庫再將事務提交到事務引擎，應用此時才能看到數(shù)據(jù)的變化。

不過看下來增強半同步復制，在同步給從庫之后，因為自己的數(shù)據(jù)還沒有提交，然后宕機了，主庫中也是會存在數(shù)據(jù)的丟失，不過應該想到的是，這時候主庫宕機了，是會重新在從庫中選主的，這樣新選出的主庫數(shù)據(jù)是沒有發(fā)生丟失的。

MySQL Group Replication

MySQL Group Replication 組復制，又稱為 MGR。是 Oracle MySQL 于 2016 年 12 月發(fā)布 MySQL 5.7.17 推出的一個全新高可用和高擴展的解決方案。

引入復制組主要是為了解決傳統(tǒng)異步復制和半同步復制可能產(chǎn)生數(shù)據(jù)不一致的問題。

MGR 由若干個節(jié)點共同組成一個復制組，一個事務的提交，必須經(jīng)過組內(nèi)大多數(shù)節(jié)點 (N / 2 + 1) 決議并通過，才能得以提交。

當客戶端發(fā)起一個更新事務時，該事務先在本地執(zhí)行，執(zhí)行完成之后就要發(fā)起對事務的提交操作。在還沒有真正提交之前，需要將產(chǎn)生的復制寫集廣播出去，復制到其它成員。因為事務是通過原子廣播發(fā)送的，所以組中的成員要么都接收事務，要么都不接收事務。如果組中的所有成員收到了該廣播消息(事務)，那么他們會按照之前發(fā)送事務的相同順序收到該廣播消息。因此，所有組成員都以相同的順序接收事務的寫集，并為事務建立全局順序。因此，所有組成員都以相同的順序接收事務的寫集，并為事務建立全局順序。

在不同組成員并發(fā)執(zhí)行的事務可能存在沖突。沖突是通過檢查和比較兩個不同并發(fā)事務的 write set 來驗證的，這個過程稱為認證。在認證期間，沖突檢測在行級別執(zhí)行的：如果在不同組成員上執(zhí)行的兩個并發(fā)事務更新了同一行數(shù)據(jù)，則存在沖突。根據(jù)沖突認證檢測機制判斷，按照順序，第一次提交的會正常執(zhí)行，第二次提交的事務會在事務發(fā)起的原始組成員上執(zhí)行回滾,，組中的其他成員對該事務執(zhí)行刪除。如果兩個事務經(jīng)常發(fā)生沖突，那么最好將這兩個事務放在同一個組成員中執(zhí)行，這樣它們在本地鎖管理器的協(xié)調(diào)下將都有機會提交成功，而不至于因為處在兩個不同的組成員中由于沖突認證而導致其中一個事務被頻繁回滾。

最終，所有組內(nèi)成員以相同的順序接收同一組事務。因此組內(nèi)成員以相同的順序應用相同的修改，保證組內(nèi)數(shù)據(jù)強一致性。

有下面的幾種特性：

1、避免腦裂：MGR 中不會出現(xiàn)腦裂的現(xiàn)象；

2、數(shù)據(jù)一致性保障：MGR 的冗余能力很好，能夠保證 Binlog Event 至少被復制到超過一半的成員上，只要同時宕機的成員不超過半數(shù)便不會導致數(shù)據(jù)丟失。MGR還保證只要 Binlog Event 沒有被傳輸?shù)桨霐?shù)以上的成員，本地成員不會將事務的 Binlog Event 寫入 Binlog 文件和提交事務，從而保證宕機的服務器上不會有組內(nèi)在線成員上不存在的數(shù)據(jù)。因此，宕機的服務器重啟后，不再需要特殊的處理就可以加入組；

3、多節(jié)點寫入支持：多寫模式下支持集群中的所有節(jié)點都可以寫入。

組復制的應用場景

1、彈性復制：需要非常靈活的復制基礎(chǔ)設施的環(huán)境，其中MySQL Server的數(shù)量必須動態(tài)增加或減少，并且在增加或減少Server的過程中，對業(yè)務的副作用盡可能少。例如，云數(shù)據(jù)庫服務；

2、高可用分片：分片是實現(xiàn)寫擴展的一種流行方法?；?組復制 實現(xiàn)的高可用分片，其中每個分片都會映射到一個復制組上（邏輯上需要一一對應，但在物理上，一個復制組可以承載多個分片）；

3、替代主從復制：在某些情況下，使用一個主庫會造成單點爭用。在某些情況下，向整個組內(nèi)的多個成員同時寫入數(shù)據(jù)，對應用來說可能伸縮性更強；

4、自治系統(tǒng)：可以利用組復制內(nèi)置的自動故障轉(zhuǎn)移、數(shù)據(jù)在不同組成員之間的原子廣播和最終數(shù)據(jù)一致性的特性來實現(xiàn)一些運維自動化。

InnoDB Cluster

InnoDB Cluster 是官方提供的高可用方案,是 MySQL 的一種高可用性(HA)解決方案，它通過使用 MySQL Group Replication 來實現(xiàn)數(shù)據(jù)的自動復制和高可用性，InnoDB Cluster 通常包含下面三個關(guān)鍵組件：

1、MySQL Shell: 它是 MySQL 的高級管理客戶端;

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

3、MySQL Router，一種輕量級中間件，主要進行路由請求，將客戶端發(fā)送過來的請求路由到不同的 MySQL 服務器節(jié)點。

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

優(yōu)點：

1、高可用性：通過 MySQL Group Replication，InnoDB Cluster 能夠?qū)崿F(xiàn)數(shù)據(jù)在集群中的自動復制，從而保證數(shù)據(jù)的可用性；

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

3、全自動故障轉(zhuǎn)移: InnoDB Cluster 能夠自動檢測和診斷故障，并進行必要的故障轉(zhuǎn)移，使得數(shù)據(jù)可以繼續(xù)可用。

缺點：

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

2、性能影響：由于自動復制和高可用性的要求，InnoDB Cluster 可能對 MySQL 的性能造成一定的影響；

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

InnoDB ClusterSet

MySQL InnoDB ClusterSet 通過將主 InnoDB Cluster 與其在備用位置（例如不同數(shù)據(jù)中心）的一個或多個副本鏈接起來，為 InnoDB Cluster 部署提供容災能力。

InnoDB ClusterSet 使用專用的 ClusterSet 復制通道自動管理從主集群到副本集群的復制。如果主集群由于數(shù)據(jù)中心損壞或網(wǎng)絡連接丟失而變得無法使用，用戶可以激活副本集群以恢復服務的可用性。

InnoDB ClusterSet 的特點：

1、主集群和副本集群之間的緊急故障轉(zhuǎn)移可以由管理員通過 MySQL Shell，使用 AdminAPI 進行操作；

2、InnoDB ClusterSet 部署中可以擁有的副本集群的數(shù)量沒有定義的限制；

3、異步復制通道將事務從主集群復制到副本集群。clusterset_replication 在 InnoDB ClusterSet 創(chuàng)建過程中，在每個集群上都設置了名為 ClusterSet 的復制通道，當集群是副本時，它使用該通道從主集群復制事務。底層組復制技術(shù)管理通道并確保復制始終在主集群的主服務器（作為發(fā)送方）和副本集群的主服務器（作為接收方）之間進行；

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

InnoDB ClusterSet 的限制：

1、InnoDB ClusterSet 只支持異步復制，不能使用半同步復制，無法避免異步復制的缺陷：數(shù)據(jù)延遲、數(shù)據(jù)一致性等；

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

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

4、只支持 MySQL 8.0。

InnoDB ReplicaSet

InnoDB ReplicaSet 是 MySQL 團隊在 2020 年推出的一款產(chǎn)品，用來幫助用戶快速部署和管理主從復制，在數(shù)據(jù)庫層仍然使用的是主從復制技術(shù)。

InnoDB ReplicaSet 由單個主節(jié)點和多個輔助節(jié)點（傳統(tǒng)上稱為 MySQL 復制源和副本）組成。

與 InnoDB cluster 類似, MySQL Router 支持針對 InnoDB ReplicaSet 的引導, 這意味著可以自動配置 MySQL Router 以使用 InnoDB ReplicaSet, 而無需手動配置文件. 這使得 InnoDB ReplicaSet 成為一種快速簡便的方法, 可以啟動和運行 MySQL 復制和 MySQL Router, 非常適合擴展讀取, 并在不需要 InnoDB 集群提供高可用性的用例中提供手動故障轉(zhuǎn)移功能。

InnoDB ReplicaSet 的限制：

1、沒有自動故障轉(zhuǎn)移，在主節(jié)點不可用的情況下，需要使用 AdminAPI 手動觸發(fā)故障轉(zhuǎn)移，然后才能再次進行任何更改。但是，輔助實例仍可用于讀?。?/p>

2、由于意外停止或不可用，無法防止部分數(shù)據(jù)丟失：在意外停止時未完成的事務可能會丟失；

3、在意外退出或不可用后無法防止不一致。如果手動故障轉(zhuǎn)移提升了一個輔助實例，而前一個主實例仍然可用，例如，由于網(wǎng)絡分區(qū)，裂腦情況可能會導致數(shù)據(jù)不一致；

4、InnoDB ReplicaSet 不支持多主模式。允許寫入所有成員的經(jīng)典復制拓撲無法保證數(shù)據(jù)一致性；

5、讀取橫向擴展是有限的。InnoDB ReplicaSet 基于異步復制，因此無法像 Group Replication 那樣調(diào)整流量控制；

6、一個 ReplicaSet 最多由一個主實例組成。支持一個或多個輔助。盡管可以添加到 ReplicaSet 的輔助節(jié)點的數(shù)量沒有限制，但是連接到 ReplicaSet 的每個 MySQL Router 都必須監(jiān)視每個實例。因此，一個 ReplicaSet 中加入的實例越多，監(jiān)控就越多。

使用 InnoDB ReplicaSets 的主要原因是你有更好的寫性能。使用 InnoDB ReplicaSets 的另一個原因是它們允許在不穩(wěn)定或慢速網(wǎng)絡上部署，而 InnoDB Cluster 則不允許。

MMM

MMM（Master-Master replication manager for MySQL）是一套支持雙主故障切換和雙主日常管理的腳本程序。MMM 使用 Perl 語言開發(fā)，主要用來監(jiān)控和管理 MySQL Master-Master（雙主）復制，可以說是 MySQL 主主復制管理器。

雙主模式，業(yè)務上同一時刻只能一個主庫進行數(shù)據(jù)的寫入。另一個主備庫，會在主服務器失效時，進行主備切換和故障轉(zhuǎn)移。

MMM 中是通過一個 VIP(虛擬 IP) 的機制來保證集群的高可用的。整個集群中，在主節(jié)點會提供一個 VIP 地址來提供數(shù)據(jù)讀寫服務，當出現(xiàn)故障的時候，VIP 就會從原來的主節(jié)點便宜到其他節(jié)點，由其他節(jié)點提供服務。

MMM無法完全的保證數(shù)據(jù)一致性，所以適用于對數(shù)據(jù)的一致性要求不是很高的場景。（因為主備上的數(shù)據(jù)不一定是最新的，可能還沒從庫的新。解決方法：開啟半同步）。

MMM 的優(yōu)缺點

優(yōu)點：高可用性，擴展性好，出現(xiàn)故障自動切換，對于主主同步，在同一時間只提供一臺數(shù)據(jù)庫寫操作，保證數(shù)據(jù)的一致性。

缺點：無法完全保數(shù)據(jù)的一致性，建議采用半同步復制方式，減少失敗的概率；目前 MMM 社區(qū)已經(jīng)缺少維護，不支持基于 GTID 的復制。

適用場景：

MMM的適用場景為數(shù)據(jù)庫訪問量大，業(yè)務增長快，并且能實現(xiàn)讀寫分離的場景。

MHA

Master High Availability Manager and Tools for MySQL，簡稱 MHA 。是一套優(yōu)秀的作為 MySQL 高可用性環(huán)境下故障切換和主從提升的高可用軟件。

這個工具專門用于監(jiān)控主庫的狀態(tài)，當發(fā)現(xiàn) master 節(jié)點故障的時候，會自動提升其中擁有新數(shù)據(jù)的 slave 節(jié)點成為新的 master 節(jié)點，在此期間,MHA 會通過其他從節(jié)點獲取額外的信息來避免數(shù)據(jù)一致性問題。MHA 還提供了 mater 節(jié)點的在線切換功能，即按需切換 master-slave 節(jié)點。MHA 能夠在30秒內(nèi)實現(xiàn)故障切換，并能在故障切換過程中，最大程度的保證數(shù)據(jù)一致性。

MHA 由兩部分組成；

MHA Manager（管理節(jié)點）和MHA Node（數(shù)據(jù)節(jié)點）。

MHA Manager 可以單獨部署在一臺獨立的機器上管理多個 master-slave 集群，也可以部署在一臺 slave節(jié)點上。MHA Node 運行在每臺 MySQL 服務器上，MHA Manager 會定時探測集群中的 master 節(jié)點，當 master 出現(xiàn)故障時，它可以自動將最新數(shù)據(jù)的 slave 提升為新的 master，然后將所有其他的 slave 重新指向新的 master。

整個故障轉(zhuǎn)移過程對應用程序完全透明。

在 MHA 自動故障切換過程中，MHA 試圖從宕機的主服務器上最大限度的保存二進制日志，最大程度的保證數(shù)據(jù)的不丟失，但這并不總是可行的。例如，主服務器硬件故障或無法通過 ssh 訪問，MHA 沒法保存二進制日志，只進行故障轉(zhuǎn)移而丟失了最新的數(shù)據(jù)。

使用 MySQL 5.5 開始找支持的半同步復制，可以大大降低數(shù)據(jù)丟失的風險。MHA可以與半同步復制結(jié)合起來。如果只有一個 slave 已經(jīng)收到了最新的二進制日志，MHA 可以將最新的二進制日志應用于其他所有的 slave 服務器上，因此可以保證所有節(jié)點的數(shù)據(jù)一致性。

目前 MHA 主要支持一主多從的架構(gòu)，要搭建 MHA,要求一個復制集群中必須最少有三臺數(shù)據(jù)庫服務器 ，一主二從，即一臺 master，一臺充當備用 master，另外一臺充當從庫，因為至少需要三臺服務器。

MHA 工作原理總結(jié)如下：

1、從宕機崩潰的 master 保存二進制日志事件（binlog events）；

2、識別最新更新的 slave；

3、應用差異的中繼日志(relay log) 到其他slave；

4、應用從master保存的二進制日志事件(binlog events)；

5、提升一個 slave 為新master；

6、使用其他的 slave 連接新的 master 進行復制。

優(yōu)點：

1、可以支持基于 GTID 的復制模式；

2、MHA 在進行故障轉(zhuǎn)移時更不易產(chǎn)生數(shù)據(jù)丟失；

3、同一個監(jiān)控節(jié)點可以監(jiān)控多個集群。

缺點：

1、需要編寫腳本或利用第三方工具來實現(xiàn) Vip 的配置；

2、MHA 啟動后只會對主數(shù)據(jù)庫進行監(jiān)控；

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

Galera Cluster

Galera Cluster 是由 Codership 開發(fā)的MySQL多主集群，包含在 MariaDB 中，同時支持 Percona xtradb、MySQL，是一個易于使用的高可用解決方案，在數(shù)據(jù)完整性、可擴展性及高性能方面都有可接受的表現(xiàn)。

其本身具有 multi-master 特性，支持多點寫入，Galera Cluster 中每個實例都是對等的，互為主從。當客戶端讀寫數(shù)據(jù)的時候，可以選擇任一 MySQL 實例，對于讀操作，每個實例讀取到的數(shù)據(jù)都是相同的。對于寫操作，當數(shù)據(jù)寫入某一節(jié)點后，集群會將其同步到其它節(jié)點。這種架構(gòu)不共享任何數(shù)據(jù)，是一種高冗余架構(gòu)。

主要功能

1、同步復制；

2、真正的 multi-master，即所有節(jié)點可以同時讀寫數(shù)據(jù)庫；

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

4、新節(jié)點加入數(shù)據(jù)自動復制；

5、真正的并行復制，行級；

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

優(yōu)勢

1、數(shù)據(jù)一致：同步復制保證了整個集群的數(shù)據(jù)一致性，無論何時在任何節(jié)點執(zhí)行相同的select查詢，結(jié)果都一樣；

2、高可用性：由于所有節(jié)點數(shù)據(jù)一致，單個節(jié)點崩潰不需要執(zhí)行復雜耗時的故障切換，也不會造成丟失數(shù)據(jù)或停止服務；

3、性能改進：同步復制允許在集群中的所有節(jié)點上并行執(zhí)行事務，從而提高讀寫性能；

4、更小的客戶端延遲；

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

分析下原理

Galera Cluster 中主要用到了同步復制，主庫中的單個更新事務需要在所有從庫中同步更新，當主庫提交事務，集群中的所有節(jié)點數(shù)據(jù)保持一致。

異步復制，主庫將數(shù)據(jù)更新傳播給從庫后立即提交事務，而不論從庫是否成功讀取或重放數(shù)據(jù)變化，所以異步復制會存在短暫的，主從數(shù)據(jù)同步不一致的情況出現(xiàn)。

不過同步復制的缺點也是很明顯的，同步復制協(xié)議通常使用兩階段提交或分布式鎖協(xié)調(diào)不同節(jié)點的操作，也及時說節(jié)點越多需要協(xié)調(diào)的節(jié)點也就越多，那么事務沖突和死鎖的概率也就會隨之增加。

我們知道 MGR 組復制的引入也是為了解決傳統(tǒng)異步復制和半同步復制可能產(chǎn)生數(shù)據(jù)不一致的問題，MGR 中的組復制，基于 Paxos 協(xié)議，原則上事務的提交，主要大多數(shù)節(jié)點 ACK 就可以提交了。

Galera Cluster 中的同步需要同步數(shù)據(jù)到所有節(jié)點，保證所有節(jié)點都成功?；趯Ｓ型ㄐ沤M系統(tǒng) GCommon ,所有節(jié)點都必須有 ACK。

Galera 復制是一種基于驗證的復制，基于驗證的復制使用通信和排序技術(shù)實現(xiàn)同步復制，通過廣播并發(fā)事務之間建立的全局總序來協(xié)調(diào)事務提交。簡單的講就是事務必須以相同的順序應用于所有實例。

事務現(xiàn)在本地執(zhí)行，然后發(fā)送的其他節(jié)點做沖突驗證，沒有沖突的時候所有節(jié)點提交事務，否則在所有節(jié)點回滾。

當客戶端發(fā)出 commit 命令時，在實際提交之前，對數(shù)據(jù)所做的更改都會收集到一個寫集合中，寫集合中包含事務信息和所更改行的主鍵，數(shù)據(jù)庫將寫集發(fā)送到其它節(jié)點。

節(jié)點用寫集中的主鍵與當前節(jié)點中未完成事務的所有寫集的主鍵比較，確定節(jié)點是否可以提交事務，同時滿足下面三個條件會被任務存在沖突，驗證失?。?/p>

1、兩個事務來源于不同節(jié)點；

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

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

驗證失敗，節(jié)點將刪除寫集，集群將回滾原始事務，對于所有的節(jié)點都是如此，每個節(jié)點單獨進行驗證。因為所有節(jié)點都以相同的順序接收事務，它們對事務的結(jié)果都會做出相同的決定，要么全成功，要么都失敗。成功后自然就提交了，所有的節(jié)點又會重新達到數(shù)據(jù)一致的狀態(tài)。節(jié)點之間不交換“是否沖突”的信息，各個節(jié)點獨立異步處理事務。

MySQL Cluster

MySQL Cluster 是一個高度可擴展的，兼容 ACID 事務的實時數(shù)據(jù)庫，基于分布式架構(gòu)不存在單點故障，MySQL Cluster 支持自動水平擴容，并能做自動的讀寫負載均衡。

MySQL Cluster 使用了一個叫 NDB 的內(nèi)存存儲引擎來整合多個 MySQL 實例，提供一個統(tǒng)一的服務集群。

NDB 是一種內(nèi)存性的存儲引擎,使用 Sarding-Nothing 的無共享的架構(gòu)。Sarding-Nothing 指的是每個節(jié)點有獨立的處理器，磁盤和內(nèi)存，節(jié)點之間沒有共享資源完全獨立互不干擾，節(jié)點之間通過告訴網(wǎng)絡組在一起，每個節(jié)點相當于是一個小型的數(shù)據(jù)庫，存儲部分數(shù)據(jù)。這種架構(gòu)的好處是可以利用節(jié)點的分布性并行處理數(shù)據(jù)，調(diào)高整體的性能，還有就是有很高的水平擴展性能，只需要增加節(jié)點就能增加數(shù)據(jù)的處理能力。

MySql Cluster 中包含三種節(jié)點，分別是管理節(jié)點(NDB Management Server)、數(shù)據(jù)節(jié)點(Data Nodes)和 SQL查詢節(jié)點(SQL Nodes) 。

SQL Nodes 是應用程序的接口，像普通的 mysqld 服務一樣，接受用戶的 SQL 輸入，執(zhí)行并返回結(jié)果。Data Nodes 是數(shù)據(jù)存儲節(jié)點，NDB Management Server 用來管理集群中的每個 node。

其中數(shù)據(jù)節(jié)點會存儲集群中的數(shù)據(jù)分區(qū)和分區(qū)的副本，來看下 MySql Cluster 是如何對數(shù)據(jù)進行分片的操作的，首先來了解下下面幾個概念

節(jié)點組（Node Group）： 一組數(shù)據(jù)節(jié)點的集合。節(jié)點組的個數(shù)=節(jié)點數(shù) / 副本數(shù)；

比如有集群中 4 個節(jié)點，副本數(shù)為 2（對應 NoOfReplicas 的設置），那么節(jié)點組個數(shù)為2。

另外，在可用性方面，數(shù)據(jù)的副本在組內(nèi)交叉分配，一個節(jié)點組內(nèi)只有要一臺機器可用，就可以保證整個集群的數(shù)據(jù)完整性，實現(xiàn)服務的整體可用。

分區(qū)（Partition）：MySql Cluster 是一個分布式的存儲系統(tǒng)，數(shù)據(jù)按照 分區(qū) 劃分成多份存儲在各數(shù)據(jù)節(jié)點中，分區(qū)個數(shù)由系統(tǒng)自動計算，分區(qū)數(shù) = 數(shù)據(jù)節(jié)點數(shù) / LDM 線程數(shù)；

副本（Replica）：分區(qū)數(shù)據(jù)的備份，有幾個分區(qū)就有幾個副本，為了避免單點，保證 MySql Cluster 集群的高可用，原始數(shù)據(jù)對應的分區(qū)和副本通常會保存在不同的主機上，在一個節(jié)點組內(nèi)進行交叉?zhèn)浞荨?/p>

栗如，上面的例子，有四個數(shù)據(jù)節(jié)點（使用ndbd），副本數(shù)為2的集群，節(jié)點組被分為2組（4/2），數(shù)據(jù)被分為4個分區(qū)，數(shù)據(jù)分配情況如下:

分區(qū)0（Partition 0）保存在節(jié)點組 0（Node Group 0）中，分區(qū)數(shù)據(jù)(主副本 — Primary Replica)保存在節(jié)點1(node 1) 中，備份數(shù)據(jù)(備份副本，Backup Replica)保存在節(jié)點2(node 2) 中；

分區(qū)1（Partition 1）保存在節(jié)點組 1（Node Group 1）中，分區(qū)數(shù)據(jù)(主副本 — Primary Replica)保存在節(jié)點3(node 3) 中，備份數(shù)據(jù)(備份副本，Backup Replica)保存在節(jié)點4(node 4) 中；

分區(qū)2（Partition 2）保存在節(jié)點組 0（Node Group 0）中，分區(qū)數(shù)據(jù)(主副本 — Primary Replica)保存在節(jié)點2(node 2) 中，備份數(shù)據(jù)(備份副本，Backup Replica)保存在節(jié)點1(node 1) 中；

分區(qū)3（Partition 2）保存在節(jié)點組 1（Node Group 1）中，分區(qū)數(shù)據(jù)(主副本 — Primary Replica)保存在節(jié)點4(node 4) 中，備份數(shù)據(jù)(備份副本，Backup Replica)保存在節(jié)點3(node 3) 中；

這樣，對于一張表的一個 Partition 來說，在整個集群有兩份數(shù)據(jù)，并分布在兩個獨立的 Node 上，實現(xiàn)了數(shù)據(jù)容災。同時，每次對一個 Partition 的寫操作，都會在兩個 Replica 上呈現(xiàn)，如果 Primary Replica 異常，那么 Backup Replica 可以立即提供服務，實現(xiàn)數(shù)據(jù)的高可用。

mysql cluster 的優(yōu)點

1、99.999％的高可用性；

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

3、靈活的分布式體系結(jié)構(gòu)，沒有單點故障；

4、高吞吐量和低延遲；

5、可擴展性強，支持在線擴容。

mysql cluster 的缺點

1、存在很多限制，比如：不支持外鍵，數(shù)據(jù)行不能超過8K（不包括BLOB和text中的數(shù)據(jù)）；

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

3、占用磁盤空間大，內(nèi)存大；

4、備份和恢復不方便；

5、重啟的時候，數(shù)據(jù)節(jié)點將數(shù)據(jù) load 到內(nèi)存需要很長時間。

MySQL Fabric

MySQL Fabric 會組織多個 MySQL 數(shù)據(jù)庫，將大的數(shù)據(jù)分散到多個數(shù)據(jù)庫中，即數(shù)據(jù)分片(Data Shard),同時同一個分片數(shù)據(jù)庫中又是一個主從結(jié)構(gòu)，F(xiàn)abric 會挑選合適的庫作為主庫，當主庫掛掉的時候，又會重新在從庫中選出一個主庫。

MySQL Fabric 的特點：

1、高可用；

2、使用數(shù)據(jù)分片的橫向功能。

MySQL Fabric-aware 連接器把從 MySQL Fabric 獲取的路由信息存儲到緩存中，然后憑借該信息將事務或查詢發(fā)送給正確的 MySQL 服務器。

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

HA Group 保證訪問指定 HA Group 的數(shù)據(jù)總是可用的，同時其基礎(chǔ)的數(shù)據(jù)復制是基于 MySQL Replication 實現(xiàn)的。

缺點

事務及查詢只支持在同一個分片內(nèi)，事務中更新的數(shù)據(jù)不能跨分片，查詢語句返回的數(shù)據(jù)也不能跨分片。

總結(jié)

1、MySQL Replication 是官方提供的主從同步方案，用于將一個 MySQL 的實例同步到另一個實例中，在主從復制中，從庫利用主庫上的 binlog 進行重播，實現(xiàn)主從同步，默認是異步同步，針對其在不同場景下的一些缺陷，衍生出了半同步復制，強同步復制等數(shù)據(jù)高可用的方案；

2、MySQL Group Replication 組復制又稱為 MGR,引入復制組主要是為了解決傳統(tǒng)異步復制和半同步復制可能產(chǎn)生數(shù)據(jù)不一致的問題, MGR 由若干個節(jié)點共同組成一個復制組，一個事務的提交，必須經(jīng)過組內(nèi)大多數(shù)節(jié)點 (N / 2 + 1) 決議并通過，才能得以提交;

3、InnoDB Cluster 是官方提供的高可用方案,是 MySQL 的一種高可用性(HA)解決方案，它通過使用 MySQL Group Replication 來實現(xiàn)數(shù)據(jù)的自動復制和高可用性；

4、InnoDB ClusterSet 通過將主 InnoDB Cluster 與其在備用位置（例如不同數(shù)據(jù)中心）的一個或多個副本鏈接起來，為 InnoDB Cluster 部署提供容災能力，每個節(jié)點就是一個 InnoDB Cluster；

5、InnoDB ReplicaSet 與 InnoDB cluster 類似, MySQL Router 支持針對 InnoDB ReplicaSet 的引導, 這意味著可以自動配置 MySQL Router 以使用 InnoDB ReplicaSet, 而無需手動配置文件. 這使得 InnoDB ReplicaSet 成為一種快速簡便的方法, 可以啟動和運行 MySQL 復制和 MySQL Router, 非常適合擴展讀取, 并在不需要 InnoDB 集群提供高可用性的用例中提供手動故障轉(zhuǎn)移功能；

6、MMM（Master-Master replication manager for MySQL）是一套支持雙主故障切換和雙主日常管理的腳本程序。MMM 使用 Perl 語言開發(fā)，主要用來監(jiān)控和管理 MySQL Master-Master（雙主）復制，可以說是 MySQL 主主復制管理器;

7、Master High Availability Manager and Tools for MySQL，簡稱 MHA 。是一套優(yōu)秀的作為 MySQL 高可用性環(huán)境下故障切換和主從提升的高可用軟件，這個工具專門用于監(jiān)控主庫的狀態(tài)，當發(fā)現(xiàn) master 節(jié)點故障的時候，會自動提升其中擁有新數(shù)據(jù)的 slave 節(jié)點成為新的 master 節(jié)點，在此期間,MHA 會通過其他從節(jié)點獲取額外的信息來避免數(shù)據(jù)一致性問題。MHA 還提供了 mater 節(jié)點的在線切換功能，即按需切換 master-slave 節(jié)點。MHA 能夠在30秒內(nèi)實現(xiàn)故障切換，并能在故障切換過程中，最大程度的保證數(shù)據(jù)一致性；

8、Galera Cluster 是由 Codership 開發(fā)的MySQL多主集群，包含在 MariaDB 中，同時支持 Percona xtradb、MySQL，是一個易于使用的高可用解決方案，在數(shù)據(jù)完整性、可擴展性及高性能方面都有可接受的表現(xiàn)，本身具有 multi-master 特性，支持多點寫入，Galera Cluster 中每個實例都是對等的，互為主從。當客戶端讀寫數(shù)據(jù)的時候，可以選擇任一 MySQL 實例，對于讀操作，每個實例讀取到的數(shù)據(jù)都是相同的。對于寫操作，當數(shù)據(jù)寫入某一節(jié)點后，集群會將其同步到其它節(jié)點。這種架構(gòu)不共享任何數(shù)據(jù)，是一種高冗余架構(gòu)；

9、MySQL Cluster 是一個高度可擴展的，兼容 ACID 事務的實時數(shù)據(jù)庫，基于分布式架構(gòu)不存在單點故障，MySQL Cluster 支持自動水平擴容，并能做自動的讀寫負載均衡，MySQL Cluster 使用了一個叫 NDB 的內(nèi)存存儲引擎來整合多個 MySQL 實例，提供一個統(tǒng)一的服務集群；

10、MySQL Fabric 會組織多個 MySQL 數(shù)據(jù)庫，將大的數(shù)據(jù)分散到多個數(shù)據(jù)庫中，即數(shù)據(jù)分片(Data Shard),同時同一個分片數(shù)據(jù)庫中又是一個主從結(jié)構(gòu)，F(xiàn)abric 會挑選合適的庫作為主庫，當主庫掛掉的時候，又會重新在從庫中選出一個主庫。

參考資料

【高性能MySQL(第3版)】https://book.douban.com/subject/23008813/
【MySQL 實戰(zhàn) 45 講】https://time.geekbang.org/column/100020801
【MySQL技術(shù)內(nèi)幕】https://book.douban.com/subject/24708143/
【MySQL學習筆記】https://github.com/boilingfrog/Go-POINT/tree/master/mysql
【MySQL文檔】https://dev.mysql.com/doc/refman/8.0/en/replication.html
【淺談 MySQL binlog 主從同步】http://www.linkedkeeper.com/1503.html

到此這篇關(guān)于MySQL 中常見的幾種高可用架構(gòu)部署方案的文章就介紹到這了,更多相關(guān)mysql高可用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論