MySQL Cluster的示例分析

MySQL Cluster的示例分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

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自動分配這些數據到各個組，或從各個組中組合符合條件的數據，返回給應用程序。

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

• 自增長鍵不能作為分片的鍵；

• 事務及查詢只支持在同一個分片內，事務中更新的數據不能跨分片，查詢語句返回的數據也不能跨分片。

測試高可用性

服務器架構：

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

首先，創建高可用組，例如組名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多家外國企業使用：

包括：

集群部署架構：

4.1、測試數據同步

在機器24上創建一個表：

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

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

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

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

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

現在為了測試，先將其中一個節點服務停止：

然后使用java代碼在集群上插入100W數據

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

這時啟動另外一個節點，啟動時即會自動同步集群的數據：

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

5.對比總結

6.實踐應用

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

如果三臺機器可以考慮：

看完上述內容，你們掌握MySQL Cluster的示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！