MySQL Cluster RAM要件
MySQL 5.1以降、データを完全にメモリ上に置く必要がなくなりました。
インデックス付きの列（インデックス構造全体）がメモリ内にある必要があると読みました（ MySQL High Availability、2010、pg。533 、 "MySQL Clusterはすべてのインデックス付き列をメインメモリに保持します"）。
これに照らして、十分なメモリがない場合（つまり、巨大なデータベース（> 100GB、または1TB）で、低メモリ構成（たとえば、2つのデータノード、それぞれ1GBのRAMを備えている））で実行されている場合はどうなりますか？
MySQL Clusterは、最近アクセスしたデータのLRUキャッシュを使用して、インデックスなしの列をディスクのみに保存することをサポートします。ただし、インデックス付きの列は常にメモリ内に保持されます。
MySQL Clusterは、DataMemoryおよびIndexMemoryパラメータに従って、すべてのメモリを事前に割り当てます。基礎となるOSに動的により多くのメモリを要求しません。
つまり、クラスター内のすべてのインデックス付き列をメモリに保持するのに十分なメモリを構成する必要があります。データセットが十分に大きいため、インデックス付きの列が使用可能なクラスターメモリよりも大きい場合、そのデータセットをクラスターにロードできません。ある時点でスペースが不足し、挿入トランザクションが中止されます。
DataMemoryとIndexMemoryを構成するときは、各システムの物理メモリよりいくらか少なく制限するのが最善です。一部の物理メモリは、OSおよび他のプロセス用に予約する必要があります。
理論的には、MySQL Clusterは、スワップデバイスを介して仮想メモリを使用するように構成できます（たとえば、物理メモリよりも多い）が、他の回答では、これはユースケース向けではありません。インメモリランダムアクセスパターンはディスクへのランダムアクセスを引き起こし、システム全体でスワップスラッシングとスローダウンを引き起こすため、インメモリ構造をディスクにスワップすることは通常最適ではありません。 MySQL Clusterで最も可能性が高い結果は、スワッピングデータノードが信号に十分に迅速に応答しないことによるハートビート障害およびクラスター障害です。
集約メモリよりも大きなインデックスを効率的にサポートするには、MySQL Clusterが、ディスクアクセスプロパティに合わせたキャッシュとアクセスパターンを備えたオンディスクインデックスフォーマット（おそらくBツリーなど）をサポートする必要があります。
これに照らして、十分なメモリがない場合はどうなりますか
おそらく、十分なメモリがない場合に予想されるものです。ファイルはドライブ上に作成され、ドライブが許す限り高速で実行されます。
MySQLを適切に制限して、他のシステムプロセスに必要なすべてのメモリを消費しないようにしてください。
基本的に、チェーンは最も弱いリンクと同じくらい強力です。
プライベート仮想サーバーがセットアップされると（VMWareを使用してESXクラスターがセットアップされます）、クラスター内のすべてのベアメタルサーバーのRAM容量は同じになるはずです。
MySQL Clusterも同じ種類の子供用手袋で扱う必要があります。いずれかのサーバー（1つでも）のメモリがクラスター内の他のサーバーより少ない場合、それは制限要因のようです。 2GB RAM=のサーバーが、MySQL Cluster内の他のサーバーに（それぞれ8GBのRAMが搭載されている場合でも）最大2GBのように振る舞わせても驚くことではありません。
少なくとも、あなたは
- sQLノードと一致するようにデータノードのRAMをアップグレードします
- できるだけ多くのディスクベースのテーブルを使用する
- 余分なインデックスをすべて削除します（インデックスは使用されていません）
- 詳細については
補足として、MySQL Clusterには、ストレージノードとして実行されている各サーバーのデータをディスクに保存する機能もあります。