轉【實戰體驗幾種MySQLCluster方案】

實戰體驗幾種MySQLCluster方案

1.背景

MySQL的cluster方案有不少官方和第三方的選擇，選擇多就是一種煩惱，所以，咱們考慮MySQL數據庫知足下三點需求，考察市面上可行的解決方案：

高可用性：主服務器故障後可自動切換到後備服務器可伸縮性：可方便經過腳本增長DB服務器負載均衡：支持手動把某公司的數據請求切換到另外的服務器，可配置哪些公司的數據服務訪問哪一個服務器

須要選用一種方案知足以上需求。在MySQL官方網站上參考了幾種解決方案的優缺點：

                       

 

綜合考慮，決定採用MySQL Fabric和MySQL Cluster方案，以及另一種較成熟的集羣方案Galera Cluster進行預研。

2.MySQLCluster

簡介：

MySQL Cluster 是MySQL 官方集羣部署方案，它的歷史較久。支持經過自動分片支持讀寫擴展，經過實時備份冗餘數據，是可用性最高的方案，聲稱可作到99.999%的可用性。

架構及實現原理：

 

MySQL cluster主要由三種類型的服務組成：

NDB Management Server：管理服務器主要用於管理cluster中的其餘類型節點（Data Node和SQL Node），經過它能夠配置Node信息，啓動和中止Node。 SQL Node：在MySQL Cluster中，一個SQL Node就是一個使用NDB引擎的mysql server進程，用於供外部應用提供集羣數據的訪問入口。Data Node：用於存儲集羣數據；系統會盡可能將數據放在內存中。

 

缺點及限制：

 

對須要進行分片的表須要修改引擎Innodb爲NDB，不須要分片的能夠不修改。NDB的事務隔離級別只支持Read Committed，即一個事務在提交前，查詢不到在事務內所作的修改；而Innodb支持全部的事務隔離級別，默認使用Repeatable Read，不存在這個問題。外鍵支持：雖然最新的Cluster版本已經支持外鍵，但性能有問題（由於外鍵所關聯的記錄可能在別的分片節點中），因此建議去掉全部外鍵。Data Node節點數據會被儘可能放在內存中，對內存要求大。

數據庫系統提供了四種事務隔離級別：
A.Serializable（串行化）：一個事務在執行過程當中徹底看不到其餘事務對數據庫所作的更新（事務執行的時候不容許別的事務併發執行。事務串行化執行，事務只能一個接着一個地執行，而不能併發執行。）。
B.Repeatable Read（可重複讀）：一個事務在執行過程當中能夠看到其餘事務已經提交的新插入的記錄，可是不能看到其餘其餘事務對已有記錄的更新。
C.Read Commited（讀已提交數據）：一個事務在執行過程當中能夠看到其餘事務已經提交的新插入的記錄，並且能看到其餘事務已經提交的對已有記錄的更新。
D.Read Uncommitted（讀未提交數據）：一個事務在執行過程當中能夠看到其餘事務沒有提交的新插入的記錄，並且能看到其餘事務沒有提交的對已有記錄的更新。

3.MySQL Fabric

 

簡介：

爲了實現和方便管理MySQL 分片以及實現高可用部署，Oracle在2014年5月推出了一套爲各方寄予厚望的MySQL產品 -- MySQL Fabric, 用來管理MySQL 服務，提供擴展性和容易使用的系統，Fabric當前實現了兩個特性：高可用和使用數據分片實現可擴展性和負載均衡，這兩個特性能單獨使用或結合使用。

MySQL Fabric 使用了一系列的python腳本實現。

應用案例：因爲該方案在去年才推出，目前在網上暫時沒搜索到有大公司的應用案例。

 

架構及實現原理：

Fabric支持實現高可用性的架構圖以下：

Fabric使用HA組實現高可用性，其中一臺是主服務器，其餘是備份服務器， 備份服務器經過同步複製實現數據冗餘。應用程序使用特定的驅動，鏈接到Fabric 的Connector組件，當主服務器發生故障後，Connector自動升級其中一個備份服務器爲主服務器，應用程序無需修改。

Fabric支持可擴展性及負載均衡的架構以下：

 

 

 

使用多個HA 組實現分片，每一個組之間分擔不一樣的分片數據（組內的數據是冗餘的，這個在高可用性中已經提到）
應用程序只需向connector發送query和insert等語句，Connector經過MasterGroup自動分配這些數據到各個組，或從各個組中組合符合條件的數據，返回給應用程序。

缺點及限制：
影響比較大的兩個限制是：

自增加鍵不能做爲分片的鍵；事務及查詢只支持在同一個分片內，事務中更新的數據不能跨分片，查詢語句返回的數據也不能跨分片。
 

測試高可用性

服務器架構：

功能	IP	Port
Backing store(保存各服務器配置信息)	200.200.168.24	3306
Fabric 管理進程（Connector）	200.200.168.24	32274
HA Group 1 -- Master	200.200.168.23	3306
HA Group 1 -- Slave	200.200.168.25	3306

 

安裝過程省略，下面講述如何設置高可用組、添加備份服務器等過程

首先，建立高可用組，例如組名group_id-1，命令：

mysqlfabric group create group_id-1

往組內group_id-1添加機器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

而後查看組內機器狀態：

因爲未設置主服務器，兩個服務的狀態都是SECONDARY
提高其中一個爲主服務器：
mysqlfabric group promote group_id-1 --slave_id 00f9831f-d602-11e3-b65e-0800271119cb
而後再查看狀態：

 

設置成主服務器的服務已經變成Primary。
另外，mode屬性表示該服務器是可讀寫（READ_WRITE)，或只讀(READ_ONLY)，只讀表示能夠分攤查詢數據的壓力；只有主服務器能設置成可讀寫（READ_WRITE)。
這時檢查25服務器的slave狀態：

 

能夠看到它的主服務器已經指向23


而後激活故障自動切換功能：
mysqlfabric group activate group_id-1
激活後便可測試服務的高能夠性
首先，進行狀態測試：
中止主服務器23

 

而後查看狀態：

 

能夠看到，這時將25自動提高爲主服務器。
但若是將23恢復起來後，須要手動從新設置23爲主服務器。


實時性測試：
目的：測試在主服務更新數據後，備份服務器多久才顯示這些數據
測試案例：使用java代碼建鏈接，往某張表插入100條記錄，看備份服務器多久才能同步這100條數據
測試結果：
表中原來有101條數據，運行程序後，查看主服務器的數據條數：

 

可見主服務器固然當即獲得更新。

查看備份服務器的數據條數：

 

但備份服務器等待了1-2分鐘才同步完成（能夠看到fabric使用的是異步複製，這是默認方式，性能較好，主服務器不用等待備份服務器返回，但同步速度較慢）

對於從服務器同步數據穩定性問題，有如下解決方案：

使用半同步增強數據一致性：異步複製能提供較好的性能，但主庫只是把binlog日誌發送給從庫，動做就結束了，不會驗證從庫是否接收完畢，風險較高。半同步複製會在發送給從庫後，等待從庫發送確認信息後才返回。能夠設置從庫中同步日誌的更新方式，從而減小從庫同步的延遲，加快同步速度。 安裝半同步複製：
在mysql中運行
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

穩定性測試：
測試案例：使用java代碼建鏈接，往某張表插入1w條記錄，插入過程當中將其中的master服務器停了，看備份服務器是否有這1w筆記錄
測試結果，中止主服務器後，java程序拋出異常：

 

 

但這時再次發送sql命令，能夠成功返回。證實只是當時的事務失敗了。鏈接切換到了備份服務器，仍然可用。
翻閱了mysql文檔，有章節說明了這個問題：

 

裏面提到：當主服務器當機時，咱們的應用程序雖然是不需作任何修改的，但在主服務器被備份服務器替換前，某些事務會丟失，這些能夠做爲正常的mysql錯誤來處理。

數據完整性校驗：
測試主服務器中止後，備份服務器是否可以同步全部數據。
重啓了剛纔中止主服務器後，查看記錄數

 

 

能夠看到在插入1059條記錄後被中止了。

如今看看備份服務器的記錄數是多少，看看在主服務器當機後是否全部數據都能同步過來

 

 

大約通過了幾十秒，才同步完，數據雖然不是當即同步過來，但沒有丟失。

1.2、分片：如何支持可擴展性和負載均衡

fabric分片簡介：當一臺機器或一個組承受不了服務壓力後，能夠添加服務器分攤讀寫壓力，經過Fabirc的分片功能能夠將某些表中數據分散存儲到不一樣服務器。咱們能夠設定分配數據存儲的規則，經過在表中設置分片key設置分配的規則。另外，有些表的數據可能並不須要分片存儲，須要將整張表存儲在同一個服務器中，能夠將設置一個全局組（Global Group）用於存儲這些數據，存儲到全局組的數據會自動拷貝到其餘全部的分片組中。

 

4.Galera Cluster

 

簡介：

Galera Cluster號稱是世界上最早進的開源數據庫集羣方案

 

主要優勢及特性：

真正的多主服務模式：多個服務能同時被讀寫，不像Fabric那樣某些服務只能做備份用同步複製：無延遲複製，不會產生數據丟失熱備用：當某臺服務器當機後，備用服務器會自動接管，不會產生任何當機時間自動擴展節點：新增服務器時，不需手工複製數據庫到新的節點支持InnoDB引擎對應用程序透明：應用程序不需做修改

 

 

架構及實現原理：
首先，咱們看看傳統的基於mysql Replication（複製）的架構圖：

 

Replication方式是經過啓動複製線程從主服務器上拷貝更新日誌，讓後傳送到備份服務器上執行，這種方式存在事務丟失及同步不及時的風險。Fabric以及傳統的主從複製都是使用這種實現方式。

而Galera則採用如下架構保證事務在全部機器的一致性：

 

客戶端經過Galera Load Balancer訪問數據庫，提交的每一個事務都會經過wsrep API 在全部服務器中執行，要不全部服務器都執行成功，要不就全部都回滾，保證全部服務的數據一致性，並且全部服務器同步實時更新。


缺點及限制：

因爲同一個事務須要在集羣的多臺機器上執行，所以網絡傳輸及併發執行會致使性能上有必定的消耗。全部機器上都存儲着相同的數據，全冗餘。若一臺機器既做爲主服務器，又做爲備份服務器，出現樂觀鎖致使rollback的機率會增大，編寫程序時要當心。不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…不支持XA Transaction
目前基於Galera Cluster的實現方案有三種：Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。
咱們採用較成熟、應用案例較多的Percona XtraDB Cluster。
應用案例：
超過2000多家外國企業使用：

 

 

 

包括：

 

集羣部署架構：

功能	IP	Port
Backing store(保存各服務器配置信息)	200.200.168.24	3306
Fabric 管理進程（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、測試數據同步

在機器24上建立一個表：

 

當即在25 中查看，可見已被同步建立

 

 

使用Java代碼在24服務器上插入100條記錄

 

當即在25服務器上查看記錄數

 

可見數據同步是當即生效的。

4.2、測試添加集羣節點
添加一個集羣節點的步驟很簡單，只要在新加入的機器上部署好Percona XtraDB Cluster，而後啓動，系統將自動將現存集羣中的數據同步到新的機器上。

如今爲了測試，先將其中一個節點服務中止：

 

而後使用java代碼在集羣上插入100W數據

 

查看100w數據的數據庫大小：

 

這時啓動另一個節點，啓動時即會自動同步集羣的數據：

 

啓動只需20秒左右，查看數據大小一致，查看錶記錄數，也已經同步過來

 

 

5.對比總結

 

 

	MySQL Fabric	Galera Cluster
使用案例	2014年5月才推出，目前在網上暫時沒搜索到有大公司的應用案例	方案較成熟，外國多家互聯網公司使用
數據備份的實時性	因爲使用異步複製，通常延時幾十秒，但數據不會丟失。	實時同步，數據不會丟失
數據冗餘	使用分片，經過設置分片key規則能夠將同一張表的不一樣數據分散在多臺機器中	每一個節點全冗餘，沒有分片
高可用性	經過Fabric Connector實現主服務器當機後的自動切換，但因爲備份延遲，切換後可能不能當即查詢數據	使用HAProxy實現。因爲實時同步，切換的可用性更高。
可伸縮性	添加節點後，須要先手工複製集羣數據	擴展節點十分方便，啓動節點時自動同步集羣數據，100w數據（100M）只需20秒左右
負載均衡	經過HASharding實現	使用HAProxy實現負載均衡
程序修改	須要切換成jdbc:mysql:fabric的jdbc類和url	程序無需修改
性能對比	使用java直接用jdbc插入100條記錄，大概2000+ms	跟直接操做mysql同樣，直接用jdbc插入100條記錄，大概600ms

6.實踐應用

綜合考慮上面方案的優缺點，咱們比較偏向選擇Galera 若是隻有兩臺數據庫服務器，考慮採用如下數據庫架構實現高可用性、負載均衡和動態擴展：

 

 

若是三臺機器能夠考慮：