NDB Cluster 的优势之一是它可以在普通硬件上运行，并且在这方面没有特殊要求，除了大量内存，因为所有实时数据存储都在内存中完成。（可以使用磁盘数据表来减少此要求，有关这些表的更多信息，请参见 第 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 的生产版本。为了能够使用 NDB Cluster，并不是严格要求您自己编译 MySQL。我们假设您正在使用适用于您的平台的二进制文件，这些文件可以在 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 不足，或者由于交换而出现延迟，这可能无法实现。如果心跳生成延迟足够长，其他节点会将响应缓慢的节点视为故障节点。

根据节点运行缓慢对群集其余部分的影响，在某些情况下，将运行缓慢的节点视为故障节点可能是或可能不是可取的。设置超时值（例如 HeartbeatIntervalDbDb 和 HeartbeatIntervalDbApi）时，必须谨慎选择这些值，以便快速检测到故障，并实现故障转移和恢复服务，同时避免可能代价高昂的误报。

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

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