MySQL Cluster的示例分析,相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策,為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法,通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。
創(chuàng)新互聯(lián)建站專(zhuān)業(yè)提供成都主機(jī)托管四川主機(jī)托管成都服務(wù)器托管四川服務(wù)器托管,支持按月付款!我們的承諾:貴族品質(zhì)、平民價(jià)格,機(jī)房位于中國(guó)電信/網(wǎng)通/移動(dòng)機(jī)房,服務(wù)器托管服務(wù)有保障!MySQL的cluster方案有很多官方和第三方的選擇,選擇多就是一種煩惱,因此,我們考慮mysql數(shù)據(jù)庫(kù)滿(mǎn)足下三點(diǎn)需求,考察市面上可行的解決方案:
高可用性:主服務(wù)器故障后可自動(dòng)切換到后備服務(wù)器
可伸縮性:可方便通過(guò)腳本增加DB服務(wù)器
負(fù)載均衡:支持手動(dòng)把某公司的數(shù)據(jù)請(qǐng)求切換到另外的服務(wù)器,可配置哪些公司的數(shù)據(jù)服務(wù)訪(fǎng)問(wèn)哪個(gè)服務(wù)器
需要選用一種方案滿(mǎn)足以上需求。在MySQL官方網(wǎng)站上參考了幾種解決方案的優(yōu)缺點(diǎn):
綜合考慮,決定采用MySQL Fabric和MySQL Cluster方案,以及另外一種較成熟的集群方案Galera Cluster進(jìn)行預(yù)研。
簡(jiǎn)介:
MySQL Cluster 是MySQL 官方集群部署方案,它的歷史較久。支持通過(guò)自動(dòng)分片支持讀寫(xiě)擴(kuò)展,通過(guò)實(shí)時(shí)備份冗余數(shù)據(jù),是可用性最高的方案,聲稱(chēng)可做到99.999%的可用性。
架構(gòu)及實(shí)現(xiàn)原理:
MySQL cluster主要由三種類(lèi)型的服務(wù)組成:
NDB Management Server:管理服務(wù)器主要用于管理cluster中的其他類(lèi)型節(jié)點(diǎn)(Data Node和SQL Node),通過(guò)它可以配置Node信息,啟動(dòng)和停止Node。
SQL Node:在MySQL Cluster中,一個(gè)SQL Node就是一個(gè)使用NDB引擎的mysql server進(jìn)程,用于供外部應(yīng)用提供集群數(shù)據(jù)的訪(fǎng)問(wèn)入口。
Data Node:用于存儲(chǔ)集群數(shù)據(jù);系統(tǒng)會(huì)盡量將數(shù)據(jù)放在內(nèi)存中。
缺點(diǎn)及限制:
對(duì)需要進(jìn)行分片的表需要修改引擎Innodb為NDB,不需要分片的可以不修改。
NDB的事務(wù)隔離級(jí)別只支持Read Committed,即一個(gè)事務(wù)在提交前,查詢(xún)不到在事務(wù)內(nèi)所做的修改;而Innodb支持所有的事務(wù)隔離級(jí)別,默認(rèn)使用Repeatable Read,不存在這個(gè)問(wèn)題。
外鍵支持:雖然最新的Cluster版本已經(jīng)支持外鍵,但性能有問(wèn)題(因?yàn)橥怄I所關(guān)聯(lián)的記錄可能在別的分片節(jié)點(diǎn)中),所以建議去掉所有外鍵。
Data Node節(jié)點(diǎn)數(shù)據(jù)會(huì)被盡量放在內(nèi)存中,對(duì)內(nèi)存要求大。
數(shù)據(jù)庫(kù)系統(tǒng)提供了四種事務(wù)隔離級(jí)別:
A.Serializable(串行化):一個(gè)事務(wù)在執(zhí)行過(guò)程中完全看不到其他事務(wù)對(duì)數(shù)據(jù)庫(kù)所做的更新(事務(wù)執(zhí)行的時(shí)候不允許別的事務(wù)并發(fā)執(zhí)行。事務(wù)串行化執(zhí)行,事務(wù)只能一個(gè)接著一個(gè)地執(zhí)行,而不能并發(fā)執(zhí)行。)。
B.Repeatable Read(可重復(fù)讀):一個(gè)事務(wù)在執(zhí)行過(guò)程中可以看到其他事務(wù)已經(jīng)提交的新插入的記錄,但是不能看到其他其他事務(wù)對(duì)已有記錄的更新。
C.Read Commited(讀已提交數(shù)據(jù)):一個(gè)事務(wù)在執(zhí)行過(guò)程中可以看到其他事務(wù)已經(jīng)提交的新插入的記錄,而且能看到其他事務(wù)已經(jīng)提交的對(duì)已有記錄的更新。
D.Read Uncommitted(讀未提交數(shù)據(jù)):一個(gè)事務(wù)在執(zhí)行過(guò)程中可以看到其他事務(wù)沒(méi)有提交的新插入的記錄,而且能看到其他事務(wù)沒(méi)有提交的對(duì)已有記錄的更新。
簡(jiǎn)介:
為了實(shí)現(xiàn)和方便管理MySQL 分片以及實(shí)現(xiàn)高可用部署,Oracle在2014年5月推出了一套為各方寄予厚望的MySQL產(chǎn)品 -- MySQL Fabric, 用來(lái)管理MySQL 服務(wù),提供擴(kuò)展性和容易使用的系統(tǒng),F(xiàn)abric當(dāng)前實(shí)現(xiàn)了兩個(gè)特性:高可用和使用數(shù)據(jù)分片實(shí)現(xiàn)可擴(kuò)展性和負(fù)載均衡,這兩個(gè)特性能單獨(dú)使用或結(jié)合使用。
MySQL Fabric 使用了一系列的Python腳本實(shí)現(xiàn)。
應(yīng)用案例:由于該方案在去年才推出,目前在網(wǎng)上暫時(shí)沒(méi)搜索到有大公司的應(yīng)用案例。
架構(gòu)及實(shí)現(xiàn)原理:
Fabric支持實(shí)現(xiàn)高可用性的架構(gòu)圖如下:
Fabric使用HA組實(shí)現(xiàn)高可用性,其中一臺(tái)是主服務(wù)器,其他是備份服務(wù)器, 備份服務(wù)器通過(guò)同步復(fù)制實(shí)現(xiàn)數(shù)據(jù)冗余。應(yīng)用程序使用特定的驅(qū)動(dòng),連接到Fabric 的Connector組件,當(dāng)主服務(wù)器發(fā)生故障后,Connector自動(dòng)升級(jí)其中一個(gè)備份服務(wù)器為主服務(wù)器,應(yīng)用程序無(wú)需修改。
Fabric支持可擴(kuò)展性及負(fù)載均衡的架構(gòu)如下:
使用多個(gè)HA 組實(shí)現(xiàn)分片,每個(gè)組之間分擔(dān)不同的分片數(shù)據(jù)(組內(nèi)的數(shù)據(jù)是冗余的,這個(gè)在高可用性中已經(jīng)提到)
應(yīng)用程序只需向connector發(fā)送query和insert等語(yǔ)句,Connector通過(guò)MasterGroup自動(dòng)分配這些數(shù)據(jù)到各個(gè)組,或從各個(gè)組中組合符合條件的數(shù)據(jù),返回給應(yīng)用程序。
缺點(diǎn)及限制:
影響比較大的兩個(gè)限制是:
自增長(zhǎng)鍵不能作為分片的鍵;
事務(wù)及查詢(xún)只支持在同一個(gè)分片內(nèi),事務(wù)中更新的數(shù)據(jù)不能跨分片,查詢(xún)語(yǔ)句返回的數(shù)據(jù)也不能跨分片。
測(cè)試高可用性
服務(wù)器架構(gòu):
功能 | IP | Port |
Backing store(保存各服務(wù)器配置信息) | 200.200.168.24 | 3306 |
Fabric 管理進(jìn)程(Connector) | 200.200.168.24 | 32274 |
HA Group 1 -- Master | 200.200.168.23 | 3306 |
HA Group 1 -- Slave | 200.200.168.25 | 3306 |
安裝過(guò)程省略,下面講述如何設(shè)置高可用組、添加備份服務(wù)器等過(guò)程
首先,創(chuàng)建高可用組,例如組名group_id-1,命令:
mysqlfabric group create group_id-1
往組內(nèi)group_id-1添加機(jī)器200.200.168.25和200.200.168.23:
mysqlfabric group add group_id-1 200.200.168.25:3306
mysqlfabric group add group_id-1 200.200.168.23:3306
然后查看組內(nèi)機(jī)器狀態(tài):
由于未設(shè)置主服務(wù)器,兩個(gè)服務(wù)的狀態(tài)都是SECONDARY
提升其中一個(gè)為主服務(wù)器:
mysqlfabric group promote group_id-1 --slave_id 00f9831f-d602-11e3-b65e-0800271119cb
然后再查看狀態(tài):
設(shè)置成主服務(wù)器的服務(wù)已經(jīng)變成Primary。
另外,mode屬性表示該服務(wù)器是可讀寫(xiě)(READ_WRITE),或只讀(READ_ONLY),只讀表示可以分?jǐn)偛樵?xún)數(shù)據(jù)的壓力;只有主服務(wù)器能設(shè)置成可讀寫(xiě)(READ_WRITE)。
這時(shí)檢查25服務(wù)器的slave狀態(tài):
可以看到它的主服務(wù)器已經(jīng)指向23
然后激活故障自動(dòng)切換功能:
mysqlfabric group activate group_id-1
激活后即可測(cè)試服務(wù)的高可以性
首先,進(jìn)行狀態(tài)測(cè)試:
停止主服務(wù)器23
然后查看狀態(tài):
可以看到,這時(shí)將25自動(dòng)提升為主服務(wù)器。
但如果將23恢復(fù)起來(lái)后,需要手動(dòng)重新設(shè)置23為主服務(wù)器。
實(shí)時(shí)性測(cè)試:
目的:測(cè)試在主服務(wù)更新數(shù)據(jù)后,備份服務(wù)器多久才顯示這些數(shù)據(jù)
測(cè)試案例:使用Java代碼建連接,往某張表插入100條記錄,看備份服務(wù)器多久才能同步這100條數(shù)據(jù)
測(cè)試結(jié)果:
表中原來(lái)有101條數(shù)據(jù),運(yùn)行程序后,查看主服務(wù)器的數(shù)據(jù)條數(shù):
可見(jiàn)主服務(wù)器當(dāng)然立即得到更新。
查看備份服務(wù)器的數(shù)據(jù)條數(shù):
但備份服務(wù)器等待了1-2分鐘才同步完成(可以看到fabric使用的是異步復(fù)制,這是默認(rèn)方式,性能較好,主服務(wù)器不用等待備份服務(wù)器返回,但同步速度較慢)
對(duì)于從服務(wù)器同步數(shù)據(jù)穩(wěn)定性問(wèn)題,有以下解決方案:
使用半同步加強(qiáng)數(shù)據(jù)一致性:異步復(fù)制能提供較好的性能,但主庫(kù)只是把binlog日志發(fā)送給從庫(kù),動(dòng)作就結(jié)束了,不會(huì)驗(yàn)證從庫(kù)是否接收完畢,風(fēng)險(xiǎn)較高。半同步復(fù)制會(huì)在發(fā)送給從庫(kù)后,等待從庫(kù)發(fā)送確認(rèn)信息后才返回。
可以設(shè)置從庫(kù)中同步日志的更新方式,從而減少?gòu)膸?kù)同步的延遲,加快同步速度。
安裝半同步復(fù)制:
在mysql中運(yùn)行
install plugin rpl_semi_sync_master soname 'semisync_master.so';
install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
SET GLOBAL rpl_semi_sync_master_enabled=ON;
SET GLOBAL rpl_semi_sync_slave_enabled=ON;
修改my.cnf :
rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1
sync_relay_log=1
sync_relay_log_info=1
sync_master_info=1
穩(wěn)定性測(cè)試:
測(cè)試案例:使用java代碼建連接,往某張表插入1w條記錄,插入過(guò)程中將其中的master服務(wù)器停了,看備份服務(wù)器是否有這1w筆記錄
測(cè)試結(jié)果,停止主服務(wù)器后,java程序拋出異常:
但這時(shí)再次發(fā)送sql命令,可以成功返回。證明只是當(dāng)時(shí)的事務(wù)失敗了。連接切換到了備份服務(wù)器,仍然可用。
翻閱了mysql文檔,有章節(jié)說(shuō)明了這個(gè)問(wèn)題:
里面提到:當(dāng)主服務(wù)器當(dāng)機(jī)時(shí),我們的應(yīng)用程序雖然是不需做任何修改的,但在主服務(wù)器被備份服務(wù)器替換前,某些事務(wù)會(huì)丟失,這些可以作為正常的mysql錯(cuò)誤來(lái)處理。
數(shù)據(jù)完整性校驗(yàn):
測(cè)試主服務(wù)器停止后,備份服務(wù)器是否能夠同步所有數(shù)據(jù)。
重啟了剛才停止主服務(wù)器后,查看記錄數(shù)
可以看到在插入1059條記錄后被停止了。
現(xiàn)在看看備份服務(wù)器的記錄數(shù)是多少,看看在主服務(wù)器當(dāng)機(jī)后是否所有數(shù)據(jù)都能同步過(guò)來(lái)
大約經(jīng)過(guò)了幾十秒,才同步完,數(shù)據(jù)雖然不是立即同步過(guò)來(lái),但沒(méi)有丟失。
1.2、分片:如何支持可擴(kuò)展性和負(fù)載均衡
fabric分片簡(jiǎn)介:當(dāng)一臺(tái)機(jī)器或一個(gè)組承受不了服務(wù)壓力后,可以添加服務(wù)器分?jǐn)傋x寫(xiě)壓力,通過(guò)Fabirc的分片功能可以將某些表中數(shù)據(jù)分散存儲(chǔ)到不同服務(wù)器。我們可以設(shè)定分配數(shù)據(jù)存儲(chǔ)的規(guī)則,通過(guò)在表中設(shè)置分片key設(shè)置分配的規(guī)則。另外,有些表的數(shù)據(jù)可能并不需要分片存儲(chǔ),需要將整張表存儲(chǔ)在同一個(gè)服務(wù)器中,可以將設(shè)置一個(gè)全局組(Global Group)用于存儲(chǔ)這些數(shù)據(jù),存儲(chǔ)到全局組的數(shù)據(jù)會(huì)自動(dòng)拷貝到其他所有的分片組中。
簡(jiǎn)介:
Galera Cluster號(hào)稱(chēng)是世界上最先進(jìn)的開(kāi)源數(shù)據(jù)庫(kù)集群方案
主要優(yōu)點(diǎn)及特性:
真正的多主服務(wù)模式:多個(gè)服務(wù)能同時(shí)被讀寫(xiě),不像Fabric那樣某些服務(wù)只能作備份用
同步復(fù)制:無(wú)延遲復(fù)制,不會(huì)產(chǎn)生數(shù)據(jù)丟失
熱備用:當(dāng)某臺(tái)服務(wù)器當(dāng)機(jī)后,備用服務(wù)器會(huì)自動(dòng)接管,不會(huì)產(chǎn)生任何當(dāng)機(jī)時(shí)間
自動(dòng)擴(kuò)展節(jié)點(diǎn):新增服務(wù)器時(shí),不需手工復(fù)制數(shù)據(jù)庫(kù)到新的節(jié)點(diǎn)
支持InnoDB引擎
對(duì)應(yīng)用程序透明:應(yīng)用程序不需作修改
架構(gòu)及實(shí)現(xiàn)原理:
首先,我們看看傳統(tǒng)的基于mysql Replication(復(fù)制)的架構(gòu)圖:
Replication方式是通過(guò)啟動(dòng)復(fù)制線(xiàn)程從主服務(wù)器上拷貝更新日志,讓后傳送到備份服務(wù)器上執(zhí)行,這種方式存在事務(wù)丟失及同步不及時(shí)的風(fēng)險(xiǎn)。Fabric以及傳統(tǒng)的主從復(fù)制都是使用這種實(shí)現(xiàn)方式。
而Galera則采用以下架構(gòu)保證事務(wù)在所有機(jī)器的一致性:
客戶(hù)端通過(guò)Galera Load Balancer訪(fǎng)問(wèn)數(shù)據(jù)庫(kù),提交的每個(gè)事務(wù)都會(huì)通過(guò)wsrep API 在所有服務(wù)器中執(zhí)行,要不所有服務(wù)器都執(zhí)行成功,要不就所有都回滾,保證所有服務(wù)的數(shù)據(jù)一致性,而且所有服務(wù)器同步實(shí)時(shí)更新。
缺點(diǎn)及限制:
由于同一個(gè)事務(wù)需要在集群的多臺(tái)機(jī)器上執(zhí)行,因此網(wǎng)絡(luò)傳輸及并發(fā)執(zhí)行會(huì)導(dǎo)致性能上有一定的消耗。
所有機(jī)器上都存儲(chǔ)著相同的數(shù)據(jù),全冗余。
若一臺(tái)機(jī)器既作為主服務(wù)器,又作為備份服務(wù)器,出現(xiàn)樂(lè)觀鎖導(dǎo)致rollback的概率會(huì)增大,編寫(xiě)程序時(shí)要小心。
不支持的SQL:LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…
不支持XA Transaction
目前基于Galera Cluster的實(shí)現(xiàn)方案有三種:Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。
我們采用較成熟、應(yīng)用案例較多的Percona XtraDB Cluster。
應(yīng)用案例:
超過(guò)2000多家外國(guó)企業(yè)使用:
包括:
集群部署架構(gòu):
功能 | IP | Port |
Backing store(保存各服務(wù)器配置信息) | 200.200.168.24 | 3306 |
Fabric 管理進(jìn)程(Connector) | 200.200.168.24 | 32274 |
HA Master 1 | 200.200.168.24 | 3306 |
HA Master 2 | 200.200.168.25 | 3306 |
HA Master 3 | 200.200.168.23 | 3306 |
4.1、測(cè)試數(shù)據(jù)同步
在機(jī)器24上創(chuàng)建一個(gè)表:
立即在25 中查看,可見(jiàn)已被同步創(chuàng)建
使用Java代碼在24服務(wù)器上插入100條記錄
立即在25服務(wù)器上查看記錄數(shù)
可見(jiàn)數(shù)據(jù)同步是立即生效的。
4.2、測(cè)試添加集群節(jié)點(diǎn)
添加一個(gè)集群節(jié)點(diǎn)的步驟很簡(jiǎn)單,只要在新加入的機(jī)器上部署好Percona XtraDB Cluster,然后啟動(dòng),系統(tǒng)將自動(dòng)將現(xiàn)存集群中的數(shù)據(jù)同步到新的機(jī)器上。
現(xiàn)在為了測(cè)試,先將其中一個(gè)節(jié)點(diǎn)服務(wù)停止:
然后使用java代碼在集群上插入100W數(shù)據(jù)
查看100w數(shù)據(jù)的數(shù)據(jù)庫(kù)大小:
這時(shí)啟動(dòng)另外一個(gè)節(jié)點(diǎn),啟動(dòng)時(shí)即會(huì)自動(dòng)同步集群的數(shù)據(jù):
啟動(dòng)只需20秒左右,查看數(shù)據(jù)大小一致,查看表記錄數(shù),也已經(jīng)同步過(guò)來(lái)
MySQL Fabric | Galera Cluster | |
使用案例 | 2014年5月才推出,目前在網(wǎng)上暫時(shí)沒(méi)搜索到有大公司的應(yīng)用案例 | 方案較成熟,外國(guó)多家互聯(lián)網(wǎng)公司使用 |
數(shù)據(jù)備份的實(shí)時(shí)性 | 由于使用異步復(fù)制,一般延時(shí)幾十秒,但數(shù)據(jù)不會(huì)丟失。 | 實(shí)時(shí)同步,數(shù)據(jù)不會(huì)丟失 |
數(shù)據(jù)冗余 | 使用分片,通過(guò)設(shè)置分片key規(guī)則可以將同一張表的不同數(shù)據(jù)分散在多臺(tái)機(jī)器中 | 每個(gè)節(jié)點(diǎn)全冗余,沒(méi)有分片 |
高可用性 | 通過(guò)Fabric Connector實(shí)現(xiàn)主服務(wù)器當(dāng)機(jī)后的自動(dòng)切換,但由于備份延遲,切換后可能不能立即查詢(xún)數(shù)據(jù) | 使用HAProxy實(shí)現(xiàn)。由于實(shí)時(shí)同步,切換的可用性更高。 |
可伸縮性 | 添加節(jié)點(diǎn)后,需要先手工復(fù)制集群數(shù)據(jù) | 擴(kuò)展節(jié)點(diǎn)十分方便,啟動(dòng)節(jié)點(diǎn)時(shí)自動(dòng)同步集群數(shù)據(jù),100w數(shù)據(jù)(100M)只需20秒左右 |
負(fù)載均衡 | 通過(guò)HASharding實(shí)現(xiàn) | 使用HAProxy實(shí)現(xiàn)負(fù)載均衡 |
程序修改 | 需要切換成jdbc:mysql:fabric的jdbc類(lèi)和url | 程序無(wú)需修改 |
性能對(duì)比 | 使用java直接用jdbc插入100條記錄,大概2000+ms | 跟直接操作mysql一樣,直接用jdbc插入100條記錄,大概600ms |
綜合考慮上面方案的優(yōu)缺點(diǎn),我們比較偏向選擇Galera 如果只有兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器,考慮采用以下數(shù)據(jù)庫(kù)架構(gòu)實(shí)現(xiàn)高可用性、負(fù)載均衡和動(dòng)態(tài)擴(kuò)展:
如果三臺(tái)機(jī)器可以考慮:
看完上述內(nèi)容,你們掌握MySQL Cluster的示例分析的方法了嗎?如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道,感謝各位的閱讀!
文章名稱(chēng):MySQLCluster的示例分析-創(chuàng)新互聯(lián)
轉(zhuǎn)載來(lái)于:http://jinyejixie.com/article26/ggcjg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供靜態(tài)網(wǎng)站、網(wǎng)站改版、網(wǎng)站策劃、標(biāo)簽優(yōu)化、商城網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話(huà):028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)