NDB Cluster は、標準の MySQL Server 8.0 リリースではサポートされません。 代わりに、MySQL NDB Cluster は別の製品として提供されます。 使用可能な NDB Cluster リリースシリーズには、次のものが含まれます:

NDB Cluster はソース (セクション23.2.1.4「Linux でのソースからの NDB Cluster の構築」 および セクション23.2.2.2「Windows でのソースからの NDB Cluster のコンパイルとインストール」 を参照) から取得およびコンパイルできますが、もっとも特殊なケースを除くすべてのケースで、使用しているオペレーティングシステムおよび状況に適した Oracle によって提供される次のインストーラのいずれかを使用することをお勧めします:

インストールパッケージは、プラットフォームパッケージ管理システムからも入手できます。

使用している MySQL Server で NDB がサポートされるかどうかを判別するには、SHOW VARIABLES LIKE 'have_%'、SHOW ENGINES、または SHOW PLUGINS ステートメントのいずれかを使用します。

「NDB」 は 「Network Database」 を意味しています。 NDB と NDBCLUSTER はどちらも、MySQL でのクラスタリングのサポートを可能にするストレージエンジンの名前です。 NDB をお薦めしますが、どちらの名前も正しいです。

従来の MySQL レプリケーションでは、ソース MySQL サーバーが 1 つ以上のレプリカを更新します。 トランザクションは順次コミットされ、遅いトランザクションによってレプリカがソースより遅れる可能性があります。 これは、ソースに障害が発生した場合、レプリカが最後のいくつかのトランザクションを記録していない可能性があることを意味します。 InnoDB などのトランザクションセーフエンジンが使用されている場合、トランザクションはレプリカで完了するか、まったく適用されませんが、レプリケーションではソースとレプリカのすべてのデータが常に一貫していることは保証されません。 NDB Cluster では、すべてのデータノードの同期が維持され、いずれかのデータノードによってコミットされたトランザクションがすべてのデータノードに対してコミットされます。 データノードの障害が発生した場合、ほかのすべてのデータノードでは整合性のある状態が維持されます。

つまり、標準の MySQL レプリケーションは非同期ですが、NDB Cluster は同期です。

非同期レプリケーションは NDB Cluster でも使用できます。 NDB Cluster レプリケーション (「geo-replication」 とも呼ばれる) には、2 つの NDB Cluster 間および NDB Cluster から非クラスタ MySQL サーバーへの両方をレプリケートする機能が含まれています。 セクション23.6「NDB Cluster レプリケーション」を参照してください。

NDB Cluster は、TCP/IP を使用してコンピュータを接続する高帯域幅環境で使用することを目的としています。 そのパフォーマンスは、クラスタ内のコンピュータ間の接続速度に直接関係しています。 NDB Cluster の最小接続要件には、標準的な 100 メガビットイーサネットネットワークまたは同等のものが含まれます。 可能な場合はギガビット Ethernet を使用することをお勧めします。

実行可能なクラスタの実行には、少なくとも 3 台のコンピュータが必要となります。 ただし、NDB Cluster 内のコンピュータの最小推奨数は 4 です: それぞれが管理ノードと SQL ノードを実行し、2 台のコンピュータがデータノードとして機能します。 データノードを 2 台にする目的は冗長性を持たせるためです。管理ノードは別個のマシンで実行して、いずれかのデータノードで障害が発生した場合にアービトレーションサービスが継続されることを保証する必要があります。

スループットおよび高可用性を向上させるには、複数の SQL ノード (クラスタに接続された MySQL サーバー) を使用してください。 複数の管理サーバーを実行することもできます (必須ではありません)。

NDB Cluster には物理的な編成と論理的な編成の両方があり、コンピュータは物理的な要素です。 クラスタの論理要素または機能要素はノードと呼ばれ、クラスタのノードを収容するコンピュータはクラスタホストと呼ばれることがあります。 クラスタ内の特定のロールにそれぞれ対応する 3 つのタイプのノードがあります。 これらを次に示します。

最も簡単な回答は、「「NDB Cluster のソースコードを記述または分析するソフトウェアエンジニアでないかぎり、これは制御できないため、どのような場合でも心配する必要はありません」」です。

この回答に満足できない場合、より長くテクニカルなバージョンは次のとおりです。

NDB Cluster 内の多くのメカニズムでは、データノード間で分散調整が必要です。 これらの分散アルゴリズムおよびプロトコルには、グローバルチェックポイント、DDL (スキーマ) の変更、およびノードの再起動処理が含まれます。 この調整を単純にするために、それらのメンバーのいずれかがリーダーとして動作するようにデータノードで「選出」されます。 この選択に影響を与えるユーザー向けメカニズムはありません。これは完全に自動です。これは NDB Cluster 内部アーキテクチャーの重要な部分です。

ノードがこれらのメカニズムの「リーダー」として動作する場合、通常、それがアクティビティーの調整の中心となり、「フォロワー」として動作するほかのノードは、リーダーによって指示されたアクティビティーの各自の担当分を実行します。 リーダーとして動作するノードで障害が発生すると、残りのノードによって新しいリーダーが選出されます。 古いリーダーによって調整されていた進行中のタスクは、実際に関係するメカニズムに従って、失敗するか、新しいリーダーによって続行されます。

これらの各種のメカニズムおよびプロトコルの一部で別のリーダーノードが使用されることがありますが、一般的には、それらのすべてで同じリーダーが選択されます。 管理クライアントの SHOW の出力でリーダーとして示されるノードは、DDL およびメタデータアクティビティの調整を担当する DICT マネージャと内部的に呼ばれます。

NDB Cluster は、リーダーの選択がクラスタ自体の外部で認識できないように設計されています。 たとえば、現在のリーダーの CPU またはリソースの使用量がほかのデータノードより著しく高いことはなく、リーダーで障害が発生した場合にほかのデータノードで障害が発生した場合よりクラスタに対して特別に大きい影響があるということはありません。

NDB Cluster は、ほとんどの Unix に似たオペレーティングシステムでサポートされています。 NDB Cluster は、Microsoft Windows オペレーティングシステムの本番設定でもサポートされています。

さまざまなオペレーティングシステムバージョン、オペレーティングシステム配布、およびハードウェアプラットフォームで NDB Cluster に提供されるサポートのレベルに関する詳細は、https://www.mysql.com/support/supportedplatforms/cluster.html を参照してください。

NDB Cluster は、NDB 対応バイナリが使用可能な任意のプラットフォームで実行するようにしてください。 データノードおよび API ノードの場合、より速い CPU およびより多くのメモリーによって、パフォーマンスが向上することがあり、64 ビットの CPU は 32 ビットのプロセッサよりも効率的である場合があります。 各ノードのデータベースの分担を保持するために、データノードに使用されるマシンに十分なメモリーがある必要があります (詳細は、「必要な RAM のサイズはどれくらいですか」を参照してください)。 NDB Cluster 管理サーバーの実行にのみ使用されるコンピュータの場合、要件は最小限です。一般に、このタスクには共通のデスクトップ PC (または同等のもの) で十分です。 ノードは標準の TCP/IP ネットワークおよびハードウェアを使用して通信できます。 高速の SCI プロトコルを使用することもできます。ただし、SCI を使用するには、特殊なネットワークハードウェアおよびソフトウェアが必要となります (セクション23.3.4「NDB Cluster での高速インターコネクトの使用」を参照してください)。

NDB Cluster は最初はインメモリーとしてのみ実装されましたが、現在使用可能なすべてのバージョンで NDB Cluster をディスクに格納する機能も提供されています。 詳細は、セクション23.5.10「NDB Cluster ディスクデータテーブル」を参照してください。

インメモリーの NDB テーブルの場合は、クラスタ内の各データノードで必要となる RAM の容量のおおよその見積もりを取得するために次の式を使用できます。

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

メモリー要件をより正確に計算するには、クラスタデータベースの各テーブルで行ごとに必要となる格納領域 (詳細は、セクション11.7「データ型のストレージ要件」を参照してください) を判別して、それを行数で乗算する必要があります。 カラムインデックスについては、次のことを考慮する必要もあります。

すべての主キーおよび一意インデックスに対して USING HASH を使用する「NDB Cluster の作成」テーブルでは、通常、USING HASH が主キーおよび一意キーの作成に使用されなかったテーブルの更新よりも 20 から 30% 速く、テーブルの更新が高速に実行されます。 これは、必要なメモリーが少なくなり (順序付けされたインデックスが作成されないため)、使用される CPU が少なくなる (読み取りおよび (場合によっては) 更新する必要があるインデックスが少なくなるため) ためです。 ただし、これは、本来範囲スキャンを使用するクエリーをほかの方法で実行する必要があることも意味し、選択が低速になることがあります。

クラスタのメモリー要件を計算するときに、最新の MySQL 8.0 リリースに付属している ndb_size.pl ユーティリティーが役に立つことがあります。 この Perl スクリプトは、現在の (クラスタではない) MySQL データベースに接続して、NDBCLUSTER ストレージエンジンを使用した場合にデータベースで必要となる容量に関する報告を作成します。 詳細は、セクション23.4.28「ndb_size.pl — NDBCLUSTER サイズ要件エスティメータ」を参照してください。

すべての「NDB Cluster」テーブルに主キーが必要ですを覚えておくことは特に重要です。 NDB ストレージエンジンは、主キーが定義されていない場合、主キーを自動的に作成します。この主キーは USING HASH を指定せずに作成されます。

NDB Cluster データおよびインデックスの格納に使用されているメモリーの量は、ndb_mgm クライアントの REPORT MEMORYUSAGE コマンドを使用していつでも確認できます。詳細は、セクション23.5.1「NDB Cluster 管理クライアントのコマンド」 を参照してください。 また、使用可能な DataMemory または NDB 7.6 より前の IndexMemory の 80% が使用されているとき、および使用率が 90%、99% および 100% に達したときに、警告がクラスタログに書き込まれます。

一般に、ホストオペレーティングシステムにネイティブなファイルシステムは NDB Cluster で正常に動作します。 NDB Cluster で特定のファイルシステムが特に適切に動作する (または特にうまく動作しない) ことがわかった場合は、「NDB Cluster フォーラム」での結果について話し合うように招待します。

Windows の場合は、標準の MySQL の場合と同様に、NDB Cluster に NTFS ファイルシステムを使用することをお勧めします。 FAT または VFAT ファイルシステムで NDB Cluster をテストしません。 このため、MySQL または NDB Cluster での使用はお勧めしません。

NDB Cluster はシェアードナッシングのソリューションとして実装されています。これの背後にある考えは、単一のハードウェアの障害によって複数のクラスタノードの障害が発生したり、場合によってはクラスタ全体の障害が発生したりしないことです。 このため、NDB Cluster ではネットワーク共有またはネットワークファイルシステムの使用はサポートされていません。 これは、SAN などの共有ストレージデバイスにも当てはまります。

NDB Cluster は、仮想マシンでの使用がサポートされています。 現在、Oracle VM を使用してサポートおよびテストが行われています。

一部の NDB Cluster ユーザーは、ほかの仮想化製品を使用して NDB Cluster を正常に配備しました。このような場合、Oracle は NDB Cluster のサポートを提供できますが、仮想環境に固有の問題はその製品ベンダーに示す必要があります。

原因はすべてのテーブルデータおよびすべてのインデックス (テーブル定義に主キーの定義が含まれていない場合に自動的に作成される、NDB ストレージエンジンによって要求される主キーを含む) のための十分な RAM が、使用しているセットアップで提供されていないことである可能性があります。

すべてのデータノードで同じ容量の RAM が使用されることにも注意してください。クラスタ内のデータノードは、データノードの中で使用可能なメモリーの容量がもっとも少ないノードより多いメモリーを使用することはできないためです。 たとえば、クラスタデータノードをホストしているコンピュータが 4 台あり、これらのうち 3 台にクラスタデータを格納できる 3GB の RAM があり、残りのデータノードには 1GB の RAM しかない場合、各データノードは NDB Cluster データおよびインデックス専用にすることができます。

場合によっては、ndb_mgm -e "ALL REPORT MEMORYUSAGE" で DataMemory に大きい空き領域が示されていてもTable is fullというエラーがMySQL クライアントアプリケーションで表示されることがあります。 CREATE TABLE の MAX_ROWS オプションを使用すると、NDB で強制的に「NDB Cluster」テーブルの追加パーティションを作成し、ハッシュインデックスに使用可能なメモリーを増やすことができます。 通常、テーブルに格納することが予期されている行数の 2 倍の数値を MAX_ROWS に設定すれば十分です。

同様の理由で、データが大量にロードされたノードで、データノードが再起動される問題が発生することもあります。 MinFreePct パラメータは、DataMemory および (NDB 7.6 より前の) IndexMemory の一部 (デフォルトでは 5%) を再起動で使用するために予約することで、この問題を解決できます。 この予約されたメモリーは、NDB テーブルまたはデータの格納には使用できません。

NDB Cluster は 100 Mbps またはギガビット Ethernet を使用した LAN 設定で見つかったような専用の高速接続を保証する条件で実行されることを前提として設計および実装されているため、このような状況でクラスタが確実に実行される可能性は very ではありません。 これより遅い環境で使用したときのパフォーマンスはテストされておらず保証されません。

また、NDB Cluster 内のノード間の通信はセキュリティー保護されておらず、ほかの保護メカニズムによって暗号化も保護もされていないことに注意してください。 クラスタのもっともセキュアな構成は、外部からクラスタのデータまたは管理ノードに直接アクセスされない、ファイアウォールの内側のプライベートネットワークです。 (SQL ノードの場合は、MySQL サーバーのほかのインスタンスの場合と同様の予防措置を取るようにしてください。) 詳細は、セクション23.5.17「NDB Cluster のセキュリティーの問題」を参照してください。

いいえ。 クラスタ自体の管理および構成にはいくつかの特殊なコマンドが使用されますが、次の操作には標準の (My)SQL ステートメントのみが必要となります。

NDB Cluster を設定するには、いくつかの特殊な構成パラメータおよびファイルが必要です。これらについては、セクション23.3.3「NDB Cluster 構成ファイル」 を参照してください。

NDB Cluster 管理クライアント (ndb_mgm) では、クラスタノードの起動や停止などのタスクにいくつかの単純なコマンドが使用されます。 セクション23.5.1「NDB Cluster 管理クライアントのコマンド」を参照してください。

NDB Cluster は、ODBC、.Net、MySQL C API、PHP、Perl、Python などの一般的なスクリプト言語用の多数のドライバなど、標準の MySQL Server と同じプログラミング API および言語をサポートしています。 これらの API を使用して記述された NDB Cluster アプリケーションは、ほかの MySQL アプリケーションと同様に動作し、SQL ステートメントを MySQL Server (NDB Cluster の場合は SQL ノード) に送信し、データ行を含む応答を受信します。 これらの API については、第29章「Connector および API」を参照してください。

NDB Cluster は NDB API を使用したアプリケーションプログラミングもサポートしています。NDB API は、MySQL Server を経由せずに NDB Cluster データへの下位レベルの C++ インタフェースを提供します。 The NDB APIを参照してください。 また、多くの NDBCLUSTER 管理関数が C 言語の MGM API によって提供されています。詳細は、The MGM APIを参照してください。

NDB Cluster は、セッションおよびトランザクションを使用したデータのドメインオブジェクトモデルをサポートする ClusterJ を使用した Java アプリケーションプログラミングもサポートしています。 詳細は、Java and NDB Clusterを参照してください。

さらに、NDB Cluster は memcached をサポートしているため、開発者は memcached インタフェースを使用して NDB Cluster に格納されているデータにアクセスできます。詳細は、ndbmemcache—Memcache API for NDB Cluster (NO LONGER SUPPORTED) を参照してください。

NDB Cluster には、NDB Cluster をデータストアとして、Node.js に対して記述された NoSQL アプリケーションをサポートするアダプタも含まれています。 詳細は、MySQL NoSQL Connector for JavaScriptを参照してください。

NDB Cluster には、基本管理機能を実行するためのコマンドラインクライアントが含まれています。 セクション23.4.5「ndb_mgm — NDB Cluster 管理クライアント」およびセクション23.5.1「NDB Cluster 管理クライアントのコマンド」を参照してください。

NDB Cluster 7.6 以前は、ローリング再起動や構成変更などの多くの NDB Cluster 管理タスクを自動化できる高度なコマンド行インタフェースを提供する個別の製品である MySQL Cluster Manager でもサポートされています。 バージョン 1.4.8 以降、MySQL Cluster Manager は NDB Cluster 8.0 の実験的なサポートも提供します。 MySQL Cluster Manager については、MySQL Cluster Manager 1.4.8 User Manualを参照してください。

NDB Cluster は、NDB Cluster ソフトウェアディストリビューションの一部として、NDB Cluster を設定および配備するためのグラフィカルブラウザベースの Auto-Installer も提供します。 詳細は、The NDB Cluster Auto-Installer (NDB 7.5) (No longer supported)を参照してください。

これを行うことができる方法は 2 つあります。

はい。 NDB ストレージエンジンを指定して作成されたテーブルの場合は、トランザクションがサポートされます。 現在、NDB Cluster は READ COMMITTED トランザクション分離レベルのみをサポートしています。

NDB Cluster には NDB ストレージエンジンが必要です。 つまり、NDB Cluster 内のノード間でテーブルを共有するには、ENGINE=NDB (または同等のオプション ENGINE=NDBCLUSTER) を使用してテーブルを作成する必要があります。

NDB Cluster で使用されている MySQL サーバー上で、ほかのストレージエンジン (InnoDB や MyISAM など) を使用してテーブルを作成することは可能ですが、これらのテーブルは NDB を使用しないため、クラスタ化に参加しません。このような各テーブルは、作成される個々の MySQL サーバーインスタンスに対して厳密にローカルです。

NDB Cluster は、アーキテクチャー、要件、および実装に関して InnoDB クラスタリングとは大きく異なります。名前に類似点があるにもかかわらず、両者は互換性がありません。 InnoDB クラスタリングの詳細は、MySQL AdminAPI の使用 を参照してください。 NDB ストレージエンジンと InnoDB ストレージエンジンの違いについては、セクション23.1.6「MySQL Server NDB Cluster と比較した InnoDB の使用」 も参照してください。

コミットされたすべてのトランザクションはログ記録されます。 このため、大災害が起こった場合に一部のデータが失われることはありますが、それはごく限定的なものとなります。 データの損失は、トランザクションごとの操作の数を最小限にすることによって、さらに減らすことができます。 (どのような場合でも、1 つのトランザクションで多数の操作を実行するのはよい考えではありません。)

FULLTEXT のインデックス作成は現在、InnoDB および MyISAM ストレージエンジンでのみサポートされています。 詳細は、セクション12.10「全文検索関数」を参照してください。

実行できますが常に推奨できるとは限りません。 クラスタを実行する主な理由の 1 つは冗長性を持たせるためです。 この冗長性の利点を完全に享受するには、各ノードを別個のマシン上に配置してください。 単一のマシンに複数のノードを配置した場合、そのマシンで障害が発生したときに、それらのすべてのノードが失われます。 このため、単一のマシンで複数のデータノードを実行する場合は、そのマシンの障害によってノードグループのすべてのデータノードが失われることがないように設定することが非常に重要です。

NDB Cluster は、低コスト (またはコストなし) のオペレーティングシステムでロードされたコモディティハードウェア上で実行できるため、余分なマシンまたは 2 台のマシンを使用すると、ミッションクリティカルなデータを保護する価値があります。 管理ノードを実行するクラスタホストの要件は最低限のものであることにも注意してください。 このタスクは、300 MHz の Pentium または同等の CPU、オペレーティングシステムのための十分な RAM、および ndb_mgmd プロセスと ndb_mgm プロセスのための少量のオーバーヘッドに対応した装備があれば実行できます。

複数の CPU、コア、またはその両方を持つ単一のホストで、複数のクラスタデータノードを実行することは容認できます。 NDB Cluster ディストリビューションは、このようなシステムでの使用を目的としたマルチスレッドバージョンのデータノードバイナリも提供します。 詳細は、セクション23.4.3「ndbmtd — NDB Cluster データノードデーモン (マルチスレッド)」を参照してください。

同じマシン上でデータノードと SQL ノードを同時に実行できる場合もあります。そのような配置での実行状態は、さまざまな要因 (コアおよび CPU の数、データノードおよび SQL ノードのプロセスが使用できるディスクおよびメモリーの容量など) によって異なります。そのような構成を計画する場合は、これらの要因を考慮する必要があります。

クラスタをオフラインにせずに、実行中の NDB Cluster に新しいデータノードを追加できます。 詳細は、セクション23.5.7「NDB Cluster データノードのオンラインでの追加」を参照してください。

ほかのタイプの NDB Cluster ノードの場合は、ローリング再起動がすべて必要です (セクション23.5.5「NDB Cluster のローリング再起動の実行」 を参照)。

MySQL NDB Cluster での NDB テーブルの制限事項は次のとおりです:

NDB Cluster の制限の完全なリストについては、セクション23.1.7「NDB Cluster の既知の制限事項」 を参照してください。 セクション23.1.7.11「前 NDB Cluster 8.0 で解決される NDB Cluster の問題」も参照してください。

NDB Cluster は、InnoDB ストレージエンジンで検出されるものと同等の外部キー制約のサポートを提供します。詳細は、セクション1.7.3.2「FOREIGN KEY の制約」、および セクション13.1.20.5「FOREIGN KEY の制約」 を参照してください。 外部キーのサポートが必要なアプリケーションは NDB Cluster 7.3, 7.4, 7.5 以降を使用するようにしてください。

NDB Cluster には、ほかのバージョンの MySQL と同様にデータベースをインポートできます。 この FAQ の各所で説明されている制限以外の唯一の特別な要件は、クラスタに含まれるテーブルが NDB ストレージエンジンを使用する必要があることです。 これは、ENGINE=NDB または ENGINE=NDBCLUSTER を指定してテーブルを作成する必要があることを意味します。

ほかのストレージエンジンを使用しているテーブルを、1 つ以上の ALTER TABLE ステートメントを使用して、NDBCLUSTER に変更することもできます。 ただし、変更を行う前に、テーブルの定義が NDBCLUSTER ストレージエンジンと互換性がある必要があります。 MySQL 8.0 では、追加の回避策も必要となります。詳細は、セクション23.1.7「NDB Cluster の既知の制限事項」を参照してください。

クラスタのノードは、3 種類の転送メカニズム (TCP/IP、SHM (共有メモリー)、および SCI (スケーラブルコヒーラントインタフェース)) を使用して通信できます。 使用可能な場合、同じクラスタホスト上にあるノード間では SHM がデフォルトで使用されます。ただし、これは実験的とみなされます。 SCI は、スケーラブルなマルチプロセッサシステムを構築するために使用される高速 (1 Gbps 以上) で高可用性のプロトコルであり、特殊なハードウェアおよびドライバが必要となります。 NDB Cluster のトランスポートメカニズムとして SCI を使用する方法の詳細は、セクション23.3.4「NDB Cluster での高速インターコネクトの使用」 を参照してください。

クラスタ内の 1 つ以上のデータノードで障害が発生した場合、すべてのクラスタデータノードが相互に「「参照」」できるわけではありません。 実際に、2 つのセットのデータノードがネットワークのパーティション化で別々に分離されることがあります (「スプリットブレイン」シナリオとも呼ばれます)。 各セットのデータノードがクラスタ全体のように動作しようとするため、このタイプの状況は好ましくありません。 競合するデータノードのセットのいずれかを選択するために、アービトレータが必要となります。

少なくとも 1 つのノードグループのすべてのデータノードが存続して場合、クラスタの単一のサブセットが独自に機能するクラスタを形成できないため、ネットワークのパーティション化は問題とはなりません。 本当の問題はすべてのノードが存続している単一のノードグループがない場合に発生し、その場合はネットワークのパーティション化 (「スプリットブレイン」シナリオ) が発生する可能性があります。 そしてアービトレータが必要となります。 すべてのクラスタノードは、同じノードをアービトレータとして認識しますが、通常、これは管理サーバーです。ただし、クラスタ内の MySQL サーバーのいずれかを代わりにアービトレータとして動作するように構成できます。 アービトレータは、クラスタノードの最初のセットがアクセスすることを受け入れ、残りのセットにシャットダウンするように指示します。 アービトレータの選択は、MySQL サーバーおよび管理サーバーノードの ArbitrationRank 構成パラメータによって制御されます。 ArbitrationRank 構成パラメータを使用してアービトレータの選択プロセスを制御することもできます。 これらのパラメータについては、セクション23.3.3.5「NDB Cluster 管理サーバーの定義」を参照してください。

アービトレータの役割によって、指定されたホストに重い要求が課されることはないため、アービトレータのホストはこの目的のために特別に処理が速いマシン、または追加のメモリーがあるマシンである必要はありません。

NDB Cluster は、MySQL 空間拡張機能に関連付けられたデータ型を含め、通常の MySQL データ型をすべてサポートしますが、NDB ストレージエンジンは空間インデックスをサポートしていません。 (空間インデックスは MyISAM によってのみサポートされます。詳細は、セクション11.4「空間データ型」を参照してください。) また、NDB テーブルとともに使用された場合、インデックスに関していくつかの違いがあります。

これらの問題については、セクション23.1.7「NDB Cluster の既知の制限事項」を参照してください。

クラスタ内の各ノードを次の順序で個別に起動する必要があります。

影響を受けるノードがあるマシンのシステムシェルで、これらの各コマンドを実行する必要があります。 (そのマシンを物理的にその場で操作する必要はありません。リモートログインシェルをこの目的に使用できます。) クラスタが実行されていることを確認するには、管理ノードが収容されているマシンで NDB 管理クライアント ndb_mgm を起動して、SHOW コマンドまたは ALL STATUS コマンドを発行します。

実行されているクラスタをシャットダウンするには、管理クライアントで SHUTDOWN コマンドを発行します。 または、システムシェルに次のコマンドを入力できます。

shell> ndb_mgm -e "SHUTDOWN"

(この例の引用符はオプションです。-e オプションの後ろのコマンド文字列にスペースがないためです。また、管理クライアントのほかのコマンドと同様に、SHUTDOWN コマンドでは大文字/小文字が区別されません。)

これらのコマンドのいずれかによって、ndb_mgm、ndb_mgm、および ndbd プロセスが正常に終了します。 SQL ノードとして実行されている MySQL サーバーは、mysqladmin shutdown を使用して停止できます。

詳細は、セクション23.5.1「NDB Cluster 管理クライアントのコマンド」およびセクション23.2.6「NDB Cluster の安全なシャットダウンと再起動」を参照してください。

MySQL Cluster Manager および NDB Cluster Auto-Installer には、NDB Cluster ノードの応答なし停止の開始を処理する追加の方法が用意されています。 これらのツールの詳細は、MySQL Cluster Manager 1.4.8 User Manual および セクション23.2.8「NDB Cluster Auto-Installer (サポートされなくなりました)」 を参照してください。

クラスタのデータノードによってメモリーに保持されていたデータがディスクに書き込まれ、次回クラスタが起動されたときにメモリーにリロードされます。

フェイルセーフとして役に立つことがあります。 特定の時点でクラスタを制御しているのは 1 つの管理ノードのみですが、1 つの管理ノードをプライマリとして構成し、プライマリ管理ノードで障害が発生した場合に、1 つ以上の追加の管理ノードが引き継ぐようにすることができます。

NDB Cluster 管理ノードを構成する方法については、セクション23.3.3「NDB Cluster 構成ファイル」 を参照してください。

はい。すべてのマシンおよびオペレーティングシステムが同じ「エンディアン」 (すべてがビッグエンディアンまたはすべてがリトルエンディアン) であれば可能です。

異なる NDB Cluster リリースのソフトウェアを異なるノードで使用することもできます。 ただし、このような使用はローリングアップグレード手順の一部としてのみサポートされています (セクション23.5.5「NDB Cluster のローリング再起動の実行」 を参照)。

はい。実行できます。 複数のデータノードの場合は、各ノードで別のデータディレクトリを使用することをお勧めします (必須ではありません)。 単一のマシン上で複数の SQL ノードを実行する場合は、mysqld の各インスタンスで別の TCP/IP ポートを使用する必要があります。

データノードと SQL ノードを同じホスト上で同時に実行することは可能ですが、ndbd または ndbmtd プロセスが mysqld とのメモリーを競合する可能性があることに注意してください。

はい。クラスタのホストに DNS および DHCP を使用できます。 ただし、アプリケーションが「ファイブナイン」可用性を要求する場合は、固定 (数値) IP アドレスを使用してください。クラスタホスト間通信を DNS、DHCP などのサービスに依存させると、潜在的な障害点が増えるためです。

IPv6 は SQL ノード (MySQL サーバー) 間の接続でサポートされていますが、ほかのすべてのタイプの NDB Cluster ノード間の接続は IPv4 を使用する必要があります。

これは、実質的には NDB Cluster 間のレプリケーションに IPv6 を使用できるが、同じ NDB Cluster 内のノード間の接続には IPv4 を使用する必要があることを意味します。 詳細は、セクション23.6.3「NDB Cluster レプリケーションの既知の問題」を参照してください。

通常、MySQL ユーザーアカウントと特権は、同じ NDB Cluster にアクセスする異なる MySQL サーバー間で自動的に伝播されません。 MySQL NDB Cluster は、NDB_STORED_USER 権限を使用した共有および同期されたユーザーおよび権限のサポートを提供します。詳細は、セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」 を参照してください。 この実装は NDB 8.0 の新機能であり、NDB 8.0 でサポートされなくなった以前のバージョンの NDB Cluster で採用されていた共有特権メカニズムと互換性がないことに注意してください。

MySQL NDB Cluster では、SQL ノード間の自動フェイルオーバーは一切提供されません。 アプリケーションは、SQL ノードの損失を処理し、それらの間でフェイルオーバーする準備ができている必要があります。

NDB 管理クライアントおよび ndb_restore プログラムで NDB Cluster のネイティブバックアップおよび復元機能を使用できます。 セクション23.5.8「NDB Cluster のオンラインバックアップ」およびセクション23.4.23「ndb_restore — NDB Cluster バックアップの復元」を参照してください。

このために mysqldump および MySQL サーバーで提供されている従来の機能を使用することもできます。 詳細は、セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。

このプロセスは、データノードプロセスをモニターし、必要に応じて再起動を試みます。 ndbd を起動したあとに、システムでアクティブなプロセスのリストをチェックすると、その名前で実行されているプロセスが実際には 2 つあることを確認できます (簡潔にするために、出力では ndb_mgmd および ndbd を省略しました)。

shell> ./ndb_mgmd

shell> ps aux | grep ndb
me      23002  0.0  0.0 122948  3104 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23025  0.0  0.0   5284   820 pts/2    S+   14:14   0:00 grep ndb

shell> ./ndbd -c 127.0.0.1 --initial

shell> ps aux | grep ndb
me      23002  0.0  0.0 123080  3356 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23096  0.0  0.0  35876  2036 ?        Ss   14:14   0:00 ./ndbmtd -c 127.0.0.1 --initial
me      23097  1.0  2.4 524116 91096 ?        Sl   14:14   0:00 ./ndbmtd -c 127.0.0.1 --initial
me      23168  0.0  0.0   5284   812 pts/2    R+   14:15   0:00 grep ndb

メモリー使用率と CPU 使用率の両方について 0.0 を示す ndbd プロセスは、angel プロセスです (ただし、実際には非常に少量のプロセスを使用します)。 このプロセスは、ndbd または ndbmtd のメインプロセス (実際にデータを処理するプライマリデータノードプロセス) が実行されているかどうかのみをチェックします。 許可されている場合 (たとえば、StopOnError 構成パラメータが false に設定されている場合)、angel プロセスはプライマリデータノードプロセスの再起動を試みます。