标准 MySQL 服务器版本不支持 NDB 集群。相反，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 集群复制（有时也称为 “地理复制”）包括在两个 NDB 集群之间以及从 NDB 集群到非集群 MySQL 服务器进行复制的功能。请参阅 第 25.7 节“NDB 集群复制”。

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

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

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

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

最简单的答案是：“这不是您可以控制的，并且无论如何您都不需要担心，除非您是编写或分析 NDB 集群源代码的软件工程师。”

如果您对该答案不满意，请继续阅读更长、更技术性的版本

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

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

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

NDB 集群的设计方式使得领导者的选择对集群本身之外没有明显的影响。例如，当前领导者的 CPU 或资源使用率并不比其他数据节点高得多，并且领导者节点的故障对集群的影响应该不会比其他任何数据节点的故障大得多。

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

有关在各种操作系统版本、操作系统发行版和硬件平台上对 NDB 集群的支持级别的更详细信息，请参阅 https://www.mysqlserver.cn/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 Cluster 表通常会导致表更新运行得更快——在某些情况下，比在创建主键和唯一键时未使用 USING HASH 的表上的更新快 20% 到 30%。这是因为所需的内存更少（因为没有创建有序索引），并且 CPU 使用率更低（因为必须读取和可能更新的索引更少）。但是，这也意味着无法再使用范围扫描的查询必须通过其他方式来满足，这可能会导致选择速度变慢。

在计算集群内存需求时，您可能会发现 MySQL 8.4 最新版本中提供的 ndb_size.pl 实用程序很有用。此 Perl 脚本连接到当前（非集群）MySQL 数据库，并生成一份报告，说明如果该数据库使用 NDBCLUSTER 存储引擎将需要多少空间。有关详细信息，请参阅 第 25.5.29 节 “ndb_size.pl — NDBCLUSTER 大小需求估算器”。

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

您可以使用 ndb_mgm 客户端中的 REPORT MEMORYUSAGE 命令确定在任何给定时间用于存储 NDB Cluster 数据和索引的内存量；有关详细信息，请参阅 第 25.6.1 节 “NDB Cluster 管理客户端中的命令”。此外，当使用 80% 的可用 DataMemory 或（NDB 7.6 之前版本中的）IndexMemory 时，会在集群日志中写入警告，并在使用率达到 90%、99% 和 100% 时再次写入警告。

通常，主机操作系统原生的任何文件系统都应该可以与 NDB Cluster 良好配合使用。如果您发现某个给定的文件系统在 NDB Cluster 中运行得特别好（或不是特别好），我们邀请您在 NDB Cluster 论坛 中讨论您的发现。

对于 Windows，我们建议您像使用标准 MySQL 一样，对 NDB Cluster 使用 NTFS 文件系统。我们没有使用 FAT 或 VFAT 文件系统测试 NDB Cluster。因此，我们不建议将它们与 MySQL 或 NDB Cluster 一起使用。

NDB Cluster 被实现为一种无共享解决方案；其背后的理念是，单个硬件的故障不应导致多个集群节点的故障，甚至可能导致整个集群的故障。因此，NDB Cluster 不支持使用网络共享或网络文件系统。这也适用于 SAN 等共享存储设备。

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

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

原因很可能是您的设置没有为所有表数据和所有索引提供足够的 RAM，包括 NDB 存储引擎所需的主键，并在表定义未包含主键定义的情况下自动创建。

同样值得注意的是，所有数据节点都应该具有相同的 RAM 量，因为集群中的任何数据节点都不能使用比任何单个数据节点可用的最小内存量更多的内存。例如，如果有四台计算机托管集群数据节点，其中三台计算机有 3GB 的 RAM 可用于存储集群数据，而剩余的数据节点只有 1GB 的 RAM，则每个数据节点最多可以将 1GB 的内存用于 NDB Cluster 数据和索引。

在某些情况下，即使 ndb_mgm -e "ALL REPORT MEMORYUSAGE" 显示有大量空闲 DataMemory，MySQL 客户端应用程序中也可能会出现 表已满 错误。您可以通过对 CREATE TABLE 使用 MAX_ROWS 选项来强制 NDB 为 NDB Cluster 表创建额外的分区，从而为哈希索引提供更多可用内存。通常，将 MAX_ROWS 设置为您希望存储在表中的行数的两倍就足够了。

出于类似的原因，您有时还会在数据负载较重的节点上遇到数据节点重启问题。MinFreePct 参数可以通过为重启保留一部分（默认情况下为 5%）的 DataMemory 和（NDB 7.6 之前版本中的）IndexMemory 来帮助解决此问题。此保留内存不可用于存储 NDB 表或数据。

集群在这种情况下极不可能可靠地执行，因为 NDB Cluster 的设计和实现是基于这样的假设，即它将在保证专用高速连接的条件下运行，例如在使用 100 Mbps 或千兆以太网（最好是后者）的 LAN 环境中。我们既没有测试也没有保证它在使用比这更慢的网络时的性能。

此外，务必牢记，NDB Cluster 中节点之间的通信是不安全的；它们既没有加密，也没有受到任何其他保护机制的保护。集群最安全的配置是在防火墙后的专用网络中，从外部无法直接访问任何集群数据或管理节点。（对于 SQL 节点，您应该采取与任何其他 MySQL 服务器实例相同的预防措施。）有关详细信息，请参阅 第 25.6.21 节 “NDB Cluster 安全问题”。

不需要。尽管使用了一些专门的命令来管理和配置集群本身，但以下操作只需要标准 (My)SQL 语句

设置 NDB Cluster 需要一些专门的配置参数和文件——有关这些信息，请参阅 第 25.4.3 节 “NDB Cluster 配置文件”。

在 NDB Cluster 管理客户端（ndb_mgm）中使用了一些简单的命令来执行启动和停止集群节点等任务。请参阅 第 25.6.1 节 “NDB Cluster 管理客户端中的命令”。

NDB Cluster 支持与标准 MySQL 服务器相同的编程 API 和语言，包括 ODBC、.Net、MySQL C API 以及针对 PHP、Perl 和 Python 等流行脚本语言的众多驱动程序。使用这些 API 编写的 NDB Cluster 应用程序的行为类似于其他 MySQL 应用程序；它们将 SQL 语句传输到 MySQL 服务器（在 NDB Cluster 的情况下，是 SQL 节点），并接收包含数据行的响应。有关这些 API 的详细信息，请参阅 第 31 章 “连接器和 API”。

NDB Cluster 还支持使用 NDB API 进行应用程序编程，该 API 提供了到 NDB Cluster 数据的低级 C++ 接口，而无需通过 MySQL 服务器。请参阅 NDB API。此外，许多 NDBCLUSTER 管理函数都通过 C 语言 MGM API 公开；有关详细信息，请参阅 MGM API。

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

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

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

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

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

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

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

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

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

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

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

这是可能的，但并不总是可取的。运行集群的主要原因之一是提供冗余。为了获得这种冗余的全部好处，每个节点都应该驻留在单独的机器上。如果将多个节点放在一台机器上，并且该机器出现故障，则会丢失所有这些节点。因此，如果确实在一台机器上运行多个数据节点，极其重要的是，应以这样一种方式设置它们，即该机器的故障不会导致丢失给定节点组中的所有数据节点。

鉴于 NDB 集群可以在加载了低成本（甚至免费）操作系统的商用硬件上运行，因此额外一两台机器的费用对于保护关键任务数据来说是值得的。还值得注意的是，运行管理节点的集群主机要求最低。此任务可以使用 300 MHz 奔腾或等效 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 集群中限制的完整列表，请参阅 第 25.2.7 节“NDB 集群的已知限制”。另请参阅 第 25.2.7.11 节“NDB 集群 8.4 中已解决的先前 NDB 集群问题”。

NDB 集群对外键约束的支持与 InnoDB 存储引擎中的支持相当；有关更多详细信息，请参阅 第 1.7.3.2 节“FOREIGN KEY 约束”，以及 第 15.1.20.5 节“FOREIGN KEY 约束”。需要外键支持的应用程序应使用 NDB 集群 7.3、7.4、7.5 或更高版本。

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

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

集群节点可以通过三种不同的传输机制进行通信：TCP/IP、SHM（共享内存）和 SCI（可扩展一致性接口）。在可用情况下，默认情况下，SHM 用于驻留在同一集群主机上的节点之间；但是，这被认为是实验性的。SCI 是一种用于构建可扩展多处理器系统的高速（每秒 1 千兆位或更高）、高可用性协议；它需要特殊的硬件和驱动程序。有关使用 SCI 作为 NDB 集群传输机制的更多信息，请参阅 第 25.4.4 节“将高速互连与 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 进程正常终止。作为 SQL 节点运行的 MySQL 服务器可以使用 mysqladmin shutdown 停止。

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

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

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

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

有关如何配置 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），守护进程会尝试重启 主要数据节点进程。