Question

A.10.1.

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

Answer 1

MySQL Cluster は標準の MySQL Server 5.6 リリースではサポートされません。そうではなく、MySQL Cluster は個別の製品として提供されています。現在、次の MySQL Cluster リリースを本番で使用できます。

MySQL Cluster NDB 7.3 このシリーズは、MySQL Cluster の最新の一般提供 (GA) バージョンであり、NDB ストレージエンジンのバージョン 7.3 および MySQL Server 5.6 に基づいています。新しい配備には、このシリーズの最新のリリースを使用してください。最新の MySQL Cluster NDB 7.3 リリースは https://dev.mysql.com/downloads/cluster/ から入手できます。
MySQL Cluster NDB 7.4 これは、MySQL Cluster の現在の開発バージョンであり、NDB ストレージエンジンのバージョン 7.4 および MySQL Server 5.6 に基づいています。現在、MySQL Cluster NDB 7.4 はテストおよび評価のために使用できます。最新の MySQL Cluster NDB 7.4 リリースは https://dev.mysql.com/downloads/cluster/ から入手できます。

MySQL Cluster NDB 7.4 での改善点の概要については、セクション18.1.4.2「MySQL Cluster NDB 7.4 での MySQL Cluster の開発」を参照してください。

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

Answer 2

「NDB」は「Network Database」を意味しています。NDB および NDBCLUSTER は、MySQL でクラスタがサポートされるストレージエンジンの名前です。開発者は NDB を好んでいますが、どちらの名前も正しい名前です。両方の名前がドキュメントに記述され、どちらの名前も MySQL Cluster テーブルを作成するための CREATE TABLE ステートメントの ENGINE オプションに使用できます。

Answer 3

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

簡単に言うと、標準の MySQL レプリケーションは非同期で実行され、MySQL Cluster は同期を維持して実行されます。

非同期レプリケーションは MySQL Cluster でも使用できます。MySQL Cluster Replication (「ジオレプリケーション」を呼ばれることもあります) には、2 つの MySQL Cluster 間のレプリケーション、および MySQL Cluster からクラスタ化されていない MySQL サーバーへのレプリケーションの両方を行う機能が含まれています。セクション18.6「MySQL Cluster レプリケーション」を参照してください。

Answer 4

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

より速い SCI プロトコルもサポートされますが、特殊なハードウェアが必要となります。SCI については、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。

Answer 5

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

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

Answer 6

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

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

注記

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

Answer 7

もっとも簡単な回答は、「ユーザーが制御できるものではなく、MySQL Cluster のソースコードを記述または分析するソフトウェアエンジニアではないかぎり、どのような場合でも憂慮する必要はないものです」となります。

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

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

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

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

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

Answer 8

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

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

Answer 9

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

Answer 10

以前は、MySQL Cluster はインメモリーのみを使用していました。MySQL 5.1 以降では、MySQL Cluster をディスクに格納する機能も提供されています。(この機能を以前のリリースにバックポートする計画はありません。)詳細は、セクション18.5.12「MySQL 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 を指定して MySQL Cluster のテーブルを作成すると、通常、テーブルの更新がより迅速に実行されます。主キーおよびユニークキーの作成に USING HASH が使用されなかったテーブルへの更新より 20 - 30% 速いことがあります。これは、必要なメモリーが少なくなり (順序付けされたインデックスが作成されないため)、使用される CPU が少なくなる (読み取りおよび (場合によっては) 更新する必要があるインデックスが少なくなるため) ためです。ただし、これは、本来範囲スキャンを使用するクエリーをほかの方法で実行する必要があることも意味し、選択が低速になることがあります。

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

すべての MySQL Cluster テーブルには主キーがある必要があることに留意することが非常に重要です。NDB ストレージエンジンは、主キーが定義されていない場合、主キーを自動的に作成します。この主キーは USING HASH を指定せずに作成されます。

ある時点で MySQL Cluster のデータおよびインデックスの格納に使用されているメモリー量を判別するには、ndb_mgm クライアントで REPORT MEMORYUSAGE コマンドを使用します。詳細は、セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。また、使用可能な DataMemory または IndexMemory の 80% が使用されている場合、および使用率が 85%、90% などに達した場合に、警告がクラスタのログに書き込まれます。

Answer 11

通常、ホストのオペレーティングシステムにネイティブなファイルシステムは、MySQL Cluster で動作します。特定のファイルシステムが MySQL Cluster と特に良好に動作する (またはそれほどよくない) ことがわかった場合は、その知見をMySQL Cluster フォーラムで共有してください。

Windows の場合は、通常の MySQL と同様に、MySQL Cluster に NTFS ファイルシステムを使用することをお勧めします。FAT ファイルシステムまたは VFAT ファイルシステムでは、MySQL Cluster はテストされていません。このため、それらを MySQL または MySQL Cluster に使用することはお勧めしません。

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

Answer 12

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

一部の MySQL Cluster ユーザーは、ほかの仮想化製品を使用して MySQL Cluster の配備に成功しました。そのような場合、オラクルは MySQL Cluster のサポートを提供できますが、仮想環境に固有の問題についてはその製品のベンダーに問い合わせる必要があります。

Answer 13

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

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

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

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

Answer 14

そのような状況でクラスタが確実に実行される可能性はほとんどありません。MySQL Cluster は、100M ビット/秒またはギガビット Ethernet (後者が望ましい) を使用した LAN 環境のような専用の高速接続が保証された状況で実行されることを想定して設計および実装されているためです。これより遅い環境で使用したときのパフォーマンスはテストされておらず保証されません。

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

Answer 15

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

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

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

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

Answer 16

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

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

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

MySQL Cluster (NDB 7.2 以降) には、memcached のサポートが追加され、開発者は memcached インタフェースを使用して MySQL Cluster に格納されているデータにアクセスできます。詳細は、ndbmemcache—Memcache API for NDB Clusterを参照してください。

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

Answer 17

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

MySQL Cluster NDB 7.0 以降は MySQL Cluster Manager によってもサポートされます。これは別個の製品であり、ローリング再起動、構成の変更などの MySQL Cluster の多くの管理タスクを自動化できる拡張されたコマンド行インタフェースが提供されます。MySQL Cluster Manager については、MySQL™ Cluster Manager 1.3.6 User Manualを参照してください。

MySQL Cluster NDB 7.3 では、MySQL Cluster ソフトウェア配布の一部として、MySQL Cluster を設定および配備するためのブラウザベースのグラフィカルな Auto-Installer が導入されました。詳細は、セクション18.2.1「MySQL Cluster Auto-Installer」を参照してください。

Answer 18

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

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

Answer 19

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

Answer 20

MySQL でのクラスタリングは、NDB ストレージエンジンによってのみサポートされます。つまり、MySQL Cluster のノード間でテーブルを共有するには、ENGINE=NDB (または同等のオプション ENGINE=NDBCLUSTER) を使用してテーブルを作成する必要があります。

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

Answer 21

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

Answer 22

現在、FULLTEXT インデックスは、InnoDB ストレージエンジン (MySQL 5.6.4 以降) および MyISAM ストレージエンジンのみによってサポートされています。詳細は、セクション12.9「全文検索関数」を参照してください。

Answer 23

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

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

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

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

Answer 24

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

ほかのタイプの MySQL Cluster ノードの場合は、ローリング再起動を行えばよいだけです (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。

Answer 25

MySQL Cluster NDB 7.3 以降の NDB テーブルの制限には次のものがあります。

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

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

MySQL Cluster の制限の完全なリストについては、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。セクション18.1.6.11「MySQL Cluster NDB 7.3 で解決された以前の MySQL Cluster の問題」も参照してください。

Answer 26

MySQL Cluster NDB 7.3 では、InnoDB ストレージエンジンと同等の外部キー制約のサポートが追加されました。詳細は、セクション1.7.3.2「FOREIGN KEY の制約」およびセクション13.1.17.2「外部キー制約の使用」を参照してください。外部キーのサポートが必要なアプリケーションの場合は、MySQL Cluster NDB 7.3 以降を使用してください。

Answer 27

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

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

Answer 28

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

Answer 29

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

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

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

Answer 30

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

注記

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

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

Answer 31

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

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

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

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

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

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

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

shell> ndb_mgm -e "SHUTDOWN"

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

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

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

Answer 32

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

Answer 33

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

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

Answer 34

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

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

Answer 35

はい。実行できます。複数のデータノードの場合は、各ノードで別のデータディレクトリを使用することをお勧めします (必須ではありません)。単一のマシン上で複数の SQL ノードを実行する場合は、mysqld の各インスタンスで別の TCP/IP ポートを使用する必要があります。ただし、MySQL 5.6 では、1 台のマシンで特定のタイプの複数のクラスタノードを実行することは推奨されず、本番での使用はサポートされません。

また、ndbd プロセスおよび mysqld プロセスはメモリーで競合することがあるため、同じホスト上でデータノードおよび SQL ノードを一緒に実行しないことをお勧めします。

Answer 36

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

Answer 37

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

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

Answer 38

通常、MySQL のユーザーアカウントおよび権限は、同じ MySQL Cluster にアクセスする異なる MySQL サーバー間で自動的に伝播されません。MySQL Cluster NDB 7.2 以降では、MySQL Cluster は権限の配布のサポートを提供しています。権限の配布は自動的に有効になりませんが、MySQL Cluster のドキュメントで説明されている次の手順を使用して有効にできます。詳細は、セクション18.5.14「MySQL Cluster の配布された MySQL 権限」を参照してください。

Answer 39

MySQL Cluster は SQL ノード間でどのような種類の自動フェイルオーバーも提供していません。SQL ノードを失ったときの処理、およびそれらの間のフェイルオーバーを行うように、アプリケーションで準備している必要があります。

Answer 40

MySQL Cluster 管理クライアントおよび ndb_restore プログラムの NDB にネイティブなバックアップおよびリストア機能を使用できます。セクション18.5.3「MySQL Cluster のオンラインバックアップ」およびセクション18.4.20「ndb_restore — MySQL 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 ./ndbd -c 127.0.0.1 --initial
me      23097  1.0  2.4 524116 91096 ?        Sl   14:14   0:00 ./ndbd -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 と表示されている ndbd プロセスがエンジェルプロセスです。実際には、もちろんそれぞれにごく少量が使用されます。これは、メインの ndbd プロセス (データを実際に処理するプライマリデータノードプロセス) が実行されているかどうかを単純にチェックします。許可されている場合 (たとえば、StopOnError 構成パラメータが false に設定されている場合。セクション18.3.3.1「MySQL Cluster データノードの構成パラメータ」を参照してください)、エンジェルプロセスはプライマリデータノードプロセスを再起動しようとします。

A.10.1.	クラスタがサポートされる MySQL ソフトウェアのバージョンはどれですか。ソースからコンパイルする必要がありますか。
	MySQL Cluster は標準の MySQL Server 5.6 リリースではサポートされません。そうではなく、MySQL Cluster は個別の製品として提供されています。現在、次の MySQL Cluster リリースを本番で使用できます。 MySQL Cluster NDB 7.3 このシリーズは、MySQL Cluster の最新の一般提供 (GA) バージョンであり、`NDB` ストレージエンジンのバージョン 7.3 および MySQL Server 5.6 に基づいています。新しい配備には、このシリーズの最新のリリースを使用してください。最新の MySQL Cluster NDB 7.3 リリースは https://dev.mysql.com/downloads/cluster/ から入手できます。 MySQL Cluster NDB 7.4 これは、MySQL Cluster の現在の開発バージョンであり、`NDB` ストレージエンジンのバージョン 7.4 および MySQL Server 5.6 に基づいています。現在、MySQL Cluster NDB 7.4 はテストおよび評価のために使用できます。最新の MySQL Cluster NDB 7.4 リリースは https://dev.mysql.com/downloads/cluster/ から入手できます。 MySQL Cluster NDB 7.4 での改善点の概要については、セクション18.1.4.2「MySQL Cluster NDB 7.4 での MySQL Cluster の開発」を参照してください。使用している MySQL Server で `NDB` がサポートされるかどうかを判別するには、`SHOW VARIABLES LIKE 'have_%'`、`SHOW ENGINES`、または `SHOW PLUGINS` ステートメントのいずれかを使用します。
A.10.2.	「NDB」および「NDBCLUSTER」は何を意味していますか。
	「NDB」は「Network Database」を意味しています。`NDB` および `NDBCLUSTER` は、MySQL でクラスタがサポートされるストレージエンジンの名前です。開発者は `NDB` を好んでいますが、どちらの名前も正しい名前です。両方の名前がドキュメントに記述され、どちらの名前も MySQL Cluster テーブルを作成するための `CREATE TABLE` ステートメントの `ENGINE` オプションに使用できます。
A.10.3.	MySQL Cluster を使用した場合と MySQL Replication を使用した場合の違いは何ですか。
	従来の MySQL レプリケーションでは、マスター MySQL サーバーが 1 つ以上のスレーブを更新します。トランザクションは順次的にコミットされ、遅いトランザクションの場合、スレーブでの処理がマスターより遅れることがあります。これは、マスターで障害が発生した場合に、スレーブで最後のいくつかのトランザクションが記録されないことがあることを意味します。`InnoDB` などのトランザクションセーフなエンジンを使用している場合、トランザクションはスレーブで完了するかまったく適用されないかのいずれかであり、レプリケーションではマスターおよびスレーブのすべてのデータが常時整合性がとれていることは保証されません。MySQL Cluster では、すべてのデータノードの同期が維持され、あるデータノードでコミットされたトランザクションはすべてのデータノードでコミットされます。データノードの障害が発生した場合、ほかのすべてのデータノードでは整合性のある状態が維持されます。簡単に言うと、標準の MySQL レプリケーションは非同期で実行され、MySQL Cluster は同期を維持して実行されます。非同期レプリケーションは MySQL Cluster でも使用できます。MySQL Cluster Replication (「ジオレプリケーション」を呼ばれることもあります) には、2 つの MySQL Cluster 間のレプリケーション、および MySQL Cluster からクラスタ化されていない MySQL サーバーへのレプリケーションの両方を行う機能が含まれています。セクション18.6「MySQL Cluster レプリケーション」を参照してください。
A.10.4.	MySQL Cluster を実行するには、特殊なネットワーク環境が必要となりますか。クラスタ内のコンピュータはどのように通信しますか。
	MySQL Cluster は、TCP/IP を使用してコンピュータが接続されている高帯域幅の環境で使用することが意図されています。そのパフォーマンスは、クラスタ内のコンピュータ間の接続速度に直接関係しています。MySQL Cluster の最低限の接続要件には、一般的な 100 メガビット Ethernet ネットワークまたは同等のものが含まれます。可能な場合はギガビット Ethernet を使用することをお勧めします。より速い SCI プロトコルもサポートされますが、特殊なハードウェアが必要となります。SCI については、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。
A.10.5.	MySQL Cluster を実行するために必要なコンピュータは何台ですか。その理由は何ですか。
	実行可能なクラスタの実行には、少なくとも 3 台のコンピュータが必要となります。ただし、MySQL Cluster の推奨される最低限のコンピュータの数は 4 台であり、管理ノードと SQL ノードを実行するためにそれぞれ 1 台ずつ、およびデータノードとして使用される 2 台のコンピュータです。データノードを 2 台にする目的は冗長性を持たせるためです。管理ノードは別個のマシンで実行して、いずれかのデータノードで障害が発生した場合にアービトレーションサービスが継続されることを保証する必要があります。スループットおよび高可用性を向上させるには、複数の SQL ノード (クラスタに接続された MySQL サーバー) を使用してください。複数の管理サーバーを実行することもできます (必須ではありません)。
A.10.6.	MySQL Cluster 内の各種のコンピュータにはどのような役割がありますか。
	MySQL Cluster には、コンピュータを物理的要素とする、物理組織および論理組織の両方があります。クラスタの論理要素または機能要素はノードと呼ばれ、クラスタのノードを収容するコンピュータはクラスタホストと呼ばれることがあります。クラスタ内の特定のロールにそれぞれ対応する 3 つのタイプのノードがあります。これらを次に示します。管理ノードこのノードはクラスタ全体の管理サービス (起動、シャットダウン、バックアップ、およびほかのノードの構成データを含む) を提供します。管理ノードサーバーはアプリケーション ndb_mgmd として実装されます。MySQL Cluster を制御するために使用される管理クライアントは ndb_mgm です。これらのプログラムについては、セクション18.4.4「ndb_mgmd — MySQL Cluster 管理サーバーデーモン」およびセクション18.4.5「ndb_mgm — MySQL Cluster 管理クライアント」を参照してください。データノードこのタイプのノードは、データを格納およびレプリケートします。データノードの機能は、`NDB` データノードプロセスndbd のインスタンスによって処理されます。詳細は、セクション18.4.1「ndbd — MySQL Cluster データノードデーモン」を参照してください。 SQL ノードこれは、単純に MySQL サーバーのインスタンス (mysqld) であり、`NDBCLUSTER` ストレージエンジンのサポートを組み込んでビルドされていて、`--ndb-cluster` オプションを指定して起動することによってこのエンジンを有効にし、`--ndb-connectstring` オプションを指定して MySQL Cluster の管理サーバーに接続できるようにします。これらのオプションについては、セクション18.3.4.2「MySQL Cluster 用の MySQL Server オプション」を参照してください。注記 API ノードは、データの格納および取得のためにクラスタのデータノードを直接使用するアプリケーションです。このため、SQL ノードは MySQL サーバーを使用してクラスタへの SQL インタフェースを提供する API ノードの一種であると考えることができます。直接的でオブジェクト指向のトランザクションおよび MySQL Cluster のデータへのスキャンインタフェースを提供するそのようなアプリケーション (MySQL サーバーに依存しない) は、NDB API を使用して記述できます。詳細は、NDB Cluster API Overview: The NDB APIを参照してください。
A.10.7.	MySQL Cluster の管理クライアントで `SHOW` コマンドを実行すると、次のような出力行が表示されます。 `id=2 @10.100.10.32 (Version: 5.6.22-ndb-7.3.9 Nodegroup: 0, )` `「」`は何を意味していますか。このノードはほかのノードとどのように異なりますか。
	もっとも簡単な回答は、「ユーザーが制御できるものではなく、MySQL Cluster のソースコードを記述または分析するソフトウェアエンジニアではないかぎり、どのような場合でも憂慮する必要はないものです」となります。この回答に満足できない場合、より長くテクニカルなバージョンは次のとおりです。 MySQL Cluster の多数のメカニズムでは、データノードの分散調整が必要となります。これらの分散アルゴリズムおよびプロトコルには、グローバルチェックポイント、DDL (スキーマ) の変更、およびノードの再起動処理が含まれます。この調整を単純にするために、それらのメンバーのいずれかがリーダーとして動作するようにデータノードで「選出」されます。(このノードは「マスター」と呼ばれていましたが、MySQL Replication のマスターサーバーと混乱しないように、この用語は削除されました。)この選択は完全に自動的であり、それに影響するメカニズムをユーザーが目にすることはありません。自動的であることが、MySQL Cluster の内部アーキテクチャーの重要な部分です。ノードがこれらのメカニズムの「リーダー」として動作する場合、通常、それがアクティビティーの調整の中心となり、「フォロワー」として動作するほかのノードは、リーダーによって指示されたアクティビティーの各自の担当分を実行します。リーダーとして動作するノードで障害が発生すると、残りのノードによって新しいリーダーが選出されます。古いリーダーによって調整されていた進行中のタスクは、実際に関係するメカニズムに従って、失敗するか、新しいリーダーによって続行されます。これらの各種のメカニズムおよびプロトコルの一部で別のリーダーノードが使用されることがありますが、一般的には、それらのすべてで同じリーダーが選択されます。管理クライアントの `SHOW` の出力でリーダーとして示されるノードは、DDL およびメタデータのアクティビティーの調整を担当する `DICT` マネージャーと内部では呼ばれています (詳細は、『MySQL Cluster API Developer Guide』のThe DBDICT Blockを参照してください)。 MySQL Cluster は、リーダーの選択がクラスタの外部で認識できるような影響を及ぼさないように設計されています。たとえば、現在のリーダーの CPU またはリソースの使用量がほかのデータノードより著しく高いことはなく、リーダーで障害が発生した場合にほかのデータノードで障害が発生した場合よりクラスタに対して特別に大きい影響があるということはありません。
A.10.8.	MySQL Cluster を使用できるオペレーティングシステムはどれですか。
	MySQL Cluster はほとんどの Unix 系のオペレーティングシステムでサポートされています。MySQL Cluster NDB 7.2 は、Microsoft Windows オペレーティングシステムの本番設定でもサポートされます。さまざまなオペレーティングシステムのバージョン、オペレーティングシステムの配布、およびハードウェアプラットフォームで MySQL Cluster に提供されるサポートのレベルについては、https://www.mysql.com/support/supportedplatforms/cluster.htmlを参照してください。
A.10.9.	MySQL Cluster を実行するためのハードウェア要件は何ですか。
	MySQL Cluster は `NDB` 対応のバイナリを使用できるプラットフォームで実行してください。データノードおよび API ノードの場合、より速い CPU およびより多くのメモリーによって、パフォーマンスが向上することがあり、64 ビットの CPU は 32 ビットのプロセッサよりも効率的である場合があります。各ノードのデータベースの分担を保持するために、データノードに使用されるマシンに十分なメモリーがある必要があります (詳細は、「必要な RAM のサイズはどれくらいですか」を参照してください)。MySQL Cluster の管理サーバーを実行するためにのみ使用されるコンピュータの場合、要件は最低限のものです。通常、このタスクには一般的なデスクトップ PC (または同等のもの) で十分です。ノードは標準の TCP/IP ネットワークおよびハードウェアを使用して通信できます。高速の SCI プロトコルを使用することもできます。ただし、SCI を使用するには、特殊なネットワークハードウェアおよびソフトウェアが必要となります (セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください)。
A.10.10.	MySQL Cluster を使用するために必要な RAM のサイズはどれくらいですか。ディスクメモリーを使用することはできますか。
	以前は、MySQL Cluster はインメモリーのみを使用していました。MySQL 5.1 以降では、MySQL Cluster をディスクに格納する機能も提供されています。(この機能を以前のリリースにバックポートする計画はありません。)詳細は、セクション18.5.12「MySQL 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` を指定して MySQL Cluster のテーブルを作成すると、通常、テーブルの更新がより迅速に実行されます。主キーおよびユニークキーの作成に `USING HASH` が使用されなかったテーブルへの更新より 20 - 30% 速いことがあります。これは、必要なメモリーが少なくなり (順序付けされたインデックスが作成されないため)、使用される CPU が少なくなる (読み取りおよび (場合によっては) 更新する必要があるインデックスが少なくなるため) ためです。ただし、これは、本来範囲スキャンを使用するクエリーをほかの方法で実行する必要があることも意味し、選択が低速になることがあります。クラスタのメモリー要件を計算するときに、最新の MySQL 5.6 リリースに付属している ndb_size.pl ユーティリティーが役に立つことがあります。この Perl スクリプトは、現在の (クラスタではない) MySQL データベースに接続して、`NDBCLUSTER` ストレージエンジンを使用した場合にデータベースで必要となる容量に関する報告を作成します。詳細は、セクション18.4.25「ndb_size.pl — NDBCLUSTER サイズ要件エスティメータ」を参照してください。すべての MySQL Cluster テーブルには主キーがある必要があることに留意することが非常に重要です。`NDB` ストレージエンジンは、主キーが定義されていない場合、主キーを自動的に作成します。この主キーは `USING HASH` を指定せずに作成されます。ある時点で MySQL Cluster のデータおよびインデックスの格納に使用されているメモリー量を判別するには、ndb_mgm クライアントで `REPORT MEMORYUSAGE` コマンドを使用します。詳細は、セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。また、使用可能な `DataMemory` または `IndexMemory` の 80% が使用されている場合、および使用率が 85%、90% などに達した場合に、警告がクラスタのログに書き込まれます。
A.10.11.	MySQL Cluster に使用できるファイルシステムは何ですか。ネットワークファイルシステムまたはネットワーク共有は使用できますか。
	通常、ホストのオペレーティングシステムにネイティブなファイルシステムは、MySQL Cluster で動作します。特定のファイルシステムが MySQL Cluster と特に良好に動作する (またはそれほどよくない) ことがわかった場合は、その知見をMySQL Cluster フォーラムで共有してください。 Windows の場合は、通常の MySQL と同様に、MySQL Cluster に `NTFS` ファイルシステムを使用することをお勧めします。`FAT` ファイルシステムまたは `VFAT` ファイルシステムでは、MySQL Cluster はテストされていません。このため、それらを MySQL または MySQL Cluster に使用することはお勧めしません。 MySQL Cluster はシェアードナッシングソリューションとして実装されています。この背景にある考え方は、1 つのハードウェアの障害によって、複数のクラスタノードの障害、または場合によってはクラスタ全体の障害が引き起こされないようにすることです。このため、ネットワーク共有またはネットワークファイルシステムの使用は、MySQL Cluster ではサポートされません。これは、SAN などの共有ストレージデバイスにも当てはまります。
A.10.12.	MySQL Cluster のノードは、仮想マシン (VMWare、Parallels、Xen によって作成された仮想マシンなど) 内で実行できますか。
	MySQL Cluster は MySQL Cluster NDB 7.2 以降で仮想マシンでの使用がサポートされます。現在、Oracle VM を使用してサポートおよびテストが行われています。一部の MySQL Cluster ユーザーは、ほかの仮想化製品を使用して MySQL Cluster の配備に成功しました。そのような場合、オラクルは MySQL Cluster のサポートを提供できますが、仮想環境に固有の問題についてはその製品のベンダーに問い合わせる必要があります。
A.10.13.	MySQL Cluster データベースにデータを移入しようとしています。ロード処理が予期せずに終了し、次のようなエラーメッセージが表示されます。 `「ERROR 1114: The table 'my_cluster_table' is full」` これが発生するのはなぜですか。
	原因はすべてのテーブルデータおよびすべてのインデックス (テーブル定義に主キーの定義が含まれていない場合に自動的に作成される、`NDB` ストレージエンジンによって要求される主キーを含む) のための十分な RAM が、使用しているセットアップで提供されていないことである可能性があります。すべてのデータノードで同じ容量の RAM が使用されることにも注意してください。クラスタ内のデータノードは、データノードの中で使用可能なメモリーの容量がもっとも少ないノードより多いメモリーを使用することはできないためです。たとえば、クラスタのデータノードをホストしているコンピュータが 4 台あり、そのうちの 3 台がクラスタのデータの格納に 3G バイトの RAM を使用でき、残りのデータノードが 1G バイトの RAM のみを使用できる場合、各データノードは最大 1G バイトを MySQL Cluster のデータおよびインデックスに使用できます。場合によっては、ndb_mgm -e "ALL REPORT MEMORYUSAGE" で `DataMemory` に大きい空き領域が示されていても、Table is fullというエラーが MySQL クライアントアプリケーションに表示されることがあります。`CREATE TABLE` に `MAX_ROWS` オプションを使用すると、MySQL Cluster のテーブルのために追加のパーティションを作成して、ハッシュインデックスに使用できるメモリーを増やすように `NDB` に強制できます。通常、テーブルに格納することが予期されている行数の 2 倍の数値を `MAX_ROWS` に設定すれば十分です。同様の理由で、データが大量にロードされたノードで、データノードが再起動される問題が発生することもあります。MySQL Cluster NDB 7.1 以降では、`MinFreePct` パラメータが追加され、`DataMemory` および `IndexMemory` の一部 (デフォルトでは 5%) を再起動で使用するために予約することによって、この問題に対処しています。この予約されたメモリーは、`NDB` テーブルまたはデータの格納には使用できません。
A.10.14.	MySQL Cluster は TCP/IP を使用しています。これは、1 つ以上のノードをリモートの場所に配置して、インターネット経由で実行できることを意味しますか。
	そのような状況でクラスタが確実に実行される可能性はほとんどありません。MySQL Cluster は、100M ビット/秒またはギガビット Ethernet (後者が望ましい) を使用した LAN 環境のような専用の高速接続が保証された状況で実行されることを想定して設計および実装されているためです。これより遅い環境で使用したときのパフォーマンスはテストされておらず保証されません。また、MySQL Cluster のノード間の通信はセキュアではないことに注意することも重要です。それらは暗号化されておらず、ほかの保護メカニズムによる保護手段も講じられていません。クラスタのもっともセキュアな構成は、外部からクラスタのデータまたは管理ノードに直接アクセスされない、ファイアウォールの内側のプライベートネットワークです。(SQL ノードの場合は、MySQL サーバーのほかのインスタンスの場合と同様の予防措置を取るようにしてください。)詳細は、セクション18.5.11「MySQL Cluster のセキュリティー上の問題」を参照してください。
A.10.15.	MySQL Cluster を使用するために、新しいプログラミング言語またはクエリー言語を学習する必要がありますか。
	いいえ。クラスタ自体の管理および構成にはいくつかの特殊なコマンドが使用されますが、次の操作には標準の (My)SQL ステートメントのみが必要となります。テーブルの作成、変更、および削除テーブルデータの挿入、更新、および削除プライマリインデックスおよび一意のインデックスの作成、変更、および削除 MySQL Cluster を設定するには、いくつかの特殊な構成パラメータおよびファイルが必要となります。これらの詳細は、セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください。クラスタノードの起動、停止などのタスクのために、いくつかの簡単なコマンドが MySQL Cluster 管理クライアント (ndb_mgm) で使用されます。セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。
A.10.16.	MySQL Cluster によってサポートされるプログラミング言語および API は何ですか。
	MySQL Cluster は、標準の MySQL サーバーと同じプログラミング API および言語 (ODBC、.Net、MySQL C API、および一般的なスクリプト言語 (PHP、Perl、Python など) のための多数のドライバを含む) をサポートしています。これらの API を使用して記述された MySQL Cluster アプリケーションは、ほかの MySQL アプリケーションと同様に動作します。SQL ステートメントを MySQL サーバー (MySQL Cluster の場合は SQL ノード) に送信して、データの行が含まれている応答を受け取ります。これらの API については、第23章「Connector および API」を参照してください。 MySQL Cluster は、NDB API を使用したアプリケーションプログラミングもサポートしています。これは、MySQL サーバーにアクセスする必要のない、MySQL Cluster のデータへの低レベルの C++ インタフェースを提供します。The NDB APIを参照してください。また、多くの `NDBCLUSTER` 管理関数が C 言語の MGM API によって提供されています。詳細は、The MGM APIを参照してください。 MySQL Cluster (NDB 7.1 以降) は、ClusterJ を使用した Java アプリケーションプログラミングもサポートしています。これは、セッションおよびトランザクションを使用して、データのドメインオブジェクトモデルをサポートします。詳細は、Java and NDB Clusterを参照してください。 MySQL Cluster (NDB 7.2 以降) には、`memcached` のサポートが追加され、開発者は `memcached` インタフェースを使用して MySQL Cluster に格納されているデータにアクセスできます。詳細は、ndbmemcache—Memcache API for NDB Clusterを参照してください。 MySQL Cluster NDB 7.3 には、MySQL Cluster をデータストアとして使用する、`Node.js` に対して記述された NoSQL アプリケーションをサポートするアダプタが追加されました。詳細は、MySQL NoSQL Connector for JavaScriptを参照してください。
A.10.17.	MySQL Cluster には管理ツールが含まれていますか。
	MySQL Cluster には、基本的な管理機能を実行するためのコマンド行クライアントが含まれています。セクション18.4.5「ndb_mgm — MySQL Cluster 管理クライアント」およびセクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。 MySQL Cluster NDB 7.0 以降は MySQL Cluster Manager によってもサポートされます。これは別個の製品であり、ローリング再起動、構成の変更などの MySQL Cluster の多くの管理タスクを自動化できる拡張されたコマンド行インタフェースが提供されます。MySQL Cluster Manager については、MySQL™ Cluster Manager 1.3.6 User Manualを参照してください。 MySQL Cluster NDB 7.3 では、MySQL Cluster ソフトウェア配布の一部として、MySQL Cluster を設定および配備するためのブラウザベースのグラフィカルな Auto-Installer が導入されました。詳細は、セクション18.2.1「MySQL Cluster Auto-Installer」を参照してください。
A.10.18.	MySQL Cluster を使用しているときに、エラーメッセージまたは警告メッセージの意味を確認するにはどうすればよいですか。
	これを行うことができる方法は 2 つあります。エラー状態または警告状態を通知された直後に、mysql クライアント内で SHOW ERRORS または SHOW WARNINGS を使用します。システムのシェルプロンプトで、perror --ndb `error_code` を使用します。
A.10.19.	MySQL Cluster はトランザクションセーフですか。どのような分離レベルがサポートされますか。
	はい。`NDB` ストレージエンジンを指定して作成されたテーブルの場合は、トランザクションがサポートされます。現在、MySQL Cluster では `READ COMMITTED` トランザクション分離レベルのみがサポートされます。
A.10.20.	MySQL Cluster によってサポートされるストレージエンジンは何ですか。
	MySQL でのクラスタリングは、`NDB` ストレージエンジンによってのみサポートされます。つまり、MySQL Cluster のノード間でテーブルを共有するには、`ENGINE=NDB` (または同等のオプション `ENGINE=NDBCLUSTER`) を使用してテーブルを作成する必要があります。 MySQL Cluster で使用されている MySQL サーバーに、ほかのストレージエンジン (`InnoDB`、`MyISAM` など) を使用するテーブルを作成することはできますが、それらのテーブルは `NDB` を使用していないため、クラスタリングに参加しません。そのような各テーブルはそれが作成された MySQL サーバーインスタンスに厳密にローカルなテーブルとなります。
A.10.21.	壊滅的な障害が発生した場合 (たとえば、街全体が停電かつUPS の障害が発生した場合)、すべてのデータが失われますか。
	コミットされたすべてのトランザクションはログ記録されます。このため、大災害が起こった場合に一部のデータが失われることはありますが、それはごく限定的なものとなります。データの損失は、トランザクションごとの操作の数を最小限にすることによって、さらに減らすことができます。(どのような場合でも、1 つのトランザクションで多数の操作を実行するのはよい考えではありません。)
A.10.22.	MySQL Cluster では `FULLTEXT` インデックスを使用できますか。
	現在、`FULLTEXT` インデックスは、`InnoDB` ストレージエンジン (MySQL 5.6.4 以降) および `MyISAM` ストレージエンジンのみによってサポートされています。詳細は、セクション12.9「全文検索関数」を参照してください。
A.10.23.	単一のコンピュータ上で複数のノードを実行できますか。
	実行できますが常に推奨できるとは限りません。クラスタを実行する主な理由の 1 つは冗長性を持たせるためです。この冗長性の利点を完全に享受するには、各ノードを別個のマシン上に配置してください。単一のマシンに複数のノードを配置した場合、そのマシンで障害が発生したときに、それらのすべてのノードが失われます。このため、単一のマシンで複数のデータノードを実行する場合は、そのマシンの障害によってノードグループのすべてのデータノードが失われることがないように設定することが非常に重要です。 MySQL Cluster は低コスト (または無料) のオペレーティングシステムがロードされた一般的なハードウェアで実行できるため、追加のマシンを 1 台または 2 台購入する出費は、ミッションクリティカルなデータを保護するためには十分に価値があります。管理ノードを実行するクラスタホストの要件は最低限のものであることにも注意してください。このタスクは、300 MHz の Pentium または同等の CPU、オペレーティングシステムのための十分な RAM、および ndb_mgmd プロセスと ndb_mgm プロセスのための少量のオーバーヘッドに対応した装備があれば実行できます。複数の CPU、コア、またはその両方を持つ単一のホストで、複数のクラスタデータノードを実行することは容認できます。MySQL Cluster NDB 7.0 以降では、そのようなシステムで使用することが意図された、マルチスレッドバージョンのデータノードのバイナリも提供されています。詳細は、セクション18.4.3「ndbmtd — MySQL Cluster データノードデーモン (マルチスレッド)」を参照してください。同じマシン上でデータノードと SQL ノードを同時に実行できる場合もあります。そのような配置での実行状態は、さまざまな要因 (コアおよび CPU の数、データノードおよび SQL ノードのプロセスが使用できるディスクおよびメモリーの容量など) によって異なります。そのような構成を計画する場合は、これらの要因を考慮する必要があります。
A.10.24.	MySQL Cluster を再起動せずにデータノードを追加できますか。
	クラスタをオフラインにせずに、実行されている MySQL Cluster に新しいデータノードを追加できます。詳細は、セクション18.5.13「MySQL Cluster データノードのオンライン追加」を参照してください。ほかのタイプの MySQL Cluster ノードの場合は、ローリング再起動を行えばよいだけです (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。
A.10.25.	MySQL Cluster を使用するときに、注意するべき制限はありますか。
	MySQL Cluster NDB 7.3 以降の `NDB` テーブルの制限には次のものがあります。一時テーブルはサポートされません。`ENGINE=NDB` または `ENGINE=NDBCLUSTER` を使用した `CREATE TEMPORARY TABLE` ステートメントは、エラーが発生して失敗します。 `NDBCLUSTER` テーブルでサポートされるユーザー定義のパーティション化のタイプは、`KEY` および `LINEAR KEY` のみです。ほかのパーティショニングタイプを使用して `NDB` テーブルを作成しようとすると、エラーが発生して失敗します。 `FULLTEXT` インデックスはサポートされません。インデックスのプリフィクスはサポートされません。インデックスを作成できるのは完全なカラムのみです。空間インデックスはサポートされません (空間カラムは使用できます)。セクション11.5「空間データの拡張」を参照してください。部分的なトランザクションおよび部分的なロールバックのサポートは、ほかのトランザクションストレージエンジン (個別のステートメントをロールバックできる `InnoDB` など) と同等です。テーブルごとに許可される属性の最大数は 512 個です。属性名は 31 文字以内である必要があります。各テーブルで、テーブル名とデータベース名を合わせた最大長は 122 文字です。テーブルの行の最大サイズは、`BLOB` 値をカウントせずに 14K バイトです。 `NDB` テーブルごとの行数の制限はありません。テーブルサイズの制限は多くの要因によって異なり、各データノードで使用できる RAM の容量に特に関係しています。 MySQL Cluster の制限の完全なリストについては、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。セクション18.1.6.11「MySQL Cluster NDB 7.3 で解決された以前の MySQL Cluster の問題」も参照してください。
A.10.26.	MySQL Cluster では外部キーはサポートされますか。
	MySQL Cluster NDB 7.3 では、`InnoDB` ストレージエンジンと同等の外部キー制約のサポートが追加されました。詳細は、セクション1.7.3.2「FOREIGN KEY の制約」およびセクション13.1.17.2「外部キー制約の使用」を参照してください。外部キーのサポートが必要なアプリケーションの場合は、MySQL Cluster NDB 7.3 以降を使用してください。
A.10.27.	既存の MySQL データベースを MySQL Cluster にインポートするにはどうすればよいですか。
	ほかのバージョンの MySQL の場合と同様に、データベースを MySQL Cluster にインポートできます。この FAQ の各所で説明されている制限以外の唯一の特別な要件は、クラスタに含まれるテーブルが `NDB` ストレージエンジンを使用する必要があることです。これは、`ENGINE=NDB` または `ENGINE=NDBCLUSTER` を指定してテーブルを作成する必要があることを意味します。ほかのストレージエンジンを使用しているテーブルを、1 つ以上の `ALTER TABLE` ステートメントを使用して、`NDBCLUSTER` に変更することもできます。ただし、変更を行う前に、テーブルの定義が `NDBCLUSTER` ストレージエンジンと互換性がある必要があります。MySQL 5.6 では、追加の回避策も必要となります。詳細は、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。
A.10.28.	MySQL Cluster のノードはどのようにして相互にやり取りしますか。
	クラスタのノードは、3 種類の転送メカニズム (TCP/IP、SHM (共有メモリー)、および SCI (スケーラブルコヒーラントインタフェース)) を使用して通信できます。使用可能な場合、同じクラスタホスト上にあるノード間では SHM がデフォルトで使用されます。ただし、これは実験的とみなされます。SCI は、スケーラブルなマルチプロセッサシステムを構築するために使用される高速 (1 Gbps 以上) で高可用性のプロトコルであり、特殊なハードウェアおよびドライバが必要となります。MySQL Cluster の転送メカニズムとして SCI を使用する方法については、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。
A.10.29.	アービトレータとは何ですか。
	クラスタ内の 1 つ以上のデータノードで障害が発生した場合、相互に「認識」できないクラスタデータノードが発生することがあります。実際に、2 つのセットのデータノードがネットワークのパーティション化で別々に分離されることがあります (「スプリットブレイン」シナリオとも呼ばれます)。各セットのデータノードがクラスタ全体のように動作しようとするため、このタイプの状況は好ましくありません。競合するデータノードのセットのいずれかを選択するために、アービトレータが必要となります。少なくとも 1 つのノードグループのすべてのデータノードが存続して場合、クラスタの単一のサブセットが独自に機能するクラスタを形成できないため、ネットワークのパーティション化は問題とはなりません。本当の問題はすべてのノードが存続している単一のノードグループがない場合に発生し、その場合はネットワークのパーティション化 (「スプリットブレイン」シナリオ) が発生する可能性があります。そしてアービトレータが必要となります。すべてのクラスタノードは、同じノードをアービトレータとして認識しますが、通常、これは管理サーバーです。ただし、クラスタ内の MySQL サーバーのいずれかを代わりにアービトレータとして動作するように構成できます。アービトレータは、クラスタノードの最初のセットがアクセスすることを受け入れ、残りのセットにシャットダウンするように指示します。アービトレータの選択は、MySQL サーバーおよび管理サーバーノードの `ArbitrationRank` 構成パラメータによって制御されます。MySQL Cluster NDB 7.0.7 以降では、`ArbitrationRank` 構成パラメータを使用してアービトレータの選択処理を制御することもできます。これらのパラメータについては、セクション18.3.2.5「MySQL Cluster 管理サーバーの定義」を参照してください。アービトレータの役割によって、指定されたホストに重い要求が課されることはないため、アービトレータのホストはこの目的のために特別に処理が速いマシン、または追加のメモリーがあるマシンである必要はありません。
A.10.30.	MySQL Cluster によってサポートされるデータ型を何ですか。
	MySQL Cluster は MySQL の通常のデータ型 (MySQL の空間拡張に関連付けられている型を含む) をすべてサポートしています。ただし、`NDB` ストレージエンジンは空間インデックスをサポートしていません。(空間インデックスは `MyISAM` によってのみサポートされます。詳細は、セクション11.5「空間データの拡張」を参照してください。)また、`NDB` テーブルとともに使用された場合、インデックスに関していくつかの違いがあります。注記 MySQL Cluster のディスクデータテーブル (つまり、`TABLESPACE ... STORAGE DISK ENGINE=NDB` または `TABLESPACE ... STORAGE DISK ENGINE=NDBCLUSTER` を指定して作成されたテーブル) には固定長の行のみが格納されています。これは、(たとえば) `VARCHAR(255)` カラムが含まれている各ディスクデータテーブルレコードで、実際に格納される文字数に関係なく、255 文字 (テーブルに使用されている文字セットおよび照合順序に必要となります) の領域が必要となることを意味します。これらの問題については、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。
A.10.31.	MySQL Cluster を起動および停止するにはどうすればよいですか。
	クラスタ内の各ノードを次の順序で個別に起動する必要があります。 ndb_mgmd コマンドを使用して、管理ノードを起動します。 `-f` オプションまたは `--config-file` オプションを指定して、構成ファイルのある場所を管理ノードに通知する必要があります。 ndbd コマンドを使用して、各データノードを起動します。データノードが管理サーバーに接続する方法を認識するように、`-c` オプションまたは `--ndb-connectstring` オプションを指定して各データノードを起動する必要があります。任意の起動スクリプト (mysqld_safe など) を使用して各 MySQL サーバー (SQL ノード) を起動します。各 MySQL サーバーは、`--ndbcluster` オプションおよび `--ndb-connectstring` オプションを指定して起動する必要があります。これらのオプションによって、`NDBCLUSTER` ストレージエンジンのサポート、および管理サーバーに接続する方法が mysqld で有効になります。影響を受けるノードがあるマシンのシステムシェルで、これらの各コマンドを実行する必要があります。(そのマシンを物理的にその場で操作する必要はありません。リモートログインシェルをこの目的に使用できます。)クラスタが実行されていることを確認するには、管理ノードが収容されているマシンで `NDB` 管理クライアント ndb_mgm を起動して、`SHOW` コマンドまたは `ALL STATUS` コマンドを発行します。実行されているクラスタをシャットダウンするには、管理クライアントで `SHUTDOWN` コマンドを発行します。または、システムシェルに次のコマンドを入力できます。 `shell> ndb_mgm -e "SHUTDOWN"` (この例の引用符はオプションです。`-e` オプションの後ろのコマンド文字列にスペースがないためです。また、管理クライアントのほかのコマンドと同様に、`SHUTDOWN` コマンドでは大文字/小文字が区別されません。) これらのコマンドのいずれかによって、ndb_mgm、ndb_mgm、および ndbd プロセスが正常に終了します。SQL ノードとして実行されている MySQL サーバーは、mysqladmin shutdown を使用して停止できます。詳細は、セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」およびセクション18.2.7「MySQL Cluster の安全なシャットダウンと再起動」を参照してください。
A.10.32.	MySQL Cluster をシャットダウンすると、MySQL Cluster のデータはどうなりますか。
	クラスタのデータノードによってメモリーに保持されていたデータがディスクに書き込まれ、次回クラスタが起動されたときにメモリーにリロードされます。
A.10.33.	MySQL Cluster に複数の管理ノードを使用することはよい考えですか。
	フェイルセーフとして役に立つことがあります。特定の時点でクラスタを制御しているのは 1 つの管理ノードのみですが、1 つの管理ノードをプライマリとして構成し、プライマリ管理ノードで障害が発生した場合に、1 つ以上の追加の管理ノードが引き継ぐようにすることができます。 MySQL Cluster の管理ノードを構成する方法については、セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください。
A.10.34.	単一の MySQL Cluster に、異なる種類のハードウェアおよびオペレーティングシステムを混在させることはできますか。
	はい。すべてのマシンおよびオペレーティングシステムが同じ「エンディアン」 (すべてがビッグエンディアンまたはすべてがリトルエンディアン) であれば可能です。異なる MySQL Cluster リリースのソフトウェアを各ノードに使用することもできます。ただし、ローリングアップグレードの手順の一部としてのみこれをサポートしています (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。
A.10.35.	単一のホスト上で 2 つのデータノードを実行できますか。2 つの SQL ノードは実行できますか。
	はい。実行できます。複数のデータノードの場合は、各ノードで別のデータディレクトリを使用することをお勧めします (必須ではありません)。単一のマシン上で複数の SQL ノードを実行する場合は、mysqld の各インスタンスで別の TCP/IP ポートを使用する必要があります。ただし、MySQL 5.6 では、1 台のマシンで特定のタイプの複数のクラスタノードを実行することは推奨されず、本番での使用はサポートされません。また、ndbd プロセスおよび mysqld プロセスはメモリーで競合することがあるため、同じホスト上でデータノードおよび SQL ノードを一緒に実行しないことをお勧めします。
A.10.36.	MySQL Cluster ではホスト名を使用できますか。
	はい。クラスタのホストに DNS および DHCP を使用できます。ただし、アプリケーションが「ファイブナイン」可用性を要求する場合は、固定 (数値) IP アドレスを使用してください。クラスタホスト間通信を DNS、DHCP などのサービスに依存させると、潜在的な障害点が増えるためです。
A.10.37.	MySQL Cluster では IPv6 はサポートされますか。
	IPv6 は SQL ノード (MySQL サーバー) 間の接続ではサポートされますが、ほかのすべてのタイプの MySQL Cluster ノード間の接続には IPv4 を使用する必要があります。具体的には、これは、MySQL Cluster 間のレプリケーションには IPv6 を使用できるが、同じ MySQL Cluster 内のノード間の接続には IPv4 を使用する必要があることを意味します。詳細は、セクション18.6.3「MySQL Cluster レプリケーションの既知の問題」を参照してください。
A.10.38.	複数の MySQL サーバーを持つ MySQL Cluster で MySQL ユーザーを管理するにはどうすればよいですか。
	通常、MySQL のユーザーアカウントおよび権限は、同じ MySQL Cluster にアクセスする異なる MySQL サーバー間で自動的に伝播されません。MySQL Cluster NDB 7.2 以降では、MySQL Cluster は権限の配布のサポートを提供しています。権限の配布は自動的に有効になりませんが、MySQL Cluster のドキュメントで説明されている次の手順を使用して有効にできます。詳細は、セクション18.5.14「MySQL Cluster の配布された MySQL 権限」を参照してください。
A.10.39.	SQL ノードの 1 つで障害が発生した場合に、クエリーの送信を続けるにはどうすればよいですか。
	MySQL Cluster は SQL ノード間でどのような種類の自動フェイルオーバーも提供していません。SQL ノードを失ったときの処理、およびそれらの間のフェイルオーバーを行うように、アプリケーションで準備している必要があります。
A.10.40.	MySQL Cluster をバックアップおよびリストアするにはどうすればよいですか。
	MySQL Cluster 管理クライアントおよび ndb_restore プログラムの NDB にネイティブなバックアップおよびリストア機能を使用できます。セクション18.5.3「MySQL Cluster のオンラインバックアップ」およびセクション18.4.20「ndb_restore — MySQL 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 ./ndbd -c 127.0.0.1 --initial me 23097 1.0 2.4 524116 91096 ? Sl 14:14 0:00 ./ndbd -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 と表示されている ndbd プロセスがエンジェルプロセスです。実際には、もちろんそれぞれにごく少量が使用されます。これは、メインの ndbd プロセス (データを実際に処理するプライマリデータノードプロセス) が実行されているかどうかを単純にチェックします。許可されている場合 (たとえば、`StopOnError` 構成パラメータが false に設定されている場合。セクション18.3.3.1「MySQL Cluster データノードの構成パラメータ」を参照してください)、エンジェルプロセスはプライマリデータノードプロセスを再起動しようとします。

A.10 MySQL 5.6 FAQ: MySQL Cluster