MySQL?中常見的幾種高可用架構(gòu)部署方案解析
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)都成功?;趯S型ㄐ沤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)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MySQL?數(shù)據(jù)庫(kù)如何實(shí)現(xiàn)存儲(chǔ)時(shí)間
這篇文章主要介紹了MySQL?數(shù)據(jù)庫(kù)如何實(shí)現(xiàn)存儲(chǔ)時(shí)間,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-03-03MySQL優(yōu)化表時(shí)提示 Table is already up to date的解決方法
這篇文章主要介紹了MySQL優(yōu)化表時(shí)提示 Table is already up to date的解決方法,需要的朋友可以參考下2016-11-11mysql設(shè)置默認(rèn)值無(wú)效問(wèn)題及解決
這篇文章主要介紹了mysql設(shè)置默認(rèn)值無(wú)效問(wèn)題及解決方案,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-10-10MySQL算術(shù)/比較/邏輯/位/運(yùn)算符與正則舉例詳解
每種數(shù)據(jù)庫(kù)都支持SQL語(yǔ)句,但是它們也都有各自支持的運(yùn)算符,下面這篇文章主要給大家介紹了關(guān)于MySQL算術(shù)/比較/邏輯/位/運(yùn)算符與正則的相關(guān)資料,文中通過(guò)實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-02-02Windows 下noinstall方式安裝 mysql 5.7.5 m15 winx64(推薦)
這篇文章主要介紹了Windows 下noinstall方式安裝 mysql-5.7.5-m15-winx64的相關(guān)資料,非常不錯(cuò),具有參考借鑒價(jià)值,感興趣的朋友一起看看吧2016-09-09MySQL使用的常見問(wèn)題解決與應(yīng)用技巧匯總
這篇文章主要給大家總結(jié)介紹了我們平時(shí)在使用MySQL遇到的常見問(wèn)題解決與應(yīng)用技巧的相關(guān)資料,包括忘記MySQL的root密碼、如何處理 myisam 存儲(chǔ)引擎的表?yè)p壞、數(shù)據(jù)目錄磁盤空間不足的問(wèn)題等等問(wèn)題,需要的朋友可以參考借鑒,下面來(lái)一起看看吧。2017-11-11