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

您可以从源代码获取并编译 NDB 集群（请参阅 第 25.3.1.4 节“从 Linux 上的源代码构建 NDB 集群” 和 第 25.3.2.2 节“在 Windows 上从源代码编译和安装 NDB 集群”），但除了一些特殊情况外，我们建议使用 Oracle 提供的以下安装程序之一，这些安装程序适合您的操作系统平台和情况

您还可以从平台的软件包管理系统中获取安装包。

您可以使用 SHOW VARIABLES LIKE 'have_%'、SHOW ENGINES 或 SHOW PLUGINS 语句之一来确定您的 MySQL 服务器是否支持 NDB。

“NDB” 代表 “Network Database”（网络数据库）。NDB 和 NDBCLUSTER 都是指支持 MySQL 集群功能的存储引擎的名称。NDB 是首选名称，但两者都正确。

在传统的 MySQL 复制中，一个源 MySQL 服务器会更新一个或多个副本。事务按顺序提交，缓慢的事务会导致副本滞后于源服务器。这意味着如果源服务器发生故障，则副本可能没有记录最后几个事务。如果使用的是事务安全引擎（例如 InnoDB），则事务要么在副本上完成，要么根本不应用，但复制不能保证源服务器和副本上的所有数据始终保持一致。在 NDB Cluster 中，所有数据节点都保持同步，并且任何一个数据节点提交的事务都会提交到所有数据节点。如果一个数据节点发生故障，则所有剩余的数据节点都将保持一致状态。

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

NDB Cluster 中也提供异步复制。NDB Cluster 复制（有时也称为“地理复制”）包括在两个 NDB Cluster 之间以及从 NDB Cluster 到非 Cluster MySQL 服务器之间进行复制的功能。请参见第 25.7 节“NDB Cluster 复制”。

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

运行一个可行的集群至少需要三台计算机。但是，NDB Cluster 中建议的最小计算机数量是四台：一台运行管理节点，一台运行 SQL 节点，两台用作数据节点。使用两个数据节点的目的是提供冗余；管理节点必须在单独的机器上运行，以确保在一个数据节点发生故障时继续提供仲裁服务。

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

NDB Cluster 具有物理和逻辑组织，其中计算机是物理元素。集群的逻辑或功能元素称为节点，包含集群节点的计算机有时称为集群主机。节点共有三种类型，每种类型对应于集群中的特定角色。它们是：

* 表示什么？此节点与其他节点有何不同？

最简单的答案是：“这不是您可以控制的，除非您是编写或分析 NDB Cluster 源代码的软件工程师，否则您无需担心”。

如果您对该答案不满意，请参阅以下更长、更专业的版本：

NDB Cluster 中的许多机制都需要数据节点之间的分布式协调。这些分布式算法和协议包括全局检查点、DDL（模式）更改和节点重启处理。为了简化此协调，数据节点会“选举”其中一个节点作为领导者。没有面向用户的机制来影响此选择，该选择完全是自动的；自动这一事实是 NDB Cluster 内部体系结构的关键部分。

当一个节点充当这些机制中任何一个的“领导者”时，它通常是活动的协调点，而其他节点充当“跟随者”，在领导者的指示下执行其活动的部分。如果充当领导者的节点发生故障，则剩余节点将选举新的领导者。由旧领导者协调的正在进行的任务可能会失败，也可能会由新领导者继续执行，具体取决于所涉及的实际机制。

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

我可以将 NDB Cluster 与哪些操作系统一起使用？

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

运行 NDB Cluster 的硬件要求是什么？

使用 NDB Cluster 需要多少 RAM？可以使用磁盘内存吗？

NDB Cluster 最初仅在内存中实现，但当前所有可用版本还提供了将 NDB Cluster 存储在磁盘上的功能。有关更多信息，请参见第 25.6.11 节“NDB Cluster 磁盘数据表”。

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

对于内存中 NDB 表，可以使用以下公式粗略估计集群中每个数据节点所需的 RAM 大小：

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

在计算集群内存需求时，您可能会发现 ndb_size.pl 实用程序很有用，该实用程序在最近的 MySQL 9.0 版本中可用。此 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，我们建议您对 NDB 集群使用 NTFS 文件系统，就像我们对标准 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 集群的设计和实现假设它将在保证专用高速连接的条件下运行，例如在使用 100 Mbps 或千兆以太网的 LAN 设置中发现的连接——最好是后者。我们既没有测试也没有保证它使用比这更慢的任何东西的性能。

此外，请务必牢记，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 API 提供了到 NDB 集群数据的低级 C++ 接口，而无需通过 MySQL 服务器。请参阅 NDB API。此外，许多 NDBCLUSTER 管理函数都由 C 语言 MGM API 公开；有关更多信息，请参阅 MGM API。

NDB 集群还支持使用 ClusterJ 进行 Java 应用程序编程，ClusterJ 支持使用会话和事务的数据域对象模型。有关更多信息，请参阅 Java 和 NDB 集群。

NDB 集群 8.0 还包括支持针对 Node.js 编写的 NoSQL 应用程序的适配器，其中 NDB 集群作为数据存储。有关更多信息，请参阅 适用于 JavaScript 的 MySQL NoSQL 连接器。

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

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

可以通过两种方式做到这一点

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

NDB Cluster 需要 NDB 存储引擎。也就是说，为了使表能够在 NDB Cluster 中的节点之间共享，必须使用 ENGINE=NDB（或等效选项 ENGINE=NDBCLUSTER）创建表。

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

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

所有已提交的事务都会被记录。因此，尽管在发生灾难时可能会丢失一些数据，但这应该是非常有限的。通过最大限度地减少每个事务的操作数量，可以进一步减少数据丢失。（无论如何，在每个事务中执行大量操作都不是一个好主意。）

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

这是可能的，但不一定可取。运行集群的主要原因之一是提供冗余。为了充分利用此冗余，每个节点应驻留在单独的机器上。如果将多个节点放置在同一台机器上，并且该机器发生故障，则会丢失所有这些节点。因此，如果确实在同一台机器上运行多个数据节点，则**极其**重要的是，应以这样的方式设置它们：该机器的故障不会导致给定节点组中所有数据节点的丢失。

鉴于 NDB Cluster 可以在加载了低成本（甚至免费）操作系统的商用硬件上运行，因此为了保护关键任务数据，额外购买一两台机器的费用是值得的。还值得注意的是，运行管理节点的集群主机要求最低。此任务可以使用 300 MHz 奔腾或同等 CPU 以及足够的 RAM（用于操作系统）以及 ndb_mgmd 和 ndb_mgm 进程的一小部分开销来完成。

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

在某些情况下，还可以在同一台机器上同时运行数据节点和 SQL 节点；这种安排的执行情况取决于许多因素，例如内核和 CPU 的数量以及数据节点和 SQL 节点进程可用的磁盘和内存量，在规划此类配置时必须考虑到这些因素。

可以在不使集群脱机的情况下将新的数据节点添加到正在运行的 NDB Cluster 中。有关更多信息，请参阅 第 25.6.7 节“在线添加 NDB Cluster 数据节点”。

对于其他类型的 NDB Cluster 节点，只需进行滚动重启（请参阅 第 25.6.5 节“执行 NDB Cluster 的滚动重启”）。

MySQL NDB Cluster 中对 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 节“FOREIGN KEY 约束”，以及 第 15.1.20.5 节“FOREIGN KEY 约束”。需要外键支持的应用程序应使用 NDB Cluster 7.3、7.4、7.5 或更高版本。

您可以将数据库导入 NDB Cluster，就像使用任何其他版本的 MySQL 一样。除了本常见问题解答中其他地方提到的限制之外，唯一其他的特殊要求是，要包含在集群中的任何表都必须使用 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 集群管理服务器”。

仲裁器的角色本身并不会对被指定的宿主施加任何沉重的负担，因此仲裁器宿主不需要特别快，也不需要为此专门配备额外的内存。

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 进程正常终止。作为 SQL 节点运行的 MySQL 服务器可以使用 mysqladmin shutdown 停止。

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

MySQL Cluster Manager 提供了更多处理 NDB 集群节点启动和停止的方法。有关此工具的更多信息，请参阅MySQL Cluster Manager 9.0.0 用户手册。

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

作为故障安全机制，这可能会有所帮助。在任何给定时间，只有一个管理节点控制着集群，但可以将一个管理节点配置为主节点，并将一个或多个其他管理节点配置为在主管理节点发生故障时接管。

有关如何配置 NDB 集群管理节点的信息，请参阅第 25.4.3 节“NDB 集群配置文件”。

可以，只要所有机器和操作系统具有相同的“字节序”（全部为大端序或全部为小端序）。

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

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

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

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

SQL 节点（MySQL 服务器）之间的连接支持 IPv6，但所有其他类型的 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_restore 程序中的 NDB 集群原生备份和恢复功能。请参阅第 25.6.8 节“NDB 集群的联机备份”和第 25.5.23 节“ndb_restore - 恢复 NDB 集群备份”。

您还可以使用 mysqldump 和 MySQL 服务器中为此目的提供的传统功能。有关更多信息，请参阅第 6.5.4 节“mysqldump - 数据库备份程序”。

此进程监控数据节点进程，并在必要时尝试重启它。如果您在启动 ndbd 后查看系统上的活动进程列表，您可以看到实际上有两个以该名称运行的进程，如下所示（为简洁起见，我们省略了 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 进程是守护进程（尽管它实际上确实使用了非常少量的内存和 CPU）。此进程仅检查主 ndbd 或 ndbmtd 进程（实际处理数据的​​主数据节点进程）是否正在运行。如果允许这样做（例如，如果 StopOnError 配置参数设置为 false），则守护进程会尝试重启主数据节点进程。