标准 MySQL Server 版本不支持 NDB Cluster。相反，MySQL NDB Cluster 作为一个独立产品提供。可用的 NDB Cluster 发布系列包括以下内容：NDB Cluster is not supported in standard MySQL Server releases. Instead, MySQL NDB Cluster is provided as a separate product. Available NDB Cluster release series include the following:

您可以从源代码获取并编译 NDB Cluster（请参阅 第 25.3.1.4 节，“在 Linux 上从源代码构建 NDB Cluster”，以及 第 25.3.2.2 节，“在 Windows 上从源代码编译和安装 NDB Cluster”），但除非是最专业的情况，否则我们建议使用 Oracle 提供的、适合您操作平台和情况的以下安装程序之一：You can obtain and compile NDB Cluster from source (see Section 25.3.1.4, “Building NDB Cluster from Source on Linux”, and Section 25.3.2.2, “Compiling and Installing NDB Cluster from Source on Windows”), but for all but the most specialized cases, we recommend using one of the following installers provided by Oracle that is appropriate to your operating platform and circumstances:

安装包也可能通过您所在平台的软件包管理系统提供。Installation packages may also be available from your platform's package management system.

您可以使用以下语句之一来确定您的 MySQL 服务器是否支持 NDB：SHOW VARIABLES LIKE 'have_%'、SHOW ENGINES 或 SHOW PLUGINS。You can determine whether your MySQL Server has NDB support using one of the statements SHOW VARIABLES LIKE 'have_%', SHOW ENGINES, or SHOW PLUGINS.

“NDB” 代表 “Network Database”。NDB 和 NDBCLUSTER 都是支持 MySQL 集群功能的存储引擎的名称。NDB 更为常用，但两者名称都正确。“NDB” stands for “Network Database”. NDB and NDBCLUSTER are both names for the storage engine that enables clustering support with MySQL. NDB is preferred, but either name is correct.

在传统的 MySQL 复制中，源 MySQL 服务器会更新一个或多个副本。事务是按顺序提交的，慢速事务可能导致副本落后于源服务器。这意味着如果源服务器发生故障，副本可能还没有记录最后几次事务。如果使用的是事务安全引擎，例如 InnoDB，事务要么在副本上完成，要么根本不应用，但复制并不保证源服务器和副本上的所有数据在任何时候都保持一致。在 NDB 集群中，所有数据节点保持同步，由任何一个数据节点提交的事务对所有数据节点来说都是提交的。在数据节点发生故障时，所有剩余的数据节点仍保持一致的状态。In traditional MySQL replication, a source MySQL server updates one or more replicas. Transactions are committed sequentially, and a slow transaction can cause the replica to lag behind the source. This means that if the source fails, it is possible that the replica might not have recorded the last few transactions. If a transaction-safe engine such as InnoDB is being used, a transaction is either completed on the replica or not applied at all, but replication does not guarantee that all data on the source and the replica remains consistent at all times. In NDB Cluster, all data nodes are kept in synchrony, and a transaction committed by any one data node is committed for all data nodes. In the event of a data node failure, all remaining data nodes remain in a consistent state.

简而言之，标准的 MySQL 复制是 异步），而 NDB 集群则是 synchronous。In short, whereas standard MySQL replication is asynchronous, NDB Cluster is synchronous.

异步复制也可在 NDB 集群中使用。NDB 集群复制（有时也称为 “geo-replication”）包含了两个 NDB 集群之间以及从 NDB 集群复制到非集群 MySQL 服务器的能力。参见 第 25.7 节，“NDB 集群复制”。Asynchronous replication is also available in NDB Cluster. NDB Cluster Replication (also sometimes known as “geo-replication”) includes the capability to replicate both between two NDB Clusters, and from an NDB Cluster to a non-Cluster MySQL server. See Section 25.7, “NDB Cluster Replication”.

NDB Cluster 旨在用于高带宽环境，计算机通过 TCP/IP 连接。其性能直接取决于集群计算机之间的连接速度。NDB Cluster 的最低连接要求包括典型的 100 兆以太网网络或同等水平。我们建议在条件允许时使用千兆以太网。NDB Cluster is intended to be used in a high-bandwidth environment, with computers connecting using TCP/IP. Its performance depends directly upon the connection speed between the cluster's computers. The minimum connectivity requirements for NDB Cluster include a typical 100-megabit Ethernet network or the equivalent. We recommend you use gigabit Ethernet whenever available.

A minimum of three computers is required to run a viable cluster. However, the minimum recommended number of computers in an NDB Cluster is four: one each to run the management and SQL nodes, and two computers to serve as data nodes. The purpose of the two data nodes is to provide redundancy; the management node must run on a separate machine to guarantee continued arbitration services in the event that one of the data nodes fails.

为了提供更高的吞吐量和高可用性，您应使用多个 SQL 节点（连接到集群的 MySQL 服务器）。也可以（虽然不是严格必要的）运行多个管理服务器。To provide increased throughput and high availability, you should use multiple SQL nodes (MySQL Servers connected to the cluster). It is also possible (although not strictly necessary) to run multiple management servers.

NDB 集群具有物理和逻辑组织，计算机是物理元素。集群的逻辑或功能元素称为节点，承载集群节点的计算机有时称为集群主机。节点有三种类型，每种对应集群中的特定角色。如以下所示：An NDB Cluster has both a physical and logical organization, with computers being the physical elements. The logical or functional elements of a cluster are referred to as nodes, and a computer housing a cluster node is sometimes referred to as a cluster host. There are three types of nodes, each corresponding to a specific role within the cluster. These are:

最简单的答案是，“这不是你可以控制的事情，而且无论如何你也无需担心，除非你是一个编写或分析 NDB Cluster 源代码的软件工程师”。The simplest answer is, “It's not something you can control, and it's nothing that you need to worry about in any case, unless you're a software engineer writing or analyzing the NDB Cluster source code”.

如果你觉得这个答案不够满意，这里有一个更长且更技术性的版本：If you don't find that answer satisfactory, here's a longer and more technical version:

A number of mechanisms in NDB Cluster require distributed coordination among the data nodes. These distributed algorithms and protocols include global checkpointing, DDL (schema) changes, and node restart handling. To make this coordination simpler, the data nodes “elect” one of their number to act as leader. There is no user-facing mechanism for influencing this selection, which is completely automatic; the fact that it is automatic is a key part of NDB Cluster's internal architecture.

当一个节点在这些机制中的任何一个中充当“领导者”时，它通常是活动的协调点，而其他节点则充当“跟随者”，按照领导者的指示执行各自的活动部分。如果充当领导者的节点失败，则其余节点会选举新的领导者。由旧领导者协调的正在进行的任务可能会失败，也可能由新领导者继续进行，这取决于所涉及的实际机制。When a node acts as the “leader” for any of these mechanisms, it is usually the point of coordination for the activity, and the other nodes act as “followers”, carrying out their parts of the activity as directed by the leader. If the node acting as leader fails, then the remaining nodes elect a new leader. Tasks in progress that were being coordinated by the old leader may either fail or be continued by the new leader, depending on the actual mechanism involved.

这些不同的机制和协议中的一些可能有不同的领导节点，但通常所有机制都会选择相同的领导。管理客户端中通过 SHOW 输出所指示的节点在内部被称为 DICT 管理器，负责协调 DDL 和元数据活动。It is possible for some of these different mechanisms and protocols to have different leader nodes, but in general the same leader is chosen for all of them. The node indicated as the leader in the output of SHOW in the management client is known internally as the DICT manager, responsible for coordinating DDL and metadata activity.

NDB 集群的设计方式使得领导节点的选择在集群之外没有明显影响。例如，当前的领导节点的 CPU 或资源使用率并不会比其他数据节点显著高，并且领导节点的故障对集群的影响不应显著不同于任何其他数据节点的故障。NDB Cluster is designed in such a way that the choice of leader has no discernible effect outside the cluster itself. For example, the current leader does not have significantly higher CPU or resource usage than the other data nodes, and failure of the leader should not have a significantly different impact on the cluster than the failure of any other data node.

NDB 集群支持大多数类 Unix 操作系统。NDB 集群在 Microsoft Windows 操作系统的生产环境中也受到支持。NDB Cluster is supported on most Unix-like operating systems. NDB Cluster is also supported in production settings on Microsoft Windows operating systems.

有关在各种操作系统版本、操作系统发行版和硬件平台上对 NDB Cluster 支持级别的更详细信息，请参阅 https://www.mysql.com/support/supportedplatforms/cluster.html。For more detailed information concerning the level of support which is offered for NDB Cluster on various operating system versions, operating system distributions, and hardware platforms, please refer to https://www.mysql.com/support/supportedplatforms/cluster.html.

NDB 集群应可以在任何提供 NDB 支持的二进制文件的平台上运行。对于数据节点和 API 节点，更快的 CPU 和更多的内存可能会提升性能，64 位 CPU 可能比 32 位处理器更有效。用于数据节点的计算机必须有足够的内存来存放每个节点的数据库份额（有关详细信息，请参阅 我需要多少内存？）。对于仅用于运行 NDB Cluster 管理服务器的计算机，要求很低；普通桌面计算机（或同等设备）通常足够胜任此任务。节点可以通过标准 TCP/IP 网络和硬件进行通信。它们也可以使用高速 SCI 协议；然而，要使用 SCI 需要专门的网络硬件和软件（参见 第 25.4.4 节 “使用高速互连与 NDB Cluster”）。NDB Cluster should run on any platform for which NDB-enabled binaries are available. For data nodes and API nodes, faster CPUs and more memory are likely to improve performance, and 64-bit CPUs are likely to be more effective than 32-bit processors. There must be sufficient memory on machines used for data nodes to hold each node's share of the database (see How much RAM do I Need? for more information). For a computer which is used only for running the NDB Cluster management server, the requirements are minimal; a common desktop PC (or the equivalent) is generally sufficient for this task. Nodes can communicate through the standard TCP/IP network and hardware. They can also use the high-speed SCI protocol; however, special networking hardware and software are required to use SCI (see Section 25.4.4, “Using High-Speed Interconnects with NDB Cluster”).

NDB Cluster 最初仅以内存方式实现，但目前所有可用版本也提供了将 NDB Cluster 存储在磁盘上的功能。更多信息参见 第 25.6.11 节，“NDB Cluster 磁盘表”。NDB Cluster was originally implemented as in-memory only, but all versions currently available also provide the ability to store NDB Cluster on disk. See Section 25.6.11, “NDB Cluster Disk Data Tables”, for more information.

对于内存中的 NDB 表，你可以使用以下公式粗略估算群集中的每个数据节点所需的 RAM 大小：For in-memory NDB tables, you can use the following formula for obtaining a rough estimate of how much RAM is needed for each data node in the cluster:

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

要更精确地计算内存需求，需要确定集群数据库中每个表每行所需的存储空间（详细信息请参见第 13.7 节，“数据类型存储需求”），并将其乘以行数。您还必须记得考虑任何列索引，如下所示：To calculate the memory requirements more exactly requires determining, for each table in the cluster database, the storage space required per row (see Section 13.7, “Data Type Storage Requirements”, for details), and multiplying this by the number of rows. You must also remember to account for any column indexes as follows:

为所有主键和唯一索引创建使用 USING HASH 的 NDB 集群表通常会使表更新运行得更快——在某些情况下，比未在创建主键和唯一键时使用 USING HASH 的表更新快 20% 到 30%。这是因为所需的内存更少（因为没有创建有序索引），CPU 的使用也更少（因为必须读取和可能更新的索引更少）。然而，这也意味着本可以使用范围扫描的查询必须通过其他方式满足，这可能导致选择操作变慢。Creating NDB Cluster tables with USING HASH for all primary keys and unique indexes generally causes table updates to run more quickly—in some cases by a much as 20 to 30 percent faster than updates on tables where USING HASH was not used in creating primary and unique keys. This is due to the fact that less memory is required (because no ordered indexes are created), and that less CPU must be utilized (because fewer indexes must be read and possibly updated). However, it also means that queries that could otherwise use range scans must be satisfied by other means, which can result in slower selects.

在计算集群内存需求时，您可能会发现最近 MySQL 8.4 版本提供的 ndb_size.pl 工具非常有用。该 Perl 脚本连接到当前（非集群）MySQL 数据库，并生成一份报告，说明如果该数据库使用 NDBCLUSTER 存储引擎，将需要多少空间。有关更多信息，请参阅 第 25.5.29 节，“ndb_size.pl — NDBCLUSTER 大小需求估算器”。When calculating Cluster memory requirements, you may find useful the ndb_size.pl utility which is available in recent MySQL 8.4 releases. This Perl script connects to a current (non-Cluster) MySQL database and creates a report on how much space that database would require if it used the NDBCLUSTER storage engine. For more information, see Section 25.5.29, “ndb_size.pl — NDBCLUSTER Size Requirement Estimator”.

特别重要的是要记住，每个 NDB Cluster 表都必须有一个主键。NDB 存储引擎如果没有定义主键，会自动创建一个主键；该主键在创建时不使用 USING HASH。It is especially important to keep in mind that every NDB Cluster table must have a primary key. The NDB storage engine creates a primary key automatically if none is defined; this primary key is created without USING HASH.

您可以使用 ndb_mgm 客户端中的 REPORT MEMORYUSAGE 命令来确定在任何给定时间用于存储 NDB 集群数据和索引的内存量；更多信息请参见 第 25.6.1 节，“NDB 集群管理客户端的命令”。此外，当已使用可用 DataMemory 80% 或（在 NDB 7.6 之前）IndexMemory 80% 时，会将警告写入集群日志，并且当使用量达到 90%、99% 和 100% 时会再次写入警告。You can determine how much memory is being used for storage of NDB Cluster data and indexes at any given time using the REPORT MEMORYUSAGE command in the ndb_mgm client; see Section 25.6.1, “Commands in the NDB Cluster Management Client”, for more information. In addition, warnings are written to the cluster log when 80% of available DataMemory or (prior to NDB 7.6) IndexMemory is in use, and again when usage reaches 90%, 99%, and 100%.

通常，任何操作系统本地的文件系统都应该能很好地与 NDB Cluster 一起使用。如果您发现某个文件系统与 NDB Cluster 的兼容性特别好（或不太理想），我们欢迎您在 NDB Cluster 论坛 上讨论您的发现。Generally, any file system that is native to the host operating system should work well with NDB Cluster. If you find that a given file system works particularly well (or not so especially well) with NDB Cluster, we invite you to discuss your findings in the NDB Cluster Forums.

对于 Windows，我们建议您像对标准 MySQL 一样，在 NDB Cluster 中使用 NTFS 文件系统。我们没有在 FAT 或 VFAT 文件系统上测试 NDB Cluster。因此，我们不推荐在 MySQL 或 NDB Cluster 中使用它们。For Windows, we recommend that you use NTFS file systems for NDB Cluster, just as we do for standard MySQL. We do not test NDB Cluster with FAT or VFAT file systems. Because of this, we do not recommend their use with MySQL or NDB Cluster.

NDB 集群实现为无共享解决方案；其背后的理念是单个硬件的故障不应导致多个集群节点的故障，甚至可能不会导致整个集群的故障。出于这个原因，NDB 集群不支持使用网络共享或网络文件系统。这同样适用于共享存储设备，如 SAN。NDB Cluster is implemented as a shared-nothing solution; the idea behind this is that the failure of a single piece of hardware should not cause the failure of multiple cluster nodes, or possibly even the failure of the cluster as a whole. For this reason, the use of network shares or network file systems is not supported for NDB Cluster. This also applies to shared storage devices such as SANs.

NDB 集群支持在虚拟机中使用。我们目前支持并测试使用 Oracle VM。NDB Cluster is supported for use in virtual machines. We currently support and test using Oracle VM.

一些 NDB Cluster 用户已经成功使用其他虚拟化产品部署了 NDB Cluster；在这种情况下，Oracle 可以提供 NDB Cluster 支持，但虚拟环境特有的问题必须咨询该产品的供应商。Some NDB Cluster users have successfully deployed NDB Cluster using other virtualization products; in such cases, Oracle can provide NDB Cluster support, but issues specific to the virtual environment must be referred to that product's vendor.

原因很可能是您的设置没有为所有表数据和所有索引提供足够的 RAM，包括 NDB 存储引擎所需的主键，如果表定义中未包含主键定义，主键将会自动创建。The cause is very likely to be that your setup does not provide sufficient RAM for all table data and all indexes, including the primary key required by the NDB storage engine and automatically created in the event that the table definition does not include the definition of a primary key.

同样值得注意的是，所有数据节点应具有相同数量的 RAM，因为集群中的任何数据节点都不能使用超过单个数据节点可用最少内存的容量。例如，如果有四台计算机托管集群数据节点，并且其中三台有 3GB RAM 可用于存储集群数据，而剩余的数据节点只有 1GB RAM，那么每个数据节点最多只能为 NDB 集群数据和索引分配 1GB。It is also worth noting that all data nodes should have the same amount of RAM, since no data node in a cluster can use more memory than the least amount available to any individual data node. For example, if there are four computers hosting Cluster data nodes, and three of these have 3GB of RAM available to store Cluster data while the remaining data node has only 1GB RAM, then each data node can devote at most 1GB to NDB Cluster data and indexes.

在某些情况下，即使使用 ndb_mgm -e "ALL REPORT MEMORYUSAGE" 显示 DataMemory 仍有大量可用内存时，MySQL 客户端应用程序中仍可能出现 Table is full 错误。你可以通过在 CREATE TABLE 中使用 MAX_ROWS 选项，强制 NDB 为 NDB 集群表创建额外的分区，从而为哈希索引提供更多内存。通常，将 MAX_ROWS 设置为预计存储在表中的行数的两倍应该就足够了。In some cases it is possible to get Table is full errors in MySQL client applications even when ndb_mgm -e "ALL REPORT MEMORYUSAGE" shows significant free DataMemory. You can force NDB to create extra partitions for NDB Cluster tables and thus have more memory available for hash indexes by using the MAX_ROWS option for CREATE TABLE. In general, setting MAX_ROWS to twice the number of rows that you expect to store in the table should be sufficient.

出于类似的原因，在数据负载较重的节点上，有时也会遇到数据节点重启的问题。MinFreePct 参数可以通过为重启保留一部分（默认 5%）DataMemory 和（在 NDB 7.6 之前）IndexMemory 来解决此问题。该保留内存不能用于存储 NDB 表或数据。For similar reasons, you can also sometimes encounter problems with data node restarts on nodes that are heavily loaded with data. The MinFreePct parameter can help with this issue by reserving a portion (5% by default) of DataMemory and (prior to NDB 7.6) IndexMemory for use in restarts. This reserved memory is not available for storing NDB tables or data.

It is 非常 unlikely that a cluster would perform reliably under such conditions, as NDB Cluster was designed and implemented with the assumption that it would be run under conditions guaranteeing dedicated high-speed connectivity such as that found in a LAN setting using 100 Mbps or gigabit Ethernet—preferably the latter. We neither test nor warrant its performance using anything slower than this.It is very unlikely that a cluster would perform reliably under such conditions, as NDB Cluster was designed and implemented with the assumption that it would be run under conditions guaranteeing dedicated high-speed connectivity such as that found in a LAN setting using 100 Mbps or gigabit Ethernet—preferably the latter. We neither test nor warrant its performance using anything slower than this.

此外，必须牢记，NDB 集群中节点之间的通信是不安全的；它们既不加密，也没有受到任何其他保护机制的保护。集群最安全的配置是在防火墙后的私有网络中，外部无法直接访问任何集群数据或管理节点。（对于 SQL 节点，您应采取与任何其他 MySQL 服务器实例相同的防护措施。）有关更多信息，请参见 第 25.6.19 节，“NDB 集群安全”。Also, it is extremely important to keep in mind that communications between the nodes in an NDB Cluster are not secure; they are neither encrypted nor safeguarded by any other protective mechanism. The most secure configuration for a cluster is in a private network behind a firewall, with no direct access to any Cluster data or management nodes from outside. (For SQL nodes, you should take the same precautions as you would with any other instance of the MySQL server.) For more information, see Section 25.6.19, “NDB Cluster Security”.

不需要。虽然管理和配置集群本身需要使用一些特殊命令，但以下操作只需要标准的 (My)SQL 语句：No. Although some specialized commands are used to manage and configure the cluster itself, only standard (My)SQL statements are required for the following operations:

设置 NDB 群集需要一些特殊的配置参数和文件——有关这些的更多信息，请参见 第 25.4.3 节，“NDB 群集配置文件”。Some specialized configuration parameters and files are required to set up an NDB Cluster—see Section 25.4.3, “NDB Cluster Configuration Files”, for information about these.

在 NDB 群集管理客户端中使用一些简单的命令（ndb_mgm）来执行例如启动和停止群集节点的任务。请参见 第 25.6.1 节，“NDB 群集管理客户端中的命令”。A few simple commands are used in the NDB Cluster management client (ndb_mgm) for tasks such as starting and stopping cluster nodes. See Section 25.6.1, “Commands in the NDB Cluster Management Client”.

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 supports the same programming APIs and languages as the standard MySQL Server, including ODBC, .Net, the MySQL C API, and numerous drivers for popular scripting languages such as PHP, Perl, and Python. NDB Cluster applications written using these APIs behave similarly to other MySQL applications; they transmit SQL statements to a MySQL Server (in the case of NDB Cluster, an SQL node), and receive responses containing rows of data. For more information about these APIs, see Chapter 31, Connectors and APIs.

NDB 集群还支持使用 NDB API 进行应用程序编程，该 API 提供了一个低级的 C 接口来访问 NDB 集群数据，无需通过 MySQL 服务器。请参阅 NDB API。此外，许多 NDBCLUSTER 管理功能通过 C 语言的 MGM API 暴露；更多信息请参阅 MGM API。NDB Cluster also supports application programming using the NDB API, which provides a low-level C++ interface to NDB Cluster data without needing to go through a MySQL Server. See The NDB API. In addition, many NDBCLUSTER management functions are exposed by the C-language MGM API; see The MGM API, for more information.

NDB 集群还支持使用 ClusterJ 进行 Java 应用程序编程，ClusterJ 使用会话和事务支持数据的领域对象模型。更多信息请参阅 Java 与 NDB Cluster。NDB Cluster also supports Java application programming using ClusterJ, which supports a domain object model of data using sessions and transactions. See Java and NDB Cluster, for more information.

NDB 集群 8.0 还包括支持基于 Node.js 编写的 NoSQL 应用程序的适配器，以 NDB 集群作为数据存储。有关更多信息，请参见 JavaScript 的 MySQL NoSQL 连接器。NDB Cluster 8.0 also includes adapters supporting NoSQL applications written against Node.js, with NDB Cluster as the data store. See MySQL NoSQL Connector for JavaScript, for more information.

NDB 集群包含一个命令行客户端，用于执行基本管理功能。请参阅 第 25.5.5 节，“ndb_mgm — NDB 集群管理客户端”，以及 第 25.6.1 节，“NDB 集群管理客户端中的命令”。NDB Cluster includes a command line client for performing basic management functions. See Section 25.5.5, “ndb_mgm — The NDB Cluster Management Client”, and Section 25.6.1, “Commands in the NDB Cluster Management Client”.

NDB Cluster 也受到 MySQL Cluster Manager 的支持，这是一个独立的产品，提供高级命令行界面，可以自动执行许多 NDB Cluster 管理任务，例如滚动重启和配置更改。有关 MySQL Cluster Manager 的更多信息，请参见 MySQL Cluster Manager 8.4.9 用户手册。NDB Cluster is also supported by MySQL Cluster Manager, a separate product providing an advanced command line interface that can automate many NDB Cluster management tasks such as rolling restarts and configuration changes. For more information about MySQL Cluster Manager, see MySQL Cluster Manager 8.4.9 User Manual.

可以通过两种方式来完成此操作：There are two ways in which this can be done:

是的。对于使用NDB存储引擎创建的表，支持事务。目前，NDB Cluster 仅支持READ COMMITTED事务隔离级别。Yes. For tables created with the NDB storage engine, transactions are supported. Currently, NDB Cluster supports only the READ COMMITTED transaction isolation level.

NDB Cluster 需要NDB存储引擎。也就是说，为了使表可以在 NDB Cluster 的节点之间共享，该表必须使用ENGINE=NDB（或等效选项ENGINE=NDBCLUSTER）创建。NDB Cluster requires the NDB storage engine. That is, in order for a table to be shared between nodes in an NDB Cluster, the table must be created using ENGINE=NDB (or the equivalent option ENGINE=NDBCLUSTER).

在使用 NDB 集群的 MySQL 服务器上，也可以使用其他存储引擎（例如 InnoDB 或 MyISAM）创建表，但由于这些表不使用 NDB，因此它们不会参与集群；每个此类表严格地只存在于创建它的单个 MySQL 服务器实例上。It is possible to create tables using other storage engines (such as InnoDB or MyISAM) on a MySQL server being used with NDB Cluster, but since these tables do not use NDB, they do not participate in clustering; each such table is strictly local to the individual MySQL server instance on which it is created.

NDB 集群在架构、要求和实现方面与 InnoDB 集群有很大不同；尽管它们的名称类似，但两者并不兼容。有关 InnoDB 集群的更多信息，请参见 MySQL AdminAPI。另请参阅 第 25.2.6 节，“MySQL 使用 InnoDB 与 NDB 集群的比较”，了解 NDB 和 InnoDB 存储引擎之间的差异。NDB Cluster is quite different from InnoDB clustering with regard to architecture, requirements, and implementation; despite any similarity in their names, the two are not compatible. For more information about InnoDB clustering, see MySQL AdminAPI. See also Section 25.2.6, “MySQL Server Using InnoDB Compared with NDB Cluster”, for information about the differences between the NDB and InnoDB storage engines.

所有已提交的事务都会被记录。因此，虽然在灾难发生时有可能丢失一些数据，但这种情况应该相当有限。通过最小化每个事务的操作数量，可以进一步减少数据丢失。（无论如何，每个事务执行大量操作都不是一个好主意。）All committed transactions are logged. Therefore, although it is possible that some data could be lost in the event of a catastrophe, this should be quite limited. Data loss can be further reduced by minimizing the number of operations per transaction. (It is not a good idea to perform large numbers of operations per transaction in any case.)

FULLTEXT 索引目前仅由 InnoDB 和 MyISAM 存储引擎支持。更多信息请参见 第 14.9 节，“全文搜索函数”。FULLTEXT indexing is currently supported only by the InnoDB and MyISAM storage engines. See Section 14.9, “Full-Text Search Functions”, for more information.

这是可能的，但并不总是可取的。运行集群的主要原因之一是提供冗余。为了充分利用这种冗余，每个节点应位于不同的机器上。如果你在一台机器上放置多个节点，而该机器发生故障，你将失去所有这些节点。因此，如果你确实在一台机器上运行多个数据节点，那么必须 极其 重要地将它们设置成在这台机器故障时不会导致给定节点组中的所有数据节点丢失的方式。It is possible but not always advisable. One of the chief reasons to run a cluster is to provide redundancy. To obtain the full benefits of this redundancy, each node should reside on a separate machine. If you place multiple nodes on a single machine and that machine fails, you lose all of those nodes. For this reason, if you do run multiple data nodes on a single machine, it is extremely important that they be set up in such a way that the failure of this machine does not cause the loss of all the data nodes in a given node group.

鉴于 NDB Cluster 可以在负载低成本（甚至免费的）操作系统的商用硬件上运行，为保护关键任务数据而增加一两台机器的开销是非常值得的。同时需要注意的是，运行管理节点的集群主机的要求很低。这项任务可以通过 300 MHz 的 Pentium 或同等 CPU 完成，并为操作系统提供足够的内存，加上一小部分用于 ndb_mgmd 和 ndb_mgm 进程的开销。Given that NDB Cluster can be run on commodity hardware loaded with a low-cost (or even no-cost) operating system, the expense of an extra machine or two is well worth it to safeguard mission-critical data. It also worth noting that the requirements for a cluster host running a management node are minimal. This task can be accomplished with a 300 MHz Pentium or equivalent CPU and sufficient RAM for the operating system, plus a small amount of overhead for the ndb_mgmd and ndb_mgm processes.

在具有多个 CPU、核心或两者兼有的主机上运行多个集群数据节点是可以接受的。NDB Cluster 发行版还提供了数据节点二进制文件的多线程版本，旨在用于此类系统。有关更多信息，请参见 第 25.5.3 节，“ndbmtd — NDB Cluster 数据节点守护进程（多线程）”。It is acceptable to run multiple cluster data nodes on a single host that has multiple CPUs, cores, or both. The NDB Cluster distribution also provides a multithreaded version of the data node binary intended for use on such systems. For more information, see Section 25.5.3, “ndbmtd — The NDB Cluster Data Node Daemon (Multi-Threaded)”.

在某些情况下，也可以在同一台机器上同时运行数据节点和 SQL 节点；这种安排的性能取决于多个因素，例如核心和 CPU 数量，以及数据节点和 SQL 节点进程可用的磁盘和内存量，在规划此类配置时必须考虑这些因素。It is also possible in some cases to run data nodes and SQL nodes concurrently on the same machine; how well such an arrangement performs is dependent on a number of factors such as number of cores and CPUs as well as the amount of disk and memory available to the data node and SQL node processes, and you must take these factors into account when planning such a configuration.

可以在不中断集群运行的情况下向正在运行的 NDB 集群添加新的数据节点。有关更多信息，请参见 第 25.6.7 节，“在线添加 NDB 集群数据节点”。It is possible to add new data nodes to a running NDB Cluster without taking the cluster offline. For more information, see Section 25.6.7, “Adding NDB Cluster Data Nodes Online”.

对于其他类型的 NDB 集群节点，只需要滚动重启即可（参见 第 25.6.5 节，“对 NDB 集群执行滚动重启”）。For other types of NDB Cluster nodes, a rolling restart is all that is required (see Section 25.6.5, “Performing a Rolling Restart of an NDB Cluster”).

MySQL NDB 集群中 NDB 表的限制包括以下内容：Limitations on NDB tables in MySQL NDB Cluster include the following:

有关 NDB Cluster 限制的完整列表，请参见 第 25.2.7 节，“NDB Cluster 已知的限制”。另请参见 NDB Cluster 8.0 中已解决的以前 NDB Cluster 问题。For a complete listing of limitations in NDB Cluster, see Section 25.2.7, “Known Limitations of NDB Cluster”. See also Previous NDB Cluster Issues Resolved in NDB Cluster 8.0.

NDB Cluster 提供对外键约束的支持，其功能可与 InnoDB 存储引擎中的功能相媲美；有关更详细的信息，请参见 第 1.7.3.2 节，“外键约束” 以及 第 15.1.20.5 节，“外键约束”。需要外键支持的应用程序应使用 NDB Cluster 7.3、7.4、7.5 或更高版本。NDB Cluster provides support for foreign key constraints which is comparable to that found in the InnoDB storage engine; see Section 1.7.3.2, “FOREIGN KEY Constraints”, for more detailed information, as well as Section 15.1.20.5, “FOREIGN KEY Constraints”. Applications requiring foreign key support should use NDB Cluster 7.3, 7.4, 7.5, or later.

您可以像使用任何其他版本的 MySQL 一样将数据库导入 NDB 集群。除了本常见问题解答中提到的限制之外，唯一的特殊要求是，任何要包含在集群中的表必须使用 NDB 存储引擎。这意味着表必须使用 ENGINE=NDB 或 ENGINE=NDBCLUSTER 创建。You can import databases into NDB Cluster much as you would with any other version of MySQL. Other than the limitations mentioned elsewhere in this FAQ, the only other special requirement is that any tables to be included in the cluster must use the NDB storage engine. This means that the tables must be created with ENGINE=NDB or ENGINE=NDBCLUSTER.

也可以使用一个或多个 ALTER TABLE 语句将使用其他存储引擎的现有表转换为 NDBCLUSTER。但是，在进行转换之前，表的定义必须与 NDBCLUSTER 存储引擎兼容。在 MySQL 8.4 中，还需要额外的解决方法；详情请参见 第 25.2.7 节，“NDB Cluster 的已知限制”。It is also possible to convert existing tables that use other storage engines to NDBCLUSTER using one or more ALTER TABLE statement. However, the definition of the table must be compatible with the NDBCLUSTER storage engine prior to making the conversion. In MySQL 8.4, an additional workaround is also required; see Section 25.2.7, “Known Limitations of NDB Cluster”, for details.

集群节点可以通过三种不同的传输机制进行通信：TCP/IP、SHM（共享内存）和 SCI（可扩展一致接口）。在可用情况下，默认情况下在位于同一集群主机上的节点之间使用 SHM；然而，这被认为是实验性的。SCI 是一种高速（每秒 1 千兆及以上）、高可用性的协议，用于构建可扩展多处理器系统；它需要特殊的硬件和驱动程序。有关将 SCI 用作 NDB 集群传输机制的更多信息，请参见第 25.4.4 节，“使用高速互连与 NDB 集群”。Cluster nodes can communicate through any of three different transport mechanisms: TCP/IP, SHM (shared memory), and SCI (Scalable Coherent Interface). Where available, SHM is used by default between nodes residing on the same cluster host; however, this is considered experimental. SCI is a high-speed (1 gigabit per second and higher), high-availability protocol used in building scalable multi-processor systems; it requires special hardware and drivers. See Section 25.4.4, “Using High-Speed Interconnects with NDB Cluster”, for more about using SCI as a transport mechanism for NDB Cluster.

如果集群中的一个或多个数据节点失败，可能并非所有集群数据节点都能够互相“看到””。实际上，在网络分区中，两个数据节点集可能会相互隔离，这种情况也称为“脑裂”场景。这种情况是不理想的，因为每组数据节点都试图表现得好像它是整个集群一样。需要一个仲裁者来在竞争的数据节点集之间做出决定。If one or more data nodes in a cluster fail, it is possible that not all cluster data nodes are able to “see” one another. In fact, it is possible that two sets of data nodes might become isolated from one another in a network partitioning, also known as a “split-brain” scenario. This type of situation is undesirable because each set of data nodes tries to behave as though it is the entire cluster. An arbitrator is required to decide between the competing sets of data nodes.

当至少一个节点组中的所有数据节点都存活时，网络分区不是问题，因为集群的任何单一子集都无法独立形成一个功能性集群。真正的问题出现在没有单个节点组的所有节点都存活的情况下，这时网络分区（即“脑裂”场景）就有可能发生。此时需要一个仲裁者。所有集群节点会将同一个节点识别为仲裁者，通常是管理服务器；但是，也可以将集群中的任何 MySQL 服务器配置为仲裁者。仲裁者接受首先联系它的集群节点组，并告诉其余节点组关闭。仲裁者的选择由 MySQL 服务器和管理服务器节点的 ArbitrationRank 配置参数控制。你也可以使用 ArbitrationRank 配置参数来控制仲裁者的选择过程。有关这些参数的更多信息，请参见 第 25.4.3.5 节，“定义 NDB 集群管理服务器”。When all data nodes in at least one node group are alive, network partitioning is not an issue, because no single subset of the cluster can form a functional cluster on its own. The real problem arises when no single node group has all its nodes alive, in which case network partitioning (the “split-brain” scenario) becomes possible. Then an arbitrator is required. All cluster nodes recognize the same node as the arbitrator, which is normally the management server; however, it is possible to configure any of the MySQL Servers in the cluster to act as the arbitrator instead. The arbitrator accepts the first set of cluster nodes to contact it, and tells the remaining set to shut down. Arbitrator selection is controlled by the ArbitrationRank configuration parameter for MySQL Server and management server nodes. You can also use the ArbitrationRank configuration parameter to control the arbitrator selection process. For more information about these parameters, see Section 25.4.3.5, “Defining an NDB Cluster Management Server”.

仲裁者的角色本身并不会对被指定的主机施加任何沉重的要求，因此仲裁者主机不需要特别快或为此目的配置额外内存。The role of arbitrator does not in and of itself impose any heavy demands upon the host so designated, and thus the arbitrator host does not need to be particularly fast or to have extra memory especially for this purpose.

NDB 集群支持所有常用的 MySQL 数据类型，包括与 MySQL 空间扩展相关的数据类型；然而，NDB 存储引擎不支持空间索引。（空间索引仅由 MyISAM 支持；有关更多信息，请参见 第 13.4 节，“空间数据类型”。）此外，在 NDB 表上使用索引时，也存在一些差异。NDB Cluster supports all of the usual MySQL data types, including those associated with MySQL's spatial extensions; however, the NDB storage engine does not support spatial indexes. (Spatial indexes are supported only by MyISAM; see Section 13.4, “Spatial Data Types”, for more information.) In addition, there are some differences with regard to indexes when used with NDB tables.

有关这些问题的更多信息，请参见 第 25.2.7 节，“NDB 集群的已知限制”。See Section 25.2.7, “Known Limitations of NDB Cluster”, for more information about these issues.

有必要按照以下顺序分别启动群集中的每个节点：It is necessary to start each node in the cluster separately, in the following order:

这些命令必须在托管受影响节点的计算机上的系统 shell 中运行。（你不必亲自到计算机前——可以使用远程登录 shell 来执行。）你可以通过在管理节点所在的计算机上启动NDB管理客户端ndb_mgm并执行SHOW或ALL STATUS命令来验证集群是否正在运行。Each of these commands must be run from a system shell on the machine housing the affected node. (You do not have to be physically present at the machine—a remote login shell can be used for this purpose.) You can verify that the cluster is running by starting the NDB management client ndb_mgm on the machine housing the management node and issuing the SHOW or ALL STATUS command.

要关闭正在运行的集群，在管理客户端中执行SHUTDOWN命令。或者，你也可以在系统 shell 中输入以下命令：To shut down a running cluster, issue the command SHUTDOWN in the management client. Alternatively, you may enter the following command in a system shell:

$> ndb_mgm -e "SHUTDOWN"

（这个示例中的引号是可选的，因为在 -e 选项后面的命令字符串中没有空格；另外，SHUTDOWN 命令像其他管理客户端命令一样，不区分大小写。）(The quotation marks in this example are optional, since there are no spaces in the command string following the -e option; in addition, the SHUTDOWN command, like other management client commands, is not case-sensitive.)

这些命令中的任何一个都会导致 ndb_mgm、ndb_mgm 以及任何 ndbd 进程优雅地终止。运行作为 SQL 节点的 MySQL 服务器可以使用 mysqladmin shutdown 来停止。Either of these commands causes the ndb_mgm, ndb_mgm, and any ndbd processes to terminate gracefully. MySQL servers running as SQL nodes can be stopped using mysqladmin shutdown.

有关更多信息，请参见 第 25.6.1 节，“NDB 集群管理客户端中的命令”，以及 第 25.3.6 节，“NDB 集群的安全关闭和重启”。For more information, see Section 25.6.1, “Commands in the NDB Cluster Management Client”, and Section 25.3.6, “Safe Shutdown and Restart of NDB Cluster”.

MySQL 集群管理器提供了处理 NDB 集群节点启动和停止的其他方法。有关该工具的更多信息，请参见 MySQL Cluster Manager 8.4.9 用户手册。MySQL Cluster Manager provides additional ways to handle starting ansd stopping of NDB Cluster nodes. See MySQL Cluster Manager 8.4.9 User Manual, for more information about this tool.

集群的数据节点中保存在内存中的数据会写入磁盘，并在集群下次启动时重新加载到内存中。The data that was held in memory by the cluster's data nodes is written to disk, and is reloaded into memory the next time that the cluster is started.

这可以作为一种故障保护方案。任意时刻只有一个管理节点控制集群，但可以将一个管理节点配置为主节点，将一个或多个附加管理节点配置为在主管理节点发生故障时接管。It can be helpful as a fail-safe. Only one management node controls the cluster at any given time, but it is possible to configure one management node as primary, and one or more additional management nodes to take over in the event that the primary management node fails.

有关如何配置 NDB 集群管理节点的信息，请参见 第 25.4.3 节，“NDB 集群配置文件”。See Section 25.4.3, “NDB Cluster Configuration Files”, for information on how to configure NDB Cluster management nodes.

是的，只要所有机器和操作系统具有相同的 “字节序”（全部为大端或全部为小端）。Yes, as long as all machines and operating systems have the same “endianness” (all big-endian or all little-endian).

也可以在不同节点上使用来自不同 NDB Cluster 版本的软件下载。然而，我们仅在滚动升级程序的一部分中支持这种使用（参见第 25.6.5 节，“执行 NDB Cluster 的滚动重启”）。It is also possible to use software from different NDB Cluster releases on different nodes. However, we support such use only as part of a rolling upgrade procedure (see Section 25.6.5, “Performing a Rolling Restart of an NDB Cluster”).

是的，这是可行的。在有多个数据节点的情况下，建议（但不是必须）每个节点使用不同的数据目录。如果您想在一台机器上运行多个 SQL 节点，每个 mysqld 实例必须使用不同的 TCP/IP 端口。Yes, it is possible to do this. In the case of multiple data nodes, it is advisable (but not required) for each node to use a different data directory. If you want to run multiple SQL nodes on one machine, each instance of mysqld must use a different TCP/IP port.

在同一主机上同时运行数据节点和 SQL 节点是可能的，但您应当注意，ndbd 或 ndbmtd 进程可能会与 mysqld 争夺内存。Running data nodes and SQL nodes together on the same host is possible, but you should be aware that the ndbd or ndbmtd processes may compete for memory with mysqld.

是的，可以使用 DNS 和 DHCP 来配置集群主机。不过，如果你的应用需要“五个九”的可用性，你应该使用固定（数字）IP 地址，因为让集群主机之间的通信依赖于诸如 DNS 和 DHCP 之类的服务会增加潜在的故障点。Yes, it is possible to use DNS and DHCP for cluster hosts. However, if your application requires “five nines” availability, you should use fixed (numeric) IP addresses, since making communication between Cluster hosts dependent on services such as DNS and DHCP introduces additional potential points of failure.

所有类型的 NDB 集群节点都支持 IPv6，包括管理节点、数据节点以及 API 或 SQL 节点。All types of NDB Cluster nodes support IPv6; this includes management nodes, data nodes, and API or SQL nodes.

MySQL 用户账户和权限通常不会在访问相同 NDB 集群的不同 MySQL 服务器之间自动传播。MySQL NDB 集群通过使用 NDB_STORED_USER 权限支持共享和同步的用户及权限；请参阅 使用共享授权表的分布式权限，了解更多信息。您应该注意，这种实现是在 NDB 8.0 中引入的，并且与早期 NDB 集群版本中使用的共享权限机制不兼容。旧的实现已不再在 NDB 8.0 中受到支持。MySQL user accounts and privileges are normally not automatically propagated between different MySQL servers accessing the same NDB Cluster. MySQL NDB Cluster provides support for shared and synchronized users and privileges using the NDB_STORED_USER privilege; see Distributed Privileges Using Shared Grant Tables, for more information. You should be aware that this implementation was introduced in NDB 8.0, and is not compatible with the shared privileges mechanism employed in earlier versions of NDB Cluster. The older implementation is no longer supported in NDB 8.0.

MySQL NDB 集群不提供 SQL 节点之间的任何自动故障转移功能。您的应用程序必须准备好处理 SQL 节点的丢失并在它们之间进行故障切换。MySQL NDB Cluster does not provide any sort of automatic failover between SQL nodes. Your application must be prepared to handle the loss of SQL nodes and to fail over between them.

您可以在 NDB 管理客户端中使用 NDB 集群的原生备份和恢复功能，以及 ndb_restore 程序。请参见 第 25.6.8 节，“NDB 集群的在线备份”，以及 第 25.5.23 节，“ndb_restore — 恢复 NDB 集群备份”。You can use the NDB Cluster native backup and restore functionality in the NDB management client and the ndb_restore program. See Section 25.6.8, “Online Backup of NDB Cluster”, and Section 25.5.23, “ndb_restore — Restore an NDB Cluster Backup”.

您还可以使用 mysqldump 和 MySQL 服务器提供的用于此目的的传统功能。有关更多信息，请参见 第 6.5.4 节，“mysqldump — 数据库备份程序”。You can also use the traditional functionality provided for this purpose in mysqldump and the MySQL server. See Section 6.5.4, “mysqldump — A Database Backup Program”, for more information.

该进程会监控数据节点进程，并在必要时尝试重新启动该进程。如果在启动 ndbd 后检查系统上的活动进程列表，你会看到实际上有两个具有该名称的进程在运行，如下所示（为了简洁，我们省略了来自 ndb_mgmd 和 ndbd 的输出）：This process monitors and, if necessary, attempts to restart the data node process. If you check the list of active processes on your system after starting ndbd, you can see that there are actually 2 processes running by that name, as shown here (we omit the output from ndb_mgmd and ndbd for brevity):

$> ./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进程是天使进程（尽管它实际上确实使用了非常少量的资源）。该进程仅用于检查主ndbd或ndbmtd进程（实际上处理数据的主要数据节点进程）是否正在运行。如果被允许（例如，如果StopOnError配置参数设置为false），天使进程会尝试重启主要数据节点进程。The ndbd process showing 0.0 for both memory and CPU usage is the angel process (although it actually does use a very small amount of each). This process merely checks to see if the main ndbd or ndbmtd process (the primary data node process which actually handles the data) is running. If permitted to do so (for example, if the StopOnError configuration parameter is set to false), the angel process tries to restart the primary data node process.