次のセクションでは、MySQL Cluster および NDB
ストレージエンジンに関するよくある質問に回答します。
- A.10.1. クラスタがサポートされる MySQL ソフトウェアのバージョンはどれですか。ソースからコンパイルする必要がありますか。
- A.10.2. 「NDB」 および 「NDBCLUSTER」 は何を意味していますか。
- A.10.3. MySQL Cluster を使用した場合と MySQL Replication を使用した場合の違いは何ですか。
- A.10.4. MySQL Cluster を実行するには、特殊なネットワーク環境が必要となりますか。クラスタ内のコンピュータはどのように通信しますか。
- A.10.5. MySQL Cluster を実行するために必要なコンピュータは何台ですか。その理由は何ですか。
- A.10.6. MySQL Cluster 内の各種のコンピュータにはどのような役割がありますか。
- A.10.7. MySQL Cluster の管理クライアントで SHOW コマンドを実行すると、次のような出力行が表示されます。
- A.10.8. MySQL Cluster を使用できるオペレーティングシステムはどれですか。
- A.10.9. MySQL Cluster を実行するためのハードウェア要件は何ですか。
- A.10.10. MySQL Cluster を使用するために必要な RAM のサイズはどれくらいですか。ディスクメモリーを使用することはできますか。
- A.10.11. MySQL Cluster に使用できるファイルシステムは何ですか。ネットワークファイルシステムまたはネットワーク共有は使用できますか。
- A.10.12. MySQL Cluster のノードは、仮想マシン (VMWare、Parallels、Xen によって作成された仮想マシンなど) 内で実行できますか。
- A.10.13. MySQL Cluster データベースにデータを移入しようとしています。ロード処理が予期せずに終了し、次のようなエラーメッセージが表示されます。
- A.10.14. MySQL Cluster は TCP/IP を使用しています。これは、1 つ以上のノードをリモートの場所に配置して、インターネット経由で実行できることを意味しますか。
- A.10.15. MySQL Cluster を使用するために、新しいプログラミング言語またはクエリー言語を学習する必要がありますか。
- A.10.16. MySQL Cluster によってサポートされるプログラミング言語および API は何ですか。
- A.10.17. MySQL Cluster には管理ツールが含まれていますか。
- A.10.18. MySQL Cluster を使用しているときに、エラーメッセージまたは警告メッセージの意味を確認するにはどうすればよいですか。
- A.10.19. MySQL Cluster はトランザクションセーフですか。どのような分離レベルがサポートされますか。
- A.10.20. MySQL Cluster によってサポートされるストレージエンジンは何ですか。
- A.10.21. 壊滅的な障害が発生した場合 (たとえば、街全体が停電かつUPS の障害が発生した場合)、すべてのデータが失われますか。
- A.10.22. MySQL Cluster では FULLTEXT インデックスを使用できますか。
- A.10.23. 単一のコンピュータ上で複数のノードを実行できますか。
- A.10.24. MySQL Cluster を再起動せずにデータノードを追加できますか。
- A.10.25. MySQL Cluster を使用するときに、注意するべき制限はありますか。
- A.10.26. MySQL Cluster では外部キーはサポートされますか。
- A.10.27. 既存の MySQL データベースを MySQL Cluster にインポートするにはどうすればよいですか。
- A.10.28. MySQL Cluster のノードはどのようにして相互にやり取りしますか。
- A.10.29. アービトレータとは何ですか。
- A.10.30. MySQL Cluster によってサポートされるデータ型を何ですか。
- A.10.31. MySQL Cluster を起動および停止するにはどうすればよいですか。
- A.10.32. MySQL Cluster をシャットダウンすると、MySQL Cluster のデータはどうなりますか。
- A.10.33. MySQL Cluster に複数の管理ノードを使用することはよい考えですか。
- A.10.34. 単一の MySQL Cluster に、異なる種類のハードウェアおよびオペレーティングシステムを混在させることはできますか。
- A.10.35. 単一のホスト上で 2 つのデータノードを実行できますか。2 つの SQL ノードは実行できますか。
- A.10.36. MySQL Cluster ではホスト名を使用できますか。
- A.10.37. MySQL Cluster では IPv6 はサポートされますか。
- A.10.38. 複数の MySQL サーバーを持つ MySQL Cluster で MySQL ユーザーを管理するにはどうすればよいですか。
- A.10.39. SQL ノードの 1 つで障害が発生した場合に、クエリーの送信を続けるにはどうすればよいですか。
- A.10.40. MySQL Cluster をバックアップおよびリストアするにはどうすればよいですか。
- A.10.41. 「エンジェルプロセス」とは何ですか。
A.10.1. |
クラスタがサポートされる MySQL ソフトウェアのバージョンはどれですか。ソースからコンパイルする必要がありますか。 |
MySQL Cluster は標準の MySQL Server 5.6 リリースではサポートされません。そうではなく、MySQL Cluster は個別の製品として提供されています。現在、次の MySQL Cluster リリースを本番で使用できます。
使用している MySQL Server で
|
|
A.10.2. |
「NDB」 および 「NDBCLUSTER」 は何を意味していますか。 |
「NDB」 は
「Network
Database」
を意味しています。 |
|
A.10.3. |
MySQL Cluster を使用した場合と MySQL Replication を使用した場合の違いは何ですか。 |
従来の MySQL レプリケーションでは、マスター
MySQL サーバーが 1
つ以上のスレーブを更新します。トランザクションは順次的にコミットされ、遅いトランザクションの場合、スレーブでの処理がマスターより遅れることがあります。これは、マスターで障害が発生した場合に、スレーブで最後のいくつかのトランザクションが記録されないことがあることを意味します。 簡単に言うと、標準の 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 つのタイプのノードがあります。これらを次に示します。
|
|
A.10.7. |
MySQL Cluster の管理クライアントで
|
もっとも簡単な回答は、「ユーザーが制御できるものではなく、MySQL Cluster のソースコードを記述または分析するソフトウェアエンジニアではないかぎり、どのような場合でも憂慮する必要はないものです」となります。 この回答に満足できない場合、より長くテクニカルなバージョンは次のとおりです。 MySQL Cluster の多数のメカニズムでは、データノードの分散調整が必要となります。これらの分散アルゴリズムおよびプロトコルには、グローバルチェックポイント、DDL (スキーマ) の変更、およびノードの再起動処理が含まれます。この調整を単純にするために、それらのメンバーのいずれかがリーダーとして動作するようにデータノードで「選出」されます。(このノードは「マスター」と呼ばれていましたが、MySQL Replication のマスターサーバーと混乱しないように、この用語は削除されました。)この選択は完全に自動的であり、それに影響するメカニズムをユーザーが目にすることはありません。自動的であることが、MySQL Cluster の内部アーキテクチャーの重要な部分です。 ノードがこれらのメカニズムの「リーダー」として動作する場合、通常、それがアクティビティーの調整の中心となり、「フォロワー」として動作するほかのノードは、リーダーによって指示されたアクティビティーの各自の担当分を実行します。リーダーとして動作するノードで障害が発生すると、残りのノードによって新しいリーダーが選出されます。古いリーダーによって調整されていた進行中のタスクは、実際に関係するメカニズムに従って、失敗するか、新しいリーダーによって続行されます。
これらの各種のメカニズムおよびプロトコルの一部で別のリーダーノードが使用されることがありますが、一般的には、それらのすべてで同じリーダーが選択されます。管理クライアントの
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 は |
|
A.10.10. |
MySQL Cluster を使用するために必要な RAM のサイズはどれくらいですか。ディスクメモリーを使用することはできますか。 |
以前は、MySQL Cluster はインメモリーのみを使用していました。MySQL 5.1 以降では、MySQL Cluster をディスクに格納する機能も提供されています。(この機能を以前のリリースにバックポートする計画はありません。)詳細は、セクション18.5.12「MySQL Cluster ディスクデータテーブル」を参照してください。
インメモリーの
メモリー要件をより正確に計算するには、クラスタデータベースの各テーブルで行ごとに必要となる格納領域 (詳細は、セクション11.7「データ型のストレージ要件」を参照してください) を判別して、それを行数で乗算する必要があります。カラムインデックスについては、次のことを考慮する必要もあります。
すべての主キーおよび一意のインデックスに
クラスタのメモリー要件を計算するときに、最新の
MySQL 5.6 リリースに付属している
ndb_size.pl
ユーティリティーが役に立つことがあります。この
Perl スクリプトは、現在の (クラスタではない)
MySQL
データベースに接続して、
すべての MySQL Cluster
テーブルには主キーがある必要があることに留意することが非常に重要です。
ある時点で MySQL Cluster
のデータおよびインデックスの格納に使用されているメモリー量を判別するには、ndb_mgm
クライアントで |
|
A.10.11. |
MySQL Cluster に使用できるファイルシステムは何ですか。ネットワークファイルシステムまたはネットワーク共有は使用できますか。 |
通常、ホストのオペレーティングシステムにネイティブなファイルシステムは、MySQL Cluster で動作します。特定のファイルシステムが MySQL Cluster と特に良好に動作する (またはそれほどよくない) ことがわかった場合は、その知見をMySQL Cluster フォーラムで共有してください。
Windows の場合は、通常の 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 データベースにデータを移入しようとしています。ロード処理が予期せずに終了し、次のようなエラーメッセージが表示されます。
これが発生するのはなぜですか。 |
原因はすべてのテーブルデータおよびすべてのインデックス
(テーブル定義に主キーの定義が含まれていない場合に自動的に作成される、 すべてのデータノードで同じ容量の RAM が使用されることにも注意してください。クラスタ内のデータノードは、データノードの中で使用可能なメモリーの容量がもっとも少ないノードより多いメモリーを使用することはできないためです。たとえば、クラスタのデータノードをホストしているコンピュータが 4 台あり、そのうちの 3 台がクラスタのデータの格納に 3G バイトの RAM を使用でき、残りのデータノードが 1G バイトの RAM のみを使用できる場合、各データノードは最大 1G バイトを MySQL Cluster のデータおよびインデックスに使用できます。
場合によっては、ndb_mgm -e "ALL REPORT
MEMORYUSAGE" で
同様の理由で、データが大量にロードされたノードで、データノードが再起動される問題が発生することもあります。MySQL
Cluster NDB 7.1
以降では、 |
|
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を参照してください。また、多くの
MySQL Cluster (NDB 7.1 以降) は、ClusterJ を使用した Java アプリケーションプログラミングもサポートしています。これは、セッションおよびトランザクションを使用して、データのドメインオブジェクトモデルをサポートします。詳細は、Java and NDB Clusterを参照してください。
MySQL Cluster (NDB 7.2 以降)
には、
MySQL Cluster NDB 7.3 には、MySQL Cluster
をデータストアとして使用する、 |
|
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 つあります。
|
|
A.10.19. |
MySQL Cluster はトランザクションセーフですか。どのような分離レベルがサポートされますか。 |
はい。 |
|
A.10.20. |
MySQL Cluster によってサポートされるストレージエンジンは何ですか。 |
MySQL
でのクラスタリングは、
MySQL Cluster で使用されている MySQL
サーバーに、ほかのストレージエンジン
( |
|
A.10.21. |
壊滅的な障害が発生した場合 (たとえば、街全体が停電かつUPS の障害が発生した場合)、すべてのデータが失われますか。 |
コミットされたすべてのトランザクションはログ記録されます。このため、大災害が起こった場合に一部のデータが失われることはありますが、それはごく限定的なものとなります。データの損失は、トランザクションごとの操作の数を最小限にすることによって、さらに減らすことができます。(どのような場合でも、1 つのトランザクションで多数の操作を実行するのはよい考えではありません。) |
|
A.10.22. |
MySQL Cluster では |
現在、 |
|
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 以降の
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
では、 |
|
A.10.27. |
既存の MySQL データベースを MySQL Cluster にインポートするにはどうすればよいですか。 |
ほかのバージョンの MySQL
の場合と同様に、データベースを MySQL Cluster
にインポートできます。この FAQ
の各所で説明されている制限以外の唯一の特別な要件は、クラスタに含まれるテーブルが
ほかのストレージエンジンを使用しているテーブルを、1
つ以上の |
|
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
サーバーおよび管理サーバーノードの
アービトレータの役割によって、指定されたホストに重い要求が課されることはないため、アービトレータのホストはこの目的のために特別に処理が速いマシン、または追加のメモリーがあるマシンである必要はありません。 |
|
A.10.30. |
MySQL Cluster によってサポートされるデータ型を何ですか。 |
MySQL Cluster は MySQL の通常のデータ型 (MySQL
の空間拡張に関連付けられている型を含む)
をすべてサポートしています。ただし、 注記
MySQL Cluster のディスクデータテーブル
(つまり、 これらの問題については、セクション18.1.6「MySQL Cluster の既知の制限」を参照してください。 |
|
A.10.31. |
MySQL Cluster を起動および停止するにはどうすればよいですか。 |
クラスタ内の各ノードを次の順序で個別に起動する必要があります。
影響を受けるノードがあるマシンのシステムシェルで、これらの各コマンドを実行する必要があります。(そのマシンを物理的にその場で操作する必要はありません。リモートログインシェルをこの目的に使用できます。)クラスタが実行されていることを確認するには、管理ノードが収容されているマシンで
実行されているクラスタをシャットダウンするには、管理クライアントで
(この例の引用符はオプションです。 これらのコマンドのいずれかによって、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 を省略しました)。
メモリーおよび CPU の使用量が 0
と表示されている ndbd
プロセスがエンジェルプロセスです。実際には、もちろんそれぞれにごく少量が使用されます。これは、メインの
ndbd プロセス
(データを実際に処理するプライマリデータノードプロセス)
が実行されているかどうかを単純にチェックします。許可されている場合
(たとえば、 |