ストアドプログラムが配布されていません.  ストアドプロシージャ、ストアドファンクション、トリガーおよびスケジュール済イベントはすべて、NDB ストレージエンジンを使用するテーブルでサポートされていますが、これらはクラスタ SQL ノードとして機能する MySQL Servers 間で自動的に伝播されないため、各 SQL ノードで個別に再作成する必要があります。 NDB Cluster 内のストアドルーチンとトリガーを参照してください。

分散型のテーブルロックがない.  LOCK TABLES は、ロックが発行された SQL ノードに対してのみ機能します。クラスタ内のほかの SQL ノードでは、このロックは「認識」されません。 これは、操作の一部としてテーブルをロックするステートメントによって発行されたロックにも当てはまります。 (例については、次の項目を参照してください。)

ALTER TABLE 操作.  複数の MySQL サーバー (SQL ノード) が実行されているときは、ALTER TABLE によるロックは完全ではありません。 (前の項目で説明したように、NDB Cluster は分散テーブルロックをサポートしていません。)

いずれかの管理サーバーが同じホスト上で実行されている場合は、ノード ID の自動割当てが同じホスト上の複数の管理サーバー間で機能しないため、接続文字列でノードに明示的な ID を指定する必要があります。 すべての管理サーバーが異なるホストに存在する場合、これは必要ありません。

管理サーバーは起動時に、まず同じ NDB Cluster 内のほかの管理サーバーをチェックし、ほかの管理サーバーへの接続が成功すると、その構成データを使用します。 つまり、管理サーバーの --reload および --initial 起動オプションは、それが実行中の唯一の管理サーバーでないかぎり、無視されます。 また、複数の管理ノードを持つ NDB Cluster のローリング再起動を実行する場合、管理サーバーは、それがこの NDB Cluster で実行されている唯一の管理サーバーである場合にのみ、独自の構成ファイルを読み取ります。 詳細は、セクション23.5.5「NDB Cluster のローリング再起動の実行」を参照してください。