MySQL 中的集群部署方案

前言

這里來(lái)聊聊，MySQL 中常用的部署方案。

MySQL Replication

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

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

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

優(yōu)點(diǎn)：

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

2、數(shù)據(jù)安全，因?yàn)楦北究梢詴和?fù)制過(guò)程，所以可以在副本上運(yùn)行備份服務(wù)而不會(huì)破壞相應(yīng)的源數(shù)據(jù)；

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

實(shí)現(xiàn)原理

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

IO thread: 在從庫(kù)執(zhí)行 start slave 語(yǔ)句時(shí)創(chuàng)建，負(fù)責(zé)連接主庫(kù)，請(qǐng)求 binlog，接收 binlog 并寫入 relay-log；

dump thread：用于主庫(kù)同步 binlog 給從庫(kù)，負(fù)責(zé)響應(yīng)從 IO thread 的請(qǐng)求。主庫(kù)會(huì)給每個(gè)從庫(kù)的連接創(chuàng)建一個(gè) dump thread，然后同步 binlog 給從庫(kù)；

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

來(lái)看下復(fù)制的流程：

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

2、從庫(kù)在主從之間建立長(zhǎng)連接；

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

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

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

不過(guò) MySQL Replication 有個(gè)嚴(yán)重的缺點(diǎn)就是主從同步延遲。

因?yàn)閿?shù)據(jù)是進(jìn)行主從同步的，那么就會(huì)遇到主從同步延遲的情況。

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

1、從庫(kù)機(jī)器的性能比主庫(kù)差；

2、從庫(kù)的壓力大；

大量查詢放在從庫(kù)上，可能會(huì)導(dǎo)致從庫(kù)上耗費(fèi)了大量的 CPU 資源，進(jìn)而影響了同步速度，造成主從延遲。

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

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

4、從庫(kù)的復(fù)制能力較差；

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

如何解決？

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

2、提高從庫(kù)的機(jī)器性能，減少主庫(kù)寫 binlog 和從庫(kù)讀 binlog 的效率差；

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

4、強(qiáng)行讀主庫(kù)；

5、配合 semi-sync 半同步復(fù)制；

semi-sync 半同步復(fù)制

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

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

2、全同步復(fù)制：指當(dāng)主庫(kù)執(zhí)行完一個(gè)事務(wù)，并且等到所有從庫(kù)也執(zhí)行完成這個(gè)事務(wù)的時(shí)候，主庫(kù)在提交事務(wù)，并且返回?cái)?shù)據(jù)給客戶端。因?yàn)橐却袕膸?kù)都同步到主庫(kù)中的數(shù)據(jù)才返回?cái)?shù)據(jù)，所以能夠保證主從數(shù)據(jù)的一致性，但是數(shù)據(jù)庫(kù)的性能必然受到影響；

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

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

半同步復(fù)制潛在的問(wèn)題

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

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

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

不過(guò)看下來(lái)增強(qiáng)半同步復(fù)制，在同步給從庫(kù)之后，因?yàn)樽约旱臄?shù)據(jù)還沒有提交，然后宕機(jī)了，主庫(kù)中也是會(huì)存在數(shù)據(jù)的丟失，不過(guò)應(yīng)該想到的是，這時(shí)候主庫(kù)宕機(jī)了，是會(huì)重新在從庫(kù)中選主的，這樣新選出的主庫(kù)數(shù)據(jù)是沒有發(fā)生丟失的。

MySQL Group Replication

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

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

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

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

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

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

有下面的幾種特性：

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

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

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

組復(fù)制的應(yīng)用場(chǎng)景

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

2、高可用分片：分片是實(shí)現(xiàn)寫擴(kuò)展的一種流行方法。基于 組復(fù)制 實(shí)現(xiàn)的高可用分片，其中每個(gè)分片都會(huì)映射到一個(gè)復(fù)制組上（邏輯上需要一一對(duì)應(yīng)，但在物理上，一個(gè)復(fù)制組可以承載多個(gè)分片）；

3、替代主從復(fù)制：在某些情況下，使用一個(gè)主庫(kù)會(huì)造成單點(diǎn)爭(zhēng)用。在某些情況下，向整個(gè)組內(nèi)的多個(gè)成員同時(shí)寫入數(shù)據(jù)，對(duì)應(yīng)用來(lái)說(shuō)可能伸縮性更強(qiáng)；

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

InnoDB Cluster

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

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

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

3、MySQL Router，一種輕量級(jí)中間件，主要進(jìn)行路由請(qǐng)求，將客戶端發(fā)送過(guò)來(lái)的請(qǐng)求路由到不同的 MySQL 服務(wù)器節(jié)點(diǎn)。

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

優(yōu)點(diǎn)：

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

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

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

缺點(diǎn)：

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

2、性能影響：由于自動(dòng)復(fù)制和高可用性的要求，InnoDB Cluster 可能對(duì) MySQL 的性能造成一定的影響；

3、限制：InnoDB Cluster 的功能對(duì)于一些特殊的應(yīng)用場(chǎng)景可能不夠靈活，需要更多的定制。

InnoDB ClusterSet

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

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

InnoDB ClusterSet 的特點(diǎn)：

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

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

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

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

InnoDB ClusterSet 的限制：

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

2、InnoDB ClusterSet 僅支持Cluster實(shí)例的單主模式,不支持多主模式。 即只能包含一個(gè)讀寫主集群, 所有副本集群都是只讀的, 不允許具有多個(gè)主集群的雙活設(shè)置，因?yàn)樵诩喊l(fā)生故障時(shí)無(wú)法保證數(shù)據(jù)一致性；

3、已有的 InnoDB Cluster 不能用作 InnoDB ClusterSet 部署中的副本集群。副本集群必須從單個(gè)服務(wù)器實(shí)例啟動(dòng)，作為新的 InnoDB 集群；

4、只支持 MySQL 8.0。

InnoDB ReplicaSet

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

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

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

InnoDB ReplicaSet 的限制：

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

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

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

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

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

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

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

MMM

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

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

MMM 中是通過(guò)一個(gè) VIP(虛擬 IP) 的機(jī)制來(lái)保證集群的高可用的。整個(gè)集群中，在主節(jié)點(diǎn)會(huì)提供一個(gè) VIP 地址來(lái)提供數(shù)據(jù)讀寫服務(wù)，當(dāng)出現(xiàn)故障的時(shí)候，VIP 就會(huì)從原來(lái)的主節(jié)點(diǎn)便宜到其他節(jié)點(diǎn)，由其他節(jié)點(diǎn)提供服務(wù)。

MMM無(wú)法完全的保證數(shù)據(jù)一致性，所以適用于對(duì)數(shù)據(jù)的一致性要求不是很高的場(chǎng)景。（因?yàn)橹鱾渖系臄?shù)據(jù)不一定是最新的，可能還沒從庫(kù)的新。解決方法：開啟半同步）。

MMM 的優(yōu)缺點(diǎn)

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

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

適用場(chǎng)景：

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

MHA

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

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

MHA 由兩部分組成；

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

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

整個(gè)故障轉(zhuǎn)移過(guò)程對(duì)應(yīng)用程序完全透明。

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

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

目前 MHA 主要支持一主多從的架構(gòu)，要搭建 MHA,要求一個(gè)復(fù)制集群中必須最少有三臺(tái)數(shù)據(jù)庫(kù)服務(wù)器 ，一主二從，即一臺(tái) master，一臺(tái)充當(dāng)備用 master，另外一臺(tái)充當(dāng)從庫(kù)，因?yàn)橹辽傩枰_(tái)服務(wù)器。

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

1、從宕機(jī)崩潰的 master 保存二進(jìn)制日志事件（binlog events）；

2、識(shí)別最新更新的 slave；

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

4、應(yīng)用從master保存的二進(jìn)制日志事件(binlog events)；

5、提升一個(gè) slave 為新master；

6、使用其他的 slave 連接新的 master 進(jìn)行復(fù)制。

優(yōu)點(diǎn)：

1、可以支持基于 GTID 的復(fù)制模式；

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

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

缺點(diǎn)：

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

2、MHA 啟動(dòng)后只會(huì)對(duì)主數(shù)據(jù)庫(kù)進(jìn)行監(jiān)控；

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

Galera Cluster

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

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

主要功能

1、同步復(fù)制；

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

3、自動(dòng)的節(jié)點(diǎn)成員控制，失效節(jié)點(diǎn)自動(dòng)被清除；

4、新節(jié)點(diǎn)加入數(shù)據(jù)自動(dòng)復(fù)制；

5、真正的并行復(fù)制，行級(jí)；

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

優(yōu)勢(shì)

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

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

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

4、更小的客戶端延遲；

5、同時(shí)具有讀和寫的擴(kuò)展能力。

分析下原理

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

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

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

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

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

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

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

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

節(jié)點(diǎn)用寫集中的主鍵與當(dāng)前節(jié)點(diǎn)中未完成事務(wù)的所有寫集的主鍵比較，確定節(jié)點(diǎn)是否可以提交事務(wù)，同時(shí)滿足下面三個(gè)條件會(huì)被任務(wù)存在沖突，驗(yàn)證失敗：

1、兩個(gè)事務(wù)來(lái)源于不同節(jié)點(diǎn)；

2、兩個(gè)事務(wù)包含相同的主鍵；

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

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

MySQL Cluster

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

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

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

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

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

其中數(shù)據(jù)節(jié)點(diǎn)會(huì)存儲(chǔ)集群中的數(shù)據(jù)分區(qū)和分區(qū)的副本，來(lái)看下 MySql Cluster 是如何對(duì)數(shù)據(jù)進(jìn)行分片的操作的，首先來(lái)了解下下面幾個(gè)概念

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

比如有集群中 4 個(gè)節(jié)點(diǎn)，副本數(shù)為 2（對(duì)應(yīng) NoOfReplicas 的設(shè)置），那么節(jié)點(diǎn)組個(gè)數(shù)為2。

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

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

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

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

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

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

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

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

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

mysql cluster 的優(yōu)點(diǎn)

1、99.999％的高可用性；

2、快速的自動(dòng)失效切換；

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

4、高吞吐量和低延遲；

5、可擴(kuò)展性強(qiáng)，支持在線擴(kuò)容。

mysql cluster 的缺點(diǎn)

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

2、部署、管理、配置很復(fù)雜；

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

4、備份和恢復(fù)不方便；

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

MySQL Fabric

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

MySQL Fabric 的特點(diǎn)：

1、高可用；

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

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

同時(shí)，每一個(gè)分片組，可以又多個(gè)一個(gè)服務(wù)器組成，構(gòu)成主從結(jié)構(gòu)，當(dāng)主庫(kù)掛掉的時(shí)候，又會(huì)重新在從庫(kù)中選出一個(gè)主庫(kù)。保證節(jié)點(diǎn)的高可用。

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

缺點(diǎn)

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

總結(jié)

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

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

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

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

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

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

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

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

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

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

參考資料

【高性能MySQL(第3版)】https://book.douban.com/subject/23008813/
【MySQL 實(shí)戰(zhàn) 45 講】https://time.geekbang.org/column/100020801
【MySQL技術(shù)內(nèi)幕】https://book.douban.com/subject/24708143/
【MySQL學(xué)習(xí)筆記】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)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論