本文仅为官方文件之翻译

MySQL集群硬件，软件，网络要求

MySQL集群的一个强悍的地方在于它可以运行在普通的硬件上，不需要太大容量的内存（因为所有的活动数据都存储在内存）。（使用磁盘数据表可以减少这样的要求，更多内容请看Section 18.5.12,“MySQL Cluster Disk DataTables”）多核和更快的CPU可以加强性能。自然的，集群进程对内存的需求也就相应变小。

MySQL集群对硬件的需求更多的可以用适中来描述。主机的操作系统不需要特殊的模块、服务、应用或者特别的为集群所做的配置。为了支持操作系统，一个标准的安装程序应该就足够了。MySQL软件对系统要求很简单：所有需要的东西就是一个MySQL的发行版本。如果仅仅使用MySQL集群的话，那么自行编译是没有必要的。这里假设你是用了符合你平台的MySQL集群的发行版二进制程序。

MySQL集群支持任何标准的TCP/IP网络，主机间的最小带宽应该是100Mbps，加上一个交换机，集线器，或者路由器使整个网络可以以一个整体的方式在集群中工作。我们强烈建议一个集群应验运行在它自己的子网上，子网上应该没有其它的不是集群中的机器来分享带宽。这么做的原因基于一下几点：

安全。 MySQL集群中节点之间的通讯没有任何形式的加密或者保护。唯一使你的MySQL的传输安全的手段是使你的集群运行在一个受保护的网络里面。如果你需要你的MySQL集群以Web程序的方式运行，那么你绝对应该保证你的集群在防火墙内，不在你的网络的非安全区。

效率。一个独享网络的集群可以最大限度的利用网络的带宽。使用独立的交换机不仅仅使你可以防止非法访问数据，也可以保证你的MySQL集群的节点免受网络中其它主机的干扰。为了更强的可靠性，你可以使用多个交换机和多个卡（可能是网卡）来世网络免受点单故障；很多设备的驱动都是支持失败转移的。

网络通信以及延时。MySQL集群需要数据节点和查询节点之间有通信，数据节点之间也需要通信。这些进程之间的通信延时会直接影响到用户查询的效率。另外，为了保持一致性以和服务，即使发生节点故障，MySQL集群使用心跳检测以及超时机制来检测一个节点是否失效。这种方式会降低冗余。回忆一下，为了保证数据的一致性，一个节点组中的节点全部失效造成集群关闭。因此，为了避免强制关闭的风险，节点之间的通信中断应该被极力避免。

一个数据节点或者API节点的失效会造成这个失效节点中所有未提交事务的中止。再一个失效的数据节点恢复工作之前，数据节点的恢复需要从失效节点的备份数据中同步（拥有备份数据的节点必须没有同时失效），重建需要磁盘的重建以及检查点日志。这个恢复操作可能需要一些时间，在这段时间里集群的冗余性是没有保障的。

心跳检测依赖于所有节点周期性的产生心跳信号，但是如果节点的负载过重（因为其它程序和节点共享CPU），或者因为交换延时，那么心跳信号有可能不会产生。如果一个节点的心跳信号产生失败，那么其它节点会认为那个节点失效了。

这种把慢节点当作失效节点的做法在某些环境中也许不令人满意，取决于节点的缓慢对集群中其它节点的影响。当给集群设置了HeartbeatIntervalDbDb 和HeartbeatIntervalDbApi参数，那么我们要关心的就是快速的检测，失效转移，以及恢复服务。这样可以避免潜在的昂贵错误。

当节点间的通信延时比LAN环境的期望（大约100us）延时高很多的时候，那么timeout参数应该保证任何允许内的延时是在其范围内的。增加timeout参数的值会对集群最差发现节点失效的时间有影响，因此也影响了服务的恢复。

LAN环境是可以做到稳定的低延时的，因此集群可以提供给失效转移提供冗余性。在TCP水平，单个的链接失败可以迅速的被恢复，使得时延是可控的。WAN环境可能会造成一定范围的时延，以及一定的失效转移的缓慢。单独的链接失败也许需要路由器改变以便于在终端与终端的链接恢复之前进行传播。在TCP水平这个可能造成在独立通道上的大延时。在这种情形之下，TCP的最差时延与IP层在路由之间的传播的最差时间有关。