MySQLCluster的示例分析-創(chuàng)新互聯(lián)

MySQL Cluster的示例分析，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

創(chuàng)新互聯(lián)建站專業(yè)提供成都主機(jī)托管四川主機(jī)托管成都服務(wù)器托管四川服務(wù)器托管，支持按月付款！我們的承諾：貴族品質(zhì)、平民價(jià)格，機(jī)房位于中國(guó)電信/網(wǎng)通/移動(dòng)機(jī)房，服務(wù)器托管服務(wù)有保障！

1.背景

MySQL的cluster方案有很多官方和第三方的選擇，選擇多就是一種煩惱，因此，我們考慮mysql數(shù)據(jù)庫(kù)滿足下三點(diǎn)需求，考察市面上可行的解決方案：

高可用性：主服務(wù)器故障后可自動(dòng)切換到后備服務(wù)器
可伸縮性：可方便通過(guò)腳本增加DB服務(wù)器
負(fù)載均衡：支持手動(dòng)把某公司的數(shù)據(jù)請(qǐng)求切換到另外的服務(wù)器，可配置哪些公司的數(shù)據(jù)服務(wù)訪問(wèn)哪個(gè)服務(wù)器

需要選用一種方案滿足以上需求。在MySQL官方網(wǎng)站上參考了幾種解決方案的優(yōu)缺點(diǎn)：

綜合考慮，決定采用MySQL Fabric和MySQL Cluster方案，以及另外一種較成熟的集群方案Galera Cluster進(jìn)行預(yù)研。

2.MySQLCluster

簡(jiǎn)介：

MySQL Cluster 是MySQL 官方集群部署方案，它的歷史較久。支持通過(guò)自動(dòng)分片支持讀寫(xiě)擴(kuò)展，通過(guò)實(shí)時(shí)備份冗余數(shù)據(jù)，是可用性最高的方案，聲稱可做到99.999%的可用性。

架構(gòu)及實(shí)現(xiàn)原理：

MySQL cluster主要由三種類型的服務(wù)組成：

NDB Management Server：管理服務(wù)器主要用于管理cluster中的其他類型節(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ù)的訪問(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ù)在提交前，查詢不到在事務(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ì)已有記錄的更新。

3.MySQL Fabric

簡(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ù)及查詢只支持在同一個(gè)分片內(nèi)，事務(wù)中更新的數(shù)據(jù)不能跨分片，查詢語(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)偛樵償?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)拷貝到其他所有的分片組中。

4.Galera Cluster

簡(jiǎn)介：

Galera Cluster號(hào)稱是世界上最先進(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ù)制線程從主服務(wù)器上拷貝更新日志，讓后傳送到備份服務(wù)器上執(zhí)行，這種方式存在事務(wù)丟失及同步不及時(shí)的風(fēng)險(xiǎn)。Fabric以及傳統(tǒng)的主從復(fù)制都是使用這種實(shí)現(xiàn)方式。

而Galera則采用以下架構(gòu)保證事務(wù)在所有機(jī)器的一致性：

客戶端通過(guò)Galera Load Balancer訪問(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ù)大?。?/p>

這時(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)

5.對(duì)比總結(jié)

	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)切換，但由于備份延遲，切換后可能不能立即查詢數(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類和url	程序無(wú)需修改
性能對(duì)比	使用java直接用jdbc插入100條記錄，大概2000+ms	跟直接操作mysql一樣，直接用jdbc插入100條記錄，大概600ms

6.實(shí)踐應(yīng)用

綜合考慮上面方案的優(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è)資訊頻道，感謝各位的閱讀！

文章名稱：MySQLCluster的示例分析-創(chuàng)新互聯(lián)
轉(zhuǎn)載來(lái)于：http://bm7419.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)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容