23.1.1 NDB Cluster のコア概念

NDBCLUSTER (NDB とも呼ばれる) は、高可用性とデータ永続性の機能を備えたインメモリーストレージエンジンです。

NDBCLUSTER ストレージエンジンはさまざまなフェイルオーバーとロードバランシングのオプションを使って構成できますが、クラスタレベルのストレージエンジンから始めるのがもっとも簡単です。 NDB Cluster NDB ストレージエンジンには、クラスタ自体内のほかのデータにのみ依存する完全なデータセットが含まれています。

NDB Cluster の「「クラスタ」」部分は、MySQL サーバーから独立して構成されます。 NDB Cluster では、クラスタの各部分はノードとみなされます。

注記

多くのコンテキストでは、「「ノード」」という用語はコンピュータを示すために使用されますが、NDB Cluster について説明するときはプロセスを意味します。 1 台のコンピュータで複数のノードを実行できます。1 つ以上のクラスタノードを実行しているコンピュータに対しては、クラスタホストという用語を使用します。

クラスタノードには 3 つのタイプがあり、NDB Cluster の最小構成では、少なくとも 3 つのノードがあり、これらの各タイプのいずれかです:

管理ノード: このタイプのノードの役割は、NDB Cluster 内のほかのノードを管理し、構成データの提供、ノードの起動と停止、バックアップの実行などの機能を実行することです。このノードタイプはほかのノードの構成を管理するため、このタイプのノードは最初に (ほかのノードより先に) 起動するようにしてください。管理ノードは、コマンド ndb_mgmd を使用して起動されます。
データノード: このタイプのノードにはクラスタのデータが格納されます。フラグメントレプリカの数にフラグメントの数を掛けた数と同じ数のデータノードがあります (セクション23.1.2「NDB Cluster ノード、ノードグループ、フラグメントレプリカ、およびパーティション」を参照)。たとえば、2 つのフラグメントレプリカがあり、それぞれに 2 つのフラグメントがある場合、4 つのデータノードが必要です。 1 つのフラグメントレプリカではデータストレージに十分ですが、冗長性は提供されません。したがって、冗長性と高可用性を実現するために、2 つ以上のフラグメントレプリカを使用することをお薦めします。データノードは、ndbd (セクション23.4.1「ndbd — NDB Cluster データノードデーモン」を参照してください) または ndbmtd (セクション23.4.3「ndbmtd — NDB Cluster データノードデーモン (マルチスレッド)」を参照してください) コマンドで起動します。
「NDB Cluster」テーブルは通常、ディスクではなくメモリーに完全に格納されます (このため、「NDB Cluster」を in-memory データベースと呼びます)。ただし、一部の NDB Cluster データはディスクに格納できます。詳細は、セクション23.5.10「NDB Cluster ディスクデータテーブル」を参照してください。
SQL ノード: これは、クラスタデータにアクセスするノードです。 NDB Cluster の場合、SQL ノードは NDBCLUSTER ストレージエンジンを使用する従来の MySQL サーバーです。 SQL ノードは、--ndbcluster および --ndb-connectstring オプション (これらについては、この章の別の場所で説明します) を指定して起動される mysqld プロセスです。場合によっては、追加の MySQL Server オプションも指定できます。
SQL ノードは、NDB Cluster データにアクセスするすべてのアプリケーションを指定する特殊なタイプのAPI ノードです。 API ノードのもう 1 つの例は、クラスタのバックアップをリストアするために使われる ndb_restore ユーティリティーです。 NDB API を使用してこのようなアプリケーションを作成できます。 NDB API の基本情報については、Getting Started with the NDB APIを参照してください。

重要

本番環境で 3 ノードセットアップの採用を期待するのは現実的ではありません。このような構成では冗長性は提供されません。NDB Cluster の高可用性機能を利用するには、複数のデータおよび SQL ノードを使用する必要があります。複数の管理ノードを使用することも、強くお勧めします。

NDB Cluster 内のノード、ノードグループ、フラグメントレプリカ、およびパーティション間の関係の簡単な概要については、セクション23.1.2「NDB Cluster ノード、ノードグループ、フラグメントレプリカ、およびパーティション」を参照してください。

クラスタの構成には、クラスタ内の各ノードの構成と、ノード間の個々の通信リンクの設定が含まれます。 NDB Cluster は現在、データノードがプロセッサの電力、メモリー領域、および帯域幅に関して同種であることを意図して設計されています。さらに、一元管理の構成を提供するため、クラスタのすべての構成データが全体として 1 つの構成ファイルに格納されます。

管理サーバーは、クラスタ構成ファイルとクラスタログを管理します。クラスタ内の各ノードは、管理サーバーから構成データを取得するため、管理サーバーがどこにあるかを特定する手段を必要とします。データノードで注目に値するイベントが発生すると、そのノードはこれらのイベントに関する情報を管理サーバーに転送し、管理サーバーはその情報をクラスタログに書き込みます。

さらに、任意の数のクラスタクライアントプロセスまたはアプリケーションが存在する可能性があります。これらには、標準の MySQL クライアント、NDB 専用の API プログラム、管理クライアントなどが含まれます。次のいくつかの段落で、これらについて説明します。

標準の MySQL クライアント. NDB Cluster は、PHP、Perl、C、C++、Java、Python、Ruby などで記述された既存の MySQL アプリケーションで使用できます。このようなクライアントアプリケーションは、NDB Cluster SQL ノードとして機能する MySQL サーバーとの間で、スタンドアロン MySQL サーバーとの対話とほぼ同じ方法で SQL ステートメントを送受信します。

NDB Cluster をデータソースとして使用する MySQL クライアントは、複数の MySQL サーバーに接続して負荷分散とフェイルオーバーを実現する機能を利用するように変更できます。たとえば、Connector/J 5.0.6 以降を使用する Java クライアントは、jdbc:mysql:loadbalance:// URL (Connector/J 5.1.7 で改善された) を使用して、負荷分散を透過的に実現できます。NDB Cluster で Connector/J を使用する方法の詳細は、Using Connector/J with NDB Cluster を参照してください。

NDB クライアントプログラム. 高レベルの C++ API である NDB API を使用して、クラスタに接続されている MySQL Servers をバイパスして、NDBCLUSTER ストレージエンジンから NDB Cluster データに直接アクセスするクライアントプログラムを作成できます。このようなアプリケーションは、データへの SQL インタフェースを必要としない特殊な目的に役立ちます。詳細は、The NDB APIを参照してください。

NDB 固有の Java アプリケーションは、NDB Cluster Connector for Java を使用して NDB Cluster 用に記述することもできます。この NDB Cluster コネクタには、NDBCLUSTER に直接接続する Hibernate や JPA などのオブジェクトリレーショナルマッピング永続性フレームワークに似た高レベルのデータベース API である ClusterJ が含まれているため、MySQL Server にアクセスする必要はありません。詳細は、Java and NDB ClusterおよびThe ClusterJ API and Data Object Modelを参照してください。

NDB Cluster は、Node.js を使用して JavaScript で記述されたアプリケーションもサポートします。 JavaScript 用の MySQL Connector には、MySQL Server だけでなく、NDB ストレージエンジンに直接アクセスするためのアダプタも含まれています。この Connector を使用するアプリケーションは、通常イベント駆動型であり、ClusterJ に採用されているものと多くの点で似ているドメインオブジェクトモデルを使用します。詳細は、MySQL NoSQL Connector for JavaScriptを参照してください。

管理クライアント. これらのクライアントは、管理サーバーに接続して、ノードの正常な起動と停止、メッセージトレースの開始と停止 (デバッグバージョンのみ)、ノードのバージョンとステータスの表示、バックアップの開始と停止などのコマンドを提供します。このタイプのプログラムの例としては、NDB Cluster に付属する ndb_mgm 管理クライアントがあります (セクション23.4.5「ndb_mgm — NDB Cluster 管理クライアント」を参照)。このようなアプリケーションは、NDB Cluster 管理サーバーと直接通信する C 言語 API である MGM API を使用して記述できます。詳細は、The MGM APIを参照してください。

Oracle は、多数のノードで NDB Cluster を再起動するなど、多くの複雑な NDB Cluster 管理タスクを簡略化する高度なコマンド行インタフェースを提供する MySQL Cluster Manager も使用可能にします。 MySQL Cluster Manager クライアントは、ほとんどのノード構成パラメータの値、NDB Cluster に関連する mysqld サーバーオプションおよび変数を取得および設定するためのコマンドもサポートしています。MySQL Cluster Manager 1.4.8 は NDB 8.0 の実験的なサポートを提供します。詳しくはMySQL Cluster Manager 1.4.8 User Manual,をご覧ください。

イベントログ. NDB Cluster は、イベントをカテゴリ (起動、シャットダウン、エラー、チェックポイントなど)、優先順位、および重大度別にログに記録します。すべてのレポート可能イベントの完全なリストについては、セクション23.5.3「NDB Cluster で生成されるイベントレポート」を参照してください。イベントログには、ここに示す 2 つのタイプがあります。

クラスタログ: クラスタに関する必要なすべてのレポート可能イベントが全体として保持されます。
ノードログ: 個々のノードごとに保持される個別のログです。

注記

通常の状況では、クラスタログのみを保持して調べるだけで必要十分です。ノードログを調べる必要があるのは、アプリケーション開発やデバッグの場合だけです。

Checkpoint. 一般的には、データをディスクに保存したときにチェックポイントに達したといいます。 NDB Cluster に固有のチェックポイントは、コミットされたすべてのトランザクションがディスクに格納される時点です。 NDB ストレージエンジンには、クラスタデータの一貫したビューが維持されるように連携する 2 つのタイプのチェックポイントがあります。次のリストにそれらを示します。

ローカルチェックポイント (LCP): これは、1 つのノードに固有のチェックポイントです。ただし、LCP はクラスタ内のすべてのノードである程度同時に発生します。 LCP は通常、数分ごとに発生します。正確な間隔は、ノードに格納されるデータ量、クラスタアクティビティのレベルおよびその他の要因によって異なります。
NDB 8.0 は部分 LCP をサポートしており、状況によってはパフォーマンスを大幅に向上させることができます。部分 LCP を有効にし、それらが使用する記憶域の量を制御する EnablePartialLcp および RecoveryWork の構成パラメータの説明を参照してください。
グローバルチェックポイント (GCP): GCP は、すべてのノードのトランザクションが同期し、Redo ログがディスクにフラッシュされたときに、数秒間隔で発生します。

ローカルチェックポイントとグローバルチェックポイントによって作成されるファイルおよびディレクトリの詳細は、NDB Cluster Data Node File System Directoryを参照してください。