### 第17章：MySQL簇 ** 目錄** [17.1. MySQL簇概述](#)[ 17.2. MySQL簇的基本概念](#)[ 17.3. 多計算機的簡單基礎知識](#)[ 17.3.1. 硬件、軟件和聯網](#)[ 17.3.2. 安裝](#)[ 17.3.3. 配置](#)[ 17.3.4. 首次啟動](#)[ 17.3.5. 加載示例數據并執行查詢](#)[ 17.3.6. 安全關閉和重啟](#)[17.4. MySQL簇的配置](#)[ 17.4.1. 從源碼創建MySQL簇](#)[ 17.4.2. 安裝軟件](#)[ 17.4.3. MySQL簇的快速測試設置](#)[17.4.4. 配置文件](#)[ 17.5. MySQL簇中的進程管理](#)[ 17.5.1. 用于MySQL簇的MySQL服務器進程使用](#)[17.5.2. ** ndbd**，存儲引擎節點進程](#)[17.5.3. ** ndb_mgmd**，“管理服務器”進程](#)[17.5.4. ** ndb_mgm**，“管理客戶端”進程](#)[ 17.5.5. 用于MySQL簇進程的命令選項](#)[ 17.6. MySQL簇的管理](#)[17.6.1. MySQL簇的啟動階段](#)[ 17.6.2. “管理客戶端”中的命令](#)[ 17.6.3. MySQL簇中生成的事件報告](#)[ 17.6.4. 單用戶模式](#)[ 17.6.5. MySQL簇的聯機備份](#)[ 17.7. 使用與MySQL簇的高速互連](#)[ 17.7.1. 配置MySQL簇以使用SCI套接字](#)[ 17.7.2. 理解簇互連的影響](#)[ 17.8. MySQL簇的已知限制](#)[17.9. MySQL簇發展的重要歷程](#)[17.9.1. MySQL 5.0中的MySQL簇變化](#)[ 17.9.2. 關于MySQL簇的MySQL 5.1發展歷程](#)[17.10. MySQL簇常見問題解答](#)[17.11. MySQL簇術語表](#) 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/](http://www.mysql.com/products/cluster/)。 或許你也希望使用MySQL AB提供的兩種額外資源： ·???????? MySQL簇[郵件列表](http://lists.mysql.com/cluster)。 ·???????? MySQL用戶論壇上的[簇主題區](http://forums.mysql.com/list.php?25)。 關于簇的一些常見問題，請參見[17.10節，“MySQL簇常見問題解答”](# "17.10.?MySQL Cluster FAQ")。如果你是MySQL簇的新手，請閱讀我方開發人員區的文章[如何為兩個服務器設置MySQL簇](http://dev.mysql.com/tech-resources/articles/mysql-cluster-for-two-servers.html)，這會有所幫助。 ### 17.1.?MySQL簇概述 *MySQL簇*是一種技術，該技術允許在無共享的系統中部署“內存中”數據庫的簇。通過無共享體系結構，系統能夠使用廉價的硬件，而且對軟硬件無特殊要求。此外，由于每個組件有自己的內存和磁盤，不存在單點故障。 MySQL簇將標準的MySQL服務器與名為NDB的“內存中”簇式存儲引擎集成了起來。在我們的文檔中，術語NDB指的是與存儲引擎相關的設置部分，而術語“MySQL簇”指的是MySQL和NDB存儲引擎的組合。 MySQL簇由一組計算機構成，每臺計算機上均運行著多種進程，包括MySQL服務器，NDB簇的數據節點，管理服務器，以及（可能）專門的數據訪問程序。關于簇中這些組件的關系，請參見下圖：  所有這些程序一起構成了MySQL簇。將數據保存到NDB簇存儲引擎中時，表將保存在數據節點內。能夠從簇中所有其他MySQL服務器直接訪問這些表。因此，在將數據保存在簇內的工資表應用程序中，如果某一應用程序更新了1位雇員的工資，所有查詢該數據的其他MySQL服務器能立刻發現這種變化。 對于MySQL簇，保存在數據節點內的數據可被映射，簇能夠處理單獨數據節點的故障，除了少數事務將因事務狀態丟失而被放棄外，不會產生其他影響。由于事務性應用程序能夠處理事務失敗事宜，因而它不是問題源。 通過將MySQL簇引入開放源碼世界，MySQL為所有需要它的人員提供了具有高可用性、高性能和可縮放性的簇數據管理。 ### 17.2.?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簇。 ·???????? **管理客戶端**：這類客戶端與管理服務器相連，并提供了優雅地啟動和停止節點、啟動和停止消息跟蹤（僅對調試版本）、顯示節點版本和狀態、啟動和停止備份等的命令。 ### 17.3.?多計算機的簡單基礎知識 [ 17.3.1. 硬件、軟件和聯網](#)[ 17.3.2. 安裝](#)[ 17.3.3. 配置](#)[ 17.3.4. 首次啟動](#)[ 17.3.5. 加載示例數據并執行查詢](#)[ 17.3.6. 安全關閉和重啟](#) 本節介紹了如何規劃、安裝、配置和運行MySQL簇的基本知識。與[17.4節，“MySQL簇的配置”](# "17.4.?MySQL Cluster Configuration")中給出的示例不同，按照下面介紹的步驟和指南，所得的結果應是有用的MySQL簇，它滿足對數據可用性和安全防護的最低要求。 在本節中，我們介紹了下述內容：硬件和軟件要求，聯網事宜，MySQL簇的安裝，配置事宜，簇的啟動、停止和重啟，加載樣本數據庫，以及執行查詢的方法。 **基本假定** 本節作了如下假定： 1.??? 我們將建立具有4個節點的簇，每個節點位于不同的主機上，而且在典型的以太網中具有固定的網絡地址，如下所述： <table border="1" cellpadding="0" id="table1"><tr><td> <p><strong><span>節點</span></strong></p></td> <td> <p><strong> <span>IP</span><span>地址</span></strong></p></td> </tr><tr><td> <p>管理<span>(MGM)</span>節點</p></td> <td> <p><span>192.168.0.10</span></p></td> </tr><tr><td> <p><span>MySQL</span>服務器<span>(SQL)</span>節點</p></td> <td> <p><span>192.168.0.20</span></p></td> </tr><tr><td> <p>數據<span>(NDBD)</span>節點<span>"A"</span></p></td> <td> <p><span>192.168.0.30</span></p></td> </tr><tr><td> <p>數據<span>(NDBD)</span>節點<span>"B"</span></p></td> <td> <p><span>192.168.0.40</span></p></td> </tr></table> 2.??? 通過下圖可更清楚的表明這點： 1.  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節，“硬件、軟件和聯網”](# "17.3.1.?Hardware, Software, and Networking")）。 ### 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/](http://dev.mysql.com/downloads/)。 對于節點之間的通信，簇支持采用標準拓撲方案的TCP/IP聯網，對于每臺主機的預期最低要求是1塊標準的100 Mbps以太網卡，對于作為整體的簇，還需加上交換器、網絡集線器或路由器以提供網絡連通性。我們強烈建議，應在其自己的子網內運行MySQL簇，不與非簇機器共享該子網，原因如下： ·???????? **安全性：**簇節點之間的通信未采用任何特殊加密或防護。對MySQL簇內傳輸的唯一保護方法是，在受保護的網絡上運行簇。如果打算將MySQL簇用于Web應用，簇應明確地位于防火墻后面，而且不應位于網絡的非軍事區（[DMZ](http://compnetworking.about.com/cs/networksecurity/g/bldef_dmz.htm)）或其他地方。 ·???????? **效率：**在專有的或受保護的網絡上設置MySQL簇，這樣，簇就能獨享簇主機之間的帶寬。為MySQL簇使用單獨的交換器不僅能防止對簇數據的非法訪問，而且還能確保簇節點不受網絡上其他計算機之間信息傳輸的干擾。為了增強可靠性，可以使用雙交換器和雙卡，以防止網絡出現單點故障，對于這類通信鏈路，很多設備驅動均支持故障切換功能。 也能與MySQL簇一起使用高速SCI（規模可擴展的計算機接口），但這不是要求的。關于該協議的更多信息，以及它與MySQL簇的用法，請參見[17.7節，“使用與MySQL簇的高速互連”](# "17.7.?Using High-Speed Interconnects with MySQL Cluster") ### 17.3.2.?安裝 對于每臺運行存儲或SQL節點的MySQL簇主機計算機，必須在其上安裝MySQL-max二進制版本。對于管理節點，沒有必要安裝MySQL服務器二進制版本，但應安裝MGM服務器端口監督程序和客戶端二進制版本（分別是**ndb_mgmd**和**ndb_mgm**）。在本節中，我們介紹了為每種簇節點安裝正確的二進制版本所需的步驟。 MySQL AB提供了預編譯的二進制文件，它們支持簇，你不需要自己編譯這些文件（如果你確實需要定制的二進制文件，請參見[2.8.3節，“從開發源碼樹安裝”](# "2.8.3.?Installing from the Development Source Tree")）。因此，對于每臺簇主機，安裝進程的第一步是從[MySQL下載區](http://dev.mysql.com/downloads/)下載文件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”](# "2.4.?Installing MySQL on Linux")）。使用RPM完成安裝后，仍需對簇進行配置，請參見[17.3.3節，“配置”](# "17.3.3.?Configuration")。 **注釋：**完成安裝后，不啟動任何二進制文件。配置完所有節點后，我們將向你介紹執行這類操作的方法。 **存儲節點和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節，“配置”](# "17.3.3.?Configuration")）。 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節，“配置”](# "17.3.3.?Configuration")中，我們將為示例簇中的所有節點創建和編寫配置文件。 ### 17.3.3.?配置 對于我們的4節點、4主機MySQL簇，需要編寫4個配置文件，每個節點/主機1個。 ·???????? 每個數據節點或SQl節點需要1個my.cnf文件，該文件提供了兩類信息：**connectstring**（連接字符串），用于通知節點到哪里找到MGM節點；以及一行，用于通知該主機（容納數據節點的機器）上的MySQL服務器運行在NDB模式下。 關于連接字符串的更多信息，請參見[17.4.4.2節，“MySQL簇連接字符串``”](# "17.4.4.2.?The MySQL Cluster connectstring")。 ·???????? 管理節點需要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/](http://dev.mysql.com/doc/)下載，它列在“示例”欄目下）。 一旦創建了所有的配置文件并指定了這些最低選項，可啟動簇，并驗證所有進程均能正常運行。關于這方面的討論，請參見[17.3.4節，“首次啟動”](# "17.3.4.?Initial Startup")。 關于可用MySQL簇配置參數以及其用法的更多信息，請參見[17.4.4節，“配置文件”](# "17.4.4.?Configuration File")和[17.4節，“MySQL簇的配置”](# "17.4.?MySQL Cluster Configuration")。關于與進行備份有關的MySQL簇配置，請參見[17.6.5.4節，“簇備份的配置”](# "17.6.5.4.?Configuration for Cluster Backup")。 **注釋：**簇管理節點的默認端口是1186，數據節點的默認端口2202。從MySQL 5.0.3開始，該限制已被放寬，簇能夠根據空閑的端口自動地為數據節點分配端口。 ### 17.3.4.?首次啟動 完成配置后，啟動簇并不很困難。必須在數據節點所在的主機上分別啟動每個簇節點進程。盡管能夠按任何順序啟動節點，但我們建議，應首先啟動管理節點，然后啟動存儲節點，最后啟動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**，“管理服務器”進程”](# "17.5.3.?ndb_mgmd, the Management Server Process")）。 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節，“加載示例數據并執行查詢”](# "17.3.5.?Loading Sample Data and Performing Queries")。 ### 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簇的已知限制”](# "17.8.?Known Limitations of MySQL Cluster")）。這意味著，一旦在一個數據節點上創建了世界（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訪問權限系統”](# "5.7.?The MySQL Access Privilege System")。 需要關注的是，當簇節點彼此訪問時不使用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簇存儲引擎將自動生成隱含的主鍵。（**注釋：**該隱含 鍵也將占用空間，就像任何其他的表索引一樣。由于沒有足夠的內存來容納這些自動創建的鍵，出現問題并不罕見）。 ### 17.3.6.?安全關閉和重啟 要想關閉簇，可在MGM節點所在的機器上，在Shell中簡單地輸入下述命令： ~~~ shell> ndb_mgm -e shutdown ~~~ 該命令將恰當地中止**ndb_mgm**、**ndb_mgmd**以及任何**ndbd**進程。使用**mysqladmin shutdown**或其他方法，可中止SQL節點。注意，這里的“-e”選項用于將命令從shell傳遞到**ndb_mgm**客戶端。請參見[4.3.1節，“在命令行上使用選項”](# "4.3.1.?Using Options on the Command Line")。 要想重啟簇，可簡單地運行下述命令： ·???????? 在管理主機上（本設置中為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節，“使用管理服務器創建備份”](# "17.6.5.2.?Using The Management Server to Create a Backup")。 要想從備份中恢復簇，需要使用**ndb_restore**命令。請參見[17.6.5.3節，“如何恢復簇備份”](# "17.6.5.3.?How to Restore a Cluster Backup")。 關于配置MySQL簇的更多信息，請參見[17.4節，“MySQL簇的配置”](# "17.4.?MySQL Cluster Configuration")。 ### 17.4.?MySQL簇的配置 [ 17.4.1. 從源碼創建MySQL簇](#)[ 17.4.2. 安裝軟件](#)[ 17.4.3. MySQL簇的快速測試設置](#)[17.4.4. 配置文件](#) 作為MySQL簇組成部份的MySQL服務器僅在一個方面上與正常的（非簇式）MySQL服務器不同，它采用了NDB簇存儲引擎。該引擎也簡單地稱為NDB，這兩個術語是同義詞。 為了避免不必要的資源分配，默認情況下，在服務器的配置中將禁止NDB存儲引擎。要想啟用NDB，需要更改服務器的my.cnf配置文件，或使用“—ndbcluster”選項啟動服務器。 由于MySQL服務器是簇的一部分，它也需要知道如何訪問MGM節點，以便獲得簇配置數據。默認行為是查找本地主機上MGM節點。但是，如果需要另外指定它的位置，可在my.cnf文件或MySQL服務器命令行上進行。能夠使用NDB存儲引擎之前，至少應有一個MGM節點是可操作的，而且還應有所需的數據節點。 ### 17.4.1.?從源碼創建MySQL簇 對于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節，“從開發源碼樹安裝”](# "2.8.3.?Installing from the Development Source Tree")。 ### 17.4.2.?安裝軟件 在下面的數節內，假定你已熟悉了MySQL的安裝方法，在此，我們僅介紹了MySQL簇配置與不具備簇功能的MySQL配置之間的差別。如果希望了解關于后者的更多信息，請參見[第2章：安裝MySQL](# "Chapter?2.?Installing MySQL")。 如果首先運行了所有的管理和數據節點，你將發現簇配置最簡單，這或許是最花時間的配置部分。編輯my.cnf文件相對直接，在本節中，僅討論與不具備簇功能的MySQL配置不同的部分。 ### 17.4.3.?MySQL簇的快速測試設置 為了幫助你熟悉基本概念，我們將介紹功能性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創建的表，將數據保存到簇中。 ### 17.4.4.?配置文件 [ 17.4.4.1. MySQL簇的配置示例](#)[ 17.4.4.2. MySQL簇連接字符串``](#)[ 17.4.4.3. 定義構成MySQL簇的計算機](#)[ 17.4.4.4. 定義MySQL簇管理服務器](#)[ 17.4.4.5. 定義MySQL簇數據節點](#)[ 17.4.4.6. 定義MySQL簇內的SQL節點](#)[ 17.4.4.7. MySQL簇TCP/IP連接](#)[17.4.4.8. 使用直接連接的MySQL簇TCP/IP連接](#)[ 17.4.4.9. MySQL簇共享內存連接](#)[ 17.4.4.10. MySQL簇SCI傳輸連接](#) 配置MySQL簇需要與兩個文件打交道： ·???????? my.cnf：為所有的MySQL簇可執行文件指定了選項。你應熟悉了前面介紹的使用MySQL的方式，通過運行在簇中的每個可執行文件，必須能夠訪問該文件。 ·???????? config.ini：該文件僅由MySQL簇管理服務器讀取，隨后管理服務器會將包含該文件的信息分配給簇中的所有進程。config.ini文件包含對簇中各節點的描述。包括數據節點的配置參數，以及簇中所有節點間連接的配置參數。 我們正在不斷改進簇配置，并努力簡化該進程。盡管我們將盡量維護向后兼容性，但在某些時候，可能也需要引入不兼容的變動。在這種情況下，我們將盡量讓簇用戶事先了解該變動是否是向后兼容的。如果你發現了尚未記錄在文檔中的這類變動，請使用我們的[缺陷數據庫](http://bugs.mysql.com/)通報它。 #### 17.4.4.1.?MySQL簇的配置示例 為了支持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簇連接字符串``”](# "17.4.4.2.?The MySQL Cluster connectstring")）。 ~~~ # 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值。所有的簇參數名稱均區分大小寫。 #### 17.4.4.2.?MySQL簇連接字符串`` 除了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](http://www.iana.org/assignments/port-numbers)）。 通過列出多個<host-specification>值，能夠指定數個冗余管理服務器。簇節點將按照指定的順序嘗試連接到每臺主機上的連續管理服務器，直至成功建立起連接為止。 有多種指定連接字符串的不同方法： ·???????? 每個可執行文件有自己的命令行選項，使用它，能夠在啟動時指定管理服務器（關于各可執行程序的介紹，請參見相應的文檔）。 ·???????? 也能一次性地為簇中的所有節點設置連接字符串，方法是將其放在管理服務器的my.cnf文件的[mysql_cluster]部分。 ·???????? 為了向后兼容性，還提供了兩種其他選項，其使用的語法相同： 1.??? 設置NDB_CONNECTSTRING環境變量，使之包含connectstring（連接字符串）。 2.??? 將針對各可執行文件的connectstring（連接字符串）寫入名為Ndb.cfg的文本文件，并將該文件放在可執行文件的啟動目錄下。 但是，這些方法目前已不再受重視，對于新安裝，不應使用它們。 指定連接字符串時，推薦的方法是在命令行上設置它，或為每個可執行文件在my.cnf文件中設置它。 #### 17.4.4.3.?定義構成MySQL簇的計算機 除了用于避免為系統中的每個節點定義主機名外，[COMPUTER]部分沒有實際的重要意義。這里所提到的所有參數都是需要的。 ·???????? [COMPUTER]Id 這是整數值，用于引用位于配置文件中別處的主機計算機。 ·???????? [COMPUTER]HostName 這是計算機的主機名或IP地址。 #### 17.4.4.4.?定義MySQL簇管理服務器 [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參數覆蓋它，請參見本節前面的討論）。 #### 17.4.4.5.?定義MySQL簇數據節點 [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. #### 17.4.4.6.?定義MySQL簇內的SQL節點 在config.ini文件的[MYSQLD]部分中，定義了用于訪問簇數據的MySQL服務器（SQL節點）的行為。不需要其中所給出的參數。如果未提供計算機或主機名，那么任何主機均能使用該SQL節點。 ·???????? [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。 #### 17.4.4.7.?MySQL簇TCP/IP連接 在MySQL簇中，TCP/IP是用于建立連接的默認傳輸協議。正常情況下不需要定義連接，這是因為，簇能自動建立數據節點間、數據節點與所有MySQL服務器節點、以及數據節點與管理服務器之間的連接（關于該規則的例外，，請參見[17.4.4.8節，“使用直接連接的MySQL簇TCP/IP連接”](# "17.4.4.8.?MySQL Cluster TCP/IP Connections Using Direct Connections"))。 如果打算覆蓋默認的連接參數，才需要定義連接。在這種情況下，至少需要定義*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，但是如果打算節省內存，也能更改它。 #### 17.4.4.8.?使用直接連接的MySQL簇TCP/IP連接 使用數據節點之間的直接連接建立簇時，需要在簇config.ini文件的[TCP]部分中明確指定如此連接的數據節點的交叉IP地址。 在下面的示例中，假定簇具有至少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、路由器等，從而減少了簇的等待時間。注意，對于兩個以上的數據節點，要想充分利用這類直接連接的優點，需要為各數據節點建立與相同節點組內的其他數據節點間的直接連接。 #### 17.4.4.9.?MySQL簇共享內存連接 MySQL簇將嘗試使用共享內存傳輸器，并在可能的情況下自動配置它，尤其是在相同的簇主機上同時運行著1個以上的節點時。在MySQL簇的早期版本中，僅當使用--with-ndb-shm創建了-max二進制版本時，才支持共享內存段。明確地將共享內存定義為連接方法時，至少需要定義NodeId1、NodeId2和ShmKey。對于所有其他參數，應具有在大多數情況下均良好工作的默認值。 **注釋：**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參數，默認情況下處于禁止狀態。如果允許該參數，在將所有消息置于發送緩沖之前，對為所有消息計算校驗和。 使用該特性，當消息等候在發送緩沖中時，能防止消息損壞。此外，它還能用于在傳輸過程中檢查損壞的數據。 #### 17.4.4.10.?MySQL簇SCI傳輸連接 僅當使用--with-ndb-sci=*/your/path/to/SCI*創建了MySQL-Max二進制版本時，在MySQL簇中才支持使用SCI傳輸器來連接節點。*path*應指向包含最低庫的目錄，并應包括含SISCI庫和頭文件的目錄。 此外，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（校驗和）時，在將所有消息置于發送緩沖之前，將為所有參數計算校驗和。使用該特性，當消息等候在發送緩沖中時，可以確保消息不會損壞。此外，它還能用于在傳輸過程中檢查損壞的數據。 ### 17.5.?MySQL簇中的進程管理 [ 17.5.1. 用于MySQL簇的MySQL服務器進程使用](#)[17.5.2. ** ndbd**，存儲引擎節點進程](#)[17.5.3. ** ndb_mgmd**，“管理服務器”進程](#)[17.5.4. ** ndb_mgm**，“管理客戶端”進程](#)[ 17.5.5. 用于MySQL簇進程的命令選項](#) 要想掌握管理MySQL簇的方法，需要了解4種基本進程。在本章下面的幾節內，介紹了這些進程在簇內的作用，它們的使用方法，以及每種進程可用的啟動選項。 ### 17.5.1.?用于MySQL簇的MySQL服務器進程使用 **mysqld**是傳統的MySQL服務器進程。要想與MySQL簇一起使用，所創建的**mysqld**應支持NDB簇存儲引擎，就像在預編譯的-max二進制版本中那樣，[http://dev.mysql.com/downloads/](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簇連接字符串``”](# "17.4.4.2.?The MySQL Cluster connectstring")。 給定該信息，MySQL服務器將成為簇中的完全參與者。（有時，我們也將運行在該方式下的**mysqld**進程稱為SQL節點）。它能完全了解所有的簇數據節點以及它們的狀態，并能建立與所有數據節點的連接。在這種情形下，它能將任何數據節點用作事務協調器，并能訪問數據節點以執行讀取和更新操作。 ### 17.5.2.?**ndbd**，存儲引擎節點進程 **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簇連接字符串``”](# "17.4.4.2.?The MySQL Cluster connectstring")。 啟動**ndbd**時，它實際上將啟動兩種進程。第1種進程稱為“angel process”（天使進程），它的唯一任務是發現執行進程在何時完成，然后重啟ndbd進程（如果作了該配置的話）。因此，如果你打算使用Unix的kill命令殺死ndbd進程，就需要殺死這兩個進程。中止ndbd進程的更恰當方法是使用管理客戶端，并通過該管理客戶端停止進程。 執行進程采用了1個線程，用于讀取、寫入和掃描數據，以及所有其他任務。該線程是異步實施的，以便能方便地處理數以千計的并發活動。此外，看門狗線程負責監督執行線程，以確保執行線程不會陷入無限循環。線程池負責處理文件I/O，每個線程均能處理一個打開的文件。這些線程也能被ndbd進程中的傳輸器用作傳輸器連接。在執行包含更新在內的大量操作的系統中，如果允許，ndbd進程能占用2個CPU。對于擁有多CPU的機器，建議使用屬于不同節點組的數個ndbd進程。 ### 17.5.3.?**ndb_mgmd**，“管理服務器”進程 管理服務器是這樣一種進程，它讀取簇配置文件，并將該信息分配給簇中所有請求該信息的節點。它還負責維護簇活動的日志。管理客戶端能夠連接到管理服務器，并檢查簇的狀態。 啟動管理服務器時，不是一定需要指定連接字符串。但是，如果使用了1個以上的管理服務器，應提供連接字符串，而且簇中的每個節點應明確指定自己的節點ID。 下述文件是由**ndb_mgmd**在其啟動目錄下創建或使用的，并會被置于配置文件中指定的DataDir中。在下面的列表中，*node_id*是唯一性節點ID。 ·???????? config.ini是作為整體的簇的配置文件。該文件由用戶創建并由管理服務器讀取。在[17.4節，“MySQL簇的配置”](# "17.4.?MySQL Cluster Configuration")中，討論了設置該文件的方法。 ·???????? ndb_*node_id*_cluster.log是簇事件日志文件。這類事件的例子包括：檢查點操作的啟動和完成，節點啟動事件，節點故障，以及內存使用水平。關于簇事件的完整列表和描述，請參見[17.6節，“MySQL簇的管理”](# "17.6.?Management of MySQL Cluster")。 當簇日志的大小達到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文件。 ### 17.5.4.?**ndb_mgm**，“管理客戶端”進程 對于簇的運行，實際上不需要管理客戶端的進程。其價值在于它提供了一組命令，這組命令可用于檢查簇的狀態、啟動備份、并執行其他管理功能。管理客戶端使用C API來訪問管理服務器，高級用戶也能使用C API來編制專用的管理進程來執行任務，這類任務與**ndb_mgm**執行的類似。 啟動管理客戶端時，需要提供管理服務器的主機名和端口號，如下例所示。默認值是localhost和1186。 ~~~ shell> ndb_mgm localhost 1186 ~~~ 關于使用**ndb_mgm**的更多信息，請參見[17.5.5.4節，“ndb_mgm的命令選項****”](# "17.5.5.4.?Command Options for ndb_mgm")和[17.6.2節，“管理客戶端”中的命令](# "17.6.2.?Commands in the Management Client")。 ### 17.5.5.?用于MySQL簇進程的命令選項 [ 17.5.5.1. 用于mysqld的與MySQL有關的命令選項****](#)[ 17.5.5.2. ndbd命令選項****](#)[ 17.5.5.3. ndb_mgmd的命令選**項**](#)[ 17.5.5.4. ndb_mgm的命令選項****](#) 所有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節，“在命令行上使用選項”](# "4.3.1.?Using Options on the Command Line")。 ? #### 17.5.5.1.?用于mysqld的與MySQL有關的命令選項**** ·???????? --ndbcluster 如果二進制版本包含對NDB簇存儲引擎的支持，可使用該選項覆蓋對NDB簇存儲引擎（簡稱為NDB存儲引擎）的默認禁止設置。使用MySQL簇時，NDB簇存儲引擎是必要的。 ·???????? --skip-ndbcluster 禁止NDB簇存儲引擎。對于包含該功能的二進制版本，在默認情況下，該功能是被禁止的，換句話講，NDB簇存儲引擎處于禁止狀態，直至使用“—ndbcluster”選項激活了它為止。僅當所編譯的服務器支持NDB簇存儲引擎時，才能使用該選項。 ·???????? --ndb-connectstring=*connect_string* 使用NDB存儲引擎時，通過設置該選項，能夠指定分配簇配置數據的管理服務器。 #### 17.5.5.2.?ndbd命令選項**** 關于某些常見選項的更多信息，請參見[17.5.5節，“用于MySQL簇進程的命令選項”](# "17.5.5.?Command Options for MySQL Cluster Processes")。 ·???????? -d, --daemon 通知**ndbd**作為daemon（端口監督程序）進程執行（默認行為）。 ·???????? --nodaemon 指明**ndbd**不得作為daemon（端口監督程序）進程啟動。調試ndbd以及希望將輸出重定向到屏幕時，它很有用。 ·???????? --initial 通知**ndbd**執行初始化啟動。初始化啟動將刪除以前ndbd實例為恢復目的創建的任何文件。它還能重新創建恢復用日志文件。注意，在某些操作系統上，該進程可能會占用較長的時間。 僅在首次啟動ndbd進程時才應使用—initial啟動，這是因為它將刪除簇文件系統的所有文件，并再次創建所有的REDO日志文件。該規則的例外如下： o??????? 執行那些會更改文件內容的軟件升級時。 o??????? 用新的ndbd版本重啟節點時。 o??????? 出于某種原因，節點重啟或系統重啟不斷失敗時的最后手段。在這類情形下，請注意，由于數據文件的損壞，不能使用該節點來恢復數據。 該選項不影響那些已被受影響節點創建的備份文件。 ·???????? --nostart 指示**ndbd**不自動啟動。使用該選項時，**ndbd**連接到管理服務器，從管理服務器獲取配置數據，并初始化通信對象。但是，在管理服務器特別要求之前，它不會實際啟動執行引擎。通過向管理客戶端發出恰當的命令，可完成該任務。 #### 17.5.5.3.?ndb_mgmd的命令選**項** 關于某些常見選項的更多信息，請參見[17.5.5節，“用于MySQL簇進程的命令選項”](# "17.5.5.?Command Options for MySQL Cluster Processes")。 ·???????? -f *filename*, --config-file=*filename*, (**OBSOLETE**): -c *filename* 通知管理服務器應使用哪個文件作為其配置文件。必須指定該選項。文件名默認為config.ini。注意，“-c”快捷方式已過時，不應在新的安裝實例中使用它。 ·???????? -d, --daemon 指示**ndb_mgmd**作為端口監督程序啟動。這是默認行為。 ·???????? --nodaemon 指示管理服務器不作為端口監督程序啟動。 #### 17.5.5.4.?ndb_mgm的命令選項**** 關于某些常見選項的更多信息，請參見[17.5.5節，“用于MySQL簇進程的命令選項”](# "17.5.5.?Command Options for MySQL Cluster Processes")。 ·???????? [*host_name* [*port_num*]] 要想啟動管理客戶端，需要指定管理服務器所在的位置，即指定主機名和端口。默認的主機名是localhost，默認端口是1186。 ·???????? --try-reconnect=*number* 如果與管理服務器的連接斷開，每隔5秒，節點將嘗試再次連接到管理服務器，直至成功。使用該選項，能夠將嘗試的字數限制在number指定的值，超過該限制后，將放棄嘗試并通報錯誤。 ### 17.6.?MySQL簇的管理 [17.6.1. MySQL簇的啟動階段](#)[ 17.6.2. “管理客戶端”中的命令](#)[ 17.6.3. MySQL簇中生成的事件報告](#)[ 17.6.4. 單用戶模式](#)[ 17.6.5. MySQL簇的聯機備份](#) 管理MySQL簇涉及眾多任務，首先是配置和啟動MySQL簇。詳情請參見[17.4節，“MySQL簇的配置”](# "17.4.?MySQL Cluster Configuration")和[17.5節，“MySQL簇中的進程管理”](# "17.5.?Process Management in MySQL Cluster")。 下面介紹了MySQL簇的管理事宜。 有兩種積極管理MySQL簇的基本方法。第1種方法是，使用在管理客戶端中輸入的命令，借此可檢查簇的狀態，更改日志級別，啟動和停止備份，以及啟動和停止節點。對于第2種方法，需要研究管理服務器DataDir目錄下簇日志文件ndb_*node_id*_cluster.log的內容。（*node_id*代表其活動已被記錄的節點的唯一ID）。簇日志包含由**ndbd**生成的事件報告。也能將簇日志條目發送到Unix的系統日志中。 ### 17.6.1.?MySQL簇的啟動階段 本節介紹了啟動簇時涉及的步驟。 有數種不同的啟動類型和模式，如下所述： ·???????? **首次啟動：**在所有節點上與干凈的文件系統一起啟動簇。這或是出現在首次啟動簇時，或是使用“--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** 在節點重啟或首次節點重啟的這一階段，將事件傳遞任務提交給加入簇的節點。新加入的節點負責將其主要數據傳遞給訂方。 對于首次啟動或系統重啟，一旦該進程完成，將啟用事務處理功能。對于節點重啟或首次節點重啟，啟動進程的完成意味著節點現在能夠成為事務協調程序。 ### 17.6.2.?“管理客戶端”中的命令 除了中央配置文件外，還能通過管理客戶端**ndb_mgm**提供的命令行界面對簇進行控制。這是運行簇的主要管理界面。 管理客戶端提供了下述基本命令。在下面給出的清單中，*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節點之外的所有簇節點，并退出。 在下一節中，介紹了用于事件日志的命令。在這些議題的單獨一節中，介紹了用于創建備份以及從備份中恢復的命令。 ### 17.6.3.?MySQL簇中生成的事件報告 [ 17.6.3.1. 登記管理命令](#)[ 17.6.3.2. 日志事件](#) 在本節中，我們討論了MySQL簇提供的事件日志的類型，以及記錄的事件類型。 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。 無論是簇日志還是節點日志，都能根據這些屬性進行過濾。 #### 17.6.3.1.?登記管理命令 下述管理命令與簇日志有關： ·???????? CLUSTERLOG ON 打開簇日志。 ·???????? CLUSTERLOG OFF 關閉簇日志。 ·???????? CLUSTERLOG INFO 關于簇日志設置的信息。 ·???????? * node_id* CLUSTERLOG *category*=*threshold* 用小于或等于*threshold*的優先級將*category*事件記錄到簇日志。 ·???????? CLUSTERLOG FILTER *severity_level* 將簇事件日志切換為指定的*severity_level*。 在下表中，介紹了簇日志類別閾值的默認設置（對于所有數據節點）。如果事件的優先級值低于或等于優先級閾值，就會在簇日志中記錄。 注意，事件是按數據節點通報的，可在不同的節點上設置不同的閾值。 <table border="1" cellpadding="0" id="table2"><tr><td> <p><strong> <span>類別</span></strong></p></td> <td> <p><strong> <span>默認閾值（所有數據節點）</span></strong></p></td> </tr><tr><td> <p> <span>STARTUP</span></p></td> <td> <p><strong> <span>7</span></strong></p></td> </tr><tr><td> <p> <span>SHUTDOWN</span></p></td> <td> <p><strong> <span>7</span></strong></p></td> </tr><tr><td> <p> <span>STATISTICS</span></p></td> <td> <p><strong> <span>7</span></strong></p></td> </tr><tr><td> <p> <span>CHECKPOINT</span></p></td> <td> <p><strong> <span>7</span></strong></p></td> </tr><tr><td> <p> <span>NODERESTART</span></p></td> <td> <p><strong> <span>7</span></strong></p></td> </tr><tr><td> <p> <span>CONNECTION</span></p></td> <td> <p><strong> <span>7</span></strong></p></td> </tr><tr><td> <p> <span>ERROR</span></p></td> <td> <p><strong> <span>15</span></strong></p></td> </tr><tr><td> <p> <span>INFO</span></p></td> <td> <p><strong> <span>7</span></strong></p></td> </tr></table> 閾值用于過濾每種類別中的事件。例如，對于優先級為3的STARTUP事件，不會將其記錄到日志中，除非將STARTUP的閾值更改為3或更小。如果閾值為3，僅發送優先級等于或小于3的事件。 下面給出了事件的嚴重級別（注釋：它們與Unix的syslog級別對應；但LOG_EMERG和LOG_NOTICE除外，未使用或未映射它們）： <table border="1" cellpadding="0" id="table3"><tr><td> <p><strong> <span>1</span></strong></p></td> <td> <p> <span>ALERT</span></p></td> <td> <p>應立刻更正的狀況，如損壞的系統數據庫。</p></td> </tr><tr><td> <p><strong> <span>2</span></strong></p></td> <td> <p> <span>CRITICAL</span></p></td> <td> <p>臨界狀況，如設備錯誤或資源不足。</p></td> </tr><tr><td> <p><strong> <span>3</span></strong></p></td> <td> <p> <span>ERROR</span></p></td> <td> <p>應予以更正的狀況，如配置錯誤等。</p></td> </tr><tr><td> <p><strong> <span>4</span></strong></p></td> <td> <p> <span>WARNING</span></p></td> <td> <p>不能稱其為錯誤的狀況，但仍需要特別處理。</p></td> </tr><tr><td> <p><strong> <span>5</span></strong></p></td> <td> <p> <span>INFO</span></p></td> <td> <p>通報性消息。</p></td> </tr><tr><td> <p><strong> <span>6</span></strong></p></td> <td> <p> <span>DEBUG</span></p></td> <td> <p>調試消息，用于<span><span>NDB</span>簇開發。</span></p></td> </tr></table> 可以打開或關閉事件嚴重級別。如果打開了事件嚴重級別，那么優先級等于或低于類別閾值的事件均將被記錄。如果關閉了事件嚴重級別，那么將不記錄屬于該嚴重級別的任何事件。 #### 17.6.3.2.?日志事件 事件日志中記錄的事件報告采用下述格式：*datetime* [*string*] *severity* – *message*。例如： ~~~ 09:19:30 2005-07-24 [NDB] INFO -- Node 4 Start phase 4 completed ~~~ 本節討論了所有值得通報的事件，按類別以及每一類別中的嚴重級別排序。 **CONNECTION****事件** 這類事件與簇節點之間的連接有關。 <table border="1" cellpadding="0" id="table4"><tr><td> <p><strong> <span>事件</span></strong></p></td> <td> <p><strong> <span>優先級</span></strong></p></td> <td> <p><strong> <span>嚴重級別</span></strong></p></td> <td> <p><strong> <span>描述</span></strong></p></td> </tr><tr><td> <p><span>DB</span>節點已連接</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>數據節點已連接</p></td> </tr><tr><td> <p><span>DB</span>節點斷開連接</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>數據節點斷開連接</p></td> </tr><tr><td> <p>通信關閉</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>SQL</span>節點或數據節點的連接已關閉</p></td> </tr><tr><td> <p>通信打開</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>SQL</span>節點或數據節點的連接已打開</p></td> </tr></table> **CHECKPOINT****事件** 下面給出的日志消息與檢查點有關。 （注釋：GCP =全局檢查點，LCP =本地檢查點）。 <table border="1" cellpadding="0" id="table5"><tr><td> <p><strong> <span>事件</span></strong></p></td> <td> <p><strong> <span>優先級</span></strong></p></td> <td> <p><strong> <span>嚴重級別</span></strong></p></td> <td> <p><strong> <span>描述</span></strong></p></td> </tr><tr><td> <p>在<span>calc keep GCI</span>中，<span>LCP</span>已停止</p></td> <td> <p><span>0</span></p></td> <td> <p><span>ALERT</span></p></td> <td> <p><span>LCP</span>已停止</p></td> </tr><tr><td> <p>本地檢查點片段完成</p></td> <td> <p><span>11</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>片段上的<span>LCP</span>已完成</p></td> </tr><tr><td> <p>全局檢查點完成</p></td> <td> <p><span>10</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>GCP</span>完成</p></td> </tr><tr><td> <p>全局檢查點啟動</p></td> <td> <p><span>9</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>啟動<span>GCP</span>：將<span>REDO</span>日志寫入磁盤</p></td> </tr><tr><td> <p>本地檢查點完成</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>LCP</span>已正常完成</p></td> </tr><tr><td> <p>本地檢查點啟動</p></td> <td> <p><span>7</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>啟動<span>LCP</span>：將數據寫入磁盤</p></td> </tr><tr><td> <p>報告<span>undo</span>日志已封閉</p></td> <td> <p><span>7</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>UNDO</span>日志已封閉：緩沖快要溢出</p></td> </tr></table> **STARTUP****事件** 下述事件是在成功或失敗的節點啟動或簇啟動時生成的。它們還提供了與啟動進程進展狀況有關的信息，包括與日志活動有關的信息。 <table border="1" cellpadding="0" id="table6"><tr><td> <p><strong> <span>事件</span></strong></p></td> <td> <p><strong> <span>優先級</span></strong></p></td> <td> <p><strong> <span>嚴重級別</span></strong></p></td> <td> <p><strong> <span>描述</span></strong></p></td> </tr><tr><td> <p>收到內部啟動信號<span>STTORRY</span></p></td> <td> <p><span>15</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>重啟完成后收到的信息塊</p></td> </tr><tr><td> <p><span>Undo</span>記錄已執行</p></td> <td> <p><span>15</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>新的<span>REDO</span>日志已啟動</p></td> <td> <p><span>10</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>GCI</span>保持<span><i><span>X</span></i></span>，最新的可恢復<span>GCI <span><i>Y</i></span></span></p></td> </tr><tr><td> <p>新日志已啟動</p></td> <td> <p><span>10</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>日志部分<span><i><span>X</span></i></span>，啟動<span>MB <span><i>Y</i></span></span>，停止<span>MB <span><i>Z</i></span></span></p></td> </tr><tr><td> <p>拒絕將節點納入簇中</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>由于配置錯誤、無法建立通信、或其他問題，不能將節點包含在簇中。</p></td> </tr><tr><td> <p><span>DB</span>節點鄰居</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>顯示附近的數據節點。</p></td> </tr><tr><td> <p><span>DB</span>節點啟動階段<span>X</span>完成</p></td> <td> <p><span>4</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>數據節點啟動階段已完成。</p></td> </tr><tr><td> <p>節點已被簇成功接納</p></td> <td> <p><span>3</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>顯示節點，管理節點，以及動態<span>ID</span>。</p></td> </tr><tr><td> <p><span>DB</span>節點啟動階段已開始</p></td> <td> <p><span>1</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>NDB</span>簇節點正在啟動。</p></td> </tr><tr><td> <p><span>DB</span>節點的所有啟動階段已完成</p></td> <td> <p><span>1</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>NDB</span>簇節點已啟動。</p></td> </tr><tr><td> <p><span>DB</span>節點關閉操作已啟動</p></td> <td> <p><span>1</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>數據節點的關閉操作已開始</p></td> </tr><tr><td> <p><span>DB</span>節點關閉操作失敗</p></td> <td> <p><span>1</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>無法正常關閉數據節點。</p></td> </tr></table> **NODERESTART****事件** 下述事件是在重啟節點時產生的，并與節點重啟進程的成功或失敗相關。 <table border="1" cellpadding="0" id="table7"><tr><td> <p><strong> <span>事件</span></strong></p></td> <td> <p><strong> <span>優先級</span></strong></p></td> <td> <p><strong> <span>嚴重級別</span></strong></p></td> <td> <p><strong> <span>描述</span></strong></p></td> </tr><tr><td> <p>節點失敗階段完成</p></td> <td> <p><span>8</span></p></td> <td> <p><span>ALERT</span></p></td> <td> <p>通報節點失敗階段的完成</p></td> </tr><tr><td> <p>節點失敗，節點狀態為<span><i><span>X</span></i></span></p></td> <td> <p><span>8</span></p></td> <td> <p><span>ALERT</span></p></td> <td> <p>通報節點已失敗</p></td> </tr><tr><td> <p>通報仲裁程序結果</p></td> <td> <p><span>2</span></p></td> <td> <p><span>ALERT</span></p></td> <td> <p>對于仲裁嘗試，有<span>8</span>種不同的可能結果：</p> <p> <span> ·<span>???????? </span></span>仲裁檢查失敗，剩余節點少于<span>1/2</span>。</p> <p> <span> ·<span>???????? </span></span>仲裁檢查成功，節點組多數</p> <p> <span> ·<span>???????? </span></span>仲裁檢查失敗，丟失節點組</p> <p> <span> ·<span>???????? </span></span>網絡分區，要求仲裁</p> <p> <span> ·<span>???????? </span></span>仲裁成功，來自節點<span><i><span>X</span></i></span>的正面回應</p> <p> <span> ·<span>???????? </span></span>仲裁失敗，來自節點<span><i><span>X</span></i></span>的負面回應</p> <p> <span> ·<span>???????? </span></span>網絡分區，無可用的仲裁程序</p> <p> <span> ·<span>???????? </span></span>網絡分區，未配置仲裁程序</p></td> </tr><tr><td> <p>完成了片段復制</p></td> <td> <p><span>10</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>完成了目錄信息復制</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>完成了分配信息復制</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>開始復制片段</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>完成了所有片段的復制</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p><span>GCP</span>接收已啟動</p></td> <td> <p><span>7</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p><span>GCP</span>接收已完成</p></td> <td> <p><span>7</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p><span>LCP</span>接收已啟動</p></td> <td> <p><span>7</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p><span>LCP</span>接收已完成（狀態<span>= <span><i>X</i></span></span>）</p></td> <td> <p><span>7</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>通報是否發現了仲裁程序</p></td> <td> <p><span>6</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>搜索仲裁程序時，有<span>7</span>種可能的結果：</p> <p> <span> ·<span>???????? </span></span>管理服務器重啟仲裁線程<span>[state=<span><i>X</i></span>] </span></p> <p> <span> ·<span>???????? </span></span>準備仲裁程序節點<span><i><span>X</span></i></span><span> [ticket=<span><i>Y</i></span>] </span></p> <p> <span> ·<span>???????? </span></span>接收仲裁程序節點<span><i><span>X</span></i></span><span> [ticket=<span><i>Y</i></span>] </span></p> <p> <span> ·<span>???????? </span></span>啟動仲裁程序節點<span><i><span>X</span></i></span><span> [ticket=<span><i>Y</i></span>] </span></p> <p> <span> ·<span>???????? </span></span>丟失了仲裁程序節點<span><i><span>X</span></i></span><span> </span>– 進程失敗<span> [state=<span><i>Y</i></span>] </span></p> <p> <span> ·<span>???????? </span></span>丟失了仲裁程序節點<span><i><span>X</span></i></span><span> </span>– 進程退出<span> [state=<span><i>Y</i></span>] </span></p> <p> <span> ·<span>???????? </span></span>丟失了仲裁程序節點<span><i><span>X</span></i></span><span> &lt;error msg&gt; [state=<span><i>Y</i></span>] </span></p></td> </tr></table> **STATISTICS****事件** 下述事件具有統計特性。它們提供了相應的信息，如事務和其他操作的數目，低濃度節點發送或接收的數據量，以及內存使用率等。 <table border="1" cellpadding="0" id="table8"><tr><td> <p><strong> <span>事件</span></strong></p></td> <td> <p><strong> <span>優先級</span></strong></p></td> <td> <p><strong> <span>嚴重級別</span></strong></p></td> <td> <p><strong> <span>描述</span></strong></p></td> </tr><tr><td> <p>通報作業日程統計</p></td> <td> <p><span>9</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>平均的內部作業日程統計</p></td> </tr><tr><td> <p>發送的字節數</p></td> <td> <p><span>9</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>發送至節點<span><i><span>X</span></i></span>的平均字節數</p></td> </tr><tr><td> <p>接收的自己<span>#</span></p></td> <td> <p><span>9</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>從節點<span><i><span>X</span></i></span>接收的平均字節數</p></td> </tr><tr><td> <p>通報事務統計</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p> 事務數目，提交次數，讀取次數，簡單讀取次數，寫入次數，并發操作數目。屬性信息，以及放棄次數</p></td> </tr><tr><td> <p>通報操作</p></td> <td> <p><span>8</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>操作數目</p></td> </tr><tr><td> <p>通報表創建</p></td> <td> <p><span>7</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>內存使用</p></td> <td> <p><span>5</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>數據內存和索引內存的使用率（<span>80%</span>、<span>90%</span>和<span>100%</span>）</p></td> </tr></table> **ERROR****事件** 這些事件與簇錯誤和告警有關，如果出現1個或多個這類事件，表明出現了重大故障或失敗。 <table border="1" cellpadding="0" id="table9"><tr><td> <p><strong> <span>事件</span></strong></p></td> <td> <p><strong> <span>優先級</span></strong></p></td> <td> <p><strong> <span>嚴重級別</span></strong></p></td> <td> <p><strong> <span>描述</span></strong></p></td> </tr><tr><td> <p>因失去心跳而死亡</p></td> <td> <p><span>8</span></p></td> <td> <p><span>ALERT</span></p></td> <td> <p>因失去心跳而聲明節點<span><i><span>X</span></i></span>死亡。</p></td> </tr><tr><td> <p>傳輸器錯誤</p></td> <td> <p><span>2</span></p></td> <td> <p><span>ERROR</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>傳輸器告警</p></td> <td> <p><span>8</span></p></td> <td> <p><span>WARNING</span></p></td> <td> <p><span>?</span></p></td> </tr><tr><td> <p>失去心跳</p></td> <td> <p><span>8</span></p></td> <td> <p><span>WARNING</span></p></td> <td> <p>節點<span><i><span>X</span></i></span>失去心跳<span>#<span><i>Y</i></span></span></p></td> </tr><tr><td> <p>一般性告警事件</p></td> <td> <p><span>2</span></p></td> <td> <p><span>WARNING</span></p></td> <td> <p><span>?</span></p></td> </tr></table> **INFO****事件** 這些事件給出了關于簇狀態和簇維護活動的一般信息，如日志和心跳傳輸等。 <table border="1" cellpadding="0" id="table10"><tr><td> <p><strong> <span>事件</span></strong></p></td> <td> <p><strong> <span>優先級</span></strong></p></td> <td> <p><strong> <span>嚴重級別</span></strong></p></td> <td> <p><strong> <span>描述</span></strong></p></td> </tr><tr><td> <p>發出心跳</p></td> <td> <p><span>12</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>將心跳發送至節點<span><i><span>X</span></i></span></p></td> </tr><tr><td> <p>創建日志字節</p></td> <td> <p><span>11</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p>日志部分，日志文件，<span>MB</span></p></td> </tr><tr><td> <p>一般信息事件</p></td> <td> <p><span>2</span></p></td> <td> <p><span>INFO</span></p></td> <td> <p><span>?</span></p></td> </tr></table> ### 17.6.4.?單用戶模式 采用單用戶模式，數據庫管理員能夠將對數據庫系統的訪問限制在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.??? 重啟簇的數據節點。 *或* ·???????? 進入單用戶模式之前重啟數據庫。 ### 17.6.5.?MySQL簇的聯機備份 [ 17.6.5.1. 簇備份概念](#)[ 17.6.5.2. 使用管理服務器創建備份](#)[ 17.6.5.3. 如何恢復簇備份](#)[ 17.6.5.4. 簇備份的配置](#)[ 17.6.5.5. 備份故障診斷與排除](#) 在本節中，介紹了創建備份的方法，以及從備份恢復數據庫的方法。 #### 17.6.5.1.?簇備份概念 備份指的是在給定時間對數據庫的快照。備份包含三個主要部分： ·???????? ** 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.2.?使用管理服務器創建備份 開始備份前，請確保已為備份操作恰當地配置了簇。（請參見[17.6.5.4節，“簇備份的配置”](# "17.6.5.4.?Configuration for Cluster Backup")）。 使用管理服務器創建備份包含以下步驟： 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*的備份，管理服務器不會給出任何明確回應。但是，所發出的無效放棄命令將在簇日志中給出。 #### 17.6.5.3.?如何恢復簇備份 簇恢復程序是作為單獨的命令行實用工具**ndb_restore**實現的，它將讀取由備份創建的文件，并將保存的信息插入數據庫。必須為每組備份文件執行恢復程序，也就是說，執行次數與創建備份時運行的數據庫節點數相同。 首次執行恢復程序時，還需要恢復元數據。換句話講，必須重新創建數據庫表（注意，開始執行恢復操作時，簇中應有一個空數據庫）。恢復程序對于簇來說相當于API，因此，需要一個空閑連接，以便與簇相連。可使用**ndb_mgm**命令**SHOW**（在系統shell下使用**ndb_mgm -e SHOW即可**完成該操作）進行驗證。可以使用開關“-c *connectstring*”來確定MGM節點的位置。（關于連接字符串的更多信息，請參見[17.4.4.2節，“MySQL簇連接字符串``”](# "17.4.4.2.?The MySQL Cluster connectstring")。備份文件必須位于恢復程序參量給定的目錄下。 能夠使用與創建是所用配置不同的配置將備份恢復到數據庫。例如，對于備份ID為12的備份，該備份是在具有兩個數據庫節點（節點ID無惡2和3）的簇中創建的，可以將其恢復到具有4個節點的簇中。這樣，**ndb_restore**必須運行兩次，為創建備份時的每個數據庫節點運行一次。 **注釋：**對于快速恢復，能夠以并行方式恢復數據，但必須有足夠的可用簇連接。然而，數據文件必須始終前于日志文件。 #### 17.6.5.4.?簇備份的配置 有4個用于備份的基本配置參數： ·???????? BackupDataBufferSize 將數據寫入磁盤之前用于對數據進行緩沖處理的內存量。 ·???????? BackupLogBufferSize 將日志記錄寫入磁盤之前用于對其進行緩沖處理的內存量。 ·???????? BackupMemory 在數據庫節點中為備份分配的總內存。它應是分配給備份數據緩沖的內存和分配給備份日志緩沖的內存之和。 ·???????? BackupWriteSize 寫入磁盤的塊大小。它適用于備份數據緩沖和備份日志緩沖 關于這些參數的更多細節，請參見[17.4節，“MySQL簇的配置”](# "17.4.?MySQL Cluster Configuration")。 #### 17.6.5.5.?備份故障診斷與排除 如果在發出備份請求時返回了錯誤代碼，最可能的原因是內存不足，或磁盤空間不足。應檢查是否為備份分配了足夠的內存。此外，還應檢查在備份目標的硬盤分區上是否有足夠的空間。 NDB不支持重復的讀取操作，對于恢復進程，這類操作會導致問題。盡管備份進程“hot”，但從備份恢復MySQL簇并不是100％“hot”的進程。其原因在于，在恢復進程執行期間，正在運行的事務會從已恢復的數據中獲取不可重復的讀。這意味著，當恢復正在進行時，數據的狀態是不一致的。 ### 17.7.?使用與MySQL簇的高速互連 [ 17.7.1. 配置MySQL簇以使用SCI套接字](#)[ 17.7.2. 理解簇互連的影響](#) 即使在1996年開始NDB簇的設計之前，在創建并行數據庫的過程中遇到的一個主要問題顯然是網絡中節點之間的通信問題。正因為如此，從開始設計時，NDB簇就允許使用多種不同的數據傳輸機制。在本手冊中，我們使用了術語*傳輸器*。 目前，MySQL簇代碼庫包含對四種不同傳輸器的支持。目前的大多數用戶采用的是以太網上的TCP/IP，這是因為它無處不在。它也是迄今為止在MySQL簇中經過最佳測試的傳輸器。 我們正在努力，以確保與**ndbd**進程的通信是盡可能大的“組塊”，這是因為，它有利于所有的數據傳輸類型。 對于需要它的用戶，也能使用簇互聯以進一步增強性能。實現它的方式有兩種：或使用能處理該情況的定制傳輸器，或使用能繞過TCP/IP堆棧的套接字實施方案。我們使用由[Dolphin](http://www.dolphinics.com/)開發的SCI（規模可擴展的計算機連接接口）技術，對這兩類技術進行了試驗。 ### 17.7.1.?配置MySQL簇以使用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](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的網站](http://www.dolphinics.com/support/index.html)。 在我們的測試中，采用了交換器方式，但大多數大型簇安裝應用使用的是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傳輸連接”](# "17.4.4.10.?MySQL Cluster SCI Transport Connections")）。 **啟動簇** 該進程接下來的步驟是啟動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套接字的內核變體。 ### 17.7.2.?理解簇互連的影響 **ndbd**進程有很多簡單的結構，它們可用于訪問MySQL簇中的數據。我們創建了一個十分簡單的基準測試來檢查它們的性能，以及各種互聯方式對其性能的影響。 有四種訪問方法： ·???????? **主鍵訪問** 通過其主鍵簡單地訪問記錄。在最簡單的情況下，一次僅訪問一條記錄，這意味著該單一請求需負擔設置眾多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套接字的方法。 ### 17.8.?MySQL簇的已知限制 在本節中，我們列出了5.1.x系列中對MySQL簇的一些已知限制，并與使用MyISAM和InnoDB存儲引擎時可用的特性進行了比較。目前，尚不打算在即將推出的MySQL 5.1版本中處理這些問題，但是，我們將在后續的版本系列中，提供這方面的補丁和修正。如果你檢查了MySQL缺陷數據庫（[http://bugs.mysql.com](http://bugs.mysql.com)）中的“簇”類別，可發現我們打算在即將推出的MyAQL 5.1版中更正的已知缺陷（如果標記為“5.1”的話）。 （注釋：在本節末尾，列出了在當前版本中已解決的MySQL 5.0簇中的一些事宜）。 ·???????? **語法中的不兼容性**（運行已有的應用程序時導致錯誤）： o??????? 不支持文本索引。 o??????? 不支持Geometry數據類型（WKT和WKB）。 ·???????? **限制或行為中的不兼容性**（運行已有的應用程序時可能導致錯誤）： o??????? 沒有事務的部分回滾功能。重復鍵或類似錯誤會導致整個事務的回滾。 o??????? 存在很多可配置的硬限制，但能使用簇中的可用主內存設置限制。關于配置參數的完整清單，請參見[17.4.4節，“配置文件”](# "17.4.4.?Configuration File")。大多數配置參數可在線升級。這些硬限制包括： §???????? 數據庫內存大小和索引內存大小（分別是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節，“備份故障診斷與排除”](# "17.6.5.5.?Backup Troubleshooting")。 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](http://bugs.mysql.com/13070)）。 o??????? 不支持用于數據節點的多個網絡接口。如果使用了這類接口，很容易導致問題，原因在于，在出現某一數據節點失敗的情況下，SQL節點將等待以確認該數據節點是否出現問題，但由于該數據節點的另一路徑仍保持打開狀態，SQL節點永遠不會收到該確認信息。這會導致簇無法工作。 o??????? 數據節點的最大數目為48。 o??????? MySQL簇中總的最大節點數為63。在該數值中包括所有的MySQL服務器（SQL節點），數據節點和管理服務器。 考慮到本節開始時設定的條件，我們力圖使上面列出的信息盡可能完全。你可以將任何遇到的差異通報到MySQL缺陷數據庫，[http://bugs.mysql.com/](http://bugs.mysql.com/)。如果我們不打算在MySQL 5.1中更正該問題，我們會將其添加到列表中。 ### 17.9.?MySQL簇發展的重要歷程 [17.9.1. MySQL 5.0中的MySQL簇變化](#)[ 17.9.2. 關于MySQL簇的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發展歷程”](# "17.9.2.?MySQL 5.1 Development Roadmap for MySQL Cluster")）。 ### 17.9.1.?MySQL 5.0中的MySQL簇變化 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查詢高速緩沖”](# "5.13.?The MySQL Query Cache")。 ·???????? **新的優化**：有一個需要給予特別關注的優化，即，目前在某些查詢中使用了批式讀取接口。例如，考慮下述查詢： ~~~ ·??????????????? 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版中實現該增強特性。 ### 17.9.2.?關于MySQL簇的MySQL 5.1發展歷程 這里所介紹的內容是一份狀態報告，它基于最近提交到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以上的空間不會導致頁剩余部分的浪費。 ### 17.10.?MySQL簇常見問題解答 ·???????? *使用簇與使用復制的區別是什么？* 在復制設置中，主MySQL服務器負責更新1個或多個從服務器。事務按順序提交，較慢的事務會導致從服務器滯后于主服務器。這意味著，如果主服務器失敗，從服務器可能無法記錄最近的少數事務。如果使用了事務安全引擎，如InnoDB，要末是在從服務器上完成事務，要末是根本就不記錄事務，但復制不保證主服務器和從服務器上的所有數據在任何時候都是一致的。在MySQL簇中，所有的數據節點保持同步，任何一個數據節點提交的事務將被提交給所有的數據節點。當某一數據節點失敗時，所有剩余的數據節點仍能保持一致的狀態。 簡而言之，盡管標準的MySQL復制是異步的，但MySQL簇是同步的。 我們計劃在MySQL 5.1中為簇實現（異步）復制功能。包括在兩個簇之間，以及MySQL簇和非簇類MySQL服務器之間的復制能力。 * ·???????? 為了運行簇，我是否需要進行特殊的組網呢？（簇中的計算機是如何通信的？）* MySQL簇是為高帶寬環境下的使用而設計的，計算機通過TCP/IP相連。其性能直接取決于簇計算機之間的連接速度。對于簇，最低連接要求包括：典型的100MB以太網網絡或等效網絡。如果可能，建議使用GB以太網。 也支持更快的SCI 協議，但需要特殊硬件。關于SCI的更多信息，請參見[17.7節，“使用與MySQL簇的高速互連”](# "17.7.?Using High-Speed Interconnects with MySQL Cluster")。 ·???????? *運行簇需要多少臺計算機？為什么？* 要想運行可行的簇，最少需要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**”的含義是什么？* 它是“**N**etwork **D**ata**b**ase”（網絡數據庫）的縮寫。 ·???????? *哪些版本的MySQL軟件支持簇？我必須從源碼編譯嗎？* 在5.1系列的所有MySQL-max二進制版本中均支持簇，但下面介紹的除外。使用命令SHOW VARIABLES LIKE 'have_%';或SHOW ENGINES;，可檢查你的服務器是否支持NDB（更多信息，請參見[5.1.2節，“mysq**ld-max擴展My**SQL服務器”](# "5.1.2.?The mysqld-max Extended MySQL Server")）。 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](http://dev.mysql.com/downloads/mysql/5.1.html)。 * ·???????? 我需要多少RAM？是否能全部使用磁盤內存？* 在目前，簇是僅“內存中”的。這意味著所有的表數據（包括索引）均保存在RAM中。因此，如果你的數據占用了1GB的空間，而且打算在簇中將它復制1次，需要2GB的內存。還應加上操作系統以及在簇計算機上運行的應用程序所需的內存。 可以使用下述公司粗略估計簇中每個數據節點所需的RAM量： ~~~ (SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes ~~~ 要想更準確地計算內存需求量，需要為簇數據庫中的每個表確定每行所需的存儲空間（詳情請參見[11.5節，“列類型存儲需求”](# "11.5.?Column Type Storage Requirements")），然后乘以占行數。還必須對列索引進行計算，方式如下： 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中的空間擴展*](# "Chapter?19.?Spatial Extensions in MySQL")中介紹的空間擴展。 o??????? 僅支持對事務的完整回滾。不支持部分回滾以及回滾至保存點。 o??????? 每表允許的最大屬性數為128，而且屬性名稱不得超過31個字符。對于每個表，表和數據庫名稱的最大組合長度為122個字符。 o??????? 表行的最大大小為8KB，不包括BLOB。對于每表中的行數沒有限制，表的大小限制取決于多種因素，尤其是每個數據節點可用的RAM量。 o??????? NDB引擎不支持外鍵約束。就像MyISAM表一樣，這些約束將被忽略。 o??????? 不支持查詢高速緩沖功能。 關于簇限制的更多信息，請參見[17.8節，“MySQL簇的已知限制”](# "17.8.?Known Limitations of MySQL Cluster")。 * ·???????? 怎樣將已有的MySQL數據庫導入到簇中？* 可以將數據庫導入到MySQL簇中，就像用其他版本的MySQL那樣。除了前一問題所提到的限制外，僅有的特殊要求是，準備包含到簇中的任何表必須使用NDB存儲引擎。這意味著，表必須是用ENGINE=NDB或ENGINE=NDBCLUSTER創建的。使用ALTER TABLE，能夠將使用其他存儲引擎的現有表轉換為NDB簇表，但需要采取額外避規措施，詳情請參見[17.8節，“MySQL簇的已知限制”](# "17.8.?Known Limitations of MySQL Cluster")。 ·???????? *簇節點是怎樣彼此通信的？* 簇節點能夠通過下述三種協議中的任何一種進行通信：TCP/IP、SHM（共享內存）和SCI（規模可擴展的計算機連接接口）。在適用的場合，對于位于相同簇主機上的節點間通信，默認協議為SHM。SCI是高速（每秒1GB或更高）、高可用性協議，用于創建可擴展的多處理器系統，它需要特殊硬件和驅動。關于使用SCI作為簇中傳輸機制的更多信息，請參見[17.7節，“使用與MySQL簇的高速互連”](# "17.7.?Using High-Speed Interconnects with MySQL Cluster")。 ·???????? *什么是“**arbitrator**”（仲裁程序）*？ 如果簇中的1個或多個節點失敗，并非所有的簇節點均不能彼此“看到”，這是可能的。事實上，能夠在網絡分區中將兩個節點集合彼此隔離，也稱為“分裂大腦”。這類情形并不受歡迎，這是因為，每一個節點集合都試圖表現為代表整個簇。 當簇節點出現問題時，有兩種可能性。如果剩余節點的50％以上能夠彼此通信，那么這就是我們有時稱之為的“多數支配”情形，該節點集合將被視為簇。當節點數均等時，仲裁程序將介入：在該情形下，仲裁程序所屬的節點集合將被當作簇，不屬于該節點集合的節點將被關閉。 上述描述略為簡化，更完整的解釋需要考慮下面介紹的節點組： 當至少一個節點組中的所有節點均有效時，網絡分區不是問題，這是因為，簇中的任一個部分均不能構成1個功能性的簇。當沒有一個節點組的所有成員均是有效的時，問題產生，在該情況下，網絡分區（“分裂大腦”情形）成為可能。隨后就需要仲裁程序。所有的簇節點將相同的節點視為仲裁程序，通常是管理服務器。但是，也能將簇中的任何MySQL服務器配置為仲裁程序。仲裁程序接受第一個與其接觸的簇節點集合，并通知剩余的集合關閉。對于MySQL服務器和管理服務器節點，仲裁程序的選擇是由ArbitrationRank配置參數控制的（詳情請參見[17.4.4.4節，“定義MySQL簇管理服務器”](# "17.4.4.4.?Defining the MySQL Cluster Management Server")）。此外還應注意，仲裁程序不會對指定主機施加過多的要求，因此，仲裁程序主機不需要特別塊或擁有用于該目的的額外內存。 ·???????? *MySQL簇支持的列類型是什么？* MySQL簇支持所有通常的MySQL列類型，但與MySQL空間擴展有關的例外（請參見[第19章：](#)[*MySQL中的空間擴展*](# "Chapter?19.?Spatial Extensions in MySQL")）。此外，對于索引，當與NDB表一起使用時存在一些差別。**注釋：**MySQL簇表（即用ENGINE=NDBCLUSTER創建的表）僅有固定寬度列。這意味著（例如）含有VARCHAR(255)列的每一條記錄需要256字節來保存列，無論列中保存的數據大小是多少。在未來的MySQL版本中，計劃更正它。 關于這些方面的更多信息，請參見[17.8節，“MySQL簇的已知限制”](# "17.8.?Known Limitations of MySQL Cluster")。 * ·???????? 如何啟動和停止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.6.2.?Commands in the Management Client")和[17.3.6節，“安全關閉和重啟”](# "17.3.6.?Safe Shutdown and Restart")。 ·???????? *簇中有1個以上的管理節點是否有用？* 對于可靠性來說它確有幫助。在任何給定的時間，僅需1個MGM節點來控制簇，但能夠將1個MGM配置為主節點，并配置1個或多個額外的管理節點，以便在主MGM節點出現故障時取代它。 * ·???????? 在簇中能混合使用不同的硬件和操作系統嗎？* 是。只要所有的機器和操作系統均是相同的endian。也能在不同的節點上使用不同的MySQL簇版本，但是，我們建議僅應將其作為滾動升級的一部分使用。 * ·???????? 我能在單臺主機上運行兩個數據節點嗎？兩個SQL節點？* 是，能夠這樣。在有多個數據節點的情況下，每個節點必須使用不同的數據目錄。如果打算在一臺機器上運行多個SQL節點，那么每個**mysqld**實例必須使用不同的TCP/IP端口。 * ·???????? 我能與MySQL簇一起使用主機名嗎？* 是，對于簇主機，能夠使用DNS和DHCP。但是，如果你的應用程序要求“99.999％”的可用性，建議使用固定的IP地址。這是因為，依賴該服務的簇節點間的通信會引入額外的故障點，故障點越少越好。 ### 17.11.?MySQL簇術語表 下面給出的術語對理解MySQL簇有所幫助，而且在與MySQL簇一起使用時有一定的特殊含義。 ·???????? **簇：** 按照通常的理解，簇是一個計算機集合，其功能相當于1個單位，一起工作以完成單一任務。 **NDB****簇：** 這是MySQL中使用的存儲引擎，用于實現數據存儲、檢索、以及多個計算機間分布式管理。 **MySQL簇：** 指的是使用NDB存儲引擎一起工作的一組計算機，以便在使用“內存中”存儲的非共享體系結構中支持分布式MySQL數據庫。 ·???????? **配置文件：** 包含與簇、其主機和節點有關的指令和信息的文本文件。當簇啟動時，這類文件由簇的管理節點負責讀取。詳情請參見[17.4.4節，“配置文件”](# "17.4.4.?Configuration File")。 ·???????? **備份：** 所有簇數據、事務和日志的完整拷貝，保存在磁盤上或其他長期存儲介質上。 ·???????? **恢復：** 將簇返回以前的狀態，與保存在備份中的相同。 ·???????? **檢查點：** 從廣義上講，將數據保存到磁盤時，即達到了檢查點。具體對于簇來說，它是將所有已提交事務保存到磁盤的時間點。對于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套接字”](# "17.7.1.?Configuring MySQL Cluster to use SCI Sockets")。關于SCI的基本介紹，請參見[dolphinics.com上的文章。](http://www.dolphinics.com/corporate/scitech.html) o??????? SHM Unix風格共享內存（SHM）段。在任何支持的場合下，將自動使用SHM來連接運行在相同主機上的節點。要想了解這方面的更多信息，請參見[關于shmop(2)的Unix手冊頁](http://www.scit.wlv.ac.uk/cgi-bin/mansec?2+shmop)。 **注釋：**簇傳輸器是簇內部的。使用MySQL簇的應用程序與SQL節點進行通信，就像與其他版本的MySQL服務器進行通信一樣（通過TCP/IP、或使用Unix套接字、或Windows命名管道）。可以使用標準的MySQL API發出查詢并檢索結果。 ·???????? **NDB**： 它是網絡數據庫（**N**etwork **D**ata**b**ase）的縮寫，而且指的是用于啟用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簇中的進程管理”](# "17.5.?Process Management in MySQL Cluster")。 ·???????? **事件日志：** MySQL簇按照類別（啟動、停止、錯誤、檢查點等）、優先級和嚴重級別來記錄事件。關于所有可通報事件的完整列表，請參見[17.6.3節，“MySQL簇中生成的事件報告”](# "17.6.3.?Event Reports Generated in MySQL Cluster")。事件日志具有兩種類型： o??????? **簇日志：** 為作為整體的簇記錄所有所需的、值得記錄的事件。 o??????? **節點日志：** 為每個單獨節點保存的單獨日志。 在正常情況下，僅需保存和檢查簇日志，這通常已足夠。節點日志僅用于應用程序開發和調試目的。 ? 這是MySQL參考手冊的翻譯版本，關于MySQL參考手冊，請訪問[dev.mysql.com](http://dev.mysql.com/doc/mysql/en)。原始參考手冊為英文版，與英文版參考手冊相比，本翻譯版可能不是最新的。