MySQL NDB 集群在“住建一張圖”建設中的應用

馬亞敏，李守鵬，王 鵬，夏 真

(濟南市房產測繪研究院，山東 濟南 250001)

近幾年來，隨著互聯網不斷推廣與普及，移動通訊網絡不斷完善和提速，使得數據訪問量和數據體量爆炸式增長，大數據和云計算為“智慧住建”建設帶來了契機，濟南市“住建一張圖”平臺建設也在向信息化和智慧化轉變。隨著民眾對方便快捷地獲取公共服務的需求日益迫切，住建系統的業務量、訪問量和數據流量快速增長，而傳統單機數據庫所支持的并發數、吞吐量難以滿足這一現狀。因此，亟需尋找一種新的數據庫模式來實現系統的高并發、高吞吐率、高可用性[1-4]。

結合濟南市“智慧住建”建設方案，決定采用MySQL NDB分布式存儲引擎和負載均衡技術，使用一組普通性能服務器，搭建一套高吞吐、高并發和可動態擴展的MySQL NDB 集群數據庫。MySQL NDB 集群采用分布式部署，由多臺服務器存儲數據，提高數據完整性和可用性；由多臺服務器提供SQL客戶端，有效提高并發訪問數量；通過負載均衡技術，可實現讀寫分離，有效提高吞吐數據量[5]。

本文提出一套詳細的MySQL NDB 集群解決方案，以普通服務器組建高吞吐、高并發和高可用的集群數據庫，以及數據庫集群負載均衡方法和數據庫集群性能的具體測試方案。

1 MySQL NDB集群高性能解決方案

1.1 “住建一張圖”的現狀

濟南市“住建一張圖”管理系統邏輯框架共五層，分別為硬件支撐層、數據存儲層、GIS分析層、接口層、應用系統層。其中，“住建一張圖”系統“數據層”可以劃分為兩大類數據：空間地理數據和住建業務數據。濟南市住房和城鄉建設局主管全市住房建設工作，所需整合的地理空間數據包括全市的二維地圖數據、房屋圖層數據約100萬房屋幢圖斑、各業務專題圖數據2 TB等；所需整合的業務專題數據包括項目報建、圖審、工程監理、竣工驗收、房產交易、維修資金、征收拆遷、物業管理、房屋安全、城市更新、老舊小區、直管公房、房改房、住房保障、房屋租賃等數據，數據量約9 000余萬條，涉及數據種類繁多，數據繁雜，數據量巨大。

當前濟南市住房和城鄉建設局多系統獨立并存的工作模式，造成各類業務數據資源數據指標不一、條塊分割、壁壘嚴重，喪失了信息應有的流動性；數據存在重復存儲、重復更新問題且信息不能橫向互聯互通，難以提供有效的科學分析和決策支持；信息研判多停留在對單項業務信息的分析、判斷，未能充分整合數據資源，進行全方位、多角度的剖析和提取，沒有深層次挖掘大數據的價值以輔助各部門科學決策。因此，根據濟南市“智慧住建”的規劃方案和大數據中心建設需求，將數據和業務進行集成，建設全市統一的住建信息數據庫，提供高效海量數據存儲、快速訪問和更新、全業務綜合分析應用等數據服務。

1.2 MySQL NDB集群架構方案

1.2.1 邏輯架構

MySQL集群采用NDB Cluster高冗余的存儲引擎，以保證數據的完整性，集群采用的是MySQL Cluster + MySQL Router的四層集群負載均衡部署方案，集群邏輯架構圖如圖1所示。

圖1 集群邏輯架構圖

該MySQL集群系統由客戶端應用程序、Router節點、SQL節點、數據節點和管理節點五部分組成?？蛻舳耸紫仍L問負載均衡的Router節點，而Router節點循環連接各SQL節點來訪問數據節點[6-7]，各個節點由管理節點統一管理。

(1)Router節點

Router節點代理流量轉發，實現負載均衡。多客戶端可并發訪問Router節點時，該節點循環連接各SQL節點，如果其中一個SQL斷開，Router節點會自動尋找下一SQL節點，確保集群正常使用。

(2)SQL節點

SQL節點提供客戶端訪問集群數據的接口，存儲集群數據的表結構，并且每次插入數據，所有數據節點均同步保存。

(3)數據節點

MySQL集群中，數據節點用于存儲集群中的數據，NDB引擎會根據數據節點數目將數據進行分布式存儲，確保各數據節點上數據分片的完整性。

(4)管理(MGM)節點

它負責對集群中各節點進行管理，包括對各類節點的啟動、停止、維護等操作，并記錄集群的操作日志。

1.2.2 部署架構

根據濟南市智慧“住建一張圖”的建設需求，構建了MySQL NDB 集群數據庫，并部署在浪潮政務云上，部署架構圖如圖2所示。

圖2 集群部署架構圖

其中，4臺服務器部署SQL節點和數據節點，2臺服務器部署2個管理節點。通過負載均衡技術，將SQL節點地址路由映射為政務云內網IP地址，再通過Nginx代理，將政務云IP地址代理為外網虛擬IP地址。負載均衡節點與管理節點均采用主從配置，可有效減少宕機風險，提高集群可用性。每個SQL節點均獨立部署，避免單點故障；4個數據節點分為兩個Group和四個分區，每個分區都在同一個Group里面有多個拷貝，確保數據的完整性[8-9]。

1.3 負載均衡方案

使用MySQL Router中間件代理流量轉發，實現負載均衡，具體解決方案如圖3所示。

圖3 負載均衡邏輯架構圖

負載均衡節點采用主從配置，若主節點出現故障，副節點會主動接管，主從節點之間采用心跳監測確保有效通信。

MySQL Router實現了流量分發，避免了只向一個SQL節點導入流量，如果當前的實例宕機了，就會向集群的下一個SQL導入流量。同時，MySQL Router實現了讀寫分離，根據集群使用場景讀寫任務的輕重，合理分配讀寫SQL節點數量[10]。

2 應用案例

2.1 安裝與配置

本次數據庫集群搭建使用了七臺浪潮云服務器，其中一臺在政務外網，可登錄Internet訪問該服務器，其它六臺在政務內網，Internet不能直接訪問，二者之間通過網閘控制連通實現隔離。部署環境為CentOS8.0和64位處理器架構，MySQL集群數據庫版本為mysql-cluster-8.0.22-el7-x86_64.tar.gz，MySQL負載均衡版本為mysql-router-cluster-8.0.22-el7-x86_64.tar.gz。

2.1.1 集群管理

集群數據庫安裝版本為 MySQL NDB Cluster 8.0，集群節點部署在六臺服務器上，各節點IP分配如表1所示。

表1 節點IP與Port

其中，11和12兩臺服務器是管理節點；13～16四臺服務器為數據節點和SQL節點，需要配置大內存，其配置內存是數據量的2倍時，集群運行效率較佳。

2.1.2 Router配置

啟用兩臺服務器作為負載均衡節點，分別安裝負載均衡軟件MySQL-Router 8.0，安裝版本與MySQL數據庫版本一致。負載均衡節點配置的主要文件為mysqlrouter.conf，主要配置負載均衡規則、負載均衡綁定IP地址、Port端口和需負載均衡SQL節點地址，具體配置如表2所示。

表2 負載均衡節點IP與Port

MySQL Router有兩種路由規則：循環訪問與優先訪問，此實例中，7001端口對應循環訪問，7002端口對應優先訪問。負載均衡SQL節點地址為：172.20.99.13: 3306, 172.20.99.14:3306, 172.20.99.15:3306, 172.20.99.16:3306。

2.1.3 Nginx代理

政務外網上服務器使用Nginx代理政務內網上的數據庫集群，將負載均衡生成的虛擬IP和Port代理為政務外網地址，進一步隔離內網數據，提高數據安全。其中，Nginx的配置文件為nginx.conf文件，主要完成代理IP端口和目標URL的配置，一個Nginx服務可以代理多個URL，具體Nginx服務器IP地址為:172.20.99.10，其具體配置如表3所示。

表3 Nginx代理IP與端口號

將浪潮云內網上的數據集群訪問地址，均通過Nginx服務器代理為浪潮云外網地址，端口也可以重新映射，將內網集群數據有效隔離在內網中。

2.2 數據庫構建

MySQL NDB集群可創建兩種類型的表，分別為內存表和磁盤表。磁盤表僅將主鍵、索引字段保存在內存中，其他字段數據皆保存至磁盤文件中，因此，磁盤表檢索效率比較低。內存表將所有字段和索引數據都保存在內存中，同時，也在磁盤上保存一份數據文件，數據節點會在啟動的時候把數據加載到內存，因此，內存表的檢索效率較高。

2.2.1 創建內存表

MySQL集群默認創建內存表，創建過程如下：

drop table if exists zjjdb.tb_test1；

create table zjjdb.tb_test1 (

f_id int(10)not null auto_increment，

f_addr varchar(255)default null，

primary key(f_id) using btree

)

engine=ndbcluster auto_increment=1 ;

2.2.2 創建磁盤表

MySQL Cluster磁盤表有以下三種：

Undo log files：存儲事務進行回滾需要的信息。

Tablespaces：表空間，作為磁盤表的容器。

Data files：是與表空間相關聯的數據文件。

2.2.3 數據表的分片存儲

MySQL集群中的NDB表默認自動分片，分片的數量等于數據節點數目，也可手動分庫分表進行分片。

2.3 住建數據導入

在數據導入之前，首先，創建好要導入的數據庫及數據表結構，以規避不同數據庫之間數據類型及編碼差異造成數據導入的失敗。有以下三種常用數據導入方式。

2.3.1 數據包導入

對接的業務科室，如果不在同一網段，則需要對方提供靜態的數據，包括Excel文件、oracle數據庫導出的dmp數據包、MySQL Migration Toolkit工具生產的sql文件等，將這些靜態的數據包導入到集群數據庫。

2.3.2 Navicat數據傳輸

對接的業務科室，如果可以相互ping通，則用Navicat直連，用其自帶的“數據傳輸”工具，進行數據導入。

2.3.3 Kettle增量傳輸

如果對接的業務數據每天都有新增，則需要用Kettle每天增量抽取，在抽取之前，應與相關業務部門商榷，規定好時間戳字段，以便日后維護使用。

2.4 性能測試

根據業務需要，主要測試MySQL Cluster數據庫并發讀寫能力、并發事務處理能力和吞吐能力，以及數據庫的可用性和穩定性，得到集群較優配置，來滿足用戶對數據庫的應用需求，為公司大型應用的去IOE提供科學依據。

本次測試使用的服務器CPU參數為 Intel Core i7-9700K 3.60 GHz，運行內存為32 G。

2.4.1 并發寫能力測試

將數據節點的水平擴展，選擇了百萬和千萬兩種量級的數據規模，進行對數據庫的并發寫測試，以考察擴展數據節點對集群連續寫性能的影響，測試結果如表4所示。

表4 2～4個數據節點并發寫能力測試結果匯總表/s

2.4.2 吞吐能力測試

將數據節點的水平擴展，測試MySQL集群在百萬和十萬兩種量級的高并發請求下吞吐能力的變化趨勢，以考察數據節點的擴展對吞吐能力的影響，測試結果如表5所示。

表5 2～4個數據節點吞吐能力測試結果匯總表/(請求數/s)

2.4.3 并發事務處理能力測試

采用對比測試方案， 橫向擴展SQL節點和數據節點，對比集群并發事務處理能力，數據規模維持在百萬量級，由5個SQL客戶端，測試多個用例在同一時刻并發執行。

在4個SQL數據節點情況下，橫向擴展NDB數據節點，其測試結果如表6所示。

在4個NDB數據節點情況下，橫向擴展SQL節點，其測試結果如表7所示。

2.4.4 可用性測試

測試MySQL集群的管理節點、SQL節點、數據節點是否存在單點故障，強制某一節點服務器關機，測試集群依然能正常運行。

2.4.5 穩定性測試

MySQL集群運行10 d以上，訪問十億余次，表現穩定。

2.4.6 測試結論

(1)橫向擴展SQL節點和數據節點，集群性能近似線性增長。

(2)MySQL集群的可用性高。

(3)MySQL集群有較高的穩定性。

(4)MySQL集群橫向擴展成本低，易動態擴展。

(5)擴展內存對數據節點性能影響較明顯；提高CPU頻率對SQL節點性能影響較明顯。

3 應用總結

3.1 建立集群數據庫的應用場景

已優化SQL語句及索引，且單臺數據庫服務器難以滿足訪問需求時，需建立集群數據庫，將通信壓力分攤到各個集群節點，可初步解決數據通信瓶頸問題。

3.2 提高數據庫集群性能

面對千萬級別訪問量，且單機數據庫服務器性能無法顯著提高時，可使用多臺普通性能服務器架構數據庫集群，以應對數據庫高并發、高負載，提高數據庫可用性。

3.3 現階段存在問題

訪問量越大，請求響應速度越慢；更新或插入數據量較大時，會出現鎖表和線程阻塞等。以上問題可以通過限制訪問數量或者更新數據量進行規避，目前并未找到更好的解決辦法。

4 結 語

本文針對濟南市“住建一張圖”項目的具體應用需求，提出一套基于NDB引擎的MySQL集群數據庫高性能解決方案。該方案集群系統可由普通性能設備組建，由MySQL Router中間件代理流量轉發，實現系統高并發和高吞吐，且同步更新每個數據節點上的分片，確保各數據節點的完整性，基本能夠滿足項目需要。目前，集群已完成部署測試，初步達到預期效果，且運行穩定，實現負載均衡、數據同步及故障切換。