前言:node
MySQL Cluster 是一個基於 NDB Cluster 存儲引擎的完整的分佈式數據庫系統。不只僅具備高可用性,並且能夠自動切分數據,冗餘數據等高級功能。和 Oracle Real Cluster Application 不太同樣的是,MySQL Cluster 是一個 Share Nothing 的架構,各個 MySQL Server 之間並不共享任何數據,高度可擴展以及高度可用方面的突出表現是其最大的特點。
雖然目前還只是 MySQL 家族中的一個新興產品,可是已經有很多企業正在積極的嘗試使用了。本章咱們將經過對 MySQL Cluster 的瞭解來尋找其在可擴展設計方面的優點。mysql
16.1 MySQL Cluster介紹web
簡單的說,MySQL Cluster其實是在無共享存儲設備的狀況下實現的一種徹底分佈式數據庫系統,其主要經過NDB Cluster(簡稱NDB)存儲引擎來實現。MySQL Cluster 剛剛誕生的時候能夠說是一個能夠對數據進行持久化的內存數據庫,全部數據和索引都必須裝載在內存中才可以正常運行,可是最新的 MySQL Cluster 版本已經能夠作到僅僅將全部索引裝載在內存中便可,實際的數據能夠不用所有裝載到內存中。
一個MySQL Cluster的環境主要由如下三部分組成:
a) SQL層的SQL服務器節點(後面簡稱爲SQL節點),也就是咱們常說的MySQL Server。
主要負責實現一個數據庫在存儲層之上的全部事情,好比鏈接管理,Query 優化和響應, Cache 管理等等,只有存儲層的工做交給了 NDB 數據節點去處理了。也就是說,在純粹的MySQL Cluster環境中的SQL節點,能夠被認爲是一個不須要提供任何存儲引擎的 MySQL服務器,由於他的存儲引擎有Cluster環境中的 NDB 節點來擔任。因此,SQL層各MySQL 服務器的啓動與普通的 MySQL Server 啓動也有必定的區別,必需要添加ndbcluster參數選項才行。咱們能夠添加在my.cnf配置文件中,也能夠經過啓動命令行來指定。
b) Storage 層的 NDB 數據節點,也就是上面說的 NDB Cluster。
最初的 NDB 是一個內存式存儲引擎,固然也會將數據持久化到存儲設備上。可是最新的 NDB Cluster 存儲引擎已經改進了這一點,能夠選擇數據是所有加載到內存中仍是僅僅加載索引數據。NDB 節點主要是實現底層數據存儲功能,來保存Cluster的數據。每個Cluster節點保存完整數據的一個fragment,也就是一個數據分片(或者一份完整的數據,視節點數目和配置而定),因此只要配置得當,MySQL Cluster在存儲層不會出現單點的問題。通常來講,NDB 節點被組織成一個一個的NDB Group,一個NDB Group實際上就是一組存有徹底相同的物理數據的NDB節點羣。
上面提到了NDB各個節點對數據的組織,可能每一個節點都存有所有的數據也可能只保存一部分數據,主要是受節點數目和參數來控制的。首先在MySQL Cluster主配置文件(在管理節點上面,通常爲config.ini)中,有一個很是重要的參數叫NoOfReplicas,這個參數指定了每一份數據被冗餘存儲在不一樣節點上面的份數,該參數通常至少應該被設置成2,也只須要設置成2就能夠了。由於正常來講,兩個互爲冗餘的節點同時出現故障的機率仍是很是小的,固然若是機器和內存足夠多的話,也能夠繼續增大來更進一步減少出現故障的機率。
此外,一個節點上面是保存全部的數據仍是一部分數據還受到存儲節點數目的限制。NDB存儲引擎首先保證NoOfReplicas參數配置的要求來使用存儲節點,對數據進行冗餘,而後再根據節點數目將數據分段來繼續使用多餘的NDB節點。分段的數目爲節點總數除以NoOfReplicas所得。
c) 負責管理各個節點的Manage節點主機:
管理節點負責整個Cluster集羣中各個節點的管理工做,包括集羣的配置,啓動關閉各節點,對各個節點進行常規維護,以及實施數據的備份恢復等。管理節點會獲取整個Cluster環境中各節點的狀態和錯誤信息,而且將各Cluster集羣中各個節點的信息反饋給整個集羣中其餘的全部節點。因爲管理節點上保存了整個Cluster環境的配置,同時擔任了集羣中各節點的基本溝通工做,因此他必須是最早被啓動的節點。
下面是一幅 MySQL Cluster 的基本架構圖(出自 MySQL 官方文檔手冊):sql
經過圖中咱們能夠更清晰的瞭解整個 MySQL Cluster 環境各個節點以及客戶端應用之間的關係。
因爲 MySQL Cluster 目前的成熟使用並非太多,實現也較普通的 MySQL 略複雜,因此本章將首先從如何搭建一個 MySQL Cluster 環境開始來介紹他。數據庫
16.2 MySQL Cluster環境搭建數組
搭建MySQL Cluster首先須要至少一個管理節點主機來實現管理功能,一個SQL節點主機來實現MySQL server功能和兩個ndb節點主機實現NDB Cluster的功能。在後面的介紹中,我採用雙SQL節點來搭建測試環境,具體信息以下:
一、硬件準備 服務器
a) MySQL節點1 192.168.0.1 b) MySQL節點2 192.168.0.2 c) ndb節點1 192.168.0.3 d) ndb節點2 192.168.0.4 e) 管理節點 192.168.0.5
二、軟件安裝
首先在上面5個節點的主機上儘可能確保環境基本一致,而後從MySQL官方下載相應的軟件包並分發到兩臺SQL節點和兩臺NDB節點上,以備後面的安裝時候的使用。
個人測試環境OS(RedHat Linux)以下(非必須): 網絡
root@mysql1:/usr/local>uname -a Linux oratest1 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux
a) 安裝MySQL節點:
在MySQL節點上面須要安裝支持cluster的MySQL Server,能夠經過自編譯源代碼安裝也能夠選擇MySQL官方提供的編譯好的tar包或者rpm安裝包,我是經過源代碼自行編譯的,實際上徹底能夠經過MySQL官方提供的通過優化編譯的二進制tar包,只是我本身習慣了而已,個人編譯設置參數以下: 架構
root@mysql1>./configure \ --prefix=/usr/local/MySQL \ --without-debug \ --without-bench \ --enable-thread-safe-client \ --enable-assembler \ --with-charset=utf8 \ --with-extra-charsets=complex \ --with-client-ldflags=-all-static \ --with-MySQLd-ldflags=-all-static \ --with-ndbcluster \ --with-server-suffix=-max \ --datadir=/data/mysqldata \ --with-unix-socket-path=/usr/local/MySQL/sock/mysql.sock ... root@mysql1>make ... root@mysql1>make install ...
而後是配置設置配置文件/etc/my.cnf,因爲是測試環境,因此我僅僅設置了ndbcluster所須要的最基本的兩個配置項,其餘全部的配置均用默認配置(後面會有較爲詳細的配置說明),以下: 併發
root@mysql1>vi /etc/my.cnf [client] socket = /usr/local/mysql/sock/mysql.sock #因爲編譯時候特殊指定了,因此設置在這裏,方便之後登入的時候使用 [MySQLd] socket = /usr/local/mysql/sock/mysql.sock ndbcluster [MySQL_cluster] ndb-connectstring = 192.168.0.5
繼續完成後面的MySQL安裝過程:
root@mysql1>cd /usr/local/mysql root@mysql1>bin/mysql_install_db --user=mysql -- socket=/usr/local/mysql/sock/mysql.sock Installing MySQL system tables... OK Filling help tables... OK To start MySQLd at boot time you have to copy support-files/MySQL.server to the right place for your system PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! To do so, start the server, then issue the following commands: /usr/local/mysql/bin/MySQLadmin -u root password 'new-password' /usr/local/mysql/bin/MySQLadmin -u root -h ointest_stb password 'new- password' Alternatively you can run: /usr/local/mysql/bin/MySQL_secure_installation which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the manual for more instructions. You can start the MySQL daemon with: cd /usr/local/MySQL ; /usr/local/mysql/bin/MySQLd_safe You can test the MySQL daemon with MySQL-test-run.pl cd MySQL-test ; perl MySQL-test-run.pl Please report any problems with the /usr/local/mysql/bin/MySQLbug script! The latest information about MySQL is available on the web at http://www.mysql.com Support MySQL by buying support/licenses at http://shop.mysql.com root@mysql1>chown -R root . root@mysql1>chgrp -R mysql . root@mysql1>chown -R mysql.mysql /usr/local/mysql/etc root@mysql1>chown -R mysql.mysql /usr/local/mysql/sock root@mysql1>chown -R mysql.mysql /usr/local/mysql/log root@mysql1>:/usr/local/mysql# ls -l total 40 drwxr-xr-x 2 root MySQL 4096 May 4 14:47 bin drwxr-xr-x 2 MySQL MySQL 4096 May 4 14:20 etc drwxr-xr-x 3 root MySQL 4096 May 4 14:46 include drwxr-xr-x 2 root MySQL 4096 May 4 14:46 info drwxr-xr-x 3 root MySQL 4096 May 4 14:46 lib drwxr-xr-x 2 root MySQL 4096 May 4 14:47 libexec drwxr-xr-x 2 MySQL MySQL 4096 May 4 14:20 log drwxr-xr-x 4 root MySQL 4096 May 4 14:47 man drwxr-xr-x 9 root MySQL 4096 May 4 14:47 MySQL-test drwxr-xr-x 2 MySQL MySQL 4096 May 5 22:16 sock root@mysql1>:/usr/local/mysql#
b) 安裝ndb節點:
若是但願儘量的各環境保持一致,建議在NDB節點也和SQL節點同樣安裝整個帶有NDB Cluster存儲引擎的MySQL Server。因爲安裝細節和上面的SQL節點徹底同樣, 因此這裏就再也不累述。
另外,若是隻是爲了保證可以完整的MySQL Cluster這個環境,則在NDB節點上徹底能夠僅安裝NDB存儲引擎(mysql ndb storage engine)便可。安裝NDB存儲引擎好像目前是找不到源碼來自行編譯安裝的,只能經過MySQL AB官方提供的rpm包來安裝。安裝過程很是簡單,和其餘的rpm軟件包安裝沒有任何區別。
c) 管理節點:
管理節點所須要的安裝更簡單,實際上只須要ndb_mgm和ndb_mgmd兩個程序便可,這兩個可執行程序能夠在上面的MySQL節點的MySQL安裝目錄中的bin目錄下面找到。將這兩個程序copy到管理節點上面合適的位置(自行考慮,我通常會放在/usr/local/mysql/bin下面),並在path制定的目錄中創建兩個同名的soft link在到這兩個程序上面,就能夠了。
以上便是MySQL Cluster環境的軟件安裝過程,看上去並不複雜是吧,但願你們的安裝過程也可以一切順利,固然若是遇到了什錯誤也不用擔憂,MySQL官方手冊中也提供了很是詳細的安裝過程說明。
三、基本配置
在上面全部節點的軟件安裝完成以後,就是MySQL Cluster環境的配置工做了。若是不考慮其餘一些優化和個性化的配置需求,MySQL Cluster的基本配置是比較簡單的。這裏暫時先僅僅完成一個簡單的測試環境的配置,詳細的配置說明請看後面的MySQL Cluster配置介紹的章節。
對於MySQL節點和ndb節點在上面的安裝過程當中已經完成了,僅須要設置[MySQL_cluster]參數組的ndb-connectstring參數便可完成最基本的配置。
管理節點的配置稍微複雜一點,由於他須要配置出Cluster環境中每個節點的基本信息。配置文件並不須要一個特別固定的位置和名稱,都由用戶自行設定,只須要在啓動過程當中指定配置文件便可。在咱們的測試環境中配置爲建名稱爲/var/lib/MySQL-cluster/config.ini,內容以下:
[root@mysqlMgm ~]# cat /var/lib/mysql-cluster/config.ini [NDBD DEFAULT] NoOfReplicas=2 DataMemory=64M IndexMemory=16M [TCP DEFAULT] portnumber=2202 #管理節點 [NDB_MGMD] id=1 hostname=192.168.0.5 datadir=/var/lib/mysql-cluster #第一個ndbd節點: [NDBD] id=2 hostname=192.168.0.3 datadir=/data/mysqldata #第二個ndbd節點: [NDBD] id=3 hostname=192.168.0.4 datadir=/drbddata/mysqldata # SQL node options: [MySQLD] id=4 hostname=192.168.0.1 [MySQLD] id=5 hostname=10.0.65.203 [root@mysqlMgm ~]#
1) SQL節點的配置:
MySQL節點的配置和普通的MySQL Server的配置區別主要是須要在my.cnf文件中增長[mysql_cluster]這個配置選項組,並至少指定ndb-connectstring=192.168.0.5,也就是制定管理節點的ip地址或者hostname。另外,若是但願能在啓動MySQLd的時候不用手動指定ndbcluster參數,則在[mysqld]參數選項組中增長ndbcluster項參數。除了這兩項以外,其餘的全部參數均可以可使用默認值。
2) NDB存儲節點的配置:
NDB存儲節點的配置就更簡單的了,僅僅需[mysql_cluster]中的ndb-connectstring = 192.168.0.5 參數,其餘全部的均可以再也不配置了。
四、環境測試
在MySQL Cluster環境搭建完成後,首先確定要對新搭建的環境進行一些基本的功能和異常測試,以確認搭建的環境是否已經能夠正常提供服務。
1) 首先檢測ndb引擎是否已經正常工做
經過任意客戶端鏈接任意選定的一個SQL節點,測試各類基本的ddl,dml操做, 而後再經過客戶端鏈接上Cluster環境中另外的SQL節點校驗所做的草食是否在其餘節點一樣可見了。下面是測試create table 後再插入一條數據的示例:
在節點4上面:
mysql>use test; mysql>create table t1 ( a int) engine=ndb; Query ok, 0 rows affected (0.00 sec) mysql>insert into t1 values(100); Query ok, 1 rows affected (0.00 sec) 而後在節點5上面: mysql>use test; mysql>select * from t1; +-----+ | id | +-----+ | 100 | +-----+ 1 row in set (0.00 sec)
可見,在節點4上面所插入的數據,已經在節點5上面了,說明ndb引擎工做正常的。其餘的測試與此相似,你們能夠自行測試。
若是在測試中發如今某兩個節點之間出現不一致現象,那麼能夠確定的是,Cluster 環境的配置有問題。在管理節點上面經過「ndb_mgm -e SHOW」命令查看各節點狀態是否正常,是否都已經鏈接到了管理節點上面。並檢查不正常節點的my.cnf配置文件,是否已經配置好了以ndbcluster方式啓動MySQLd,是否有正確配置[mysql_cluster]這個參數組的最基本的ndb-connectstring參數。而後檢查管理節點上面的config文件,裏面是否有正確配置好各全部節點的配置,尤爲是不正常的SQL節點的配置。
2) 檢測冗餘環境的單點故障問題
a、模擬NDB節點Crash
因爲是模擬Crash,因此咱們經過在節點2上面kill掉ndb進程,而後再分別經過兩個SQL節點去訪問t1表,查看是否能夠正常訪問,數據是否同樣。
在節點4上面:
mysql> use test; mysql> select * from t1; +-----+ | id | +-----+ | 100 | +-----+ 1 row in set (0.00 sec) mysql> insert into t1 values(200); Query ok, 1 rows affected (0.00 sec)
在節點5上面:
mysql>use test; mysql>select * from t1; +-----+ | id | +-----+ | 100 | | 200 | +-----+ 2 row in set (0.00 sec) mysql> delete from t1 where id = 100; Query ok, 1 rows affected (0.00 sec)
再回到節點4上面:
mysql> select * from t1; +-----+ | id | +-----+ | 200 | +-----+ 1 row in set (0.00 sec)
能夠看到,不只t1仍然能夠正常訪問,數據也沒有任何丟失,且仍然能夠正常插入,刪除數據。可見,在有一個NDB節點Crash以後,真個MySQL Cluster環境仍然能夠正常提供服務。固然,若是兩個NDB節點都Crash以後,MySQL Cluster環境就沒法正常提供服務了,你們也能夠自行測試一下。
b、模擬SQL節點Crash
一樣和測試NDB節點Crash同樣,kill掉一個SQL節點(好比節點4)的mysqld 進程,而後經過節點5進行訪問:
在節點5上面:
mysql> use test; mysql> select * from t1; +-----+ | id | +-----+ | 200 | +-----+ 1 row in set (0.00 sec) mysql> insert into t1 values(300); Query ok, 1 rows affected (0.00 sec) mysql> select * from t1; +-----+ | id | +-----+ | 200 | | 300 | +-----+ 2 row in set (0.00 sec)
能夠看到,當節點4 Crash以後,節點5仍然可以提供正常的服務。固然,若是在應用環境中,應用環境須要至少支持當一個SQL節點出現問題的時候可以自行切換到剩下的正常的SQL節點來訪問。
c、管理節點的單點
通常狀況來講,管理節點是最容易控制的,實施也很是簡單,只須要將配置文件和
兩個可執行程序(ndb_mgmd和ndb_mgm)存放在多臺機器上面便可,因此通常來講不須要太多考慮單點故障。
16.3 MySQL Cluster配置詳細介紹(config.ini)
在MySQL Cluster環境的配置文件config.ini裏面,每一類節點都有兩個(或以上)的相應配置項組,每一類節點的配置項都主要由兩部分組成,一部分是同類全部節點相同的配置項組,在[NDB_MGM DEFAULT]、[NDBD DEFAULT]和[MySQLD DEFAULT]這三個配置組裏面, 並且每個配置組只出現一次;而另一部分則是針對每個節點獨有配置內容的配置項組[NDB_MGM]、[NDBD]和[MySQLD],因爲這三類配置組中配置的每個節點獨有的個性化配置,因此每個配置組均可能會出現屢次(每個節點一次)。下面是每一類節點的各類配置說明:
一、管理節點相關配置
在整個MySQL Cluster環境中,管理節點相關的配置爲[NDBD_MGM DEFAULT]和[NDB_MGMD]相關的兩組:
1) [NDB_MGMD DEFAULT]中各管理節點的共用配置項:
PortNumber:配置管理節點的服務端程序(ndb_mgmd)監聽客戶端(ndb_mgm)鏈接請求和發送的指令,從文檔上能夠查找到,默認端口是1186端口。通常來講這一項不須要更改,固然若是是爲了在同一臺主機上面啓動多個管理節點的話,確定須要將兩個管理節點啓動不一樣的監聽端口;
LogDestination:配置管理節點上面的cluster日誌處理方式。
a) 能夠寫入文件如:LogDestination=FILE:filename=my-
cluster.log,maxsize=500000,maxfiles=4;
b) 也能夠經過標準輸出來打印出來如:LogDestination=CONSOLE;
c) 還能夠計入syslog裏面如:LogDestination=SYSLOG:facility=syslog;
d) 甚至多種方式共存:
LogDestination=CONSOLE;SYSLOG:facility=syslog;FILE:filename=/var/log/cluster- log
Datadir:設置用於管理節點存放文件輸出的位置。如process文件(.pid),cluster log文件(當LogDestination有FILE處理方式存在時候)。
ArbitrationRank:配置各節點在處理某些事件出現分歧的時候的級別。有0,1,2 三個值能夠選擇。
a) 0表明本節點徹底聽其餘節點的,不參與決策
b) 1表明本節點有最高優先權,「一切由我來決策」
c) 2表明本節點參與決策,可是優先權較1低,可是比0高
ArbitrationRank參數不只僅管理節點有,MySQL節點也有。並且通常來講,全部的管理節點通常都應該設置成1,全部SQL節點都設置成2。
2) [NDB_MGMD]是每一個管理節點配置一組,所需配置項以下(下面的參數只能設置在[NDB_MGMD]參數組中):
Id:爲節點指定一個惟一的ID號,要求在整個Cluster環境中惟一;
Hostname:配置該節點的IP地址或者主機名,若是是主機名,則該主機名必需要在配置文件所在的節點的/etc/hosts文件中存在,並且綁定的IP是準確的。
上面[NDB_MGMD DEFAULT]裏面的全部參數項,均可以設置在下面的[NDB_MGMD]參數組裏面,可是Id和Hostname兩個參數只能設置在[NDB_MGMD]裏面,而不能設置在[NDB_MGMD DEFAULT]裏面,由於這兩個參數項針對每個節點都是不相同的內容。
二、NDB節點相關配置
NDB節點和管理節點同樣,既有各個節點共用的配置信息組[NDBD DEFAULT],也有每個節點個性化配置的[NDBD]配置組(實際上SQL節點也是如此)。
1) [NDBD DEFAULT]中的配置項:
NoOfReplicas:定義在Cluster環境中相同數據的分數,通俗一點來講就是每一份數據存放NoOfReplicas份。若是但願可以冗餘,那麼至少設置爲2(通常狀況來講此參數值設置爲2就夠了),最大隻能設置爲4。另外,NoOfReplicas值得大小,實際上也就是node group大小的定義。NoOfReplicas參數沒有系統默認值,因此必須設定,並且只能設置在[NDBD DEFAULT]中,由於此數值在整個Cluster集羣中一個node group中全部的NDBD節點都須要同樣。另外NoOfReplicas的數目對整個Cluster環境中NDB節點數量有較大的影響, 由於NDB節點總數量是NoOfReplicas * 2 * node_group_num;
DataDir:指定本地的pid文件,trace文件,日誌文件以及錯誤日誌子等存放的路徑,無系統默認地址,因此必須設定;
DataMemory:設定用於存放數據和主鍵索引的內存段的大小。這個大小限制了能存放的數據的大小,由於ndb存儲引擎需屬於內存數據庫引擎,須要將全部的數據(包括索引)都load到內存中。這個參數並非必定須要設定的,可是默認值很是小(80M),只也就是說若是使用默認值,將只能存放很小的數據。參數設置須要帶上單位,如512M,2G等。另外,DataMemory裏面還會存放UNDO相關的信息,因此,事務的大小和事務併發量也決定了DataMemory的使用量,建議儘可能使用小事務;
IndexMemory:設定用於存放索引(非主鍵)數據的內存段大小。和DataMemory相似,這個參數值的大小一樣也會限制該節點能存放的數據的大小,由於索引的大小是隨着數據量增加而增加的。參數設置也如DataMemory同樣須要單位。IndexMemory默認大小爲18M;
實際上,一個NDB節點能存放的數據量是會受到DataMemory和IndexMemory兩個參數設置的約束,二者任何一個達到限制數量後,都沒法再增長能存儲的數據量。若是繼續存入數據系統會報錯「table is full」。
FileSystemPath:指定redo日誌,undo日誌,數據文件以及meta數據等的存放位置,默認位置爲DataDir的設置,而且在ndbd初始化的時候,參數所設定的文件夾必須存在。在第一次啓動的時候,ndbd進程會在所設定的文件夾下創建一個子文件夾叫ndb_id_fs,這裏的id爲節點的ID值,如節點id爲3則文件夾名稱爲ndb_3_fs。固然,這個參數也不必定非得設置在[NDBD DEFAULT]參數組裏面讓全部節點的設置都同樣(不過建議這樣設置),還能夠設置在[NDBD]參數組下爲每個節點單獨設置本身的FileSystemPath值;
BackupDataDir:設置備份目錄路徑,默認爲FileSystemPath/BACKUP。
接下來的幾個參數也是很是重要的,主要都是與並行事務數和其餘一些並行限制有關的參數設置。
MaxNoOfConcurrentTransactions:設置在一個節點上面的最大並行事務數目,默認爲4096,通常狀況下來講是足夠了的。這個參數值全部節點必須設置同樣,因此通常都是設置在[NDBD DEFAULT]參數組下面;
MaxNoOfConcurrentOperations:設置同時可以被更新(或者鎖定)的記錄數量。
通常來講能夠設置爲在整個集羣中相同時間內可能被更新(或者鎖定)的總記錄數,除以NDB節點數,所獲得的值。好比,在集羣中有兩個NDB節點,而但願可以處理同時更新(或鎖定)100000條記錄,那麼此參數應該被設置爲:100000 / 4 = 25000。此外,這裏的記錄數量並非指單純的表裏面的記錄數,而是指事物裏面的操做記錄。當使用到惟一索引的時候,表的數據和索引二者都要算在裏面,也就是說,若是是經過一個惟一索引來做爲過濾條件更新某一條記錄,那麼這裏算是兩條操做記錄。並且即便是鎖定也會產生操做記錄,好比經過惟一索引來查找一條記錄,就會產生以下兩條操做記錄:經過讀取惟一索引中的某個記錄數據會產生鎖定,產生一條操做記錄,而後讀取基表裏面的數據,這裏也會產生讀鎖,也會產生一條操做記錄。MaxNoOfConcurrentOperations參數的默認值爲32768。當咱們額度系統運行過程當中,若是出現此參數不夠的時候,就會報出「Out of operation records in transaction coordinator」這樣的錯誤信息;MaxNoOfLocalOperations:此參數默認是MaxNoOfConcurrentOperations * 1.1 的大小,也就是說,每一個節點通常能夠處理超過平均值的10%的操做記錄數量。可是通常來講,MySQL建議單獨設置此參數而不要使用默認值,而且將此參數設置得更較大一些;
如下的三個參數主要是在一個事務中執行一條query的時候臨時用到存儲(或者內存)的狀況下所使用到的,所使用的存儲信息會在事務結束(commit或者rollback)的時候釋放資源;
MaxNoOfConcurrentIndexOperations:這個參數和MaxNoOfConcurrentOperations參數比較相似,只不過所針對的是Index的record而已。其默認值爲8192,對伊通常的系統來講都已經足夠了,只有在事務併發很是很是大的系統上纔有須要增長這個參數的設置。
固然,此參數越大,系統運行時候爲此而消耗的內存也會越大;
MaxNoOfFiredTriggers:觸發惟一索引(hash index)操做的最大的操做數,這個操做數是影響索引的操做條目數,而不是操做的次數。系統默認值爲4000,通常系統來講夠用了。固然,若是系統併發事務很是高,並且涉及到索引的操做也很是多,天然也就須要提升這個參數值的設置了;
TransactionBufferMemory:這個buffer值得設置主要是指定用於跟蹤索引操做而使用的。主要是用來存儲索引操做中涉及到的索引key值和column的實際信息。這個參數的值通常來講也不多須要調整,由於實際系統中須要的這部分buffer量很是小,雖然默認值只是1M,可是對於通常應用也已經足夠了;
下面要介紹到的參數主要是在系統處理中作table scan或者range scan的時候使用的一些buffer的相關設置,設置的恰當能夠既節省內存又達到足夠的性能要求。
MaxNoOfConcurrentScans:這個參數主要控制在Cluster環境中併發的table scan和range scan的總數量平均分配到每個節點後的平均值。通常來講,每個scan都是經過並行的掃描全部的partition來完成的,每個partition的掃描都會在該partition 所在的節點上面使用一個scan record。因此,這個參數值得大小應該是「scan record」 數目 * 節點數目。參數默認大小爲256,最大隻能設置爲500;
MaxNoOfLocalScans:和上面的這個參數相對應,只不過設置的是在本節點上面的併發table scan和range scan數量。若是在系統中有大量的併發並且通常都不使用並行的話,須要注意此參數的設置。默認爲MaxNoOfConcurrentScans * node數目;
BatchSizePerLocalScan:該參用於計算在Localscan(併發)過程當中被鎖住的記錄數,文檔上說明默認爲64;
LongMessageBuffer:這個參數定義的是消息傳遞時候的buffer大小,而這裏的消息傳遞主要是內部信息傳遞以及節點與節點之間的信息傳遞。這個參數通常不多須要調整,默認大小爲1MB大小;
下面介紹一下與log相關的參數配置說明,包括log level。這裏的log level有多種,從0到15,也就是共16種。若是設定爲0,則表示不記錄任何log。若是設置爲最高level,也就是15,則表示全部的信息都會經過標準輸出來記錄log。因爲這裏的全部信息實際上都會傳遞到管理節點的cluster log中,因此,通常來講,除了啓動時候的log級別須要設置爲1以外,其餘全部的log level都只須要設置爲0就能夠了。
NoOfFragmentLogFiles:這個參數實際上和Oracle的redo log的group同樣的。
其實就是ndb的redo log group數目,這些redo log用於存放ndb引擎所作的全部須要變動數據的事情,以及各類checkpoint信息等。默認值爲8;
MaxNoOfSavedMessages:這個參數設定了能夠保留的trace文件(在節點crash的時候參數)的最大個數,文檔上面說此參數默認值爲25。
LogLevelStartup:設定啓動ndb節點時候須要記錄的信息的級別(不一樣級別所記錄的信息的詳細程度不同),默認級別爲1;
LogLevelShutdown:設定關閉ndb節點時候記錄日誌的信息的級別,默認爲0;
LogLevelStatistic:這個參數是針對於統計相關的日誌的,就像更新數量,插入數量,buffer使用狀況,主鍵數量等等統計信息。默認日誌級別爲0;
LogLevelCheckpoint:checkpoint日誌記錄級別(包括local和global的),默認爲0;
LogLevelNodeRestart:ndb節點重啓過程日誌級別,默認爲0;
LogLevelConnection:各節點之間鏈接相關日誌記錄的級別,默認0;
LogLevelError:在整個Cluster中錯誤或者警告信息的日誌記錄級別,默認0;
LogLevelInfo:普通訊息的日誌記錄級別,默認爲0。
這裏再介紹幾個用來做爲log記錄時候須要用到的Buffer相關參數,這些參數對於性能都有必定的影響。固然,若是節點運行在無盤模式下的話,則影響不大。
UndoIndexBuffer:undo index buffer主要是用於存儲主鍵hash索引在變動以後產生的undo信息的緩衝區。默認值爲2M大小,最小能夠設置爲1M,對於大多數應用來講, 2M的默認值是夠的。固然,在更新很是頻繁的應用裏面,適當的調大此參數值對性能仍是有必定幫助的。若是此參數過小,會報出677錯誤:Index UNDO buffers overloaded;
UndoDataBuffer:和undo index buffer相似,undo data buffer主要是在數據發生變動的時候所須要的undo信息的緩衝區。默認大小爲16M,最小一樣爲1M。當這個參數值過小的時候,系統會報出以下的錯誤:Data UNDO buffers overloaded,錯誤號爲891;
RedoBuffer:Redo buffer是用redo log信息的緩衝區,默認大小爲8M,最小爲1M。
若是此buffer過小,會報1221錯誤:REDO log buffers overloaded。
此外,NDB節點還有一些和metadata以及內部控制相關的參數,但大部分參數都基本上不須要任何調整,因此就不作進一步介紹。若是有興趣但願詳細瞭解,能夠根據MySQL 官方的相關參考手冊,手冊上面都有較爲詳細的介紹。
三、SQL節點相關配置說明
1) 和其餘節點同樣,先介紹一些適用於全部節點的[MySQLD DEFAULT]參數ArbitrationRank:這個參數在介紹管理節點的參數時候已經介紹過了,用於設定節點級別(主要是在多個節點在處理相關操做時候出現分歧時候設定裁定者)的。通常來講,全部的SQL節點都應該設定爲2;
ArbitrationDelay:默認爲0,裁定者在開始裁定以前須要被delay多久,單位爲毫秒。通常不須要更改默認值。
BatchByteSize:在作全表掃描或者索引範圍掃描的時候,每一次fatch的數據量,默認爲32KB;
BatchSize:相似BatchByteSize參數,只不過BatchSize所設定的是每一次fetch的record數量,而不是物理總量,默認爲64,最大爲992(暫時還不知道這個值是基於什麼理論而設定的)。在實際運行query的過程當中,fetch的量受到BatchByteSize和BatchSize兩個參數的共同制約,兩者取最小值;
MaxScanBatchSize:在Cluster環境中,進行並行處理的狀況下,全部節點的BatchSize總和的最大值。默認值爲256KB,最大值爲16MB。
2) 每一個節點獨有的[MySQLD]參數組,僅有id和hostname參數須要配置,在以前各種節點均有介紹了,這裏就再也不累述。
16.4 MySQL Cluster基本管理與維護
MySQL Cluster的管理和普通的MySQL Server管理區別較大,基本上大部分管理工做都是在管理節點上面完成,僅有少數管理內容須要在其餘節點實施。
一、各節點啓動與關閉
要想Cluster環境可以正常工做,只好要啓動一個NDB節點和一個SQL節點,另外爲了完成管理,也至少要啓動一個管理節點。各種節點的啓動順序也有要求,首先是管理節點,而後是NDB節點,最後纔是SQL節點。
1) 按順序啓動各節點:
a、 啓動管理節點:
[root@localhost MySQL-cluster]# ndb_mgmd -f /var/lib/MySQL- cluster/config.ini
這裏執行的ndb_mgmd命令實際上就是MySQL Cluster管理服務器,能夠經過-f config_file_name或者--config=config_filename來指定MySQL Cluster集羣的參數文件。
若是想了解更多關於ndb_mgmd的參數信息,能夠經過運行ndb_mgmd --help來獲取更詳細的信息。
b、 啓動用於存儲數據的ndb節點要啓動存儲節點,必須在每一臺ndb節點主機上面都執行ndbd程序,若是是第一
次啓動,則須要添加--initial參數,以便進行ndb節點的初始化工做。可是,在之後的啓動過程當中,是不能添加該參數的,不然ndbd程序會清除在以前創建的全部用於恢復的數據文件和日誌文件。啓動命令以下
root@ndb1:/root>ndbd --initial
c、 啓動SQL節點
SQL節點的啓動和普通MySQL Server的啓動沒有太多明顯的差異,不過有一個前提就是須要在MySQL Server的配置文件my.cnf設置好[MySQL_cluster]配置組中的ndb-connectstring參數和[MySQLd]配置組中的ndbcluster參數。
root@mysql1:/root>MySQLd_safe --user=MySQL
2) 節點狀態檢查:
在各節點都啓動完成後,回到管理節點,能夠經過ndb_mgm來查看各節點狀態:
[root@localhost MySQL-cluster]# ndb_mgm -e SHOW Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=2 @192.168.0.3 (Version: 5.0.51, Nodegroup: 0, Master) id=3 @192.168.0.4 (Version: 5.0.51, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.0.5 (Version: 5.0.51) [MySQLd(API)] 2 node(s) id=4 @192.168.0.1 (Version: 5.0.51) id=5 @10.0.65.203 (Version: 5.0.51)
這裏顯示出整個集羣有5個幾點,其中各節點信息以下:
a) 2個NDBD節點:
[ndbd(NDB)] 2 node(s) id=2 @192.168.0.3 (Version: 5.0.51, Nodegroup: 0, Master) id=3 @192.168.0.4 (Version: 5.0.51, Nodegroup: 0) b) 兩個SQL節點: [MySQLd(API)] 2 node(s) id=4 @192.168.0.1 (Version: 5.0.51) id=5 @10.0.65.203 (Version: 5.0.51) c) 1個管理節點: [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.0.5 (Version: 5.0.51)
3) 節點的關閉操做:
在MySQL Cluster環境中,NDB節點和管理節點的關閉均可以在管理節點的管理程序中完成,可是SQL節點卻沒辦法。因此,在關閉整個MySQL Cluster環境或者關閉某個SQL節點的時候,首先必須到SQL節點主機上來關閉SQL節點程序。關閉方法和MySQL Server的關閉同樣,就不累述。而NDB節點和管理節點則均可以在管理節點經過管理程序來完成:
ndb_mgm> shutdown Connected to Management Server at: localhost:1186 Node 3: Cluster shutdown initiated Node 2: Cluster shutdown initiated Node 2: Node shutdown completed. Node 3: Node shutdown completed. 2 NDB Cluster node(s) have shutdown. Disconnecting to allow management server to shutdown.
二、基本管理維護
前面運行的命令ndb_mgm若是不帶任何參數,其實是進入MySQL Cluster的命令行管理界面。在命令行管理界面裏面能夠作大量的維護工做,以下:
[root@localhost MySQL-cluster]# ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm>
而後一樣執行show命令:
ndb_mgm>show Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=2 (not connected, accepting connect from 192.168.0.3) id=3 @192.168.0.4 (Version: 5.0.51, Nodegroup: 0, Master) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.0.5 (Version: 5.0.51) [MySQLd(API)] 2 node(s) id=4 @192.168.0.1 (Version: 5.0.51) id=5 @10.0.65.203 (Version: 5.0.51)
咱們能夠看到結果和上面的徹底同樣。能夠經過在ndb控制界面下執行help命令查看能夠查看不少基本的維護管理命令:
ndb_mgm> help --------------------------------------------------------------------------- NDB Cluster -- Management Client -- Help --------------------------------------------------------------------------- HELP Print help text HELP COMMAND Print detailed help for COMMAND(e.g. SHOW) SHOW Print information about cluster START BACKUP [NOWAIT | WAIT STARTED | WAIT COMPLETED] Start backup (default WAIT COMPLETED) ABORT BACKUP <backup id> Abort backup SHUTDOWN Shutdown all processes in cluster CLUSTERLOG ON [<severity>] ... Enable Cluster logging CLUSTERLOG OFF [<severity>] ... Disable Cluster logging CLUSTERLOG TOGGLE [<severity>] ... Toggle severity filter on/off CLUSTERLOG INFO Print cluster log information <id> START Start data node (started with -n) <id> RESTART [-n] [-i] Restart data or management server node <id> STOP Stop data or management server node ENTER SINGLE USER MODE <id> Enter single user mode EXIT SINGLE USER MODE Exit single user mode <id> STATUS Print status <id> CLUSTERLOG {<category>=<level>}+ Set log level for cluster log PURGE STALE SESSIONS Reset reserved nodeid's in the mgmt server CONNECT [<connectstring>] Connect to management server (reconnect if already connected) QUIT Quit management client <severity> = ALERT | CRITICAL | ERROR | WARNING | INFO | DEBUG <category> = STARTUP | SHUTDOWN | STATISTICS | CHECKPOINT | NODERESTART | CONNECTION | INFO | ERROR | CONGESTION | DEBUG | BACKUP <level> = 0 - 15 <id> = ALL | Any database node id For detailed help on COMMAND, use HELP COMMAND.
也能夠經過執行help後面跟命令名稱而獲取各類命令的操做說明幫助信息:
ndb_mgm> help start --------------------------------------------------------------------------- NDB Cluster -- Management Client -- Help for START command --------------------------------------------------------------------------- START Start data node (started with -n) <id> START Start the data node identified by <id>. Only starts data nodes that have not yet joined the cluster. These are nodes launched or restarted with the -n(--nostart) option. It does not launch the ndbd process on a remote machine. ndb_mgm> help shutdown --------------------------------------------------------------------------- NDB Cluster -- Management Client -- Help for SHUTDOWN command --------------------------------------------------------------------------- SHUTDOWN Shutdown the cluster SHUTDOWN Shutdown the data nodes and management nodes. MySQL Servers and NDBAPI nodes are currently not shut down by issuing this command. ndb_mgm> help PURGE STALE SESSIONS --------------------------------------------------------------------------- NDB Cluster -- Management Client -- Help for PURGE STALE SESSIONS command --------------------------------------------------------------------------- PURGE STALE SESSIONS Reset reserved nodeid's in the mgmt server PURGE STALE SESSIONS Running this statement forces all reserved node IDs to be checked; any that are not being used by nodes acutally connected to the cluster are then freed. This command is not normally needed, but may be required in some situations where failed nodes cannot rejoin the cluster due to failing to allocate a node id.
經過上面的幾個幫助命令所獲取的信息得知,咱們能夠經過在管理節點上面經過執行restart,stop,shutdown等基本的命令來重啓某個節點,關閉某個節點,還能夠同時一次性關閉全部節點。
此外,還能夠經過執行備份相關的命令在管理節點對整個Cluster環境進行備份,以及經過日誌相關命令實施對日誌的相關管理。
16.5 基本優化思路
MySQL Cluster 雖然是一個分佈式的數據庫系統,可是在大部分地方的優化思路和方法仍是和普通的 MySQL Server 同樣。和常規 MySQL Server 在優化方面的區別主要提如今各節點之間的協做配置以及網絡環境相關的優化。
因爲 MySQL Cluster 是一個分佈式的環境,並且全部訪問都是須要通過超過一個節點(至少有一個 SQL 節點和一個 NDB 節點)才能完成,因此各個節點之間的協做配合就顯得尤其重要。
首先,因爲各個節點之間存在大量的數據通信,因此節點之間的內部互聯網絡帶寬必定要保證足夠使用。爲了適應不一樣的網絡環境和性能需求,MySQL Cluster 支持了多種內部網絡互聯的協議和方式。最爲經常使用的天然是經過 TCP/IP 來進行互聯。此外還能夠有 SCI Socket 方式來進行互聯,還支持 Myrinet,Infiniband,VIA 接口等等。
其次,SQL 節點和 NDB 節點的主機性能配比應該合適,而不該該出現某一類節點過早出現瓶頸的時候,另一類節點卻還處於很是空閒的狀態。若是在咱們遇到的環境中出現這樣的狀況,那麼咱們就該從新評估兩類節點的硬件設備配比了。不然,有一類節點的硬件資源就至關處於浪費狀態了。
最後,就是 SQL 節點 和 NDB 節點二者軟件配置方面的優化了。對於 SQL 節點的配置,和普通的 MySQL 區別不是太大。各種參數的配置原則也和普通 MySQL 基本相同。NDB Cluster 存儲引擎的主要配置參數在前面的配置介紹中也基本都進行了性能相關的說明,這裏就再也不累述了。
16.6 小結
MySQL Cluster 的核心在於 NDB Cluster 存儲引擎,他不只對數據進行了水平切分,還對數據進行了跨節點冗餘。既解決了數據庫的擴展問題,同時也在很大程度上提升了數據庫總體可用性。 雖然目前 MySQL Cluster 的應用還不如普通的 MySQL Server 應用那麼普遍,可是我想隨着他的不斷成熟和改善,將會被愈來愈普遍的使用。這種 Share Nothing 的 Cluster架構也極可能會成爲將來的趨勢,就讓咱們共同期待愈來愈成熟穩定高效的 MySQL Cluster吧。