从MySQL 5.1开始，数据不再需要完全存储在内存中。
我已经读到索引列（我认为整个索引结构）必须仍在内存中（MySQL High Availability，2010，第533页，“ MySQL群集将所有索引列保留在主内存中”）。
有鉴于此，如果没有足够的内存（例如，巨大的数据库（> 100GB或1TB），且内存配置较低（例如2个数据节点，每个内存1GB）的服务器上运行）会发生什么？
Answers:
MySQL Cluster支持使用最近访问的数据的LRU高速缓存仅在磁盘上存储非索引列。但是，索引列始终保留在内存中。
MySQL Cluster根据DataMemory和IndexMemory参数预先分配所有内存。它不会动态要求底层操作系统提供更多内存。
这意味着您需要在整个群集中配置足够的内存以将所有索引列保存在内存中。如果您的数据集足够大，以至于索引列大于可用的群集内存，则您无法将该数据集加载到群集中。在某些时候，您将用完空间，并且插入事务将被中止。
在配置DataMemory和IndexMemory时，最好将自己限制为小于每个系统中的物理内存。应该为OS和其他进程保留一些物理内存。
从理论上讲，可以配置MySQL群集，以便它通过交换设备使用虚拟内存（例如，比物理内存更多），但是在其他回答状态下，这不是设计用例。将内存中的结构交换到磁盘通常不是最佳选择，因为内存中的随机访问模式会导致对磁盘的随机访问，从而导致整个系统的交换异常和速度变慢。对于MySQL Cluster，最有可能的结果是心跳故障和群集故障，这是由于交换数据节点对信号的响应速度不够快所致。
为了有效地支持大于聚合的内存索引，MySQL Cluster将需要支持磁盘索引格式（也许是B树等），并具有与磁盘访问属性对齐的缓存和访问模式。
MySQL集群是围绕索引结构构建的，该索引结构针对内存适合性进行了优化。一棵T树。这与MySQL中使用B树或B +树结构的常规存储引擎不同，假定您具有一些热点/非统一访问，则它们可以在内存不足的情况下很好地存活（这通常是一个安全的假设）。
如果您想建立某种概念验证，那么没有什么可以阻止您使用大量交换来弥补您的内存不足。请注意，这将无法很好地执行，并且您正在将产品用于非特定设计的用例。
基本上，一条链的强度与其最薄弱的环节一样强。
设置专用虚拟服务器（使用VMWare设置ESX群集）时，群集中的所有裸机服务器都应具有相同数量的RAM。
MySQL Cluster应该使用相同类型的儿童手套。如果任何服务器（甚至只有1个）的内存少于群集中其他服务器的内存，那将是一个限制因素。如果具有2GB RAM的服务器导致MySQL群集中的其他服务器（即使这些其他服务器每个都具有8GB RAM）的行为也就好像它们最多具有2GB，这也不会令我感到惊讶。
至少，您应该
作为附带说明，请记住，MySQL Cluster还具有为作为存储节点运行的每个服务器在磁盘上存储数据的功能。