我有一个 MySQL 双主复制 MySQL，每台服务器都有 21 GB 内存，我现在正在为这个项目寻找集群解决方案，可能有 6 个服务器：其中两个有 20 GB RAM 和其他 10 GB RAM。在 MySQL Cluster 文档中，它为总内存和每个节点 RAM 编写了以下公式，看来我需要更多现有 Replication 的 RAM，并且很难让我的公司同意这种 RAM 要求，除了目的集群不是让大型服务器使用相互连接的较小（资源）服务器，但使用此公式，集群的每个节点都比我现有的服务器大得多。
如果设计一个全新的数据库，可以使用以下计算来帮助确定数据节点的大致内存大小要求：
•（在内存中）数据大小 * 副本 * 1.25 = 总数据库内存要求示例：50 GB * 2 * 1.25 = 125 GB
• (数据大小 * 副本 * 1.25)/节点 = 每个节点的 RAM 示例：(2 GB * 2 * 1.25)/4 = 31.25 GB
在这种情况下，我有一些问题：
- 有必要遵守这些公式吗？我可以为节点使用更少的 RAM 吗？
在评估集群解决方案时，您需要考虑应用程序的读/写配置文件，并将其与可用解决方案进行匹配。
对于应用程序的基于大量读取的配置文件，您可以通过在 MySQL 主-主复制设置中设置多个 MySQL 副本来扩展读取。
对于写入繁重的配置文件，您正在实现主-主复制中的一些明显选择。
在集群 MySQL 选项之间进行选择时，有两种技术选项：基于 NDB 的 Oracle MySQL 集群和来自 Percona（XtraDB 集群）和 MariaDB（MariaDB 集群）的基于 Galera 的选项，以及用于 MySQL 的 Galera 集群。它们的架构不同，并且具有不同的优点和缺点。
关于区别的一个很好的网络研讨会在这里：
http://severalnines.com/blog/galera-cluster-mysql-vs-mysql-ndb-cluster-high-level-comparison-webinar-replay-slides
提到的公式主要用于测量 NDB 集群的每个节点的预计需求。最初的 MySQL Cluster，以前的 NDB Cluster，是一个仅内存的数据库，它要求所有数据都驻留在可用节点的内存中。如果您的所有数据都需要保留在内存中，那么如果您没有足够的 RAM 来保存所有数据，那么您在硬件方面的配置不足。
现在，MySQL集群中的每个节点，即一个数据节点，都是一个MySQL实例。即使您应该将数据保存在内存中以获得最佳性能，但这不是必需的。因此，基本上，如果您不“遵守”公式，您最终将掉入磁盘，并且必须处理节点可用的特定硬件的所有 IO 性能。