標準 MySQL 伺服器版本不支援 NDB Cluster。相反地，MySQL NDB Cluster 是作為獨立產品提供的。可用的 NDB Cluster 發行系列包括以下

您可以從原始碼取得並編譯 NDB Cluster（請參閱第 25.3.1.4 節，「在 Linux 上從原始碼建置 NDB Cluster」和第 25.3.2.2 節，「在 Windows 上從原始碼編譯和安裝 NDB Cluster」），但對於所有除了最特殊的情況外，我們建議使用 Oracle 提供的以下其中一種適用於您的作業平台和情況的安裝程式。

安裝套件也可能可以從您平台的套件管理系統取得。

您可以使用 SHOW VARIABLES LIKE 'have_%'、SHOW ENGINES 或 SHOW PLUGINS 其中一個陳述式，來判斷您的 MySQL Server 是否有 NDB 支援。

“NDB” 代表 “Network Database”。NDB 和 NDBCLUSTER 都是用於啟用 MySQL 叢集支援的儲存引擎的名稱。NDB 是首選名稱，但這兩個名稱都是正確的。

在傳統的 MySQL 複寫中，來源 MySQL 伺服器會更新一個或多個複本。交易會依序提交，而速度慢的交易可能會導致複本落後於來源。這表示如果來源失敗，複本可能沒有記錄最後幾筆交易。如果正在使用諸如 InnoDB 之類的交易安全引擎，則交易會在複本上完成或完全不套用，但複寫無法保證來源和複本上的所有資料在所有時間都保持一致。在 NDB Cluster 中，所有資料節點都會保持同步，而且任何一個資料節點提交的交易都會提交給所有資料節點。如果資料節點發生故障，所有剩餘的資料節點都會保持一致的狀態。

簡而言之，標準 MySQL 複寫是非同步的，而 NDB Cluster 是同步的。

非同步複寫也適用於 NDB Cluster。NDB Cluster 複寫（有時也稱為 “異地複寫”）包括在兩個 NDB Cluster 之間複寫以及從 NDB Cluster 複寫到非叢集 MySQL 伺服器的功能。請參閱第 25.7 節，「NDB Cluster 複寫」。

NDB Cluster 旨在用於高頻寬環境，電腦使用 TCP/IP 連線。其效能直接取決於叢集電腦之間的連線速度。NDB Cluster 的最低連線需求包括典型的 100 百萬位元乙太網路或同等網路。我們建議您盡可能使用千兆乙太網路。

執行可運作的叢集至少需要三台電腦。但是，NDB Cluster 中最建議的電腦數量為四台：一台用於執行管理和 SQL 節點，兩台電腦用作資料節點。兩個資料節點的目的是提供備援；管理節點必須在不同的機器上執行，以保證在其中一個資料節點發生故障時能繼續提供仲裁服務。

為了提供更高的輸送量和高可用性，您應使用多個 SQL 節點（連線到叢集的 MySQL Server）。也可以（儘管不是絕對必要）執行多個管理伺服器。

NDB Cluster 具有實體和邏輯組織，電腦是實體元素。叢集的邏輯或功能元素稱為節點，而容納叢集節點的電腦有時稱為叢集主機。有三種類型的節點，每個節點都對應於叢集中的特定角色。這些是

最簡單的答案是：“這不是您可以控制的，而且無論如何您都不需要擔心，除非您是編寫或分析 NDB Cluster 原始碼的軟體工程師”。

如果您覺得這個答案不夠滿意，這裡有一個更長且更技術性的版本

NDB Cluster 中的一些機制需要在資料節點之間進行分散式協調。這些分散式演算法和協定包括全域檢查點、DDL（結構描述）變更和節點重新啟動處理。為了簡化此協調，資料節點會 “選出” 其中一個作為領導者。沒有使用者可操作的機制來影響此選取，此選取是完全自動的；事實上，它是自動的，這是 NDB Cluster 內部架構的關鍵部分。

當節點充當任何這些機制的 “領導者” 時，它通常是活動的協調點，而其他節點充當 “追隨者”，依照領導者的指示執行其活動部分。如果充當領導者的節點失敗，則其餘節點會選出新的領導者。正在進行中且由舊領導者協調的任務可能會失敗或由新領導者繼續執行，具體取決於所涉及的實際機制。

這些不同的機制和協定有可能會有不同的領導者節點，但通常會為所有機制和協定選取相同的領導者。在管理用戶端中 SHOW 的輸出中指示為領導者的節點在內部稱為 DICT 管理員，負責協調 DDL 和中繼資料活動。

NDB叢集在設計上，選擇領導者本身不會對叢集外部產生明顯的影響。例如，目前的領導者不會比其他資料節點有明顯更高的 CPU 或資源使用率，而且領導者發生故障對於叢集的影響，不應該與任何其他資料節點故障的影響有顯著差異。

NDB 叢集支援大多數類 Unix 作業系統。NDB 叢集也支援在 Microsoft Windows 作業系統上的生產環境中使用。

關於 NDB 叢集在各種作業系統版本、作業系統發行版本和硬體平台上所提供的支援程度的更多詳細資訊，請參閱 https://mysql.dev.org.tw/support/supportedplatforms/cluster.html。

NDB 叢集應可在任何有 NDB 啟用二進制檔的平台上執行。對於資料節點和 API 節點，更快的 CPU 和更多的記憶體可能會提高效能，而 64 位元 CPU 可能比 32 位元處理器更有效。用於資料節點的機器必須有足夠的記憶體來保存每個節點的資料庫共享（更多資訊請參閱我需要多少 RAM？）。對於僅用於執行 NDB 叢集管理伺服器的電腦，需求很低；一般的桌上型電腦（或同等規格）通常足以勝任此任務。節點可以透過標準 TCP/IP 網路和硬體進行通訊。它們也可以使用高速 SCI 協定；但是，需要特殊的網路硬體和軟體才能使用 SCI（請參閱第 25.4.4 節，"在 NDB 叢集中使用高速互連"）。

NDB 叢集最初是作為純記憶體實作的，但目前所有可用的版本也提供了將 NDB 叢集儲存在磁碟上的能力。有關更多資訊，請參閱第 25.6.11 節，“NDB 叢集磁碟資料表”。

對於記憶體中的 NDB 資料表，您可以使用以下公式來粗略估算叢集中每個資料節點所需的 RAM 量

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

要更精確地計算記憶體需求，需要確定叢集資料庫中每個資料表的每列所需的儲存空間（詳細資訊請參閱第 13.7 節，“資料類型儲存需求”），並將其乘以列數。您還必須記住考慮任何欄索引，如下所示

為所有主鍵和唯一索引使用 USING HASH 建立 NDB 叢集資料表，通常會使資料表更新執行得更快 - 在某些情況下，比在建立主鍵和唯一鍵時未使用 USING HASH 的資料表更新快 20% 到 30%。這是因為需要較少的記憶體（因為沒有建立排序索引），並且必須使用較少的 CPU（因為必須讀取和可能更新的索引較少）。但是，這也意味著原本可以使用範圍掃描的查詢必須通過其他方式滿足，這可能會導致選擇速度較慢。

在計算叢集記憶體需求時，您可能會發現最近的 MySQL 8.4 版本中提供的 ndb_size.pl 工具很有用。此 Perl 腳本會連線到目前的（非叢集）MySQL 資料庫，並產生一份報告，說明如果該資料庫使用 NDBCLUSTER 儲存引擎，需要多少空間。有關更多資訊，請參閱第 25.5.29 節，“ndb_size.pl — NDBCLUSTER 大小需求估算器”。

特別重要的是要記住，每個 NDB 叢集資料表都必須有一個主鍵。NDB 儲存引擎會在沒有定義主鍵的情況下自動建立主鍵；此主鍵的建立未使用 USING HASH。

您可以使用 ndb_mgm 用戶端中的 REPORT MEMORYUSAGE 命令，隨時確定 NDB 叢集資料和索引的儲存使用多少記憶體；有關更多資訊，請參閱第 25.6.1 節，“NDB 叢集管理用戶端中的命令”。此外，當可用的 DataMemory 或（在 NDB 7.6 之前）IndexMemory 使用率達到 80% 時，以及當使用率達到 90%、99% 和 100% 時，叢集記錄檔中會寫入警告。

一般來說，主機作業系統原生的任何檔案系統都應能與 NDB 叢集良好搭配使用。如果您發現某個檔案系統與 NDB 叢集搭配使用特別好（或不是特別好），我們邀請您在 NDB 叢集論壇 中討論您的發現。

對於 Windows，我們建議您將 NTFS 檔案系統用於 NDB 叢集，就像我們對標準 MySQL 所做的一樣。我們不使用 FAT 或 VFAT 檔案系統測試 NDB 叢集。因此，我們不建議將它們用於 MySQL 或 NDB 叢集。

NDB 叢集實作為無共享解決方案；其背後的想法是單一硬體故障不應導致多個叢集節點故障，甚至可能導致整個叢集故障。因此，不支援將網路共用或網路檔案系統用於 NDB 叢集。這也適用於共用儲存裝置，例如 SAN。

支援在虛擬機器中使用 NDB 叢集。我們目前支援並測試使用 Oracle VM。

某些 NDB 叢集使用者已成功使用其他虛擬化產品部署 NDB 叢集；在這種情況下，Oracle 可以提供 NDB 叢集支援，但虛擬環境特有的問題必須轉給該產品的供應商。

原因很可能是您的設定沒有為所有資料表資料和所有索引提供足夠的 RAM，包括 NDB 儲存引擎所需的主鍵，並且在資料表定義未包含主鍵定義的情況下自動建立。

同樣值得注意的是，所有資料節點都應具有相同的 RAM 容量，因為叢集中沒有任何資料節點可以使用比任何個別資料節點可用的最小容量更多的記憶體。例如，如果有四台電腦託管叢集資料節點，其中三台有 3GB 的 RAM 可用來儲存叢集資料，而其餘的資料節點只有 1GB RAM，則每個資料節點最多只能將 1GB 用於 NDB 叢集資料和索引。

在某些情況下，即使 ndb_mgm -e "ALL REPORT MEMORYUSAGE" 顯示大量可用的 DataMemory，在 MySQL 用戶端應用程式中也可能會遇到 資料表已滿 錯誤。您可以使用 CREATE TABLE 的 MAX_ROWS 選項，強制 NDB 為 NDB 叢集資料表建立額外的分割區，從而為雜湊索引提供更多可用記憶體。一般來說，將 MAX_ROWS 設定為您預期儲存在資料表中列數的兩倍就足夠了。

由於類似的原因，您有時也會在資料負載量大的節點上遇到資料節點重新啟動的問題。MinFreePct 參數可以幫助解決此問題，方法是保留一部分（預設為 5%）的 DataMemory 和（在 NDB 7.6 之前）IndexMemory 以用於重新啟動。此保留的記憶體無法用於儲存 NDB 資料表或資料。

在這種情況下，叢集不太可能可靠地執行，因為 NDB 叢集的設計和實作都假設它會在保證專用高速連線的條件下執行，例如在 LAN 環境中使用 100 Mbps 或 gigabit 乙太網路 - 最好是後者。我們既不測試也不保證在比這更慢的任何情況下的效能。

此外，非常重要的是要記住，NDB叢集中的節點之間的通訊並非安全；它們既未加密，也沒有任何其他保護機制加以保護。叢集最安全的配置是在防火牆後的私有網路中，外部無法直接存取任何叢集資料或管理節點。（對於 SQL 節點，您應採取與任何其他 MySQL 伺服器實例相同的預防措施。）有關更多資訊，請參閱第 25.6.21 節，「NDB 叢集安全問題」。

否。雖然某些特殊的指令用於管理和配置叢集本身，但下列操作只需要標準的 (My)SQL 陳述式

設定 NDB 叢集需要一些特殊的配置參數和檔案 — 有關這些資訊，請參閱第 25.4.3 節，「NDB 叢集配置檔案」。

在 NDB 叢集管理用戶端（ndb_mgm）中使用一些簡單的指令來執行啟動和停止叢集節點等任務。請參閱第 25.6.1 節，「NDB 叢集管理用戶端中的指令」。

NDB 叢集支援與標準 MySQL 伺服器相同的程式設計 API 和語言，包括 ODBC、.Net、MySQL C API，以及許多用於熱門腳本語言（例如 PHP、Perl 和 Python）的驅動程式。使用這些 API 編寫的 NDB 叢集應用程式的行為與其他 MySQL 應用程式類似；它們將 SQL 陳述式傳輸到 MySQL 伺服器（在 NDB 叢集中，則為 SQL 節點），並接收包含資料列的回應。有關這些 API 的更多資訊，請參閱第 31 章，連接器和 API。

NDB 叢集也支援使用 NDB API 進行應用程式程式設計，它提供與 NDB 叢集資料的低層級 C++ 介面，而無需通過 MySQL 伺服器。請參閱NDB API。此外，許多 NDBCLUSTER 管理功能都由 C 語言 MGM API 公開；有關更多資訊，請參閱MGM API。

NDB 叢集還支援使用 ClusterJ 進行 Java 應用程式程式設計，它使用會期和交易來支援資料的網域物件模型。有關更多資訊，請參閱Java 和 NDB 叢集。

NDB 叢集 8.0 還包含支援針對 Node.js 編寫的 NoSQL 應用程式的配接器，並將 NDB 叢集作為資料儲存區。有關更多資訊，請參閱適用於 JavaScript 的 MySQL NoSQL 連接器。

NDB 叢集包含一個命令列用戶端，用於執行基本管理功能。請參閱第 25.5.5 節，「ndb_mgm — NDB 叢集管理用戶端」和第 25.6.1 節，「NDB 叢集管理用戶端中的指令」。

MySQL 叢集管理員也支援 NDB 叢集，這是一個單獨的產品，提供進階命令列介面，可以自動執行許多 NDB 叢集管理任務，例如滾動重新啟動和配置變更。有關 MySQL 叢集管理員的更多資訊，請參閱MySQL 叢集管理員 8.4.1 使用者手冊。

有兩種方法可以做到這一點

是。對於使用 NDB 儲存引擎建立的表格，支援交易。目前，NDB 叢集僅支援 READ COMMITTED 交易隔離等級。

NDB 叢集需要 NDB 儲存引擎。也就是說，為了使表格在 NDB 叢集中的節點之間共享，必須使用 ENGINE=NDB（或等效選項 ENGINE=NDBCLUSTER）建立表格。

可以使用其他儲存引擎（例如 InnoDB 或 MyISAM）在與 NDB 叢集一起使用的 MySQL 伺服器上建立表格，但由於這些表格不使用 NDB，因此它們不參與叢集；每個此類表格都嚴格本地化於建立它的個別 MySQL 伺服器實例。

NDB 叢集在架構、需求和實作方面與 InnoDB 叢集完全不同；儘管它們的名稱有任何相似之處，但兩者並不相容。有關 InnoDB 叢集的更多資訊，請參閱MySQL AdminAPI。另請參閱第 25.2.6 節，「使用 InnoDB 的 MySQL 伺服器與 NDB 叢集的比較」，以了解有關 NDB 和 InnoDB 儲存引擎之間差異的資訊。

所有已提交的交易都會記錄下來。因此，儘管在發生災難時可能會遺失某些資料，但此遺失應相當有限。透過盡量減少每次交易的操作次數，可以進一步減少資料遺失。（無論如何，每次交易執行大量操作都不是一個好主意。）

目前只有 InnoDB 和 MyISAM 儲存引擎支援 FULLTEXT 索引。有關更多資訊，請參閱第 14.9 節，「全文搜尋功能」。

這是可能的，但不總是明智的。執行叢集的主要原因之一是提供備援。若要充分利用此備援的好處，每個節點都應位於單獨的機器上。如果您將多個節點放在單一機器上，並且該機器發生故障，您將會遺失所有這些節點。因此，如果您確實在單一機器上執行多個資料節點，非常重要的是，應以這樣的方式設定它們，即此機器的故障不會導致給定節點群組中的所有資料節點遺失。

鑑於 NDB 叢集可以在載有低成本（甚至免費）作業系統的商用硬體上執行，額外一兩台機器的費用非常值得，可以保護關鍵任務資料。同樣值得注意的是，執行管理節點的叢集主機的要求很低。此任務可以使用 300 MHz Pentium 或同等 CPU 以及足夠的作業系統 RAM，外加少量的 ndb_mgmd 和 ndb_mgm 程序所帶來的額外負擔來完成。

在具有多個 CPU、核心或兩者的單一主機上執行多個叢集資料節點是可以接受的。NDB 叢集散發套件還提供資料節點二進位檔的多執行緒版本，適用於此類系統。有關更多資訊，請參閱第 25.5.3 節，「ndbmtd — NDB 叢集資料節點守護程式（多執行緒）」。

在某些情況下，也可以在同一機器上同時執行資料節點和 SQL 節點；此類配置的效能取決於多種因素，例如核心和 CPU 的數量，以及資料節點和 SQL 節點程序可用的磁碟和記憶體量，並且您在規劃此類配置時必須考慮這些因素。

可以在不將叢集離線的情況下，將新的資料節點新增到執行中的 NDB 叢集。有關更多資訊，請參閱第 25.6.7 節，「線上新增 NDB 叢集資料節點」。

對於其他類型的 NDB 叢集節點，只需要滾動重新啟動（請參閱第 25.6.5 節，「執行 NDB 叢集的滾動重新啟動」）。

MySQL NDB 叢集中 NDB 表格的限制包括以下各項

如需 NDB Cluster 中限制的完整清單，請參閱 第 25.2.7 節，「NDB Cluster 的已知限制」。另請參閱 第 25.2.7.11 節，「在 NDB Cluster 8.4 中解決的先前 NDB Cluster 問題」。

NDB Cluster 提供的外鍵約束支援與 InnoDB 儲存引擎中的支援相當；請參閱 第 1.7.3.2 節，「外鍵約束」以取得更多詳細資訊，以及 第 15.1.20.5 節，「外鍵約束」。需要外鍵支援的應用程式應使用 NDB Cluster 7.3、7.4、7.5 或更高版本。

您可以像匯入任何其他版本的 MySQL 一樣將資料庫匯入 NDB Cluster。除了本常見問題解答中其他地方提到的限制之外，唯一其他特殊要求是叢集中包含的任何表格都必須使用 NDB 儲存引擎。這表示表格必須使用 ENGINE=NDB 或 ENGINE=NDBCLUSTER 建立。

也可以使用一或多個 ALTER TABLE 語句將使用其他儲存引擎的現有表格轉換為 NDBCLUSTER。但是，表格的定義必須與轉換前的 NDBCLUSTER 儲存引擎相容。在 MySQL 8.4 中，還需要額外的解決方法；有關詳細資訊，請參閱 第 25.2.7 節，「NDB Cluster 的已知限制」。

叢集節點可以透過三種不同的傳輸機制進行通訊：TCP/IP、SHM（共用記憶體）和 SCI（可擴展一致性介面）。在可用的情況下，位於相同叢集主機上的節點之間預設使用 SHM；但是，這被認為是實驗性的。SCI 是一種高速（每秒 1 千兆位元及以上）、高可用性協定，用於建立可擴展的多處理器系統；它需要特殊的硬體和驅動程式。有關使用 SCI 作為 NDB Cluster 的傳輸機制的更多資訊，請參閱 第 25.4.4 節，「將高速互連用於 NDB Cluster」。

如果叢集中的一或多個資料節點失敗，則可能並非所有叢集資料節點都能「看到」彼此。事實上，在網路分割（也稱為「裂腦」）中，兩組資料節點可能會彼此隔離。這種情況是不可取的，因為每一組資料節點都試圖表現得像是整個叢集。仲裁器需要決定競爭的資料節點集之間。

當至少一個節點群組中的所有資料節點都處於活動狀態時，網路分割不是問題，因為沒有單一的叢集子集可以自行形成功能正常的叢集。當沒有單一節點群組的所有節點都處於活動狀態時，才會出現真正的問題，在這種情況下，網路分割（「裂腦」情況）變得可能。然後需要仲裁器。所有叢集節點都將相同的節點識別為仲裁器，這通常是管理伺服器；但是，也可以將叢集中的任何 MySQL 伺服器設定為充當仲裁器。仲裁器接受第一組聯絡它的叢集節點，並告訴其餘組關閉。仲裁器的選擇由 MySQL 伺服器和管理伺服器節點的 ArbitrationRank 設定參數控制。您也可以使用 ArbitrationRank 設定參數來控制仲裁器選擇過程。有關這些參數的更多資訊，請參閱 第 25.4.3.5 節，「定義 NDB Cluster 管理伺服器」。

仲裁器的角色本身不會對指定的主機施加任何繁重的需求，因此仲裁器主機不需要特別快或具有額外的記憶體來專門用於此目的。

NDB Cluster 支援所有常用的 MySQL 資料類型，包括與 MySQL 空間延伸相關的資料類型；但是，NDB 儲存引擎不支援空間索引。（空間索引僅由 MyISAM 支援；有關更多資訊，請參閱 第 13.4 節，「空間資料類型」。）此外，與 NDB 表格一起使用時，索引方面存在一些差異。

有關這些問題的更多資訊，請參閱 第 25.2.7 節，「NDB Cluster 的已知限制」。

必須按照以下順序分別啟動叢集中的每個節點

這些命令都必須在受影響節點所在機器的系統 Shell 中執行。（您不必實際位於該機器旁，可以使用遠端登入 Shell 來達到此目的。）您可以藉由在管理節點所在的機器上啟動 NDB 管理用戶端 ndb_mgm，並發出 SHOW 或 ALL STATUS 命令，來驗證叢集是否正在執行。

要關閉正在執行的叢集，請在管理用戶端中發出命令 SHUTDOWN。或者，您可以在系統 Shell 中輸入以下命令：

$> ndb_mgm -e "SHUTDOWN"

（此範例中的引號是可選的，因為在 -e 選項之後的命令字串中沒有空格；此外，SHUTDOWN 命令與其他管理用戶端命令一樣，不區分大小寫。）

這些命令中的任何一個都會導致 ndb_mgm、ndb_mgm 和任何 ndbd 程序正常終止。可以透過使用 mysqladmin shutdown 來停止作為 SQL 節點執行的 MySQL 伺服器。

如需更多資訊，請參閱 第 25.6.1 節「NDB Cluster 管理用戶端中的命令」 和 第 25.3.6 節「安全關閉和重新啟動 NDB Cluster」。

MySQL Cluster Manager 提供了處理 NDB Cluster 節點啟動和停止的其他方式。請參閱MySQL Cluster Manager 8.4.1 使用手冊，以取得關於此工具的更多資訊。

叢集資料節點在記憶體中保存的資料會寫入磁碟，並在下次啟動叢集時重新載入記憶體。

作為故障安全機制，這會很有幫助。在任何給定時間，只有一個管理節點控制叢集，但可以將一個管理節點配置為主節點，並配置一個或多個額外的管理節點，以便在主管理節點失敗時接管。

有關如何配置 NDB Cluster 管理節點的資訊，請參閱第 25.4.3 節「NDB Cluster 組態檔案」。

可以，只要所有機器和作業系統具有相同的 「位元組序」（全部為大端序或全部為小端序）。

也可以在不同的節點上使用來自不同 NDB Cluster 版本的軟體。但是，我們僅支援將此類使用作為滾動升級程序的一部分（請參閱第 25.6.5 節「執行 NDB Cluster 的滾動重新啟動」）。

可以，這是有可能做到的。對於多個資料節點的情況，建議（但非必要）每個節點使用不同的資料目錄。如果您想在一台機器上執行多個 SQL 節點，則每個 mysqld 執行個體都必須使用不同的 TCP/IP 連接埠。

在同一主機上同時執行資料節點和 SQL 節點是可行的，但您應該知道 ndbd 或 ndbmtd 程序可能會與 mysqld 爭奪記憶體。

可以，可以將 DNS 和 DHCP 用於叢集主機。但是，如果您的應用程式需要 「五個九」的可用性，您應該使用固定的（數字）IP 位址，因為使叢集主機之間的通訊依賴諸如 DNS 和 DHCP 之類的服務會引入其他潛在的故障點。

IPv6 支援 SQL 節點（MySQL 伺服器）之間的連線，但所有其他類型的 NDB Cluster 節點之間的連線必須使用 IPv4。

實際上，這意味著您可以將 IPv6 用於 NDB Cluster 之間的複寫，但同一 NDB Cluster 中的節點之間的連線必須使用 IPv4。如需更多資訊，請參閱第 25.7.3 節「NDB Cluster 複寫中的已知問題」。

MySQL 使用者帳戶和權限通常不會在存取同一 NDB Cluster 的不同 MySQL 伺服器之間自動傳播。MySQL NDB Cluster 支援使用 NDB_STORED_USER 權限來共用和同步使用者和權限；如需更多資訊，請參閱使用共用授權表的散發權限。您應該知道此實作是在 NDB 8.0 中引入的，並且與較早版本的 NDB Cluster 中採用的共用權限機制不相容。較舊的實作在 NDB 8.0 中不再支援。

MySQL NDB Cluster 不提供 SQL 節點之間的任何自動故障轉移。您的應用程式必須準備好處理 SQL 節點的遺失，並在它們之間進行故障轉移。

您可以使用 NDB 管理用戶端和 ndb_restore 程式中的 NDB Cluster 原生備份和還原功能。請參閱第 25.6.8 節「NDB Cluster 的線上備份」和第 25.5.23 節「ndb_restore — 還原 NDB Cluster 備份」。

您也可以使用為此目的在 mysqldump 和 MySQL 伺服器中提供的傳統功能。如需更多資訊，請參閱第 6.5.4 節「mysqldump — 資料庫備份程式」。

此程序會監控資料節點程序，並在必要時嘗試重新啟動它。如果在啟動 ndbd 後檢查系統上的活動程序清單，您會看到實際上以該名稱執行的 2 個程序，如下所示（為了簡潔起見，我們省略了 ndb_mgmd 和 ndbd 的輸出）：

$> ./ndb_mgmd

$> ps aux | grep ndb
me      23002  0.0  0.0 122948  3104 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23025  0.0  0.0   5284   820 pts/2    S+   14:14   0:00 grep ndb

$> ./ndbd -c 127.0.0.1 --initial

$> ps aux | grep ndb
me      23002  0.0  0.0 123080  3356 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23096  0.0  0.0  35876  2036 ?        Ss   14:14   0:00 ./ndbmtd -c 127.0.0.1 --initial
me      23097  1.0  2.4 524116 91096 ?        Sl   14:14   0:00 ./ndbmtd -c 127.0.0.1 --initial
me      23168  0.0  0.0   5284   812 pts/2    R+   14:15   0:00 grep ndb

顯示記憶體和 CPU 使用率均為 0.0 的 ndbd 程序是天使程序（儘管它實際上確實使用非常少量的每個資源）。此程序僅檢查主 ndbd 或 ndbmtd 程序（實際處理資料的主要資料節點程序）是否正在執行。如果允許這樣做（例如，如果 StopOnError 組態參數設定為 false），則天使程序會嘗試重新啟動主要資料節點程序。