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” 是 “Network Database” 的缩写。 NDB 和 NDBCLUSTER 都是 MySQL 中支持集群的存储引擎的名称。NDB 是首选名称，但两者都是正确的。

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

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

NDB 集群也支持异步复制。NDB 集群复制（也称为 “geo-replication”）包括在两个 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 用于 NDB 集群数据和索引。

在某些情况下，即使ndb_mgm -e "ALL REPORT MEMORYUSAGE" 显示了大量的可用内存，仍然可能在 MySQL 客户端应用程序中遇到“表已满”错误。你可以通过使用NDB创建额外的分区来强制 NDB 集群表，并因此拥有更多的内存来存储散列索引，方法是使用CREATE TABLE中的MAX_ROWS选项。一般来说，将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++ 接口，以便在不需要通过 MySQL 服务器的情况下访问 NDB 集群数据。请参阅 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，因此它们不参与集群；每个这样的表都是严格局部的 MySQL 服务器实例上创建的。

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

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

FULLTEXT 索引目前仅支持 InnoDB 和 MyISAM 存储引擎。请参阅 第 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 集群的滚动重新启动”）。

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

有关 NDB 集群的完整限制列表，请参阅 第 25.2.7 节，“NDB 集群的已知限制”。请参阅 第 25.2.7.11 节，“NDB 集群 8.0 中解决的以前的问题”。

NDB 集群提供了与 InnoDB 存储引擎类似的外键约束支持；请参阅 第 1.6.3.2 节，“FOREIGN KEY 约束”，以获取更多信息，以及 第 15.1.20.5 节，“FOREIGN KEY 约束”。需要外键支持的应用程序应该使用 NDB 集群 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 集群的已知限制”，以获取这些问题的更多信息。

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

每个命令都必须从系统 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 用户账户和权限通常不会在访问同一个 NDB 集群的不同 MySQL 服务器之间自动传播。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 后检查系统上的活动进程列表，您可以看到实际上有 2 个以该名称运行的进程，如下所示（我们省略了 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

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