目錄
MySQL叢集是MySQL適合於分佈式計算環境的高實用、高冗余版本。它採用了NDB叢集儲存引擎,允許在1個叢集中運行多個MySQL伺服器。在MySQL 5.1二進製版本中、以及與最新的Linux版本兼容的RPM中提供了該儲存引擎。(注意,要想獲得MySQL叢集的功能,必須安裝mysql-server和mysql-max RPM)。
目前能夠運行MySQL叢集的作業系統有Linux、Mac OS X和Solaris。(一些用戶通報成功地在FreeBSD上運行了MySQL叢集,但MySQL AB公司尚未正式支援該特性)。我們正在努力,以便使MySQL叢集能運行在MySQL支援的所有作業系統上,包括Windows,而且當支援新的平台時,將更新該頁面。
本章介紹了正在進行的工作,其內容將隨著MySQL叢集的不斷演化而變化。關於MySQL叢集的更多訊息,請訪問MySQL AB公司的網站http://www.mysql.com/products/cluster/。
或許您也希望使用MySQL AB提供的兩種額外資源:
· MySQL叢集郵件列資料表。
· MySQL用戶論壇上的叢集主題區。
關於叢集的一些常見問題,請參見17.10節,「MySQL叢集常見問題解答」。如果您是MySQL叢集的新手,請閱讀我方開發人員區的文章如何為兩個伺服器設置MySQL叢集,這會有所幫助。
MySQL叢集是一種技術,該技術允許在無共享的系統中部署「內存中」資料庫的叢集。通過無共享體系結構,系統能夠使用廉價的硬件,而且對軟硬件無特殊要求。此外,由於每個組件有自己的內存和磁盤,不存在單點故障。
MySQL叢集將標準的MySQL伺服器與名為NDB的「內存中」叢集式儲存引擎集成了起來。在我們的文檔中,術語NDB指的是與儲存引擎相關的設置部分,而術語「MySQL叢集」指的是MySQL和NDB儲存引擎的組合。
MySQL叢集由一組計算機構成,每台計算機上均運行著多種程序,包括MySQL伺服器,NDB叢集的數據節點,管理伺服器,以及(可能)專門的數據訪問程式。關於叢集中這些組件的關係,請參見下圖:
所有這些程式一起構成了MySQL叢集。將數據保存到NDB叢集儲存引擎中時,資料表將保存在數據節點內。能夠從叢集中所有其他MySQL伺服器直接訪問這些資料表。因此,在將數據保存在叢集內的工資資料表應用程式中,如果某一應用程式更新了1位僱員的工資,所有查詢該數據的其他MySQL伺服器能立刻發現這種變化。
對於MySQL叢集,保存在數據節點內的數據可被映射,叢集能夠處理單獨數據節點的故障,除了少數事務將因事務狀態丟失而被放棄外,不會產生其他影響。由於事務性應用程式能夠處理事務失敗事宜,因而它不是問題源。
通過將MySQL叢集引入開放原始碼世界,MySQL為所有需要它的人員提供了具有高可用性、高性能和可縮放性的叢集數據管理。
NDB是一種「內存中」儲存引擎,它具有可用性高和數據一致性好的特點。
能夠使用多種故障切換和負載平衡選項配置NDB儲存引擎,但以叢集層面上的儲存引擎開始最簡單。MySQL叢集的NDB儲存引擎包含完整的數據集,僅取決於叢集本身內的其他數據。
下面,我們介紹了設置由NDB儲存引擎和一些MySQL伺服器構成的MySQL叢集的設置方法。
目前,MySQL叢集的叢集部分可獨立於MySQL伺服器進行配置。在MySQL叢集中,叢集的每個部分被視為1個節點。
註釋:在很多情況下,術語「節點」用於指計算機,但在討論MySQL叢集時,它資料表示的是程序。在單台計算機上可以有任意數目的節點,為此,我們採用術語叢集主機。
有三類叢集節點,在最低的MySQL叢集配置中,至少有三個節點,這三類節點分別是:
· 管理(MGM)節點:這類節點的作用是管理MySQL叢集內的其他節點,如提供配置數據、啟動並停止節點、運行備份等。由於這類節點負責管理其他節點的配置,應在啟動其他節點之前首先啟動這類節點。MGM節點是用命令ndb_mgmd啟動的。
· 數據節點:這類節點用於保存叢集的數據。數據節點的數目與副本的數目相關,是片段的倍數。例如,對於兩個副本,每個副本有兩個片段,那麼就有4個數據節點。沒有必要有一個以上的副本。數據節點是用命令ndbd啟動的。
· SQL節點:這是用來訪問叢集數據的節點。對於MySQL叢集,客戶端節點是使用NDB叢集儲存引擎的傳統MySQL伺服器。典型情況下,SQL節點是使用命令mysqld –ndbcluster啟動的,或將ndbcluster新增到my.cnf後使用mysqld啟動。
叢集配置包括對叢集中單獨節點的配置,以及設置節點之間的單獨通信鏈路。對於目前設計的MySQL叢集,其意圖在於,從處理器的能力、內存空間和帶寬來講,儲存節點是同質的,此外,為了提供單一的配置點,作為整體,叢集的所有配置數據均位於1個配置檔案中。
管理伺服器(MGM節點)負責管理叢集配置檔案和叢集日誌。叢集中的每個節點從管理伺服器檢索配置數據,並請求確定管理伺服器所在位置的方式。當數據節點內出現有趣的事件時,節點將關於這類事件的訊息傳輸到管理伺服器,然後,將這類訊息寫入叢集日誌。
此外,可以有任意數目的叢集客戶端程序或應用程式。它們分為兩種類型:
· 標準MySQL客戶端:對於MySQL叢集,它們與標準的(非叢集類)MySQL沒有區別。換句話講,能夠從用PHP、Perl、C、C++、Java、Python、Ruby等編寫的現有MySQL應用程式訪問MySQL叢集。
· 管理客戶端:這類客戶端與管理伺服器相連,並提供了優雅地啟動和停止節點、啟動和停止消息跟蹤(僅對調試版本)、顯示節點版本和狀態、啟動和停止備份等的命令。
本節介紹了如何規劃、安裝、配置和運行MySQL叢集的基本知識。與17.4節,「MySQL叢集的配置」中給出的示範不同,按照下面介紹的步驟和指南,所得的結果應是有用的MySQL叢集,它滿足對數據可用性和安全防護的最低要求。
在本節中,我們介紹了下述內容:硬件和軟件要求,聯網事宜,MySQL叢集的安裝,配置事宜,叢集的啟動、停止和重啟,加載樣本資料庫,以及執行查詢的方法。
基本假定
本節作了如下假定:
1. 我們將建立具有4個節點的叢集,每個節點位於不同的主機上,而且在典型的以太網中具有固定的網絡地址,如下所述:
節點 |
IP地址 |
管理(MGM)節點 |
192.168.0.10 |
MySQL伺服器(SQL)節點 |
192.168.0.20 |
數據(NDBD)節點"A" |
192.168.0.30 |
數據(NDBD)節點"B" |
192.168.0.40 |
2. 通過下圖可更清楚的表明這點:
4. 註釋:出於簡單性(以及可靠性)方面的考慮,在本基本知識介紹中我們僅使用數值IP地址。但是,如果在您的網絡中具備DNS解析功能,在配置叢集的過程中,可使用主機名代替IP地址。作為可選方式,也能使用/etc/hosts檔案,或能提供主機查詢的作業系統的等效物(如果可用的話)。
5. 在我們的場景中,每台主機均是基於Intel的桌面PC,PC上運行的是常見的一般性Linux版本,作業系統以標準配置安裝在磁盤上,未運行任何不必要的服務。具備標準TCP/IP聯網客戶端的核心作業系統應足以符合我們的要求。此外,為了簡單性,我們還假定所有主機上的檔案系統是等同的。如果這些主機上的檔案系統不同,就需對這些說明作相應的調整。
6. 在每台機器上安裝了標準的100 Mbps或1吉比特以太網卡,為每塊網卡安裝了恰當的驅動程式,並用標準的以太網聯網裝置(如交換器等)將4台主機連接起來(所有機器應使用具有相同容量的網卡,也就是說,叢集中的所有4台機器應全部使用100M網卡,或全部使用1G網卡)。MySQL叢集將工作在100 Mbps網絡中,但吉比特以太網能提供更好的性能。
注意,MySQL叢集不適合於連通性低於100 Mbps的網絡。出於該原因(尤其是),在公共網絡如Internet上運行MySQL叢集很難成功,也不推薦這樣做。
7. 對於樣本數據,我們將使用世界資料庫,該資料庫可從MySQL AB公司的網站上下載。由於該資料庫佔用的空間相對較小,我們假定每台機器有256 MB RAM,這足以運行作業系統、主機NDB程序、以及儲存資料庫(對於數據節點)。
儘管在本基本介紹中採用的是Linux作業系統,但對這裡給出的說明和步驟來說,僅過簡單的修改,也能適用於Solaris或Mac OS X。此外,我們還假定您已掌握了安裝和配置具備聯網功能的作業系統的基本知識,或能夠在需要的時候獲得幫助。
下一節,我們更詳細地討論了MySQL叢集的硬件、軟件和聯網要求。(請參見17.3.1節,「硬件、軟件和聯網」)。
MySQL叢集的一個強大優點在於,它能運行在普通硬件上,除了需要較大的RAM外在這點上沒有特殊要求,這是因為實際的數據儲存均是在內存中進行的。(注意,未來這點會改變,我們打算在未來的MySQL叢集版本中實現基於磁盤的儲存)。顯然,多個CPU和更快的CPU能增強性能。對於叢集程序來說,對內存的要求相對較少。
叢集的軟件要求程度適中。主機作業系統不需要任何特殊模塊、服務、應用程式、或配置就能支援MySQL叢集。對於Mac OS X或Solaris,標準安裝就已足夠。對於Linux,標準的「即開即用」安裝應是所需的全部。MySQL軟件要求很簡單:MySQL-max 5.1的生產版就是所需的全部,要想獲得叢集支援,必須使用MySQL的-max版本。無需自己編譯MySQL就能使用叢集。在本節中,我們假定您使用了與Linux相適應的-max二進製版本。對於Solaris或Mac OS X作業系統,相應的部分可通過MySQL軟件下載頁面獲得,http://dev.mysql.com/downloads/。
對於節點之間的通信,叢集支援採用標準拓撲方案的TCP/IP聯網,對於每台主機的預期最低要求是1塊標準的100 Mbps以太網卡,對於作為整體的叢集,還需加上交換器、網絡集線器或路由器以提供網絡連通性。我們強烈建議,應在其自己的子網內運行MySQL叢集,不與非叢集機器共享該子網,原因如下:
· 安全性:叢集節點之間的通信未採用任何特殊加密或防護。對MySQL叢集內傳輸的唯一保護方法是,在受保護的網絡上運行叢集。如果打算將MySQL叢集用於Web應用,叢集應明確地位於防火牆後面,而且不應位於網絡的非軍事區(DMZ)或其他地方。
· 效率:在專有的或受保護的網絡上設置MySQL叢集,這樣,叢集就能獨享叢集主機之間的帶寬。為MySQL叢集使用單獨的交換器不僅能防止對叢集數據的非法訪問,而且還能確保叢集節點不受網絡上其他計算機之間訊息傳輸的干擾。為了增強可靠性,可以使用雙交換器和雙卡,以防止網絡出現單點故障,對於這類通信鏈路,很多設備驅動均支援故障切換功能。
也能與MySQL叢集一起使用高速SCI(規模可延伸的計算機接口),但這不是要求的。關於該協議的更多訊息,以及它與MySQL叢集的用法,請參見17.7節,「使用與MySQL叢集的高速互連」對於每台運行儲存或SQL節點的MySQL叢集主機計算機,必須在其上安裝MySQL-max二進製版本。對於管理節點,沒有必要安裝MySQL伺服器二進製版本,但應安裝MGM伺服器端口監督程式和客戶端二進製版本(分別是ndb_mgmd和ndb_mgm)。在本節中,我們介紹了為每種叢集節點安裝正確的二進製版本所需的步驟。
MySQL AB提供了預編譯的二進制檔案,它們支援叢集,您不需要自己編譯這些檔案(如果您確實需要定制的二進制檔案,請參見2.8.3節,「從開發原始碼樹安裝」)。因此,對於每台叢集主機,安裝程序的第一步是從MySQL下載區下載檔案mysql-max-5.1.2-alpha-pc-linux-gnu-i686.tar.gz。我們假定您將該檔案放在各機器的/var/tmp目錄下。
對於32位和64位Linux平台,均有相應的RPM,RPM安裝的-max二進制檔案支援NDB叢集儲存引擎。如果您選擇使用它們而不是二進制檔案,務必在運行叢集節點的所有機器上安裝-server和-max軟件包(關於使用RPM安裝MySQL的更多訊息,請參見2.4節,「在Linux下安裝MySQL」)。使用RPM完成安裝後,仍需對叢集進行配置,請參見17.3.3節,「配置」。
註釋:完成安裝後,不啟動任何二進制檔案。配置完所有節點後,我們將向您介紹執行這類操作的方法。
儲存節點和SQL節點安裝
在設計為運行儲存節點或SQL節點的三台機器的每一台上,以系統根用戶身份執行下述步驟:
1. 檢查您的/etc/passwd和/etc/group檔案(或使用作業系統提供的用於管理用戶和組的工具),查看在系統上是否已存在mysql組和mysql用戶,這是因為某些作業系統會將其作為安裝程序的一部分予以建立。如果它們不存在,建立新的mysql用戶組,然後為該組新增1個mysql用戶。
2. groupadd mysql
3. useradd -g mysql mysql
4. 進入包含下載檔案的目錄,解包檔案檔案,並建立與mysql-max可執行檔案的symlink。注意,根據MySQL的版本號,實際的檔案名和目錄名會有所不同。
5. cd /var/tmp
6. tar -xzvf -C /usr/local/bin mysql-max-5.1.2-alpha-pc-linux-gnu-i686.tar.gz
7. ln -s /usr/local/bin/mysql-max-5.1.2-alpha-pc-linux-gnu-i686 mysql
8. 進入mysql目錄,運行所提供的用於建立系統資料庫的指令:
9. cd mysql
10. scripts/mysql_install_db --user=mysql
11.為MySQL伺服器和數據目錄設置必要的權限:
12. chown -R root .
13. chown -R mysql data
14. chgrp -R mysql .
注意,在每台運行數據節點的機器上,數據目錄是/usr/local/mysql/data。配置管理節點時將用到這類訊息(請參見17.3.3節,「配置」)。
15.將MySQL啟動指令拷貝到恰當的目錄下,使之成為可執行的指令,並設置它以便在啟動作業系統時啟動:
16. cp support-files/mysql.server /etc/rc.d/init.d/
17. chmod +x /etc/rc.d/init.d/mysql.server
18. chkconfig --add mysql.server
在此,我們使用Red Hat的chkconfig來建立與啟動指令的連結,請在您的作業系統上使用恰當的用於該目的的方式,如Debian上的update-rc.d。
請記住,對於儲存節點或SQL節點所在的每台機器,必須分別指向上述步驟。
管理節點安裝
對於MGM(管理)節點,不需要安裝mysqld可執行檔案,僅需安裝用於MGM伺服器和客戶端的二進制檔案,這類檔案可在下載的-max檔案中找到。再次假定您將該檔案放在了/var/tmp目錄下,引導系統時(也就是說使用sudo, su root或系統的等效命令後,假定具有系統管理員帳號的權限),執行下述步驟,在叢集管理節點主機上安裝ndb_mgmd和ndb_mgm:
1. 即如/var/tmp目錄,從檔案檔案中將ndb_mgm和ndb_mgmd提取到恰當的目錄下,如/usr/local/bin:
2. cd /var/tmp
3. tar -zxvf mysql-max-5.1.2-alpha-pc-linux-gnu-i686.tar.gz /usr/local/bin '*/bin/ndb_mgm*'
4. 進入解包檔案所在的目錄,然後使這兩個檔案成為可執行的:
5. cd /usr/local/bin
6. chmod +x ndb_mgm*
在17.3.3節,「配置」中,我們將為示範叢集中的所有節點建立和編寫配置檔案。
對於我們的4節點、4主機MySQL叢集,需要編寫4個配置檔案,每個節點/主機1個。
· 每個數據節點或SQl節點需要1個my.cnf檔案,該檔案提供了兩類訊息:connectstring(連接字串),用於通知節點到哪裡找到MGM節點;以及一行,用於通知該主機(容納數據節點的機器)上的MySQL伺服器運行在NDB模式下。
關於連接字串的更多訊息,請參見17.4.4.2節,「MySQL叢集連接字串」。
· 管理節點需要config.ini檔案,該檔案通知節點有多少需要維護的副本,需要在每個數據節點上為數據和索引分配多少內存,數據節點的位置,在每個數據節點上保存數據的磁盤位置,以及SQL節點的位置。
配置儲存節點和SQL節點
數據節點所需的my.cnf檔案相當簡單。配置檔案應位於/etc目錄下,並能用任何文本編輯器進行編輯(如有必要,建立該檔案),例如:
vi /etc/my.cnf
對於本示範中的每個數據節點和SQL節點,my.cnf檔案類似於:
# Options for mysqld process:
[MYSQLD]
ndbcluster # run NDB engine
ndb-connectstring=192.168.0.10 # location of MGM node
# Options for ndbd process:
[MYSQL_CLUSTER]
ndb-connectstring=192.168.0.10 # location of MGM node
輸入上述內容後,保存檔案並退出文本編輯器。在容納數據節點「A」、數據節點「B」和SQL節點的機器上分別執行上述操作。
配置管理節點
配置MGM節點的第一步是建立目錄,該目錄用於存放配置檔案,然後建立配置檔案本身。例如(以根用戶身份運行):
mkdir /var/lib/mysql-cluster
cd /var/lib/mysql-cluster
vi config.ini
在此使用了vi來建立檔案,不過,任何文本編輯器均應能勝任。
對於我們的典型設置,config.ini檔案應類似於:
# Options affecting ndbd processes on all data nodes:
[NDBD DEFAULT]
NoOfReplicas=2 # Number of replicas
DataMemory=80M # How much memory to allocate for data storage
IndexMemory=18M # How much memory to allocate for index storage
# For DataMemory and IndexMemory, we have used the
# default values. Since the "world" database takes up
# only about 500KB, this should be more than enough for
# this example Cluster setup.
# TCP/IP options:
[TCP DEFAULT]
portnumber=2202 # This the default; however, you can use any
# port that is free for all the hosts in cluster
# Note: It is recommended beginning with MySQL 5.0 that
# you do not specify the portnumber at all and simply allow
# the default value to be used instead
# Management process options:
[NDB_MGMD]
hostname=192.168.0.10 # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster # Directory for MGM node logfiles
# Options for data node "A":
[NDBD]
# (one [NDBD] section per data node)
hostname=192.168.0.30 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's datafiles
# Options for data node "B":
[NDBD]
hostname=192.168.0.40 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's datafiles
# SQL node options:
[MYSQLD]
hostname=192.168.0.20 # Hostname or IP address
# (additional mysqld connections can be
# specified for this node for various
# purposes such as running ndb_restore)
(註釋:"world"資料庫可從站點http://dev.mysql.com/doc/下載,它列在「示範」欄目下)。
一旦建立了所有的配置檔案並指定了這些最低選項,可啟動叢集,並驗證所有程序均能正常運行。關於這方面的討論,請參見17.3.4節,「首次啟動」。
關於可用MySQL叢集配置參數以及其用法的更多訊息,請參見17.4.4節,「配置檔案」和17.4節,「MySQL叢集的配置」。關於與進行備份有關的MySQL叢集配置,請參見17.6.5.4節,「叢集備份的配置」。
註釋:叢集管理節點的預設端口是1186,數據節點的預設端口2202。從MySQL 5.0.3開始,該限制已被放寬,叢集能夠根據空閒的端口自動地為數據節點分配端口。
完成配置後,啟動叢集並不很困難。必須在數據節點所在的主機上分別啟動每個叢集節點程序。儘管能夠按任何順序啟動節點,但我們建議,應首先啟動管理節點,然後啟動儲存節點,最後啟動SQL節點:
1. 在管理主機上,從系統shell發出下述命令以啟動MGM節點程序:
2. shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
注意,必須用「-f」或「--config-file」選項,告訴ndb_mgmd到哪裡找到配置檔案(詳情請參見17.5.3節,「ndb_mgmd,「管理伺服器」程序」)。
3. 在每台數據節點主機上,對於首次啟動,運行下述命令啟動NDBD程序:
4. shell> ndbd --initial
注意,僅應在首次啟動ndbd時,或在備份/恢復或配置變化後重啟ndbd時使用「--initial」參數,這很重要。原因在於,該參數會使節點刪除由早期ndbd實例建立的、用於恢復的任何檔案,包括恢復用日誌檔案。
5. 如果使用RPM在SQL節點所在的叢集主機上安裝了MySQL,能夠(也應當)使用安裝在/etc/init.d下的啟動指令在SQL節點上啟動MySQL伺服器程序。注意,要想運行「-max」伺服器二進制檔案,除了標準的RPM外,還需要安裝-max伺服器RPM。
如果一切順利,並已正確設置了叢集,那麼叢集現在應能運行。通過使用ndb_mgm管理節點客戶端,可對其進行測試。其輸出應類似於:
shell> ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 @192.168.0.30 (Version: 5.1.2-alpha, Nodegroup: 0, Master)
id=3 @192.168.0.40 (Version: 5.1.2-alpha, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.0.10 (Version: 5.1.2-alpha)
[mysqld(SQL)] 1 node(s)
id=4 (Version: 5.1.2-alpha)
具體的輸出內容可能會略有不同,這取決於您所使用的MySQL版本。
註釋:如果您正在使用較早的MySQL版本,您或許會看到引用為『[mysqld(API)]』的SQL節點。這是一種早期的用法,現已放棄。
現在,應能在MySQL叢集中處理資料庫,資料表和數據。關於這方面的簡要討論,請參見17.3.5節,「加載示範數據並執行查詢」。
與沒有使用叢集的MySQL相比,在MySQL叢集內操作數據的方式沒有太大的區別。執行這類操作時應記住兩點:
· 資料表必須用ENGINE=NDB或ENGINE=NDBCLUSTER選項建立,或用ALTER TABLE選項更改,以使用NDB叢集儲存引擎在叢集內複製它們。如果使用mysqldump的輸出從已有資料庫導入資料表,可在文本編輯器中打開SQL指令,並將該選項新增到任何資料表建立語句,或用這類選項之一替換任何已有的ENGINE(或TYPE)選項。例如,假定在另一個MySQL伺服器(不支援MySQL叢集)上有樣本世界資料庫,而且您打算導出城市資料表的定義:
· shell> mysqldump --add-drop-table world City > city_table.sql
在所得的city_table.sql檔案中,將包含這條資料表建立語句(以及導入資料表數據所需的INSERT語句):
DROP TABLE IF EXISTS City;
CREATE TABLE City (
ID int(11) NOT NULL auto_increment,
Name char(35) NOT NULL default '',
CountryCode char(3) NOT NULL default '',
District char(20) NOT NULL default '',
Population int(11) NOT NULL default '0',
PRIMARY KEY (ID)
) ENGINE=MyISAM;
INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
# (remaining INSERT statements omitted)
需要確認MySQL為該資料表使用了NDB儲存引擎。有兩種完成該任務的方法。其中一種方法是,在將資料表導入叢集資料庫之前更改其定義,使其類似於(仍使用「城市」作為示範):
DROP TABLE IF EXISTS City;
CREATE TABLE City (
ID int(11) NOT NULL auto_increment,
Name char(35) NOT NULL default '',
CountryCode char(3) NOT NULL default '',
District char(20) NOT NULL default '',
Population int(11) NOT NULL default '0',
PRIMARY KEY (ID)
) ENGINE=NDBCLUSTER;
INSERT INTO City VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO City VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO City VALUES (3,'Herat','AFG','Herat',186800);
# (etc.)
對於將成為叢集資料庫組成部份的每個資料表,均需要為其定義執行上述操作。完成該任務的最簡單方法是,簡單地在world.sql檔案上執行「搜尋-替換」,並用ENGINE=NDBCLUSTER替換所有的TYPE=MyISAM實例。如果您不打算更改該檔案,也可使用ALTER TABLE。詳情請參見下面的介紹。
假定您已在叢集的SQL節點上建立了名為「world」的資料庫,隨後可使用mysql命令行客戶端讀取city_table.sql,並按通常方式建立和填充對應的資料表:
shell> mysql world < city_table.sql
請記住,上述命令必須在運行SQL節點的主機上執行,這點十分重要。對於本例,應在IP地址為192.168.0.20的機器上執行。
要想在SQL節點上建立世界資料庫的副本,請將檔案保存到/usr/local/mysql/data,然後運行:
shell> cd /usr/local/mysql/data
shell> mysql world < world.sql
當然,SQL指令必須能被mysql系統用戶讀取。如果將檔案保存到了不同的目錄下,請作相應的調整。
注意,在MySQL 5.1中,NDB叢集不支援自動發現資料庫的功能,這點很重要(請參見17.8節,「MySQL叢集的已知限制」)。這意味著,一旦在一個數據節點上建立了世界(world)資料庫和它的資料表,在叢集中的每個SQL節點上還需要發出命令CREATE DATABASE world(從MySQL 5.0.2開始,可以使用CREATE SCHEMA world取而代之),後跟FLUSH TABLES。這樣,節點就能識別資料庫並讀取其資料表定義。
在SQL節點上運行SELECT查詢與在MySQL伺服器的任何其他實例上運行查詢沒有區別。要想從命令行運行查詢,首先應按照通常方式登錄到MySQL監視器:
shell> mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.1.2-alpha
鍵入』help;』或』\h』獲取幫助。鍵入』\c』清空緩衝區。
mysql>
如果在導入MySQL指令之前未更改資料表定義中的ENGINE=子句,應在此時運行下述命令:
mysql> USE world;
mysql> ALTER TABLE City ENGINE=NDBCLUSTER;
mysql> ALTER TABLE Country ENGINE=NDBCLUSTER;
mysql> ALTER TABLE CountryLanguage ENGINE=NDBCLUSTER;
注意,在這裡我們簡單地使用了MySQL伺服器密碼為空的預設根用戶帳號。當然,在生產設置下,安裝MySQL伺服器時,總應遵守標準的安全方法措施,包括設置牢靠的根用戶密碼,並為用戶建立具有完成任務所需的權限的用戶帳號。關於這方面的更多訊息,請參見5.7節,「MySQL訪問權限系統」。
需要關注的是,當叢集節點彼此訪問時不使用MySQL的權限系統,設置或更改MySQL用戶帳號(包括根用戶帳號)不影響節點之間的交互,它們僅對訪問SQL節點的應用程式有效。
能夠以通常的方式選擇資料庫,並對資料表執行SELECT查詢,就像退出MySQL監視器一樣:
mysql> USE world;
mysql> SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5;
+-----------+------------+
| 名稱 | 人口 |
+-----------+------------+
| 孟買 | 10500000 |
| 漢城 | 9981619 |
| 聖保羅 | 9968485 |
| 上海 | 9696300 |
| 雅加達 | 9604900 |
+-----------+------------+
5 rows in set (0.34 sec)
mysql> \q
Bye
shell>
使用MySQL的應用程式能夠使用標準的API。重要的是應記住,您的應用程式必須訪問SQL節點,而不是MGM或儲存節點。在下面的簡單示範中,介紹了使用PHP 5的mysqli延伸(運行在位於網絡中其他位置的Web伺服器上)執行相同查詢的方法:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>SIMPLE mysqli SELECT</title>
</head>
<body>
<?php
# connect to SQL node:
$link = new mysqli('192.168.0.20', 'root', '', 'world');
# parameters for mysqli constructor are:
# host, user, password, database
if( mysqli_connect_errno() )
die("Connect failed: " . mysqli_connect_error());
$query = "SELECT Name, Population
FROM City
ORDER BY Population DESC
LIMIT 5";
# if no errors...
if( $result = $link->query($query) )
{
?>
<table border="1" width="40%" cellpadding="4" cellspacing ="1">
<tbody>
<tr>
<th width="10%">City</th>
<th>Population</th>
</tr>
<?
# then display the results...
while($row = $result->fetch_object())
printf(<tr>\n <td align=\"center\">%s</td><td>%d</td>\n</tr>\n",
$row->Name, $row->Population);
?>
</tbody
</table>
<?
# ...and verify the number of rows that were retrieved
printf("<p>Affected rows: %d</p>\n", $link->affected_rows);
}
else
# otherwise, tell us what went wrong
echo mysqli_error();
# free the result set and the mysqli connection object
$result->close();
$link->close();
?>
</body>
</html>
我們假定運行在Web伺服器上的程序能夠訪問SQL節點的IP地址。
採用類似的風格,可以使用MySQL C API、Perl-DBI、Python-mysql、或MySQL AB自己的連接器來執行數據定義和操控任務,就像正常使用MySQL那樣。
· 另外還請記住,每個NDB資料表必須有一個主鍵。如果在建立資料表時用戶未定義主鍵,NDB叢集儲存引擎將自動生成隱含的主鍵。(註釋:該隱含 鍵也將佔用空間,就像任何其他的資料表索引一樣。由於沒有足夠的內存來容納這些自動建立的鍵,出現問題並不罕見)。
要想關閉叢集,可在MGM節點所在的機器上,在Shell中簡單地輸入下述命令:
shell> ndb_mgm -e shutdown
該命令將恰當地中止ndb_mgm、ndb_mgmd以及任何ndbd程序。使用mysqladmin shutdown或其他方法,可中止SQL節點。注意,這裡的「-e」選項用於將命令從shell傳遞到ndb_mgm客戶端。請參見4.3.1節,「在命令行上使用選項」。
要想重啟叢集,可簡單地運行下述命令:
· 在管理主機上(本設置中為192.168.0.10):
· shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
· 在每台數據節點主機上(192.168.0.30和192.168.0.40):
· shell> ndbd
請記住,正常重啟NDBD節點時,不要用「--initial」選項使用該命令。
· 在SQL主機上(192.168.0.20):
· shell> mysqld &
關於建立叢集備份的更多訊息,請參見17.6.5.2節,「使用管理伺服器建立備份」。
要想從備份中恢復叢集,需要使用ndb_restore命令。請參見17.6.5.3節,「如何恢復叢集備份」。
關於配置MySQL叢集的更多訊息,請參見17.4節,「MySQL叢集的配置」。
為了避免不必要的資源分配,預設情況下,在伺服器的配置中將禁止NDB儲存引擎。要想啟用NDB,需要更改伺服器的my.cnf配置檔案,或使用「—ndbcluster」選項啟動伺服器。
由於MySQL伺服器是叢集的一部分,它也需要知道如何訪問MGM節點,以便獲得叢集配置數據。預設行為是搜尋本地主機上MGM節點。但是,如果需要另外指定它的位置,可在my.cnf檔案或MySQL伺服器命令行上進行。能夠使用NDB儲存引擎之前,至少應有一個MGM節點是可操作的,而且還應有所需的數據節點。
對於Linux、Mac OS X和Solaris,在其二進制分發版中均提供了NDB叢集儲存引擎。在Windows平台上尚不支援它,但我們打算在不遠的將來使其能用於win32和其他平台。
如果選擇從原始碼tarball或MySQL 5.1 BitKeeper樹建立它,運行configure時,務必使用「--with-ndbcluster」選項。也可以使用BUILD/compile-pentium-max建立指令。注意,該指令包含OpenSSL,因此,要想成功建立,必須有或獲得OpenSSL,如不然,需要更改「compile-pentium-max」以便將該要求排除在外,當然,也能採用標準步驟來編譯您自己的二進制檔案,然後執行常規測試和安裝步驟。請參見2.8.3節,「從開發原始碼樹安裝」。
在下面的數節內,假定您已熟悉了MySQL的安裝方法,在此,我們僅介紹了MySQL叢集配置與不具備叢集功能的MySQL配置之間的差別。如果希望瞭解關於後者的更多訊息,請參見第2章:安裝MySQL。
如果首先運行了所有的管理和數據節點,您將發現叢集配置最簡單,這或許是最花時間的配置部分。編輯my.cnf檔案相對直接,在本節中,僅討論與不具備叢集功能的MySQL配置不同的部分。
首先,應以系統根用戶身份通過執行下述命令建立配置目錄,如/var/lib/mysql-cluster:
shell> mkdir /var/lib/mysql-cluster
在該目錄下,使用下述訊息建立名為config.ini的檔案,針對系統的情況,用恰當的值替換HostName和DataDir。
# file "config.ini" - showing minimal setup consisting of 1 data node,
# 1 management server, and 3 MySQL servers.
# The empty default sections are not required, and are shown only for
# the sake of completeness.
# Data nodes must provide a hostname but MySQL Servers are not required
# to do so.
# If you don't know the hostname for your machine, use localhost.
# The DataDir parameter also has a default value, but it is recommended to
# set it explicitly.
# Note: DB, API, and MGM are aliases for NDBD, MYSQLD, and NDB_MGMD
# respectively. DB and API are deprecated and should not be used in new
# installations.
[NDBD DEFAULT]
NoOfReplicas= 1
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
[TCP DEFAULT]
[NDB_MGMD]
HostName= myhost.example.com
[NDBD]
HostName= myhost.example.com
DataDir= /var/lib/mysql-cluster
[MYSQLD]
[MYSQLD]
[MYSQLD]
現在,能夠按下述方式啟動管理伺服器:
shell> cd /var/lib/mysql-cluster
shell> ndb_mgmd
接下來,通過運行ndbd啟動單個DB節點。首次為給定的DB節點啟動ndbd時,應使用「—initial」選項,如下所示:
shell> ndbd --initial
對於後續的ndbd啟動,通常不需要使用該選項:
shell> ndbd
這是因為,--initial選項將刪除該數據節點的所有已有數據和日誌檔案(以及所有的資料表元數據),並建立新的數據和日誌檔案。該規則的一項例外是:新增了新數據節點後重啟叢集並從備份進行恢復之時。
預設情況下,ndbd將在端口1186上搜尋本地主機上的管理伺服器。
註釋:如果從二進制tarball安裝了MySQL,需要明確指定ndb_mgmd和ndbd伺服器的路徑。(正常情況下,它們位於/usr/local/mysql/bin目錄下)。
最後,進入MySQL數據目錄(通常是/var/lib/mysql或/usr/local/mysql/data),並確保my.cnf檔案包含啟用NDB儲存引擎所需的選項:
[mysqld]
ndbcluster
現在,您能按通常方式啟動MySQL伺服器:
shell> mysqld_safe --user=mysql &
等待一段時間,確認MySQL伺服器正在恰當運行。如果發現通知用mysql停止,請檢查伺服器的.err檔案,找出錯誤。
如果到目前為止一切正常,可使用叢集啟動它:
shell> mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.1.2-alpha-Max
鍵入』help;』或』\h』獲取幫助。鍵入』\c』清空緩衝區。
mysql> SHOW ENGINES\G
...
*************************** 12. row ***************************
Engine: NDBCLUSTER
Support: YES
Comment: Clustered, fault-tolerant, memory-based tables
*************************** 13. row ***************************
Engine: NDB
Support: YES
Comment: Alias for NDBCLUSTER
...
(注意,上例輸出中顯示的行號可能與您的系統上顯示的不同,具體情況取決於使用的MySQL版本,以及配置它的方式)。
shell> mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.1.2-alpha-Max
鍵入』help;』或』\h』獲取幫助。鍵入』\c』清空緩衝區。
mysql> USE test;
Database changed
mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.09 sec)
mysql> SHOW CREATE TABLE ctest \G
*************************** 1. row ***************************
Table: ctest
Create Table: CREATE TABLE `ctest` (
`i` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
要想檢查是否恰當設置了節點,可啟動管理客戶端:
shell> ndb_mgm
隨後,為了獲得關於叢集狀態的報告,可從管理客戶端內使用SHOW命令:
NDB> SHOW
Cluster Configuration
---------------------
[ndbd(NDB)] 1 node(s)
id=2 @127.0.0.1 (Version: 3.5.3, Nodegroup: 0, Master)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @127.0.0.1 (Version: 3.5.3)
[mysqld(API)] 3 node(s)
id=3 @127.0.0.1 (Version: 3.5.3)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)
此時,您成功地設置了工作的MySQL叢集。現在,您能使用由ENGINE=NDBCLUSTER或其別名ENGINE=NDB建立的資料表,將數據保存到叢集中。
配置MySQL叢集需要與兩個檔案打交道:
· my.cnf:為所有的MySQL叢集可執行檔案指定了選項。您應熟悉了前面介紹的使用MySQL的方式,通過運行在叢集中的每個可執行檔案,必須能夠訪問該檔案。
· config.ini:該檔案僅由MySQL叢集管理伺服器讀取,隨後管理伺服器會將包含該檔案的訊息分配給叢集中的所有程序。config.ini檔案包含對叢集中各節點的描述。包括數據節點的配置參數,以及叢集中所有節點間連接的配置參數。
我們正在不斷改進叢集配置,並努力簡化該程序。儘管我們將盡量維護向後相容性,但在某些時候,可能也需要引入不兼容的變動。在這種情況下,我們將盡量讓叢集用戶事先瞭解該變動是否是向後兼容的。如果您發現了尚未記錄在文檔中的這類變動,請使用我們的問題資料庫通報它。
為了支援MySQL叢集,需要更新檔案my.cnf,如下例所示。注意,不應將這裡給出的選項與config.ini檔案中出現的選項混淆起來。此外,從命令行使用可執行檔案時,或許也應指定這些參數。
# my.cnf
# example additions to my.cnf for MySQL Cluster
# (valid in MySQL 5.1)
# enable ndbcluster storage engine, and provide connectstring for
# management server host (default port is 1186)
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com
# provide connectstring for management server host (default port: 1186)
[ndbd]
connect-string=ndb_mgmd.mysql.com
# provide connectstring for management server host (default port: 1186)
[ndb_mgm]
connect-string=ndb_mgmd.mysql.com
# provide location of cluster configuration file
[ndb_mgmd]
config-file=/etc/config.ini
(關於連接字元的更多訊息,請參見17.4.4.2節,「MySQL叢集連接字串」)。
# my.cnf
# example additions to my.cnf for MySQL Cluster
# (will work on all versions)
# enable ndbcluster storage engine, and provide connectstring for management
# server host to the default port 1186
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com:1186
或許,您也可以使用叢集my.cnf中單獨的[mysql_cluster]部分,設置可被所有可執行檔案讀取的設置,並影響所有的可執行檔案:
# cluster-specific settings
[mysql_cluster]
ndb-connectstring=ndb_mgmd.mysql.com:1186
目前,配置檔案採用的是INI格式,預設情況下被命名為config.ini。該檔案在啟動時由ndb_mgmd讀取,並能被置於任何地方。在命令行上與ndb_mgmd一起使用--config-file=[<path>]<filename>,可指定其位置和名稱。如果未指定配置檔案,預設情況下,ndb_mgmd將嘗試讀取位於當前工作目錄下的檔案config.ini。
對於大多數參數,均定義了預設值,也能在config.ini檔案中指定預設值。要想建立預設值部分,可簡單地將單詞DEFAULT新增到該部分的名稱上。例如,數據節點是使用[NDBD]部分配置的。如果所有的數據節點使用相同大小的數據內存,而且該內存大小不同於預設的大小,應建立包含DataMemory行的[NDBD DEFAULT]部分,為所有數據節點指定預設的數據內存大小。
INI格式包含多個部分,每一部分以該部分的標題(用方括號括住)開始,後跟恰當的參數名和值。與標準格式的不同之處在於,不能用冒號「:」和等號「=」隔開參數名和值;另一處不同是,這些部分並不是用名稱唯一標識的。其唯一性條目(如具有相同類型的兩個不同節點)是由唯一ID標識的。
作為最低要求,配置檔案必須定義叢集中的計算機和節點,以及這些節點所在的計算機。下面給出了一個簡單的叢集配置檔案示範,該叢集包含1個管理伺服器,2個數據節點和2個MySQL伺服器:
# file "config.ini" - 2 data nodes and 2 SQL nodes
# This file is placed in the startup directory of ndb_mgmd (the management
# server)
# The first MySQL Server can be started from any host. The second can be started
# only on the host mysqld_5.mysql.com
[NDBD DEFAULT]
NoOfReplicas= 2
DataDir= /var/lib/mysql-cluster
[NDB_MGMD]
Hostname= ndb_mgmd.mysql.com
DataDir= /var/lib/mysql-cluster
[NDBD]
HostName= ndbd_2.mysql.com
[NDBD]
HostName= ndbd_3.mysql.com
[MYSQLD]
[MYSQLD]
HostName= mysqld_5.mysql.com
在該配置檔案中,有6個不同部分:
· [COMPUTER]:定義了叢集主機。
· [NDBD]:定義了叢集的數據節點。
· [MYSQLD]:定義了叢集的MySQL伺服器節點。
· [MGM]或[NDB_MGMD]:定義了叢集的管理伺服器節點。
· [TCP]:定義了叢集中節點間的TCP/IP連接,TCP/IP是預設的連接協議。
· [SHM]:定義了節點間的共享內存連接。以前,這類連接僅能在使用「--with-ndb-shm」選項建立的二進制檔案中使用。在MySQL 5.1-Max中,預設情況下它是允許的,但仍應將其視為試驗性的。
注意,每個節點在config.ini檔案中有自己的部分。例如,由於該叢集有兩個數據節點,在配置檔案中,也包含定義這些節點的部分。
可以為每個部分定義DEFAULT值。所有的叢集參數名稱均區分大小寫。
除了MySQL叢集管理伺服器(ndb_mgmd),構成MySQL叢集的每個節點均需要1個連接字串,該連接字串指向管理伺服器所在的位置。它用於建立與管理伺服器的連接,並執行其他任務,這類其他任務取決於節點在叢集內扮演的角色。連接字串的語法如下:
<connectstring> :=
[<nodeid-specification>,]<host-specification>[,<host-specification>]
<nodeid-specification> := node_id
<host-specification> := host[:port]
node_id是大於1的整數,用於確定config.ini中的節點。port是引用正常Unix端口的整數。host是代資料表有效Internet地址的字串。
example 1 (long): "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
example 2 (short): "myhost1"
如果未提供,所有節點均將使用localhost:1186作為預設的連接字串值。如果在連接字串中省略了<port>,預設端口為1186。該端口在網絡上總應是可用的,這是因為它是由IANA為該目的而指定的(詳情請參見http://www.iana.org/assignments/port-numbers)。
通過列出多個<host-specification>值,能夠指定數個冗余管理伺服器。叢集節點將按照指定的順序嘗試連接到每台主機上的連續管理伺服器,直至成功建立起連接為止。
有多種指定連接字串的不同方法:
· 每個可執行檔案有自己的命令行選項,使用它,能夠在啟動時指定管理伺服器(關於各可執行程式的介紹,請參見相應的文檔)。
· 也能一次性地為叢集中的所有節點設置連接字串,方法是將其放在管理伺服器的my.cnf檔案的[mysql_cluster]部分。
· 為了向後相容性,還提供了兩種其他選項,其使用的語法相同:
1. 設置NDB_CONNECTSTRING環境變數,使之包含connectstring(連接字串)。
2. 將針對各可執行檔案的connectstring(連接字串)寫入名為Ndb.cfg的文本檔案,並將該檔案放在可執行檔案的啟動目錄下。
但是,這些方法目前已不再受重視,對於新安裝,不應使用它們。
指定連接字串時,推薦的方法是在命令行上設置它,或為每個可執行檔案在my.cnf檔案中設置它。
除了用於避免為系統中的每個節點定義主機名外,[COMPUTER]部分沒有實際的重要意義。這裡所提到的所有參數都是需要的。
· [COMPUTER]Id
這是整數值,用於引用位於配置檔案中別處的主機計算機。
· [COMPUTER]HostName
這是計算機的主機名或IP地址。
[NDB_MGMD]部分(或其別名[MGM])用於配置管理伺服器的行為。下面列出的所有參數均能被忽略,如果是這樣,將使用其預設值。註釋:如果ExecuteOnComputer和HostName參數均未出現,會為它們指定預設值localhost。
· [NDB_MGMD]Id
叢集中的每個節點都有唯一的標識,由從1到63的整數資料表示。所有的內部叢集消息使用該ID來定址結點。
· [NDB_MGMD]ExecuteOnComputer
它引用在[COMPUTER]部分中定義的計算機之一。
· [NDB_MGMD]PortNumber
這是管理伺服器用於監聽配置請求和管理命令的端口號。
· [NDB_MGMD]LogDestination
該參數指定了將叢集登錄訊息發送到哪裡。有三種選項,CONSOLE、SYSLOG和FILE:
o CONSOLE,將日誌輸出到標準輸出設備(stdout):
o CONSOLE
o SYSLOG,將日誌發送到syslog(系統日誌)軟設備,可能的值包括:auth、authpriv、cron、daemon、ftp、kern、lpr、mail、news、syslog、user、uucp、local0、local1、local2、local3、local4、local5、local6或local7。
註釋:並非所有的作業系統均支援所有的軟設備。
SYSLOG:facility=syslog
o FILE,將叢集日誌輸出導向相同機器上的正規檔案。可指定下述值:
§ filename:日誌檔案的名稱。
§ maxsize:日誌記錄切換到新檔案之前,檔案能增長到的最大尺寸。出現該情況時,將通過在檔案名上新增.x,重命名日誌檔案,其中,x是該名稱尚未使用的下一個數字。
§ maxfiles:日誌檔案的最大數目。
o FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
使用由分號分隔的字串,可以指定多個日誌目標,如下所示:
CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
FILE參數的預設值是FILE:filename=ndb_node_id_cluster.log,maxsize=1000000,maxfiles=6,其中,node_id是節點的ID。
· [NDB_MGMD]ArbitrationRank
該參數用於定義哪個節點將扮演仲裁程式的角色。只有MGM節點和SQL節點能扮演仲裁程式的角色。ArbitrationRank可以取下述值之一:
o 0:該節點永遠不會用作仲裁程式。
o 1:該節點具有高的優先級,也就是說,與低優先級節點相比,它更容易成為仲裁程式。
o 2:表明節點具有低的優先級,僅當具有高優先級的節點無法用於該目的時,才能成為仲裁程式。
通常情況下,應將ArbitrationRank設置為1(預設值),並將所有的SQL節點設置為0,將管理伺服器配置為仲裁程式。
· [NDB_MGMD]ArbitrationDelay
整數值,以毫秒為單位規定了管理伺服器對仲裁請求的延遲時間。預設情況下,該值為0,通常不需要改變它。
· [NDB_MGMD]DataDir
它用於設置保存管理伺服器輸出檔案的位置。這些檔案包括叢集日誌檔案、程序輸出檔案、以及端口監督程式的pid檔案(對於日誌檔案,可通過設置[NDB_MGMD]LogDestination的FILE參數覆蓋它,請參見本節前面的討論)。
[NDBD]部分用於配置叢集數據節點的行為。有很多可用於控制緩衝區大小、池大小、超時等的參數。強制性參數包括:
· ExecuteOnComputer或HostName.
· 參數NoOfReplicas
這些參數需要在[NDBD DEFAULT]部分中定義。
大多數數據節點參數是在[NDBD DEFAULT]部分中設置的。只有那些明確聲明為能設置本地值的參數才能在[NDBD]部分中被更改。HostName、Id以及ExecuteOnComputer必須在本地[NDBD]部分中定義。
識別數據節點
啟動節點時,可在命令行上分配Id值(即數據節點ID),也能在配置檔案中分配Id值。
對於各參數,能夠使用後綴k、M或G用於指明單位,分別資料表示1024、1024*1024或1024*1024*1024(例如,100k資料表示100 * 1024 = 102400)。目前,參數和值區分大小寫。
· [NBDB]Id
這是用作節點地址的節點ID,供有的叢集內部消息使用。這是介於1~63之間的整數。叢集中的每個節點均有唯一的ID。
· [NDBD]ExecuteOnComputer
用於引用在COMPUTER部分中定義的計算機(主機)。
· [NDBD]HostName
指定該參數的效果類似於指定ExecuteOnComputer。它定義了儲存節點所在計算機的主機名。指定除localhost之外的其他主機名時,需要該參數或ExecuteOnComputer。
· (OBSOLETE) [NDBD]ServerPort
叢集中的各節點使用端口來與其他節點相連。該端口也用於連接建立階段中的非TCP傳輸器。由於預設端口是動態分配的,同一台計算機上的兩個節點具有不同的端口號,正常情況下不需要為該參數指定值。
· [NDBD]NoOfReplicas
該全局參數僅能在[NDBD DEFAULT]中設置,它定義了叢集中每個資料表保存的副本數。該參數還指定了節點組的大小。節點組指的是保存相同訊息的節點集合。
節點組是以隱式方式構成的。第1個節點組由具有最低節點ID的數據節點集合構成,下一個節點組由具有次低節點ID的數據節點集合構成,依此類推。作為示範,截頂我們有4個數據節點,並將NoOfReplicas設置為2。這四個數據節點的ID分別是2、3、4、5。那麼第1個節點組由節點2和3構成,第2個節點組由節點4和5構成。重要的是對叢集進行相應的配置,使得同一節點組中的節點位於不同的計算機上,這是因為,如果位於相同的計算機上,單個硬件故障會導致整個叢集崩潰。
如果未提供節點ID,那麼數據節點的順序將是節點組的決定因素。無論是否進行了明確的分配,可在管理客戶端SHOW命令的輸出中查看它們。
NoOfReplicas沒有預設值,最大的可能值為4。
· [NDBD]DataDir
該參數指定了存放跟蹤檔案、日誌檔案、pid檔案以及錯誤日誌的目錄。
· [NDBD]FileSystemPath
該參數指定了存放為元數據建立的所有檔案、REDO日誌、UNDO日誌和數據檔案的目錄。預設目錄是由DataDir指定的。注意,啟動ndbd程序之前,該目錄必須已存在。
為MySQl叢集推薦的目錄層次包括/var/lib/mysql-cluster,在其下為節點的檔案系統建立1個為目錄。該子目錄包含節點ID。例如,如果節點ID為2,該子目錄的名稱為ndb_2_fs。
· [NDBD]BackupDataDir
也能指定存放備份的目錄。預設情況下,該目錄是FileSystemPath/BACKUP(請參見前面的介紹)。
數據內存和索引內存
參數DataMemory和IndexMemory指定了存放實際記錄及其索引的內存段的大小。這是它們的值時,重要的是應掌握使用DataMemory和IndexMemory的方式,這是因為,為了反映叢集的實際使用情況,常常需要更新它們:
· [NDBD]DataMemory
該參數定義了用於保存資料庫記錄的空間大小。全部空間均是分配在內存中的,因此,機器應具有足夠的物理內存來容納該值,這點極其重要。
由DataMemory分配的內存用於保存實際記錄和索引。目前,每條記錄具有固定的大小(甚至VARCHAR列也保存為固定寬度列)。每條記錄的開銷為16字節,此外,每條記錄還需要額外的空間,這是因為,這類記錄保存在具有128字節頁面開銷的32KB頁中(請參見下面的介紹)。由於每條記錄僅保存在1個頁中,因而每頁有少量的浪費。目前,最大記錄大小為8052字節。
由DataMemory定義的內存空間也用於保存有序索引,對於每條記錄,索引約使用10字節。在有序索引中,資料表示了每個資料表行。用戶常犯的一個錯誤是,想當然地認為所有的索引均保存在由IndexMemory分配的內存中,但情況並非如此:只有主鍵和唯一性混編索引使用該內存,有序索引使用的是由DataMemory分配的內存。然而,建立主鍵或唯一性混編索引時,也會在相同的 鍵上建立有序索引,除非在索引建立語句中指定了USING HASH。通過在管理客戶端中運行ndb_desc -d db_name table_name,可對其進行驗證。
DataMemory分配的內存空間由多個32KB頁構成,它們是為資料表片段分配的。通常情況下,為每一資料表劃分的資料表片段數目與叢集中的節點數目相同。因此,對於每一節點,片段數目與在NoOfReplicas中設置的相同。一旦分配了1頁,目前無法將其返回到自由頁池中,除非刪除資料表。執行節點恢復也將壓縮分區,這是因為,所有記錄均會被插入到其他活動節點的空分區中。
DataMemory內存空間也包含UNDO訊息:對於每一更新,未改變記錄的副本將被分配到DataMemory中。在有序資料表索引中,還有對每一副本的引用。僅當更新唯一性索引列時,才會更新唯一性混編索引,在該情況下,將在索引資料表中插入新的條目,並在提交時刪除舊的條目。因此,也有必要分配足夠的內存,以便處理由使用叢集的應用程式執行的最大事務。在任何情況下,執行少量大的事務並不比使用眾多小的事務佔優,原因如下:
o 大事務的速度沒有較小事務的速度快。
o 大的事務會增加丟失操作的數目,一旦事務失敗,必須重複執行。
o 大的事務使用更多的內存。
DataMemory的預設值是80MB,最小為1MB。沒有最大尺寸限制,但在實際使用過程中,最大限制應恰當,以便當達到最大限制時,程序不會啟動交換功能。該限制由機器上可用的物理RAM量、以及作業系統能提交給任何程序的內存量決定。對於32位作業系統,該限制值為每程序2~4GB,對於64位作業系統,該限制值更大。對於大的資料庫,出於該原因,最好使用64位作業系統。此外,在每台機器上也能運行一個以上的ndbd程序,在使用多CPU的機器上,該特性頗具優勢。
· [NDBD]IndexMemory
該參數用於控制MySQL叢集中哈希(混編)索引所使用的儲存量。哈希(混編)索引總用於主鍵索引、唯一性索引、以及唯一性約束。注意,定義主鍵和唯一性索引時,將建立兩條索引,其中一條是用於所有tuple訪問和鎖定處理的哈希(混編)索引。此外,它還能用於增強唯一性約束。
哈希(混編)索引的大小是每記錄25字節,再加上主鍵的大小。對大於32字節的主鍵,還需加上8字節。
考慮下例定義的資料表:
CREATE TABLE example (
a INT NOT NULL,
b INT NOT NULL,
c INT NOT NULL,
PRIMARY KEY(a),
UNIQUE(b)
) ENGINE=NDBCLUSTER;
有12字節的開銷(無可空列將節省4字節的開銷)加上每記錄12字節的數據。此外,在列a和b上有兩個有序索引,假定每記錄分別耗用約10字節的空間。在每記錄約使用29字節的基資料表上有1條主鍵哈希索引。唯一性約束由以b作為主鍵以及a作為列的單獨資料表實現。對於該資料表,每記錄將耗用額外的29字節索引內存,在示範資料表中,還包括12字節的開銷再加上8字節的記錄數據。
因此,對於100萬條記錄,需要58MB的索引內存來處理用於主鍵和唯一性約束的哈希索引。還需要64 MB來處理基資料表和唯一索引資料表、以及兩個有序索引資料表的記錄。
由此可見,哈希索引佔用了相當大的內存空間,但作為回報,它們提供了對數據的極快訪問。在MySQl叢集中,它們也用於處理唯一性約束。
目前僅有的分區算法是散列法,有序索引對每個節點來說都是局部性的。因此,有序索引不能用於處理一般情況下的唯一性約束。
對於IndexMemory和DataMemory,重要的是,總的資料庫大小是各節點組的所有數據內存和所有索引內存之和。每個節點組用於保存複製訊息,因此,如果有4個節點和2個副本,將有2個節點組。對於每個數據節點,可用的總數據內存是2*DataMemory。
強烈建議為所有的節點設置相同的DataMemory值和IndexMemory值。由於數據是平均分佈在叢集中的所有節點上,任何節點可用的最大空間不超過叢集中最小節點的可用空間。
DataMemory和IndexMemory可被更改,但降低任何一個的值均會導致危險,如果這樣做,很容易使某一節點甚至整個叢集因缺少足夠的內存空間而無法重啟。增加它們的值應是可接受的,但建議採用與軟件升級相同的方式升級它,首先更新配置檔案,然後重啟管理伺服器,最後依次重啟每個數據節點。
更新不會增加所用的索引內存。插入將立刻生效,但是,在提交事務之前並不會實際刪除行。
IndexMemory的預設值是18MB。最小值為1MB。
事務參數
下面討論的三個參數十分重要,這是因為,它們會影響並發事務的數目,以及系統能夠處理的事務的大小。MaxNoOfConcurrentTransactions用於設置節點內可能的並發事務數目。MaxNoOfConcurrentOperations用於設置能同時出現在更新階段或同時鎖定的記錄數目。
對於打算設定特定值、不使用預設值的用戶,這兩個參數可能正是他們所需的(尤其是MaxNoOfConcurrentOperations)。預設值是為使用小型事務的系統而設置的,為的是確保這類事務不會使用過多的內存。
· [NDBD]MaxNoOfConcurrentTransactions
對於叢集中的每個活動事務,必須在叢集節點之一中有1條記錄。對事務的協調任務是在各節點間進行的:在叢集中,事務記錄的總數等於任意給定節點中的事務數乘以叢集中的節點數。
事務記錄被分配給單獨的MySQL伺服器。正常情況下,對於使用叢集中任何資料表的每個連接,必須為其分配至少1條事務記錄。出於該原因,應確保叢集中的事務記錄數大於叢集中所有MySQL伺服器的並發連接數。
對於所有的叢集節點,必須將該參數設置為相同的值。
更改該參數不安全,如果這樣做,會導致叢集崩潰。當某一節點崩潰時,叢集中的一個節點(實際上是生存時間最久的節點)將為崩潰之時正在崩潰節點中運行的所有事務建立事務狀態。因此,重要的是,該節點的事務記錄數不低於失效節點中的事務記錄數。
該參數的預設值為4096.
· [NDBD]MaxNoOfConcurrentOperations
根據事務的大小和數目調整該參數的值,這個想法不錯。執行僅包含少量操作且不涉及很多記錄的事務時,不需要將該參數設置得很高。但在執行涉及大量記錄的大事務時,需要將該參數設置得較高。
對於每次事務更新的叢集數據,均會保存記錄,並會將它們保存在事務協調器中以及執行實際更新的節點中。這些記錄包含所需的狀態訊息,這類訊息可用於為回滾操作找到UNDO記錄,用於鎖定查詢或其他目的。
該參數應被設置為:事務中同時更新的記錄數除以叢集數據節點的數目。例如,在包含4個數據節點的叢集中,如果預期處理的、使用事務的並發更新數為1000000,就應將該值設置為1000000 / 4 = 250000。
設置鎖定的讀請求也會導致操作記錄的建立。在單獨節點內也會分配一些額外的空間,以便處理在節點間分配不完美的問題。
當查詢使用唯一性哈希索引時,對於事務中的每條記錄,實際上將使用兩條操作記錄。第1條記錄代資料表在索引資料表中的讀,第2條記錄負責處理基資料表上的操作。
該參數的預設值為32768.
該參數實際上處理的是能分別配置的兩個值。第1個值指定了將多少操作記錄放到事務協調器中,第2個值指定了多少操作記錄是資料庫的本地記錄。
對於在8節點叢集上執行的特大事務,它要求事務協調器中的操作記錄數不少於事務中涉及的讀取、更新和刪除次數。然而,叢集中的操作記錄分佈在所有的8個節點上。因此,如果有必要為特大事務配置系統,良好的方法是分別配置該參數的兩個部分。MaxNoOfConcurrentOperations總會被用於計算節點的事務協調器部分中的操作記錄數。
應瞭解操作記錄對內存的要求,這點也很重要。每記錄約消耗1KB。
· [NDBD]MaxNoOfLocalOperations
預設情況下,將按照1.1 * MaxNoOfConcurrentOperations計算該參數,它適合於具有很多並發事務但不存在特大事務的系統。如果需要在某一時間處理特大事務而且有很多節點,最好通過明確指定該參數以覆蓋預設值。
事務臨時儲存
下一組參數用於決定執行作為叢集事務組成部分的查詢時所需的臨時儲存空間。查詢完成後將釋放所有記錄,叢集將等待提交或回滾事件。
對於大多數情況,這些參數的預設值是恰當的。但是,如果需要支援涉及大量行或操作的事務,用戶或許應增大這些參數的值,以便在系統中獲得更好的平行性。對於需要相對較少事務的應用程式,用戶可降低這些參數的值,以便節省內存。
· [NDBD]MaxNoOfConcurrentIndexOperations
對於使用唯一性哈希索引的查詢,在查詢執行期間,將使用操作記錄的另一個臨時集合。該參數用於設置記錄池的大小。因此,僅當執行查詢的某一部分時才會分配該記錄,一旦該部分執行完成,將釋放記錄。對於處理放棄和提交所需的狀態,它是由正常的操作記錄負責處理的,這類記錄的池大小由參數MaxNoOfConcurrentOperations設置。
該參數的預設值為8192。只有在極其罕見的情況下,需要使用唯一性哈希索引執行極高的並行操作時,才有必要增大該值。如果DBA(資料庫管理員)確信該叢集不需要高的並行操作,可以使用較小的值並節省內存。
· [NDBD]MaxNoOfFiredTriggers
MaxNoOfFiredTriggers的預設值是4000,它足以應付大多數情況。在某些情況下,如果DBA認為在叢集中對並行操作的要求並不高,甚至還能降低它。
執行會影響唯一哈希索引的操作時,將建立記錄。在具有哈希索引的資料表中插入或刪除記錄時,或更新作為唯一哈希索引組成部分的列時,均會觸發索引資料表中的插入或刪除操作。所獲得的記錄用於代資料表該索引資料表操作,同時等待促使其完成的初始操作。該操作的時間很短,但對於在基資料表(包含唯一哈希索引)上有很多並發寫操作的情形,仍需要在記錄池中有大量的記錄。
· [NDBD]TransactionBufferMemory
該參數影響的內存用於跟蹤更新索引資料表和讀取唯一索引時執行的操作。該內存用於保存關於這類操作的鍵和列訊息。幾乎不需要更改該參數的預設值。
正常的讀和寫操作使用類似的緩衝區,其使用時間甚至更短。編譯時間參數ZATTRBUF_FILESIZE(在ndb/src/kernel/blocks/Dbtc/Dbtc.hpp中)被設為4000*128字節(500KB)。用於 鍵訊息的類似緩衝區,ZDATABUF_FILESIZE(也在Dbtc.hpp中)包含4000 * 16 = 62.5KB的緩衝空間。Dbtc是用於處理事務協調的模塊。
掃瞄和緩衝
在Dblqh模塊中(在ndb/src/kernel/blocks/Dblqh/Dblqh.hpp內)有很多附加參數,這些參數會影響讀和寫操作。這些參數包括:ZATTRINBUF_FILESIZE,預設值為10000*128字節(1250KB);以及ZDATABUF_FILE_SIZE,預設的緩衝空間大小為10000*16字節(約156KB)。到目前為止,沒有任何跡象表明應增加這類編譯時間限制參數的值,無論是用戶報告還是我們自己的大量測試。
TransactionBufferMemory的預設值是1MB。
· [NDBD]MaxNoOfConcurrentScans
該參數用於控制可在叢集中執行的並行掃瞄的數目。每個事務協調程式均能處理為該參數定義的並行掃瞄。對於每次執行的掃瞄查詢,將以並行方式掃瞄所有分區。每次分區掃瞄將使用分區所在節點內的掃瞄記錄,記錄數等於該參數的值乘以節點數。叢集應能支援從叢集內所有節點同時執行的MaxNoOfConcurrentScans掃瞄。
掃瞄實際上是在兩種情況下執行的。第1種情況是,處理查詢時不存在哈希或有序索引,在該情況下,查詢是通過執行全資料表掃瞄進行的。第2種情況是,沒有支援查詢的哈希索引,但存在有序索引。使用有序索引意味著將執行並發範圍掃瞄。由於順序僅保存在本地分區上,需要在所有分區上執行索引掃瞄。
MaxNoOfConcurrentScans的預設值是256。最大值為500。
該參數指定了事務協調器中的可能掃瞄數。如果未提供本地掃瞄記錄的數目,會對其進行計算,等於MaxNoOfConcurrentScans乘以系統中數據節點的數目。
· [NDBD]MaxNoOfLocalScans
如果很多掃瞄不是完全並行化的,指定本地掃瞄記錄的數目。
· [NDBD]BatchSizePerLocalScan
該參數用於計算鎖定記錄的數目,要想處理很多並發掃瞄操作,需要這類記錄。
預設值是64,該值與SQL節點中定義的ScanBatchSize關係密切。
· [NDBD]LongMessageBuffer
這是用於在單獨節點內和節點之間傳遞消息的內部緩衝。儘管幾乎不需要改變它,但它仍是可配置的。預設情況下,它被設置為1MB。
日誌和Checkpointing
· [NDBD]NoOfFragmentLogFiles
該參數用於設置節點的REDO日誌檔案的大小。REDO日誌檔案是按循環方式組織的。第1個和最後1個日誌檔案(有時也分別稱為「頭」日誌檔案和「尾」日誌檔案)不應相遇,這點極其重要,當它們彼此過於接近時,由於缺少新日誌記錄的空間,節點將開始放棄所有事務,包括更新。
自插入日誌記錄開始,在三個本地檢查點完成之前,不會刪除REDO日誌記錄。檢查點的頻率由其自己的配置參數集決定,請參見本章的相應部分。
預設的參數值為8,它資料表示有8個集合,每個集合有4個16MB檔案,總容量為512MB。換句話講,REDO日誌空間必須按64MB的塊大小分配。在需要大量更新的情況下,可能需要將NoOfFragmentLogFiles的值增加到300或更高,以便為REDO日誌提供足夠的空間。
如果checkpointing很慢,並有很多對資料庫的寫操作以至於日誌檔案已滿,而且在沒有jeapo rdising恢復功能的情況下無法截斷日誌尾部,那麼所有的更新日誌均將被放棄,並給出錯誤代碼410或缺少臨時日誌空間。該狀況將一直持續,直至完成了檢查點操作並能將日誌尾部向前移動為止。
· [NDBD]MaxNoOfSavedMessages
該參數用於設置跟蹤檔案的最大數目,在覆蓋舊檔案之前,將保留這些跟蹤檔案。無論出於何種原因,當節點崩潰時將建立跟蹤檔案。
預設為25個跟蹤檔案。
元數據對像
下一組參數為元數據對像定義了池的大小,可用於定義最大屬性數,資料表,索引,索引使用的觸發程式對象,事件,以及叢集之間的複製。注意,這些參數僅是對叢集的「建議」,任何未指定的參數均將採用其預設值。
· [NDBD]MaxNoOfAttributes
定義了可在叢集中定義的屬性數目。
該參數的預設值為1000,最小的可能值為32。沒有最大值限制。對於每一屬性,每節點約需200字節的儲存空間,這是應為,所有的元數據將完整地複製到伺服器上。
設置MaxNoOfAttributes時,應實現準備好打算在將來執行的任何ALTER TABLE命令,這點很重要。這是因為下述事實,在叢集資料表上執行ALTER TABLE的過程中,所使用的屬性數目是原始資料表中的3倍。例如,如果某一資料表需要100個屬性,而且您打算在以後更改它,那麼就需要將MaxNoOfAttributes的值設為300。有一個良好的經驗規則,如果您能在不出現問題的情況下建立所有所需的資料表,請將最大資料表中屬性數目的兩倍加到MaxNoOfAttributes上。完成該設置後,應通過執行實際的ALTER TABLE操作,驗證該數目是足夠的。如果失敗,將原始值的倍數加到MaxNoOfAttributes上,並再次測試。
· [NDBD]MaxNoOfTables
資料表對象是為每個資料表、唯一哈希索引和有序索引分配的。該參數為作為整體的叢集設置了最大資料表對像數目。
對於具有BLOB數據類型的每個屬性,將使用額外的資料表來保存大部分BLOB數據。定義資料表的總數時,必須將這些資料表考慮在內。
該參數的預設值為128。最小值為8,最大值為1600。每個資料表對像每節點約需20KB的空間。
· [NDBD]MaxNoOfOrderedIndexes
對於叢集中的每個有序索引,將分配1個對象,該對像描述了編入索引的是什麼以及其儲存段。預設情況下,每個這樣定義的索引還將定義1個有序索引。每個唯一索引和主鍵既有1個有序索引還有1個哈希索引。
該參數的預設值為128。每個對象每節點約需10KB的數據。
· [NDBD]MaxNoOfUniqueHashIndexes
對於每個不是主鍵的唯一索引,將分配1個特殊資料表,該資料表將唯一鍵映射到索引資料表的主鍵上。預設情況下,對於每個唯一索引,還將定義1個有序索引。為了防止該情況,定義唯一索引時,必須使用USING HASH選項。
預設值是64。每個索引每節點約需15KB的空間。
· [NDBD]MaxNoOfTriggers
對於每個唯一性哈希索引,將分配內部更新、插入、和刪除觸發程式(這意味著對於每個唯一性哈希索引,將建立三個觸發程式)。但是,1個有序索引僅需要1個觸發程式對象。對於叢集中每個正常資料表,備份也將使用三個觸發程式對象。
註釋:支援叢集之間的複製時,也將使用內部觸發程式。
該參數用於設置叢集中觸發程式對象的最大數目。
該參數的預設值為768.
· [NDBD]MaxNoOfIndexes
在MySQL 5.1中,該參數已被放棄,應使用MaxNoOfOrderedIndexes和MaxNoOfUniqueHashIndexes取而代之。
該參數僅供唯一性哈希索引使用。對於在叢集中定義的每個唯一性哈希索引,在該池中需要有1條記錄。
該參數的預設值為128.
布爾參數
數據節點的行為也會受具有布爾值的一組參數的影響。將其設為「1」或「Y」,可將這類參數設置為「真」,將其設為「0」或「N」,可將這類參數設置為「假」。
· [NDBD]LockPagesInMainMemory
對於包括Solaris和Linux在內的很多作業系統,能夠將程序鎖定在內存中,以避免與磁盤的交換。使用它,可確保叢集的實時特性。
預設情況下,該特性是被禁止的。
· [NDBD]StopOnError
出現錯誤時,該參數指定了NDBD程序是退出還是執行自動重啟。
預設情況下,允許該特性。
· [NDBD]Diskless
能夠將MySQL叢集的資料表指定為「無磁盤的」,這意味著不會在磁盤上對資料表執行檢查點操作,也不會出現日誌操作。這類資料表僅存在於主內存中。使用「無磁盤」資料表的一個結果是,出現崩潰侯,不會保留這類資料表,也不會保留這類資料表中的任何記錄。但是,當工作在「無磁盤」模式下時,能夠在無盤計算機上運行ndbd。
要點:該特性會使整個叢集運行在「無磁盤」模式下。
允許該特性時,可執行備份操作,但不會實際保存備份數據。
將「Diskless」設置為「1」或「Y」可允許該特性。預設情況下,禁止該特性。
· [NDBD]RestartOnErrorInsert
僅當建立調試版時才能訪問該特性,在執行作為測試組成部份的代碼塊的過程中,可以插入錯誤。
預設情況下,該特性是被禁止的。
控制超時、間隔、和磁盤分頁
有多種用於指定超時以及叢集數據節點中各種動作間時間間隔的參數。大多數超時值以毫秒為單位指定。任何例外均將在適用時指明。
· [NDBD]TimeBetweenWatchDogCheck
為了防止主線程在某一點上陷入無限循環,採用了「看門狗」線程來檢查主線程。該參數以毫秒為單位指定了檢查之間的時間間隔。如果三次檢查之後程序仍保持在相同的狀態,它將被「看門狗」線程中止。
出於試驗目的,可方便地更改該參數,也可以對其進行調整以適合本地條件。也可以按節點指定它,雖然這樣作的理由很少。
預設超時為4000毫秒(4秒)。
· [NDBD]StartPartialTimeout
該參數指定了在使用叢集初始化子程式之前,叢集等待所有儲存節點出現的時間。該超時參數由於防止部分叢集啟動。
預設值是30000毫秒(30秒)。0資料表示無限超時,換句話講,僅當所有節點均可能時才會啟動叢集。
· [NDBD]StartPartitionedTimeout
等待了StartPartialTimeout毫秒後,如果叢集做好了啟動準備但仍可能處於隔離狀態,叢集將等待該超時時間結束。
預設超時為60000毫秒(60秒)。
· [NDBD]StartFailureTimeout
如果數據節點在該參數指定的時間內未完成其啟動序列,節點啟動將失敗。如果將該參數設置為0,資料表示不採用數據節點超時。
預設值是60000毫秒(60秒)。對於包含大量數據的數據節點,應增加該參數。例如,對於包含數GB數據的儲存節點,為了執行節點重啟,可能需要10~15分鐘(即600000~1000000毫秒)。
· [NDBD]HeartbeatIntervalDbDb
發現失敗節點的主要方法之一是使用「心跳」數。該參數指明了心跳信號的發送頻率,以及接收它們的頻率。如果在1行內丟失了三次心跳,節點將被宣告為死亡。因此,通過心跳機制發現故障的最大時間是心跳間隔的四倍。
預設的心跳間隔為1500毫秒(1.5秒)。不得大幅度更改該參數,各節點間該參數的變化範圍也不得過寬。例如,如果某一節點使用了5000毫米的值,而觀察它的節點採用1000毫秒,很顯然,該節點很快就會被宣佈為死亡。能夠在軟件升級期間更改該參數,但增量應較小。
· [NDBD]HeartbeatIntervalDbApi
每個數據節點會將心跳信號發送到各MySQL伺服器(SQL節點),以確保保持接觸。如果某一MySQL伺服器未能及時發出心跳信號,它將被宣佈為死亡。在這種情況下,所有正在進行的事務將結束並釋放所有資源。SQL節點不能重新連接,直至由以前的MySQL實例初始化的所有活動完成為止。用於該判斷的3心跳判據與HeartbeatIntervalDbDb描述的相同。
預設時間間隔為1500毫秒(1.5秒)。不同的數據節點之間,該間隔可以有所不同,這是因為,每個儲存節點均會獨立於所有其他數據節點觀察與之相連的MySQL伺服器。
· [NDBD]TimeBetweenLocalCheckpoints
該參數是一個例外,它未指定啟動新的本地檢查前應等待的時間,相反,它用於確保在出現相對較少更新的叢集內未執行本地檢查點操作。在具有較高更新率的大多數叢集內,很可能在前一個本地檢查點操作完成後立刻啟動一個新的檢查點操作。
從前一個本地檢查點啟動後,所有已執行寫操作的大小將增加。該參數也是一個例外,原因在於它被指定為4字節字總數的以2為底數的對數,因此,預設值20資料表示4MB (4 × 220)寫操作,21資料表示8MB,依此類推,直至等同於8GB寫操作的最大值31。
叢集中所有的寫操作將加在一起。將TimeBetweenLocalCheckpoints設置為6或更小資料表示本地檢查點操作將不停頓地連續執行,與叢集的工作負荷無關。
· [NDBD]TimeBetweenGlobalCheckpoints
提交事務時,它被提交到存有鏡像數據的所有節點的主內存中。但是,事務日誌記錄不會作為提交程序的一部分寫入磁盤。其原因在於,在至少兩台獨立主機機器上安全體提交事務應能滿足關於關於持久性的合理標準。
另一個很重要的方面是,應確保即使在最差情況下(叢集完全崩潰),也能進行恰當地處理。為了確保這點,在給定時間間隔內出現的所有事務均會被放到全局檢查點,可將其視為寫入磁盤的已提交事務的集合。換句話講,作為提交程序的組成部分,事務將被放入全局檢查點組;稍後,該組的日誌記錄將被寫入磁盤,然後將整個事務組安全地提交到叢集內所有計算機的磁盤上。。
該參數定義了全局檢查點操作之間的時間間隔。預設值為2000毫秒。 milliseconds.
· [NDBD]TimeBetweenInactiveTransactionAbortCheck
對於該參數指定的每個時間間隔,通過檢查每個事務的定時器來執行超時處理。因此,如果該參數被設為1000毫秒,每隔1秒就會對事務進行檢查。
該參數的預設值為1000毫秒(1秒)。
· [NDBD]TransactionInactiveTimeout
如果事務目前未執行任何查詢,而是等待進一步的用戶輸入,該參數指明了放棄事務之前用戶能夠等待的最長時間。
該參數的預設值是0(無超時)。對於需要確保無任何事務鎖定了過長時間的資料庫,應將參數設置為較小的值。單位為毫秒。
· [NDBD]TransactionDeadlockDetectionTimeout
當節點執行涉及事務的查詢時,在繼續之前,節點將等待叢集中其他節點作出回應。如果出現下述原因,將無法予以回應:
1. 節點「死亡」。
2. 操作進入鎖定隊列。
3. 被請求執行動作的節點負荷過重。
該超時參數指明了放棄事務之前,事務協調器等候另一節點執行查詢的時間長短,該參數在節點失敗處理和死鎖檢測方面十分重要。在涉及死鎖和節點失敗的情形下,如果將其設置的過高,會導致不合需要的行為。
預設的超時值為1200毫秒(1.2秒)。
· [NDBD]NoOfDiskPagesToDiskAfterRestartTUP
執行本地檢查點操作時,相應的算法會將所有數據頁寫入磁盤。如果追求盡快完成該操作而不是適中,很可能會對處理器、網絡和磁盤帶來過重負擔。為了控制寫入速度,該參數指明了每100毫秒可寫入多少數據頁。在本情形下,1個數據頁定義為8KB,因而該參數的單位是每秒80KB。因此,如果將NoOfDiskPagesToDiskAfterRestartTUP設置為20,那麼在執行本地檢查點操作期間,要求每秒想磁盤寫入1.6MB的數據。該值包括針對數據頁的UNDO日誌記錄寫入,也就是說,該參數能處理來自數據內存的寫入限制。置於針對索引頁的UNDO日誌記錄,它們是由參數NoOfDiskPagesToDiskAfterRestartACC處理的(關於索引頁的更多訊息,請參見關於IndexMemory的條目)。
簡而言之,該參數指定了執行本地檢查點操作的速度,並能與NoOfFragmentLogFiles、DataMemory和IndexMemory一起使用。
預設值是40(每秒3.2MB的數據頁)。
· [NDBD]NoOfDiskPagesToDiskAfterRestartACC
該參數使用的單位與NoOfDiskPagesToDiskAfterRestartTUP的相同,工作方式也類似,但限制的是從索引內存進行的索引頁寫入速度。
該參數的預設值為每秒20個索引內存頁(1.6MB每秒)。
· [NDBD]NoOfDiskPagesToDiskDuringRestartTUP
該參數的工作方式類似於NoOfDiskPagesToDiskAfterRestartTUP和NoOfDiskPagesToDiskAfterRestartACC,但僅對重啟節點時在節點內執行的本地檢查點操作有效。作為所有節點重啟的組成部份,總會執行本地檢查點操作。在節點重啟過程中,能夠以比其他時間更快的速度執行磁盤寫入操作,這是因為,此時在節點內執行的活動數較少。
該參數涉及從數據內存寫入的頁。
預設值是40(3.2MB每秒)。
· [NDBD]NoOfDiskPagesToDiskDuringRestartACC
在節點重啟的本地檢查點階段,對能夠寫入到磁盤的索引內存頁的數目進行控制。
與NoOfDiskPagesToDiskAfterRestartTUP和NoOfDiskPagesToDiskAfterRestartACC一樣,該參數的值採用的單位也是每100毫秒寫入8KB(80KB/秒)。
預設值是20 (1.6MB每秒)。
· [NDBD]ArbitrationTimeout
該參數指定了數據節點等待仲裁程式對仲裁消息的回應的時間。如果超過了該時間,將假定網絡已中斷。
預設值是1000毫秒(1秒)。
緩衝和日誌功能
一些與以前的編譯時間參數對應的配置參數仍可用。使用這些參數,高級用戶能夠對節點程序使用的資源進行更多的控制,並能根據需要調整各種緩衝區大小。
將日誌記錄寫入磁盤時,這些緩衝區用作檔案系統的前端。如果節點運行在無盤模式下,那麼可以將這些參數設置為它們的最小值而不會造成負面影響,這是因為,磁盤寫入是由NDB儲存引擎的檔案系統提取層虛擬的。
· [NDBD]UndoIndexBuffer
該緩衝用於本地檢查點操作執行期間。NDB儲存引擎採用了一種恢復方案,該方案建立在檢查點一致性以及操作性REDO日誌值上。為了在不隔斷整個系統的寫操作的情況下獲得一致的檢查點,在執行本地檢查點操作的同時,將執行UNDO日誌操作。UNDO日誌功能每次是在單個資料表偏短上觸發的。由於資料表全部保存在主內存中,該最佳化是可能的。
UNDO索引緩衝用於主鍵哈希索引上的更新。插入和刪除操作會導致哈希索引的重新排列,NDB儲存引擎將映射了所有物理變化的UNDO日誌記錄寫入索引頁,以便能在系統重啟時撤銷這些變化。它還能記錄啟動本地檢查點操作時對每個偏短的所有插入操作。
讀取和更新能夠設置鎖定位,並更新哈希索引條目中的標題。這類變更由頁寫入算法負責處理,以確保這些操作不需要UNDO日誌。
該緩衝的預設大小為2MB。最小值為1MB,對於大多數應用,最小值已足夠。對於執行極大和/或大量插入和刪除操作、並處理大事務和大主鍵的應用程式,或許有必要增大該緩衝。如果該緩衝過小,NDB儲存引擎會發出錯誤代碼677「索引UNDO緩衝過載」。
· [NDBD]UndoDataBuffer
UNDO數據緩衝的作用與UNDO索引緩衝的相同,不同之處在於,它作用在數據內存上而不是索引內存上。對於插入、刪除和更新,該緩衝是在片段的本地檢查點階段使用的。
由於UNDO日誌條目會隨著所記錄操作的增加而增大,該緩衝大於與之對應的索引內存緩衝,預設值為16MB。
對於某些應用程式,該內存可能過大。在這種情況下,可降低它的值,最小為1MB。
需要增加該緩衝的情況十分罕見。如果確實有這方面的要求,較好的方式是,檢查磁盤是否能實際處理資料庫更新活動所產生的負荷。如果缺少足夠的磁盤空間,即使增加該緩衝的大小也不能解決問題。
如果該緩衝過小並變得「擁擠不堪」,NDB儲存引擎將發出錯誤代碼891「數據UNDO緩衝過載」。
· [NDBD]RedoBuffer
所有的更新活動也需要被記錄到日誌中。使用這類日誌,當系統重啟時,能夠重現這類更新。NDB恢復算法採用了「模糊」數據檢查點和UNDO日誌,然後使用REDO日誌再現所有變化直至到達恢復點。
該緩衝的預設大小是8MB。最小值為1MB。
如果該緩衝過小,NDB儲存引擎將發出錯誤代碼1221「REDO日誌緩衝過載」。
在管理叢集的過程中,應能控制為各種事件類型發送至標準輸出裝置的日誌消息的數目,這點十分重要。有16種可能的事件級別(編號從0到15)。如果將給定事件類別的事件通報級別設置為15,那麼該類別中的所有事件報告均會被發送至標準輸出裝置,如果將其設置為0,資料表示在該類別中的沒有事件報告。
預設情況下,僅會將啟動消息發送至標準輸出裝置,其餘的事件通報級別預設為0。這樣做的原因在於,這些消息也會被發送至管理伺服器的叢集日誌。
對於管理客戶端,也能設置類似的級別,用以確定在叢集日誌中記錄哪些級別的事件。
· [NDBD]LogLevelStartup
通報級別,用於程序啟動過程中生成的事件。
預設級別為1.
· [NDBD]LogLevelShutdown
通報級別,用於作為節點恰當關閉程序組成部分而生成的事件。
預設級別為0.
· [NDBD]LogLevelStatistic
通報級別,用於統計事件,如主鍵法讀取次數,更新數目,插入數目,與緩衝使用有關的訊息等。
預設級別為0.
· [NDBD]LogLevelCheckpoint
通報級別,用於由本地和全局檢查點操作生成的事件。
預設級別為0.
· [NDBD]LogLevelNodeRestart
通報級別,用於在節點重啟過程中生成的事件。
預設級別為0.
· [NDBD]LogLevelConnection
通報級別,用於由叢集節點間的連接生成的事件。
預設級別為0.
· [NDBD]LogLevelError
通報級別,用於由在整個叢集內的錯誤和警告生成的事件。這類錯誤不會導致任何節點失敗,當仍值得通報。
預設級別為0.
· [NDBD]LogLevelInfo
通報級別,用於為叢集的一般狀態訊息而生成的事件。
預設級別為0.
備份參數
本節討論的參數定義了與線上備份執行有關的內存緩衝集。
· [NDBD]BackupDataBufferSize
在建立備份的過程中,為了將數據發送到磁盤,將使用兩類緩衝。備份數據緩衝用於填充由掃瞄節點的資料表而記錄的數據。一旦將該緩衝填充到了指定的水平BackupWriteSize(請參見下面的介紹),就會將頁發送至磁盤。在將頁寫入磁盤的同時,備份程序能夠繼續填充該緩衝,直至其空間消耗完為止。出現該情況時,備份程序將暫停掃瞄,直至一些磁盤寫入操作完成並釋放了內存為止,然後掃瞄繼續。
該參數的預設值為2MB。
· [NDBD]BackupLogBufferSize
備份日誌緩衝扮演的角色類似於備份數據緩衝,不同之處在於,它用於生成備份執行期間進行的所有資料表寫入的日誌。相同的原理也適用於備份數據緩衝情形下的頁寫入,不同之處在於,當備份日誌緩衝中沒有多餘空間時,備份將失敗。出於該原因,備份日誌緩衝的大小應足以處理執行備份時產生的負載。
該參數的預設值對於大多數應用程式均是適當的。事實上,備份失敗的原因更可能是因為磁盤寫入速度不夠,而不是備份日誌緩衝變滿。如果沒有為應用程式產生的寫負載配置磁盤子系統,叢集很可能無法執行所需的操作。
最好按恰當的方式配置叢集,使得處理器成為瓶頸而不是磁盤或網絡連接。
預設值是2MB。
· [NDBD]BackupMemory
該參數是BackupDataBufferSize和BackupLogBufferSize之和。
預設值是2MB + 2MB = 4MB。
· [NDBD]BackupWriteSize
該參數指定了由備份日誌緩衝和備份數據緩衝寫入磁盤的消息大小。
預設值是32KB.
· [MYSQLD]Id
該值用作節點的地址,供所有的叢集內部消息使用,它必須是介於1和63之間的整數。在叢集內,每個叢集節點必須有唯一的ID。
· [MYSQLD]ExecuteOnComputer
它引用的是在配置檔案的[COMPUTER]部分定義的主機(計算機)之一。
· [MYSQLD]ArbitrationRank
該參數用於定義可作為仲裁程式的節點。MGM節點和SQL節點均能成為仲裁程式。如果值為0,表明給定的節點永遠不會用作仲裁程式,如果值為1,表明給定的節點在成為仲裁程式方面具有高的優先級,如果值為2,表明給定的節點在成為仲裁程式方面具有低的優先級。對於正常配置,使用管理伺服器作為仲裁程式,將它的ArbitrationRank設置為1(預設),並將所有SQL節點的ArbitrationRank設置為0。
· [MYSQLD]ArbitrationDelay
如果將該參數設置為除0(預設值)以外的其他值,資料表示仲裁程式對仲裁請求的相應將被延遲設定的毫秒數。通常不需要更改該值。
· [MYSQLD]BatchByteSize
對於轉換為全資料表掃瞄或對索引的範圍掃瞄的查詢,要想獲得最佳性能,重要的是以恰當的大小獲取記錄。能夠以記錄數為單位(BatchSize)和字節為單位(BatchByteSize)設置恰當的大小。實際的批大小由兩個參數限定。
查詢的執行速度可能會出現40%的變化,具體情況取決於該參數的設置。在未來的版本中,MySQL伺服器將根據查詢類型恰當地設置與批大小相關的參數。
該參數以字節為單位,預設值是32KB。
· [MYSQLD]BatchSize
該參數以記錄數為單位,預設值是64。最大值為992。
· [MYSQLD]MaxScanBatchSize
批大小指的是從各數據節點發送的每批數據的大小。大多數掃瞄均是以並行方式執行的,目的是為了防止MySQL伺服器收到來自眾多節點的過多數據,該參數對所有節點上的總的批大小進行了限制。
該參數的預設值為256KB。其最大大小為16MB。
在MySQL叢集中,TCP/IP是用於建立連接的預設傳輸協議。正常情況下不需要定義連接,這是因為,叢集能自動建立數據節點間、數據節點與所有MySQL伺服器節點、以及數據節點與管理伺服器之間的連接(關於該規則的例外,,請參見17.4.4.8節,「使用直接連接的MySQL叢集TCP/IP連接」)。
如果打算覆蓋預設的連接參數,才需要定義連接。在這種情況下,至少需要定義NodeId1、NodeId2、以及打算更改的參數。
通過在[TCP DEFAULT]部分進行設置,也能更改這些參數的預設值。
· [TCP]NodeId1 , [TCP]NodeId2
要想確定兩個節點之間的連接,需要在配置檔案的〔TCP〕部分中提供每個節點的ID。
· [TCP]SendBufferMemory
在向作業系統發出使用請求之前,TCP傳輸器採用緩衝來保存所有的消息。當該緩衝達到64KB時,將發送其內容,執行完一組消息循環後,也將發送這些內容。為了處理臨時過載情況,也能定義一個較大的發送緩衝。發送緩衝的預設值是256KB。
· [TCP]SendSignalId
為了能夠回掃分佈式消息圖,需要確定每條消息。將該參數設置為「Y」時,將通過網絡傳輸消息ID。預設情況下禁止該特性。
· [TCP]Checksum
該參數也是一個布爾參數(Y/N或1/0),預設情況下是禁止的。啟用了該參數時,在將所有消息置於發送緩衝之前,將為所有參數計算校驗和。使用該特性,當消息等候在發送緩衝中時,可以確保消息不會損壞,也能確保消息不會被傳輸機制破壞。
· [TCP]PortNumber
(已過時)以前,該參數指定了用於監聽來自其他節點的連接的端口號。不應再使用嘎參數。
· [TCP]ReceiveBufferMemory
指定了從TCP/IP套接字接收數據時所使用的緩衝大小。幾乎不需要更改該參數的預設值,預設值為64KB,但是如果打算節省內存,也能更改它。
在下面的示範中,假定叢集具有至少4台主機,1台用於管理伺服器,一台用於SQL節點,兩台用於數據節點。作為整體,叢集位於LAN的172.23.72.*子網內。除了通常的網絡連接外,兩個數據節點使用標準的交叉電纜直接相連,並使用範圍在1.1.0.*的IP地址彼此間直接通信,如下所示:
# Management Server
[NDB_MGMD]
Id=1
HostName=172.23.72.20
# SQL Node
[MYSQLD]
Id=2
HostName=172.23.72.21
# Data Nodes
[NDBD]
Id=3
HostName=172.23.72.22
[NDBD]
Id=4
HostName=172.23.72.23
# TCP/IP Connections
[TCP]
NodeId1=3
NodeId2=4
HostName1=1.1.0.1
HostName2=1.1.0.2
使用數據節點間的直接連接能夠改善叢集的整體效率,使用該方式,數據節點能繞過以太網設備,如交換器、Hub、路由器等,從而減少了叢集的等待時間。注意,對於兩個以上的數據節點,要想充分利用這類直接連接的優點,需要為各數據節點建立與相同節點組內的其他數據節點間的直接連接。
註釋:SHM支援仍應被視為試驗性的。
· [SHM]NodeId1, [SHM]NodeId2
要想確定兩個節點之間的連接,需要為每個節點提供節點ID,NodeId1和NodeId2。
· [SHM]ShmKey
設置共享內存段時,節點ID用於唯一地確定通信所用的共享內存段。它以整數資料表示,沒有預設值。
· [SHM]ShmSize
每個SHM連接均有一個共享內存段,發送方將節點之間的消息置於該處,讀取方從該處讀取這類消息。gai 共享內存段的大小由ShmSize定義。預設值是1MB。
· [SHM]SendSignalId
為了回掃分佈式消息的路徑,需要為每條消息提供唯一性ID。如果將該參數設置為「Y」,也能在網絡上傳輸這類消息ID。預設情況下,該特性是禁止的。
· [SHM]Checksum
該參數也是一種Y/N參數,預設情況下處於禁止狀態。如果允許該參數,在將所有消息置於發送緩衝之前,對為所有消息計算校驗和。
使用該特性,當消息等候在發送緩衝中時,能防止消息損壞。此外,它還能用於在傳輸過程中檢查損壞的數據。
此外,SCI要求專用硬件。
強烈建議,僅應為ndbd程序之間的通信使用SVI傳輸器。注意,使用SCI傳輸器意味著ndbd程序永不停止。因此,僅應在具有至少兩塊專供ndbd程序使用的CPU的機器上使用SCI傳輸器。每個ndbd程序至少應有1塊CPU,至少還應有1塊CPU用於處理作業系統的活動。
· [SCI]NodeId1, [SCI]NodeId2
為了確定兩個節點之間的連接,需要為每個節點提供節點ID,NodeId1和NodeId2。
· [SCI]Host1SciId0
它用於確定第1個叢集節點上的SCI節點ID(由NodeId1確定)。
· [SCI]Host1SciId1
能夠為兩塊SCI卡間的故障切換設置SCI傳輸器,這兩塊卡應使用節點之間的不同網絡。它用於確定節點ID,以及在第1個節點上使用的第2塊SCI卡。
· [SCI]Host2SciId0
它用於確定第2個叢集節點上的SCI節點ID(由NodeId2確定)。
· [SCI]Host2SciId1
使用兩塊SCI卡來提供故障切換功能時,該參數用於確定將在第2個節點上使用的第2塊SCI卡。
· [SCI]SharedBufferSize
每個SCI傳輸器均有1個用於兩節點間通信的共享內存段。可將該共享內存段設置為預設的1 MB,這足以應對大多數應用程式。如果使用較小的值,當執行大量並行插入操作時,會出現問題,如共享緩衝過小,還會導致ndbd程序崩潰。
· [SCI]SendLimit
SCI媒介前面的小緩衝用於保存消息,在通過SCI網絡傳輸這類消息前,會將它們保存在該緩衝內。它的預設值為8kB。按照我們的基準,在64KB時性能最好,但16kB僅有少量提升,即使大於8KB有好處,好處也不大。
· [SCI]SendSignalId
為了跟蹤分佈式消息,需要唯一地確定每條消息。將該參數設置為「Y」時,就能在網絡上傳輸消息ID。預設情況下禁止該特性。
· [SCI]Checksum
T該參數也是一種布爾值,預設情況下,該參數是被禁止的。啟用了Checksum(校驗和)時,在將所有消息置於發送緩衝之前,將為所有參數計算校驗和。使用該特性,當消息等候在發送緩衝中時,可以確保消息不會損壞。此外,它還能用於在傳輸過程中檢查損壞的數據。
mysqld是傳統的MySQL伺服器程序。要想與MySQL叢集一起使用,所建立的mysqld應支援NDB叢集儲存引擎,就像在預編譯的-max二進製版本中那樣,http://dev.mysql.com/downloads/。
即使採用該方式建立了mysqld二進製版本,在預設情況下,NDB叢集儲存引擎仍處於禁止狀態。要想啟用NDB叢集儲存引擎,可使用兩種可能的選項之一:
· 啟動mysqld時,將「—ndbcluster」用作啟動選項。
· 在my.cnf檔案的[mysqld]部分插入包含ndbcluster的1行內容。
驗證運行的伺服器是否啟用了NDB叢集儲存引擎的簡單方法是,在MySQL監視器(mysql)中發出命令SHOW ENGINES。在列出NDBCLUSTER的行中應能看到值YES,如果在該行上看到NO(或在輸出中未顯示該行),您所運行的是未啟用NDB功能的MySQl版本。如果在該行上看到DISABLED,就需採用上述兩種方法之一啟用它。
為了讀取叢集配置數據,MySQL伺服器至少需要3種訊息:
· MySQL伺服器自己的叢集節點ID。
· 管理伺服器(MGM節點)的主機名或IP地址。
· 與管理伺服器相連的端口。
節點ID可動態分配,因此不一定需要明確指定它們。
mysqld參數ndb-connectstring用於指定連接字串,或是在啟動mysqld時在命令行上指定,或是在my.cnf檔案中指定。連接字串包含主機名或IP地址,以及能夠發現管理伺服器的端口。
在下面的示範中,ndb_mgmd.mysql.com是管理伺服器所在的主機,管理伺服器在端口1186上監聽叢集消息。
shell> mysqld --ndb-connectstring=ndb_mgmd.mysql.com:1186
關於連接字串的更多訊息,請參見17.4.4.2節,「MySQL叢集連接字串」。
給定該訊息,MySQL伺服器將成為叢集中的完全參與者。(有時,我們也將運行在該方式下的mysqld程序稱為SQL節點)。它能完全瞭解所有的叢集數據節點以及它們的狀態,並能建立與所有數據節點的連接。在這種情形下,它能將任何數據節點用作事務協調器,並能訪問數據節點以執行讀取和更新操作。
ndbd是使用NDB叢集儲存引擎處理資料表中所有數據的程序。通過該程序,儲存節點能夠實現分佈式事務處理,節點恢復,對磁盤的檢查點操作,線上備份,以及相關的任務。
在MySQL叢集中,一組ndbd程序能夠共同處理數據。這些程序可以在相同的計算機(主機)上執行,也能在不同的計算機上執行。數據節點和叢集主機之間的通信是完全可配置的。
Ndbd將生成一組日誌檔案,這些檔案位於由配置檔案中DataDir指定的目錄下。下面列出了這些日誌檔案。注意,node_id代資料表節點的唯一ID。例如,ndb_2_error.log是由節點ID為2的儲存節點生成的錯誤日誌。
· ndb_node_id_error.log是包含所引用ndbd程序所遇到的所有崩潰記錄的檔案。該檔案中的每條記錄均包含1個簡要的錯誤字串,以及對該崩潰跟蹤檔案的引用。該檔案的典型條目與下面給出的類似:
· Date/Time: Saturday 30 July 2004 - 00:20:01
· Type of error: error
· Message: Internal program error (failed ndbrequire)
· Fault ID: 2341
· Problem data: DbtupFixAlloc.cpp
· Object of reference: DBTUP (Line: 173)
· ProgramName: NDB Kernel
· ProcessID: 14909
· TraceFile: ndb_2_trace.log.2
· ***EOM***
註釋:請記住,錯誤日誌檔案中的最後1個條目並不必然是最新的(也不太可能),這點很重要。錯誤日誌中的條目不是按時間順序排列的,而是與ndb_node_id_trace.log.next(請參見下面的介紹)中定義的跟蹤檔案的順序對應。因此,錯誤日誌條目是按循環方式而不是順序方式覆蓋的。
· ndb_node_id_trace.log.trace_id是準確描述了錯誤出現之時所發生情況的跟蹤檔案。該訊息在MySQL叢集開發團隊進行分析時很有幫助。
能夠對覆蓋舊檔案之前建立的跟蹤檔案的數目進行配置。trace_id是為每個連續的跟蹤檔案增加的編號。
· ndb_node_id_trace.log.next是記錄了要指定的下一個跟蹤檔案編號的檔案。
· ndb_node_id_out.log是包含ndbd程序的任何數據輸出的檔案。僅當將ndbd啟動為端口監督程式時才會建立該檔案。
· ndb_node_id.pid是包含啟動時作為端口監督程式的ndbd程序的程序ID的檔案。它還能起到鎖定檔案的作用,以防止啟動具有相同ID的節點。
· ndb_node_id_signal.log是僅在ndbd調試版下使用的檔案,它能跟蹤ndbd程序中所有的入站、出站和內部消息。以及它們的數據。
建議不要使用通過NFS安裝的目錄,這是因為在某些情況下,如果pid-file上的鎖定依舊有效,即使當程序中止後也會產生問題。
啟動ndbd時,或許需要指定管理伺服器的主機名以及監聽的端口號。作為可選方式,也可以指定程序將使用的節點ID。
shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"
關於這方面的額外訊息,請參見17.4.4.2節,「MySQL叢集連接字串」。
啟動ndbd時,它實際上將啟動兩種程序。第1種程序稱為「angel process」(天使程序),它的唯一任務是發現執行程序在何時完成,然後重啟ndbd程序(如果作了該配置的話)。因此,如果您打算使用Unix的kill命令殺死ndbd程序,就需要殺死這兩個程序。中止ndbd程序的更恰當方法是使用管理客戶端,並通過該管理客戶端停止程序。
執行程序採用了1個線程,用於讀取、寫入和掃瞄數據,以及所有其他任務。該線程是異步實施的,以便能方便地處理數以千計的並發活動。此外,看門狗線程負責監督執行線程,以確保執行線程不會陷入無限循環。線程池負責處理檔案I/O,每個線程均能處理一個打開的檔案。這些線程也能被ndbd程序中的傳輸器用作傳輸器連接。在執行包含更新在內的大量操作的系統中,如果允許,ndbd程序能佔用2個CPU。對於擁有多CPU的機器,建議使用屬於不同節點組的數個ndbd程序。
管理伺服器是這樣一種程序,它讀取叢集配置檔案,並將該訊息分配給叢集中所有請求該訊息的節點。它還負責維護叢集活動的日誌。管理客戶端能夠連接到管理伺服器,並檢查叢集的狀態。
啟動管理伺服器時,不是一定需要指定連接字串。但是,如果使用了1個以上的管理伺服器,應提供連接字串,而且叢集中的每個節點應明確指定自己的節點ID。
下述檔案是由ndb_mgmd在其啟動目錄下建立或使用的,並會被置於配置檔案中指定的DataDir中。在下面的列資料表中,node_id是唯一性節點ID。
· config.ini是作為整體的叢集的配置檔案。該檔案由用戶建立並由管理伺服器讀取。在17.4節,「MySQL叢集的配置」中,討論了設置該檔案的方法。
· ndb_node_id_cluster.log是叢集事件日誌檔案。這類事件的例子包括:檢查點操作的啟動和完成,節點啟動事件,節點故障,以及內存使用水平。關於叢集事件的完整列資料表和描述,請參見17.6節,「MySQL叢集的管理」。
當叢集日誌的大小達到1MB時,檔案將被重命名為ndb_node_id_cluster.log.seq_id,其中seq_id是叢集日誌檔案的序列號(例如,如果編號1、2、3已存在,下一個日誌檔案將用4命名)。
· ndb_node_id_out.log是將管理伺服器用作端口監督程式時用於stdout和stderr的檔案。
· ndb_node_id.pid是將管理伺服器用作端口監督程式時所使用的PID檔案。
對於叢集的運行,實際上不需要管理客戶端的程序。其價值在於它提供了一組命令,這組命令可用於檢查叢集的狀態、啟動備份、並執行其他管理功能。管理客戶端使用C API來訪問管理伺服器,高級用戶也能使用C API來編製專用的管理程序來執行任務,這類任務與ndb_mgm執行的類似。
啟動管理客戶端時,需要提供管理伺服器的主機名和端口號,如下例所示。預設值是localhost和1186。
shell> ndb_mgm localhost 1186
關於使用ndb_mgm的更多訊息,請參見17.5.5.4節,「ndb_mgm的命令選項」和17.6.2節,「管理客戶端」中的命令。
所有MySQL叢集的可執行檔案(除mysqld)均使用下述選項。早期MySQL叢集版本的用戶應注意,這些選項開關中的一些與MySQL 4.1叢集中的相比有所改變,為的是保持它們之間的一致性,以及與mysqld的一致性。可以使用-?開關來查看支援的選項列資料表。
· -?, --usage, --help
給出簡明清單,以及可用命令選項的描述。
· -V, --version
給出ndbd程序的版本號。該版本號是MySQL叢集的版本號。版本號有一定的作用,這是因為並非所有的版本均能一起使用,而且在啟動時,MySQL叢集程序將驗證二進制檔案的版本是否能在同一叢集內共存。執行MySQL叢集的線上升級時,它也很重要(請參見MySQL叢集的軟件升級)。
· -c connect_string, --connect-string
connect_string作為命令選項,用於設置與管理伺服器的連接字串。
shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"
· --debug[=options]
該選項僅能用於具有調試功能的版本。使用它,能夠以與mysqld程序相同的方式允許來自調試使用的輸出。
· -e, --execute
使用它,能夠從系統shell將命令發送至叢集執行程式,如:
shell> ndb_mgm -e show
或
shell> ndb_mgm --execute="SHOW"
等效於
NDB> SHOW;
它類似於「-e」選項與mysql命令行客戶端一起工作的方式。請參見4.3.1節,「在命令行上使用選項」。
· --ndbcluster
如果二進製版本包含對NDB叢集儲存引擎的支援,可使用該選項覆蓋對NDB叢集儲存引擎(簡稱為NDB儲存引擎)的預設禁止設置。使用MySQL叢集時,NDB叢集儲存引擎是必要的。
· --skip-ndbcluster
禁止NDB叢集儲存引擎。對於包含該功能的二進製版本,在預設情況下,該功能是被禁止的,換句話講,NDB叢集儲存引擎處於禁止狀態,直至使用「—ndbcluster」選項激活了它為止。僅當所編譯的伺服器支援NDB叢集儲存引擎時,才能使用該選項。
· --ndb-connectstring=connect_string
使用NDB儲存引擎時,通過設置該選項,能夠指定分配叢集配置數據的管理伺服器。
關於某些常見選項的更多訊息,請參見17.5.5節,「用於MySQL叢集程序的命令選項」。
· -d, --daemon
通知ndbd作為daemon(端口監督程式)程序執行(預設行為)。
· --nodaemon
指明ndbd不得作為daemon(端口監督程式)程序啟動。調試ndbd以及希望將輸出重定向到屏幕時,它很有用。
· --initial
通知ndbd執行初始化啟動。初始化啟動將刪除以前ndbd實例為恢復目的建立的任何檔案。它還能重新建立恢復用日誌檔案。注意,在某些作業系統上,該程序可能會佔用較長的時間。
僅在首次啟動ndbd程序時才應使用—initial啟動,這是因為它將刪除叢集檔案系統的所有檔案,並再次建立所有的REDO日誌檔案。該規則的例外如下:
o 執行那些會更改檔案內容的軟件升級時。
o 用新的ndbd版本重啟節點時。
o 出於某種原因,節點重啟或系統重啟不斷失敗時的最後手段。在這類情形下,請注意,由於數據檔案的損壞,不能使用該節點來恢復數據。
該選項不影響那些已被受影響節點建立的備份檔案。
· --nostart
指示ndbd不自動啟動。使用該選項時,ndbd連接到管理伺服器,從管理伺服器獲取配置數據,並初始化通信對象。但是,在管理伺服器特別要求之前,它不會實際啟動執行引擎。通過向管理客戶端發出恰當的命令,可完成該任務。
關於某些常見選項的更多訊息,請參見17.5.5節,「用於MySQL叢集程序的命令選項」。
· -f filename, --config-file=filename, (OBSOLETE): -c filename
通知管理伺服器應使用哪個檔案作為其配置檔案。必須指定該選項。檔案名預設為config.ini。注意,「-c」快捷方式已過時,不應在新的安裝實例中使用它。
· -d, --daemon
指示ndb_mgmd作為端口監督程式啟動。這是預設行為。
· --nodaemon
指示管理伺服器不作為端口監督程式啟動。
關於某些常見選項的更多訊息,請參見17.5.5節,「用於MySQL叢集程序的命令選項」。
· [host_name [port_num]]
要想啟動管理客戶端,需要指定管理伺服器所在的位置,即指定主機名和端口。預設的主機名是localhost,預設端口是1186。
· --try-reconnect=number
如果與管理伺服器的連接中斷,每隔5秒,節點將嘗試再次連接到管理伺服器,直至成功。使用該選項,能夠將嘗試的字數限制在number指定的值,超過該限制後,將放棄嘗試並通報錯誤。
管理MySQL叢集涉及眾多任務,首先是配置和啟動MySQL叢集。詳情請參見17.4節,「MySQL叢集的配置」和17.5節,「MySQL叢集中的程序管理」。
下面介紹了MySQL叢集的管理事宜。
有兩種積極管理MySQL叢集的基本方法。第1種方法是,使用在管理客戶端中輸入的命令,借此可檢查叢集的狀態,更改日誌級別,啟動和停止備份,以及啟動和停止節點。對於第2種方法,需要研究管理伺服器DataDir目錄下叢集日誌檔案ndb_node_id_cluster.log的內容。(node_id代資料表其活動已被記錄的節點的唯一ID)。叢集日誌包含由ndbd生成的事件報告。也能將叢集日誌條目發送到Unix的系統日誌中。
本節介紹了啟動叢集時涉及的步驟。
有數種不同的啟動類型和模式,如下所述:
· 首次啟動:在所有節點上與乾淨的檔案系統一起啟動叢集。這或是出現在首次啟動叢集時,或是使用「--initial」選項重啟叢集時。
· 系統重啟:叢集啟動並讀取保存在數據節點中的數據。這出現在下述情況下:使用完後關閉了叢集,並希望從叢集的停止點恢復叢集操作時。
· 節點重啟:這是在叢集運行的同時叢集節點的線上重啟。
· 首次節點重啟:與節點重啟類似,差別在於將再次初始化節點,並與乾淨的檔案系統一起啟動。
啟動之前,必須對每個節點進行初始化操作(ndbd程序)。這包括下述步驟:
1. 獲取節點ID。
2. 獲取配置數據。
3. 為節點間的通信分配端口。
4. 根據從配置檔案獲得的設置分配內存。
一旦完成了對各節點的初始化操作,將進入叢集啟動程序。在該程序中,叢集將經歷下述階段:
· 階段0
清理叢集檔案系統。僅當使用「--initial」選項啟動叢集時,才會出現。
· 階段1
建立叢集連接,建立節點間的通信。啟動叢集「心跳」機制。
· 階段2
選舉仲裁程式節點。
如果這是系統重啟階段,叢集將確定最近的可恢復全局檢查點。
· 階段3
該階段包括眾多內部叢集變數的初始化。
· 階段4
對於初始啟動或初始節點重啟,將建立redo日誌檔案。這類檔案的數目等於NoOfFragmentLogFiles/
對於系統重啟:
o 讀取方案。
o 從本地檢查點和undo日誌讀取數據。
o 應用所有的redo訊息,直至到達最近的可恢復檢查點為止。
對於節點重啟,找到redo日誌的末尾。
· 階段5
如果這是首次啟動,將建立SYSTAB_0和NDB$EVENTS內部系統資料表。
對於節點重啟或首次節點重啟:
o 節點包含在事務處理操作中。
o 將節點的方案與主伺服器的方案進行比較,並與其同步。
o 對所收到的、來自本節點所在節點組內其他節點的、INSERT形式的數據進行同步。
o 在任何情形下,等待由仲裁程式判定的本地檢查點操作的完成。
· 階段6
更新內部變數。
· 階段7
更新內部變數。
· 階段8
在系統重啟中,重建所有的索引。
· 階段9
更新內部變數。
· 階段10
在節點重啟或首次節點重啟的這一階段,API可能會連接到節點,並接收事件。
· 階段11
在節點重啟或首次節點重啟的這一階段,將事件傳遞任務提交給加入叢集的節點。新加入的節點負責將其主要數據傳遞給訂方。
對於首次啟動或系統重啟,一旦該程序完成,將啟用事務處理功能。對於節點重啟或首次節點重啟,啟動程序的完成意味著節點現在能夠成為事務協調程式。
管理客戶端提供了下述基本命令。在下面給出的清單中,node_id指的是資料庫節點ID或關鍵字ALL,指明命令將應用到所有的叢集數據節點上。
· HELP
顯示關於所有可能命令的訊息。
· SHOW
顯示關於叢集狀態的訊息。
註釋:在使用多個管理節點的叢集中,該命令僅顯示與當前管理伺服器實際相連的數據節點的訊息。
· node_id START
啟動由node_id標識的數據節點(或所有數據節點)。
· node_id STOP
停止由node_id標識的數據節點(或所有數據節點)。
· node_id RESTART [-N] [-I]
重啟由node_id標識的數據節點(或所有數據節點)。
· node_id STATUS
顯示由node_id標識的數據節點(或所有數據節點)的狀態訊息。
· ENTER SINGLE USER MODE node_id
進入單用戶模式,僅允許由節點ID「node_id」標識的MySQL伺服器訪問資料庫。
· EXIT SINGLE USER MODE
退出單用戶模式,允許所有的SQL節點(即所有運行的mysqld程序)訪問資料庫。
· QUIT
中止管理客戶端。
· SHUTDOWN
關閉除SQL節點之外的所有叢集節點,並退出。
在下一節中,介紹了用於事件日誌的命令。在這些議題的單獨一節中,介紹了用於建立備份以及從備份中恢復的命令。
MySQL叢集提供了兩種事件日誌。它們是cluster log和node logs,cluster log(叢集日誌)包括由所有叢集節點生成的事件,node logs(節點日誌)僅記錄每個數據節點的本地事件。
由叢集事件日誌功能生成的輸出可以有多個目的地,包括檔案、管理伺服器控制台窗口、或syslog。由節點事件日誌功能生成的輸出將被寫入數據節點的控制台窗口。
可以對這兩類事件日誌進行設置,使之記錄不同的事件子集。
註釋:叢集日誌是為大多數使用場合推薦的日誌,這是因為它在1個檔案中提供了關於整個叢集的日誌訊息。節點日誌僅應在應用程式的開發過程中使用,或用於調試應用程式代碼。
可根據三種不同的判據識別每個值得通報的事件:
· Category(類別):可以是下述值之一:STARTUP, SHUTDOWN, STATISTICS, CHECKPOINT, NODERESTART, CONNECTION, ERROR,或INFO。
· Priority(優先級):由從1到15的數字資料表示,「1」資料表示「最重要」,「15」資料表示「最不重要」。
· Severity Level(嚴重級別):可以是下述值之一:ALERT, CRITICAL, ERROR, WARNING, INFO, 或DEBUG。
無論是叢集日誌還是節點日誌,都能根據這些屬性進行過濾。
下述管理命令與叢集日誌有關:
· CLUSTERLOG ON
打開叢集日誌。
· CLUSTERLOG OFF
關閉叢集日誌。
· CLUSTERLOG INFO
關於叢集日誌設置的訊息。
· node_id CLUSTERLOG category=threshold
用小於或等於threshold的優先級將category事件記錄到叢集日誌。
· CLUSTERLOG FILTER severity_level
將叢集事件日誌切換為指定的severity_level。
在下資料表中,介紹了叢集日誌類別閾值的預設設置(對於所有數據節點)。如果事件的優先級值低於或等於優先級閾值,就會在叢集日誌中記錄。
注意,事件是按數據節點通報的,可在不同的節點上設置不同的閾值。
類別 |
預設閾值(所有數據節點) |
STARTUP |
7 |
SHUTDOWN |
7 |
STATISTICS |
7 |
CHECKPOINT |
7 |
NODERESTART |
7 |
CONNECTION |
7 |
ERROR |
15 |
INFO |
7 |
閾值用於過濾每種類別中的事件。例如,對於優先級為3的STARTUP事件,不會將其記錄到日誌中,除非將STARTUP的閾值更改為3或更小。如果閾值為3,僅發送優先級等於或小於3的事件。
下面給出了事件的嚴重級別(註釋:它們與Unix的syslog級別對應;但LOG_EMERG和LOG_NOTICE除外,未使用或未映射它們):
1 |
ALERT |
應立刻更正的狀況,如損壞的系統資料庫。 |
2 |
CRITICAL |
臨界狀況,如設備錯誤或資源不足。 |
3 |
ERROR |
應予以更正的狀況,如配置錯誤等。 |
4 |
WARNING |
不能稱其為錯誤的狀況,但仍需要特別處理。 |
5 |
INFO |
通報性消息。 |
6 |
DEBUG |
調試消息,用於NDB叢集開發。 |
可以打開或關閉事件嚴重級別。如果打開了事件嚴重級別,那麼優先級等於或低於類別閾值的事件均將被記錄。如果關閉了事件嚴重級別,那麼將不記錄屬於該嚴重級別的任何事件。
事件日誌中記錄的事件報告採用下述格式:datetime [string] severity – message。例如:
09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed
本節討論了所有值得通報的事件,按類別以及每一類別中的嚴重級別排序。
CONNECTION事件
這類事件與叢集節點之間的連接有關。
事件 |
優先級 |
嚴重級別 |
描述 |
DB節點已連接 |
8 |
INFO |
數據節點已連接 |
DB節點中斷連接 |
8 |
INFO |
數據節點中斷連接 |
通信關閉 |
8 |
INFO |
SQL節點或數據節點的連接已關閉 |
通信打開 |
8 |
INFO |
SQL節點或數據節點的連接已打開 |
CHECKPOINT事件
下面給出的日誌消息與檢查點有關。
(註釋:GCP =全局檢查點,LCP =本地檢查點)。
事件 |
優先級 |
嚴重級別 |
描述 |
在calc keep GCI中,LCP已停止 |
0 |
ALERT |
LCP已停止 |
本地檢查點片段完成 |
11 |
INFO |
片段上的LCP已完成 |
全局檢查點完成 |
10 |
INFO |
GCP完成 |
全局檢查點啟動 |
9 |
INFO |
啟動GCP:將REDO日誌寫入磁盤 |
本地檢查點完成 |
8 |
INFO |
LCP已正常完成 |
本地檢查點啟動 |
7 |
INFO |
啟動LCP:將數據寫入磁盤 |
報告undo日誌已封閉 |
7 |
INFO |
UNDO日誌已封閉:緩衝快要溢出 |
STARTUP事件
下述事件是在成功或失敗的節點啟動或叢集啟動時生成的。它們還提供了與啟動程序進展狀況有關的訊息,包括與日誌活動有關的訊息。
事件 |
優先級 |
嚴重級別 |
描述 |
收到內部啟動信號STTORRY |
15 |
INFO |
重啟完成後收到的訊息塊 |
Undo記錄已執行 |
15 |
INFO |
|
新的REDO日誌已啟動 |
10 |
INFO |
GCI保持X,最新的可恢復GCI Y |
新日誌已啟動 |
10 |
INFO |
日誌部分X,啟動MB Y,停止MB Z |
拒絕將節點納入叢集中 |
8 |
INFO |
由於配置錯誤、無法建立通信、或其他問題,不能將節點包含在叢集中。 |
DB節點鄰居 |
8 |
INFO |
顯示附近的數據節點。 |
DB節點啟動階段X完成 |
4 |
INFO |
數據節點啟動階段已完成。 |
節點已被叢集成功接納 |
3 |
INFO |
顯示節點,管理節點,以及動態ID。 |
DB節點啟動階段已開始 |
1 |
INFO |
NDB叢集節點正在啟動。 |
DB節點的所有啟動階段已完成 |
1 |
INFO |
NDB叢集節點已啟動。 |
DB節點關閉操作已啟動 |
1 |
INFO |
數據節點的關閉操作已開始 |
DB節點關閉操作失敗 |
1 |
INFO |
無法正常關閉數據節點。 |
NODERESTART事件
下述事件是在重啟節點時產生的,並與節點重啟程序的成功或失敗相關。
事件 |
優先級 |
嚴重級別 |
描述 |
節點失敗階段完成 |
8 |
ALERT |
通報節點失敗階段的完成 |
節點失敗,節點狀態為X |
8 |
ALERT |
通報節點已失敗 |
通報仲裁程式結果 |
2 |
ALERT |
對於仲裁嘗試,有8種不同的可能結果: · 仲裁檢查失敗,剩餘節點少於1/2。 · 仲裁檢查成功,節點組多數 · 仲裁檢查失敗,丟失節點組 · 網絡分區,要求仲裁 · 仲裁成功,來自節點X的正面回應 · 仲裁失敗,來自節點X的負面回應 · 網絡分區,無可用的仲裁程式 · 網絡分區,未配置仲裁程式 |
完成了片段複製 |
10 |
INFO |
|
完成了目錄訊息複製 |
8 |
INFO |
|
完成了分配訊息複製 |
8 |
INFO |
|
開始複製片段 |
8 |
INFO |
|
完成了所有片段的複製 |
8 |
INFO |
|
GCP接收已啟動 |
7 |
INFO |
|
GCP接收已完成 |
7 |
INFO |
|
LCP接收已啟動 |
7 |
INFO |
|
LCP接收已完成(狀態= X) |
7 |
INFO |
|
通報是否發現了仲裁程式 |
6 |
INFO |
搜索仲裁程式時,有7種可能的結果: · 管理伺服器重啟仲裁線程[state=X] · 準備仲裁程式節點X [ticket=Y] · 接收仲裁程式節點X [ticket=Y] · 啟動仲裁程式節點X [ticket=Y] · 丟失了仲裁程式節點X – 程序失敗 [state=Y] · 丟失了仲裁程式節點X – 程序退出 [state=Y] · 丟失了仲裁程式節點X <error msg> [state=Y] |
STATISTICS事件
下述事件具有統計特性。它們提供了相應的訊息,如事務和其他操作的數目,低濃度節點發送或接收的數據量,以及內存使用率等。
事件 |
優先級 |
嚴重級別 |
描述 |
通報作業日程統計 |
9 |
INFO |
平均的內部作業日程統計 |
發送的字節數 |
9 |
INFO |
發送至節點X的平均字節數 |
接收的自己# |
9 |
INFO |
從節點X接收的平均字節數 |
通報事務統計 |
8 |
INFO |
事務數目,提交次數,讀取次數,簡單讀取次數,寫入次數,並發操作數目。屬性訊息,以及放棄次數 |
通報操作 |
8 |
INFO |
操作數目 |
通報資料表建立 |
7 |
INFO |
|
內存使用 |
5 |
INFO |
數據內存和索引內存的使用率(80%、90%和100%) |
ERROR事件
這些事件與叢集錯誤和告警有關,如果出現1個或多個這類事件,表明出現了重大故障或失敗。
事件 |
優先級 |
嚴重級別 |
描述 |
因失去心跳而死亡 |
8 |
ALERT |
因失去心跳而聲明節點X死亡。 |
傳輸器錯誤 |
2 |
ERROR |
|
傳輸器告警 |
8 |
WARNING |
|
失去心跳 |
8 |
WARNING |
節點X失去心跳#Y |
一般性告警事件 |
2 |
WARNING |
|
INFO事件
這些事件給出了關於叢集狀態和叢集維護活動的一般訊息,如日誌和心跳傳輸等。
事件 |
優先級 |
嚴重級別 |
描述 |
發出心跳 |
12 |
INFO |
將心跳發送至節點X |
建立日誌字節 |
11 |
INFO |
日誌部分,日誌檔案,MB |
一般訊息事件 |
2 |
INFO |
|
採用單用戶模式,資料庫管理員能夠將對資料庫系統的訪問限制在1個MySQL伺服器(SQL節點)。進入單用戶模式時,與所有其他MySQL伺服器的所有連接均將恰當關閉,而且所有正在運行的事務均將被放棄。不允許啟動任何新事務。
一旦叢集進入單用戶模式,只有指定的SQL節點才有權訪問資料庫。使用ALL STATUS命令,可查看叢集進入單用戶模式的時間。
示範:
NDB> ENTER SINGLE USER MODE 5
執行該命令而且叢集進入單用戶模式後,節點ID為5的SQL節點將成為叢集中唯一允許的用戶。
上述命令中指定的節點必須是MySQL伺服器節點,如果指定任何其他類型的節點,將被拒絕。
註釋:執行上述命令時,指定節點上所有正在運行的事務均將被放棄,連接關閉,而且必須重啟伺服器。
使用EXIT SINGLE USER MODE命令,能夠將叢集數據節點的狀態從單用戶模式更改為正常模式。對於等待連接的MySQL伺服器(即,對於即將準備就緒並可用的叢集),現在允許進行連接。在狀態變化期間和變化之後,指定為單用戶SQL節點的MySQL伺服器將繼續運行(如果仍連接的話)。
示範:
NDB> EXIT SINGLE USER MODE
運行在單用戶模式下時,如果節點失敗,推薦的處理方法是:
1. 結束所有的單用戶模式事務。
2. 發出EXIT SINGLE USER MODE命令。
3. 重啟叢集的數據節點。
或
· 進入單用戶模式之前重啟資料庫。
· Metadata(元數據):所有資料庫資料表的名稱和定義。
· Table records(資料表記錄):執行備份時實際保存在資料庫資料表中的數據。
· Transaction log(事務日誌):指明如何以及何時將數據保存在資料庫中的連續記錄。
每一部分均會保存在參與備份的所有節點上。在備份過程中 ,每個節點均會將這三個部分保存在磁盤上的三個檔案中:
· BACKUP-backup_id.node_id.ctl
包含控制訊息和元數據的控制檔案。每個節點均會將相同的資料表定義(對於叢集中的所有資料表)保存在自己的該檔案中。
· BACKUP-backup_id-0.node_id.data
包含資料表記錄的數據檔案,它是按片段保存的,也就是說,在備份過程中,不同的節點會保存不同的片段。每個節點保存的檔案以指明了記錄所屬資料表的標題開始。在記錄清單後面有一個包含關於所有記錄校驗和的腳注。
· BACKUP-backup_id.node_id.log
包含已提交事務的記錄的日誌檔案。在日誌中,僅保存已在備份中保存的資料表上的事務。參與備份的節點將保存不同的記錄,這是因為,不同的節點容納了不同的資料庫片段。
在上面所列的內容中,backup_id指的是備份ID,node_id是建立檔案的節點的唯一ID。
開始備份前,請確保已為備份操作恰當地配置了叢集。(請參見17.6.5.4節,「叢集備份的配置」)。
使用管理伺服器建立備份包含以下步驟:
1. 啟動管理伺服器(ndb_mgm)。
2. 執行命令START BACKUP。
3. 管理伺服器將用消息「指示備份開始」作出應答。這意味著管理伺服器將請求提交給了叢集,但尚未收到任何回應。
4. 管理伺服器回復「備份backup_id開始」,其中,backup_id是該備份的唯一ID(如果未作其他配置,該ID還將保存在叢集日誌中)。這意味著叢集已收到並開始處理備份請求。它不資料表示備份已完成。
5. 管理伺服器發出消息「備份backup_id完成」,通知備份操作已結束。
要想放棄正在處理的備份:
1. 啟動管理伺服器。
2. 執行命令ABORT BACKUP backup_id。backup_id是當備份開始時包含在管理伺服器應大中的備份ID(在消息「備份backup_id啟動」中)。
3. 管理伺服器用消息「放棄指示的備份backup_id」確認放棄請求,注意,尚未收到對該請求的實際回應。
4. 一旦放棄了備份,管理伺服器將通報「備份backup_id因XYZ而放棄」。這意味著叢集中止了備份,並從叢集檔案系統中刪除了與該備份有關的所有檔案。
在系統shell中使用下述命令,也能放棄正在執行的備份:
shell> ndb_mgm -e "ABORT BACKUP backup_id"
註釋:執行放棄操作時,如果沒有ID為backup_id的備份,管理伺服器不會給出任何明確回應。但是,所發出的無效放棄命令將在叢集日誌中給出。
叢集恢復程式是作為單獨的命令行實用工具ndb_restore實現的,它將讀取由備份建立的檔案,並將保存的訊息插入資料庫。必須為每組備份檔案執行恢復程式,也就是說,執行次數與建立備份時運行的資料庫節點數相同。
首次執行恢復程式時,還需要恢復元數據。換句話講,必須重新建立資料庫資料表(注意,開始執行恢復操作時,叢集中應有一個空資料庫)。恢復程式對於叢集來說相當於API,因此,需要一個空閒連接,以便與叢集相連。可使用ndb_mgm命令SHOW(在系統shell下使用ndb_mgm
-e SHOW即可完成該操作)進行驗證。可以使用開關「-c
connectstring」來確定MGM節點的位置。(關於連接字串的更多訊息,請參見17.4.4.2節,「MySQL叢集連接字串」。備份檔案必須位於恢復程式參量給定的目錄下。
能夠使用與建立是所用配置不同的配置將備份恢復到資料庫。例如,對於備份ID為12的備份,該備份是在具有兩個資料庫節點(節點ID無惡2和3)的叢集中建立的,可以將其恢復到具有4個節點的叢集中。這樣,ndb_restore必須運行兩次,為建立備份時的每個資料庫節點運行一次。
註釋:對於快速恢復,能夠以並行方式恢復數據,但必須有足夠的可用叢集連接。然而,數據檔案必須始終前於日誌檔案。
有4個用於備份的基本配置參數:
· BackupDataBufferSize
將數據寫入磁盤之前用於對數據進行緩衝處理的內存量。
· BackupLogBufferSize
將日誌記錄寫入磁盤之前用於對其進行緩衝處理的內存量。
· BackupMemory
在資料庫節點中為備份分配的總內存。它應是分配給備份數據緩衝的內存和分配給備份日誌緩衝的內存之和。
· BackupWriteSize
寫入磁盤的塊大小。它適用於備份數據緩衝和備份日誌緩衝
關於這些參數的更多細節,請參見17.4節,「MySQL叢集的配置」。
即使在1996年開始NDB叢集的設計之前,在建立並行資料庫的過程中遇到的一個主要問題顯然是網絡中節點之間的通信問題。正因為如此,從開始設計時,NDB叢集就允許使用多種不同的數據傳輸機制。在本手冊中,我們使用了術語傳輸器。
目前,MySQL叢集代碼庫包含對四種不同傳輸器的支援。目前的大多數用戶採用的是以太網上的TCP/IP,這是因為它無處不在。它也是迄今為止在MySQL叢集中經過最佳測試的傳輸器。
我們正在努力,以確保與ndbd程序的通信是盡可能大的「組塊」,這是因為,它有利於所有的數據傳輸類型。
對於需要它的用戶,也能使用叢集互聯以進一步增強性能。實現它的方式有兩種:或使用能處理該情況的定制傳輸器,或使用能繞過TCP/IP堆棧的套接字實施方案。我們使用由Dolphin開發的SCI(規模可延伸的計算機連接接口)技術,對這兩類技術進行了試驗。
在本節中,我們將介紹如何改編為常規TCP/IP通信配置的叢集,以使用SCI套接字。本文檔基於2004年10月1日發佈的SCI套接字2.3.0版。
前提條件
對於任何打算使用SCI套接字的機器,都必須配備SCI卡。
能夠與任何版本的MySQL叢集一起使用SCI套接字。不需要特殊建立,這是因為它採用了MySQL叢集中已提供的正常套接字使用。但是,目前僅在Linux 2.4和2.6內核上才支援SCI套接字。儘管到目前為止我們僅在Linux 2.4上核實了這點,在一些其他作業系統上也成功測試了SCI傳輸器。
對於SCI套接字,有四種基本要求:
1. 建立SCI套接字庫。
2. 安裝SCI套接字內核庫。
3. 安裝1個或2個配置檔案。
4. 必須為整個機器或啟動MySQL叢集程序的shell啟用SCI套接字庫。
對於打算將SCI套接字用於節點間的通信的叢集,需要為叢集中的每台機器重複該程序。
要想使SCI套接字工作,需要獲得兩個軟件包:
1. 包含用於SCI套接字庫的DIS支援庫的原始碼軟件包。
2. 用於SCI套接字庫本身的原始碼軟件包。
目前,僅以原始碼格式提供了它們。編寫本文檔時可用的最新版本的軟件包分別是DIS_GPL_2_5_0_SEP_10_2004.tar.gz和SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz。在下述站點,可找到它們(也可能找到更新的版本):http://www.dolphinics.no/support/downloads.html。
軟件包安裝
獲得庫軟件包後,接下來應將它們解包到恰當的目錄下,將SCI套接字庫解包到DIS代碼下的目錄中。然後,需要建立庫。在下面的示範中,給出了在Linux/x86平台上執行該任務所需的命令:
shell> tar xzf DIS_GPL_2_5_0_SEP_10_2004.tar.gz
shell> cd DIS_GPL_2_5_0_SEP_10_2004/src/
shell> tar xzf ../../SCI_SOCKET_2_3_0_OKT_01_2004.tar.gz
shell> cd ../adm/bin/Linux_pkgs
shell> ./make_PSB_66_release
能夠為64位處理器建立這些庫。要想為使用64位延伸的Opteron CPU建立這些庫,請運行make_PSB_66_X86_64_release而不是make_PSB_66_release。如果建立工作是在Itanium機器上進行的,應使用make_PSB_66_IA64_release。X86-64變體應能與Intel EM64T體系結構一起工作,但這點尚未測試(就我們所知)。
完成建立程序後,在zipped tar檔案中可發現已編譯好的庫,檔案的名稱符合DIS-<operating-system>-time-date。現在,可將軟件包安裝到恰當位置。在本例中,我們使用的安裝目錄是/opt/DIS(註釋:您很可能需要以系統根用戶的身份運行下述命令):
shell> cp DIS_Linux_2.4.20-8_181004.tar.gz /opt/
shell> cd /opt
shell> tar xzf DIS_Linux_2.4.20-8_181004.tar.gz
shell> mv DIS_Linux_2.4.20-8_181004 DIS
網絡配置
至此,所有的庫和二進制檔案均已安裝到了恰當的位置,還需確保SCI卡在SCI的地址空間範圍內擁有恰當的節點ID。
進行後面的操作前,還需確定網絡結構。對於該情形,有三種可使用的網絡結構:
· 一維單環網絡。
· 1個或多個SCI交換器,每個交換器端口有1個環形網。
· 2維或3維環面網。
每類拓撲結構均有自己的、用於提供節點ID的方法。下面給出了簡要討論。
單環網採用的節點ID是4的非0倍數,4,8,12…。
下一個可行的選擇是SCI交換器。1個SCI交換器有8個端口,每個端口都能支援1個環形網。有必要確保不同的環形網使用了不同的節點ID空間。對於典型的配置,第1個端口使用的節點ID低於64(4~60),接下來的64個節點ID(68~124)指定給下一個端口,依此類推,節點ID 452~508將被指定給第8個端口。
對於2維或3維環面網結構,每個節點位於各維中,在第1維中,各節點的增量為4,在第2維中,增量為64,在第3維中(如果適用的話),增量為1024。關於更詳盡的文檔,請參見Dolphin的網站。
在我們的測試中,採用了交換器方式,但大多數大型叢集安裝應用使用的是2維或3維環面網結構。採用交換器方式具有的優點是:使用雙SCI卡和雙交換器,能夠相對容易地建立冗余網絡,SCI網絡上的平均故障切換時間在100毫秒量級。對於SCI套接字實施,MySQl叢集中的SCI傳輸器支援該結構,而且它也處於發展當中。
對於2D/3D環面網,故障切換也是可能的,但需要向所有節點發送發出新的路由索引。然而,這僅需要100毫秒左右就能完成,對於大多數高可用性情形,這是可接受的。
通過將叢集數據節點恰當地置於交換式體系結構中,能夠使用2個交換器來構建結構,將16台計算機互聯在一起,任何單點故障均不會妨礙1台以上的計算機。對於32台計算機和2台交換器,也能以這樣的方式配置叢集,任何單點故障均不會導致2個以上的節點丟失,在此情況下,也能知道那一對節點收到影響。因此,通過將兩個節點置於不同的節點組,就能建立「安全的」MySQL叢集。
要想為SCI卡設置節點ID,可使用/opt/DIS/sbin目錄中的下述命令。在本例中,「-c 1」指的是SCI卡的編號(如果在機器上只有1塊卡,它總為1),「-a 0」指的是適配器0,「68」是節點ID:
shell> ./sciconfig -c 1 -a 0 -n 68
如果在同一台機器上有多塊SCI卡,使用下述命令(假定當前的工作目錄是/opt/DIS/sbin),可確定哪塊卡使用哪個插槽:
shell> ./sciconfig -c 1 -gsn
它將給出SCI卡的序列號。然後用「-c 2」重複該步驟,依此類推(對機器上的每塊卡)。一旦將每塊卡與1個插槽匹配後,可為所有卡設置節點ID。
安裝了必要的庫和二進制檔案,並設置了SCI節點ID後,下一步是設置從主機名(或IP地址)到SCI節點ID的映射。該任務可在SCI套接字配置檔案中完成,該檔案應被保存為/etc/sci/scisock.conf。在該檔案中,通過恰當的SCI卡將SCI節點映射到與之通信的主機名或IP地址。這裡給出了一個很簡單的配置檔案示範:
#host #nodeId
alpha 8
beta 12
192.168.10.20 16
也能對配置進行限制,使其僅應用在這些主機的可用端口子集上。也能使用額外的配置檔案/etc/sci/scisock_opt.conf完成該設置,如下所示:
#-key -type -values
EnablePortsByDefault yes
EnablePort tcp 2200
DisablePort tcp 2201
EnablePortRange tcp 2202 2219
DisablePortRange tcp 2220 2231
驅動程式安裝
建立好了配置檔案後,可安裝驅動程式。
首先應安裝底層驅動,然後安裝SCI套接字驅動:
shell> cd DIS/sbin/
shell> ./drv-install add PSB66
shell> ./scisocket-install add
如果願意,可使用指令來核實SCI套接字配置檔案中的所有節點是否均能訪問,通過該方式檢查安裝:
shell> cd /opt/DIS/sbin/
shell> ./status.sh
如果發現錯誤並需要更改SCI套接字配置,需要使用ksocketconfig來完成該任務:
shell> cd /opt/DIS/util
shell> ./ksocketconfig -f
測試設置
為了確保SCI套接字已實際使用,可使用latency_bench測試程式。使用該實用工具的伺服器組件,客戶端能夠連接伺服器以測試連接的等待時間,通過觀察等待時間,可方便地判定是否啟用了SCI。(註釋:使用latency_bench之前,需要設置環境變數LD_PRELOAD,請參見本節後面的介紹)。
要想設置伺服器,可使用下述命令:
shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -server
要想運行客戶端,再次使用latency_bench,但此時採用「-client」選項:
shell> cd /opt/DIS/bin/socket
shell> ./latency_bench -client server_hostname
到目前為止,應完成了SCI套接字配置,而且MySQL叢集已做好了使用SCI套接字和SCI傳輸器的準備(請參見17.4.4.10節,「MySQL叢集SCI傳輸連接」)。
啟動叢集
該程序接下來的步驟是啟動MySQL叢集。要想啟用SCI套接字,在啟動ndbd、mysqld和ndb_mgmd之前,需要設置環境變數LD_PRELOAD。該變數應指向用於SCI套接字的內核庫。
要想在bash shell下啟動ndbd,可執行下述命令:
bash-shell> export LD_PRELOAD=/opt/DIS/lib/libkscisock.so
bash-shell> ndbd
在tcsh環境下,可使用下述命令完成相同的任務:
tcsh-shell> setenv LD_PRELOAD=/opt/DIS/lib/libkscisock.so
tcsh-shell> ndbd
註釋:MySQL叢集可以僅使用SCI套接字的內核變體。
有四種訪問方法:
· 主鍵訪問
通過其主鍵簡單地訪問記錄。在最簡單的情況下,一次僅訪問一條記錄,這意味著該單一請求需負擔設置眾多TCP/IP消息的全部開銷以及眾多的場景切換開銷。對於在一批中發出多個主鍵訪問請求的情況,這些訪問請求將分擔設置必要TCP/IP消息和場景切換的開銷。如果TCP/IP消息是面向不同目標的,還須設置額外的TCP/IP消息。
· 唯一鍵訪問
唯一鍵訪問與主鍵訪問類似,差別在於,唯一鍵訪問是作為在索引資料表上的讀取操作執行的,然後是作用在資料表上的主鍵訪問。但是,MySQL伺服器僅發送一條請求,而且對索引資料表的讀取是由ndbd負責處理的。這類請求也受益於批處理法。
· 全資料表掃瞄
對於資料表查詢,當不存在索引時,將執行全資料表掃瞄。這將作為單一請求被發送至ndbd程序,該程序隨後將資料表掃瞄分為在所有叢集ndbd程序上進行的一組並行掃瞄。在未來的MySQL叢集版本中,SQL節點能夠過濾某些掃瞄。
· 使用有序索引的範圍掃瞄
使用有序索引時,它將使用與全資料表掃瞄相同的方式執行掃瞄,不同之處在於,它僅掃瞄位於MySQL伺服器(SQL節點)所傳輸查詢使用的範圍內的記錄。當所有綁定的索引屬性包含分區 鍵中的所有屬性時,將以並行方式掃瞄所有分區。
為了檢查這些訪問方法的基本性能,我們開發了一組基準。作為這類基準之一,testReadPerf能夠測試簡單的和批處理式主鍵和唯一鍵訪問。通過發出返回單一記錄的掃瞄請求,該基準還能測量範圍掃瞄的設置開銷。此外,還有1個該基準的變體,它採用了範圍掃瞄來獲取批量記錄。
這樣,我們就能確定單鍵訪問的開銷,以及單記錄掃瞄訪問的開銷,並能根據基本訪問方法測量通信媒介的影響。
在我們進行的測試中,為採用TCP/IP套接字的正常傳輸器和使用SCI套接字的類似設置進行了基本設置。下面給出的數字是關於少量訪問的,每次訪問20條記錄。使用2KB的記錄時,串行訪問和批式訪問之間的差異將降低3~4倍。對於2KB的記錄,未測試SCI套接字。測試是在下述叢集上進行的,該叢集有兩個數據節點,這兩個數據節點運行在2台雙CPU機器上,處理器為AMD MP1900+。
Access type: TCP/IP sockets SCI Socket
Serial pk access: 400 microseconds 160 microseconds
Batched pk access: 28 microseconds 22 microseconds
Serial uk access: 500 microseconds 250 microseconds
Batched uk access: 70 microseconds 36 microseconds
Indexed eq-bound: 1250 microseconds 750 microseconds
Index range: 24 microseconds 12 microseconds
我們還執行了另一組測試,以檢查SCI套接字的性能以及SCI傳輸器的性能,並將這兩者與TCP/IP傳輸器的性能進行了比較。所有測試均採用了主鍵訪問方法,或採用串行多線程方式,或採用多線程批方式。
測試結果表明,SCI套接字比TCP/IP約快100%。與SCI套接字相比,在大多數情況下,SCI傳輸器的速度更快。在具有很多線程的測試程式中出現了1個值得關注的情況,它表明,與mysqld程序一起使用時,SCI傳輸器的執行性能並不很好。
我們得出的總體結論是,對於大多數基準,與TCP/IP相比,除了罕見的通信性能不成其為關注事宜的情況外,使用SCI套接字能將性能提升約100%。當掃瞄過濾器佔用大多數處理時間,或當執行大量的主鍵訪問,就會出現該情況。在這類情況下,ndbd程序中的CPU處理操作將佔用開銷的相當大部分。
對於使用SCI傳輸器來取代SCI套接字,它僅對ndbd程序之間的通信有意義。如果CPU能專門用於ndbd程序,使用SCI傳輸器也也很有意義,這是因為SCI傳輸器能確保該程序永不休息。另一個重要特性是,它能確保對ndbd程序的優先級進行特定的設置,即使運行了很長的時間,其優先級也不會喪失,就像在Linux 2.6中通過將程序鎖定到CPU而能實現的那樣。如果這類配置是可能的,與使用SCI套接字相比,ndbd程序將獲得10~70%的性能提升(執行更新以及可能的並行掃瞄操作時,性能提升較大)。。
對於計算機叢集,還有數種其他的最佳化套接字實施方案,包括Myrinet、吉比特以太網、Infiniband(無限帶寬)和VIA接口。迄今為止,我們僅與SCI套接字一起測試了MySQL叢集。我們還提供了上述文檔,其中,介紹了如何使用針對MySQL叢集的常規TCP/IP來設置SCI套接字的方法。
在本節中,我們列出了5.1.x系列中對MySQL叢集的一些已知限制,並與使用MyISAM和InnoDB儲存引擎時可用的特性進行了比較。目前,尚不打算在即將推出的MySQL 5.1版本中處理這些問題,但是,我們將在後續的版本系列中,提供這方面的補丁和修正。如果您檢查了MySQL問題資料庫(http://bugs.mysql.com)中的「叢集」類別,可發現我們打算在即將推出的MyAQL 5.1版中更正的已知問題(如果標記為「5.1」的話)。
(註釋:在本節末尾,列出了在當前版本中已解決的MySQL 5.0叢集中的一些事宜)。
· 語法中的不相容性(運行已有的應用程式時導致錯誤):
o 不支援文本索引。
o 不支援Geometry數據類型(WKT和WKB)。
· 限制或行為中的不相容性(運行已有的應用程式時可能導致錯誤):
o 沒有事務的部分回滾功能。重複鍵或類似錯誤會導致整個事務的回滾。
o 存在很多可配置的硬限制,但能使用叢集中的可用主內存設置限制。關於配置參數的完整清單,請參見17.4.4節,「配置檔案」。大多數配置參數可線上升級。這些硬限制包括:
§ 資料庫內存大小和索引內存大小(分別是DataMemory和IndexMemory)。
§ 對於能夠執行的最大事務數,可使用配置參數MaxNoOfConcurrentOperations進行設置。注意批量加載,TRUNCATE TABLE和ALTER TABLE是通過運行多個事務作為特殊情況進行處理的,因而不受該限制的約束。
§ 與資料表和索引有關的不同限制。例如,每資料表的最大有序索引數是由MaxNoOfOrderedIndexes確定的。
o 在NDB資料表中,資料庫名稱、資料表名稱和屬性名稱不能與其他資料表處理程式中的一樣長。屬性名稱將被截短至31個字元,截短後如果不是唯一的,將導致錯誤。資料庫名稱和資料表名的總最大長度為122個字元(也就是說,NDB叢集資料表名的最大長度為122個字元減去該資料表所屬的資料庫的名稱中的字元數)。
o 所有的叢集資料表行具有固定長度。這意味著(例如),如果資料表中有僅包含相對較小值的1個或多個VARCHAR字段,與使用MyISAM引擎的相同資料表和數據相比,使用NDB儲存引擎時需要更多的內存和磁盤空間。換句話講,對於VARCHAR列,它所需的儲存空間與具有相同大小的CHAR列所需的相同。
o 叢集資料庫中的最大資料表數目限制為1792。
o 每資料表的最大屬性數限制為128。
o 任一行的最大允許大小為8K,不包括保存在BLOB列中的數據。
o 每鍵的最大屬性數為32。
· 不支援的特性(不會導致錯誤,但不被支援或強制):
o 外部鍵結構將被忽略,就像在MyISAM資料表中那樣。
o 保存點以及對保存點的回滾將被忽略,就像在MyISAM中那樣。
· 性能以及與限制有關的事宜
o 由於對NDB儲存引擎的連續訪問,存在查詢性能問題,與MyISAM或InnoDB的情形相比,執行很多範圍掃瞄時,開銷相對昂貴。
o 不支援範圍統計中的記錄,在某些情況下,這會造成非最優查詢計劃。可採用USE INDEX或FORCE INDEX規避該問題。
o 對於使用USING HASH建立的唯一性哈希索引,如果NULL是鍵的一部分,不能使用這類索引訪問資料表。
o MySQL叢集不支援磁盤上的持續提交。提交將被複製,但不保證在提交時會將日誌寫入磁盤。
· 丟失特性:
o 唯一支援的隔離級別是READ_COMMITTED(InnoDB支援READ_COMMITTED、READ_COMMITTED、REPEATABLE_READ和SERIALIZABLE)。關於其如何影響叢集資料庫備份和恢復的更多訊息,請參見17.6.5.5節,「備份故障診斷與排除」。
o 不支援磁盤上的持續提交。提交將被複製,但不保證在提交時會將日誌寫入磁盤。
· 與多MySQL伺服器有關的問題(與MyISAM或InnoDB無關):
o 運行多個MySQL伺服器時,ALTER TABLE未完全鎖定(無分佈式資料表鎖定)。
o 如果在多個MySQL伺服器上進行了更新,MySQL複製功能不能正確處理。但是,如果資料庫分區方案是在應用級別上完成的,而且在這些分區上非發生事務,那麼可使複製功能正確工作。
o 對於訪問相同MySQL叢集的多MySQL伺服器,不支援資料庫的自動發現(autodiscovery)功能。但是,在情況下,支援對資料表的自動發現(autodiscovery)功能。這意味著,建立了名為db_name的資料庫後,或使用1個MySQL伺服器導入了該資料庫後,應在訪問相同MySQL叢集的每個額外MySQL伺服器上發出CREATE DATABASE db_name語句(從MySQL 5.0.2開始,您還能使用CREATE SCHEMA db_name;)。一旦對給定MySQL伺服器完成了該操作,伺服器應能檢測到資料庫資料表,而不產生錯誤。
· 僅與MySQL叢集有關的事宜(與MyISAM或InnoDB無關):
o 叢集中使用的所有機器必須具有相同的體系結構,也就是說,所有承載節點的機器必須是big-endian或little-endian,不能混合使用這兩者。例如,不能用運行在PPC上的管理節點指揮運行在x86機器上的數據節點。該限制不適用於簡單運行mysql或其他客戶端(可能會訪問叢集的SQL節點)的機器。
o 不能像使用ALTER TABLE或CREATE INDEX完成的那樣執行線上方案更改,這是因為NDB叢集不支援這類變更的自動檢測(但是,能夠導入或建立使用不同儲存引擎的資料表,然後使用「ALTER TABLE tbl_name ENGINE=NDBCLUSTER;」將其轉換為NDB。在這類情況下,需要發出FLUSH TABLES命令,強制叢集發現變化)。
o 不能線上增加或捨棄節點(此時必須重啟叢集)。
o 使用多個管理伺服器時:
§ 必須在連接字串中明確為節點指定ID,這是因為,在多個管理伺服器上,自動分配的節點ID不能正常工作。
§ 必須十分小心,確保所有的管理伺服器具有相同的配置。叢集對此方面不進行任何特殊檢查,
§ 要想使管理節點能發現彼此的存在,建立了叢集後必須重啟所有的數據節點(詳細解釋請參見Bug #13070)。
o 不支援用於數據節點的多個網絡接口。如果使用了這類接口,很容易導致問題,原因在於,在出現某一數據節點失敗的情況下,SQL節點將等待以確認該數據節點是否出現問題,但由於該數據節點的另一路徑仍保持打開狀態,SQL節點永遠不會收到該確認訊息。這會導致叢集無法工作。
o 數據節點的最大數目為48。
o MySQL叢集中總的最大節點數為63。在該數值中包括所有的MySQL伺服器(SQL節點),數據節點和管理伺服器。
考慮到本節開始時設定的條件,我們力圖使上面列出的訊息盡可能完全。您可以將任何遇到的差異通報到MySQL問題資料庫,http://bugs.mysql.com/。如果我們不打算在MySQL 5.1中更正該問題,我們會將其新增到列資料表中。
在本節,我們討論了MySQL 5.1在MySQL叢集實施中的一些變化,並與MySQL 5.0進行了比較。我們還將討論對MySQL叢集的進一步重大改進,目前是為MySQL 5.2規劃的。
在MySQL 5.0和5.1中,NDB叢集儲存引擎實施方案之間的變化相對較少,因此其升級相對快捷和簡單。
為MySQL叢集開發的主要新特性均歸入了MySQL 5.1樹。在本節中,我們還提供了一些提示,介紹了在MySQL 5.1中叢集特性可能包含的方面(請參見17.9.2節,「關於MySQL叢集的MySQL 5.1發展歷程」)。
MySQL 5.0.3-beta以及更新的版本包含一些有趣的新特性:
· 下推條件:一種查詢,如:
· SELECT * FROM t1 WHERE non_indexed_attribute = 1;
它將使用全資料表掃瞄,並會在叢集的數據節點內評估條件。因此,不需要在網絡中發送用於評估的記錄(也就是說,採用函數傳輸而不是數據傳輸)。對於這種查詢類型,其速度快5~10倍。請注意,模目前該特性是預設禁止的(有待更徹底的測試),但在某些情況下也能良好工作。使用命令「SET engine-condition-pushdown=On; command」可啟用該特性。作為可選方式,您也可以用新的「--engine-condition-pushdown」選項標誌啟動MySQL伺服器,運行啟用了該特性的mysqld。
可以使用EXPLAIN來判定在何時使用了下推條件。
該變化的一項主要優點在於,能夠以並行方式執行查詢。這意味著,與以往相比,對非索引列的查詢要快5~10倍,乘以數據節點的數目。原因在於,多個CPU能以並行方式執行查詢。
· 降低了IndexMemory使用:在MySQL 5.1中,每條記錄約消耗25字節的索引內存,每個唯一索引每記錄將使用25字節的索引內存(不含某些數據內存,這是因為它們保存在單獨資料表中)。這是因為在索引內存中,不再需要保存主鍵。
· 為MySQL叢集啟用了查詢高速緩衝:關於配置和使用查詢高速緩衝的更多訊息,請參見5.13節,「MySQL查詢高速緩衝」。
· 新的最佳化:有一個需要給予特別關注的最佳化,即,目前在某些查詢中使用了批式讀取接口。例如,考慮下述查詢:
· SELECT * FROM t1 WHERE primary_key IN (1,2,3,4,5,6,7,8,9,10);
與以往的MySQL叢集版本相比,該查詢的執行速度快2~3倍,原因在於,全部10個 鍵搜尋是在1個批次中發出的,而不是一次發送一個。
· 限制元數據對象的數目:在MySQL 4.1中,每個叢集資料庫最多可能包含1600個元數據對象,包括資料庫資料表,系統資料表,索引和BLOB。在MySQL 5.0中,我們希望將該數值增加到20320。我們打算在2005年年中發佈的MySQL 5.0.6 beta版中實現該增強特性。
這裡所介紹的內容是一份狀態報告,它基於最近提交到MySQL 5.1原始碼樹的內容。請注意,所有的5.1開發活動均可能隨時變化。
目前,有四種為MySQL 5.1開發的主要新特性:
1. 將MySQL叢集集成到了MySQL複製中:這樣,就能從叢集中的任何MySQL伺服器執行更新,並由叢集中的1個MySQL伺服器處理MySQL複製,並保持了從伺服器端安裝的一致性。
2. 支援基於磁盤的記錄:將支援磁盤上的記錄。對於包含主鍵哈希索引的有索引字段,必須仍保存在RAM中,但可以將所有其他字段保存在磁盤上。
3. 大小可變的記錄:定義為VARCHAR(255)的列目前使用260字節的儲存空間,與任何特定記錄中保存的內容無關。在MySQL 5.1叢集資料表中,只保存被記錄實際佔用的字段部分。這樣,在很多情況下,能夠將這類列的空間需求量降低5倍。
4. 用戶定義的分區功能:用戶能夠根據主關鍵的字段部分定義分區。MySQL伺服器能夠發現是否能將某些分區從WHERE子句中刪除。能夠根據KEY、HASH、RANGE和LIST處理程式執行分區操作和子分區操作。對於很多其他處理程式,也應能使用該特性。
此外,對於叢集資料表中包含除BLOB或TEXT外的列類型的行,我們正準備增大8K的大小限制值。這是因為,行目前具有固定的大小,頁大小為32768字節(減去用於行標題的128字節)。在目前,這意味著,如果允許每記錄佔用的大小超過8K,剩餘的空間將為空(多達14000字節)。在MySQL 5.1中,我們打算更正該限制,從而使得在給定行中使用8K以上的空間不會導致頁剩餘部分的浪費。
· 使用叢集與使用複製的區別是什麼?
在複製設置中,主MySQL伺服器負責更新1個或多個從伺服器。事務按順序提交,較慢的事務會導致從伺服器滯後於主伺服器。這意味著,如果主伺服器失敗,從伺服器可能無法記錄最近的少數事務。如果使用了事務安全引擎,如InnoDB,要末是在從伺服器上完成事務,要末是根本就不記錄事務,但複製不保證主伺服器和從伺服器上的所有數據在任何時候都是一致的。在MySQL叢集中,所有的數據節點保持同步,任何一個數據節點提交的事務將被提交給所有的數據節點。當某一數據節點失敗時,所有剩餘的數據節點仍能保持一致的狀態。
簡而言之,儘管標準的MySQL複製是異步的,但MySQL叢集是同步的。
我們計劃在MySQL 5.1中為叢集實現(異步)複製功能。包括在兩個叢集之間,以及MySQL叢集和非叢集類MySQL伺服器之間的複製能力。
· 為了運行叢集,我是否需要進行特殊的組網呢?(叢集中的計算機是如何通信的?)
MySQL叢集是為高帶寬環境下的使用而設計的,計算機通過TCP/IP相連。其性能直接取決於叢集計算機之間的連接速度。對於叢集,最低連接要求包括:典型的100MB以太網網絡或等效網絡。如果可能,建議使用GB以太網。
也支援更快的SCI 協議,但需要特殊硬件。關於SCI的更多訊息,請參見17.7節,「使用與MySQL叢集的高速互連」。
· 運行叢集需要多少台計算機?為什麼?
要想運行可行的叢集,最少需要3台計算機。但在MySQL叢集中,推薦的最低計算機數目為4:1台負責運行管理節點,1台負責運行SQL節點,2台用作儲存節點。使用2個數據節點的目的是為了提供冗余性,管理節點必須運行在單獨的機器上,這樣,當1個數據節點失敗時,仍能保證連續的仲裁服務。
· 叢集中不同計算機所負責的任務是什麼?
MySQL叢集包含物理和邏輯結構,計算機是其物理部件。叢集的邏輯或功能部件稱為節點,容納叢集節點的計算機有時也稱為叢集主機。在理想情況下,每台叢集主機將有1個節點,但在單個叢集主機上可運行多個節點。叢集中有三種節點,每一種節點均對應特定的角色。它們是:
1. 管理節點(MGM節點):為整個叢集提供管理服務,包括啟動、停止、備份、以及為其他節點配置數據。管理節點伺服器是作為應用程式ndb_mgmd實現的,用於通過MGM節點控制MySQL叢集的管理客戶端是ndb_mgm。
2. 數據節點:保存和複製數據。數據節點的功能由NDB數據節點程序ndbd的實例負責處理。
3. SQL節點:這是用「--ndb-cluster」選項啟動的MySQL伺服器(mysqld)的一個實例。
· 用什麼作業系統才能使用叢集呢?
在MySQL 5.1中,在Linux、Mac OS X和Solaris平台上均正式支援MySQL叢集。我們正在努力為其他平台增加叢集支援,包括Windows,我們的目標是,最終在支援MySQL本身的所有平台上實現MySQL叢集。
在其他作業系統上運行叢集也是可能的。用戶告訴我們,他們在FreeBSD平台上超過運行了叢集。但是,除了前面介紹的三種作業系統外,在其他平台上運行的叢集應被視為alpha軟件(最好情況),不保證在生產環境下的可靠性,而且不被MySQL AB支援。
· 運行MySQL叢集的硬件要求是什麼?
在叢集運行的任何平台上,應具有具備NDB功能的二進制檔案。顯而易見,更快的CPU和更多的內存能夠改善性能,64位CPU的效率很可能高於32位處理器。在用於數據節點的機器上必須有足夠的內存,以便容納各節點共享的資料庫部分。(更多訊息,請參見我需要多少內存?)。節點能通過標準的TCP/IP網絡和硬件進行通信。對於SCI支援,需要特殊的組網硬件。
· 由於MySQL叢集使用了TCP/IP,這是否意味著我能在Internet上運行1個或多個節點位於遠程位置的叢集?
請記住,在MySQL叢集中,節點間的通信並不安全,這點極其重要,這類通信未加密,也未採用任何防護機制。對於叢集,最安全的配置是位於防火牆後的專用網絡,不能從外部直接訪問任何叢集數據或管理節點(對於SQL節點,應採取相同的防護措施,就像在MySQL伺服器的其他實例中那樣)。
無論是任何情況,在這類條件下叢集的可靠運行十分令人懷疑,這是因為設計和實施MySQL叢集時,假定它運行在能保證專用高速連通性的條件下,如使用100MB或GB以太網的LAN中(更傾向於後者)。對於低於該要求的任何環境,我們未作任何測試,也不保證其性能。
· 要想使用叢集,我是否不得不學習新的編程語言或查詢語言?
不。儘管使用了一些專用命令來管理和配置叢集本身,但對於下述操作,僅需要標準的(My)SQL查詢和命令:
o 建立、更改和撤銷資料表。
o 插入、更新和刪除資料表數據。
o 建立、更改和撤銷主索引和唯一索引。
o 配置和管理SQL節點(MySQL伺服器)。
· 使用叢集時,如何瞭解錯誤或警告消息的含義呢?
有兩種完成它的方式:
1. 出現錯誤或告警狀況時,在MySQL監視器內,立刻使用SHOW ERRORS或SHOW WARNINGS。也能在MySQL Query Browser(查詢瀏覽器)中顯示它們。
2. 在系統shell提示符下,使用perror --ndb error_code。
· MySQL叢集是事務安全的嗎?支援什麼隔離級別?
是。對於用NDB儲存引擎建立的資料表,支援事務。在MySQL 5.1中,叢集僅支援READ_COMMITTED事務隔離級別。
· 叢集支援的資料表類型是什麼?
NDB是僅有的支援叢集功能的MySQL儲存引擎。
(能夠使用其他儲存引擎在用於叢集的MySQL伺服器上建立資料表,如MyISAM或InnoDB,但這類非NDB資料表不在叢集中)。
· 「NDB」的含義是什麼?
它是「Network Database」(網絡資料庫)的縮寫。
· 哪些版本的MySQL軟件支援叢集?我必須從原始碼編譯嗎?
在5.1系列的所有MySQL-max二進製版本中均支援叢集,但下面介紹的除外。使用命令SHOW VARIABLES LIKE 'have_%';或SHOW ENGINES;,可檢查您的伺服器是否支援NDB(更多訊息,請參見5.1.2節,「mysqld-max延伸MySQL伺服器」)。
Linux用戶請注意,NDB未包含在標準的MySQL伺服器RPM中。對於NDB儲存引擎以及所附的管理工具和其他工具,有單獨的RPM軟件包。請參見MySQL 5.1下載頁上的NDB RPM下載部分(以前,您必須使用以.tar.gz檔案方式提供的「-max」二進制檔案。目前仍能這樣,但卻不是必須的,如果願意,可使用Linux分發版的RPM管理器)。通過從原始碼編譯-max二進制檔案,也能獲得NDB支援,但使用MySQL叢集時,不需要這樣。要想只下載最新的MySQL 5.1系列的二進製版本、RPM、或原始碼分發版,請訪問http://dev.mysql.com/downloads/mysql/5.1.html。
· 我需要多少RAM?是否能全部使用磁盤內存?
在目前,叢集是僅「內存中」的。這意味著所有的資料表數據(包括索引)均保存在RAM中。因此,如果您的數據佔用了1GB的空間,而且打算在叢集中將它複製1次,需要2GB的內存。還應加上作業系統以及在叢集計算機上運行的應用程式所需的內存。
可以使用下述公司粗略估計叢集中每個數據節點所需的RAM量:
(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes
要想更準確地計算內存需求量,需要為叢集資料庫中的每個資料表確定每行所需的儲存空間(詳情請參見11.5節,「列類型儲存需求」),然後乘以占行數。還必須對列索引進行計算,方式如下:
o 對於為NDB叢集資料表建立的每個主鍵索引或哈希索引,每記錄需要21-25字節。這類索引使用IndexMemory(索引內存)。
o 每個有序索引每記錄需要10字節的儲存空間,使用DataMemory(數據內存)。
o 建立主鍵或唯一索引時,還會建立1個有序索引,除非該索引是使用USING HASH建立的。換句話講,如果未使用USING HASH建立它們,對於叢集資料表上的每個鍵多因或唯一索引,在MySQL 5.1中,每記錄佔用31-35字節。
注意,使用USING HASH為所有主鍵和唯一索引建立MySQL叢集資料表時,通常還能使資料表的更新速度更快。這是因為,它需要較少的內存(因未建立有序索引),對CPU的佔用也較低(僅需讀取或更新較少的索引)。
請記住,所有的MySQL叢集資料表必須有主鍵,這點極其重要。如果未定義,NDB儲存引擎將自動建立主鍵,而且該主鍵是在未使用USING HASH的條件下建立的。
很難準確確定叢集索引在任何給定時間用於儲存的內存量,但是,當可用DataMemory和/或IndexMemory的使用率到達80%時,會將警告消息寫入叢集日誌,到達80%、90%等時,也會寫入叢集日誌。
我們經常遇到用戶通報的下述問題,當他們視圖填充叢集資料庫時,加載程序提前終止,並顯示下述錯誤消息:
錯誤1114:資料表'my_cluster_table'已滿。
出現該情況時,很可能是因為在您的設置中未為所有的資料表數據和索引提供足夠的RAM,包括NDB儲存引擎所需的主鍵,以及資料表定義中不包含主鍵定義時自動建立的主鍵。
此外還應注意,所有的數據節點應具有相同的RAM量,這是因為,叢集中任何數據節點所能使用的內存均不超過任意單獨數據節點的最低可用內存。換句話講,如果有三台運行叢集數據節點的計算機,在其中兩台計算機上,有3GB用於保存叢集數據的RAM,另一台計算機只有1GB RAM,那麼每個數據節點僅能為叢集貢獻1GB。
· 出現災難性故障時,例如整個城市斷電而且我的UPS也出現故障,我會丟失所有的數據嗎?
所有已提交的事務將被記錄。因此,在出現災難的情況下,某些數據可能會丟失,但相當有限。通過減少每事務的操作數,能夠進一步減少數據損失(在任何情形下,在每事務上執行大量操作都不是一個好主意)。
· 能夠與叢集一起使用FULLTEXT索引嗎?
FULLTEXT索引功能目前不被NDB儲存引擎支援,也不被除MyISAM之外的任何儲存引擎支援。我們打算在未來的版本中增加該功能。
· 我能在一台計算機上運行多個節點嗎?
可以,但不建議這樣。運行叢集的主要原因之一是提供冗余,為了獲得冗余性的全部優點,每個節點應位於單獨的計算機上。如果將多個節點置於同一台機器,當該機器出現故障時,所有節點均將丟失。考慮到MySQL叢集能運行在常見的硬件上並利用廉價的作業系統(或不需費用),為了確保任務關鍵型數據的安全,值得為額外的機器戶花費開銷。此外還須注意,對運行管理節點的叢集主機的要求最低,使用200 MHz Pentium CPU,作業系統所需的足夠RAM,以及用於ndb_mgmd和ndb_mgm程序的少量開銷,就能完成該任務。
· 我能在不重啟的情況下為叢集增加節點嗎?
目前不行。對於在叢集中新增新的MGM或SQL節點來說,簡單的重啟就是所需的一切。新增數據節點時,程序略微複雜些,需要採取下述步驟:
o 對所有叢集數據進行完整備份。
o 徹底關閉叢集和所有的叢集節點程序。
o 使用「—initial」啟動選項重啟叢集。
o 從備份中恢復所有叢集數據。
在未來的MySQL叢集版本中,我們希望為MySQL叢集實現「熱」重配置功能,以便能夠將新增新節點時重啟叢集的要求降至最低(如果不能消除的話)。
· 使用叢集時有需要我瞭解的限制嗎?
MySQL中的NDB資料表服從下述限制:
o 並非所有的字元編碼和校對均被支援。
o 不支援FULLTEXT索引和前綴索引。只能為完整的列設置索引。不支援第19章:MySQL中的空間延伸中介紹的空間延伸。
o 僅支援對事務的完整回滾。不支援部分回滾以及回滾至保存點。
o 每資料表允許的最大屬性數為128,而且屬性名稱不得超過31個字元。對於每個資料表,資料表和資料庫名稱的最大組合長度為122個字元。
o 資料表行的最大大小為8KB,不包括BLOB。對於每資料表中的行數沒有限制,資料表的大小限制取決於多種因素,尤其是每個數據節點可用的RAM量。
o NDB引擎不支援外部鍵約束。就像MyISAM資料表一樣,這些約束將被忽略。
o 不支援查詢高速緩衝功能。
關於叢集限制的更多訊息,請參見17.8節,「MySQL叢集的已知限制」。
· 怎樣將已有的MySQL資料庫導入到叢集中?
可以將資料庫導入到MySQL叢集中,就像用其他版本的MySQL那樣。除了前一問題所提到的限制外,僅有的特殊要求是,準備包含到叢集中的任何資料表必須使用NDB儲存引擎。這意味著,資料表必須是用ENGINE=NDB或ENGINE=NDBCLUSTER建立的。使用ALTER TABLE,能夠將使用其他儲存引擎的現有資料表轉換為NDB叢集資料表,但需要採取額外避規措施,詳情請參見17.8節,「MySQL叢集的已知限制」。
· 叢集節點是怎樣彼此通信的?
叢集節點能夠通過下述三種協議中的任何一種進行通信:TCP/IP、SHM(共享內存)和SCI(規模可延伸的計算機連接接口)。在適用的場合,對於位於相同叢集主機上的節點間通信,預設協議為SHM。SCI是高速(每秒1GB或更高)、高可用性協議,用於建立可延伸的多處理器系統,它需要特殊硬件和驅動。關於使用SCI作為叢集中傳輸機制的更多訊息,請參見17.7節,「使用與MySQL叢集的高速互連」。
· 什麼是「arbitrator」(仲裁程式)?
如果叢集中的1個或多個節點失敗,並非所有的叢集節點均不能彼此「看到」,這是可能的。事實上,能夠在網絡分區中將兩個節點集合彼此隔離,也稱為「分裂大腦」。這類情形並不受歡迎,這是因為,每一個節點集合都試圖資料表現為代資料表整個叢集。
當叢集節點出現問題時,有兩種可能性。如果剩餘節點的50%以上能夠彼此通信,那麼這就是我們有時稱之為的「多數支配」情形,該節點集合將被視為叢集。當節點數均等時,仲裁程式將介入:在該情形下,仲裁程式所屬的節點集合將被當作叢集,不屬於該節點集合的節點將被關閉。
上述描述略為簡化,更完整的解釋需要考慮下面介紹的節點組:
當至少一個節點組中的所有節點均有效時,網絡分區不是問題,這是因為,叢集中的任一個部分均不能構成1個功能性的叢集。當沒有一個節點組的所有成員均是有效的時,問題產生,在該情況下,網絡分區(「分裂大腦」情形)成為可能。隨後就需要仲裁程式。所有的叢集節點將相同的節點視為仲裁程式,通常是管理伺服器。但是,也能將叢集中的任何MySQL伺服器配置為仲裁程式。仲裁程式接受第一個與其接觸的叢集節點集合,並通知剩餘的集合關閉。對於MySQL伺服器和管理伺服器節點,仲裁程式的選擇是由ArbitrationRank配置參數控制的(詳情請參見17.4.4.4節,「定義MySQL叢集管理伺服器」)。此外還應注意,仲裁程式不會對指定主機施加過多的要求,因此,仲裁程式主機不需要特別塊或擁有用於該目的的額外內存。
· MySQL叢集支援的列類型是什麼?
MySQL叢集支援所有通常的MySQL列類型,但與MySQL空間延伸有關的例外(請參見第19章:MySQL中的空間延伸)。此外,對於索引,當與NDB資料表一起使用時存在一些差別。註釋:MySQL叢集資料表(即用ENGINE=NDBCLUSTER建立的資料表)僅有固定寬度列。這意味著(例如)含有VARCHAR(255)列的每一條記錄需要256字節來保存列,無論列中保存的數據大小是多少。在未來的MySQL版本中,計劃更正它。
關於這些方面的更多訊息,請參見17.8節,「MySQL叢集的已知限制」。
· 如何啟動和停止MySQL叢集?
需要按照下述順序分別啟動叢集中的每個節點:
1. 用ndb_mgmd命令啟動管理節點。
2. 用ndbd命令啟動每個數據節點。
3. 使用mysqld_safe --user=mysql &,啟動每個MySQL伺服器(SQL節點)。
對於這類命令中的每一個,必須在受影響節點所在機器上的系統shell中執行。在容納MGM節點的機器上啟動管理客戶端ndb_mgm,可驗證叢集是否正在運行。
· 當叢集關閉時,會對叢集數據有什麼影響?
由叢集數據節點保存在內存中的數據將被寫入磁盤,並在下一次啟動叢集時重新裝入內存。
要想關閉叢集,請在MGM節點所在的機器上、在shell下輸入下述命令:
shell> ndb_mgm -e shutdown
這樣就能恰當地中止ndb_mgm、ndb_mgm、以及任何ndbd程序。對於用作叢集SQL節點的MySQL伺服器,可使用mysqladmin shutdown停止它。
更多訊息,請參見17.6.2節,「管理客戶端」中的命令和17.3.6節,「安全關閉和重啟」。
· 叢集中有1個以上的管理節點是否有用?
對於可靠性來說它確有幫助。在任何給定的時間,僅需1個MGM節點來控制叢集,但能夠將1個MGM配置為主節點,並配置1個或多個額外的管理節點,以便在主MGM節點出現故障時取代它。
· 在叢集中能混合使用不同的硬件和作業系統嗎?
是。只要所有的機器和作業系統均是相同的endian。也能在不同的節點上使用不同的MySQL叢集版本,但是,我們建議僅應將其作為滾動升級的一部分使用。
· 我能在單台主機上運行兩個數據節點嗎?兩個SQL節點?
是,能夠這樣。在有多個數據節點的情況下,每個節點必須使用不同的數據目錄。如果打算在一台機器上運行多個SQL節點,那麼每個mysqld實例必須使用不同的TCP/IP端口。
· 我能與MySQL叢集一起使用主機名嗎?
是,對於叢集主機,能夠使用DNS和DHCP。但是,如果您的應用程式要求「99.999%」的可用性,建議使用固定的IP地址。這是因為,依賴該服務的叢集節點間的通信會引入額外的故障點,故障點越少越好。
下面給出的術語對理解MySQL叢集有所幫助,而且在與MySQL叢集一起使用時有一定的特殊含義。
· 叢集:
按照通常的理解,叢集是一個計算機集合,其功能相當於1個單位,一起工作以完成單一任務。
NDB叢集:
這是MySQL中使用的儲存引擎,用於實現數據儲存、檢索、以及多個計算機間分佈式管理。
MySQL叢集:
指的是使用NDB儲存引擎一起工作的一組計算機,以便在使用「內存中」儲存的非共享體系結構中支援分佈式MySQL資料庫。
· 配置檔案:
包含與叢集、其主機和節點有關的指令和訊息的文本檔案。當叢集啟動時,這類檔案由叢集的管理節點負責讀取。詳情請參見17.4.4節,「配置檔案」。
· 備份:
所有叢集數據、事務和日誌的完整拷貝,保存在磁盤上或其他長期儲存介質上。
· 恢復:
將叢集返回以前的狀態,與保存在備份中的相同。
· 檢查點:
從廣義上講,將數據保存到磁盤時,即達到了檢查點。具體對於叢集來說,它是將所有已提交事務保存到磁盤的時間點。對於NDB儲存引擎,有兩種一起工作的檢查點,以確保維護叢集數據的一致性:
o 本地檢查點(LCP):
這是專門針對單一節點的檢查點,但是,LCP也會在叢集中的所有節點發生,同步性或強或弱。LCP包括將節點的所有數據保存到磁盤,通常每幾分鐘出現一次。準確的時間間隔會出現變化,具體情況取決於節點上保存的數據量,叢集活動的級別,以及其他因素。
o 全局檢查點(GCP):
GCP每數秒出現一次,此時,將對所有節點的事務進行同步化處理,並將redo日誌保存到磁盤。
· 叢集主機:
構成MySQL叢集組成部分的計算機。叢集具有物理結構和邏輯結構。從物理意義上講,叢集由多個計算機構成,這些計算機也稱為叢集主機(或主機)另請參見下面的節點和節點組。
· 節點:
它指的是MySQL叢集的邏輯或功能性單元,有時也稱為叢集節點。對於MySQL叢集,我們使用術語「節點」資料表示程序而不是叢集的物理部件。實施有效的MySQL叢集需要三種節點。它們是:
o 管理(MGM)節點:
負責管理叢集中的其他節點。它為其他節點提供了配置數據,負責啟動和停止節點,處理網絡分區事宜,建立備份和從備份恢復,等等。
o SQL(MySQL伺服器)節點:
MySQL伺服器的實例,用作叢集數據節點所保存數據的前端。打算保存、檢索或更新數據的客戶端可訪問SQL節點,就像訪問其他MySQL伺服器一樣,採用通常的鑒定方法和API,節點組之間的基本數據分配對用戶和應用程式來說是透明的。SQL節點訪問作為整體的叢集資料庫,而不管數據在不同數據節點或叢集主機上的分佈情況。
o 數據節點:
這些節點負責保存實際數據。資料表數據片段保存在節點組集合中,每個節點組保存資料表數據的不同子集。構成節點組的每個節點均保存了該節點組所負責片段的副本。目前,1個叢集能支援總數為48的數據節點。
1個以上的節點能共存於單台機器上(事實上,能夠在一台機器上設置完成的叢集,但在生產環境下幾乎沒人會這樣做)。請記住,使用MySQL叢集時,術語「主機」指的是叢集的物理部件,而「節點」指的是邏輯或功能部件(即程序),這很有幫助。
關於過時術語的註釋:在MySQL叢集文檔的早期版本中,數據節點有時也稱為「資料庫節點」、「DB節點」、或偶爾使用的「儲存節點」。此外,SQL節點有時也稱為「客戶端節點」或「API節點」。為了將混淆降至最低,這類早期術語已被放棄,為此,應避免使用它們。
· 節點組:
數據節點的集合。位於節點組內的所有數據節點包含相同的數據(片段),而且單個組內的所有節點應位於不同的主機上。能夠對哪個節點術語哪個節點組進行控制。
· 節點失敗:
MySQL叢集並不僅取決於構成構成叢集的任一節點的功能,如果1個或多個節點失敗,叢集仍能運行。給定叢集能容忍的失敗節點的準確數目取決於節點的數目和叢集的配置。
· 節點重啟:
重啟失敗叢集節點的程序。
· 首次節點重啟:
不與其檔案系統一起啟動叢集節點的程序。有時用於軟件升級或其他特殊場合。
· 系統崩潰(或系統失敗):
當很多叢集節點失敗並無法保證叢集的狀態時,就會出現該情況。
· 系統重啟:
重啟叢集並根據磁盤日誌和檢查點重新初始化叢集狀態的程序。在叢集的計劃關閉或非計劃關閉後,通常需要執行該程序。
· 片段:
資料庫資料表的一部分,在NDB儲存引擎中,將資料表分為眾多片段,並以片段方式保存。片段有時也稱為「分區」,但「片段」是更可取的術語。在MySQL叢集中,對資料表進行了片段化處理,從而簡化了機器和節點間的負載平衡。
· 副本:
在NDB儲存引擎下,每個資料表片段均有多個副本,這些副本保存在其他數據節點上,以提供冗余性。目前,每片段最多有4個副本。
· 傳輸器:
提供節點間數據傳輸的協議。MySQL叢集目前提供了四種不同的傳輸器連接:
o TCP/IP(本地)
當然,這是廣為人知的網絡協議,它是Internet上HTTP、FTP等的基礎。
o TCP/IP(遠程)
同上,但用於遠程通信。
o SCI
SCI(規模可延伸的計算機連接接口)是一種高速協議,由於構建多處理器系統和並行處理應用程式。與MySQL叢集一起使用SCI時,需要專門的硬件,具體討論請參見17.7.1節,「配置MySQL叢集以使用SCI套接字」。關於SCI的基本介紹,請參見dolphinics.com上的文章。
o SHM
Unix風格共享內存(SHM)段。在任何支援的場合下,將自動使用SHM來連接運行在相同主機上的節點。要想瞭解這方面的更多訊息,請參見關於shmop(2)的Unix手冊頁。
註釋:叢集傳輸器是叢集內部的。使用MySQL叢集的應用程式與SQL節點進行通信,就像與其他版本的MySQL伺服器進行通信一樣(通過TCP/IP、或使用Unix套接字、或Windows命名管道)。可以使用標準的MySQL API發出查詢並檢索結果。
· NDB:
它是網絡資料庫(Network Database)的縮寫,而且指的是用於啟用MySQL叢集的儲存引擎。NDB儲存引擎支援所有通常的MySQL列類型和SQL語句,而且是ACID兼容的。該引擎還提供了對事務的完整支援(提交和回滾)。
· 無共享體系結構:
用於MySQL叢集的理想體系結構。在真正的無共享設置下,每個節點運行在單獨的主機上。這類安排的優點在於,單個主機或節點不會造成單點故障,也不會成為系統整體的性能瓶頸。
· 內存中儲存:
保存在每個數據節點中的數據均保存在節點宿主計算機的內存中。對於叢集中的每個數據節點,必須提供足夠的RAM,所需的RAM量為:資料庫的大小乘以副本數目,然後除以數據節點的數目。因此,如果資料庫佔用1GB的內存,而且您打算設置具有4個副本和8個數據節點的叢集,每節點所需的最小內存為500 MB。注意,還應加上作業系統所需的內存以及運行在主機上的應用程式所需的內存。
· 資料表:
與關聯資料庫下的通常情況一樣,術語「資料表」指的是具有等同結構的記錄的集合。在MySQL叢集中,資料庫資料表以片段集合的方式保存在數據節點中,並將每個片段複製到額外的數據節點上。複製相同片段或片段集合的數據節點集合稱為節點組。
· 叢集程式:
它們是命令行程式,用於運行、配置和管理MySQL叢集。它們包括兩種伺服器端口監督程式:
o ndbd:
數據節點端口監督程式(運行數據節點程序)。
o ndb_mgmd:
管理伺服器端口監督程式(運行管理伺服器程序)。
以及客戶端程式:
o ndb_mgm:
管理客戶端(為執行管理命令提供了1個界面)。
o ndb_waiter:
用於驗證叢集中所有節點的狀態。
o ndb_restore:
從備份中恢復叢集數據。
關於這些程式及其用法的更多訊息,請參見17.5節,「MySQL叢集中的程序管理」。
· 事件日誌:
MySQL叢集按照類別(啟動、停止、錯誤、檢查點等)、優先級和嚴重級別來記錄事件。關於所有可通報事件的完整列資料表,請參見17.6.3節,「MySQL叢集中生成的事件報告」。事件日誌具有兩種類型:
o 叢集日誌:
為作為整體的叢集記錄所有所需的、值得記錄的事件。
o 節點日誌:
為每個單獨節點保存的單獨日誌。
在正常情況下,僅需保存和檢查叢集日誌,這通常已足夠。節點日誌僅用於應用程式開發和調試目的。
這是MySQL參考手冊的翻譯版本,關於MySQL參考手冊,請訪問dev.mysql.com。原始參考手冊為英文版,與英文版參考手冊相比,本翻譯版可能不是最新的。