MySQL叢集手冊

1. 叢集與普通MySQL伺服器差別

        與沒有使用叢集的MySQL相比，在MySQL叢集内操作資料的方式沒有太大的差別。執行這類操作時應記住兩點：

        1．表必須用ENGINE=NDB或ENGINE=NDBCLUSTER選項建立，或用ALTER TABLE選項更改，以使用NDB叢集存儲引擎在叢集内複制它們。如果使用mysqldump的輸出從已有資料庫導入表，可在文本編輯器中打開SQL腳本，并将該選項添加到任何表建立語句，或用這類選項之一替換任何已有的ENGINE（或TYPE）選項。

        2．每個NDB表必須有一個主鍵。如果在建立表時使用者未定義主鍵，NDB叢集存儲引擎将自動生成隐含的主鍵。

2. 直接連接配接的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、路由器等，進而減少了叢集的等待時間。注意，對于兩個以上的資料節點，要想充分利用這類直接連接配接的優點，需要為各資料節點建立與相同節點組内的其他資料節點間的直接連接配接。

3. MySQL叢集中的程序管理

3.1. 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"

        啟動ndbd時，它實際上将啟動兩種程序。第1種程序稱為“angel process”（天使程序），它的唯一任務是發現執行程序在何時完成，然後重新開機ndbd程序（如果作了該配置的話）。是以，如果你打算使用Unix的kill指令殺死ndbd程序，就需要殺死這兩個程序。中止ndbd程序的更恰當方法是使用管理用戶端，并通過該管理用戶端停止程序。

        執行程序采用了1個線程，用于讀取、寫入和掃描資料，以及所有其他任務。該線程是異步實施的，以便能友善地處理數以千計的并發活動。此外，看門狗線程負責監督執行線程，以確定執行線程不會陷入無限循環。線程池負責處理檔案I/O，每個線程均能處理一個打開的檔案。這些線程也能被ndbd程序中的傳輸器用作傳輸器連接配接。在執行包含更新在内的大量操作的系統中，如果允許，ndbd程序能占用2個CPU。對于擁有多CPU的機器，建議使用屬于不同節點組的數個ndbd程序。

3.2. ndb_mgmd，“管理伺服器”程序

        ndb_node_id_cluster.log是叢集事件日志檔案。這類事件的例子包括：檢查點操作的啟動和完成，節點啟動事件，節點故障，以及記憶體使用水準。

當叢集日志的大小達到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檔案。

4. 指令選項

4.1. ndbd指令選項

        -d, --daemon：通知ndbd作為daemon（端口監督程式）程序執行（預設行為）。

        --nodaemon：指明ndbd不得作為daemon（端口監督程式）程序啟動。調試ndbd以及希望将輸出重定向到螢幕時，它很有用。

        --initial：通知ndbd執行初始化啟動。初始化啟動将删除以前ndbd執行個體為恢複目的建立的任何檔案。它還能重新建立恢複用日志檔案。注意，在某些作業系統上，該程序可能會占用較長的時間。

        僅在首次啟動ndbd程序時才應使用—initial啟動，這是因為它将删除叢集檔案系統的所有檔案，并再次建立所有的REDO日志檔案。該規則的例外如下：

        l 執行那些會更改檔案内容的軟體更新時。

        l 用新的ndbd版本重新開機節點時。

        l 出于某種原因，節點重新開機或系統重新開機不斷失敗時的最後手段。在這類情形下，請注意，由于資料檔案的損壞，不能使用該節點來恢複資料。

4.2. ndb_mgmd的指令選項

        -d, --daemon：訓示ndb_mgmd作為端口監督程式啟動。這是預設行為。

         --nodaemon：訓示管理伺服器不作為端口監督程式啟動。

5. MySQL叢集的管理

5.1. “管理用戶端”中的指令

        除了中央配置檔案外，還能通過管理用戶端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節點之外的所有叢集節點，并退出。

5.2. 登記管理指令

        下述管理指令與叢集日志有關：

        CLUSTERLOG ON：打開叢集日志。

        CLUSTERLOG OFF：關閉叢集日志。

        CLUSTERLOG INFO：關于叢集日志設定的資訊。

        node_id CLUSTERLOG category=threshold：用小于或等于threshold的優先級将category事件記錄到叢集日志。

        CLUSTERLOG FILTER severity_level：将叢集事件日志切換為指定的severity_level。

        在下表中，介紹了叢集日志類别門檻值的預設設定（對于所有資料節點）。如果事件的優先級值低于或等于優先級門檻值，就會在叢集日志中記錄。

        注意，事件是按資料節點通報的，可在不同的節點上設定不同的門檻值。

類别	預設門檻值（所有資料節點）
STARTUP	7
SHUTDOWN	7
STATISTICS	7
CHECKPOINT	7
NODERESTART	7
CONNECTION	7
ERROR	15
INFO	7

        門檻值用于過濾每種類别中的事件。例如，對于優先級為3的STARTUP事件，不會将其記錄到日志中，除非将STARTUP的門檻值更改為3或更小。如果門檻值為3，僅發送優先級等于或小于3的事件。

        下面給出了事件的嚴重級别（注釋：它們與Unix的syslog級别對應；但LOG_EMERG和LOG_NOTICE除外，未使用或未映射它們）：

1	ALERT	應立刻更正的狀況，如損壞的系統資料庫。
2	CRITICAL	臨界狀況，如裝置錯誤或資源不足。
3	ERROR	應予以更正的狀況，如配置錯誤等。
4	WARNING	不能稱其為錯誤的狀況，但仍需要特别處理。
5	INFO	通報性消息。
6	DEBUG	調試消息，用于NDB叢集開發。

        可以打開或關閉事件嚴重級别。如果打開了事件嚴重級别，那麼優先級等于或低于類别門檻值的事件均将被記錄。如果關閉了事件嚴重級别，那麼将不記錄屬于該嚴重級别的任何事件。

6. 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。

7. 單使用者模式

        采用單使用者模式，資料庫管理者能夠将對資料庫系統的通路限制在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.    重新開機叢集的資料節點。

        或進入單使用者模式之前重新開機資料庫。

8. 叢集備份概念

        備份指的是在給定時間對資料庫的快照。備份包含三個主要部分：

        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。

9. 使用管理伺服器建立備份

        使用管理伺服器建立備份包含以下步驟：

        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的備份，管理伺服器不會給出任何明确回應。但是，所發出的無效放棄指令将在叢集日志中給出。

10. 如何恢複叢集備份

        叢集恢複程式是作為單獨的指令行實用工具ndb_restore實作的，它将讀取由備份建立的檔案，并将儲存的資訊插入資料庫。必須為每組備份檔案執行恢複程式，也就是說，執行次數與建立備份時運作的資料庫節點數相同。

        首次執行恢複程式時，還需要恢複中繼資料。換句話講，必須重新建立資料庫表（注意，開始執行恢複操作時，叢集中應有一個空資料庫）。恢複程式對于叢集來說相當于API，是以，需要一個空閑連接配接，以便與叢集相連。可使用ndb_mgm指令SHOW（在系統shell下使用ndb_mgm -e SHOW即可完成該操作）進行驗證。可以使用開關“-cconnectstring”來确定MGM節點的位置。備份檔案必須位于恢複程式參量給定的目錄下。

        能夠使用與建立是所用配置不同的配置将備份恢複到資料庫。例如，對于備份ID為12的備份，該備份是在具有兩個資料庫節點（節點ID無惡2和3）的叢集中建立的，可以将其恢複到具有4個節點的叢集中。這樣，ndb_restore必須運作兩次，為建立備份時的每個資料庫節點運作一次。

        注釋：對于快速恢複，能夠以并行方式恢複資料，但必須有足夠的可用叢集連接配接。然而，資料檔案必須始終前于日志檔案。

11. 叢集備份的配置

        有4個用于備份的基本配置參數：

        BackupDataBufferSize：将資料寫入磁盤之前用于對資料進行緩沖處理的記憶體量。

        BackupLogBufferSize：将日志記錄寫入磁盤之前用于對其進行緩沖處理的記憶體量。

        BackupMemory：在資料庫節點中為備份配置設定的總記憶體。它應是配置設定給備份資料緩沖的記憶體和配置設定給備份日志緩沖的記憶體之和。

        BackupWriteSize：寫入磁盤的塊大小。它适用于備份資料緩沖和備份日志緩沖

12. 備份故障診斷與排除

        如果在發出備份請求時傳回了錯誤代碼，最可能的原因是記憶體不足，或磁盤空間不足。應檢查是否為備份配置設定了足夠的記憶體。此外，還應檢查在備份目标的硬碟分區上是否有足夠的空間。

         限制或行為中的不相容性（運作已有的應用程式時可能導緻錯誤）：

        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中那樣。

        僅與MySQL叢集有關的事宜（與MyISAM或InnoDB無關）：

        o        不能像使用ALTER TABLE或CREATE INDEX完成的那樣執行線上方案更改，這是因為NDB叢集不支援這類變更的自動檢測（但是，能夠導入或建立使用不同存儲引擎的表，然後使用“ALTER TABLE tbl_nameENGINE=NDBCLUSTER;”将其轉換為NDB。在這類情況下，需要發出FLUSH TABLES指令，強制叢集發現變化）。

        o        不能線上增加或舍棄節點（此時必須重新開機叢集）。

        o        使用多個管理伺服器時：

        §         必須在連接配接字元串中明确為節點指定ID，這是因為，在多個管理伺服器上，自動配置設定的節點ID不能正常工作。

        §         必須十分小心，確定所有的管理伺服器具有相同的配置。叢集對此方面不進行任何特殊檢查，

        §         要想使管理節點能發現彼此的存在，建立了叢集後必須重新開機所有的資料節點

        o        不支援用于資料節點的多個網絡接口。如果使用了這類接口，很容易導緻問題，原因在于，在出現某一資料節點失敗的情況下，SQL節點将等待以确認該資料節點是否出現問題，但由于該資料節點的另一路徑仍保持打開狀态，SQL節點永遠不會收到該确認資訊。這會導緻叢集無法工作。

        o        資料節點的最大數目為48。

        o        MySQL叢集中總的最大節點數為63。在該數值中包括所有的MySQL伺服器（SQL節點），資料節點和管理伺服器。

13. MySQL叢集常見問題解答

13.1. 使用叢集與使用複制的差別是什麼？

        在複制設定中，主MySQL伺服器負責更新1個或多個從伺服器。事務按順序送出，較慢的事務會導緻從伺服器滞後于主伺服器。這意味着，如果主伺服器失敗，從伺服器可能無法記錄最近的少數事務。如果使用了事務安全引擎，如InnoDB，要末是在從伺服器上完成事務，要末是根本就不記錄事務，但複制不保證主伺服器和從伺服器上的所有資料在任何時候都是一緻的。在MySQL叢集中，所有的資料節點保持同步，任何一個資料節點送出的事務将被送出給所有的資料節點。當某一資料節點失敗時，所有剩餘的資料節點仍能保持一緻的狀态。

        簡而言之，盡管标準的MySQL複制是異步的，但MySQL叢集是同步的。

        我們計劃在MySQL 5.1中為叢集實作（異步）複制功能。包括在兩個叢集之間，以及MySQL叢集和非叢集類MySQL伺服器之間的複制能力。

13.2. 為了運作叢集，我是否需要進行特殊的組網呢？（叢集中的計算機是如何通信的？）

        MySQL叢集是為高帶寬環境下的使用而設計的，計算機通過TCP/IP相連。其性能直接取決于叢集計算機之間的連接配接速度。對于叢集，最低連接配接要求包括：典型的100MB以太網網絡或等效網絡。如果可能，建議使用GB以太網。

        也支援更快的SCI 協定，但需要特殊硬體。關于SCI的更多資訊，

13.3. 運作叢集需要多少台計算機？為什麼？

        要想運作可行的叢集，最少需要3台計算機。但在MySQL叢集中，推薦的最低計算機數目為4：1台負責運作管理節點，1台負責運作SQL節點，2台用作存儲節點。使用2個資料節點的目的是為了提供備援性，管理節點必須運作在單獨的機器上，這樣，當1個資料節點失敗時，仍能保證連續的仲裁服務。

13.4. 運作MySQL叢集的硬體要求是什麼？

        在叢集運作的任何平台上，應具有具備NDB功能的二進制檔案。顯而易見，更快的CPU和更多的記憶體能夠改善性能，64位CPU的效率很可能高于32位處理器。在用于資料節點的機器上必須有足夠的記憶體，以便容納各節點共享的資料庫部分。（更多資訊，請參見我需要多少記憶體？）。節點能通過标準的TCP/IP網絡和硬體進行通信。對于SCI支援，需要特殊的組網硬體。

13.5. 由于MySQL叢集使用了TCP/IP，這是否意味着我能在Internet上運作1個或多個節點位于遠端位置的叢集？

        在MySQL叢集中，節點間的通信并不安全，這點極其重要，這類通信未加密，也未采用任何防護機制。對于叢集，最安全的配置是位于防火牆後的專用網絡，不能從外部直接通路任何叢集資料或管理節點（對于SQL節點，應采取相同的防護措施，就像在MySQL伺服器的其他執行個體中那樣）。

        無論是任何情況，在這類條件下叢集的可靠運作十分令人懷疑，這是因為設計和實施MySQL叢集時，假定它運作在能保證專用高速連通性的條件下，如使用100MB或GB以太網的LAN中（更傾向于後者）。對于低于該要求的任何環境，我們未作任何測試，也不保證其性能。

13.6. 使用叢集時，如何了解錯誤或警告消息的含義呢？

        有兩種完成它的方式：

        1．出現錯誤或告警狀況時，在MySQL螢幕内，立刻使用SHOW ERRORS或SHOW WARNINGS。也能在MySQL Query Browser（查詢浏覽器）中顯示它們。

        2．在系統shell提示符下，使用perror --ndb error_code。

13.7. MySQL叢集是事務安全的嗎？支援什麼隔離級别？

        是。對于用NDB存儲引擎建立的表，支援事務。在MySQL 5.1中，叢集僅支援READ_COMMITTED事務隔離級别。

13.8. 叢集支援的表類型是什麼？

        NDB是僅有的支援叢集功能的MySQL存儲引擎。（能夠使用其他存儲引擎在用于叢集的MySQL伺服器上建立表，如MyISAM或InnoDB，但這類非NDB表不在叢集中）。

13.9. 哪些版本的MySQL軟體支援叢集？我必須從源碼編譯嗎？

        在5.1系列的所有MySQL-max二進制版本中均支援叢集，但下面介紹的除外。使用指令SHOW VARIABLES LIKE 'have_%';或SHOW ENGINES;，可檢查你的伺服器是否支援NDB

13.10. 我需要多少RAM？是否能全部使用磁盤記憶體？

        在目前，叢集是僅“記憶體中”的。這意味着所有的表資料（包括索引）均儲存在RAM中。是以，如果你的資料占用了1GB的空間，而且打算在叢集中将它複制1次，需要2GB的記憶體。還應加上作業系統以及在叢集計算機上運作的應用程式所需的記憶體。

        可以使用下述公司粗略估計叢集中每個資料節點所需的RAM量：

        (SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes

        要想更準确地計算記憶體需求量，需要為叢集資料庫中的每個表确定每行所需的存儲空間（詳情請參見11.5節，“列類型存儲需求”），然後乘以占行數。還必須對列索引進行計算，方式如下：

        o對于為NDB叢集表建立的每個主鍵索引或哈希索引，每記錄需要21-25位元組。這類索引使用IndexMemory（索引記憶體）。

        o每個有序索引每記錄需要10位元組的存儲空間，使用DataMemory（資料記憶體）。

        o建立主鍵或唯一索引時，還會建立1個有序索引，除非該索引是使用USING HASH建立的。換句話講，如果未使用USING HASH建立它們，對于叢集表上的每個鍵多因或唯一索引，在MySQL 5.1中，每記錄占用31-35位元組。

        注意，使用USING HASH為所有主鍵和唯一索引建立MySQL叢集表時，通常還能使表的更新速度更快。這是因為，它需要較少的記憶體（因未建立有序索引），對CPU的占用也較低（僅需讀取或更新較少的索引）。

        所有的MySQL叢集表必須有主鍵，這點極其重要。如果未定義，NDB存儲引擎将自動建立主鍵，而且該主鍵是在未使用USING HASH的條件下建立的。

很難準确确定叢集索引在任何給定時間用于存儲的記憶體量，但是，當可用DataMemory和/或IndexMemory的使用率到達80％時，會将警告消息寫入叢集日志，到達80％、90％等時，也會寫入叢集日志。

        我們經常遇到使用者通報的下述問題，當他們視圖填充叢集資料庫時，加載程序提前終止，并顯示下述錯誤消息：

        錯誤1114：表'my_cluster_table'已滿。

        出現該情況時，很可能是因為在你的設定中未為所有的表資料和索引提供足夠的RAM，包括NDB存儲引擎所需的主鍵，以及表定義中不包含主鍵定義時自動建立的主鍵。

        此外還應注意，所有的資料節點應具有相同的RAM量，這是因為，叢集中任何資料節點所能使用的記憶體均不超過任意單獨資料節點的最低可用記憶體。換句話講，如果有三台運作叢集資料節點的計算機，在其中兩台計算機上，有3GB用于儲存叢集資料的RAM，另一台計算機隻有1GB RAM，那麼每個資料節點僅能為叢集貢獻1GB。

13.11. 出現災難性故障時，例如整個城市斷電而且我的UPS也出現故障，我會丢失所有的資料嗎？

        所有已送出的事務将被記錄。是以，在出現災難的情況下，某些資料可能會丢失，但相當有限。通過減少每事務的操作數，能夠進一步減少資料損失（在任何情形下，在每事務上執行大量操作都不是一個好主意）。

13.12. 我能在一台計算機上運作多個節點嗎？

        可以，但不建議這樣。運作叢集的主要原因之一是提供備援，為了獲得備援性的全部優點，每個節點應位于單獨的計算機上。如果将多個節點置于同一台機器，當該機器出現故障時，所有節點均将丢失。考慮到MySQL叢集能運作在常見的硬體上并利用廉價的作業系統（或不需費用），為了確定任務關鍵型資料的安全，值得為額外的機器戶花費開銷。此外還須注意，對運作管理節點的叢集主機的要求最低，使用200 MHz Pentium CPU，作業系統所需的足夠RAM，以及用于ndb_mgmd和ndb_mgm程序的少量開銷，就能完成該任務。

13.13. 我能在不重新開機的情況下為叢集增加節點嗎？

        目前不行。對于在叢集中添加新的MGM或SQL節點來說，簡單的重新開機就是所需的一切。添加資料節點時，程序略微複雜些，需要采取下述步驟：

        o對所有叢集資料進行完整備份。

        o徹底關閉叢集和所有的叢集節點程序。

        o使用“—initial”啟動選項重新開機叢集。

   o從備份中恢複所有叢集資料。

        在未來的MySQL叢集版本中，我們希望為MySQL叢集實作“熱”重配置功能，以便能夠将添加新節點時重新開機叢集的要求降至最低（如果不能消除的話）。

13.14. 使用叢集時有需要我了解的限制嗎？

        MySQL中的NDB表服從下述限制：

        o并非所有的字元集和校對均被支援。

        o不支援FULLTEXT索引和字首索引。隻能為完整的列設定索引。不支援第19章：MySQL中的空間擴充中介紹的空間擴充。

        o僅支援對事務的完整復原。不支援部分復原以及復原至儲存點。

        o每表允許的最大屬性數為128，而且屬性名稱不得超過31個字元。對于每個表，表和資料庫名稱的最大組合長度為122個字元。

        o表行的最大大小為8KB，不包括BLOB。對于每表中的行數沒有限制，表的大小限制取決于多種因素，尤其是每個資料節點可用的RAM量。

        oNDB引擎不支援外鍵限制。就像MyISAM表一樣，這些限制将被忽略。

        o不支援查詢高速緩沖功能。

13.15. MySQL叢集支援的列類型是什麼？

        MySQL叢集支援所有通常的MySQL列類型，但與MySQL空間擴充有關的例外（請參見第19章：MySQL中的空間擴充）。此外，對于索引，當與NDB表一起使用時存在一些差别。注釋：MySQL叢集表（即用ENGINE=NDBCLUSTER建立的表）僅有固定寬度列。這意味着（例如）含有VARCHAR(255)列的每一條記錄需要256位元組來儲存列，無論列中儲存的資料大小是多少。在未來的MySQL版本中，計劃更正它。

13.16. 當叢集關閉時，會對叢集資料有什麼影響？

        由叢集資料節點儲存在記憶體中的資料将被寫入磁盤，并在下一次啟動叢集時重新裝入記憶體。

        要想關閉叢集，請在MGM節點所在的機器上、在shell下輸入下述指令：

        shell> ndb_mgm -e shutdown

        這樣就能恰當地中止ndb_mgm、ndb_mgm、以及任何ndbd程序。對于用作叢集SQL節點的MySQL伺服器，可使用mysqladmin shutdown停止它。

13.17. 在叢集中能混合使用不同的硬體和作業系統嗎？

        是。隻要所有的機器和作業系統均是相同的endian。也能在不同的節點上使用不同的MySQL叢集版本，但是，我們建議僅應将其作為滾動更新的一部分使用。

13.18. 我能在單台主機上運作兩個資料節點嗎？兩個SQL節點？

        是，能夠這樣。在有多個資料節點的情況下，每個節點必須使用不同的資料目錄。如果打算在一台機器上運作多個SQL節點，那麼每個mysqld執行個體必須使用不同的TCP/IP端口。

轉自：

http://dev.mysql.com/doc/refman/5.1/zh/ndbcluster.html