“NDB” 代表 “网络 数据库”。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 兆比特以太网或等效的网络。我们建议您使用 gigabit 以太网，尽可能使用。

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

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

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

对于 Windows，我们建议使用 NTFS 文件系统与 NDB 集群，正如我们对标准 MySQL 所做的那样。我们不测试 NDB 集群与 FAT 或 VFAT 文件系统。因此，我们不建议使用它们与 MySQL 或 NDB 集群。

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

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

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

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

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

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

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

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

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数、磁盘和内存可用性等，您必须在规划这种配置时考虑这些因素。

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

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

集群节点可以通过三种不同的传输机制进行通信：TCP/IP、SHM（共享内存）和 SCI（Scalable Coherent Interface）。在同一集群主机上，默认情况下使用 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 集群的已知限制”，以获取更多关于这些问题的信息。

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

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

请参阅第 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 后检查系统上的活动进程列表，你可以看到实际上有两个进程在运行，正如这里所示（我们省略了 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

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