NDB 集群不支持标准 MySQL 服务器版本。相反，MySQL NDB 集群作为单独的产品提供。可用的 NDB 集群版本系列包括以下内容：

你可以从源代码编译 NDB 集群（参阅 第 25.3.1.4 节，“在 Linux 上从源代码构建 NDB 集群” 和 第 25.3.2.2 节，“在 Windows 上从源代码编译和安装 NDB 集群”），但对于大多数情况，我们建议使用 Oracle 提供的适合您操作平台和情况的安装程序：

安装包也可能来自您的平台的包管理系统。

你可以使用以下语句确定 MySQL 服务器是否支持 NDB：SHOW VARIABLES LIKE 'have_%'、SHOW ENGINES 或 SHOW PLUGINS。

“NDB” 代表 “网络 数据库”. NDB 和 NDBCLUSTER 都是 MySQL 中支持集群的存储引擎的名称。 NDB 是首选，但两者都是正确的。

在传统的 MySQL 复制中，一个源 MySQL 服务器更新一个或多个副本。事务按顺序提交，并且慢事务可能会导致副本落后于源。如果源服务器失败，副本可能没有记录最后几笔事务。如果使用事务安全引擎，如 InnoDB，事务要么在副本上完成，要么不应用，但复制不保证源和副本的数据始终保持一致。在 NDB 集群中，所有数据节点保持同步，任何一个数据节点提交的事务都将在所有数据节点上提交。如果数据节点失败，所有剩余数据节点将保持一致状态。

简言之，标准的 MySQL 复制是 异步 的，而 NDB 集群是 同步 的。

NDB 集群也支持异步复制。NDB 集群复制（也称为 “地理复制”）包括从一个 NDB 集群到另一个 NDB 集群的复制能力，以及从 NDB 集群到非集群 MySQL 服务器的复制能力。见 第 25.7 节，“NDB 集群复制”。

NDB 集群旨在高带宽环境中使用，计算机使用 TCP/IP 连接。其性能直接取决于集群计算机之间的连接速度。NDB 集群的最低连接要求包括典型的 100 兆比特以太网网络或等效网络。我们建议您使用 gigabit 以太网网络，尽可能地使用。

至少需要三台计算机来运行可行的集群。然而，推荐的最少计算机数量是四台：一台管理节点、一台 SQL 节点和两台数据节点。两台数据节点的目的是提供冗余；管理节点必须在单独的机器上运行，以确保在数据节点失败时继续提供仲裁服务。

为了提高吞吐量和高可用性，您应该使用多个 SQL 节点（连接到集群的 MySQL 服务器）。也可以（但不一定）运行多个管理服务器。

一个 NDB 集群同时具有物理和逻辑组织，计算机是物理元素。集群的逻辑或功能元素被称为 节点，而一个包含集群节点的计算机有时被称为 集群主机。有三种类型的节点，每种对应集群中的特定角色。这些是：

最简单的答案是，“这不是你可以控制的东西，也不是你需要担心的事情，除非你是一个软件工程师，正在编写或分析NDB Cluster源代码””。

如果你不满意这个答案，这里有一个更长、更技术性的版本：

NDB Cluster中的许多机制需要在数据节点之间进行分布式协调。这些分布式算法和协议包括全局检查点、DDL（模式）更改和节点重新启动处理。为了使这种协调变得更简单，数据节点““选举””其中一个作为领导者。没有用户面向的机制来影响这种选择，这完全是自动的；事实上这是NDB Cluster内部架构的一部分。

当一个节点充当领导者时，它通常是这些机制的协调点，而其他节点则充当““跟随者””，按照领导者的指令执行活动的一部分。如果领导者节点失败，那么剩余的节点将选举出一个新的领导者。在进度中的任务可能会失败或由新的领导者继续执行，具体取决于所涉及的机制。

这些不同的机制和协议可能具有不同的领导者节点，但通常情况下，同一个领导者被选为所有这些机制。节点在管理客户端的SHOW输出中被指示为领导者，内部被称为DICT管理器，负责协调DDL和元数据活动。

NDB Cluster被设计成这样，领导者的选择对集群外部没有明显的影响。例如，当前领导者不具有明显高于其他数据节点的CPU或资源使用率，领导者失败对集群的影响与其他数据节点的失败没有明显的区别。

NDB Cluster支持大多数类Unix操作系统。NDB Cluster也支持Microsoft Windows操作系统的生产环境。

有关NDB Cluster在各种操作系统版本、操作系统发行版和硬件平台上支持级别的详细信息，请参阅https://www.mysql.com/support/supportedplatforms/cluster.html。

NDB Cluster应该在任何平台上运行，为其提供NDB-enabled二进制文件。对于数据节点和API节点，较快的CPU和更多的内存可能会提高性能，64位CPU可能比32位处理器更有效。用于数据节点的机器必须具有足够的内存来存储每个节点的数据库份额（请参阅《我需要多少RAM？》以获取更多信息）。对于仅用于运行NDB Cluster管理服务器的计算机，要求很小；一台普通的桌面PC（或等效的）通常足以完成这项任务。节点可以通过标准的TCP/IP网络和硬件进行通信。它们也可以使用高速SCI协议；但是，需要特殊的网络硬件和软件来使用SCI（请参阅第25.4.4节，“使用NDB Cluster的高速互连”）。

NDB 集群最初是作为内存中的实现，但当前所有版本也提供了在磁盘上存储 NDB 集群的能力。请参阅 第 25.6.11 节，“NDB 集群磁盘数据表”，以获取更多信息。

对于内存中的 NDB 表，可以使用以下公式来估算每个数据节点在集群中的 RAM 需求：

(数据库大小 × 复制数量 × 1.1 ) / 数据节点数量

要更准确地计算内存需求，需要确定每个表在集群数据库中的存储空间需求（请参阅 第 13.7 节，“数据类型存储需求”，以获取详细信息），然后将其乘以行数。您还必须记住考虑列索引，如下所示：

使用 USING HASH 创建所有主键和唯一索引的 NDB 集群表通常使表更新速度加快——在某些情况下，速度可以提高 20 到 30%。这是因为需要的内存较少（因为没有创建有序索引），并且需要的 CPU 资源较少（因为需要读取和更新的索引较少）。然而，这也意味着无法使用范围扫描的查询必须通过其他方式满足，这可能会导致选择速度变慢。

计算集群内存需求时，您可能会发现 ndb_size.pl 实用程序非常有用，该实用程序位于最近的 MySQL 8.3 版本中。该 Perl 脚本连接到当前（非集群）MySQL 数据库，并创建一个报告，说明该数据库如果使用 NDBCLUSTER 存储引擎所需的空间。有关更多信息，请参阅 第 25.5.29 节，“ndb_size.pl — NDBCLUSTER 大小需求估算器”。

请牢记 每个 NDB 集群表都必须有一个主键。 NDB 存储引擎会自动创建一个主键，如果没有定义；该主键是在没有 USING HASH 的情况下创建的。

您可以使用 REPORT MEMORYUSAGE 命令在 ndb_mgm 客户端中确定 NDB 集群数据和索引的当前内存使用情况；请参阅 第 25.6.1 节，“NDB 集群管理客户端命令”，以获取更多信息。此外，当可用 DataMemory 或（在 NDB 7.6 之前）IndexMemory 达到 80%、90%、99% 和 100% 时，集群日志中将写入警告。

一般来说，任何宿主操作系统的本机文件系统都应该与NDB Cluster配合良好。如果您发现某个文件系统特别适合（或不太适合）NDB Cluster，我们邀请您在NDB Cluster 论坛中讨论您的发现。

对于Windows，我们建议您使用NTFS文件系统来运行NDB Cluster，就像我们对标准MySQL所做的那样。我们不测试NDB Cluster与FAT或VFAT文件系统的兼容性。因此，我们不建议使用它们与MySQL或NDB Cluster。

NDB Cluster作为一个共享无解决方案实现的；背后的想法是，单个硬件的故障不应该导致多个集群节点的故障，或者可能导致整个集群的故障。因此，我们不支持使用网络共享或网络文件系统来运行NDB Cluster。这也适用于共享存储设备，如SAN。

NDB Cluster支持在虚拟机中使用。我们当前支持和测试使用Oracle VM。

一些NDB Cluster用户已经成功部署了NDB Cluster，使用其他虚拟化产品；在这种情况下，Oracle可以提供NDB Cluster支持，但虚拟环境中的问题必须转交给该产品的供应商。

很可能是您的设置没有为所有表数据和所有索引提供足够的RAM，包括NDB存储引擎自动创建的主键。

还值得注意的是，所有数据节点都应该具有相同的RAM，因为集群中的任何数据节点都不能使用超过最少可用RAM的内存。例如，如果有四台计算机托管集群数据节点，其中三台计算机有 3GB 的 RAM 可以用于存储集群数据，而剩下的数据节点只有 1GB 的 RAM，那么每个数据节点最多只能使用 1GB 的 RAM 来存储 NDB Cluster 数据和索引。

在某些情况下，即使ndb_mgm -e "ALL REPORT MEMORYUSAGE" 显示有足够的可用内存，仍然可能在 MySQL 客户端应用程序中遇到“表已满”的错误。在这种情况下，您可以使用 MAX_ROWS 选项来强制 NDB 为 NDB Cluster 表创建额外的分区，从而为哈希索引提供更多的内存。通常，将 MAX_ROWS 设置为预期表行数的两倍应该足够。

类似地，您也可能在数据节点重启时遇到问题，特别是在节点上存储了大量数据的情况下。MinFreePct 参数可以帮助解决这个问题，通过保留一部分（默认为 5%）的 DataMemory 和（在 NDB 7.6 之前）IndexMemory 用于重启。这些保留的内存不可用于存储 NDB 表或数据。

在这种条件下，集群可能无法可靠地运行，因为 NDB Cluster 是在假设有专用高速连接的情况下设计和实现的，例如 LAN 设置中的 100 Mbps 或千兆以太网 - 最好是后者。我们既不测试也不保证使用任何慢于此的性能。

此外，需要牢记的是，集群节点之间的通信是不安全的；它们既不加密也不受任何其他保护机制的保护。集群的最安全配置是在防火墙后的私有网络中，没有直接访问集群数据或管理节点的外部访问。（对于 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 的应用程序编程，该 API 提供了一个低级 C++ 接口，用于访问 NDB 集群数据，而不需要通过 MySQL 服务器。请参阅 NDB API。此外，许多 NDBCLUSTER 管理函数通过 C 语言的 MGM API 暴露；请参阅 MGM API，以获取更多信息。

NDB 集群还支持使用 ClusterJ 的 Java 应用程序编程，该 API 支持使用会话和事务的域对象模型。请参阅 Java 和 NDB 集群，以获取更多信息。

NDB 集群 8.0 还包括支持 Node.js 的 NoSQL 应用程序的适配器，使用 NDB 集群作为数据存储。请参阅 MySQL NoSQL Connector for JavaScript，以获取更多信息。

NDB 集群包括一个命令行客户端，用于执行基本管理功能。请参阅 第 25.5.5 节，“ndb_mgm — NDB 集群管理客户端”，和 第 25.6.1 节，“NDB 集群管理客户端中的命令”。

NDB 集群还支持 MySQL 集群管理器，一个单独的产品，提供了一个高级命令行界面，可以自动执行许多 NDB 集群管理任务，例如滚动重新启动和配置更改。有关 MySQL 集群管理器的更多信息，请参阅 MySQL 集群管理器 8.3.0 用户手册。

有两种方法可以实现这一点：

是。对于使用 NDB 存储引擎创建的表，事务是支持的。目前，NDB 集群仅支持 READ COMMITTED 事务隔离级别。

NDB 集群需要 NDB 存储引擎。也就是说，要共享 NDB 集群中的表，表必须使用 ENGINE=NDB（或等效选项 ENGINE=NDBCLUSTER）创建。

可以在 MySQL 服务器上使用其他存储引擎（如 InnoDB 或 MyISAM）与 NDB 集群一起使用，但这些表不使用 NDB，因此它们不参与集群；每个这样的表都是严格局部的 MySQL 服务器实例上创建的。

NDB 集群与 InnoDB 集群在架构、要求和实现方面有很大不同，尽管它们的名称相似，但它们不兼容。有关 InnoDB 集群的更多信息，请参阅 MySQL AdminAPI。另请参阅 第 25.2.6 节，“使用 InnoDB 的 MySQL 服务器与 NDB 集群比较”，以获取 NDB 和 InnoDB 存储引擎之间的差异信息。

所有提交的事务都被记录下来。因此，尽管灾难事件可能会导致一些数据丢失，但这应该是非常有限的。通过将每个事务中的操作数量最小化，可以进一步减少数据丢失。（在任何情况下都不应该在一个事务中执行大量操作。）

FULLTEXT 索引目前仅支持 InnoDB 和 MyISAM 存储引擎。请参阅 第 14.9 节，“全文搜索函数”，以获取更多信息。

这是可能的，但不总是明智的。运行集群的主要原因是提供冗余性。如果您在单个机器上运行多个节点，并且该机器失败，您将失去所有这些节点。因此，如果您在单个机器上运行多个数据节点，非常重要的是它们被设置为这样，即使该机器失败，也不会导致给定节点组中的所有数据节点丢失。

考虑到 NDB Cluster 可以在低成本（或免费）的操作系统上运行的 commodity 硬件上运行，这笔额外的机器或两台机器的费用是值得的，以保护关键任务数据。此外，管理节点的要求也很小。这个任务可以使用 300 MHz Pentium 或等效 CPU 和足够的 RAM 运行操作系统，另外还需要一些用于 ndb_mgmd 和 ndb_mgm 进程的开销。

在具有多个 CPU、核心或两者的主机上运行多个集群数据节点是可以接受的。NDB Cluster 分发版还提供了一个多线程版本的数据节点二进制文件，旨在这些系统上使用。有关更多信息，请参阅 第 25.5.3 节，“ndbmtd — NDB 集群数据节点守护进程（多线程）”。

在某些情况下，也可以在同一台机器上同时运行数据节点和 SQL 节点；这种安排的性能取决于多个因素，如核心数、CPU 数量、磁盘和内存可用性等，您必须在规划这种配置时考虑这些因素。

可以在不关闭 NDB Cluster 的情况下添加新数据节点。有关更多信息，请参阅 第 25.6.7 节，“在线添加 NDB 集群数据节点”。

对于其他类型的 NDB 集群节点，只需要滚动重新启动（请参阅 第 25.6.5 节，“滚动重新启动 NDB 集群”）。

在 MySQL NDB Cluster 中的 NDB 表的限制包括以下几点：

要查看 NDB Cluster 的所有限制，请参阅 第 25.2.7 节，“NDB Cluster 的已知限制”。见 also 第 25.2.7.11 节，“NDB Cluster 8.0 中解决的以前问题”。

NDB Cluster 提供了与 InnoDB 存储引擎类似的外键约束支持；见 第 1.6.3.2 节，“FOREIGN KEY 约束”，以获取更多信息，以及 第 15.1.20.5 节，“FOREIGN KEY 约束”。需要外键支持的应用程序应该使用 NDB Cluster 7.3、7.4、7.5 或更高版本。

您可以像使用其他版本的 MySQL 一样将数据库导入 NDB 集群。除了本 FAQ 中提到的其他限制外，唯一的特殊要求是要将要包含在集群中的表使用 NDB 存储引擎。这意味着表必须使用 ENGINE=NDB 或 ENGINE=NDBCLUSTER 创建。

您也可以使用一个或多个 ALTER TABLE 语句将使用其他存储引擎的现有表转换为 NDBCLUSTER。然而，在进行转换之前，表的定义必须与 NDBCLUSTER 存储引擎兼容。在 MySQL 8.3 中，还需要一个额外的解决方法；请参阅 第 25.2.7 节，“NDB 集群的已知限制”，以获取详细信息。

集群节点可以通过三种不同的传输机制进行通信：TCP/IP、SHM（共享内存）和 SCI（可扩展的相干接口）。在同一集群主机上，默认情况下使用 SHM，但这被认为是实验性的。SCI 是一种高速（每秒 1 吉字节以上）、高可用性的协议，用于构建可扩展的多处理器系统；它需要特殊的硬件和驱动程序。请参阅 第 25.4.4 节，“使用 NDB 集群的高速互连”，以获取关于使用 SCI 作为 NDB 集群传输机制的更多信息。

如果集群中的一个或多个数据节点失败，可能会出现这种情况：不是所有的数据节点都可以“看到”彼此。实际上，可能会出现网络分区（也称为“脑裂”）的情况，其中两个数据节点集群彼此隔离。在这种情况下，仲裁器是必需的，以便在竞争的数据节点集之间进行决策。

当至少一个节点组中的所有数据节点都活跃时，不会出现网络分区问题，因为没有单个子集可以单独形成功能完整的集群。真正的问题出现时，当没有单个节点组中的所有节点都活跃时，网络分区（“脑裂”）的情况就会出现。这时需要仲裁器。所有集群节点都将同一个节点识别为仲裁器，通常是管理服务器；但是，可以配置集群中的任何 MySQL 服务器来充当仲裁器。仲裁器接受第一个联系它的集群节点集，并告诉剩余的集群节点关闭。仲裁器的选择由 MySQL 服务器和管理服务器节点的 ArbitrationRank 配置参数控制。您也可以使用 ArbitrationRank 配置参数来控制仲裁器选择过程。有关这些参数的更多信息，请参阅 第 25.4.3.5 节，“定义 NDB 集群管理服务器”。

仲裁器的角色本身并不对主机施加太高的要求，因此仲裁器主机不需要特别快或具有额外的内存来满足这个目的。

NDB 集群支持所有通常的 MySQL 数据类型，包括与 MySQL 的空间扩展相关的那些；然而，NDB 存储引擎不支持空间索引。（空间索引仅由 MyISAM 支持；见 第 13.4 节，“空间数据类型”，以获取更多信息。）此外，当与 NDB 表一起使用时，还有一些索引的差异。

请参阅 第 25.2.7 节，“NDB 集群的已知限制”，以获取这些问题的更多信息。

您可以像使用其他版本的 MySQL 一样将数据库导入 NDB 集群。除了本 FAQ 中提到的其他限制外，唯一的特殊要求是要将要包含在集群中的表使用 NDB 存储引擎。这意味着表必须使用 ENGINE=NDB 或 ENGINE=NDBCLUSTER 创建。

您也可以使用一个或多个 ALTER TABLE 语句将使用其他存储引擎的现有表转换为 NDBCLUSTER。然而，在进行转换之前，表的定义必须与 NDBCLUSTER 存储引擎兼容。在 MySQL 8.3 中，还需要一个额外的解决方法；请参阅 第 25.2.7 节，“NDB 集群的已知限制”，以获取详细信息。

集群节点可以通过三种不同的传输机制进行通信：TCP/IP、SHM（共享内存）和 SCI（可扩展的相干接口）。在同一集群主机上，默认情况下使用 SHM，但这被认为是实验性的。SCI 是一种高速（每秒 1 吉字节以上）、高可用性的协议，用于构建可扩展的多处理器系统；它需要特殊的硬件和驱动程序。请参阅 第 25.4.4 节，“使用 NDB 集群的高速互连”，以获取关于使用 SCI 作为 NDB 集群传输机制的更多信息。

如果集群中的一个或多个数据节点失败，可能会出现这种情况：不是所有的数据节点都可以“看到”彼此。实际上，可能会出现网络分区（也称为“脑裂”）的情况，其中两个数据节点集群彼此隔离。在这种情况下，仲裁器是必需的，以便在竞争的数据节点集之间进行决策。

当至少一个节点组中的所有数据节点都活跃时，不会出现网络分区问题，因为没有单个子集可以单独形成功能完整的集群。真正的问题出现时，当没有单个节点组中的所有节点都活跃时，网络分区（“脑裂”）的情况就会出现。这时需要仲裁器。所有集群节点都将同一个节点识别为仲裁器，通常是管理服务器；但是，可以配置集群中的任何 MySQL 服务器来充当仲裁器。仲裁器接受第一个联系它的集群节点集，并告诉剩余的集群节点关闭。仲裁器的选择由 MySQL 服务器和管理服务器节点的 ArbitrationRank 配置参数控制。您也可以使用 ArbitrationRank 配置参数来控制仲裁器选择过程。有关这些参数的更多信息，请参阅 第 25.4.3.5 节，“定义 NDB 集群管理服务器”。

仲裁器的角色本身并不对主机施加太高的要求，因此仲裁器主机不需要特别快或具有额外的内存来满足这个目的。

NDB 集群支持所有通常的 MySQL 数据类型，包括与 MySQL 的空间扩展相关的那些；然而，NDB 存储引擎不支持空间索引。（空间索引仅由 MyISAM 支持；见 第 13.4 节，“空间数据类型”，以获取更多信息。）此外，当与 NDB 表一起使用时，还有一些索引的差异。

请参阅 第 25.2.7 节，“NDB 集群的已知限制”，以获取这些问题的更多信息。

必须分别启动集群中的每个节点，按照以下顺序：

每个命令都必须从系统 shell 中的受影响节点的机器上运行。（您不需要亲自在机器上出现—远程登录 shell 可以用于此目的。）您可以通过启动 NDB 管理客户端 ndb_mgm 在管理节点的机器上，并发出 SHOW 或 ALL STATUS 命令来验证集群是否正在运行。

要关闭正在运行的集群，请在管理客户端中发出 SHUTDOWN 命令。或者，您可以在系统 shell 中输入以下命令：

$> ndb_mgm -e "SHUTDOWN"

(在这个示例中，引号是可选的，因为在 -e 选项后的命令字符串中没有空格；此外，SHUTDOWN 命令，如同其他管理客户端命令一样，不区分大小写。)

这两个命令都会使 ndb_mgm、ndb_mgm 和任何 ndbd 进程终止。

MySQL 服务器作为 SQL 节点可以使用 mysqladmin shutdown 关闭。

有关更多信息，请参阅 第 25.6.1 节，“NDB 集群管理客户端中的命令” 和 第 25.3.6 节，“NDB 集群的安全关闭和重启”。

MySQL 集群管理器提供了其他方式来处理 NDB 集群节点的启动和停止。请参阅 MySQL 集群管理器 8.3.0 用户手册，以获取有关该工具的更多信息。

集群的数据节点将内存中的数据写入磁盘，并在下次启动集群时重新加载到内存中。

这可以作为故障安全措施。任何时候，只有一个管理节点控制集群，但可以配置一个主要管理节点，并且可以配置一个或多个辅助管理节点，以便在主要管理节点失败时接管。

请参阅 第 25.4.3 节，“NDB 集群配置文件”，了解如何配置 NDB 集群管理节点。

是的，只要所有机器和操作系统具有相同的“endianness”（所有大端或所有小端）。

也可以在不同的 NDB 集群版本上使用软件，但是我们仅支持在滚动升级过程中使用这种方法（请参阅 第 25.6.5 节，“执行 NDB 集群的滚动重启”）。

是的，可以这样做。在数据节点的情况下，建议（但不是必需的）每个节点使用不同的数据目录。如果您想在一台机器上运行多个 SQL 节点，每个实例的 mysqld 都必须使用不同的 TCP/IP 端口。

在同一主机上运行数据节点和 SQL 节点是可能的，但是您应该注意 ndbd 或 ndbmtd 进程可能与 mysqld 竞争内存。

是的，可以使用 DNS 和 DHCP 来管理集群主机。但是，如果您的应用程序需要“五个九”可用性，那么您应该使用固定（数字）IP 地址，因为使集群主机之间的通信依赖于服务如 DNS 和 DHCP 会引入额外的故障点。

IPv6 在 SQL 节点（MySQL 服务器）之间的连接中受支持，但是 NDB 集群中其他类型节点之间的连接必须使用 IPv4。

实际上，这意味着您可以使用 IPv6 进行 NDB 集群之间的复制，但是同一个 NDB 集群中的节点之间的连接必须使用 IPv4。有关更多信息，请参阅 第 25.7.3 节，“NDB 集群复制中的已知问题”。

MySQL 用户账户和权限通常不会自动在不同的 MySQL 服务器之间传播，访问同一个 NDB 集群。MySQL NDB 集群提供了使用 NDB_STORED_USER 权限来共享和同步用户和权限的支持；请参阅 分布式权限使用共享授权表，以获取更多信息。你应该知道，这个实现是在 NDB 8.0 中引入的，并且与早期版本的 NDB 集群中的共享权限机制不兼容。早期实现不再在 NDB 8.0 中受支持。

MySQL NDB 集群不提供自动故障转移到 SQL 节点之间的功能。您的应用程序必须准备好处理 SQL 节点的损失，并在它们之间进行故障转移。

您可以使用 NDB 集群原生的备份和恢复功能，在 NDB 管理客户端和 ndb_restore 程序中。请参阅 第 25.6.8 节，“NDB 集群的在线备份”，和 第 25.5.23 节，“ndb_restore — Restore an NDB Cluster Backup”。

您也可以使用 mysqldump 和 MySQL 服务器提供的传统备份功能。请参阅 第 6.5.4 节，“mysqldump — A Database Backup Program”，以获取更多信息。

该进程监控并尝试重新启动数据节点进程。如果您在启动 ndbd 后检查系统上的活动进程列表，您可以看到实际上有两个进程在运行，如下所示（我们省略了 ndb_mgmd 和 ndbd 的输出，以简洁起见）：

$> ./ndb_mgmd

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

显示 0.0 的 ndbd 进程实际上是守护进程（尽管它实际上使用了非常少的内存和 CPU）。该进程只是检查主 ndbd 或 ndbmtd 进程（实际处理数据的主数据节点进程）是否正在运行。如果允许这样做（例如，如果 StopOnError 配置参数设置为 false），则守护进程尝试重新启动主数据节点进程。