MySQL Cluster 是正確的選擇嗎？
我有一個 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 集群。它們的架構不同，並且具有不同的優點和缺點。
關於區別的一個很好的網路研討會在這裡：
提到的公式主要用於測量 NDB 集群的每個節點的預計需求。最初的 MySQL Cluster，以前的 NDB Cluster，是一個僅記憶體的數據庫，它要求所有數據都駐留在可用節點的記憶體中。如果您的所有數據都需要保留在記憶體中，那麼如果您沒有足夠的 RAM 來保存所有數據，那麼您在硬體方面的配置不足。
現在，MySQL集群中的每個節點，即一個數據節點，都是一個MySQL實例。即使您應該將數據保存在記憶體中以獲得最佳性能，但這不是必需的。因此，基本上，如果您不“遵守”公式，您最終將掉入磁碟，並且必須處理節點可用的特定硬體的所有 IO 性能。