このページは機械翻訳したものです。

23.1.7.10 複数の NDB Cluster ノードに関する制限事項

複数の SQL ノード.  NDB Cluster SQL ノードとしての複数の MySQL サーバーの使用に関連する問題は次のとおりで、NDBCLUSTER ストレージエンジンに固有です:

• ストアドプログラムが配布されていません.  ストアドプロシージャ、ストアドファンクション、トリガーおよびスケジュール済イベントはすべて、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 のローリング再起動の実行」を参照してください。

複数のネットワークアドレス.  1 つのデータノードに対する複数のネットワークアドレスはサポートされません。 これらを使用すると、問題が発生しやすくなります。データノードに障害が発生すると、SQL ノードはデータノードが停止したことの確認を待機しますが、そのデータノードへの別のルートが開いたままであるため、この確認を受信できません。 これにより、クラスタは実質的に操作不能になります。

注記

1 つのデータノードで複数のネットワークハードウェアインタフェース (Ethernet カードなど) を使用できますが、これらは同じアドレスにバインドする必要があります。 これは、config.ini ファイルで接続ごとに複数の [tcp] セクションを使用できないことも意味します。 詳細は、セクション23.3.3.10「NDB Cluster TCP/IP 接続」を参照してください。