Question

A.10.1.

NDB Cluster をサポートする MySQL ソフトウェアのバージョンはどれですか。ソースからコンパイルする必要がありますか。

Answer 1

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

NDB Cluster 7.2. このシリーズは、新しいデプロイメントまたはメンテナンスではサポートされなくなりました。 NDB Cluster 7.2 のユーザーは、できるだけ早く新しいリリースシリーズにアップグレードするようにしてください。新しい配備では、最新の NDB Cluster 8.0 リリースを使用することをお勧めします。
NDB Cluster 7.3. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 8.0 リリースを使用することをお勧めします。最新の NDB Cluster 7.3 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。
NDB Cluster 7.4. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 8.0 リリースを使用することをお勧めします。最新の NDB Cluster 7.4 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。
NDB Cluster 7.5. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 7.6 リリースを使用することをお勧めします。最新の NDB Cluster 7.5 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。
NDB Cluster 7.6. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 8.0 リリースを使用することをお勧めします。最新の NDB Cluster 7.6 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。
NDB Cluster 8.0. このシリーズは、NDB ストレージエンジンおよび MySQL Server 8.0 のバージョン 8.0 に基づいた NDB Cluster の最新の General Availability (GA) バージョンです。 NDB Cluster 8.0 は本番で使用できます。本番用の新しい配備では、現在 NDB Cluster 8.0.23 であるこのシリーズの最新の GA リリースを使用するようにしてください。 https://dev.mysql.com/downloads/cluster/ から最新の NDB Cluster 8.0 リリースを取得できます。このシリーズの新機能およびその他の重要な変更の詳細は、What is New in NDB Cluster を参照してください。

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

web ベースの NDB Cluster Auto-Installer (NDB でサポートされているすべてのプラットフォームで動作)
Linux binary release (tar.gz ファイル)
Linux RPM package
Linux .deb file
Windows binary 「no-install」 release
Windows MSI Installer

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

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

Answer 2

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

Answer 3

従来の 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 レプリケーション」を参照してください。

Answer 4

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

Answer 5

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

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

Answer 6

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

管理ノード. このノードはクラスタ全体の管理サービス (起動、シャットダウン、バックアップ、およびほかのノードの構成データを含む) を提供します。管理ノードサーバーはアプリケーション ndb_mgmd として実装され、NDB Cluster の制御に使用される管理クライアントは ndb_mgm です。これらのプログラムについては、セクション23.4.4「ndb_mgmd — NDB Cluster 管理サーバーデーモン」およびセクション23.4.5「ndb_mgm — NDB Cluster 管理クライアント」を参照してください。
データノード. このタイプのノードは、データを格納およびレプリケートします。データノードの機能は、NDB データノードプロセスndbd のインスタンスによって処理されます。詳細は、セクション23.4.1「ndbd — NDB Cluster データノードデーモン」を参照してください。
SQL ノード. これは、NDBCLUSTER ストレージエンジンをサポートして構築され、エンジンを有効にするための --ndb-cluster オプションと NDB Cluster 管理サーバーに接続できるようにするための --ndb-connectstring オプションで起動される MySQL Server (mysqld) の単なるインスタンスです。これらのオプションについては、セクション23.3.3.9.1「NDB Cluster の MySQL Server オプション」を参照してください。

注記

API ノードは、データの格納および取得のためにクラスタのデータノードを直接使用するアプリケーションです。このため、SQL ノードは MySQL サーバーを使用してクラスタへの SQL インタフェースを提供する API ノードの一種であると考えることができます。 NDB Cluster データに直接のオブジェクト指向トランザクションおよびスキャンインタフェースを提供する NDB API を使用して、そのようなアプリケーション (MySQL Server に依存しない) を記述できます。詳細は、NDB Cluster API Overview: The NDB API を参照してください。

Answer 7

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

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

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

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

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

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

Answer 8

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

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

Answer 9

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

Answer 10

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

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

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

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

NDBCLUSTER テーブルに作成される各主キーまたはハッシュインデックスには、レコードごとに 21−25 バイトが必要となります。これらのインデックスは IndexMemory を使用します。
順序付けされた各インデックスでは、DataMemory を使用して、レコードごとに 10 バイトのストレージが必要となります。
また、主キーまたは一意のインデックスを作成すると、このインデックスが USING HASH を指定して作成された場合を除き、順序付けされたインデックスが作成されます。言い換えると、次のようになります。
- 通常、クラスタテーブルの主キーまたは一意のインデックスには、レコードごとに 31 - 35 バイトが使用されます。
- ただし、主キーまたは一意のインデックスが USING HASH を指定して作成されている場合は、レコードごとに 21 バイトから 25 バイトのみが必要となります。

すべての主キーおよび一意インデックスに対して 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% に達したときに、警告がクラスタログに書き込まれます。

Answer 11

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

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

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

Answer 12

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

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

Answer 13

原因はすべてのテーブルデータおよびすべてのインデックス (テーブル定義に主キーの定義が含まれていない場合に自動的に作成される、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 テーブルまたはデータの格納には使用できません。

Answer 14

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

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

Answer 15

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

テーブルの作成、変更、および削除
テーブルデータの挿入、更新、および削除
プライマリインデックスおよび一意のインデックスの作成、変更、および削除

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

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

Answer 16

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を参照してください。

Answer 17

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)を参照してください。

Answer 18

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

エラー状態または警告状態を通知された直後に、mysql クライアント内で SHOW ERRORS または SHOW WARNINGS を使用します。
システムのシェルプロンプトで、perror --ndb error_code を使用します。

Answer 19

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

Answer 20

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 の使用」も参照してください。

Answer 21

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

Answer 22

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

Answer 23

実行できますが常に推奨できるとは限りません。クラスタを実行する主な理由の 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 ノードのプロセスが使用できるディスクおよびメモリーの容量など) によって異なります。そのような構成を計画する場合は、これらの要因を考慮する必要があります。

Answer 24

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

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

Answer 25

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

一時テーブルはサポートされません。ENGINE=NDB または ENGINE=NDBCLUSTER を使用した CREATE TEMPORARY TABLE ステートメントは、エラーが発生して失敗します。
NDBCLUSTER テーブルでサポートされるユーザー定義のパーティション化のタイプは、KEY および LINEAR KEY のみです。ほかのパーティショニングタイプを使用して NDB テーブルを作成しようとすると、エラーが発生して失敗します。
FULLTEXT インデックスはサポートされません。
インデックスのプリフィクスはサポートされません。インデックスを作成できるのは完全なカラムのみです。
空間インデックスはサポートされません (空間カラムは使用できます)。セクション11.4「空間データ型」を参照してください。
部分的なトランザクションおよび部分的なロールバックのサポートは、ほかのトランザクションストレージエンジン (個別のステートメントをロールバックできる InnoDB など) と同等です。
テーブルごとに許可される属性の最大数は 512 個です。属性名は 31 文字以内である必要があります。各テーブルで、テーブル名とデータベース名を合わせた最大長は 122 文字です。
NDB 8.0 では、テーブル行の最大サイズは 14 K バイトであり、BLOB 値はカウントされません。 NDB 8.0 では、この最大値は 30000 バイトに増加します。詳細は、セクション23.1.7.5「NDB Cluster 内のデータベースオブジェクトに関連付けられる制限」を参照してください。

NDB テーブルごとの行数の制限はありません。テーブルサイズの制限は多くの要因によって異なり、各データノードで使用できる RAM の容量に特に関係しています。

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

Answer 26

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

Answer 27

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

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

Answer 28

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

Answer 29

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

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

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

Answer 30

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

注記

「NDB Cluster ディスクデータ」テーブル (TABLESPACE ... STORAGE DISK ENGINE=NDB または TABLESPACE ... STORAGE DISK ENGINE=NDBCLUSTER で作成されたテーブル) には固定幅の行のみがあります。これは、(たとえば) VARCHAR(255) カラムが含まれている各ディスクデータテーブルレコードで、実際に格納される文字数に関係なく、255 文字 (テーブルに使用されている文字セットおよび照合順序に必要となります) の領域が必要となることを意味します。

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

Answer 31

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

ndb_mgmd コマンドを使用して、管理ノードを起動します。

-f オプションまたは --config-file オプションを指定して、構成ファイルのある場所を管理ノードに通知する必要があります。
ndbd コマンドを使用して、各データノードを起動します。

データノードが管理サーバーに接続する方法を認識するように、-c オプションまたは --ndb-connectstring オプションを指定して各データノードを起動する必要があります。
任意の起動スクリプト (mysqld_safe など) を使用して各 MySQL サーバー (SQL ノード) を起動します。

各 MySQL サーバーは、--ndbcluster オプションおよび --ndb-connectstring オプションを指定して起動する必要があります。これらのオプションにより、mysqld は NDBCLUSTER ストレージエンジンのサポートおよび管理サーバーへの接続方法を有効にします。

影響を受けるノードがあるマシンのシステムシェルで、これらの各コマンドを実行する必要があります。 (そのマシンを物理的にその場で操作する必要はありません。リモートログインシェルをこの目的に使用できます。) クラスタが実行されていることを確認するには、管理ノードが収容されているマシンで 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 (サポートされなくなりました)」を参照してください。

Answer 32

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

Answer 33

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

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

Answer 34

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

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

Answer 35

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

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

Answer 36

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

Answer 37

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

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

Answer 38

通常、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 で採用されていた共有特権メカニズムと互換性がないことに注意してください。

Answer 39

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

Answer 40

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

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

Answer 41

このプロセスは、データノードプロセスをモニターし、必要に応じて再起動を試みます。 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 プロセスはプライマリデータノードプロセスの再起動を試みます。

A.10.1.	NDB Cluster をサポートする MySQL ソフトウェアのバージョンはどれですか。ソースからコンパイルする必要がありますか。
	NDB Cluster は、標準の MySQL Server 8.0 リリースではサポートされません。代わりに、MySQL NDB Cluster は別の製品として提供されます。使用可能な NDB Cluster リリースシリーズには、次のものが含まれます: NDB Cluster 7.2. このシリーズは、新しいデプロイメントまたはメンテナンスではサポートされなくなりました。 NDB Cluster 7.2 のユーザーは、できるだけ早く新しいリリースシリーズにアップグレードするようにしてください。新しい配備では、最新の NDB Cluster 8.0 リリースを使用することをお勧めします。 NDB Cluster 7.3. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 8.0 リリースを使用することをお勧めします。最新の NDB Cluster 7.3 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。 NDB Cluster 7.4. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 8.0 リリースを使用することをお勧めします。最新の NDB Cluster 7.4 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。 NDB Cluster 7.5. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 7.6 リリースを使用することをお勧めします。最新の NDB Cluster 7.5 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。 NDB Cluster 7.6. このシリーズは NDB Cluster の以前の General Availability (GA) バージョンであり、本番で引き続き使用できますが、新しい配備では最新の NDB Cluster 8.0 リリースを使用することをお勧めします。最新の NDB Cluster 7.6 リリースは、https://dev.mysql.com/downloads/cluster/ から取得できます。 NDB Cluster 8.0. このシリーズは、`NDB` ストレージエンジンおよび MySQL Server 8.0 のバージョン 8.0 に基づいた NDB Cluster の最新の General Availability (GA) バージョンです。 NDB Cluster 8.0 は本番で使用できます。本番用の新しい配備では、現在 NDB Cluster 8.0.23 であるこのシリーズの最新の GA リリースを使用するようにしてください。 https://dev.mysql.com/downloads/cluster/ から最新の NDB Cluster 8.0 リリースを取得できます。このシリーズの新機能およびその他の重要な変更の詳細は、What is New in NDB Cluster を参照してください。 NDB Cluster はソース (セクション23.2.1.4「Linux でのソースからの NDB Cluster の構築」およびセクション23.2.2.2「Windows でのソースからの NDB Cluster のコンパイルとインストール」を参照) から取得およびコンパイルできますが、もっとも特殊なケースを除くすべてのケースで、使用しているオペレーティングシステムおよび状況に適した Oracle によって提供される次のインストーラのいずれかを使用することをお勧めします: web ベースの NDB Cluster Auto-Installer (`NDB` でサポートされているすべてのプラットフォームで動作) Linux binary release (`tar.gz` ファイル) Linux RPM package Linux `.deb` file Windows binary 「no-install」 release Windows MSI Installer インストールパッケージは、プラットフォームパッケージ管理システムからも入手できます。使用している MySQL Server で `NDB` がサポートされるかどうかを判別するには、`SHOW VARIABLES LIKE 'have_%'`、`SHOW ENGINES`、または `SHOW PLUGINS` ステートメントのいずれかを使用します。
A.10.2.	「NDB」および「NDBCLUSTER」は何を意味していますか。
	「NDB」は「Network Database」を意味しています。 `NDB` と `NDBCLUSTER` はどちらも、MySQL でのクラスタリングのサポートを可能にするストレージエンジンの名前です。 `NDB` をお薦めしますが、どちらの名前も正しいです。
A.10.3.	NDB Cluster の使用と MySQL レプリケーションの使用の違いは何ですか。
	従来の 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 レプリケーション」を参照してください。
A.10.4.	NDB Cluster を実行するために特別なネットワークは必要ですか。クラスタ内のコンピュータはどのように通信しますか。
	NDB Cluster は、TCP/IP を使用してコンピュータを接続する高帯域幅環境で使用することを目的としています。そのパフォーマンスは、クラスタ内のコンピュータ間の接続速度に直接関係しています。 NDB Cluster の最小接続要件には、標準的な 100 メガビットイーサネットネットワークまたは同等のものが含まれます。可能な場合はギガビット Ethernet を使用することをお勧めします。
A.10.5.	NDB Cluster を実行するために必要なコンピュータの数とその理由を教えてください。
	実行可能なクラスタの実行には、少なくとも 3 台のコンピュータが必要となります。ただし、NDB Cluster 内のコンピュータの最小推奨数は 4 です: それぞれが管理ノードと SQL ノードを実行し、2 台のコンピュータがデータノードとして機能します。データノードを 2 台にする目的は冗長性を持たせるためです。管理ノードは別個のマシンで実行して、いずれかのデータノードで障害が発生した場合にアービトレーションサービスが継続されることを保証する必要があります。スループットおよび高可用性を向上させるには、複数の SQL ノード (クラスタに接続された MySQL サーバー) を使用してください。複数の管理サーバーを実行することもできます (必須ではありません)。
A.10.6.	NDB Cluster では、どのようなコンピュータが機能しますか。
	NDB Cluster には物理的な編成と論理的な編成の両方があり、コンピュータは物理的な要素です。クラスタの論理要素または機能要素はノードと呼ばれ、クラスタのノードを収容するコンピュータはクラスタホストと呼ばれることがあります。クラスタ内の特定のロールにそれぞれ対応する 3 つのタイプのノードがあります。これらを次に示します。管理ノード. このノードはクラスタ全体の管理サービス (起動、シャットダウン、バックアップ、およびほかのノードの構成データを含む) を提供します。管理ノードサーバーはアプリケーション ndb_mgmd として実装され、NDB Cluster の制御に使用される管理クライアントは ndb_mgm です。これらのプログラムについては、セクション23.4.4「ndb_mgmd — NDB Cluster 管理サーバーデーモン」およびセクション23.4.5「ndb_mgm — NDB Cluster 管理クライアント」を参照してください。データノード. このタイプのノードは、データを格納およびレプリケートします。データノードの機能は、`NDB` データノードプロセスndbd のインスタンスによって処理されます。詳細は、セクション23.4.1「ndbd — NDB Cluster データノードデーモン」を参照してください。 SQL ノード. これは、`NDBCLUSTER` ストレージエンジンをサポートして構築され、エンジンを有効にするための `--ndb-cluster` オプションと NDB Cluster 管理サーバーに接続できるようにするための `--ndb-connectstring` オプションで起動される MySQL Server (mysqld) の単なるインスタンスです。これらのオプションについては、セクション23.3.3.9.1「NDB Cluster の MySQL Server オプション」を参照してください。注記 API ノードは、データの格納および取得のためにクラスタのデータノードを直接使用するアプリケーションです。このため、SQL ノードは MySQL サーバーを使用してクラスタへの SQL インタフェースを提供する API ノードの一種であると考えることができます。 NDB Cluster データに直接のオブジェクト指向トランザクションおよびスキャンインタフェースを提供する NDB API を使用して、そのようなアプリケーション (MySQL Server に依存しない) を記述できます。詳細は、NDB Cluster API Overview: The NDB API を参照してください。
A.10.7.	NDB Cluster 管理クライアントで `SHOW` コマンドを実行すると、次のような出力行が表示されます: `id=2 @10.100.10.32 (Version: 8.0.23-ndb-8.0.23 Nodegroup: 0, )` `「」`は何を意味していますか。このノードはほかのノードとどのように異なりますか。
	最も簡単な回答は、「「NDB Cluster のソースコードを記述または分析するソフトウェアエンジニアでないかぎり、これは制御できないため、どのような場合でも心配する必要はありません」」です。この回答に満足できない場合、より長くテクニカルなバージョンは次のとおりです。 NDB Cluster 内の多くのメカニズムでは、データノード間で分散調整が必要です。これらの分散アルゴリズムおよびプロトコルには、グローバルチェックポイント、DDL (スキーマ) の変更、およびノードの再起動処理が含まれます。この調整を単純にするために、それらのメンバーのいずれかがリーダーとして動作するようにデータノードで「選出」されます。この選択に影響を与えるユーザー向けメカニズムはありません。これは完全に自動です。これは NDB Cluster 内部アーキテクチャーの重要な部分です。ノードがこれらのメカニズムの「リーダー」として動作する場合、通常、それがアクティビティーの調整の中心となり、「フォロワー」として動作するほかのノードは、リーダーによって指示されたアクティビティーの各自の担当分を実行します。リーダーとして動作するノードで障害が発生すると、残りのノードによって新しいリーダーが選出されます。古いリーダーによって調整されていた進行中のタスクは、実際に関係するメカニズムに従って、失敗するか、新しいリーダーによって続行されます。これらの各種のメカニズムおよびプロトコルの一部で別のリーダーノードが使用されることがありますが、一般的には、それらのすべてで同じリーダーが選択されます。管理クライアントの `SHOW` の出力でリーダーとして示されるノードは、DDL およびメタデータアクティビティの調整を担当する `DICT` マネージャと内部的に呼ばれます。 NDB Cluster は、リーダーの選択がクラスタ自体の外部で認識できないように設計されています。たとえば、現在のリーダーの CPU またはリソースの使用量がほかのデータノードより著しく高いことはなく、リーダーで障害が発生した場合にほかのデータノードで障害が発生した場合よりクラスタに対して特別に大きい影響があるということはありません。
A.10.8.	NDB Cluster はどのオペレーティングシステムで使用できますか。
	NDB Cluster は、ほとんどの Unix に似たオペレーティングシステムでサポートされています。 NDB Cluster は、Microsoft Windows オペレーティングシステムの本番設定でもサポートされています。さまざまなオペレーティングシステムバージョン、オペレーティングシステム配布、およびハードウェアプラットフォームで NDB Cluster に提供されるサポートのレベルに関する詳細は、https://www.mysql.com/support/supportedplatforms/cluster.html を参照してください。
A.10.9.	NDB Cluster を実行するためのハードウェア要件は何ですか。
	NDB Cluster は、`NDB` 対応バイナリが使用可能な任意のプラットフォームで実行するようにしてください。データノードおよび API ノードの場合、より速い CPU およびより多くのメモリーによって、パフォーマンスが向上することがあり、64 ビットの CPU は 32 ビットのプロセッサよりも効率的である場合があります。各ノードのデータベースの分担を保持するために、データノードに使用されるマシンに十分なメモリーがある必要があります (詳細は、「必要な RAM のサイズはどれくらいですか」を参照してください)。 NDB Cluster 管理サーバーの実行にのみ使用されるコンピュータの場合、要件は最小限です。一般に、このタスクには共通のデスクトップ PC (または同等のもの) で十分です。ノードは標準の TCP/IP ネットワークおよびハードウェアを使用して通信できます。高速の SCI プロトコルを使用することもできます。ただし、SCI を使用するには、特殊なネットワークハードウェアおよびソフトウェアが必要となります (セクション23.3.4「NDB Cluster での高速インターコネクトの使用」を参照してください)。
A.10.10.	NDB Cluster を使用するには、どのくらいの RAM が必要ですか。ディスクメモリーを使用することはできますか。
	NDB Cluster は最初はインメモリーとしてのみ実装されましたが、現在使用可能なすべてのバージョンで NDB Cluster をディスクに格納する機能も提供されています。詳細は、セクション23.5.10「NDB Cluster ディスクデータテーブル」を参照してください。インメモリーの `NDB` テーブルの場合は、クラスタ内の各データノードで必要となる RAM の容量のおおよその見積もりを取得するために次の式を使用できます。 `(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes` メモリー要件をより正確に計算するには、クラスタデータベースの各テーブルで行ごとに必要となる格納領域 (詳細は、セクション11.7「データ型のストレージ要件」を参照してください) を判別して、それを行数で乗算する必要があります。カラムインデックスについては、次のことを考慮する必要もあります。 `NDBCLUSTER` テーブルに作成される各主キーまたはハッシュインデックスには、レコードごとに 21−25 バイトが必要となります。これらのインデックスは `IndexMemory` を使用します。順序付けされた各インデックスでは、`DataMemory` を使用して、レコードごとに 10 バイトのストレージが必要となります。また、主キーまたは一意のインデックスを作成すると、このインデックスが `USING HASH` を指定して作成された場合を除き、順序付けされたインデックスが作成されます。言い換えると、次のようになります。通常、クラスタテーブルの主キーまたは一意のインデックスには、レコードごとに 31 - 35 バイトが使用されます。ただし、主キーまたは一意のインデックスが `USING HASH` を指定して作成されている場合は、レコードごとに 21 バイトから 25 バイトのみが必要となります。すべての主キーおよび一意インデックスに対して `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% に達したときに、警告がクラスタログに書き込まれます。
A.10.11.	NDB Cluster ではどのファイルシステムを使用できますか。ネットワークファイルシステムまたはネットワーク共有は使用できますか。
	一般に、ホストオペレーティングシステムにネイティブなファイルシステムは NDB Cluster で正常に動作します。 NDB Cluster で特定のファイルシステムが特に適切に動作する (または特にうまく動作しない) ことがわかった場合は、「NDB Cluster フォーラム」での結果について話し合うように招待します。 Windows の場合は、標準の MySQL の場合と同様に、NDB Cluster に `NTFS` ファイルシステムを使用することをお勧めします。 `FAT` または `VFAT` ファイルシステムで NDB Cluster をテストしません。このため、MySQL または NDB Cluster での使用はお勧めしません。 NDB Cluster はシェアードナッシングのソリューションとして実装されています。これの背後にある考えは、単一のハードウェアの障害によって複数のクラスタノードの障害が発生したり、場合によってはクラスタ全体の障害が発生したりしないことです。このため、NDB Cluster ではネットワーク共有またはネットワークファイルシステムの使用はサポートされていません。これは、SAN などの共有ストレージデバイスにも当てはまります。
A.10.12.	NDB Cluster ノードを仮想マシン (VMWare、VirtualBox、Parallels、Xen によって作成されたものなど) 内で実行できますか。
	NDB Cluster は、仮想マシンでの使用がサポートされています。現在、Oracle VM を使用してサポートおよびテストが行われています。一部の NDB Cluster ユーザーは、ほかの仮想化製品を使用して NDB Cluster を正常に配備しました。このような場合、Oracle は NDB Cluster のサポートを提供できますが、仮想環境に固有の問題はその製品ベンダーに示す必要があります。
A.10.13.	NDB Cluster データベースにデータを移入しようとしています。ロード処理が予期せずに終了し、次のようなエラーメッセージが表示されます。 `「ERROR 1114: The table 'my_cluster_table' is full」` これが発生するのはなぜですか。
	原因はすべてのテーブルデータおよびすべてのインデックス (テーブル定義に主キーの定義が含まれていない場合に自動的に作成される、`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` テーブルまたはデータの格納には使用できません。
A.10.14.	NDB Cluster は TCP/IP を使用します。これは、1 つ以上のノードをリモートの場所に配置して、インターネット経由で実行できることを意味しますか。
	NDB Cluster は 100 Mbps またはギガビット Ethernet を使用した LAN 設定で見つかったような専用の高速接続を保証する条件で実行されることを前提として設計および実装されているため、このような状況でクラスタが確実に実行される可能性は very ではありません。これより遅い環境で使用したときのパフォーマンスはテストされておらず保証されません。また、NDB Cluster 内のノード間の通信はセキュリティー保護されておらず、ほかの保護メカニズムによって暗号化も保護もされていないことに注意してください。クラスタのもっともセキュアな構成は、外部からクラスタのデータまたは管理ノードに直接アクセスされない、ファイアウォールの内側のプライベートネットワークです。 (SQL ノードの場合は、MySQL サーバーのほかのインスタンスの場合と同様の予防措置を取るようにしてください。) 詳細は、セクション23.5.17「NDB Cluster のセキュリティーの問題」を参照してください。
A.10.15.	NDB Cluster を使用するには、新しいプログラミング言語またはクエリー言語を学習する必要がありますか。
	いいえ。クラスタ自体の管理および構成にはいくつかの特殊なコマンドが使用されますが、次の操作には標準の (My)SQL ステートメントのみが必要となります。テーブルの作成、変更、および削除テーブルデータの挿入、更新、および削除プライマリインデックスおよび一意のインデックスの作成、変更、および削除 NDB Cluster を設定するには、いくつかの特殊な構成パラメータおよびファイルが必要です。これらについては、セクション23.3.3「NDB Cluster 構成ファイル」を参照してください。 NDB Cluster 管理クライアント (ndb_mgm) では、クラスタノードの起動や停止などのタスクにいくつかの単純なコマンドが使用されます。セクション23.5.1「NDB Cluster 管理クライアントのコマンド」を参照してください。
A.10.16.	NDB Cluster でサポートされているプログラミング言語および API は何ですか。
	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を参照してください。
A.10.17.	NDB Cluster には管理ツールは含まれていますか。
	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)を参照してください。
A.10.18.	NDB Cluster の使用時にエラーまたは警告メッセージが何を意味しているかを調べるにはどうすればよいですか。
	これを行うことができる方法は 2 つあります。エラー状態または警告状態を通知された直後に、mysql クライアント内で SHOW ERRORS または SHOW WARNINGS を使用します。システムのシェルプロンプトで、perror --ndb `error_code` を使用します。
A.10.19.	NDB Cluster トランザクションセーフですか。どのような分離レベルがサポートされますか。
	はい。 `NDB` ストレージエンジンを指定して作成されたテーブルの場合は、トランザクションがサポートされます。現在、NDB Cluster は `READ COMMITTED` トランザクション分離レベルのみをサポートしています。
A.10.20.	NDB Cluster でサポートされているストレージエンジンを教えてください。
	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 の使用」も参照してください。
A.10.21.	致命的な障害が発生した場合 (たとえば、都市全体の電力が失われ、UPS で障害が発生した場合、すべてのデータが失われますか。
	コミットされたすべてのトランザクションはログ記録されます。このため、大災害が起こった場合に一部のデータが失われることはありますが、それはごく限定的なものとなります。データの損失は、トランザクションごとの操作の数を最小限にすることによって、さらに減らすことができます。 (どのような場合でも、1 つのトランザクションで多数の操作を実行するのはよい考えではありません。)
A.10.22.	NDB Cluster で `FULLTEXT` インデックスを使用できますか。
	`FULLTEXT` のインデックス作成は現在、`InnoDB` および `MyISAM` ストレージエンジンでのみサポートされています。詳細は、セクション12.10「全文検索関数」を参照してください。
A.10.23.	単一のコンピュータ上で複数のノードを実行できますか。
	実行できますが常に推奨できるとは限りません。クラスタを実行する主な理由の 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 ノードのプロセスが使用できるディスクおよびメモリーの容量など) によって異なります。そのような構成を計画する場合は、これらの要因を考慮する必要があります。
A.10.24.	NDB Cluster を再起動せずにデータノードを追加できますか。
	クラスタをオフラインにせずに、実行中の NDB Cluster に新しいデータノードを追加できます。詳細は、セクション23.5.7「NDB Cluster データノードのオンラインでの追加」を参照してください。ほかのタイプの NDB Cluster ノードの場合は、ローリング再起動がすべて必要です (セクション23.5.5「NDB Cluster のローリング再起動の実行」を参照)。
A.10.25.	NDB Cluster を使用するときに注意するべき制限はありますか。
	MySQL NDB Cluster での `NDB` テーブルの制限事項は次のとおりです: 一時テーブルはサポートされません。`ENGINE=NDB` または `ENGINE=NDBCLUSTER` を使用した `CREATE TEMPORARY TABLE` ステートメントは、エラーが発生して失敗します。 `NDBCLUSTER` テーブルでサポートされるユーザー定義のパーティション化のタイプは、`KEY` および `LINEAR KEY` のみです。ほかのパーティショニングタイプを使用して `NDB` テーブルを作成しようとすると、エラーが発生して失敗します。 `FULLTEXT` インデックスはサポートされません。インデックスのプリフィクスはサポートされません。インデックスを作成できるのは完全なカラムのみです。空間インデックスはサポートされません (空間カラムは使用できます)。セクション11.4「空間データ型」を参照してください。部分的なトランザクションおよび部分的なロールバックのサポートは、ほかのトランザクションストレージエンジン (個別のステートメントをロールバックできる `InnoDB` など) と同等です。テーブルごとに許可される属性の最大数は 512 個です。属性名は 31 文字以内である必要があります。各テーブルで、テーブル名とデータベース名を合わせた最大長は 122 文字です。 NDB 8.0 では、テーブル行の最大サイズは 14 K バイトであり、`BLOB` 値はカウントされません。 NDB 8.0 では、この最大値は 30000 バイトに増加します。詳細は、セクション23.1.7.5「NDB Cluster 内のデータベースオブジェクトに関連付けられる制限」を参照してください。 `NDB` テーブルごとの行数の制限はありません。テーブルサイズの制限は多くの要因によって異なり、各データノードで使用できる RAM の容量に特に関係しています。 NDB Cluster の制限の完全なリストについては、セクション23.1.7「NDB Cluster の既知の制限事項」を参照してください。セクション23.1.7.11「前 NDB Cluster 8.0 で解決される NDB Cluster の問題」も参照してください。
A.10.26.	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 以降を使用するようにしてください。
A.10.27.	NDB Cluster に既存の MySQL データベースをインポートするにはどうすればよいですか。
	NDB Cluster には、ほかのバージョンの MySQL と同様にデータベースをインポートできます。この FAQ の各所で説明されている制限以外の唯一の特別な要件は、クラスタに含まれるテーブルが `NDB` ストレージエンジンを使用する必要があることです。これは、`ENGINE=NDB` または `ENGINE=NDBCLUSTER` を指定してテーブルを作成する必要があることを意味します。ほかのストレージエンジンを使用しているテーブルを、1 つ以上の `ALTER TABLE` ステートメントを使用して、`NDBCLUSTER` に変更することもできます。ただし、変更を行う前に、テーブルの定義が `NDBCLUSTER` ストレージエンジンと互換性がある必要があります。 MySQL 8.0 では、追加の回避策も必要となります。詳細は、セクション23.1.7「NDB Cluster の既知の制限事項」を参照してください。
A.10.28.	NDB Cluster ノードはどのように相互に通信しますか。
	クラスタのノードは、3 種類の転送メカニズム (TCP/IP、SHM (共有メモリー)、および SCI (スケーラブルコヒーラントインタフェース)) を使用して通信できます。使用可能な場合、同じクラスタホスト上にあるノード間では SHM がデフォルトで使用されます。ただし、これは実験的とみなされます。 SCI は、スケーラブルなマルチプロセッサシステムを構築するために使用される高速 (1 Gbps 以上) で高可用性のプロトコルであり、特殊なハードウェアおよびドライバが必要となります。 NDB Cluster のトランスポートメカニズムとして SCI を使用する方法の詳細は、セクション23.3.4「NDB Cluster での高速インターコネクトの使用」を参照してください。
A.10.29.	アービトレータとは何ですか。
	クラスタ内の 1 つ以上のデータノードで障害が発生した場合、すべてのクラスタデータノードが相互に「「参照」」できるわけではありません。実際に、2 つのセットのデータノードがネットワークのパーティション化で別々に分離されることがあります (「スプリットブレイン」シナリオとも呼ばれます)。各セットのデータノードがクラスタ全体のように動作しようとするため、このタイプの状況は好ましくありません。競合するデータノードのセットのいずれかを選択するために、アービトレータが必要となります。少なくとも 1 つのノードグループのすべてのデータノードが存続して場合、クラスタの単一のサブセットが独自に機能するクラスタを形成できないため、ネットワークのパーティション化は問題とはなりません。本当の問題はすべてのノードが存続している単一のノードグループがない場合に発生し、その場合はネットワークのパーティション化 (「スプリットブレイン」シナリオ) が発生する可能性があります。そしてアービトレータが必要となります。すべてのクラスタノードは、同じノードをアービトレータとして認識しますが、通常、これは管理サーバーです。ただし、クラスタ内の MySQL サーバーのいずれかを代わりにアービトレータとして動作するように構成できます。アービトレータは、クラスタノードの最初のセットがアクセスすることを受け入れ、残りのセットにシャットダウンするように指示します。アービトレータの選択は、MySQL サーバーおよび管理サーバーノードの `ArbitrationRank` 構成パラメータによって制御されます。 `ArbitrationRank` 構成パラメータを使用してアービトレータの選択プロセスを制御することもできます。これらのパラメータについては、セクション23.3.3.5「NDB Cluster 管理サーバーの定義」を参照してください。アービトレータの役割によって、指定されたホストに重い要求が課されることはないため、アービトレータのホストはこの目的のために特別に処理が速いマシン、または追加のメモリーがあるマシンである必要はありません。
A.10.30.	NDB Cluster でサポートされているデータ型は何ですか。
	NDB Cluster は、MySQL 空間拡張機能に関連付けられたデータ型を含め、通常の MySQL データ型をすべてサポートしますが、`NDB` ストレージエンジンは空間インデックスをサポートしていません。 (空間インデックスは `MyISAM` によってのみサポートされます。詳細は、セクション11.4「空間データ型」を参照してください。) また、`NDB` テーブルとともに使用された場合、インデックスに関していくつかの違いがあります。注記「NDB Cluster ディスクデータ」テーブル (`TABLESPACE ... STORAGE DISK ENGINE=NDB` または `TABLESPACE ... STORAGE DISK ENGINE=NDBCLUSTER` で作成されたテーブル) には固定幅の行のみがあります。これは、(たとえば) `VARCHAR(255)` カラムが含まれている各ディスクデータテーブルレコードで、実際に格納される文字数に関係なく、255 文字 (テーブルに使用されている文字セットおよび照合順序に必要となります) の領域が必要となることを意味します。これらの問題については、セクション23.1.7「NDB Cluster の既知の制限事項」を参照してください。
A.10.31.	NDB Cluster を起動および停止するにはどうすればよいですか。
	クラスタ内の各ノードを次の順序で個別に起動する必要があります。 ndb_mgmd コマンドを使用して、管理ノードを起動します。 `-f` オプションまたは `--config-file` オプションを指定して、構成ファイルのある場所を管理ノードに通知する必要があります。 ndbd コマンドを使用して、各データノードを起動します。データノードが管理サーバーに接続する方法を認識するように、`-c` オプションまたは `--ndb-connectstring` オプションを指定して各データノードを起動する必要があります。任意の起動スクリプト (mysqld_safe など) を使用して各 MySQL サーバー (SQL ノード) を起動します。各 MySQL サーバーは、`--ndbcluster` オプションおよび `--ndb-connectstring` オプションを指定して起動する必要があります。これらのオプションにより、mysqld は `NDBCLUSTER` ストレージエンジンのサポートおよび管理サーバーへの接続方法を有効にします。影響を受けるノードがあるマシンのシステムシェルで、これらの各コマンドを実行する必要があります。 (そのマシンを物理的にその場で操作する必要はありません。リモートログインシェルをこの目的に使用できます。) クラスタが実行されていることを確認するには、管理ノードが収容されているマシンで `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 (サポートされなくなりました)」を参照してください。
A.10.32.	NDB Cluster をシャットダウンすると、NDB Cluster データはどうなりますか。
	クラスタのデータノードによってメモリーに保持されていたデータがディスクに書き込まれ、次回クラスタが起動されたときにメモリーにリロードされます。
A.10.33.	NDB Cluster に複数の管理ノードを設定することをお勧めしますか。
	フェイルセーフとして役に立つことがあります。特定の時点でクラスタを制御しているのは 1 つの管理ノードのみですが、1 つの管理ノードをプライマリとして構成し、プライマリ管理ノードで障害が発生した場合に、1 つ以上の追加の管理ノードが引き継ぐようにすることができます。 NDB Cluster 管理ノードを構成する方法については、セクション23.3.3「NDB Cluster 構成ファイル」を参照してください。
A.10.34.	1 つの NDB Cluster に異なる種類のハードウェアとオペレーティングシステムを混在させることはできますか。
	はい。すべてのマシンおよびオペレーティングシステムが同じ「エンディアン」 (すべてがビッグエンディアンまたはすべてがリトルエンディアン) であれば可能です。異なる NDB Cluster リリースのソフトウェアを異なるノードで使用することもできます。ただし、このような使用はローリングアップグレード手順の一部としてのみサポートされています (セクション23.5.5「NDB Cluster のローリング再起動の実行」を参照)。
A.10.35.	単一のホスト上で 2 つのデータノードを実行できますか。 2 つの SQL ノードは実行できますか。
	はい。実行できます。複数のデータノードの場合は、各ノードで別のデータディレクトリを使用することをお勧めします (必須ではありません)。単一のマシン上で複数の SQL ノードを実行する場合は、mysqld の各インスタンスで別の TCP/IP ポートを使用する必要があります。データノードと SQL ノードを同じホスト上で同時に実行することは可能ですが、ndbd または ndbmtd プロセスが mysqld とのメモリーを競合する可能性があることに注意してください。
A.10.36.	NDB Cluster でホスト名を使用できますか。
	はい。クラスタのホストに DNS および DHCP を使用できます。ただし、アプリケーションが「ファイブナイン」可用性を要求する場合は、固定 (数値) IP アドレスを使用してください。クラスタホスト間通信を DNS、DHCP などのサービスに依存させると、潜在的な障害点が増えるためです。
A.10.37.	NDB Cluster は IPv6 をサポートしていますか。
	IPv6 は SQL ノード (MySQL サーバー) 間の接続でサポートされていますが、ほかのすべてのタイプの NDB Cluster ノード間の接続は IPv4 を使用する必要があります。これは、実質的には NDB Cluster 間のレプリケーションに IPv6 を使用できるが、同じ NDB Cluster 内のノード間の接続には IPv4 を使用する必要があることを意味します。詳細は、セクション23.6.3「NDB Cluster レプリケーションの既知の問題」を参照してください。
A.10.38.	複数の MySQL サーバーを持つ NDB Cluster で MySQL ユーザーを処理するにはどうすればよいですか。
	通常、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 で採用されていた共有特権メカニズムと互換性がないことに注意してください。
A.10.39.	SQL ノードの 1 つで障害が発生した場合に、クエリーの送信を続けるにはどうすればよいですか。
	MySQL NDB Cluster では、SQL ノード間の自動フェイルオーバーは一切提供されません。アプリケーションは、SQL ノードの損失を処理し、それらの間でフェイルオーバーする準備ができている必要があります。
A.10.40.	NDB Cluster をバックアップおよび復元するにはどうすればよいですか。
	NDB 管理クライアントおよび ndb_restore プログラムで NDB Cluster のネイティブバックアップおよび復元機能を使用できます。セクション23.5.8「NDB Cluster のオンラインバックアップ」およびセクション23.4.23「ndb_restore — NDB Cluster バックアップの復元」を参照してください。このために mysqldump および MySQL サーバーで提供されている従来の機能を使用することもできます。詳細は、セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。
A.10.41.	「エンジェルプロセス」とは何ですか。
	このプロセスは、データノードプロセスをモニターし、必要に応じて再起動を試みます。 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 プロセスはプライマリデータノードプロセスの再起動を試みます。

A.10 MySQL 8.0 FAQ: NDB Cluster