標準 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-megabit 乙太網路或同等網路。我們建議您盡可能使用 gigabit 乙太網路。

執行可行的叢集至少需要三部電腦。但是，NDB Cluster 中建議的最低電腦數目為四部：每部電腦分別執行管理和 SQL 節點，以及兩部電腦作為資料節點。兩個資料節點的目的是提供備援；管理節點必須在單獨的機器上執行，以保證在其中一個資料節點失敗時能夠繼續提供仲裁服務。

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

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

最簡單的答案是，「「這不是您可以控制的東西，而且無論如何您都不必擔心，除非您是編寫或分析 NDB Cluster 原始程式碼的軟體工程師」」。

如果您覺得這個答案不滿意，以下是更長、更技術性的版本

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

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

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

NDB Cluster 的設計方式為領導者的選擇在叢集本身之外不會產生明顯影響。例如，目前的領導者不會比其他資料節點具有顯著較高的 CPU 或資源使用率，而且領導者的失敗對叢集的影響不應與任何其他資料節點的失敗有顯著差異。

NDB Cluster 支援大多數類 Unix 作業系統。NDB Cluster 也支援在 Microsoft Windows 作業系統上的生產設定中執行。

如需有關在各種作業系統版本、作業系統發行版本和硬體平台上提供的 NDB Cluster 支援層級的詳細資訊，請參閱 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 9.0 版本中提供的 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 叢集管理用戶端中的命令」。此外，當使用 80% 的可用 DataMemory 或（在 NDB 7.6 之前）IndexMemory 時，以及當使用量達到 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 用戶端應用程式中也可能出現 Table is full 錯誤。您可以使用 CREATE TABLE 的 MAX_ROWS 選項，強制 NDB 為 NDB 叢集資料表建立額外的分割區，進而獲得更多記憶體用於雜湊索引。一般而言，將 MAX_ROWS 設定為您預期儲存在資料表中的列數的兩倍就足夠了。

由於類似的原因，您也可能會在大量載入資料的節點上遇到資料節點重新啟動的問題。MinFreePct 參數可以透過保留一部分（預設為 5%）的 DataMemory 和（在 NDB 7.6 之前）IndexMemory 來用於重新啟動，從而解決此問題。此保留的記憶體不適用於儲存 NDB 資料表或資料。

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

另外，請務必記住，NDB Cluster 中節點之間的通訊並非安全；它們既未加密，也未受到任何其他保護機制保護。叢集最安全的配置是在防火牆後的私人網路中，從外部無法直接存取任何叢集資料或管理節點。（對於 SQL 節點，您應採取與任何其他 MySQL 伺服器執行個體相同的預防措施。）如需更多資訊，請參閱 第 25.6.21 節「NDB 叢集安全問題」。

否。雖然會使用一些專門的命令來管理和設定叢集本身，但下列操作僅需要標準 (My)SQL 陳述式

需要一些特殊的組態參數和檔案才能設定 NDB 叢集 — 如需相關資訊，請參閱 第 25.4.3 節「NDB 叢集組態檔案」。

在 NDB 叢集管理用戶端 (ndb_mgm) 中使用一些簡單的命令來執行諸如啟動和停止叢集節點等工作。請參閱 第 25.6.1 節「NDB 叢集管理用戶端中的命令」。

NDB Cluster 支援與標準 MySQL Server 相同的程式設計 API 和語言，包括 ODBC、.Net、MySQL C API 以及許多適用於熱門指令碼語言（如 PHP、Perl 和 Python）的驅動程式。使用這些 API 撰寫的 NDB Cluster 應用程式的行為方式與其他 MySQL 應用程式類似；它們將 SQL 陳述式傳輸到 MySQL Server（在 NDB Cluster 的情況下，為 SQL 節點），並接收包含資料列的回應。如需這些 API 的更多資訊，請參閱 第 31 章連線器和 API。

NDB Cluster 也支援使用 NDB API 進行應用程式程式設計，該 API 提供與 NDB Cluster 資料的低階 C++ 介面，而無需透過 MySQL Server。請參閱 NDB API。此外，許多 NDBCLUSTER 管理函式透過 C 語言 MGM API 公開；如需更多資訊，請參閱 MGM API。

NDB Cluster 也支援使用 ClusterJ 進行 Java 應用程式程式設計，該程式設計使用工作階段和交易來支援資料的網域物件模型。如需更多資訊，請參閱 Java 和 NDB 叢集。

NDB Cluster 8.0 還包括支援針對 Node.js 撰寫的 NoSQL 應用程式的介面卡，並以 NDB Cluster 作為資料存放區。如需更多資訊，請參閱 適用於 JavaScript 的 MySQL NoSQL 連接器。

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

MySQL Cluster Manager 也支援 NDB Cluster，這是一個獨立的產品，提供進階的命令列介面，可以自動執行許多 NDB Cluster 管理工作，例如滾動重新啟動和組態變更。如需 MySQL Cluster Manager 的更多資訊，請參閱 MySQL Cluster Manager 9.0.0 使用手冊。

有兩種方法可以執行此操作

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

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

可以使用其他儲存引擎（例如 InnoDB 或 MyISAM）在搭配 NDB Cluster 使用的 MySQL 伺服器上建立資料表，但由於這些資料表未使用 NDB，因此它們不參與叢集；每個此類資料表嚴格來說都是本機到建立它的個別 MySQL 伺服器執行個體。

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

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

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

這是可以的，但不總是建議這麼做。執行叢集的主要原因之一是提供備援。為了充分獲得此備援的好處，每個節點都應位於不同的機器上。如果您將多個節點放在單一機器上，而該機器發生故障，您會遺失所有這些節點。因此，如果您確實在單一機器上執行多個資料節點，極為重要的是，這些節點的設定方式應能確保此機器的故障不會造成特定節點群組中所有資料節點的遺失。

鑑於 NDB Cluster 可以在裝載低成本（甚至免費）作業系統的商用硬體上執行，額外的一兩部機器的費用非常值得，以保護任務關鍵資料。還值得注意的是，執行管理節點的叢集主機的需求非常低。這項工作可以使用 300 MHz Pentium 或同等 CPU 以及足夠作業系統的 RAM 來完成，再加上 ndb_mgmd 和 ndb_mgm 處理序的一些額外負荷。

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

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

可以在不使叢集離線的情況下，將新的資料節點新增至執行中的 NDB Cluster。如需更多資訊，請參閱 第 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 9.0 中解決的先前 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 9.0 中，也需要額外的變通方法；有關詳細資訊，請參閱第 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 的已知限制」。

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

必須從受影響節點所駐留的機器上的系統殼層執行每個命令。(您不必實際在機器上—可以使用遠端登入殼層來達到此目的。) 您可以透過在管理節點所駐留的機器上啟動 NDB 管理用戶端 ndb_mgm，並發出 SHOW 或 ALL STATUS 命令來驗證叢集是否正在執行。

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

$> ndb_mgm -e "SHUTDOWN"

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

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

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

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

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

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

有關如何配置 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 之類的服務，會引入其他潛在的故障點。

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

實際上，這表示您可以使用 IPv6 在 NDB 叢集之間進行複寫，但是在同一 NDB 叢集中的節點之間的連線必須使用 IPv4。有關更多資訊，請參閱 第 25.7.3 節，「NDB Cluster 複寫中的已知問題」。

MySQL 使用者帳戶和權限通常不會在存取同一個 NDB 叢集的不同 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），則守護程序會嘗試重新啟動主要資料節點程序。