One of the strengths of NDB Cluster is that it can be run on commodity hardware and has no unusual requirements in this regard, other than for large amounts of RAM, due to the fact that all live data storage is done in memory. (It is possible to reduce this requirement using Disk Data tables—see Section 25.6.11, “NDB Cluster Disk Data Tables”, for more information about these.) You can obtain information about memory usage by data nodes by viewing the ndbinfo.memoryusage table, or the output of the REPORT MemoryUsage command in the ndb_mgm client. For information about memory used by NDB tables, you can query the ndbinfo.memory_per_fragment权限。One of the strengths of NDB Cluster is that it can be run on commodity hardware and has no unusual requirements in this regard, other than for large amounts of RAM, due to the fact that all live data storage is done in memory. (It is possible to reduce this requirement using Disk Data tables—see Section 25.6.11, “NDB Cluster Disk Data Tables”, for more information about these.) You can obtain information about memory usage by data nodes by viewing the ndbinfo.memoryusage table, or the output of the REPORT MemoryUsage command in the ndb_mgm client. For information about memory used by NDB tables, you can query the ndbinfo.memory_per_fragment table.

增加托管数据节点的计算机上的 CPU 数量、使用更快的 CPU 或两者结合，通常可以提高 NDB 集群的性能。除了数据节点之外，集群进程的内存需求相对较小。Increasing the number of CPUs, using faster CPUs, or both, on the computers hosting data nodes can generally be expected to enhance the performance of NDB Cluster. Memory requirements for cluster processes other than the data nodes are relatively small.

NDB Cluster 的软件需求也很适中。主机操作系统不需要任何特殊的模块、服务、应用程序或配置来支持 NDB Cluster。对于受支持的操作系统，标准安装应该就足够了。MySQL 的软件需求很简单：所需的只是 NDB Cluster 的生产版本。为了使用 NDB Cluster，并不严格要求自己编译 MySQL。我们假设您使用的是适合您平台的二进制文件，可从 NDB Cluster 软件下载页面下载：https://dev.mysql.com/downloads/cluster/。The software requirements for NDB Cluster are also modest. Host operating systems do not require any unusual modules, services, applications, or configuration to support NDB Cluster. For supported operating systems, a standard installation should be sufficient. The MySQL software requirements are simple: all that is needed is a production release of NDB Cluster. It is not strictly necessary to compile MySQL yourself merely to be able to use NDB Cluster. We assume that you are using the binaries appropriate to your platform, available from the NDB Cluster software downloads page at https://dev.mysql.com/downloads/cluster/.

为了节点之间的通信，NDB Cluster 在任何标准拓扑中都支持 TCP/IP 网络，每个主机的最低要求是一块标准的 100 Mbps 网卡，以及一个交换机、集线器或路由器，以为整个集群提供网络连接。For communication between nodes, NDB Cluster supports TCP/IP networking in any standard topology, and the minimum expected for each host is a standard 100 Mbps Ethernet card, plus a switch, hub, or router to provide network connectivity for the cluster as a whole.

我们强烈建议将 NDB 集群运行在自己的子网中，该子网不与不属于集群的计算机共享；使用私有或受保护的网络可以让集群专用带宽用于集群主机之间的通信。为 NDB 集群安装使用单独的交换机不仅有助于防止未经授权访问存储在集群中的数据，还可以确保集群节点不受网络上其他计算机传输干扰的影响。为了增强可靠性，可以使用双交换机和双网卡，将网络从单点故障中移除；许多设备驱动程序支持此类通信链路的故障切换。We strongly recommend that an NDB Cluster be run on its own subnet which is not shared with machines not forming part of the cluster; using a private or protected network allows the cluster to make exclusive use of bandwidth between cluster hosts. Using a separate switch for your NDB Cluster installation not only helps protect against unauthorized access to data stored in the cluster, but also ensures that cluster nodes are shielded from interference caused by transmissions between other computers on the network. For enhanced reliability, you can use dual switches and dual cards to remove the network as a single point of failure; many device drivers support failover for such communication links.

NDB 支持加密的实时和备份文件及文件系统，如 第 25.6.19.4 节，“NDB 集群的文件系统加密” 所述。第 25.6.19.5 节，“NDB 集群的 TLS 链接加密” 提供了关于启用节点之间加密连接支持的信息。加密备份可以被许多 NDB 命令行程序读取，包括 ndb_restore、ndbxfrm、ndb_print_backup_file 和 ndb_mgm。有关创建加密备份的更多信息，请参见 第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”。NDB supports encrypted live and backup files and file systems, as discussed in Section 25.6.19.4, “File System Encryption for NDB Cluster”. Section 25.6.19.5, “TLS Link Encryption for NDB Cluster”, provides information about enabling support for encrypted connections between nodes. Encrypted backups can be read by many NDB command-line programs including ndb_restore, ndbxfrm, ndb_print_backup_file, and ndb_mgm. See Section 25.6.8.2, “Using The NDB Cluster Management Client to Create a Backup”, for more information about creating encypted backups.

NDB 集群还支持节点之间的加密网络连接；详情请参阅第 25.6.19.4 节，“NDB 集群文件系统加密”。NDB Cluster also supports encrypted network connections between nodes; see Section 25.6.19.4, “File System Encryption for NDB Cluster”, for details.

网络通信和延迟。 NDB 集群需要数据节点与 API 节点（包括 SQL 节点）之间，以及数据节点与其他数据节点之间的通信，以执行查询和更新操作。这些进程之间的通信延迟会直接影响用户查询的实际性能和延迟。此外，为了在节点静默失败的情况下保持一致性和服务，NDB 集群使用心跳和超时机制，将来自某个节点的长时间通信中断视为节点故障。这可能导致冗余度下降。请记住，为了保持数据一致性，当节点组中的最后一个节点发生故障时，NDB 集群会关闭。因此，为了避免增加被迫关闭的风险，应尽可能避免节点之间的通信中断。Network communication and latency.  NDB Cluster requires communication between data nodes and API nodes (including SQL nodes), as well as between data nodes and other data nodes, to execute queries and updates. Communication latency between these processes can directly affect the observed performance and latency of user queries. In addition, to maintain consistency and service despite the silent failure of nodes, NDB Cluster uses heartbeating and timeout mechanisms which treat an extended loss of communication from a node as node failure. This can lead to reduced redundancy. Recall that, to maintain data consistency, an NDB Cluster shuts down when the last node in a node group fails. Thus, to avoid increasing the risk of a forced shutdown, breaks in communication between nodes should be avoided wherever possible.

数据或 API 节点的故障会导致涉及该故障节点的所有未提交事务中止。数据节点的恢复需要将故障节点的数据与存活的数据节点同步，并重新建立基于磁盘的重做和检查点日志，然后数据节点才能重新投入服务。这种恢复可能需要一些时间，在此期间，集群将以降低的冗余水平运行。The failure of a data or API node results in the abort of all uncommitted transactions involving the failed node. Data node recovery requires synchronization of the failed node's data from a surviving data node, and re-establishment of disk-based redo and checkpoint logs, before the data node returns to service. This recovery can take some time, during which the Cluster operates with reduced redundancy.

心跳依赖于所有节点及时生成心跳信号。如果节点负载过高、因与其他程序共享资源而 CPU 不足，或由于交换导致延迟，则可能无法及时生成心跳。如果心跳生成严重延迟，其他节点会将响应缓慢的节点视为故障节点。Heartbeating relies on timely generation of heartbeat signals by all nodes. This may not be possible if the node is overloaded, has insufficient machine CPU due to sharing with other programs, or is experiencing delays due to swapping. If heartbeat generation is sufficiently delayed, other nodes treat the node that is slow to respond as failed.

将一个运行缓慢的节点视为一个故障节点在某些情况下可能是可取的，也可能不可取，这取决于该节点运行缓慢对集群其他部分的影响。在为 NDB Cluster 设置如 HeartbeatIntervalDbDb 和 HeartbeatIntervalDbApi 等超时值时，必须小心以实现快速检测、故障切换和恢复服务，同时避免可能代价高昂的误报。This treatment of a slow node as a failed one may or may not be desirable in some circumstances, depending on the impact of the node's slowed operation on the rest of the cluster. When setting timeout values such as HeartbeatIntervalDbDb and HeartbeatIntervalDbApi for NDB Cluster, care must be taken care to achieve quick detection, failover, and return to service, while avoiding potentially expensive false positives.

当数据节点之间的通信延迟预计高于局域网环境中预期的延迟（大约 100 微秒）时，必须增加超时参数，以确保任何允许的延迟期都在配置的超时范围内。以这种方式增加超时会对检测故障的最坏情况时间以及服务恢复的时间产生相应影响。Where communication latencies between data nodes are expected to be higher than would be expected in a LAN environment (on the order of 100 µs), timeout parameters must be increased to ensure that any allowed periods of latency periods are well within configured timeouts. Increasing timeouts in this way has a corresponding effect on the worst-case time to detect failure and therefore time to service recovery.

局域网（LAN）环境通常可以配置为低延迟稳定，并且能够提供具有快速故障切换的冗余。单个链路故障可以在 TCP 层（NDB Cluster 通常运行的地方）以最小且可控的延迟恢复。广域网（WAN）环境可能会提供不同的延迟，以及具有较慢故障切换时间的冗余。单个链路故障可能需要路由更改传播之后才能恢复端到端连接。在 TCP 层，这可能表现为单个通道上的高延迟。在这些场景中观察到的最坏情况 TCP 延迟与 IP 层绕过故障的最坏情况时间相关。LAN environments can typically be configured with stable low latency, and such that they can provide redundancy with fast failover. Individual link failures can be recovered from with minimal and controlled latency visible at the TCP level (where NDB Cluster normally operates). WAN environments may offer a range of latencies, as well as redundancy with slower failover times. Individual link failures may require route changes to propagate before end-to-end connectivity is restored. At the TCP level this can appear as large latencies on individual channels. The worst-case observed TCP latency in these scenarios is related to the worst-case time for the IP layer to reroute around the failures.