NDB Cluster 的优势之一是它可以在商品硬件上运行，并且在这方面没有特殊的要求，除了需要大量的 RAM，因为所有活动数据存储都在内存中进行。（可以使用磁盘数据表来减少此要求，有关这些内容的更多信息，请参阅第 25.6.11 节“NDB Cluster 磁盘数据表”。）可以通过查看ndbinfo.memoryusage 表或REPORT MemoryUsage 命令的输出（在 ndb_mgm 客户端中）来获取有关数据节点的内存使用情况的信息。有关NDB 表使用的内存信息，可以查询ndbinfo.memory_per_fragment 表。

在托管数据节点的计算机上增加 CPU 数量，使用更快的 CPU 或同时进行这两项操作，通常可以预期会提高 NDB Cluster 的性能。除数据节点之外的群集进程的内存需求相对较小。

NDB Cluster 的软件要求也很低。主机操作系统不需要任何特殊的模块、服务、应用程序或配置来支持 NDB Cluster。对于支持的操作系统，标准安装就足够了。MySQL 软件要求很简单：只需要 NDB Cluster 的生产版即可。无需自行编译 MySQL 即可使用 NDB Cluster。我们假设您使用的是适合您平台的二进制文件，这些二进制文件可以在 NDB Cluster 软件下载页面上找到：https://dev.mysqlserver.cn/downloads/cluster/。

为了在节点之间进行通信，NDB Cluster 支持任何标准拓扑中的 TCP/IP 网络，并且每个主机都至少需要一个标准 100 Mbps 以太网卡，加上一个交换机、集线器或路由器来为整个群集提供网络连接。我们强烈建议将 NDB Cluster 运行在自己的子网上，不与不属于群集的机器共享，原因如下：

网络通信和延迟。 NDB Cluster 需要在数据节点和 API 节点（包括 SQL 节点）之间以及数据节点和数据节点之间进行通信，以执行查询和更新。这些进程之间的通信延迟会直接影响用户查询的观察到的性能和延迟。此外，为了保持一致性和服务，即使节点静默故障，NDB Cluster 也使用心跳和超时机制，将来自节点的长时间通信丢失视为节点故障。这会导致冗余度降低。请记住，为了保持数据一致性，当节点组中的最后一个节点发生故障时，NDB Cluster 会关闭。因此，为了避免增加强制关闭的风险，应尽可能避免节点之间的通信中断。

数据节点或 API 节点的故障会导致涉及故障节点的所有未提交事务中止。数据节点恢复需要从存活数据节点同步故障节点的数据，并重新建立基于磁盘的重做和检查点日志，然后数据节点才能恢复服务。此恢复可能需要一些时间，在此期间群集以降低的冗余度运行。

心跳依赖于所有节点及时生成心跳信号。如果节点过载、由于与其他程序共享而导致机器 CPU 不足或由于交换而导致延迟，则可能无法实现。如果心跳生成延迟足够长，其他节点会将响应速度慢的节点视为故障节点。

在某些情况下，将响应速度慢的节点视为故障节点可能是可取的，也可能是不必要的，具体取决于节点运行速度变慢对群集其余部分的影响。在设置 NDB Cluster 的超时值（如HeartbeatIntervalDbDb 和HeartbeatIntervalDbApi）时，必须小心谨慎，以确保快速检测、故障转移和恢复服务，同时避免可能导致昂贵误报。

如果预期数据节点之间的通信延迟高于 LAN 环境中预期的延迟（大约 100 µs），则必须增加超时参数，以确保所有允许的延迟期都远在配置的超时时间内。以这种方式增加超时时间会相应地影响检测故障的最坏情况时间，因此也影响服务恢复时间。

LAN 环境通常可以使用稳定的低延迟配置，并且可以提供快速故障转移的冗余。单个链路故障可以在 TCP 层（NDB Cluster 通常在该层运行）出现最小且可控的延迟的情况下恢复。WAN 环境可能提供一系列延迟，以及更慢的故障转移时间的冗余。单个链路故障可能需要路由更改才能传播，然后才能恢复端到端连接。在 TCP 层，这可能表现为单个通道上的大延迟。这些情况下观察到的最坏情况 TCP 延迟与 IP 层在故障周围重新路由的最坏情况时间有关。