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

增加数据节点上的 CPU 数量、使用更快的 CPU 或者两者都可以，通常可以提高 NDB 集群的性能。集群进程的内存要求（除了数据节点）相对较小。

NDB 集群的软件要求也很 modest。主机操作系统不需要任何特殊的模块、服务、应用程序或配置来支持 NDB 集群。对于支持的操作系统，标准安装应该足够。MySQL 软件要求很简单：只需要生产版本的 NDB 集群。编译 MySQL 自己并不一定需要使用 NDB 集群。我们假设您正在使用适合您平台的二进制文件，来自 NDB 集群软件下载页面 https://dev.mysql.com/downloads/cluster/。

对于节点之间的通信，NDB 集群支持 TCP/IP 网络在任何标准拓扑结构中，并且每个主机的最低要求是一个标准的 100 Mbps 以太网卡，另外还需要一个交换机、集线器或路由器来提供集群的网络连接。我们强烈建议在自己的子网上运行 NDB 集群，而不是与其他机器共享网络，因为：

网络通信和延迟。 NDB 集群需要在数据节点和 API 节点（包括 SQL 节点）之间、以及在数据节点之间进行通信，以执行查询和更新。这些进程之间的通信延迟可以直接影响用户查询的性能和延迟。此外，为了维持一致性和服务，即使节点失败，NDB 集群使用心跳和超时机制，这可能会导致节点的失效。因此，应该尽量避免节点之间的通信中断。

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

心跳信号的生成依赖于所有节点的及时生成。这可能不可能实现，如果节点过载、机器CPU不足（由于与其他程序共享）或由于交换延迟。如果心跳信号的生成延迟太长，其他节点将认为慢响应的节点已经失败。

在某些情况下，将慢节点视为失败节点可能是或不是可取的，取决于节点的减速操作对集群的影响。在设置超时值时，如HeartbeatIntervalDbDb和HeartbeatIntervalDbApi，必须小心地平衡快速检测、故障转移和服务恢复，同时避免可能的虚假警报。

在数据节点之间的通信延迟预计高于局域网环境（约100 µs）时，必须增加超时参数，以确保允许的延迟期内的任何延迟都在配置的超时范围内。这样做将增加检测故障和服务恢复的最坏情况时间。

局域网环境通常可以配置为稳定的低延迟环境，提供快速故障转移。单个链路故障可以在TCP级别上快速恢复（NDB Cluster通常在此级别上操作）。广域网环境可能提供一系列延迟，以及较慢的故障转移时间。单个链路故障可能需要路由更改以恢复端到端的连接。在TCP级别上，这可能表现为单个通道上的大延迟。这种情况下的最坏情况TCP延迟与IP层 reroute 故障的最坏情况时间相关。