第 18 章 MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4

目次

18.1 MySQL Cluster の概要
18.1.1 MySQL Cluster の主な概念
18.1.2 MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション
18.1.3 MySQL Cluster のハードウェア、ソフトウェア、およびネットワーク要件
18.1.4 MySQL Cluster の開発履歴
18.1.5 InnoDB を使用した MySQL Server と MySQL Cluster の比較
18.1.6 MySQL Cluster の既知の制限
18.2 MySQL Cluster のインストール
18.2.1 MySQL Cluster Auto-Installer
18.2.2 Linux での MySQL Cluster のインストール
18.2.3 Windows での MySQL Cluster のインストール
18.2.4 MySQL Cluster の初期構成
18.2.5 MySQL Cluster の初期起動
18.2.6 テーブルとデータを含む MySQL Cluster の例
18.2.7 MySQL Cluster の安全なシャットダウンと再起動
18.2.8 MySQL Cluster NDB 7.3 のアップグレードとダウングレード
18.3 MySQL Cluster の構成
18.3.1 MySQL Cluster の簡易テストセットアップ
18.3.2 MySQL Cluster の構成ファイル
18.3.3 MySQL Cluster 構成パラメータの概要
18.3.4 MySQL Cluster 用の MySQL Server オプションおよび変数
18.3.5 MySQL Cluster での高速インターコネクトの使用
18.4 MySQL Cluster プログラム
18.4.1 ndbd — MySQL Cluster データノードデーモン
18.4.2 ndbinfo_select_all — ndbinfo テーブルからの選択
18.4.3 ndbmtd — MySQL Cluster データノードデーモン (マルチスレッド)
18.4.4 ndb_mgmd — MySQL Cluster 管理サーバーデーモン
18.4.5 ndb_mgm — MySQL Cluster 管理クライアント
18.4.6 ndb_blob_tool — MySQL Cluster テーブルの BLOB および TEXT カラムのチェックおよび修復
18.4.7 ndb_config — MySQL Cluster 構成情報の抽出
18.4.8 ndb_cpcd — NDB 開発のためのテストの自動化
18.4.9 ndb_delete_all — NDB テーブルからのすべての行の削除
18.4.10 ndb_desc — NDB テーブルの表示
18.4.11 ndb_drop_index — NDB テーブルからのインデックスの削除
18.4.12 ndb_drop_table — NDB テーブルの削除
18.4.13 ndb_error_reporter — NDB エラーレポートユーティリティー
18.4.14 ndb_index_stat — NDB インデックス統計ユーティリティー
18.4.15 ndb_print_backup_file — NDB バックアップファイルの内容の出力
18.4.16 ndb_print_file — NDB ディスクデータファイル内容の出力
18.4.17 ndb_print_schema_file — NDB スキーマファイル内容の出力
18.4.18 ndb_print_sys_file — NDB システムファイル内容の出力
18.4.19 ndbd_redo_log_reader — クラスタ Redo ログ内容のチェックおよび出力
18.4.20 ndb_restore — MySQL Cluster バックアップのリストア
18.4.21 ndb_select_all — NDB テーブルの行の出力
18.4.22 ndb_select_count — NDB テーブルの行数の出力
18.4.23 ndb_setup.py — MySQL Cluster のブラウザベース自動インストーラの開始
18.4.24 ndb_show_tables — NDB テーブルのリストの表示
18.4.25 ndb_size.pl — NDBCLUSTER サイズ要件エスティメータ
18.4.26 ndb_waiter — MySQL Cluster が指定したステータスになるまで待機する
18.4.27 MySQL Cluster プログラムに共通するオプション — MySQL Cluster プログラムに共通するオプション
18.5 MySQL Cluster の管理
18.5.1 MySQL Cluster の起動フェーズのサマリー
18.5.2 MySQL Cluster 管理クライアントのコマンド
18.5.3 MySQL Cluster のオンラインバックアップ
18.5.4 MySQL Cluster での MySQL サーバーの使用法
18.5.5 MySQL Cluster のローリング再起動の実行
18.5.6 MySQL Cluster で生成されたイベントレポート
18.5.7 MySQL Cluster ログメッセージ
18.5.8 MySQL Cluster のシングルユーザーモード
18.5.9 クイックリファレンス: MySQL Cluster の SQL ステートメント
18.5.10 ndbinfo MySQL Cluster 情報データベース
18.5.11 MySQL Cluster のセキュリティー上の問題
18.5.12 MySQL Cluster ディスクデータテーブル
18.5.13 MySQL Cluster データノードのオンライン追加
18.5.14 MySQL Cluster の配布された MySQL 権限
18.5.15 NDB API 統計のカウンタと変数
18.6 MySQL Cluster レプリケーション
18.6.1 MySQL Cluster レプリケーション: 略語と記号
18.6.2 MySQL Cluster レプリケーションの一般要件
18.6.3 MySQL Cluster レプリケーションの既知の問題
18.6.4 MySQL Cluster レプリケーションスキーマとテーブル
18.6.5 レプリケーションのための MySQL Cluster の準備
18.6.6 MySQL Cluster レプリケーションの起動 (レプリケーションチャネルが 1 つ)
18.6.7 2 つのレプリケーションチャネルを使用する MySQL Cluster レプリケーション
18.6.8 MySQL Cluster レプリケーションを使用したフェイルオーバーの実装
18.6.9 MySQL Cluster レプリケーションを使用した MySQL Cluster バックアップ
18.6.10 MySQL Cluster レプリケーション: マルチマスターと循環レプリケーション
18.6.11 MySQL Cluster レプリケーションの競合解決
18.7 MySQL Cluster リリースノート

この章には、分散コンピューティング環境に適した MySQL の高可用性および高冗長性バージョンである MySQL Cluster に関する情報が含まれています。MySQL Cluster の最近のバージョンでは、NDB ストレージエンジン (NDBCLUSTER) のバージョン 7 を使用して、MySQL Server およびその他のソフトウェアを含む複数のコンピュータをクラスタ内で動作させることができます。本番環境で使用可能な最新リリースである MySQL Cluster NDB 7.3 には、NDB バージョン 7.3 が組み込まれています。この章には、NDB ストレージエンジンのバージョン 7.4 を使用し、開発者マイルストーンリリースで入手可能になった MySQL Cluster NDB 7.4 に関する情報も含まれています。

NDB ストレージエンジンのサポートは、オラクルによってビルドされた標準の MySQL Server 5.6 バイナリには含まれていません。代わりに、オラクルから提供される MySQL Cluster バイナリのユーザーは、サポートされるプラットフォームに対応する MySQL Cluster の最新のバイナリリリースにアップグレードするようにしてください。これらには、ほとんどの Linux 配布で機能するはずの RPM が含まれています。ソースからビルドする MySQL Cluster ユーザーは、MySQL Cluster 用に提供されるソースを使用するようにしてください。(ソースを入手できる場所については、このセクションで後述します。)

この章には、MySQL Cluster NDB 7.3 リリース (5.6.22-ndb-7.3.9 まで) および MySQL Cluster NDB 7.4 リリース (5.6.22-ndb-7.4.4 まで) に関する情報が含まれています。現在、MySQL Cluster NDB 7.3 リリースシリーズは一般提供 (GA) されており、MySQL Cluster 7.4 は開発者プレビューが入手可能です。MySQL Cluster NDB 7.2、MySQL Cluster NDB 7.1、および MySQL Cluster NDB 7.0 は以前の GA リリースです。これらは引き続きサポートされますが、新規の配備には MySQL Cluster NDB 7.3 を使用することをお勧めします。

サポートされるプラットフォーム  MySQL Cluster は現在数多くのプラットフォームで利用可能であり、サポートされています。オペレーティングシステムバージョン、オペレーティングシステム配布、およびハードウェアプラットフォームの特定の組み合わせで利用可能な正確なサポートレベルについては、https://www.mysql.com/support/supportedplatforms/cluster.html を参照してください。

可用性  サポートされるプラットフォーム用の MySQL Cluster のバイナリおよびソースパッケージは、https://dev.mysql.com/downloads/cluster/ から入手できます。

MySQL Cluster のリリース番号  MySQL Cluster は、メインラインの MySQL Server 5.6 のリリースシリーズとはやや異なるリリースパターンに従っています。このマニュアルおよび MySQL のその他のドキュメントでは、NDB で始まるバージョン番号を使用して、これらおよびそれ以降の MySQL Cluster リリースを識別します。このバージョン番号は、そのリリースで使用されている NDBCLUSTER ストレージエンジンのバージョン番号であり、その MySQL Cluster リリースのベースになっている MySQL Server バージョンのバージョン番号ではありません。

MySQL Cluster ソフトウェアで使用されるバージョン文字列  MySQL Cluster のプログラムに表示されるバージョン文字列には、この書式が使用されます。

mysql-mysql_server_version-ndb-ndb_engine_version

mysql_server_version は、その MySQL Cluster リリースのベースになっている MySQL Server のバージョンを表します。すべての MySQL Cluster NDB 7.3 リリースおよび現在の MySQL Cluster NDB 7.4 リリースでは、これは 5.6 です。ndb_engine_version は、このリリースの MySQL Cluster ソフトウェアで使用されている NDB ストレージエンジンのバージョンです。次に示すように、mysql クライアントでこの書式が使用されていることがわかります。

shell> mysqlWelcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.6.22-ndb-7.4.4 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> SELECT VERSION()\G*************************** 1. row ***************************
VERSION(): 5.6.22-ndb-7.4.4
1 row in set (0.00 sec)

このバージョン文字列は、ndb_mgm クライアントの SHOW コマンドの出力にも表示されます。

ndb_mgm> SHOWConnected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=1 @10.0.10.6 (5.6.22-ndb-7.4.4, Nodegroup: 0, *)
id=2 @10.0.10.8 (5.6.22-ndb-7.4.4, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=3 @10.0.10.2 (5.6.22-ndb-7.4.4)
[mysqld(API)] 2 node(s)
id=4 @10.0.10.10 (5.6.22-ndb-7.4.4)
id=5 (not connected, accepting connect from any host)

このバージョン文字列によって、その MySQL Cluster リリースの分岐元であるメインラインの MySQL のバージョンと、使用されている NDB ストレージエンジンのバージョンを特定できます。たとえば、MySQL Cluster NDB 7.3.2 (MySQL Server 5.6 をベースとする最初の MySQL Cluster 本番リリース) の完全なバージョン文字列は mysql-5.6.11-ndb-7.3.2 です。これによって、次のことを特定できます。

新しい MySQL Cluster リリースは、NDB ストレージエンジンの更新に従って番号付けされ、メインラインの MySQL Server リリースとは必ずしも 1 対 1 で対応しません。たとえば、MySQL Cluster NDB 7.3.2 は (前述のように) MySQL 5.6.11 をベースとしていますが、MySQL Cluster NDB 7.3.1 は MySQL 5.6.10 をベースとしていました (バージョン文字列: mysql-5.6.10-ndb-7.3.1)。

標準の MySQL 5.6 リリースとの互換性  標準の MySQL スキーマおよびアプリケーションの多くが MySQL Cluster を使用しても機能しますが、MySQL Cluster を使用して未変更のアプリケーションやデータベーススキーマを実行すると、互換性がやや低下したり、パフォーマンスが最適でなくなったりする可能性があることも事実です (セクション18.1.6「MySQL Cluster の既知の制限」を参照してください)。これらの問題のほとんどは克服できますが、これは、スキーマ、クエリー、およびアプリケーションに変更を加える可能性を考慮せずに、既存の (たとえば、MyISAMInnoDB を使用する) アプリケーションデータストアを NDB ストレージエンジンを使用するものに切り替えることがほとんど不可能であることも意味します。さらに、MySQL Server と MySQL Cluster のコードベースは大幅に異なるため、標準の mysqld を MySQL Cluster に付属するバージョンの mysqld と簡単に取り替えて使用することはできません。

MySQL Cluster の開発ソースツリー  MySQL Cluster の開発ツリーには、https://code.launchpad.net/~mysql/ からもアクセスできます。

https://code.launchpad.net/~mysql/ で管理されている MySQL Cluster の開発ソースは、GPL でライセンス付与されています。Bazaar を使った MySQL ソースの取得およびユーザー自身によるソースのビルドについては、セクション2.9.3「開発ソースツリーを使用して MySQL をインストールする」を参照してください。

注記

MySQL Server 5.6 と同じように、MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4 リリースは CMake を使用してビルドされています。

現在、MySQL Cluster NDB 7.2 および MySQL Cluster NDB 7.3 リリースは一般提供 (GA) されています。新規の配備には MySQL Cluster NDB 7.3 を使用することをお勧めします。MySQL Cluster NDB 7.1 は以前の GA リリースで、現在も保守中です。MySQL Cluster NDB 7.0 以前のバージョンは、アクティブな開発が終了しました。MySQL Cluster NDB 7.3 に追加された主な機能の概要については、セクション18.1.4「MySQL Cluster の開発履歴」を参照してください。

この章はまだ完成されたものではなく、その内容は MySQL Cluster の継続的な進化に応じて改訂されます。MySQL Cluster に関する追加情報については、http://www.mysql.com/products/cluster/ の MySQL Web サイトを参照してください。

追加のリソース  MySQL Cluster の詳細は、次の場所を参照してください。

18.1 MySQL Cluster の概要

MySQL Cluster はシェアードナッシングシステムでのインメモリーデータベースのクラスタリングを可能にするテクノロジです。シェアードナッシングアーキテクチャーでは、非常に安価なハードウェアでシステムが動作し、ハードウェアやソフトウェアの要件が最小限に抑えられます。

MySQL Cluster は、単一障害点が発生しないように設計されています。シェアードナッシングシステムでは、各コンポーネントに固有のメモリーとディスクが用意され、ネットワーク共有、ネットワークファイルシステム、SAN などの共有ストレージメカニズムの使用は推奨またはサポートされません。

MySQL Cluster は、標準の MySQL Server と NDB (Network DataBase を表します) と呼ばれるインメモリーのクラスタ化されたストレージエンジンを統合したものです。このドキュメントでは、NDB はセットアップのストレージエンジン固有の部分を表し、MySQL Cluster は 1 つ以上の MySQL Server と NDB ストレージエンジンの組み合わせを表します。

MySQL Cluster は、それぞれが 1 つ以上のプロセスを実行するホストと呼ばれる一連のコンピュータで構成されます。ノードと呼ばれるこれらのプロセスには、MySQL Server (NDB データへのアクセス用)、データノード (データのストレージ用)、1 つ以上の管理サーバー、および場合によってはその他の特殊なデータアクセスプログラムが含まれます。MySQL Cluster 内のこれらのコンポーネントの関係をここに示します。

MySQL Cluster のコンポーネント

これらすべてのプログラムが一体となって MySQL Cluster を形成します (セクション18.4「MySQL Cluster プログラム」を参照してください)。NDB ストレージエンジンによってデータが格納されると、データノードにテーブル (およびテーブルデータ) が格納されます。このようなテーブルには、クラスタ内のほかのすべての MySQL Server (SQL ノード) から直接アクセスできます。したがって、クラスタにデータを格納する給料計算アプリケーションでは、あるアプリケーションが社員の給料を更新すると、このデータをクエリーするほかのすべての MySQL サーバーがこの変更をただちに認識できます。

MySQL Cluster の SQL ノードでは mysqld サーバーデーモンが使用されますが、これは MySQL 5.6 配布に付属する mysqld バイナリとはいくつかの重要な点で異なっており、これら 2 つのバージョンの mysqld を交換することはできません。

さらに、MySQL Cluster に接続されていない MySQL Server は、NDB ストレージエンジンを使用できず、MySQL Cluster のデータにアクセスできません。

MySQL Cluster のデータノードに格納されたデータはミラー化できます。クラスタは、少数のトランザクションがトランザクション状態の消失によって中止されること以外の影響を受けずに、個々のデータノードの障害を処理できます。トランザクションの失敗はトランザクションアプリケーションが処理すると想定されるため、これが問題の原因になることはないはずです。

個々のノードは、停止して再起動したあと、システム (クラスタ) に再度参加できます。構成の変更やソフトウェアのアップグレードを行うときは、ローリング再起動 (すべてのノードが順に再起動される) が使用されます (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。ローリング再起動は、新しいデータノードをオンラインで追加するプロセスの一部としても使用されます (セクション18.5.13「MySQL Cluster データノードのオンライン追加」を参照してください)。データノードの詳細、MySQL Cluster でのデータノードの構成方法、およびデータノードによる MySQL Cluster データの処理方法と格納方法については、セクション18.1.2「MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション」を参照してください。

MySQL Cluster データベースのバックアップとリストアは、MySQL Cluster 管理クライアントにある NDB 固有の機能、および MySQL Cluster 配布に含まれる ndb_restore プログラムを使用して行うことができます。詳細は、セクション18.5.3「MySQL Cluster のオンラインバックアップ」およびセクション18.4.20「ndb_restore — MySQL Cluster バックアップのリストア」を参照してください。mysqldump および MySQL Server でこの目的のために用意されている標準の MySQL 機能を使用することもできます。詳細は、セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。

MySQL Cluster ノードのノード間通信では、標準の 100M ビット/秒またはより高速な Ethernet ハードウェアを使用する TCP/IP など、多くの異なる転送メカニズムを使用できます。MySQL Cluster では、高速なスケーラブルコヒーラントインタフェース (SCI) プロトコルを使用することもできますが、これは MySQL Cluster を使用する上で必須ではありません。SCI には特別なハードウェアとソフトウェアが必要です。SCI および MySQL Cluster での SCI の使用方法の詳細は、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。

18.1.1 MySQL Cluster の主な概念

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

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

MySQL Cluster のクラスタ部分は、MySQL Server とは別個に構成されます。MySQL Cluster では、クラスタの各部分がノードとみなされます。

注記

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

クラスタノードには 3 つのタイプがあります。最小限の MySQL Cluster 構成には少なくとも 3 つのノードがあり、各ノードがこれらのタイプのそれぞれに対応します。

  • 管理ノード: このタイプのノードの役割は、構成データの提供、ノードの起動と停止、バックアップの実行などの機能を実行して、MySQL Cluster 内のほかのノードを管理することです。このノードタイプはほかのノードの構成を管理するため、このタイプのノードは最初に (ほかのノードより先に) 起動するようにしてください。MGM ノードは ndb_mgmd コマンドで起動します。

  • データノード: このタイプのノードにはクラスタのデータが格納されます。データノードの数は、レプリカの数にフラグメントの数を乗算した数です (セクション18.1.2「MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション」を参照してください)。たとえば、レプリカが 2 つあり、それぞれにフラグメントが 2 つある場合は、4 つのデータノードが必要です。データストレージとしては 1 つのレプリカで十分ですが、それでは冗長性がありません。したがって、レプリカを 2 つ以上にして、冗長性 (およびその結果としての高可用性) を確保することをお勧めします。データノードは、ndbd (セクション18.4.1「ndbd — MySQL Cluster データノードデーモン」を参照してください) または ndbmtd (セクション18.4.3「ndbmtd — MySQL Cluster データノードデーモン (マルチスレッド)」を参照してください) コマンドで起動します。

    通常、MySQL Cluster テーブルはディスクではなくメモリー内に完全に格納されます (MySQL Cluster をインメモリーデータベースと呼ぶ理由はここにあります)。ただし、MySQL Cluster の一部のデータはディスクに格納できます。詳細は、セクション18.5.12「MySQL Cluster ディスクデータテーブル」を参照してください。

  • SQL ノード: これは、クラスタデータにアクセスするノードです。MySQL Cluster の場合、SQL ノードは NDBCLUSTER ストレージエンジンを使用する従来の MySQL Server です。SQL ノードは、--ndbcluster および --ndb-connectstring オプション (これらについては、この章の別の場所で説明します) を指定して起動される mysqld プロセスです。場合によっては、追加の MySQL Server オプションも指定できます。

    SQL ノードは、実際には MySQL Cluster データにアクセスするアプリケーションが指定された特別なタイプの API ノードです。API ノードのもう 1 つの例は、クラスタのバックアップをリストアするために使われる ndb_restore ユーティリティーです。NDB API を使用してこのようなアプリケーションを作成できます。NDB API の基本情報については、Getting Started with the NDB APIを参照してください。

重要

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

MySQL Cluster のノード間、ノードグループ間、レプリカ間、およびパーティション間の関係の概要については、セクション18.1.2「MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション」を参照してください。

クラスタの構成には、クラスタ内の各ノードの構成と、ノード間の個々の通信リンクの設定が含まれます。MySQL Cluster は現在、データノードがプロセッサの性能、メモリースペース、および帯域幅に関して均一になるよう開発されています。さらに、一元管理の構成を提供するため、クラスタのすべての構成データが全体として 1 つの構成ファイルに格納されます。

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

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

標準の MySQL クライアント  MySQL Cluster は、PHP、Perl、C、C++、Java、Python、Ruby などで作成された既存の MySQL アプリケーションとともに使用できます。このようなクライアントアプリケーションは、スタンドアロンの MySQL Server とやり取りする場合とほとんど同じ方法で、MySQL Cluster の SQL ノードとして機能する MySQL Server に SQL ステートメントを送信し、その MySQL Server から応答を受信します。

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

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

Java 用 MySQL Cluster Connector を使用して、MySQL Cluster 用に NDB 専用の Java アプリケーションを作成することもできます。この MySQL Cluster Connector には、NDBCLUSTER に直接接続する Hibernate や JPA のようなオブジェクトリレーショナルマッピングの永続性フレームワークに似た高レベルのデータベース API である ClusterJ が含まれているため、MySQL Server へのアクセスは必要ありません。MySQL Cluster NDB 7.1 以降では、ClusterJ と JDBC の長所を生かした MySQL Cluster 用の OpenJPA 実装である ClusterJPA もサポートされます。ID ルックアップやその他の高速処理は ClusterJ を使用して (MySQL Server をバイパスして) 実行されますが、MySQL のクエリーオプティマイザによるメリットが得られるより複雑なクエリーは、JDBC を使用して MySQL Server 経由で送信されます。詳細は、Java and NDB ClusterおよびThe ClusterJ API and Data Object Modelを参照してください。

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

memcached バージョン 1.6 以降用のロード可能な ndbmemcache ストレージエンジンとして実装されている MySQL Cluster 用の Memcache API を使用して、memcache プロトコルを使用してアクセスされる永続的な MySQL Cluster データストアを提供できます。

標準の memcached キャッシュエンジンは、MySQL Cluster NDB 7.3 以降の配布に含まれています。各 memcached サーバーは、MySQL Cluster に格納されたデータに直接アクセスしますが、データをローカルでキャッシュして、このローカルキャッシュから要求を処理することもできます。

詳細は、ndbmemcache—Memcache API for NDB Cluster (DEPRECATED)を参照してください。

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

オラクルは、多数のノードを含む MySQL Cluster の再起動など、MySQL Cluster の多くの複雑な管理タスクを簡略化する高度なコマンド行インタフェースを備えた MySQL Cluster Manager も提供しています。MySQL Cluster Manager クライアントは、MySQL Cluster に関連する mysqld サーバーのオプションや変数に加えて、ほとんどのノード構成パラメータの値を取得および設定するためのコマンドもサポートします。詳細は、MySQL™ Cluster Manager 1.3.6 User Manualを参照してください。

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

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

  • ノードログ: 個々のノードごとに保持される個別のログです。

注記

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

チェックポイント  一般的には、データをディスクに保存したときにチェックポイントに達したといいます。MySQL Cluster に限定した場合、チェックポイントはコミットされたトランザクションがディスクに格納された時点です。NDB ストレージエンジンについては 2 つのタイプのチェックポイントがあり、その組み合わせによってクラスタのデータを一貫して確認し続けることができます。次のリストにそれらを示します。

  • ローカルチェックポイント (LCP): これは、1 つのノードに固有のチェックポイントです。ただし、LCP はクラスタ内のすべてのノードである程度同時に発生します。LCP は、ノードのすべてのデータをディスクに保存する必要があるため、通常は数分間隔で発生します。正確な間隔は、ノードに格納されているデータの量、クラスタのアクティビティーのレベル、およびその他の要因によって異なります。

  • グローバルチェックポイント (GCP): GCP は、すべてのノードのトランザクションが同期し、Redo ログがディスクにフラッシュされたときに、数秒間隔で発生します。

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

18.1.2 MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション

このセクションでは、MySQL Cluster が格納するデータを分割および複製する方法について説明します。

次の各段落では、このトピックを理解する上で中心となるいくつかの概念について説明します。

(データ) ノード レプリカ (そのノードがメンバーとなっているノードグループに割り当てられたパーティション (次を参照してください) のコピー) を格納する ndbd プロセスです。

各データノードは、別個のコンピュータに配置するようにしてください。1 つのコンピュータで複数の ndbd プロセスをホストすることも可能ですが、そのような構成はサポートされていません。

通常、ndbd プロセスに言及するときは、ノードデータノードを区別せずに使用します。この説明で管理ノード (ndb_mgmd プロセス) と SQL ノード (mysqld プロセス) に言及するときは、そのように明示します。

ノードグループ  ノードグループは、1 つ以上のノードで構成され、パーティションまたはレプリカ (次の項目を参照してください) のセットを格納します。

MySQL Cluster 内のノードグループの数を直接構成することはできません。これは、ここに示すように、データノードの数とレプリカの数 (NoOfReplicas 構成パラメータ) の関数です。

[number_of_node_groups] = number_of_data_nodes / NoOfReplicas

したがって、4 つのデータノードを含む MySQL Cluster で、config.ini ファイルの NoOfReplicas が 1 に設定されている場合は 4 つのノードグループが存在し、NoOfReplicas が 2 に設定されている場合は 2 つのノードグループが存在し、NoOfReplicas が 4 に設定されている場合は 1 つのノードグループが存在します。レプリカについてはこのセクションで後述します。NoOfReplicas の詳細は、セクション18.3.2.6「MySQL Cluster データノードの定義」を参照してください。

注記

MySQL Cluster 内のすべてのノードグループに同じ数のデータノードが含まれている必要があります。

実行中の MySQL Cluster にオンラインで新しいノードグループ (およびその結果としての新しいデータノード) を追加できます。詳細は、セクション18.5.13「MySQL Cluster データノードのオンライン追加」を参照してください。

パーティション  これは、クラスタに格納されるデータの一部分です。クラスタに参加するノードと同じ数のクラスタパーティションが存在します。各ノードは、そのノードに割り当てられたパーティションの少なくとも 1 つのコピー (つまり、少なくとも 1 つレプリカ) をクラスタで利用可能な状態に維持する役割を担います。

レプリカは完全に 1 つのノードに属します。ノードには複数のレプリカを格納できます (そして通常はそのようにします)。

NDB とユーザー定義のパーティション化  通常、MySQL Cluster は NDBCLUSTER テーブルを自動的にパーティション化します。ただし、NDBCLUSTER テーブルにユーザー定義のパーティション化を適用することもできます。これには、次の制限があります。

  1. NDB テーブルには、KEY および LINEAR KEY パーティション化スキームのみを使用できます。

  2. ndbd を使用する場合、NDB テーブルに対して明示的に定義できるパーティションの最大数は 8 * [ノードグループの数] です。(MySQL Cluster 内のノードグループの数は、このセクションで前述した方法で決定されます。)

    ndbmtd を使用する場合、この最大数は MaxNoOfExecutionThreads 構成パラメータの値によって決定されるローカルクエリーハンドラスレッドの数にも影響されます。このような場合、NDB テーブルに対して明示的に定義できるパーティションの最大数は 4 * MaxNoOfExecutionThreads * [ノードグループの数] になります。

    詳細は、セクション18.4.3「ndbmtd — MySQL Cluster データノードデーモン (マルチスレッド)」を参照してください。

MySQL Cluster とユーザー定義のパーティション化に関する詳細は、セクション18.1.6「MySQL Cluster の既知の制限」およびセクション19.6.2「ストレージエンジンに関連するパーティショニング制限」を参照してください。

レプリカ  これは、クラスタパーティションのコピーです。レプリカは、ノードグループ内の各ノードに格納されます。パーティションレプリカと呼ばれることもあります。レプリカの数は、ノードグループあたりのノード数と同じになります。

次の図に、4 つのデータノードを含む MySQL Cluster を示します。これらのノードはそれぞれ 2 ノードから成る 2 つのノードグループに配置されています。ノード 1 および 2 はノードグループ 0 に属し、ノード 3 および 4 はノードグループ 1 に属します。ここにはデータ (ndbd) ノードのみを表示しています。正常に機能するクラスタにはクラスタ管理用の ndb_mgm プロセスと、クラスタに格納されているデータにアクセスするための SQL ノードが少なくとも 1 つ必要ですが、この図ではわかりやすくするためにこれらを省略しています。

2 ノードから成る 2 つのノードグループを含む MySQL Cluster

クラスタに格納されたデータは、0、1、2、3 の番号が付けられた 4 つのパーティションに分割されています。各パーティションは同じノードグループに (複数のコピーで) 格納されます。パーティションは、次のように各ノードグループに交互に格納されます。

  • パーティション 0 はノードグループ 0 に格納されます。プライマリレプリカ (プライマリコピー) がノード 1 に格納され、バックアップレプリカ (パーティションのバックアップコピー) がノード 2 に格納されます。

  • パーティション 1 は別のノードグループ (ノードグループ 1) に格納されます。このパーティションのプライマリレプリカがノード 3 に格納され、そのバックアップレプリカがノード 4 に格納されます。

  • パーティション 2 はノードグループ 0 に格納されます。ただし、その 2 つのレプリカはパーティション 0 とは逆に配置されます。プライマリレプリカがノード 2 に格納され、バックアップレプリカがノード 1 に格納されます。

  • パーティション 3 はノードグループ 1 に格納され、その 2 つのレプリカはパーティション 1 とは逆に配置されます。つまり、プライマリレプリカがノード 4 に格納され、バックアップレプリカがノード 3 に格納されます。

これは、MySQL Cluster の継続的な運用に関して次のような意味を持っています。クラスタに参加している各ノードグループで少なくとも 1 つのノードが動作しているかぎり、クラスタはすべてのデータの完全なコピーを保持し、実行可能な状態を維持します。これを次の図に示します。

2x2 クラスタの実行可能な状態を維持するのに必要なノード

この例では、クラスタはそれぞれに 2 つのノードを含む 2 つのノードグループで構成されており、クラスタを存続させるには、ノードグループ 0 の少なくとも 1 つのノードとノードグループ 1 の少なくとも 1 つのノードの任意の組み合わせ (図の矢印で示したもの) があれば十分です。ただし、どちらかのノードグループの両方のノードに障害が発生した場合、残りの 2 つのノード (X 印を付けた矢印で示したもの) では不十分です。どちらの場合も、クラスタからパーティション全体が消失するため、すべてのクラスタデータの完全なセットへのアクセスを提供できなくなります。

18.1.3 MySQL Cluster のハードウェア、ソフトウェア、およびネットワーク要件

MySQL Cluster の長所の 1 つは、汎用のハードウェアで実行できるため、すべてのライブデータをメモリーに格納するために大量の RAM を必要とする以外は、ハードウェアに関して特別な要件がないことです。(ディスクデータテーブルを使用してこの要件を削減することもできます。詳細は、セクション18.5.12「MySQL Cluster ディスクデータテーブル」を参照してください。)当然ながら、複数の高速な CPU を使用すればパフォーマンスは向上します。ほかの MySQL Cluster プロセスのメモリー要件は、比較的少量です。

MySQL Cluster のソフトウェア要件も小規模です。ホストのオペレーティングシステムに、MySQL Cluster をサポートするための特別なモジュール、サービス、アプリケーション、または構成は必要ありません。サポートされるオペレーティングシステムについては、標準のインストールで十分のはずです。MySQL のソフトウェア要件は単純です。必要なものは MySQL Cluster の本番リリースだけです。MySQL Cluster を使用できるようにするだけなら、必ずしも MySQL をユーザー自身でコンパイルする必要はありません。ここでは、ユーザーが MySQL Cluster ソフトウェアダウンロードページ (https://dev.mysql.com/downloads/cluster/) から入手できる各自のプラットフォームに適したバイナリを使用していると仮定します。

ノード間の通信については、MySQL Cluster は標準的なトポロジの TCP/IP ネットワークをサポートします。各ホストには、標準の 100M ビット/秒 Ethernet カードが最低限必要です。さらに、クラスタ全体のネットワーク接続を提供するためにスイッチ、ハブ、またはルーターが必要です。次の理由で、クラスタの構成要素でないマシンと共有しない独立したサブネットで MySQL Cluster を実行することをお勧めします。

  • セキュリティー  MySQL Cluster ノード間の通信では、暗号化や保護がまったく行われません。MySQL Cluster 内の伝送を保護する唯一の手段は、MySQL Cluster を保護されたネットワークで実行することです。MySQL Cluster を Web アプリケーションのために使用する場合は、クラスタをネットワークの非武装地帯 (DMZ) などに配置せず、ファイアウォールの背後に間違いなく配置するようにしてください。

    詳細は、セクション18.5.11.1「MySQL Cluster のセキュリティーとネットワーク上の問題」を参照してください。

  • 効率  MySQL Cluster をプライベートネットワークや保護されたネットワークにセットアップすると、クラスタはクラスタホスト間の帯域幅を独占的に使用できます。MySQL Cluster 用に別個のスイッチを使用すると、MySQL Cluster データを不正アクセスから保護できるだけでなく、ネットワーク上のほかのコンピュータ間の伝送によって発生する障害から MySQL Cluster ノードを確実に保護できます。信頼性を高めるため、デュアルスイッチとデュアルカードを使用して、単一障害点になったネットワークを除去できます。多くのデバイスドライバがこのような通信リンクのフェイルオーバーをサポートしています。

ネットワーク通信と待機時間  MySQL Cluster では、データノードと API ノード (SQL ノードを含む) 間、およびデータノードと別のデータノード間でクエリーや更新を実行するために通信を行う必要があります。これらのプロセス間通信の待機時間は、ユーザークエリーの観測されるパフォーマンスと待機時間に直接影響を与える可能性があります。さらに、ノードのサイレント障害が発生した場合でも一貫性とサービスを維持するため、MySQL Cluster では長時間にわたるノードからの通信の喪失をノード障害として扱うハートビートとタイムアウトのメカニズムが使用されます。これは、冗長性の低下につながる可能性があります。ノードグループ内の最後のノードに障害が発生すると、MySQL Cluster はデータの一貫性を維持するためにシャットダウンすることを思い出してください。したがって、強制的なシャットダウンのリスクを増やさないようにするため、ノード間通信の中断はできるかぎり回避すべきです。

データノードまたは API ノードに障害が発生すると、障害が発生したノードに関係するコミットされていないすべてのトランザクションが中止されます。データノードをリカバリするには、データノードのサービスを再開する前に、障害が発生したノードのデータを残存するデータノードのデータと同期し、ディスクベースの redo ログとチェックポイントログを再構築する必要があります。このリカバリには時間がかかる場合があり、その間、クラスタは冗長性が低下した状態で動作します。

ハートビートは、すべてのノードでハートビート信号が遅延なく生成されるかどうかに依存しています。ノードに過大な負荷がかかったり、マシンの CPU がほかのプログラムと共有されるために不十分だったり、スワッピングによる遅延が発生したりすると、これは不可能になります。ハートビート生成の遅延が十分に大きくなると、ほかのノードは応答が遅いノードを障害発生ノードとして扱います。

このように遅いノードを障害発生ノードとして扱うことは、ノードの遅い動作がクラスタの残りの部分にどの程度影響するかによって、望ましい場合とそうでない場合があります。MySQL Cluster の HeartbeatIntervalDbDbHeartbeatIntervalDbApi などのタイムアウト値を設定するときは、高コストの可能性がある誤判定を回避しながら、迅速な検出、フェイルオーバー、サービス再開が実現されるように配慮する必要があります。

データノード間の通信待機時間が LAN 環境での予想値 (およそ 100 マイクロ秒) より大きくなると予想される場合は、タイムアウトのパラメータを増やして、許容する待機時間が構成したタイムアウトの範囲に十分に収まるようにする必要があります。このようにタイムアウトを増やすと、最大の障害検出時間および (その結果としての) サービスリカバリ時間にも類似の効果があります。

LAN 環境は、通常、安定した小さい待機時間で構成できるため、高速フェイルオーバーによる冗長性を提供できます。個々のリンク障害は、TCP レベルで認識できる最小限の制御された (MySQL Cluster が正常に動作する) 待機時間でリカバリできます。WAN 環境では、待機時間に幅があり、冗長性についてもフェイルオーバーに時間がかかる可能性があります。個々のリンク障害では、エンドツーエンドの接続をリストアする前に、ルート変更を伝播する必要があります。これは、TCP レベルでは個々のチャネルの大きな待機時間として現れます。これらのシナリオで最悪の場合に観測される TCP 待機時間は、IP 層で障害を回避するために行われる再ルーティングの最大時間に関連しています。

SCI のサポート  MySQL Cluster に高速なスケーラブルコヒーラントインタフェース (SCI) を使用することもできますが、これは必要条件ではありません。このプロトコルおよび MySQL Cluster での使用方法の詳細は、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。

18.1.4 MySQL Cluster の開発履歴

次の 2 つのセクションでは、MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4 での MySQL Cluster 実装の変更点について、MySQL Cluster NDB 7.2 以前のリリースと比較して説明します。もっとも注目に値する変更点と機能を次の 2 つの表に示します。

MySQL Cluster NDB 7.3
MySQL Cluster NDB 7.3 は MySQL 5.6 をベースにしています。MySQL Server 5.6 の新機能の詳細は、セクション1.4「MySQL 5.6 の新機能」を参照してください。
MySQL Cluster NDB 7.3 は、テーブルの外部キー制約をサポートします。詳細は、セクション1.7.3.2「FOREIGN KEY の制約」およびセクション13.1.17.2「外部キー制約の使用」を参照してください。
MySQL Cluster NDB 7.3 は、JavaScript 用 MySQL NoSQL Connector を使用して Node.js のサポートを提供します。詳細は、MySQL NoSQL Connector for JavaScriptを参照してください。
MySQL Cluster NDB 7.4
MySQL Cluster NDB 7.4 は MySQL 5.6 をベースにしています (MySQL Server 5.6 の新機能の詳細は、セクション1.4「MySQL 5.6 の新機能」を参照してください)。
競合例外テーブルに対する拡張機能を含む、MySQL Cluster レプリケーションの競合検出および解決の拡張 (セクション18.6.11「MySQL Cluster レプリケーションの競合解決」を参照してください)
循環 (アクティブ-アクティブ) レプリケーションの管理の改善 (ndb_slave_conflict_role によるプライマリ/セカンダリの割り当て)
memory_per_fragment テーブルでのフラグメント単位のメモリー使用状況レポート
次の拡張機能を含む多数のパフォーマンス改善
  • 初期メモリー割り当ての高速化

  • ローカルチェックポイントの並列化の強化 (LCP でサポートされるフラグメント数が 2 から 32 に増加)

    このバージョンで導入された一連の構成パラメータ (MaxDiskWriteSpeedMaxDiskWriteSpeedOtherNoderestartMaxDiskWriteSpeedOwnRestart) によって、LCP 中のディスク書き込みの制御が改善されました

    このバージョンの ndbinfo データベースに追加された disk_write_speed_basedisk_write_speed_aggregate、および disk_write_speed_aggregate_node テーブルで、最近のディスク書き込みに関する情報を入手できます

  • バックアップから MySQL Cluster をリストアする時間の短縮

  • NDB 受信スレッドの最適化

ノード再起動中のエラーおよびその他のレポートの改善

これらのセクションには、MySQL Cluster NDB 7.3 リリースの 5.6.22-ndb-7.3.9 (現在一般提供リリースとして入手可能) まで、および MySQL Cluster NDB 7.4 リリースの 5.6.22-ndb-7.4.4 (現在開発者マイルストーンリリースとして入手可能) までに関する情報が含まれています。MySQL Cluster NDB 7.2 および MySQL Cluster NDB 7.1 は、以前の GA リリースシリーズであり、現在もサポートされていますが、新規の配備には MySQL Cluster NDB 7.3 を使用することをお勧めします。

18.1.4.1 MySQL Cluster NDB 7.3 での MySQL Cluster の開発

MySQL Cluster NDB 7.3 では、MySQL Cluster に対して次の改善が行われました。

  • MySQL Server 5.6 ベースになった  MySQL Cluster NDB 7.3 は、MySQL Server 5.6 をベースにしているため、MySQL Cluster ユーザーは MySQL 5.6 の拡張性とパフォーマンスモニタリングの改善によるメリットを得ることができます。MySQL 5.6 と同様に、MySQL Cluster NDB 7.3 では構成とソースからのビルドに CMake が使用されます。MySQL 5.6 での変更点と改善点の詳細は、セクション1.4「MySQL 5.6 の新機能」を参照してください。

  • 外部キー NDB ストレージエンジンバージョン 7.3.0 以降を使用して作成されたテーブルでは、外部キー制約がサポートされます。(これには、すべての MySQL Cluster NDB 7.3 リリースが含まれます。)MySQL 5.6 および MySQL Cluster NDB 7.3 での外部キーの処理方法に関する一般的な情報は、セクション1.7.3.2「FOREIGN KEY の制約」を参照してください。構文および関連情報については、セクション13.1.17「CREATE TABLE 構文」およびセクション13.1.17.2「外部キー制約の使用」を参照してください。

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

MySQL Cluster NDB 7.3 は、MySQL Cluster の多くの複雑な管理タスクを簡略化できる高度なコマンド行インタフェースを備えた MySQL Cluster Manager でもサポートされます。詳細は、MySQL™ Cluster Manager 1.3.6 User Manualを参照してください。

18.1.4.2 MySQL Cluster NDB 7.4 での MySQL Cluster の開発

MySQL Cluster NDB 7.4 では、MySQL Cluster に対して次の改善が行われました。

  • 競合検出および解決の拡張  例外テーブルのメタカラムに対して予約されたカラム名名前空間 NDB$ が採用され、メインテーブルのカラムの任意のサブセットが元のテーブルの主キーの一部でなくても、それらを記録できるようになりました。

    例外テーブルのカラムとの一致が名前と型だけで行われるようになったため、元の主キーを完全に記録する必要がなくなりました。メインテーブルの主キーの一部ではないカラムの値を例外テーブルに記録することも可能になりました。

    読み取りの競合検出が可能になりました。競合するトランザクションによって読み取られたすべての行がフラグ付けされ、例外テーブルに記録されます。同じトランザクションに挿入された行は、読み取りまたは記録の対象となる行に含まれません。この読み取り追跡は、スレーブが事前に ndb_log_exclusive_reads を設定する必要がある排他的な読み取りロックを持っているかどうかに依存します。詳細と例については、読み取り競合の検出と解決を参照してください。

    既存の例外テーブルも引き続きサポートされます。詳細は、セクション18.6.11「MySQL Cluster レプリケーションの競合解決」を参照してください。

  • 循環 (アクティブ-アクティブ) レプリケーションでのロール管理  MySQL Cluster の循環 (アクティブ-アクティブ) レプリケーショントポロジを使用する場合は、ndb_slave_conflict_role サーバーシステム変数を使用して、プライマリまたはセカンダリのいずれかのロールを特定の MySQL Cluster に割り当てることができます。この変数には、PRIMARYSECONDARYPASSNULL のいずれかの値を指定できます。デフォルトは NULL です。これは、プライマリとして機能する MySQL Cluster からフェイルオーバーするときに使用できます。

    競合解決機能の効果が無視されるパススルー状態 (PASS) もサポートされます。詳細は、ndb_slave_conflict_role 変数の説明およびセクション18.6.11「MySQL Cluster レプリケーションの競合解決」を参照してください。

  • フラグメント単位のメモリー使用状況レポート  メモリー使用状況に関するデータを、MySQL Cluster NDB 7.4.1 の ndbinfo 情報データベースに追加された memory_per_fragment ビューから個々の MySQL Cluster フラグメント単位で取得できるようになりました。詳細は、セクション18.5.10.17「ndbinfo memory_per_fragment テーブル」を参照してください。

  • ノードの再起動の改善 

    MySQL Cluster NDB 7.4 には、データノードの再起動にかかる時間を短縮する多数の改善が含まれています。次のリストで、これらについて説明します。

    • ノードの起動時に割り当てられるメモリーは割り当てられるまで使用できないため、オペレーティングシステムは必要な実際の物理メモリーを確保します。MySQL Cluster の以前のバージョンでは、割り当てられたメモリーの各ページにアクセスするプロセスはシングルスレッド化されていたため、比較的時間がかかっていました。このプロセスがマルチスレッドで実装し直されました。16 個のスレッドによるテストでは、シングルスレッドの場合より約 3 倍速いアクセス時間が観測されました。

    • ローカルチェックポイントの並列化が強化され、MySQL Cluster NDB 7.4 では LCP でサポートされるフラグメント数が以前の 2 から 32 に増加しました。これにより、使用されなかった CPU パワーの利用率が大幅に向上し、LCP が最大 10 倍高速化されます。この高速化によってノードの再起動時間も大幅に短縮されます。

    • 新しい ndbinfo テーブルである disk_write_speed_basedisk_write_speed_aggregate、および disk_write_speed_aggregate_node によってディスク書き込みのレポートが提供されます。これらのテーブルは、使用中の各 LDM スレッドのディスク書き込み速度に関する情報を提供します。

      このリリースでは、現在のノードまたは別のノードが現在再起動されているとき、あるいは現在再起動されているノードがないときの LCP およびバックアップの書き込み速度を制御するため、MinDiskWriteSpeedMaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart データノード構成パラメータも追加されています。

      これらの変更の目的は、DiskCheckpointSpeed および DiskCheckpointSpeedInRestart 構成パラメータを使ったディスク書き込みの構成の代替となることです。これら 2 つのパラメータは現在非推奨になっており、今後の MySQL Cluster リリースで削除される予定です。

    • パフォーマンスにとって重要であることが判明したポイントで検出された遅延シグナルを通常の (遅延しない) シグナルに置換することで、バックアップから MySQL Cluster をリストアする時間が短縮されます。これらの不要な遅延シグナルを除去または置換することで、MySQL Cluster のバックアップやバックアップからの MySQL Cluster のリストアにかかる時間が大幅に短縮されるはずです。

    • NDB の受信スレッドに関連する複数の内部メソッドが最適化され、NDB による SQL 処理の効率が向上しました。受信スレッドは、場合によっては 1 秒間に数百万件の受信レコードを処理する必要があるため、MySQL Cluster のデータノードからレコードを取得するときに不要な作業を実行したり、リソースを浪費したりしないようにすることが重要です。

  • MySQL Cluster の起動フェーズのレポートが改善され、起動中の出力回数が増加しました。セクション18.5.1「MySQL Cluster の起動フェーズのサマリー」を参照してください。

18.1.5 InnoDB を使用した MySQL Server と MySQL Cluster の比較

MySQL Server では、ストレージエンジンに数多くの選択肢があります。NDBCLUSTERInnoDB は、どちらもトランザクション対応の MySQL ストレージエンジンとして機能するため、MySQL Server のユーザーが MySQL Cluster に興味を持つこともあります。NDB は、MySQL 5.6 のデフォルトの InnoDB ストレージエンジンの代替候補またはアップグレード候補とみなされています。NDBInnoDB には共通する特徴もありますが、アーキテクチャーや実装が異なるため、既存の MySQL Server アプリケーションや使用シナリオの中には MySQL Cluster に適合するものもありますが、すべてが適合するわけではありません。

このセクションでは、MySQL Cluster NDB 7.3 で使用されている NDB ストレージエンジンの特徴を、MySQL 5.6 で使用されている InnoDB と比較して説明します。次のいくつかのセクションでは、技術的な比較を示します。多くの場合、MySQL Cluster をいつどこで使用するかは、すべての要因を考慮に入れながらケースバイケースで決定する必要があります。このドキュメントでは、考えられるあらゆる使用シナリオの詳細を示すことはしませんが、一般的なタイプのアプリケーションが InnoDB バックエンドに比べて NDB にどの程度適合するかについて、ごく一般的なガイダンスを示します。

MySQL Cluster NDB 7.3 では MySQL 5.6 をベースとする mysqld が使用されますが、これには InnoDB 1.1 のサポートも含まれます。MySQL Cluster で InnoDB テーブルを使用することは可能ですが、このようなテーブルはクラスタ化されません。MySQL Server 5.6 で MySQL Cluster NDB 7.3 配布のプログラムやライブラリを使用すること (またはその逆) もできません。

一般的なビジネスアプリケーションの中には MySQL Cluster と MySQL Server (ほとんどの場合、InnoDB ストレージエンジンを使用) のどちらかで実行可能なタイプがあることも事実ですが、アーキテクチャーと実装には重要な違いがあります。これらの違いのサマリーについては、セクション18.1.5.1「NDB および InnoDB ストレージエンジンの違い」を参照してください。これらの違いのため、一部の使用シナリオは明らかにどちらか一方のエンジンに適しています。セクション18.1.5.2「NDB と InnoDB のワークロード」を参照してください。これは、NDB または InnoDB とともに使用するのが適切なアプリケーションのタイプにも影響を与えます。それぞれが一般的なタイプのデータベースアプリケーションでの使用にどの程度適合するかの比較については、セクション18.1.5.3「NDB および InnoDB の機能使用のサマリー」を参照してください。

NDB および MEMORY ストレージエンジンの相対的な特徴については、MEMORY または MySQL Cluster を使用する場合を参照してください。

MySQL ストレージエンジンに関する追加情報は、第15章「代替ストレージエンジンを参照してください。

18.1.5.1 NDB および InnoDB ストレージエンジンの違い

MySQL Cluster の NDB ストレージエンジンは、分散型のシェアードナッシングアーキテクチャーを使用して実装されているため、InnoDB とは多くの点で動作が異なります。NDB の操作に慣れていないユーザーにとっては、NDB の持つ分散型の性質によって、トランザクション、外部キー、テーブルの制限、およびその他の特性に関して予期しない動作が発生する可能性があります。次の表にそれらを示します。

機能

InnoDB 1.1

MySQL Cluster NDB 7.3、MySQL Cluster NDB 7.4

MySQL Server のバージョン

5.6

5.6

InnoDB のバージョン

InnoDB 5.6.23

InnoDB 5.6.23

MySQL Cluster のバージョン

N/A

NDB 7.3.9

ストレージの制限

64T バイト

3T バイト

(それぞれ 64G バイトの RAM を備えた 48 個のデータノードを基にした現実的な上限。ディスクベースのデータや BLOB によって増える可能性があります)

外部キー

はい

MySQL Cluster NDB 7.3 より前のバージョン: いいえ。(MyISAM と同様に無視されます)

MySQL Cluster NDB 7.3 では利用可能です。

トランザクション

すべての標準タイプ

READ COMMITTED

MVCC

はい

いいえ

データ圧縮

はい

いいえ

(MySQL Cluster のチェックポイントおよびバックアップファイルは圧縮できます)

大きな行のサポート (> 14K)

VARBINARYVARCHARBLOB、および TEXT カラムでサポートされます

BLOB および TEXT カラムでのみサポートされます

(これらの型を使用して非常に大量のデータを格納すると、MySQL Cluster のパフォーマンスが低下する可能性があります)

レプリケーションのサポート

MySQL レプリケーションを使用した非同期および準同期レプリケーション

MySQL Cluster 内での自動的な同期レプリケーション。

MySQL レプリケーションを使用した MySQL Cluster 間の非同期レプリケーション

読み取り操作のスケールアウト

はい (MySQL レプリケーション)

はい (MySQL Cluster 内の自動パーティション化、MySQL レプリケーション)

書き込み操作のスケールアウト

アプリケーションレベルのパーティション化 (シャーディング) が必要です

はい (MySQL Cluster 内の自動パーティション化がアプリケーションに対して透過的に行われます)

高可用性 (HA)

追加のソフトウェアが必要です

はい (99.999% の稼働時間を実現するように設計されています)

ノードの障害リカバリとフェイルオーバー

追加のソフトウェアが必要です

自動

(MySQL Cluster アーキテクチャーの重要な要素)

ノードの障害リカバリにかかる時間

30 秒以上

通常は 1 秒未満

リアルタイムのパフォーマンス

いいえ

はい

インメモリーテーブル

いいえ

はい

(必要に応じて一部のデータをディスクに格納できます。インメモリーとディスクの両方のデータストレージが永続的です)

ストレージエンジンへの NoSQL アクセス

ネイティブの memcached インタフェースが開発中です (MySQL Dev Zone の記事「MySQL Cluster 7.2 (DMR2): NoSQL, Key/Value, Memcached」を参照してください)

はい

Memcached、Node.js/JavaScript、Java、JPA、C++、HTTP/REST を含む複数の API

同時および並列書き込み

サポートされません

同時書き込みのために最適化された最大 48 個のライター

競合検出および解決 (複数のレプリケーションマスター)

いいえ

はい

ハッシュインデックス

いいえ

はい

オンラインのノード追加

MySQL レプリケーションを使った読み取り専用レプリカ

はい (すべてのノードタイプ)

オンラインのアップグレード

いいえ

はい

オンラインのスキーマ変更

はい (MySQL 5.6 の一部として)。

はい。

18.1.5.2 NDB と InnoDB のワークロード

MySQL Cluster には、高可用性、高速フェイルオーバー、高スループット、および低待機時間を必要とするアプリケーションに対応するのに最適なさまざまな固有の属性があります。MySQL Cluster には、その分散型アーキテクチャーと複数ノード実装による固有の制約も存在し、そのために一部のワークロードが適切に実行されないことがあります。データベース駆動型アプリケーションの一般的なワークロードのタイプに関する NDB ストレージエンジンと InnoDB ストレージエンジンの動作の主な違いを、次の表にいくつか示します。

ワークロード

InnoDB

MySQL Cluster (NDB)

大容量 OLTP アプリケーション

はい

はい

DSS アプリケーション (データマート、分析)

はい

制限付き (サイズが 3T バイトを超える OLTP データセット間の結合操作は不可)

カスタムアプリケーション

はい

はい

パッケージ化されたアプリケーション

はい

制限付き (ほとんどが主キーアクセス)。

MySQL Cluster NDB 7.3 は外部キーをサポートします。

ネットワーク内電気通信アプリケーション (HLR、HSS、SDP)

いいえ

はい

セッション管理およびキャッシュ

はい

はい

電子商取引アプリケーション

はい

はい

ユーザープロファイル管理、AAA プロトコル

はい

はい

18.1.5.3 NDB および InnoDB の機能使用のサマリー

InnoDBNDB の機能に対するアプリケーション機能要件を比較すると、その一部は明らかにどちらか一方のストレージエンジンと高い互換性があります。

次の表に、サポートされるアプリケーション機能を、一般に各機能がより適合するストレージエンジンに従って示します。

InnoDB がより適合するアプリケーション要件

NDB がより適合するアプリケーション要件

  • 外部キー

    注記

    MySQL Cluster NDB 7.3 は外部キーをサポートします。

  • 完全なテーブルスキャン

  • 非常に大規模なデータベース、行、またはトランザクション

  • READ COMMITTED 以外のトランザクション

  • 書き込みのスケーリング

  • 99.999% の稼働時間

  • オンラインのノード追加とオンラインのスキーマ操作

  • 複数の SQL および NoSQL API (NDB Cluster APIs: Overview and Conceptsを参照してください)

  • リアルタイムのパフォーマンス

  • BLOB カラムの限定的な使用

  • 外部キーがサポートされますが、外部キーの使用は高スループットでのパフォーマンスに影響する可能性があります。

18.1.6 MySQL Cluster の既知の制限

以降のセクションでは、MySQL Cluster の現在のリリースに含まれる既知の制限について、MyISAM および InnoDB ストレージエンジンを使用した場合に使用できる機能と比較して説明します。MySQL バグデータベース (http://bugs.mysql.com) で Cluster カテゴリをチェックすると、MySQL バグデータベース (http://bugs.mysql.com) の MySQL Server: の下にある次のカテゴリで既知のバグが見つかります。これらのバグは、MySQL Cluster の今後のリリースで修正される予定です。

  • MySQL Cluster

  • Cluster Direct API (NDBAPI)

  • Cluster Disk Data

  • Cluster Replication

  • ClusterJ

この情報は、規定された条件に関して完結するように意図されています。不具合が発生した場合は、セクション1.6「質問またはバグをレポートする方法」に示す手順を使用して MySQL バグデータベースにそれらを報告できます。MySQL Cluster NDB 7.3 の問題を修正する予定がない場合、その問題はリストに追加されます。

MySQL Cluster NDB 7.3 で解決された MySQL Cluster NDB 7.2 の問題のリストについては、セクション18.1.6.11「MySQL Cluster NDB 7.3 で解決された以前の MySQL Cluster の問題」を参照してください。

注記

MySQL Cluster レプリケーションに固有の制限およびその他の問題については、セクション18.6.3「MySQL Cluster レプリケーションの既知の問題」を参照してください。

18.1.6.1 MySQL Cluster での SQL 構文の不適合

次のリストに示すように、特定の MySQL 機能に関連する SQL ステートメントの中には、NDB テーブルで使用したときにエラーを生成するものがあります。

  • 一時テーブル  一時テーブルはサポートされません。NDB ストレージエンジンを使用する一時テーブルを作成しようとしたり、NDB を使用するように既存の一時テーブルを変更しようとしたりすると、失敗して次のエラーが発生します:Table storage engine 'ndbcluster' does not support the create option 'TEMPORARY'.

  • NDB テーブルのインデックスとキー  MySQL Cluster テーブルのインデックスとキーには、次の制限があります。

    • カラム幅  3072 バイトを超える幅の NDB テーブルカラムに対するインデックスを作成しようとすると、成功しますが、インデックスに実際に使用されるのは最初の 3072 バイトだけです。このような場合は、警告 Specified key was too long; max key length is 3072 bytes が発行され、SHOW CREATE TABLE ステートメントではインデックスの長さが 3072 と表示されます。

    • TEXT および BLOB カラム TEXT または BLOB データ型のどちらかを使用する NDB テーブルカラムに対するインデックスは作成できません。

    • FULLTEXT インデックス NDB ストレージエンジンは、FULLTEXT インデックスをサポートしません。これは、MyISAM および (MySQL 5.6.4 以降の) InnoDB テーブルでのみ可能です。

      ただし、NDB テーブルの VARCHAR カラムに対するインデックスは作成できます。

    • USING HASH キーと NULL  一意キーおよび主キーで NULL 可能カラムを使用すると、これらのカラムを使用するクエリーは完全なテーブルスキャンとして処理されます。この問題を回避するには、カラムを NOT NULL にするか、USING HASH オプションを指定せずにインデックスを再作成します。

    • プリフィクス  プリフィクスインデックスはありません。インデックスはカラム全体にのみ付けることができます。(NDB のカラムインデックスのサイズは、このセクションで前述したように、カラムの幅 (バイト単位) と常に同じ (最大 3072 バイトまで) です。追加情報については、セクション18.1.6.6「MySQL Cluster の未サポート機能または欠落している機能」を参照してください。)

    • BIT カラム BIT カラムを主キー、一意キー、またはインデックスにすることはできません。また、複合の主キー、一意キー、またはインデックスの一部にすることもできません。

    • AUTO_INCREMENT カラム  ほかの MySQL ストレージエンジンと同様に、NDB ストレージエンジンはテーブルあたり最大 1 つの AUTO_INCREMENT カラムを処理できます。ただし、明示的な主キーがないクラスタテーブルの場合は、AUTO_INCREMENT カラムが自動的に定義され、隠し主キーとして使用されます。このため、明示的な AUTO_INCREMENT カラムを持つテーブルは、PRIMARY KEY オプションを同時に使用してカラムを宣言しないかぎり定義できません。テーブルの主キーでない AUTO_INCREMENT カラムを持つテーブルを作成しようとして、NDB ストレージエンジンを使用すると、失敗してエラーが発生します。

  • 外部キーに関する制限  MySQL Cluster NDB 7.3 での外部キー制約のサポートは、InnoDB によるサポートと同等ですが、次の制限があります。

    • 外部キーとして参照されるすべてのカラムは、それがテーブルの主キーでない場合、明示的な一意キーを必要とします。

    • 参照先が親テーブルの主キーである場合、ON UPDATE CASCADE はサポートされません。

    • SET DEFAULT はサポートされません。(InnoDB でもサポートされません。)

    • NO ACTION キーワードは受け入れられますが、RESCRICT として扱われます。(InnoDB でも同じです。)

    • MySQL Cluster NDB 7.3.5 以前のバージョンでは、別のテーブルのインデックスを参照する外部キーを含むテーブルを作成したときに、インデックス内のカラムの順序が一致しなくても内部で適切なエラーが返されないことがあったため、外部キーを作成できるように見える場合がありました。MySQL Cluster NDB 7.3.5 ではこの問題が部分的に修正され、内部で使用されるエラーがほとんどの場合に機能するように改善されましたが、親インデックスが一意のインデックスである場合は、まだこの状況が発生する可能性があります。(Bug #18094360)

    詳細は、セクション13.1.17.2「外部キー制約の使用」およびセクション1.7.3.2「FOREIGN KEY の制約」を参照してください。

  • MySQL Cluster とジオメトリデータ型 NDB テーブルでは、ジオメトリデータ型 (WKT および WKB) がサポートされます。ただし、空間インデックスはサポートされません。

  • 文字セットとバイナリログファイル  現在、ndb_apply_status および ndb_binlog_index テーブルは latin1 (ASCII) 文字セットを使用して作成されています。バイナリログの名前はこのテーブルに記録されるため、ラテン語以外の文字を使用する名前が付けられたバイナリログファイルはこれらのテーブルで正しく参照されません。これは既知の問題であり、現在修正中です。(Bug #50226)

    この問題を回避するには、バイナリログファイルの名前を付けるときや、--basedir--log-bin、または --log-bin-index オプションを設定するときに、Latin-1 文字のみを使用してください。

  • ユーザー定義のパーティション化を使用した NDBCLUSTER テーブルの作成 MySQL Cluster でのユーザー定義のパーティション化のサポートは、[LINEAR] KEY のパーティション化に限定されます。CREATE TABLE ステートメントで ENGINE=NDB または ENGINE=NDBCLUSTER とともにほかのパーティショニングタイプを使用すると、エラーが発生します。

    デフォルトのパーティション化スキーム  すべての MySQL Cluster テーブルは、デフォルトではテーブルの主キーをパーティション化キーとして使用して KEY によってパーティション化されます。テーブルに明示的に設定された主キーがない場合は、代わりに NDB ストレージエンジンによって自動的に作成された隠し主キーが使用されます。これらおよび関連する問題の追加情報については、セクション19.2.5「KEY パーティショニング」を参照してください。

    ユーザーパーティション化された NDBCLUSTER テーブルが次の 2 つの要件のどちらかまたは両方を満たさない原因となる CREATE TABLE および ALTER TABLE ステートメントは許可されず、失敗してエラーが発生します。

    1. テーブルに明示的な主キーが存在する必要があります。

    2. テーブルのパーティショニング式に指定されたすべてのカラムが主キーの一部である必要があります。

    例外  空のカラムリストを使用して (つまり、PARTITION BY [LINEAR] KEY() を使用して) ユーザーパーティション化された NDBCLUSTER テーブルを作成する場合は、明示的な主キーは必要ありません。

    NDBCLUSTER テーブルの最大パーティション数  ユーザー定義のパーティション化を使用したときに NDBCLUSTER テーブルに定義できるパーティションの最大数は、ノードグループあたり 8 個です。(MySQL Cluster ノードグループの詳細は、セクション18.1.2「MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション」を参照してください。

    DROP PARTITION の未サポート ALTER TABLE ... DROP PARTITION を使用して NDB テーブルからパーティションを削除することはできません。クラスタテーブルでは ALTER TABLE に対する別のパーティション化拡張機能 (ADD PARTITIONREORGANIZE PARTITION、および COALESCE PARTITION) がサポートされますが、コピーが使用されるため、最適化されません。セクション19.3.1「RANGE および LIST パーティションの管理」およびセクション13.1.7「ALTER TABLE 構文」を参照してください。

  • 行ベースのレプリケーション  MySQL Cluster で行ベースのレプリケーションを使用するときは、バイナリロギングを無効にすることができません。つまり、NDB ストレージエンジンは sql_log_bin の値を無視します。(Bug #16680)

18.1.6.2 MySQL Cluster の制限と標準の MySQL の制限との違い

このセクションでは、MySQL Cluster に含まれる制限のうち、標準の MySQL に含まれる制限とは異なる (または含まれない) ものを示します。

メモリーの使用量とリカバリ  ほかのストレージエンジンと同様、NDB テーブルにデータを挿入したときに消費されたメモリーは、削除したときに自動的にリカバリされません。代わりに、次のルールが適用されます。

  • NDB テーブルに対して DELETE ステートメントを実行すると、削除された行で以前使用されていたメモリーが同じテーブルでの挿入にかぎって再利用可能になります。ただし、OPTIMIZE TABLE を実行すると、このメモリーの一般的な再利用が可能になります。

    クラスタのローリング再起動が行われた場合も、削除された行で使用されていたメモリーが解放されます。セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください。

  • NDB テーブルに対して DROP TABLE または TRUNCATE TABLE 操作を実行すると、このテーブルで使用されていたメモリーが解放され、任意の NDB テーブルで (同じテーブルでも別の NDB テーブルでも) 再利用可能になります。

    注記

    TRUNCATE TABLE によってテーブルが削除され、再作成されることを思い出してください。セクション13.1.33「TRUNCATE TABLE 構文」を参照してください。

  • クラスタの構成によって課される制限  多くの構成可能なハード制限がありますが、クラスタ内の利用可能なメインメモリーによって制限が設定されます。セクション18.3.2「MySQL Cluster の構成ファイル」の構成パラメータの完全なリストを参照してください。ほとんどの構成パラメータはオンラインでアップグレードできます。これらのハード制限には次のようなものがあります。

    • データベースのメモリーサイズとインデックスのメモリーサイズ (それぞれ DataMemoryIndexMemory)。

      DataMemory は 32K バイトのページとして割り当てられます。各 DataMemory ページは、使用されたときに特定のテーブルに割り当てられます。割り当てられたあとは、テーブルを削除した場合を除いてこのメモリーを解放できません。

      詳細は、セクション18.3.2.6「MySQL Cluster データノードの定義」を参照してください。

    • 1 つのトランザクションで実行できる操作の最大数は、構成パラメータ MaxNoOfConcurrentOperations および MaxNoOfLocalOperations を使用して設定されます。

      注記

      一括ロード、TRUNCATE TABLE、および ALTER TABLE は、複数のトランザクションを実行することによって特別なケースとして扱われるため、この制限が適用されません。

    • テーブルとインデックスに関するさまざまな制限。たとえば、クラスタ内の順序付けされたインデックスの最大数は MaxNoOfOrderedIndexes によって決定され、テーブルあたりの順序付けされたインデックスの最大数は 16 です。

  • ノードとデータオブジェクトの最大数  クラスタノードとメタデータオブジェクトの数には、次の制限が適用されます。

    • データノードの最大数は 48 です。

      データノードは 1 から 48 までの (これらを含む) 範囲のノード ID を持つ必要があります。(管理ノードと API ノードには、1 から 255 までの (これらを含む) 範囲のノード ID が使用される場合があります。)

    • MySQL Cluster 内のノードの最大合計数は 255 です。この数には、すべての SQL ノード (MySQL Server)、API ノード (MySQL Server 以外のクラスタにアクセスするアプリケーション)、データノード、および管理サーバーが含まれます。

    • メタデータオブジェクトの最大数は、MySQL Cluster の現在のバージョンでは 20320 です。この制限はハードコーディングされています。

    詳細は、セクション18.1.6.11「MySQL Cluster NDB 7.3 で解決された以前の MySQL Cluster の問題」を参照してください。

18.1.6.3 MySQL Cluster でのトランザクション処理に関する制限

MySQL Cluster には、トランザクションの処理に関していくつかの制限があります。これらには、次のものが含まれます。

  • トランザクション分離レベル NDBCLUSTER ストレージエンジンは、READ COMMITTED トランザクション分離レベルのみをサポートします。(たとえば、InnoDBREAD COMMITTEDREAD UNCOMMITTEDREPEATABLE READ、および SERIALIZABLE をサポートします。)これがクラスタデータベースのバックアップとリストアに与える影響については、セクション18.5.3.4「MySQL Cluster バックアップのトラブルシューティング」を参照してください。)

  • トランザクションと BLOB または TEXT カラム NDBCLUSTER は、MySQL から認識できるテーブルに MySQL の BLOB または TEXT データ型のいずれかを使用するカラム値の一部のみを格納します。BLOB または TEXT の残りの部分は、MySQL からアクセスできない別の内部テーブルに格納されます。これに関連して、これらの型のカラムを含むテーブルに対して SELECT ステートメントを実行するときに常に注意すべき問題が 2 つ発生します。

    1. MySQL Cluster テーブルからの SELECT の場合: SELECTBLOB または TEXT カラムが含まれる場合は、READ COMMITTED トランザクション分離レベルが読み取りロック付きの読み取りに変換されます。これは一貫性を保証するために行われます。

    2. 一意キーのルックアップを使用して BLOB または TEXT データ型のいずれかを使用するカラムを取得し、1 つのトランザクション内で実行される SELECT の場合は、共有読み取りロックがトランザクションの期間中 (つまり、トランザクションがコミットまたは中止されるまで) そのテーブルに保持されます。

      インデックスまたはテーブルスキャンを使用するクエリーでは、BLOB または TEXT カラムを含む NDB テーブルが対象であっても、この問題は発生しません。

      たとえば、次の CREATE TABLE ステートメントによって定義されたテーブル t について考えます。

      CREATE TABLE t ( a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b INT NOT NULL, c INT NOT NULL, d TEXT, INDEX i(b), UNIQUE KEY u(c)
      ) ENGINE = NDB,

      t に対する次のクエリーでは、1 つ目のクエリーが主キールックアップを使用し、2 つ目が一意キールックアップを使用しているため、いずれも共有読み取りロックが発生します。

      SELECT * FROM t WHERE a = 1;
      SELECT * FROM t WHERE c = 1;

      しかし、ここに示す 4 つのクエリーでは、いずれも共有読み取りロックは発生しません。

      SELECT * FROM t WHERE b 1;
      SELECT * FROM t WHERE d = '1';
      SELECT * FROM t;
      SELECT b,c WHERE a = 1; 

      その理由は、これら 4 つのクエリーのうち、1 つ目はインデックススキャンを使用し、2 つ目と 3 つ目はテーブルスキャンを使用し、4 つ目は (主キールックアップを使用していますが) BLOB または TEXT カラムの値を取得していないためです。

      BLOB または TEXT カラムを取得する一意キールックアップを使用するクエリーを回避するか、このようなクエリーを回避できない場合はトランザクションのコミットをできるだけあとで行うようにすると、共有読み取りロックによる問題を最小限に抑えることができます。

  • ロールバック  部分的なトランザクションおよびトランザクションの部分的なロールバックはありません。重複キーまたは同様のエラーが発生すると、トランザクション全体がロールバックされます。

    この動作は、個々のステートメントをロールバックできる InnoDB などのほかのトランザクション対応のストレージエンジンと異なります。

  • トランザクションとメモリー使用量  この章の別の場所で説明したように、MySQL Cluster では大規模なトランザクションが適切に処理されません。多数の操作を含む 1 つの大規模なトランザクションを実行するより、少数の操作を含む複数の小規模なトランザクションを実行する方が適切です。特に考慮すべき点は、大規模なトランザクションが非常に大量のメモリーを必要とすることです。このため、いくつかの MySQL ステートメントのトランザクション動作に対して次のリストに示すような影響があります。

    • TRUNCATE TABLE は、NDB テーブルに対して使用した場合、トランザクションになりません。TRUNCATE TABLE でテーブルを空にできない場合は、成功するまでこれを再実行する必要があります。

    • DELETE FROM (WHERE 句が内場合も含む) は、トランザクションになります。テーブルに非常に多くの行が含まれる場合は、複数の DELETE FROM ... LIMIT ... ステートメントを使用して削除操作をひとまとめにすると、パフォーマンスが向上することがあります。テーブルを空にすることが目的である場合は、代わりに TRUNCATE TABLE を使用することをお勧めします。

    • LOAD DATA ステートメント LOAD DATA INFILE は、NDB テーブルに使用した場合、トランザクションになりません。

      重要

      LOAD DATA INFILE ステートメントを実行すると、NDB エンジンは通信ネットワークの利用率が高くなるように不規則な間隔でコミットを実行します。このようなコミットが発生するタイミングを事前に知ることはできません。

    • ALTER TABLE とトランザクション ALTER TABLE の一部として NDB テーブルをコピーする場合、コピーの作成はトランザクションになりません。(いずれにしても、コピーが削除されたときにこの操作はロールバックされます。)

  • トランザクションと COUNT() 関数  MySQL Cluster レプリケーションを使用する場合、スレーブでの COUNT() 関数のトランザクション一貫性は保証されません。つまり、1 つのトランザクション内でテーブル内の行数を変更する一連のステートメント (INSERTDELETE、またはその両方) をマスターで実行しているときに、スレーブで SELECT COUNT(*) FROM table クエリーを実行すると、中間の結果が返される可能性があります。これは、SELECT COUNT(...) がダーティー読み取りを行うために発生し、NDB ストレージエンジンのバグではありません。(詳細は、Bug #31321 を参照してください。)

18.1.6.4 MySQL Cluster のエラー処理

ノードの起動、停止、および再起動によって、トランザクションが失敗する原因となる一時的なエラーが発生する場合があります。これらには、次のケースが含まれます。

  • 一時エラー  ノードを最初に起動するときは、エラー 1204 Temporary failure, distribution changedおよび同様の一時エラーが発生する可能性があります。

  • ノード障害によるエラー  データノードの停止または障害によって、いくつかの異なるノード障害エラーが発生する場合があります。(ただし、クラスタの計画的なシャットダウンを実行したときに中止されるトランザクションは存在しないはずです。)

これらのいずれの場合も、生成されたエラーはアプリケーションの内部で処理する必要があります。これは、トランザクションの再試行によって行うべきです。

セクション18.1.6.2「MySQL Cluster の制限と標準の MySQL の制限との違い」も参照してください。

18.1.6.5 MySQL Cluster 内のデータベースオブジェクトに関する制限

NDBCLUSTER ストレージエンジンを使用するときは、テーブルやインデックスなどの一部のデータベースオブジェクトに関してさまざまな制限があります。

  • データベース名とテーブル名 NDB ストレージエンジンを使用するときは、データベース名とテーブル名の最大許容長はどちらも 63 文字です。

    MySQL Cluster NDB 7.3.8 以降では、この制限を超える長さのデータベース名またはテーブル名を使用するステートメントは該当するエラーで失敗します。(Bug #19550973)

  • データベースオブジェクトの数  1 つの MySQL Cluster に含まれるすべてのNDB データベースオブジェクト (データベース、テーブル、およびインデックスを含む) の最大数は、20320 に制限されています。

  • テーブルあたりの属性数  特定のテーブルに属すことができる属性 (つまり、カラムとインデックス) の最大数は 512 です。

  • キーあたりの属性数  キーあたりの属性の最大数は 32 です。

  • 行サイズ  1 行の最大許容サイズは 14000 バイトです (MySQL Cluster NDB 7.0 の時点で)。この合計のうち、個々の BLOB または TEXT カラムは 256 + 8 = 264 バイトを占めます。

18.1.6.6 MySQL Cluster の未サポート機能または欠落している機能

NDB テーブルでは、ほかのストレージエンジンでサポートされるいくつかの機能がサポートされません。MySQL Cluster でこれらの機能を使用しようとすると、それ自体ではエラーは発生しませんが、その機能がサポートまたは適用されることを予期するアプリケーションでエラーが発生する可能性があります。

  • インデックスのプリフィクス NDBCLUSTER テーブルでは、インデックスのプリフィクスはサポートされません。CREATE TABLEALTER TABLECREATE INDEX などのステートメントでインデックス指定の一部としてプリフィクスが使用された場合、そのプリフィクスは無視されます。

  • セーブポイントとロールバック  セーブポイントおよびセーブポイントへのロールバックは、MyISAM と同様に無視されます。

  • コミットの持続性  ディスクに対する永続的なコミットはありません。コミットはレプリケートされますが、コミット時にログがディスクにフラッシュされる保証はありません。

  • レプリケーション  ステートメントベースのレプリケーションはサポートされません。クラスタのレプリケーションを設定するときは、--binlog-format=ROW (または --binlog-format=MIXED) を使用してください。詳細は、セクション18.6「MySQL Cluster レプリケーション」を参照してください。

    グローバルトランザクション ID (GTID) を使用したレプリケーションは、MySQL Cluster と互換性がなく、MySQL Cluster NDB 7.3 または MySQL Cluster NDB 7.4 ではサポートされません。MySQL Cluster レプリケーションの失敗を含む問題が発生する可能性が非常に高いため、NDB ストレージエンジンを使用するときは GTID を有効にしないでください。

注記

NDB でのトランザクション処理に関する制限の詳細は、セクション18.1.6.3「MySQL Cluster でのトランザクション処理に関する制限」を参照してください。

18.1.6.7 MySQL Cluster のパフォーマンスに関する制限

次のパフォーマンスの問題は、MySQL Cluster に固有の問題または MySQL Cluster で特に顕著な問題です。

  • Range scans NDB ストレージエンジンへの順次アクセスによって発生するクエリーのパフォーマンスの問題があります。多数の範囲スキャンの実行も、MyISAMInnoDB に比べて負荷が高くなります。

  • Records in range の信頼性 Records in range 統計は使用可能ですが、完全なテストや正式なサポートは行われていません。このため、場合によっては最適でないクエリー計画が生成されることがあります。必要な場合は、USE INDEX または FORCE INDEX を使用して実行プランを変更できます。これを行う方法の詳細は、セクション13.2.9.3「インデックスヒントの構文」を参照してください。

  • 一意のハッシュインデックス USING HASH で作成された一意のハッシュインデックスは、NULL がキーの一部として指定された場合はテーブルへのアクセスに使用できません。

18.1.6.8 MySQL Cluster に限定された問題

NDBCLUSTER ストレージエンジンに固有の制限を次に示します。

  • マシンアーキテクチャー  クラスタ内で使用されるすべてのマシンが同じアーキテクチャーである必要があります。つまり、ノードをホストするすべてのマシンがビッグエンディアンまたはリトルエンディアンのどちらかである必要があり、両者を組み合わせて使用することはできません。たとえば、PowerPC で実行されている管理ノードから x86 マシンで実行されているデータノードに指示することはできません。この制限は、クラスタの SQL ノードにアクセスする可能性がある mysql またはその他のクライアントを実行するだけのマシンには適用されません。

  • バイナリロギング  MySQL Cluster には、バイナリロギングに関して次の制限または規制があります。

    • sql_log_bin は、データ操作では効果がありませんが、スキーマ操作ではサポートされます。

    • MySQL Cluster は、BLOB カラムがあっても主キーがないテーブルのバイナリログを生成できません。

    • ステートメントを実行する mysqld に配置されていないクラスタバイナリログには、次のスキーマ操作だけが記録されます。

      • CREATE TABLE

      • ALTER TABLE

      • DROP TABLE

      • CREATE DATABASE / CREATE SCHEMA

      • DROP DATABASE / DROP SCHEMA

      • CREATE TABLESPACE

      • ALTER TABLESPACE

      • DROP TABLESPACE

      • CREATE LOGFILE GROUP

      • ALTER LOGFILE GROUP

      • DROP LOGFILE GROUP

セクション18.1.6.10「複数の MySQL Cluster ノードに関する制限」も参照してください。

18.1.6.9 MySQL Cluster のディスクデータストレージに関する制限

ディスクデータオブジェクトの最大数と最小数  ディスクデータオブジェクトには、次の最大数および最小数が適用されます。

  • テーブルスペースの最大数: 232 (4294967296)

  • テーブルスペースあたりのデータファイルの最大数: 216 (65536)

  • データファイルの最大サイズ: 理論的な限界は 64G ですが、実際的な上限は 32G です。これは、1M のエクステント 32768 個分に相当します。

    MySQL Cluster のディスクデータテーブルは最大 1 つのテーブルスペースを使用できます。つまり、1 つの NDB テーブルによってディスク上に格納できるデータ量 (バイト単位) の理論的な上限は 32G * 65536 = 2251799813685248 (およそ 2 ペタバイト) です。

  • テーブルスペースのデータファイルあたりのエクステントの理論的な最大数は 216 (65536) です。ただし、実際的に推奨されるデータファイルあたりのエクステントの最大数は 215 (32768) です。

    テーブルスペースのデータファイルのエクステントが取り得る最小および最大サイズは、それぞれ 32K および 2G です。詳細は、セクション13.1.18「CREATE TABLESPACE 構文」を参照してください。

ディスクデータテーブルとディスクレスモード  クラスタをディスクレスモードで実行しているときは、ディスクデータテーブルを使用できません。

18.1.6.10 複数の MySQL Cluster ノードに関する制限

複数の SQL ノード  複数の MySQL サーバーを MySQL Cluster の SQL ノードとして使用することに関する NDBCLUSTER ストレージエンジン固有の問題を次に示します。

  • 分散型のテーブルロックがない LOCK TABLES は、ロックが発行された SQL ノードに対してのみ機能します。クラスタ内のほかの SQL ノードでは、このロックは認識されません。これは、操作の一部としてテーブルをロックするステートメントによって発行されたロックにも当てはまります。(例については、次の項目を参照してください。)

  • ALTER TABLE 操作  複数の MySQL サーバー (SQL ノード) が実行されているときは、ALTER TABLE によるロックは完全ではありません。(前の項目で説明したように、MySQL Cluster は分散型のテーブルロックをサポートしません。)

複数の管理ノード  複数の管理サーバーを使用する場合:

  • ノード ID の自動割り当てが複数の管理サーバー間で機能しないため、接続文字列にノードの明示的な ID を指定する必要があります。

  • 管理サーバーを起動すると、まず同じ MySQL Cluster 内にほかの管理サーバーがあるかどうかがチェックされ、ほかの管理サーバーへの接続に成功すると、その構成データが使用されます。つまり、管理サーバーの --reload および --initial 起動オプションは、それが実行中の唯一の管理サーバーでないかぎり、無視されます。また、複数の管理ノードを含む MySQL Cluster のローリング再起動を実行すると、管理サーバーはその MySQL Cluster で実行中の唯一の管理サーバーである場合にかぎって、それ自身の構成ファイルを読み取ります。詳細は、セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください。

複数のネットワークアドレス  1 つのデータノードに対する複数のネットワークアドレスはサポートされません。これらを使用すると、問題が発生しやすくなります。データノードに障害が発生すると、SQL ノードはデータノードが停止したことの確認を待機しますが、そのデータノードへの別のルートが開いたままであるため、この確認を受信できません。これにより、クラスタは実質的に操作不能になります。

注記

1 つのデータノードで複数のネットワークハードウェアインタフェース (Ethernet カードなど) を使用できますが、これらは同じアドレスにバインドする必要があります。これは、config.ini ファイルで接続ごとに複数の [tcp] セクションを使用できないことも意味します。詳細は、セクション18.3.2.8「MySQL クラスタの TCP/IP 接続」を参照してください。

18.1.6.11 MySQL Cluster NDB 7.3 で解決された以前の MySQL Cluster の問題

MySQL Cluster NDB 7.3 では、MySQL Cluster の以前のバージョンに存在したいくつかの制限および関連する問題が解決されました。これらについて、次のリストで簡単に説明します。

  • 外部キーのサポート NDB テーブルの外部キー制約が、InnoDB ストレージエンジンでのサポートと同様の方法でサポートされました。

    注記

    ユーザーパーティション化された InnoDB テーブルの場合とは異なり、KEY または LINEAR KEY によってパーティション化された NDB テーブルで外部キーがサポートされます。

    MySQL での外部キーのサポートの詳細は、セクション1.7.3.2「FOREIGN KEY の制約」を参照してください。MySQL でサポートされる外部キーの構文の詳細は、セクション13.1.17.2「外部キー制約の使用」を参照してください。

18.2 MySQL Cluster のインストール

このセクションでは、MySQL Cluster の計画、インストール、構成、および実行の基本について説明します。セクション18.3「MySQL Cluster の構成」の例ではクラスタリングのさまざまなオプションと構成について詳しく説明しますが、ここで概説するガイドラインと手順に従うことで、データの可用性と保護に関する最小要件を満たす使用可能な MySQL Cluster が構築されます。

MySQL Cluster のリリースバージョンでのアップグレードまたはダウングレードについては、セクション18.2.8「MySQL Cluster NDB 7.3 のアップグレードとダウングレード」を参照してください。

このセクションでは、ハードウェアとソフトウェアの要件、ネットワークの問題、MySQL Cluster のインストール、基本的な構成の問題、クラスタの開始、停止、および再起動、サンプルデータベースのロード、およびクエリーの実行について説明します。

MySQL Cluster NDB 7.3 以降では、Web ベースのグラフィカルインストーラである MySQL Cluster Auto-Installer が MySQL Cluster 配布の一部として提供されます。Auto-Installer を使用すると、1 台 (テスト用) または複数のホストコンピュータに対して MySQL Cluster の基本的なインストールとセットアップを実行できます。詳細は、セクション18.2.1「MySQL Cluster Auto-Installer」を参照してください。

仮定  以降のセクションでは、クラスタの物理的構成とネットワーク構成に関していくつかの仮定を立てています。これらの仮定については、次のいくつかの段落で説明します。

クラスタノードとホストコンピュータ  このクラスタは、ここに示す 4 つのノードで構成されます。各ノードは別個のホストコンピュータ上に配置され、一般的な Ethernet ネットワーク上に固定のネットワークアドレスを持っています。

ノードIP アドレス
管理ノード (mgmd)192.168.0.10
SQL ノード (mysqld)192.168.0.20
データノード "A" (ndbd)192.168.0.30
データノード "B" (ndbd)192.168.0.40

これをより明確に表したものが次の図です。

複数のコンピュータによる MySQL Cluster のセットアップ

ネットワークアドレス設定 簡略化 (および信頼性) のため、この操作手順では数値の IP アドレスのみを使用します。ただし、ネットワーク上で DNS 解決が利用可能な場合は、クラスタ構成時に IP アドレスの代わりにホスト名を使用できます。また、hosts ファイル (通常、Linux およびその他の Unix 系オペレーティングシステムでは /etc/hosts、Windows では C:\WINDOWS\system32\drivers\etc\hosts、または使用しているオペレーティングシステムの同等のファイル) が使用可能な場合は、ホスト検索を行う手段として使用することもできます。

hosts ファイルの潜在的な問題  クラスタノードにホスト名を使用しようとしたときによくある問題は、一部のオペレーティングシステム (一部の Linux 配布を含む) がインストール中にシステム独自のホスト名を /etc/hosts に設定する方法が原因で発生します。ndb1 および ndb2 というホスト名を持つ 2 台のマシンがどちらも cluster ネットワークドメインに含まれる場合について考えます。Red Hat Linux (CentOS や Fedora などの一部の派生バージョンを含む) では、これらのマシンの /etc/hosts ファイルに次のエントリが設定されます。

# ndb1 /etc/hosts:
127.0.0.1 ndb1.cluster ndb1 localhost.localdomain localhost
# ndb2 /etc/hosts:
127.0.0.1 ndb2.cluster ndb2 localhost.localdomain localhost

SUSE Linux (OpenSUSE を含む) では、マシンの /etc/hosts ファイルにこれらのエントリが設定されます。

# ndb1 /etc/hosts:
127.0.0.1 localhost
127.0.0.2 ndb1.cluster ndb1
# ndb2 /etc/hosts:
127.0.0.1 localhost
127.0.0.2 ndb2.cluster ndb2

どちらの場合も、ndb1ndb1.cluster をループバック IP アドレスにルーティングしますが、DNS から ndb2.cluster のパブリック IP アドレスを取得します。一方、ndb2ndb2.cluster をループバックアドレスにルーティングし、ndb1.cluster のパブリックアドレスを取得します。その結果、各データノードは管理サーバーに接続しますが、ほかのデータノードが接続したことを検出できないため、データノードが起動中にハングアップしたように見えます。

注意

config.ini では localhost とほかのホスト名または IP アドレスを混在できません。これらの理由により、このようなケースの (config.iniすべてのHostName エントリで IP アドレスを使用する以外の) 解決策は、すべてのクラスタホストの /etc/hosts から完全修飾ホスト名を削除し、config.ini で使用することです。

ホストコンピュータのタイプ  このインストールシナリオに含まれる各ホストコンピュータは、標準的な構成でディスクにインストールされたサポート対象のオペレーティングシステムを実行し、不要なサービスを実行していない Intel ベースのデスクトップ PC です。標準の TCP/IP ネットワーク機能を含む中核的なオペレーティングシステムで十分です。また、簡略化のため、すべてのホストのファイルシステムが完全に同じように設定されていると仮定します。そうでない場合は、状況に応じてこれらの手順を適用してください。

ネットワークハードウェア  各マシンには標準の 100M ビット/秒または 1 ギガビット Ethernet カードが (カードに対応するドライバとともに) 取り付けられ、4 台のホストすべてがスイッチなどの標準仕様の Ethernet ネットワークアプライアンスを介して接続されています。(すべてのマシンで同じスループットのネットワークカードを使用してください。つまり、クラスタ内の 4 台のマシンで 100M ビット/秒カードを使用するか、または 4 台のマシンで 1 ギガビットカードを使用してください。)MySQL Cluster は 100M ビット/秒のネットワークで動作しますが、ギガビット Ethernet ではパフォーマンスがさらに向上します。

重要

MySQL Cluster は、スループットが 100M ビット/秒未満のネットワークや長い待機時間が発生するネットワークで使用できるように設計されていません。特にこの理由により、インターネットなどの広域ネットワークを介して MySQL Cluster を実行することは、成功する可能性が低く、本番環境ではサポートされていません。

サンプルデータ  ここでは、MySQL Web サイトからダウンロードできる world データベースを使用します (https://dev.mysql.com/doc/index-other.html を参照してください)。ここでは、オペレーティングシステムと必要な MySQL Cluster プロセスを実行し、(データノードで) データベースを格納するための十分なメモリーが各マシンにあると仮定します。

MySQL のインストールに関する一般的な情報は、第2章「MySQL のインストールと更新を参照してください。Linux およびその他の Unix 系オペレーティングシステムに対する MySQL Cluster のインストールについては、セクション18.2.2「Linux での MySQL Cluster のインストール」を参照してください。Windows オペレーティングシステムに対する MySQL Cluster のインストールについては、セクション18.2.3「Windows での MySQL Cluster のインストール」を参照してください。

MySQL Cluster のハードウェア、ソフトウェア、およびネットワーク要件に関する一般的な情報は、セクション18.1.3「MySQL Cluster のハードウェア、ソフトウェア、およびネットワーク要件」を参照してください。

18.2.1 MySQL Cluster Auto-Installer

このセクションでは、MySQL Cluster NDB 7.3.1 から MySQL Cluster 配布の一部として組み込まれた Web ベースのグラフィカル構成インストーラについて説明します。説明するトピックには、インストーラとその各部分の概要、インストーラを実行するためのソフトウェアおよびその他の要件、GUI の操作、およびインストーラを使用して 1 台以上のホストコンピュータに MySQL Cluster をセットアップし、起動または停止する方法が含まれます。

18.2.1.1 MySQL Cluster Auto-Installer の要件

このセクションでは、サポートされるオペレーティングプラットフォームとソフトウェア、必要なソフトウェア、および MySQL Cluster Auto-Installer を実行するためのその他の前提条件について説明します。

サポートされるプラットフォーム MySQL Cluster Auto-Installer は、Linux、Windows、Solaris、および MacOS X の最近のバージョンに対応する MySQL Cluster NDB 7.3 以降のほとんどの配布で使用できます。MySQL Cluster および MySQL Cluster Auto-Installer のプラットフォームサポートの詳細は、https://www.mysql.com/support/supportedplatforms/cluster.html を参照してください。

サポートされる Web ブラウザ この Web ベースのインストーラは、Firefox および Microsoft Internet Explorer の最近のバージョンでサポートされます。また、Opera、Safari、および Chrome の最近のバージョンでも動作しますが、これらのブラウザとの互換性に関する詳細なテストは行われていません。

必要なソフトウェア (セットアップホスト) Auto-Installer を実行するホストには、次のソフトウェアがインストールされている必要があります。

  • Python 2.6 以降 Auto-Installer には、Python インタプリタおよび標準ライブラリが必要です。これらがシステムにまだインストールされていない場合は、システムのパッケージマネージャーを使用して追加できる可能性があります。そうでない場合は、http://python.org/download/ からダウンロードできます。

  • Paramiko 1.7.7.1 以降  これは、SSH を使用してリモートホストと通信するために必要です。http://www.lag.net/paramiko/ からダウンロードできます。Paramiko は、使用しているシステムのパッケージマネージャーから入手することもできます。

  • Pycrypto バージョン 2.6 以降  この暗号化モジュールは Paramiko が必要とします。使用しているシステムのパッケージマネージャーを使用して入手できない場合は、https://www.dlitz.net/software/pycrypto/ からダウンロードできます。

構成ツールの Windows バージョンには、前のリストに示したすべてのソフトウェアが含まれているため、別個にインストールする必要はありません。

Paramiko および Pycrypto ライブラリは、MySQL Cluster ノードをリモートホストに配備する場合にのみ必要です。インストーラを実行する同じホストにすべてのノードを配置する場合は必要ありません。

必要なソフトウェア (リモートホスト) MySQL Cluster ノードを配備するリモートホストに必要な唯一のソフトウェアは、Linux および Solaris システムでは通常デフォルトでインストールされる SSH サーバーです。Windows では、いくつかの代わりとなるものが使用可能です。概要については、http://en.wikipedia.org/wiki/Comparison_of_SSH_servers を参照してください。

複数のホストを使用するときの追加要件は、次の段落で説明するように、SSH と適切な鍵またはユーザー資格証明を使用してリモートホストで認証できるようにすることです。

認証とセキュリティー Auto-Installer では、リモートアクセスに対してここに示す 3 つの基本的なセキュリティーまたは認証メカニズムを使用できます。

  • SSH  セキュアシェル接続を使用すると、バックエンドからリモートホストでのアクションを実行できるようになります。そのためには、リモートホストで SSH サーバーが実行されている必要があります。また、インストーラを実行するシステムユーザーがユーザー名とパスワードまたは公開鍵と秘密鍵を使用してリモートサーバーにアクセスできる必要があります。

    重要

    システムの root アカウントは安全性がきわめて低いため、リモートアクセスには決して使用しないでください。また、mysqld はシステムの root によって正常に起動できません。これらの理由やその他の理由から、システムの root ではく、ターゲットシステム上の通常のユーザーアカウントの SSH 資格証明を提供してください。この問題の詳細は、セクション6.1.5「MySQL を通常ユーザーとして実行する方法」を参照してください。

  • HTTPS  Web ブラウザのフロントエンドとバックエンド間のリモート通信は、デフォルトでは暗号化されません。これは、ユーザーの SSH パスワードなどの情報がすべてのユーザーに判読可能な平文で転送されることを意味します。リモートクライアントからの通信を暗号化するには、バックエンドに証明書を用意し、フロントエンドが HTTP ではなく HTTPS を使用してバックエンドと通信する必要があります。HTTPS を有効にするには、自己署名証明書を発行するのがもっとも簡単です。証明書を発行したあとは、それが使用されていることを確認する必要があります。これを行うには、コマンド行から --use-https および --cert-file オプションを指定して ndb_setup.py コマンドを起動します。

  • 証明書ベースの認証  バックエンドの ndb_setup.py プロセスは、ローカルホストだけでなくリモートホストに対してもコマンドを実行できます。これは、バックエンドに接続した任意のユーザーがコマンドの実行方法を管理できることを意味します。バックエンドへの不要な接続を拒否するには、クライアントを認証するための証明書が必要です。この場合は、証明書がユーザーによって発行され、ブラウザにインストールされ、バックエンドで認証に使用できるようになっている必要があります。この要件を (パスワードまたは鍵による認証と組み合わせて、またはその代わりに) 設定するには、--ca-certs-file オプションを指定して ndb_setup.py を起動します。

クライアントブラウザを Auto-Installer のバックエンドと同じホストで実行する場合は、セキュアな認証の必要性または要件はありません。

MySQL のより一般的なセキュリティー情報については、セクション18.5.11「MySQL Cluster のセキュリティー上の問題」(MySQL Cluster を配備するときに考慮に入れるセキュリティーの検討事項について説明しています) および第6章「セキュリティーも参照してください。

18.2.1.2 MySQL Cluster Auto-Installer の概要

MySQL Cluster Auto-Installer は 2 つのコンポーネントで構成されます。フロントエンドは、Firefox や Microsoft Internet Explorer などの標準的な Web ブラウザ内でロードおよび実行される Web ページとして実装された GUI クライアントです (セクション18.2.1.1「MySQL Cluster Auto-Installer の要件」を参照してください)。バックエンドは、ローカルマシンまたはユーザーがアクセスできる別のホストで実行されるサーバープロセス (ndb_setup.py) です。

これら 2 つのコンポーネント (クライアントとサーバー) は、標準の HTTP 要求および応答を使用して相互に通信します。バックエンドでは、バックエンドのユーザーがアクセスを許可された任意のホスト上の MySQL Cluster ソフトウェアプログラムを管理できます。MySQL Cluster ソフトウェアが別のホスト上にある場合、バックエンドは SSH を利用してアクセスし、Paramiko ライブラリを使用してリモートでコマンドを実行します (セクション18.2.1.1「MySQL Cluster Auto-Installer の要件」を参照してください)。

このセクションの残りの部分では、主に Web クライアントについて説明します。コマンド行ツールの使用方法の詳細は、セクション18.4.23「ndb_setup.py — MySQL Cluster のブラウザベース自動インストーラの開始」を参照してください。

MySQL Cluster Auto-Installer のインタフェース このセクションでは、MySQL Cluster Auto-Installer のレイアウトとナビゲーションについて説明します。Auto-Installer を Web ブラウザで最初に開くと、ここに示すような「ようこそ」画面が表示されます。

MySQL Cluster Auto-Installer の「ようこそ」画面。

インストーラの UI にアクセスするには、「Create New MySQL Cluster」または「Continue Previous Cluster Configuration」のいずれかのオプションを選択します。Auto-Installer の一般的な画面には、次の要素が含まれています。

  1. 表示パネル  構成設定に関するデータとそれらを変更するためのコントロールが表示される中央の領域です。

  2. ブレッドクラムナビゲーション  GUI の左上および中央上部にあるブレッドクラムナビゲーションバーは、MySQL Cluster の構成の各ステップに対応する画面にリンクする一連のタイトルで構成されます。ブレッドクラムを使用すると、これらの段階の間を任意の順序でジャンプできます。

  3. 順次ナビゲーション  これは、「Previous」「Next」、および「Finished」というラベルが付いた一連のボタンで構成され、GUI の右下隅にあります。順次ナビゲーションは、指示された順序でステップ間を移動するために使用します。

  4. 「設定」および「ヘルプ」メニュー  これらのメニューは、GUI の右上隅 (ブレッドクラムナビゲーションバーの右側) にあります。「設定」では、Auto-Installer の構成設定を確認 (場合によっては変更) できます。「ヘルプ」は、インストーラの組み込みヘルプファイルにアクセスするために使用できます。

この図は、前述の各要素の場所を Auto-Installer の一般的なページで示したものです。図に重ね合わせた番号は、前のリストの番号に対応しています。

MySQL Cluster Auto-Installer GUI のレイアウト

このセクションの残りの部分では、表示パネルを除くすべての要素について詳しく説明します。セクション18.2.1.3「MySQL Cluster Auto-Installer の使用」では、表示領域に表示されるパネルについて、各パネルの機能とそこに含まれるコントロールとともに説明します。

任意および順次ナビゲーション  Auto-Installer には、MySQL Cluster 配備のセットアップと構成の異なる段階をカバーするページのいずれかが表示されます。ページ間を移動するには、次の 2 つの方法のいずれかを使用します。1 つ目は、さまざまなページのタイトルを表示するブレッドクラムトレイルナビゲーションツールバーです (現在のページのタイトルは強調表示され、無効になっています)。この中から目的のページのタイトルを選択すると、任意のページに任意の順序で移動できます。このツールバーを次に示します。

ページのタイトル (リンク) を表示する MySQL Cluster Auto-Installer のブレッドクラムナビゲーションの詳細

Auto-Installer に用意されている 2 つ目のナビゲーションメカニズムは、ページの右下にある順次ナビゲーションボタン「Next」「Previous」、および「Finish」で構成されます。これを使用すると、特定の順序で次または前のページに移動したり、最後のページに移動したりできます。このボタンは必要に応じて有効および無効にして、最後のページをとばして進めないようにしたりできます。

「設定」および「ヘルプ」メニュー  これらのメニューは、このセクションの冒頭で説明したように、GUI の右上隅に並んで配置されています。「設定」メニューの詳細を次に示します。

MySQL Cluster Auto-Installer の「設定」メニューの詳細。

次のリストでは、「設定」メニューのエントリについて説明します。

  • 「Clear configuration and restart」: すべてのホストおよびプロセスを削除し、すべてのパラメータ値をデフォルトに戻し、インストーラを最初のページからやり直します。

  • 「Automatically save configuration as cookies」: 構成情報 (ホスト名、プロセスデータ、パラメータ値など) をブラウザの Cookie として保存します。このオプションを選択すると、SSH パスワードを除くすべての情報が保存されます。つまり、ブラウザを終了して再起動したときに、前のセッションと同じ構成作業を最後に中止したポイントから続行できます。

    SSH パスワードは保存されないため、使用している場合は、新しいセッションの開始時にもう一度入力する必要があります。

  • 「Show advanced configuration options」: Auto-Installer に高度な構成パラメータを表示し、ユーザーが設定できるようにします。

    高度なパラメータは、一度設定すると、明示的に変更またはリセットするまで構成ファイル内で使用され続けます。これは、高度なパラメータが現在インストーラに表示されているかどうかは関係ありません。メニュー項目を無効にしても、パラメータの値はリセットされません。

  • 「Automatically get resource information for new hosts」: 新しいホストのハードウェアリソース情報を自動的にクエリーして、構成オプションおよび値を事前に移入します。この場合、提案された値は必須ではありませんが、インストーラの対応する編集オプションを使用して明示的に変更しないかぎり、その値が使用されます。

インストーラのナビゲーション要素と同様に、ユーザーがそれまでに行なった選択に応じて、「設定」メニューの 1 つ以上のエントリが無効になることがあります。

展開時の「ヘルプ」メニューを次に示します。

MySQL Cluster Auto-Installer の展開された「ヘルプ」メニュー。

「ヘルプ」メニューには、次のリストで説明する複数のオプションがあります。

  • 「Content」: 組み込みのユーザーガイドを表示します。これは、別のブラウザウィンドウで開くため、ワークフローを中断せずにインストーラと同時に使用できます。

  • 「現在のページ」: 組み込みのユーザーガイドの、インストーラに現在表示されているページについて説明するセクションを開きます。

  • 「この製品について」: ここに示すように、インストーラの名前とこのインストーラが提供される MySQL Cluster 配布のバージョン番号が表示された小さいダイアログを表示します。

    MySQL Cluster Auto-Installer の「この製品について」ダイアログ。

Auto-Installer では、ほとんどの入力ウィジェットでツールチップ形式のコンテキスト依存ヘルプも提供されます。これらのツールチップの 1 つは、ウィジェットやウィジェットラベルの横に表示されることがある小さい疑問符にマウスを合わせたときに表示されます。

また、MySQL Cluster の構成パラメータの名前は MySQL Cluster のオンラインドキュメント内の対応する説明にリンクされているため、特定のパラメータの名前をクリックすると、そのパラメータのドキュメントが別のウィンドウに表示されます。

18.2.1.3 MySQL Cluster Auto-Installer の使用

MySQL Cluster Auto-Installer は複数のページで構成され、各ページは MySQL Cluster を構成して配備するために使用されるプロセス内のステップに対応しています。各ページについて次に示します。

  • 「ようこそ」: 新しい MySQL Cluster の構成または既存の MySQL Cluster 構成の続行のいずれかを選択して、Auto-Installer の使用を開始します。

  • 「Define Cluster」: クラスタ全体の基本的な情報 (名前、ホスト、負荷タイプなど) を設定します。ここでは、必要に応じてリモートホストへのアクセスに使用する SSH 認証のタイプを設定することもできます。

  • 「Define Hosts」: MySQL Cluster プロセスを実行するホストを特定します。

  • 「Define Processes」: 各クラスタホストに特定のタイプのプロセスを 1 つ以上割り当てます。

  • 「Define Attributes」: プロセスまたはプロセスタイプの構成属性を設定します。

  • 「Deploy Cluster」: 前に設定された構成でクラスタを配備します。また、配備されたクラスタを開始および停止します。

次のセクションでは、これらの各ページの目的と機能について、リストに示した順に詳しく説明します。

18.2.1.3.1 MySQL Cluster Auto-Installer の起動

Auto-Installer は、MySQL Cluster ソフトウェアとともに提供されます。(セクション18.2「MySQL Cluster のインストール」を参照してください。)このセクションでは、インストーラの起動方法について説明します。起動するには、ndb_setup.py 実行可能ファイルを起動します。ndb_setup.py は、MySQL Cluster インストールディレクトリ内の bin にあります。一般的な場所は、Linux システムでは /usr/local/mysql/bin、Windows システムでは C:\Program Files\MySQL\MySQL Server 5.6\bin ですが、これは MySQL Cluster ソフトウェアをインストールしたシステム上の場所によって異なる可能性があります。

Windows では、MySQL Cluster インストールディレクトリ内の setup.bat を実行してインストーラを起動することもできます。コマンド行から起動するときは、ndb_setup.py と同じオプションを指定できます。

ndb_setup.py は、その動作に影響を与える複数のオプションを指定して起動できますが、通常はデフォルト設定を使用するだけで十分です。その場合は、次の 2 つの方法で ndb_setup.py を起動できます。

  1. 端末で MySQL Cluster の bin ディレクトリに移動し、このようにコマンド行から引数やオプションを追加せずに起動します。

    shell> ndb_setup

    これは、オペレーティングシステムに関係なく有効です。

  2. ファイルブラウザ (Windows の Windows Explorer、Linux の Konqueror、Dolphin、Nautilus など) で MySQL Cluster の bin ディレクトリに移動し、ndb_setup.py ファイルアイコンを (通常はダブルクリックによって) アクティブ化します。これは Windows で有効ですが、ほとんどの一般的な Linux デスクトップでも有効です。

    Windows では、MySQL Cluster インストールディレクトリに移動して、setup.bat ファイルアイコンをアクティブ化することもできます。

どちらの場合も、ndb_setup.py を起動すると、システムのデフォルトの Web ブラウザで Auto-Installer の「ようこそ」画面が開きます。

場合によっては、Auto-Installer に含まれている Web サーバーの実行用として異なるポートを指定するなど、インストーラのデフォルト以外の設定を使用する必要があります。その場合は、必要なデフォルトをオーバーライドする値を含む起動オプションを指定して ndb_setup.py を起動する必要があります。Windows システムで同じ起動オプションを使用するには、MySQL Cluster ソフトウェア配布でそのようなプラットフォーム用に提供されている setup.bat ファイルを使用します。これはコマンド行を使用して実行できますが、これらのオプションを 1 つ以上使用しながらデスクトップまたはファイルブラウザからインストーラを起動する必要がある場合は、適切な起動を含むスクリプトまたはバッチファイルを作成し、ファイルブラウザでそのファイルアイコンをダブルクリックしてインストーラを起動することもできます。(Linux システムでは、最初にスクリプトファイルを実行可能にする必要もあります。)MySQL Cluster Auto-Installer の高度な起動オプションについては、セクション18.4.23「ndb_setup.py — MySQL Cluster のブラウザベース自動インストーラの開始」を参照してください。

18.2.1.3.2 MySQL Cluster Auto-Installer の「ようこそ」画面

「ようこそ」画面は、ここに示すように、ndb_setup.py を起動したときにデフォルトのブラウザにロードされます。

MySQL Cluster Auto-Installer の「ようこそ」画面。

この画面には、インストーラに入るための選択肢として次の 2 つが表示されます。続行するには、そのいずれかを選択する必要があります。

  1. 「Create New MySQL Cluster」: 完全に新しいクラスタをセットアップして配備するために Auto-Installer を起動します。

  2. 「Continue Previous Cluster Configuration」: 前のセッションが終了した同じポイントから、前の設定をすべて保持した状態で Auto-Installer を起動します。

2 つ目のオプションでは、ブラウザが前のセッションの Cookie にアクセスできる必要があります。これらの Cookie は、セッション中に生成された構成やその他の情報を格納するメカニズムとして使用されています。つまり、Auto-Installer で前のセッションを続行するには、前のセッションと同じホストで実行される同じブラウザを使用する必要があります。

18.2.1.3.3 MySQL Cluster Auto-Installer の「Define Cluster」画面

「Define Cluster」画面は、「ようこそ」画面での選択に続いて表示される最初の画面で、クラスタの一般的なプロパティーを設定するために使用されます。「Define Cluster」画面のレイアウトを次に示します。

MySQL Cluster Auto-Installer の「Define Cluster」画面。

「Define Cluster」画面では、このリストで説明するクラスタの一般的なプロパティーを設定できます。

  • 「Cluster name」: クラスタを識別する名前。デフォルトは MyCluster です。

  • 「Host list」: クラスタプロセスを実行する 1 台以上のホストのカンマ区切りリスト。デフォルトでは、これは 127.0.0.1 です。このリストにリモートホストを追加した場合は、指定した「SSH Credentials」を使用して接続できる必要があります。

  • 「Application type」: 次のいずれかを選択します。

    1. 「Simple testing」: 小規模なテストに対応する最小限のリソース使用。これはデフォルトです。本番環境を目的にしたものではありません

    2. 「Web」: 特定のハードウェアに合わせてパフォーマンスを最大化します。

    3. 「Real-time」: 障害の発生したクラスタプロセスの検出にかかる時間を最小限に抑えるため、タイムアウトへの感度を最大限にしながらパフォーマンスを最大化します。

  • 「Write load」: クラスタ全体で予測される書き込み数のレベルを選択します。次のいずれかのレベルを選択できます。

    1. 「Low」: 予想される負荷に、1 秒あたり 100 件未満の書き込みトランザクションが含まれます。

    2. 「Medium」: 予想される負荷に、1 秒あたり 100-1000 件の書き込みトランザクションが含まれます。

    3. 「High」: 予想される負荷に、1 秒あたり 1000 件を超える書き込みトランザクションが含まれます。

  • 「SSH Credentials」: 「Key-Based SSH」を選択するか、「User」および「Password」資格証明を入力します。この SSH 鍵またはユーザー名とパスワードは、「Host list」に指定したリモートホストに接続するときに必要になります。デフォルトでは、「Key-Based SSH」が選択され、「User」および「Password」フィールドは空になっています。

18.2.1.3.4 MySQL Cluster Auto-Installer の「Define Hosts」画面

ここに示す「Define Hosts」画面では、各クラスタホストのいくつかの主要なプロパティーを表示および指定できます。

MySQL Cluster の「Define Hosts」画面。

現在入力されているホストが各種の情報とともにグリッドに表示されます。ホストを追加するには、「Add hosts」ボタンをクリックし、(「Define Cluster」画面のホストリストを編集するときと同じように) カンマで区切られた 1 つ以上のホスト名、IP アドレス、またはその両方のリストを入力します。

同様に、「Remove selected host(s)」というラベルのボタンを使用して 1 台以上のホストを削除できます。この方法でホストを削除すると、そのホストに構成されたプロセスもすべて削除されます。

「設定」メニュー「Automatically get resource information for new hosts」にチェックマークを付けると、Auto-Installer はプラットフォーム名、メモリーの量、および CPU コアの数を取得して、それらを自動的に設定しようとします。このステータスは「Resource info」カラムに表示されます。リモートホストからの情報は即座にフェッチできず、特に Windows を実行しているホストからは、ある程度時間がかかることがあります。

「Define Cluster」画面の SSH ユーザー資格情報を変更すると、このツールは情報が欠落しているホストのハードウェア情報をリフレッシュしようとします。ただし、特定のフィールドがすでに編集されている場合、ユーザーが指定した情報がホストからフェッチされた値で上書きされることはありません

ハードウェアリソース情報、プラットフォーム名、インストールディレクトリ、およびデータディレクトリは、ユーザーがグリッド内の対応するセルをクリックし、1 台以上のホストを選択し、「Edit selected host(s)」というラベルのボタンをクリックすると編集できます。これにより、ここに示すように、これらのフィールドを編集できるダイアログボックスが表示されます。

MySQL Cluster Auto-Installer の「Edit Hosts(s)」ダイアログ。

複数のホストを選択すると、編集した値が選択したすべてのホストに適用されます。

18.2.1.3.5 MySQL Cluster Auto-Installer の「Define Processes」画面

ここに示す「Define Processes」画面では、MySQL Cluster プロセス (ノード) をクラスタホストに割り当てることができます。

MySQL Cluster Auto-Installer の「Define Processes」画面。

この画面の左側には、クラスタホストと各ホストで実行するように設定されたプロセスを示すツリーが含まれています。右側には、ツリーで現在選択されている項目に関する情報を表示するパネルがあります。

特定のクラスタでこの画面に最初にアクセスすると、ホストの数に基づいてデフォルトのプロセスセットが自動的に定義されます。その後「Define Hosts」画面に戻り、すべてのホストを削除して新しいホストを追加した場合も、新しいデフォルトのプロセスセットが定義されます。

MySQL Cluster プロセスには次のタイプがあります。

  • 管理ノード  個々のデータノードの停止、ノードやクラスタのステータスのクエリー、バックアップの作成などの管理タスクを実行します。実行可能ファイル: ndb_mgmd

  • シングルスレッドのデータノード  データを格納し、クエリーを実行します。実行可能ファイル: ndbd

  • マルチスレッドのデータノード  並列で実行される複数のワーカースレッドによってデータを格納し、クエリーを実行します。実行可能ファイル: ndbmtd

  • SQL ノード NDB に対して SQL クエリーを実行するための MySQL サーバー。実行可能ファイル: mysqld

  • API ノード  SQL を使用せずに、NDB API またはその他の低レベルのクライアント API を使用して NDB 内のデータにアクセスするクライアント。詳細は、MySQL NDB Cluster API Developer Guideを参照してください。

プロセス (ノード) タイプの詳細は、セクション18.1.1「MySQL Cluster の主な概念」を参照してください。

ツリーに表示されるプロセスには、簡単に識別できるように (たとえば、SQL node 1SQL node 2 のように) ホストごとにタイプ別の連番が付けられています。

個々の管理ノード、データノード、または SQL プロセスは、特定のホストに割り当てる必要があり、ほかのホストでは実行できません。API ノードは 1 台のホストに割り当てることもできますが、これは必須ではありません。代わりに、ほかのホストとは別にツリー内に表示される「Any host」エントリに別途割り当てることができます。このエントリは、任意のホストで実行できるプロセスのプレースホルダとして機能します。この「Any host」エントリを使用できるのは API プロセスだけです

プロセスの追加 特定のホストに新しいプロセスを追加するには、ツリー内のそのホストのエントリを右クリックし、表示された「Add process」ポップアップを選択するか、プロセスツリー内のホストを選択して、プロセスツリーの下にある「Add process」ボタンをクリックします。これらのアクションのどちらを実行した場合も、ここに示すようなプロセス追加ダイアログが開きます。

MySQL Cluster Auto-Installer の「Define Processes」画面で新しいクラスタプロセスを追加するために使用されるダイアログ。

ここでは、このセクションで前述した利用可能なプロセスタイプを選択できます。必要に応じて、提案された値の代わりに任意のプロセス名を入力することもできます。

プロセスの削除 プロセスを削除するには、ツリー内のプロセスを右クリックし、表示されるポップアップメニューから「delete process」を選択します。または、プロセスを選択して、プロセスツリーの下にある「delete process」ボタンを使用します。

プロセスツリー内のプロセスを選択すると、そのプロセスに関する情報がツリーの右側のパネルに表示され、ここでプロセス名 (場合によってはプロセスタイプ) を変更できます。重要: 現在のところ、シングルスレッドデータノード (ndbd) をマルチスレッドデータノード (ndbmtd) に (またはその逆に) 変更できます。ほかのプロセスタイプには変更できません。ほかのプロセスタイプ間で変更する場合は、最初に元のプロセスを削除し、次に目的のタイプの新しいプロセスを追加する必要があります。

18.2.1.3.6 MySQL Cluster Auto-Installer の「Define Attributes」画面

この画面のレイアウトは「Define Processes」画面とほぼ同じで、左側にプロセスツリーが表示されます。その画面のツリーとは異なり、「Define Attributes」プロセスツリーはプロセスまたはノードのタイプで分類され (この場合、シングルスレッドおよびマルチスレッドデータノードは同じタイプとみなされます)、各グループに「Management Layer」「Data Layer」「SQL Layer」、および「API Layer」というラベルが付けられています。このツリーの右側のパネルには、現在選択されている項目に関する情報が表示されます。「Define Attributes」画面をここに示します。

MySQL Cluster Auto-Installer の「Define Attributes」画面。

プロセスツリーの下に「Show advanced configuration」というラベルのチェックボックスがあります。このボックスにチェックマークを付けると、情報ペインに高度なオプションが表示されます。これらのオプションは、表示されているかどうかに関係なく設定および使用されます。

1 つのプロセスの属性を編集するには、ツリーからそのプロセスを選択します。クラスタに含まれる同じタイプのプロセスすべての属性を編集するには、いずれかの「Layer」フォルダを選択します。プロセス単位で設定された特定の属性の値は、該当するプロセスに以前に適用されていた属性のグループ単位の設定をオーバーライドします。このような情報パネルの例 (SQL プロセスの場合) をここに示します。

ツリー内で選択した SQL プロセスの属性が情報パネルに表示された「Define Attributes」プロセス

情報パネルに表示された属性の一部については、その右側に、この属性の値をオーバーライドできることを示すプラス記号が付いたボタンが表示されます。この + ボタンをクリックすると、属性の入力ウィジェットがアクティブ化され、属性の値を変更できるようになります。値がオーバーライドされている場合は、ここに示すように、このボタンが X を示すボタンに変更されます。

X ボタンで示されるように、SQL プロセス属性のデフォルト値がオーバーライドされています。

属性の横にある X ボタンをクリックすると、その属性に対する変更が取り消され、ただちに事前定義値に戻ります。

すべての構成属性には、インストーラがホスト名、ノード ID、ノードタイプなどの要因に基づいて計算した事前定義値があります。ほとんどの場合、これらの値はそのままにしておくことができます。これらの操作をまだ習熟していない場合は、属性値を変更する前に該当するドキュメントを読むことを強くお勧めします。この情報を見つけやすくするため、情報パネルに表示される個々の属性名は、MySQL Cluster のオンラインドキュメント内の対応する説明にリンクされています。

18.2.1.3.7 MySQL Cluster Auto-Installer の「Deploy Cluster」画面

この画面では、次のタスクを実行できます。

  • 適用されるプロセス起動コマンドと構成ファイルを確認します

  • すべてのクラスタホストで必要なファイルおよびディレクトリを作成して、構成ファイルを配布します (つまり、現在の構成に従ってクラスタを配備します)

  • クラスタを起動および停止します

「Deploy Cluster」画面をここに示します。

MySQL Cluster Auto-Installer の「Deploy Cluster」画面。

「Define Attributes」画面と同じように、この画面の左側にはプロセスタイプで分類されたプロセスツリーが表示されます。各プロセスの横には、プロセスの現在のステータスを色で示すステータスアイコン (実行中の場合は緑、起動または停止中の場合は黄、プロセスが停止している場合は赤) が表示されます。

プロセスツリーの右側には、2 つの情報パネルが表示されます。上側のパネルには起動コマンド (選択したプロセスを起動するのに必要なコマンド) が表示されます。(プロセスによっては、初期化が必要な場合など、複数のコマンドが必要な場合があります。)下側のパネルには、指定したプロセスの構成ファイル (あれば) の内容が表示されます。現在のところ、構成ファイルがあるプロセスタイプは管理ノードプロセスだけです。ほかのプロセスタイプは、プロセスの起動時にコマンド行パラメータを使用して、または必要に応じて管理ノードからリアルタイムで構成情報を取得して構成されます。

プロセスツリーのすぐ下には、3 つのボタンがあります。これらは、次のリストで説明する機能を実行し、各機能を示すラベルが付いています。

  • 「Deploy cluster」: 構成が有効かどうか検証します。クラスタホスト上に必要なディレクトリを作成し、各ホストに構成ファイルを配布します。進行状況バーに、配備の進行状況が表示されます。

  • 「Start cluster」: 「Deploy cluster」と同様にクラスタを配備し、その後、すべてのクラスタプロセスを正しい順序で起動します。

    これらのプロセスの起動には、ある程度時間がかかることがあります。完了までの推定時間が長すぎる場合は、起動プロセスを取り消しまたは続行できます。ここに示すように、進行状況バーに起動手順の現在のステータスが示されます。

    画像について説明するテキスト。

    前述したプロセスツリーの横にあるプロセスステータスアイコンも、各プロセスのステータスに合わせて更新されます。

  • 「Stop cluster」: クラスタを起動したあとは、これを使用して停止できます。クラスタの起動と同様に、クラスタは瞬時にシャットダウンされず、ある程度時間がかかることがあります。クラスタの起動時に表示されるのと同様の進行状況バーが表示され、プロセスツリーの横にあるプロセスステータスアイコンと同じように、クラスタのシャットダウン手順の現在の大まかなステータスが示されます。

MySQL Cluster NDB 7.3.3 より前のバージョンでは、SQL ノードはコマンド行で指定されたすべてのオプションを使用して起動されました。MySQL Cluster NDB 7.3.3 以降では、Auto-Installer によってクラスタ内の各 mysqld プロセスに適したオプションを含む my.cnf ファイルが生成されます。(Bug #16994782)

18.2.2 Linux での MySQL Cluster のインストール

このセクションでは、Linux およびその他の Unix 系オペレーティングシステムでの MySQL Cluster のインストール方法について説明します。次のセクションでは Linux オペレーティングシステムについて言及しますが、記載されている指示と手順は、サポートされるほかの Unix 系プラットフォームにも簡単に適用できます。Windows システムに固有の手動のインストールおよびセットアップ手順については、セクション18.2.3「Windows での MySQL Cluster のインストール」を参照してください。

個々の MySQL Cluster ホストコンピュータに適切な実行可能プログラムがインストールされている必要があります。SQL ノードを実行するホストには、MySQL Server バイナリ (mysqld) がインストールされている必要があります。管理ノードには、管理サーバーデーモン (ndb_mgmd) が必要です。データノードには、データノードデーモン (ndbd または ndbmtd) が必要です。管理ノードホストおよびデータノードホストに MySQL Server バイナリをインストールする必要はありません。管理サーバーホストには管理クライアント (ndb_mgm) もインストールすることをお勧めします。

Linux での MySQL Cluster のインストールは、オラクルが提供する事前コンパイル済みバイナリ (.tar.gz アーカイブとしてダウンロード) を使用するか、RPM パッケージ (これもオラクルから入手可能) を使用するか、ソースコードから実行できます。次のセクションでは、これら 3 つのすべてのインストール方法について説明します。

使用する方法に関係なく、クラスタを起動する前に、MySQL Cluster バイナリのインストールに続いてすべてのクラスタノードの構成ファイルを作成する必要もあります。セクション18.2.4「MySQL Cluster の初期構成」を参照してください。

18.2.2.1 Linux での MySQL Cluster バイナリリリースのインストール

このセクションでは、オラクルが提供する事前コンパイル済みバイナリからクラスタノードの各タイプに対応する適切な実行可能ファイルをインストールするために必要なステップについて説明します。

事前コンパイル済みバイナリを使用してクラスタをセットアップする場合は、各クラスタホストのインストールプロセスの最初のステップとして、MySQL Cluster ダウンロード領域から最新の MySQL Cluster NDB 7.3 以降のバイナリアーカイブ (mysql-cluster-gpl-7.3.9-linux-i686-glibc23.tar.gz または mysql-cluster-gpl-7.4.4-linux-i686-glibc23.tar.gz) をダウンロードします。ここでは、このファイルが各マシンの /var/tmp ディレクトリに配置されていると仮定します。(カスタムバイナリが必要な場合は、セクション2.9.3「開発ソースツリーを使用して MySQL をインストールする」を参照してください。)

注記

インストールが完了しても、バイナリはまだ起動しないでください。ノードの構成に続いてその実行方法を示します (セクション18.2.4「MySQL Cluster の初期構成」を参照してください)。

SQL ノード  SQL ノードのホストとして指定された各マシンで、システムの root ユーザーとして次のステップを実行します。

  1. /etc/passwd および /etc/group ファイルを調べて (または、オペレーティングシステムが提供する何らかのユーザーおよびグループ管理ツールを使用して)、システムに mysql グループと mysql ユーザーがすでに存在しているかどうかを確認します。一部の OS 配布では、オペレーティングシステムのインストールプロセスの一部としてこれらが作成されます。まだ存在しない場合は、mysql ユーザーグループを新規作成し、このグループに mysql ユーザーを追加します。

    shell> groupadd mysqlshell> useradd -g mysql mysql

    useradd および groupadd の構文は、Unix のバージョンによって多少異なる場合があり、また adduser および addgroup などの別な名前を使用している場合もあります。

  2. ダウンロードしたファイルを含むディレクトリに移動し、アーカイブを解凍して、mysql という名前で mysql ディレクトリへのシンボリックリンクを作成します。実際のファイルおよびディレクトリ名は、MySQL Cluster のバージョン番号によって異なります。

    shell> cd /var/tmpshell> tar -C /usr/local -xzvf mysql-cluster-gpl-7.4.4-linux2.6.tar.gzshell> ln -s /usr/local/mysql-cluster-gpl-7.4.4-linux2.6-i686 /usr/local/mysql
  3. mysql ディレクトリに移動し、システムデータベースを作成するための付属のスクリプトを実行します。

    shell> cd mysqlshell> scripts/mysql_install_db --user=mysql
  4. MySQL サーバーおよびデータディレクトリで必要なアクセス許可を設定します。

    shell> chown -R root .shell> chown -R mysql datashell> chgrp -R mysql .
  5. MySQL 起動スクリプトを適切なディレクトリにコピーし、実行可能にして、オペレーティングシステムがブートしたときに起動するように設定します。

    shell> cp support-files/mysql.server /etc/rc.d/init.d/shell> chmod +x /etc/rc.d/init.d/mysql.servershell> chkconfig --add mysql.server

    (起動スクリプトのディレクトリは、オペレーティングシステムとバージョンによって異なります。たとえば、一部の Linux 配布では /etc/init.d です。)

    ここでは、起動スクリプトへのリンクを作成するために Red Hat の chkconfig を使用します。使用しているプラットフォームのこの目的に適した何らかの手段 (Debian の update-rc.d など) を使用してください。

前述の各ステップは、SQL ノードを配置するマシンごとに繰り返す必要があります。

データノード  データノードのインストールには、mysqld バイナリは必要ありません。MySQL Cluster のデータノード実行可能ファイル ndbd (シングルスレッド) または ndbmtd (マルチスレッド) のみが必要です。これらのバイナリも、.tar.gz アーカイブに含まれています。ここでも、このアーカイブが /var/tmp に配置されていると仮定します。

システムの root として (つまり、sudosu root、または使用しているシステムでシステム管理者アカウントの特権を一時的に持つための同等のコマンドを使用したあとで)、次のステップを実行してデータノードホストにデータノードバイナリをインストールします。

  1. /var/tmp ディレクトリに移動し、アーカイブに含まれる ndbd および ndbmtd バイナリを /usr/local/bin などの適切なディレクトリに抽出します。

    shell> cd /var/tmpshell> tar -zxvf mysql-5.6.22-ndb-7.4.4-linux-i686-glibc23.tar.gzshell> cd mysql-5.6.22-ndb-7.4.4-linux-i686-glibc23shell> cp bin/ndbd /usr/local/bin/ndbdshell> cp bin/ndbmtd /usr/local/bin/ndbmtd

    (ndb_mgm および ndb_mgmd を実行可能ファイルのディレクトリにコピーしたあとは、ダウンロードしたアーカイブを解凍したときに作成されたディレクトリ (およびディレクトリ内のファイル) を /var/tmp から安全に削除できます。)

  2. ファイルをコピーしたディレクトリに移動して、両方のファイルを実行可能にします。

    shell> cd /usr/local/binshell> chmod +x ndb*

前述のステップは、データノードホストごとに繰り返してください。

MySQL Cluster データノードを実行するために必要なのはいずれかのデータノード実行可能ファイルだけですが、前の説明では ndbdndbmtd の両方のインストール方法を示しました。MySQL Cluster をインストールまたはアップグレードするときは、どちらか一方のみを使用する予定であっても、あとでもう一方に変更する場合の時間と問題が減るため、このようにすることをお勧めします。

注記

データノードをホストする各マシン上のデータディレクトリは /usr/local/mysql/data です。この情報は、管理ノードを構成するときに重要になります。(セクション18.2.4「MySQL Cluster の初期構成」を参照してください。)

管理ノード  管理ノードのインストールには、mysqld バイナリは必要ありません。MySQL Cluster の管理サーバー (ndb_mgmd) のみが必要です。ほとんどの場合、管理クライアント (ndb_mgm) もインストールする必要があります。これらのバイナリは、どちらも .tar.gz アーカイブに含まれています。ここでも、このアーカイブが /var/tmp に配置されていると仮定します。

システムの root として、次のステップを実行して管理ノードホストに ndb_mgmd および ndb_mgm をインストールします。

  1. /var/tmp ディレクトリに移動し、アーカイブに含まれる ndb_mgm および ndb_mgmd/usr/local/bin などの適切なディレクトリに抽出します。

    shell> cd /var/tmpshell> tar -zxvf mysql-5.6.22-ndb-7.4.4-linux2.6-i686.tar.gzshell> cd mysql-5.6.22-ndb-7.4.4-linux2.6-i686shell> cp bin/ndb_mgm* /usr/local/bin

    (ndb_mgm および ndb_mgmd を実行可能ファイルのディレクトリにコピーしたあとは、ダウンロードしたアーカイブを解凍したときに作成されたディレクトリ (およびディレクトリ内のファイル) を /var/tmp から安全に削除できます。)

  2. ファイルをコピーしたディレクトリに移動して、両方のファイルを実行可能にします。

    shell> cd /usr/local/binshell> chmod +x ndb_mgm*

セクション18.2.4「MySQL Cluster の初期構成」では、この例の MySQL Cluster に含まれるすべてのノード用の構成ファイルを作成しています。

18.2.2.2 RPM からの MySQL Cluster のインストール

このセクションでは、オラクルが提供する RPM パッケージを使用して MySQL Cluster ノードの各タイプに対応する適切な実行可能ファイルをインストールするために必要なステップについて説明します。

RPM は、32 ビットと 64 ビットの両方の Linux プラットフォームで使用できます。これらの RPM のファイル名には、次のパターンが使用されています。

MySQL-Cluster-component-producttype-ndbversion.distribution.architecture.rpmcomponent:= {server | client [| other]}producttype:= {gpl | advanced}ndbversion:= major.minor.releasedistribution:= {sles10 | rhel5 | el6}architecture:= {i386 | x86_64}

component は、server または client です。(ほかの値になる可能性もありますが、MySQL Cluster の正常なインストールには server および client コンポーネントのみが必要であるため、ここでは説明しません。)https://dev.mysql.com/downloads/cluster/ からダウンロードした Community RPM の producttype は常に gpl です。advanced は商用リリースを示すために使用されます。ndbversion は、3 つの部分から成る (7.3.x または 7.4.x 形式の) NDB ストレージエンジンのバージョン番号を表します。distribution は、sles11 (SUSE Enterprise Linux 11)、rhel5 (Oracle Linux 5、Red Hat Enterprise Linux 4 および 5)、el6 (Oracle Linux 6、Red Hat Enterprise Linux 6) のいずれかです。architecture は、32 ビット RPM の場合は i386、64 ビットバージョンの場合は x86_64 です。

MySQL Cluster では、1 つ (場合によっては 2 つ) の RPM が必要です。

  • NDBCLUSTER ストレージエンジンのサポート付きで (つまり、MySQL Cluster の SQL ノードとして) MySQL Server を実行するために必要なコアファイルと、管理ノード、データノード、および ndb_mgm クライアントのバイナリを含むすべての MySQL Cluster 実行可能ファイルを提供する server RPM (たとえば、MySQL-Cluster-server-gpl-7.3.9-1.sles11.i386.rpm または MySQL-Cluster-server-gpl-7.4.4-1.sles11.i386.rpm)。MySQL Cluster をインストールするには、常にこの RPM が必要です。

  • MySQL サーバーを管理する機能を持つ独自のクライアントアプリケーションがない場合は、mysql クライアントを提供する client RPM (たとえば、MySQL-Cluster-client-gpl-7.3.9-1.sles11.i386.rpm または MySQL-Cluster-client-gpl-7.4.4-1.sles11.i386.rpm) も入手してインストールしてください。

RPM ファイル名に含まれる MySQL Cluster のバージョン番号 (ここでは、MySQL Cluster NDB 7.3 と MySQL Cluster NDB 7.4 のどちらをインストールするかに応じて 7.3.9 または 7.4.4 として示したもの) は、実際に使用するバージョンによって異なります。インストールするすべてのクラスタ RPM のバージョン番号が同じになっていることが非常に重要ですarchitecture の指定も、RPM をインストールするマシンに適合するようにしてください。特に、32 ビットオペレーティングシステムでは 64 ビット RPM を使用できないことを留意してください。

データノード  クラスタのデータノードをホストするコンピュータには、server RPM のみをインストールする必要があります。これを行うには、この RPM をデータノードホストにコピーし、システムの root ユーザーとして次のコマンドを実行します。示された RPM の名前は、必要に応じて MySQL Web サイトからダウンロードした RPM の名前と一致するように置き換えてください。

shell> rpm -Uhv MySQL-Cluster-server-gpl-7.3.9-1.sles11.i386.rpm

または

shell> rpm -Uhv MySQL-Cluster-server-gpl-7.4.4-1.sles11.i386.rpm

これによってすべての MySQL Cluster バイナリがインストールされますが、MySQL Cluster のデータノードを実行するために実際に必要なのは ndbd または ndbmtd プログラム (どちらも /usr/sbin にあります) だけです。

SQL ノード  クラスタの SQL ノードをホストするために使用される各マシンで、システムの root ユーザーとして次のコマンドを実行して server RPM をインストールします。示された RPM の名前は、必要に応じて MySQL Web サイトからダウンロードした RPM の名前と一致するように置き換えてください。

shell> rpm -Uhv MySQL-Cluster-server-gpl-7.3.9-1.sles11.i386.rpm

または

shell> rpm -Uhv MySQL-Cluster-server-gpl-7.4.4-1.sles11.i386.rpm

これにより、NDB ストレージエンジンのサポートを含む MySQL サーバーバイナリ (mysqld) と必要なすべての MySQL Server サポートファイルが /usr/sbin ディレクトリにインストールされます。また、mysql.server および mysqld_safe 起動スクリプトも (それぞれ /usr/share/mysql および /usr/bin に) インストールされます。RPM インストーラでは、一般的な構成の問題 (必要に応じて mysql ユーザーおよびグループを作成するなど) に自動的に対応します。

SQL ノード (MySQL サーバー) を管理するには、ここに示すように client RPM もインストールするようにしてください。

shell> rpm -Uhv MySQL-Cluster-client-gpl-7.3.9-1.sles11.i386.rpm

または

shell> rpm -Uhv MySQL-Cluster-client-gpl-7.4.4-1.sles11.i386.rpm

これにより、mysql クライアントプログラムがインストールされます。

管理ノード  MySQL Cluster の管理サーバーをインストールするには、server RPM のみを使用する必要があります。この RPM を管理ノードをホストするためのコンピュータにコピーし、システムの root ユーザーとして次のコマンドを実行して、この RPM をインストールします (示された RPM の名前は、必要に応じて MySQL Web サイトからダウンロードした server RPM の名前と一致するように置き換えてください)。

shell> rpm -Uhv MySQL-Cluster-server-gpl-7.3.9-1.sles11.i386.rpm

または

shell> rpm -Uhv MySQL-Cluster-server-gpl-7.4.4-1.sles11.i386.rpm

この RPM によってほかの多くのファイルがインストールされますが、管理ノードを実行するために実際に必要なのは管理サーバーバイナリ ndb_mgmd (/usr/sbin ディレクトリにあります) だけです。server RPM によって、NDB の管理クライアントである ndb_mgm もインストールされます。

オラクルが提供する RPM を使った MySQL のインストールに関する一般的な情報は、セクション2.5.5「RPM パッケージを使用して MySQL を Linux にインストールする」を参照してください。

RPM からインストールしたあとは、セクション18.2.4「MySQL Cluster の初期構成」の説明に従ってクラスタを構成する必要もあります。

注記

MySQL Cluster NDB 7.1 で使用されていた一部の RPM は、MySQL Cluster NDB 7.3 で非推奨になり、廃止されました。これには、以前の MySQL-Cluster-clusterjMySQL-Cluster-extraMySQL-Cluster-managementMySQL-Cluster-storage、および MySQL Cluster-tools RPM が含まれます。このパッケージの以前の内容は、現在 MySQL-Cluster-server RPM に含まれています。

18.2.2.3 Linux でのソースからの MySQL Cluster のビルド

このセクションでは、Linux およびその他の Unix 系プラットフォームでの MySQL Cluster のコンパイルについて説明します。ソースからの MySQL Cluster のビルドは、標準の MySQL Server のビルドとほぼ同じですが、ここで説明するいくつかの重要な点が異なります。ソースからの MySQL のビルドに関する一般的な情報は、セクション2.9「ソースから MySQL をインストールする」を参照してください。Windows プラットフォームでの MySQL Cluster のコンパイルについては、セクション18.2.3.2「Windows でのソースからの MySQL Cluster のコンパイルとインストール」を参照してください。

MySQL Cluster をビルドするには、MySQL Cluster ソースを使用する必要があります。これらは、MySQL Cluster のダウンロードページ (https://dev.mysql.com/downloads/cluster/) から入手できます。アーカイブされたソースファイルには、mysql-cluster-gpl-7.3.9.tar.gz (MySQL Cluster NDB 7.3) や mysql-cluster-gpl-7.4.4.tar.gz (MySQL Cluster NDB 7.4) のような名前が付いています。launchpad.net から MySQL の開発ソースを入手することもできます。標準の MySQL Server 5.6 ソースからの MySQL Cluster のビルドはサポートされません

CMakeWITH_NDBCLUSTER_STORAGE_ENGINE オプションを指定すると、管理ノード、データノード、およびその他の MySQL Cluster プログラムのバイナリがビルドされます。また、これによって NDB ストレージエンジンのサポート付きで mysqld がコンパイルされます。このオプションは、MySQL Cluster NDB 7.3 以降のソースではデフォルトで有効になっています。

重要

MySQL Cluster NDB 7.3 以降では、WITH_NDB_JAVA オプションがデフォルトで有効になっています。つまり、デフォルトでは CMake でシステム上の Java の場所が見つからなかった場合に構成プロセスが失敗します。Java および ClusterJ のサポートを有効にしない場合は、-DWITH_NDB_JAVA=OFF を使用してビルドを構成することで、これを明示的に示す必要があります。必要な場合は、WITH_CLASSPATH を使用して Java クラスパスを指定します。

MySQL Cluster のビルドに固有の CMake オプションの詳細は、MySQL Cluster をコンパイルするためのオプションを参照してください。

make && make install (または使用しているシステムの同等のコマンド) を実行すると、同じ場所に事前コンパイル済みバイナリを解凍した場合と同じ結果が得られます。

管理ノード  ソースからビルドしてデフォルトの make install を実行すると、管理サーバーと管理クライアントのバイナリ (ndb_mgmdndb_mgm) が /usr/local/mysql/bin に見つかります。管理ノードホストに配置する必要があるのは ndb_mgmd だけですが、同じホストマシンに ndb_mgm も配置することをお勧めします。これらの実行可能ファイルは、どちらもホストマシンのファイルシステム上の特定の場所に配置する必要はありません。

データノード  データノードホストに配置する必要がある実行可能ファイルは、データノードバイナリ ndbd または ndbmtd だけです。(たとえば、mysqld をホストマシンに配置する必要はありません。)ソースからビルドすると、デフォルトではこのファイルは /usr/local/mysql/bin ディレクトリに配置されます。複数のデータノードホストにインストールする場合、ほかのマシンにコピーする必要があるのは ndbd または ndbmtd だけです。(これは、すべてのデータノードホストで同じアーキテクチャーとオペレーティングシステムが使用されていることが前提です。そうでない場合は、異なるプラットフォームごとに別個にコンパイルする必要がある可能性があります。)データノードバイナリは、その場所が既知であるかぎり、ホストのファイルシステム上の特定の場所に配置する必要はありません。

ソースから MySQL Cluster をコンパイルする場合、マルチスレッドのデータノードバイナリをビルドするために特別なオプションは必要ありません。NDB ストレージエンジンのサポート付きでビルドを構成すると、自動的に ndbmtd がビルドされます。make install を実行すると、ndbmtd バイナリは mysqldndbd、および ndb_mgm とともにインストールの bin ディレクトリに配置されます。

SQL ノード  クラスタリングのサポート付きで MySQL をコンパイルし、デフォルトのインストールを実行 (システムの root ユーザーとして make install を使用) すると、mysqld/usr/local/mysql/bin に配置されます。セクション2.9「ソースから MySQL をインストールする」に示したステップに従って、mysqld を使用できるようにします。複数の SQL ノードを実行する場合は、同じ mysqld 実行可能ファイルと関連するサポートファイルのコピーを複数のマシンで使用できます。これを実行するもっとも簡単な方法は、/usr/local/mysql ディレクトリ全体およびその内部に含まれているすべてのディレクトリとファイルをほかの SQL ノードホストにコピーし、各マシンでセクション2.9「ソースから MySQL をインストールする」のステップを繰り返すことです。デフォルトではない PREFIX オプションを指定してビルドを構成する場合は、それに合わせてディレクトリを調整する必要があります。

セクション18.2.4「MySQL Cluster の初期構成」では、この例の MySQL Cluster に含まれるすべてのノード用の構成ファイルを作成しています。

18.2.3 Windows での MySQL Cluster のインストール

このセクションでは、Windows ホストでの MySQL Cluster のインストール手順について説明します。Windows 用の MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4 バイナリは、https://dev.mysql.com/downloads/cluster/ から入手できます。Windows でオラクルが提供するバイナリリリースから MySQL Cluster をインストールする方法については、セクション18.2.3.1「Windows でのバイナリリリースからの MySQL Cluster のインストール」を参照してください。

Windows では、Microsoft Visual Studio を使用してソースから MySQL Cluster をコンパイルしてインストールすることもできます。詳細は、セクション18.2.3.2「Windows でのソースからの MySQL Cluster のコンパイルとインストール」を参照してください。

18.2.3.1 Windows でのバイナリリリースからの MySQL Cluster のインストール

このセクションでは、オラクルが提供する MySQL Cluster の no-install バイナリリリースを使用した MySQL Cluster の基本的なインストールについて説明します。ここでは、次の表に示すように、このセクションの冒頭 (セクション18.2「MySQL Cluster のインストール」を参照してください) で概説したのと同じ 4 ノードのセットアップを使用します。

ノードIP アドレス
管理 (MGMD) ノード192.168.0.10
MySQL サーバー (SQL) ノード192.168.0.20
データ (NDBD) ノード "A"192.168.0.30
データ (NDBD) ノード "B"192.168.0.40

ほかのプラットフォームと同様に、SQL ノードを実行する MySQL Cluster ホストコンピュータには MySQL Server バイナリ (mysqld.exe) をインストールする必要があります。このホストには MySQL クライアント (mysql.exe) も配置するようにしてください。管理ノードおよびデータノードに MySQL Server バイナリをインストールする必要はありません。各管理サーバーには、管理サーバーデーモン (ndb_mgmd.exe) が必要です。各データノードには、データノードデーモン (ndbd.exe または ndbmtd.exe) が必要です。この例では ndbd.exe をデータノード実行可能ファイルと呼びますが、代わりにこのプログラムのマルチスレッドバージョンである ndbmtd.exe をまったく同じ方法でインストールできます。管理サーバーホストには、管理クライアント (ndb_mgm.exe) もインストールするようにしてください。このセクションでは、MySQL Cluster ノードの各タイプに対応する適切な Windows バイナリをインストールするのに必要なステップについて説明します。

注記

ほかの Windows プログラムと同様に、MySQL Cluster 実行可能ファイルの名前には .exe ファイル拡張子が付けられています。ただし、コマンド行からこれらのプログラムを起動するときに .exe 拡張子を含める必要はありません。そのため、このドキュメントでは多くの場合、これらのプログラムを mysqldmysqlndb_mgmd などと呼びます。ここでは、(たとえば) mysqldmysqld.exe のどちらの呼び方であっても、どちらの名前も同じもの (MySQL Server プログラム) を意味しています。

オラクルの no-install バイナリを使用して MySQL Cluster をセットアップする場合は、インストールプロセスの最初のステップとして、https://dev.mysql.com/downloads/cluster/ から最新の MySQL Cluster Windows バイナリアーカイブをダウンロードします。このアーカイブには、mysql-cluster-gpl-noinstall-ver-winarch.zip という形式のファイル名が付けられます。verNDB ストレージエンジンのバージョン (7.3.1 など) であり、arch はアーキテクチャー (32 ビットバイナリの場合は 32、64 ビットバイナリの場合は 64) です。たとえば、MySQL Cluster NDB 7.3.1 の 32 ビット Windows システム用 no-install アーカイブの名前は mysql-cluster-gpl-noinstall-7.3.1-win32.zip です。

32 ビット MySQL Cluster バイナリは Windows の 32 ビットと 64 ビットの両方のバージョンで実行できますが、64 ビット MySQL Cluster バイナリは Windows の 64 ビットバージョンでのみ使用できます。64 ビット CPU を搭載したコンピュータで Windows の 32 ビットバージョンを使用する場合は、32 ビット MySQL Cluster バイナリを使用する必要があります。

インターネットからダウンロードしたりマシン間でコピーしたりする必要があるファイルの数を最小限に抑えるため、ここでは SQL ノードを実行するコンピュータから始めます。

SQL ノード  ここでは、IP アドレスが 192.168.0.20 であるコンピュータ上の C:\Documents and Settings\username\My Documents\Downloads (username は現在のユーザーの名前です) ディレクトリに no-install アーカイブのコピーが配置されていると仮定します。(この名前は、コマンド行で ECHO %USERNAME% を使用すると表示されます。)MySQL Cluster 実行可能ファイルを Windows サービスとしてインストールおよび実行するには、このユーザーが Administrators グループのメンバーになります。

アーカイブからすべてのファイルを抽出します。このタスクには、Windows Explorer に組み込まれた抽出ウィザードが適しています。(別のアーカイブプログラムを使用する場合は、アーカイブからすべてのファイルとディレクトリが抽出されたこと、アーカイブのディレクトリ構造が維持されていることを確認してください。)出力先のディレクトリを求められたら、C:\ と入力します。抽出ウィザードによってディレクトリ C:\mysql-cluster-gpl-noinstall-ver-winarch にアーカイブが抽出されます。このディレクトリの名前を C:\mysql に変更します。

MySQL Cluster バイナリを C:\mysql\bin 以外のディレクトリにインストールすることもできますが、その場合は、この手順に示されているパスをそれに合わせて変更する必要があります。特に、MySQL Server (SQL ノード) バイナリを C:\mysql または C:\Program Files\MySQL\MySQL Server 5.6 以外の場所にインストールした場合や、SQL ノードのデータディレクトリが C:\mysql\data または C:\Program Files\MySQL\MySQL Server 5.6\data 以外の場所にある場合は、SQL ノードの起動時に、追加の構成オプションをコマンド行で使用するか、my.ini または my.cnf ファイルに追加する必要があります。標準以外の場所で実行するように MySQL Server を構成する方法の詳細は、セクション2.3.5「非インストール Zip アーカイブを使用して Microsoft Windows に MySQL をインストールする」を参照してください。

MySQL Cluster サポートを含む MySQL Server を MySQL Cluster の一部として実行するには、--ndbcluster および --ndb-connectstring オプションを指定して起動する必要があります。これらのオプションは、コマンド行で指定することもできますが、通常はオプションファイルに設定する方が便利です。そのためには、メモ帳などのテキストエディタで新しいテキストファイルを作成します。このファイルに次の構成情報を入力します。

[mysqld]
# Options for mysqld process:
ndbcluster # run NDB storage engine
ndb-connectstring=192.168.0.10 # location of management server

この MySQL Server が使用するほかのオプション (セクション2.3.5.2「オプションファイルの作成」を参照してください) を必要に応じて追加できますが、このファイルには少なくともここに示したオプションを含める必要があります。このファイルを C:\mysql\my.ini として保存します。これで、SQL ノードのインストールとセットアップが完了します。

データノード  Windows ホストの MySQL Cluster データノードには、ndbd.exe または ndbmtd.exe のいずれか 1 つの実行可能ファイルのみが必要です。この例では、ndbd.exe を使用すると仮定しますが、ndbmtd.exe を使用するときも同じ手順が適用されます。データノードを実行する各コンピュータ (IP アドレスが 192.168.0.30 および 192.168.0.40 のコンピュータ) で、C:\mysqlC:\mysql\bin、および C:\mysql\cluster-data の各ディレクトリを作成します。次に、no-install アーカイブをダウンロードして抽出したコンピュータで、C:\mysql\bin ディレクトリ内の ndbd.exe を見つけます。このファイルを 2 台のデータノードホストの C:\mysql\bin ディレクトリにそれぞれコピーします。

データノードを MySQL Cluster の一部として機能させるには、各ノードに対して管理サーバーのアドレスまたはホスト名を指定する必要があります。この情報を指定するには、各データノードプロセスの起動時にコマンド行で --ndb-connectstring または -c オプションを使用します。ただし、通常はオプションファイルにこの情報を指定することをお勧めします。そのためには、メモ帳などのテキストエディタで新しいテキストファイルを作成して、次のテキストを入力します。

[mysql_cluster]
# Options for data node process:
ndb-connectstring=192.168.0.10 # location of management server

このファイルをデータノードホストに C:\mysql\my.ini として保存します。もう一方のデータノードホストで同じ内容を含むテキストファイルをもう 1 つ作成し、それを C:mysql\my.ini として保存するか、my.ini ファイルを 1 つ目のデータノードホストから 2 つ目のデータノードホストにコピーし、そのコピーを 2 つ目のデータノードの C:\mysql ディレクトリに確実に配置します。これで、両方のデータノードホストを MySQL Cluster で使用できるようになりました。あとは、管理ノードをインストールして構成するだけです。

管理ノード  MySQL Cluster 管理ノードのホストとして使用するコンピュータに必要な実行可能プログラムは、管理サーバープログラム ndb_mgmd.exe だけです。ただし、起動された MySQL Cluster を管理するため、管理サーバーと同じマシンに MySQL Cluster 管理クライアントプログラム ndb_mgm.exe もインストールしてください。no-install アーカイブをダウンロードして抽出したマシンで、これら 2 つのプログラムを見つけます。これは、SQL ノードホストの C:\mysql\bin ディレクトリになります。IP アドレスが 192.168.0.10 であるコンピュータに C:\mysql\bin ディレクトリを作成し、両方のプログラムをこのディレクトリにコピーします。

ここで、ndb_mgmd.exe が使用する 2 つの構成ファイルを作成してください。

  1. 管理ノード自体に固有の構成データを提供するローカル構成ファイル。通常、このファイルに指定する必要があるのは、MySQL Cluster グローバル構成ファイル (項目 2 を参照してください) の場所だけです。

    このファイルを作成するには、メモ帳などのテキストエディタで新しいテキストファイルを作成し、次の情報を入力します。

    [mysql_cluster]
    # Options for management node process
    config-file=C:/mysql/bin/config.ini

    このファイルをプレーンテキストファイル C:\mysql\bin\my.ini として保存します。

  2. 管理ノードが MySQL Cluster 全体を制御する構成情報を取得できるグローバル構成ファイル。このファイルには、少なくとも MySQL Cluster 内の各ノード用のセクションと、管理ノードおよびすべてのデータノードの IP アドレスまたはホスト名 (HostName 構成パラメータ) が含まれている必要があります。また、次の追加情報も含めることをお勧めします。

    • SQL ノードの IP アドレスまたはホスト名

    • 各データノードに割り当てられたデータメモリーおよびインデックスメモリー (DataMemory および IndexMemory 構成パラメータ)

    • レプリカの数 (NoOfReplicas 構成パラメータを使用します。セクション18.1.2「MySQL Cluster のノード、ノードグループ、レプリカ、およびパーティション」を参照してください)

    • 各データノードがデータおよびログファイルを格納するディレクトリと、管理ノードがログファイルを保持するディレクトリ (どちらの場合も、DataDir 構成パラメータ)

    メモ帳などのテキストエディタを使用して新しいテキストファイルを作成し、次の情報を入力します。

    [ndbd default]
    # Options affecting ndbd processes on all data nodes:
    NoOfReplicas=2 # Number of replicas
    DataDir=C:/mysql/cluster-data # Directory for each data node's data files # Forward slashes used in directory path, # rather than backslashes. This is correct; # see Important note in text
    DataMemory=80M # Memory allocated to data storage
    IndexMemory=18M # Memory allocated to index storage # For DataMemory and IndexMemory, we have used the # default values. Since the "world" database takes up # only about 500KB, this should be more than enough for # this example Cluster setup.
    [ndb_mgmd]
    # Management process options:
    HostName=192.168.0.10 # Hostname or IP address of management node
    DataDir=C:/mysql/bin/cluster-logs # Directory for management node log files
    [ndbd]
    # Options for data node "A": # (one [ndbd] section per data node)
    HostName=192.168.0.30 # Hostname or IP address
    [ndbd]
    # Options for data node "B":
    HostName=192.168.0.40 # Hostname or IP address
    [mysqld]
    # SQL node options:
    HostName=192.168.0.20 # Hostname or IP address

    このファイルをプレーンテキストファイル C:\mysql\bin\config.ini として保存します。

重要

Windows 上の MySQL Cluster が使用するプログラムオプションまたは構成ファイルでは、ディレクトリパスを指定するときに単独のバックスラッシュ文字 (\) を使用できません。代わりに、個々のバックスラッシュ文字を 2 つ目のバックスラッシュ (\\) でエスケープするか、バックスラッシュをスラッシュ文字 (/) に置き換えてください。たとえば、MySQL Cluster の config.ini ファイルの [ndb_mgmd] セクションから抜粋した次の行は機能しません。

DataDir=C:\mysql\bin\cluster-logs

代わりに、次のいずれかを使用できます。

DataDir=C:\\mysql\\bin\\cluster-logs # Escaped backslashes
DataDir=C:/mysql/bin/cluster-logs # Forward slashes

簡潔さと読みやすさのため、Windows 上の MySQL Cluster プログラムのオプションや構成ファイルで使用するディレクトリパスには、スラッシュを使用することをお勧めします。

18.2.3.2 Windows でのソースからの MySQL Cluster のコンパイルとインストール

オラクルは、ほとんどのユーザーに適合する事前コンパイル済みの Windows 用 MySQL Cluster バイナリを提供しています。ただし、必要な場合はソースコードから Windows 用の MySQL Cluster をコンパイルすることもできます。これを実行する手順は、標準の Windows 用 MySQL Server バイナリをコンパイルする場合の手順とほぼ同じであり、同じツールを使用します。ただし、2 つの大きな違いがあります。

  • MySQL Cluster をビルドするには、https://dev.mysql.com/downloads/cluster/ から入手できる MySQL Cluster ソースを使用する必要があります。

    標準の MySQL Server のソースコードから MySQL Cluster をビルドしようとすると、失敗する可能性が高く、オラクルではサポートされません。

  • CMake で使用するほかのビルドオプションに加えて、WITH_NDBCLUSTER_STORAGE_ENGINE または WITH_NDBCLUSTER オプションを使用してビルドを構成する必要があります。(WITH_NDBCLUSTERWITH_NDBCLUSTER_STORAGE_ENGINE のエイリアスとしてサポートされており、まったく同じように機能します。)

重要

MySQL Cluster NDB 7.3 以降では、WITH_NDB_JAVA オプションがデフォルトで有効になっています。つまり、デフォルトでは CMake でシステム上の Java の場所が見つからなかった場合に構成プロセスが失敗します。Java および ClusterJ のサポートを有効にしない場合は、-DWITH_NDB_JAVA=OFF を使用してビルドを構成することで、これを明示的に示す必要があります。(Bug #12379735) 必要な場合は、WITH_CLASSPATH を使用して Java クラスパスを指定します。

MySQL Cluster のビルドに固有の CMake オプションの詳細は、MySQL Cluster をコンパイルするためのオプションを参照してください。

ビルドプロセスが完了したら、コンパイルされたバイナリを含む Zip アーカイブを作成できます。Windows システムでこのタスクを実行するのに必要なコマンドについては、セクション2.9.2「標準ソース配布を使用して MySQL をインストールする」を参照してください。MySQL Cluster バイナリは、生成されたアーカイブの bin ディレクトリに含まれています。このアーカイブは no-install アーカイブと同等であり、同じ方法でインストールおよび構成できます。詳細は、セクション18.2.3.1「Windows でのバイナリリリースからの MySQL Cluster のインストール」を参照してください。

18.2.3.3 Windows での MySQL Cluster の初期起動

MySQL Cluster の実行可能ファイルと必要な構成ファイルを配置したあと、クラスタの初期起動を行うには、単純にクラスタ内のすべてのノードで MySQL Cluster の実行可能ファイルを起動します。各クラスタノードプロセスは、それが配置されているホストコンピュータ上で別個に起動する必要があります。最初に管理ノード、次にデータノード、最後に SQL ノードを起動するようにしてください。

  1. 管理ノードホストでは、コマンド行から次のコマンドを発行して管理ノードプロセスを起動します。ここに示すような出力が表示されます。

    C:\mysql\bin> ndb_mgmd2010-06-23 07:53:34 [MgmtSrvr] INFO -- NDB Cluster Management Server. mysql-5.6.22-ndb-7.4.4
    2010-06-23 07:53:34 [MgmtSrvr] INFO -- Reading cluster configuration from 'config.ini'

    管理ノードプロセスは、ロギング出力をコンソールに出力し続けます。管理ノードは Windows サービスとして実行されていないため、これは正常な動作です。(Linux などの Unix 系プラットフォームで MySQL Cluster を使用したことがある場合は、これに関する Windows での管理ノードのデフォルトの動作が実質的に Unix システムの動作 (デフォルトでは Unix デーモンプロセスとして実行されます) と逆であることに気付くでしょう。この動作は、Windows で実行される MySQL Cluster データノードプロセスにも当てはまります。)このため、ndb_mgmd.exe が実行されているウィンドウを閉じないでください。閉じると、管理ノードプロセスが強制終了されます。(MySQL Cluster プロセスを Windows サービスとしてインストールして実行する方法については、セクション18.2.3.4「Windows サービスとしての MySQL Cluster プロセスのインストール」を参照してください。)

    必須の -f オプションで、管理ノードにグローバル構成ファイル (config.ini) がある場所を指示します。このオプションの長形式は --config-file です。

    重要

    MySQL Cluster 管理ノードは、config.ini から読み取った構成データをキャッシュします。構成キャッシュが作成されたあとは、強制的に読み取りを行わないかぎり、その後の起動時に config.ini ファイルは無視されます。つまり、このファイル内のエラーが原因で管理ノードが起動に失敗した場合は、エラーを修正してから、管理ノードに config.ini を再度読み取らせる必要があります。これを行うには、コマンド行で --reload または --initial オプションを指定して ndb_mgmd.exe を起動します。これらのオプションは、どちらも構成キャッシュをリフレッシュする機能を持っています。

    管理ノードの my.ini ファイルでこれらのオプションのいずれかを使用することは、必要ないか、または推奨されません。

    ndb_mgmd で使用できるオプションに関する追加情報は、セクション18.4.4「ndb_mgmd — MySQL Cluster 管理サーバーデーモン」およびセクション18.4.27「MySQL Cluster プログラムに共通するオプション — MySQL Cluster プログラムに共通するオプション」を参照してください。

  2. 各データノードホストで、ここに示すコマンドを実行してデータノードプロセスを起動します。

    C:\mysql\bin> ndbd2010-06-23 07:53:46 [ndbd] INFO -- Configuration fetched from 'localhost:1186', generation: 1

    いずれの場合も、データノードプロセスによって生成される出力の最初の行は前の例で示したものと似ていますが、そのあとにロギング出力の行が追加されます。管理ノードと同様に、データノードは Windows サービスとして実行されていないため、これは正常な動作です。このため、データノードプロセスが実行されているコンソールウィンドウを閉じないでください。閉じると、ndbd.exe が強制終了されます。(詳細はセクション18.2.3.4「Windows サービスとしての MySQL Cluster プロセスのインストール」を参照してください。)

  3. SQL ノードをまだ起動しないでください。データノードの起動 (しばらく時間がかかることがあります) が完了するまでは、SQL ノードをクラスタに接続できません。代わりに、管理ノードホストの新しいコンソールウィンドウで、管理ノードホストの C:\mysql\bin にある MySQL Cluster 管理クライアント ndb_mgm.exe を起動します。(CTRL+C を入力して ndb_mgmd.exe が実行されているコンソールウィンドウを再利用しないでください。これを行うと管理ノードが強制終了されます。)生成される出力は次のようになります。

    C:\mysql\bin> ndb_mgm-- NDB Cluster -- Management Client --
    ndb_mgm>

    ndb_mgm> というプロンプトが表示された場合、これは管理クライアントが MySQL Cluster の管理コマンドを受信できるようになったことを示します。管理クライアントのプロンプトで ALL STATUS と入力すると、データノードの起動時のステータスを確認できます。このコマンドによって、データノードの起動シーケンスのレポートが実行され、次のように表示されます。

    ndb_mgm> ALL STATUSConnected to Management Server at: localhost:1186
    Node 2: starting (Last completed phase 3) (mysql-5.6.22-ndb-7.4.4)
    Node 3: starting (Last completed phase 3) (mysql-5.6.22-ndb-7.4.4)
    Node 2: starting (Last completed phase 4) (mysql-5.6.22-ndb-7.4.4)
    Node 3: starting (Last completed phase 4) (mysql-5.6.22-ndb-7.4.4)
    Node 2: Started (version 7.4.4)
    Node 3: Started (version 7.4.4)
    ndb_mgm>
    注記

    管理クライアントで発行されるコマンドでは大文字と小文字が区別されません。ここでは、コマンドの標準形式として大文字を使用しますが、ndb_mgm クライアントに入力するときに、この表記法に従う必要はありません。詳細は、セクション18.5.2「MySQL Cluster 管理クライアントのコマンド」を参照してください。

    ALL STATUS によって生成される出力は、データノードの起動速度、使用する MySQL Cluster ソフトウェアのリリースバージョン番号、およびその他の要因によって、ここに示すものと異なる可能性があります。重要なのは、両方のデータノードの起動を確認したときに、SQL ノードの起動準備が整うことです。

    ndb_mgm.exe は実行したままにできます。MySQL Cluster のパフォーマンスに悪影響を与えることはありません。次のステップではこれを使用して、起動した SQL ノードがクラスタに接続したか確認します。

  4. SQL ノードホストとして指定したコンピュータで、コンソールウィンドウを開き、MySQL Cluster バイナリを解凍したディレクトリ (この例に従っている場合、これは C:\mysql\bin です) に移動します。

    SQL ノードを起動するには、ここに示すように、コマンド行で mysqld.exe を起動します。

    C:\mysql\bin> mysqld --console

    --console オプションによって、コンソールにロギング情報が書き込まれます。これは問題が発生したときに役立つことがあります。(SQL ノードが問題なく実行されていることを確認できたら、SQL ノードを停止してから --console オプションを指定せずに起動すると、ロギングが通常どおり実行されるようになります。)

    管理ノードホストの管理クライアント (ndb_mgm.exe) が実行されているコンソールウィンドウで、SHOW コマンドを入力します。ここに示すような出力が生成されます。

    ndb_mgm> SHOWConnected to Management Server at: localhost:1186
    Cluster Configuration
    ---------------------
    [ndbd(NDB)] 2 node(s)
    id=2 @192.168.0.30 (Version: 5.6.22-ndb-7.4.4, Nodegroup: 0, *)
    id=3 @192.168.0.40 (Version: 5.6.22-ndb-7.4.4, Nodegroup: 0)
    [ndb_mgmd(MGM)] 1 node(s)
    id=1 @192.168.0.10 (Version: 5.6.22-ndb-7.4.4)
    [mysqld(API)] 1 node(s)
    id=4 @192.168.0.20 (Version: 5.6.22-ndb-7.4.4)

    また、SQL ノードが MySQL Cluster に接続されているか確認するには、mysql クライアント (mysql.exe) で SHOW ENGINE NDB STATUS ステートメントを使用します。

これで、MySQL Cluster の NDBCLUSTER ストレージエンジンを使用してデータベースオブジェクトとデータを操作する準備ができました。詳細と例については、セクション18.2.6「テーブルとデータを含む MySQL Cluster の例」を参照してください。

ndb_mgmd.exendbd.exe、および ndbmtd.exe を Windows サービスとしてインストールすることもできます。これを行う方法については、セクション18.2.3.4「Windows サービスとしての MySQL Cluster プロセスのインストール」を参照してください)。

18.2.3.4 Windows サービスとしての MySQL Cluster プロセスのインストール

MySQL Cluster が要求どおりに実行されていることを確認できたら、管理ノードとデータノードを Windows サービスとしてインストールできます。これにより、Windows の起動または停止に合わせて各プロセスを自動的に起動および停止できます。また、この場合は、コマンド行で適切な NET START または NET STOP コマンドを使用するか、Windows のグラフィカルな「サービス」ユーティリティーを使用すると、このプロセスを制御できます。

プログラムを Windows サービスとしてインストールする場合は、通常、システム上の Administrator 権利を持つアカウントを使用する必要があります。

管理ノードを Windows 上のサービスとしてインストールするには、ここに示すように、管理ノードをホストするマシンのコマンド行で --install オプションを使用して ndb_mgmd.exe を起動します。

C:\> C:\mysql\bin\ndb_mgmd.exe --installInstalling service 'MySQL Cluster Management Server' as '"C:\mysql\bin\ndbd.exe" "--service=ndb_mgmd"'
Service successfully installed.
重要

MySQL Cluster プログラムを Windows サービスとしてインストールするときは、常に完全なパスを指定するようにしてください。そうしないと、サービスのインストールが失敗し、次のエラーが発生します: The system cannot find the file specified

--install オプションは、ndb_mgmd.exe に指定できるほかのオプションより先に使用する必要があります。ただし、このようなオプションはオプションファイルに指定することをお勧めします。オプションファイルが ndb_mgmd.exe--help の出力に示されるデフォルトの場所のいずれにも存在しない場合は、--config-file オプションを使用するとその場所を指定できます。

これで、このように管理サーバーを起動および停止できるようになります。

C:\> NET START ndb_mgmdThe MySQL Cluster Management Server service is starting.
The MySQL Cluster Management Server service was started successfully.
C:\> NET STOP ndb_mgmdThe MySQL Cluster Management Server service is stopping..
The MySQL Cluster Management Server service was stopped successfully.

ここに示すように、管理サーバーを Windows サービスとして起動または停止するときに記述名を使用することもできます。

C:\> NET START 'MySQL Cluster Management Server'The MySQL Cluster Management Server service is starting.
The MySQL Cluster Management Server service was started successfully.
C:\> NET STOP 'MySQL Cluster Management Server'The MySQL Cluster Management Server service is stopping..
The MySQL Cluster Management Server service was stopped successfully.

ただし、通常は短いサービス名を指定するか、サービスのインストール時にデフォルトのサービス名を使用できるように設定して、サービスの起動または停止時にその名前を参照する方が簡単です。ndb_mgmd 以外のサービス名を指定するには、この例に示すように --install オプションを追加します。

C:\> C:\mysql\bin\ndb_mgmd.exe --install=mgmd1Installing service 'MySQL Cluster Management Server' as '"C:\mysql\bin\ndb_mgmd.exe" "--service=mgmd1"'
Service successfully installed.

これで、このように指定した名前を使用してサービスを起動または停止できるようになります。

C:\> NET START mgmd1The MySQL Cluster Management Server service is starting.
The MySQL Cluster Management Server service was started successfully.
C:\> NET STOP mgmd1The MySQL Cluster Management Server service is stopping..
The MySQL Cluster Management Server service was stopped successfully.

管理ノードサービスを削除するには、ここに示すように --remove オプションを指定して ndb_mgmd.exe を起動します。

C:\> C:\mysql\bin\ndb_mgmd.exe --removeRemoving service 'MySQL Cluster Management Server'
Service successfully removed.

デフォルト以外のサービス名を使用してサービスをインストールした場合は、このように --remove オプションの値としてこの名前を渡すと、サービスを削除できます。

C:\> C:\mysql\bin\ndb_mgmd.exe --remove=mgmd1Removing service 'mgmd1'
Service successfully removed.

Windows サービスとしての MySQL Cluster データノードプロセスのインストールは、ここに示すように、ndbd.exe (または ndbmtd.exe) の --install オプションを使用して同じように実行できます。

C:\> C:\mysql\bin\ndbd.exe --installInstalling service 'MySQL Cluster Data Node Daemon' as '"C:\mysql\bin\ndbd.exe" "--service=ndbd"'
Service successfully installed.

これで、次の例に示すように net start または net stop でデフォルトのサービス名または記述名を使用してデータノードを起動または停止できます。

C:\> NET START ndbdThe MySQL Cluster Data Node Daemon service is starting.
The MySQL Cluster Data Node Daemon service was started successfully.
C:\> NET STOP ndbdThe MySQL Cluster Data Node Daemon service is stopping..
The MySQL Cluster Data Node Daemon service was stopped successfully.
C:\> NET START 'MySQL Cluster Data Node Daemon'The MySQL Cluster Data Node Daemon service is starting.
The MySQL Cluster Data Node Daemon service was started successfully.
C:\> NET STOP 'MySQL Cluster Data Node Daemon'The MySQL Cluster Data Node Daemon service is stopping..
The MySQL Cluster Data Node Daemon service was stopped successfully.

データノードサービスを削除するには、ここに示すように --remove オプションを指定して ndbd.exe を起動します。

C:\> C:\mysql\bin\ndbd.exe --removeRemoving service 'MySQL Cluster Data Node Daemon'
Service successfully removed.

ndb_mgmd.exe (および mysqld.exe) と同様に、ndbd.exe を Windows サービスとしてインストールするときは、このようにサービスの名前を --install の値として指定し、サービスの起動または停止時にそれを使用することもできます。

C:\> C:\mysql\bin\ndbd.exe --install=dnode1Installing service 'dnode1' as '"C:\mysql\bin\ndbd.exe" "--service=dnode1"'
Service successfully installed.
C:\> NET START dnode1The MySQL Cluster Data Node Daemon service is starting.
The MySQL Cluster Data Node Daemon service was started successfully.
C:\> NET STOP dnode1The MySQL Cluster Data Node Daemon service is stopping..
The MySQL Cluster Data Node Daemon service was stopped successfully.

データノードサービスのインストール時にサービス名を指定した場合は、ここに示すように、それを削除するときもこの名前を (--remove オプションの値として渡すことで) 使用できます。

C:\> C:\mysql\bin\ndbd.exe --remove=dnode1Removing service 'dnode1'
Service successfully removed.

Windows サービスとしての SQL ノードのインストール、サービスの起動、サービスの停止、およびサービスの削除も、mysqld--installNET STARTNET STOP、および mysqld--remove を使用して同じように行います。追加情報については、セクション2.3.5.7「Windows のサービスとして MySQL を起動する」を参照してください。

18.2.4 MySQL Cluster の初期構成

このセクションでは、構成ファイルの作成と編集によるインストール済み MySQL Cluster の手動構成について説明します。

MySQL Cluster (NDB バージョン 7.3 以降) には、別のアプリケーションでテキストファイルを編集せずに構成を行うために使用できる GUI インストーラも用意されています。詳細は、セクション18.2.1「MySQL Cluster Auto-Installer」を参照してください。

ここで使用する 4 ノードおよび 4 ホストの MySQL Cluster (クラスタノードとホストコンピュータを参照してください) では、4 つ (ノードホストごとに 1 つずつ) の構成ファイルを作成する必要があります。

  • 個々のデータノードまたは SQL ノードには my.cnf ファイルが必要です。このファイルは、管理ノードが配置されたノードを指定する接続文字列と、このホスト (データノードをホストしているマシン) の MySQL サーバーに対して NDBCLUSTER ストレージエンジンを有効にするように指示する行の 2 つの情報を提供します。

    接続文字列の詳細は、セクション18.3.2.3「MySQL Cluster の接続文字列」を参照してください。

  • 管理ノードには config.ini ファイルが必要です。このファイルは、保持するレプリカの数、各データノードのデータおよびインデックスに割り当てるメモリーの量、データノードの場所、各データノードのデータを保存するディスク上の場所、および SQL ノードの場所を指示します。

データノードと SQL ノードの構成  データノードに必要な my.cnf ファイルはかなり単純です。この構成ファイルは、/etc ディレクトリに配置され、任意のテキストエディタを使用して編集できます。(このファイルが存在しない場合は作成してください。)例:

shell> vi /etc/my.cnf
注記

ここでは、vi を使用してこのファイルを作成しますが、どのテキストエディタでも同じように機能します。

このセットアップ例の各データノードおよび SQL ノードでは、my.cnf はこのようになります。

[mysqld]
# Options for mysqld process:
ndbcluster # run NDB storage engine
[mysql_cluster]
# Options for MySQL Cluster processes:
ndb-connectstring=192.168.0.10 # location of management server

上記の情報を入力したら、このファイルを保存してテキストエディタを終了します。これを、データノード A、データノードB、および SQL ノードをホストしているマシンで実行します。

重要

上記の my.cnf ファイルの [mysqld] および [mysql_cluster] セクションの ndbcluster および ndb-connectstring パラメータを使用して mysqld プロセスを起動したあとは、クラスタが実際に起動しないと、CREATE TABLE または ALTER TABLE ステートメントを実行できません。そうでない場合、これらのステートメントはエラーで失敗します。これは意図的なものです。

管理ノードの構成  管理ノードの構成では、最初のステップとして構成ファイルを配置するディレクトリを作成し、その後構成ファイル自体を作成します。例 (root として実行します):

shell> mkdir /var/lib/mysql-clustershell> cd /var/lib/mysql-clustershell> vi config.ini

ここで使用する典型的なセットアップでは、config.ini ファイルは次のようになります。

[ndbd default]
# Options affecting ndbd processes on all data nodes:
NoOfReplicas=2 # Number of replicas
DataMemory=80M # How much memory to allocate for data storage
IndexMemory=18M # How much memory to allocate for index storage # For DataMemory and IndexMemory, we have used the # default values. Since the "world" database takes up # only about 500KB, this should be more than enough for # this example Cluster setup.
[tcp default]
# TCP/IP options:
portnumber=2202 # This the default; however, you can use any # port that is free for all the hosts in the cluster # Note: It is recommended that you do not specify the port # number at all and simply allow the default value to be used # instead
[ndb_mgmd]
# Management process options:
hostname=192.168.0.10 # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster # Directory for MGM node log files
[ndbd]
# Options for data node "A": # (one [ndbd] section per data node)
hostname=192.168.0.30 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's data files
[ndbd]
# Options for data node "B":
hostname=192.168.0.40 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's data files
[mysqld]
# SQL node options:
hostname=192.168.0.20 # Hostname or IP address # (additional mysqld connections can be # specified for this node for various # purposes such as running ndb_restore)
注記

world データベースは https://dev.mysql.com/doc/ からダウンロードできます (Examples の下にあります)。

すべての構成ファイルを作成し、最小限のオプションを指定したら、クラスタの起動とすべてのプロセスの実行確認に進む準備が整います。これを行う方法については、セクション18.2.5「MySQL Cluster の初期起動」で説明します。

使用可能な MySQL Cluster 構成パラメータとその使用方法の詳細は、セクション18.3.2「MySQL Cluster の構成ファイル」およびセクション18.3「MySQL Cluster の構成」を参照してください。MySQL Cluster のバックアップ作成に関する構成については、セクション18.5.3.3「MySQL Cluster バックアップ用の構成」を参照してください。

注記

クラスタ管理ノードのデフォルトポートは 1186 です。データノードのデフォルトポートは 2202 です。ただし、クラスタではすでに開放されているポートからデータノードのポートを自動的に割り当てることができます。

18.2.5 MySQL Cluster の初期起動

構成後のクラスタを起動することは、それほど難しいことではありません。各クラスタノードプロセスは、配置されているホストで別個に起動する必要があります。最初に管理ノード、次にデータノード、最後に SQL ノードを起動してください。

  1. 管理ホストで、システムシェルから次のコマンドを発行して管理ノードプロセスを起動します。

    shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini

    ndb_mgmd をはじめて起動するときは、-f または --config-file オプションを使用してその構成ファイルの場所を指定する必要があります。(詳細は、セクション18.4.4「ndb_mgmd — MySQL Cluster 管理サーバーデーモン」を参照してください。)

    ndb_mgmd で使用できる追加のオプションについては、セクション18.4.27「MySQL Cluster プログラムに共通するオプション — MySQL Cluster プログラムに共通するオプション」を参照してください。

  2. 個々のデータノードホストで、このコマンドを実行して ndbd プロセスを起動します。

    shell> ndbd
  3. SQL ノードを配置するクラスタホストで RPM ファイルを使用して MySQL をインストールした場合は、付属の起動スクリプトを使用して SQL ノードの MySQL サーバープロセスを起動できます (起動するようにしてください)。

すべてが順調に進み、クラスタが正しくセットアップされると、クラスタは使用できる状態になります。これをテストするには、ndb_mgm 管理ノードクライアントを起動します。ここに示すような出力が表示されますが、使用している MySQL の特定のバージョンによって出力内容がやや異なる場合があります。

shell> ndb_mgm-- NDB Cluster -- Management Client --
ndb_mgm> SHOWConnected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 @192.168.0.30 (Version: 5.6.22-ndb-7.4.4, Nodegroup: 0, *)
id=3 @192.168.0.40 (Version: 5.6.22-ndb-7.4.4, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.0.10 (Version: 5.6.22-ndb-7.4.4)
[mysqld(API)] 1 node(s)
id=4 @192.168.0.20 (Version: 5.6.22-ndb-7.4.4)

ここでは、SQL ノードが [mysqld(API)] として参照されています。これは、mysqld プロセスが MySQL Cluster の API ノードとして機能していることを反映しています。

注記

SHOW の出力で MySQL Cluster の特定の SQL ノードまたはその他の API ノードに関して表示されている IP アドレスは、SQL または API ノードが管理ノードではなくクラスタデータノードに接続するために使用するアドレスです。

これで、MySQL Cluster 内のデータベース、テーブル、およびデータを操作する準備が整いました。簡単な説明については、セクション18.2.6「テーブルとデータを含む MySQL Cluster の例」を参照してください。

18.2.6 テーブルとデータを含む MySQL Cluster の例

注記

このセクションの情報は、Unix と Windows のプラットフォームで実行される MySQL Cluster に適用されます。

MySQL Cluster 内のデータベースデーブルおよびデータの操作は、標準の MySQL の場合とほとんど違いはありません。留意すべき重要なポイントが 2 つあります。

  • クラスタ内でレプリケートされるテーブルでは、NDBCLUSTER ストレージエンジンを使用する必要があります。これを指定するには、テーブルの作成時に ENGINE=NDBCLUSTER または ENGINE=NDB オプションを使用します。

    CREATE TABLE tbl_name (col_namecolumn_definitions) ENGINE=NDBCLUSTER;

    または、異なるストレージエンジンを使用する既存のテーブルに対して ALTER TABLE を使用して、NDBCLUSTER を使用するようにテーブルを変更します。

    ALTER TABLE tbl_name ENGINE=NDBCLUSTER;
  • すべての NDBCLUSTER テーブルには主キーがあります。テーブルの作成時にユーザーが主キーを定義しなかった場合は、NDBCLUSTER ストレージエンジンが隠し主キーを自動的に生成します。このようなキーは、ほかのテーブルインデックスと同じサイズの領域を占有します。(これらの自動的に作成されるインデックスを格納する十分なメモリーがないために問題が発生することは、珍しくありません。)

mysqldump の出力を使用して既存のデータベースからテーブルをインポートする場合は、SQL スクリプトをテキストエディタで開いて、テーブル作成ステートメントに ENGINE オプションを追加するか、既存の ENGINE オプションを置き換えることができます。MySQL Cluster をサポートしない別の MySQL サーバーに world サンプルデータベースがあり、City テーブルをエクスポートする必要があるとします。

shell> mysqldump --add-drop-table world City > city_table.sql

この結果作成される city_table.sql ファイルには、このテーブル作成ステートメント (およびテーブルデータをインポートするために必要な INSERT ステートメント) が格納されます。

DROP TABLE IF EXISTS `City`;
CREATE TABLE `City` ( `ID` int(11) NOT NULL auto_increment, `Name` char(35) NOT NULL default '', `CountryCode` char(3) NOT NULL default '', `District` char(20) NOT NULL default '', `Population` int(11) NOT NULL default '0', PRIMARY KEY (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
INSERT INTO `City` VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO `City` VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO `City` VALUES (3,'Herat','AFG','Herat',186800);(remaining INSERT statements omitted)

MySQL がこのテーブルに対して NDBCLUSTER ストレージエンジンを使用するか確認する必要があります。これを行うには 2 つの方法があります。1 つは、テーブル定義をクラスタデータベースにインポートする前に変更することです。例として City テーブルを使用し、定義の ENGINE オプションを次のように変更します。

DROP TABLE IF EXISTS `City`;
CREATE TABLE `City` ( `ID` int(11) NOT NULL auto_increment, `Name` char(35) NOT NULL default '', `CountryCode` char(3) NOT NULL default '', `District` char(20) NOT NULL default '', `Population` int(11) NOT NULL default '0', PRIMARY KEY (`ID`)
) ENGINE=NDBCLUSTER DEFAULT CHARSET=latin1;
INSERT INTO `City` VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO `City` VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO `City` VALUES (3,'Herat','AFG','Herat',186800);(remaining INSERT statements omitted)

クラスタ化されたデータベースの一部になる個々のテーブルの定義で、これを行う必要があります。これを行うもっとも簡単な方法は、定義を含むファイルに対して検索置換を実行し、TYPE=engine_name または ENGINE=engine_name のすべてのインスタンスを ENGINE=NDBCLUSTER に置換することです。ファイルを変更したくない場合は、変更していないファイルを使用してテーブルを作成してから、ALTER TABLE を使用してストレージエンジンを変更します。詳細はこのセクションで後述します。

クラスタの SQL ノードで world という名前のデータベースがすでに作成されていることを前提に、mysql コマンド行クライアントを使用して city_table.sql を読み取り、対応するテーブルを通常の方法で作成して移入します。

shell> mysql world < city_table.sql

非常に重要な留意点として、前述のコマンドは SQL ノードを実行しているホスト (この場合は、IP アドレスが 192.168.0.20 のマシン) で実行する必要があります。

SQL ノードで world データベース全体のコピーを作成するには、非クラスタサーバーで mysqldump を使用して、(たとえば) /tmp ディレクトリの world.sql という名前のファイルにデータベースをエクスポートします。次に、前述のとおりにテーブル定義を変更し、このようにファイルをクラスタの SQL ノードにインポートします。

shell> mysql world < /tmp/world.sql

ファイルを別の場所に保存する場合は、それに合わせて前述の手順を調整してください。

SQL ノードでの SELECT クエリーの実行は、MySQL サーバーのほかのインスタンスでの実行と違いはありません。コマンド行からクエリーを実行するには、最初に通常の方法で (Enter password: プロンプトで root パスワードを指定して) MySQL Monitor にログインする必要があります。

shell> mysql -u root -pEnter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.6.22-ndb-7.4.4
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>

ここでは、MySQL サーバーの root アカウントを使用し、MySQL サーバーのインストールに関する標準的なセキュリティー対策 (強力な root パスワードの設定を含む) に従っていると仮定します。詳細は、セクション2.10.2「最初の MySQL アカウントのセキュリティー設定」を参照してください。

クラスタノードが相互にアクセスするときは MySQL の権限システムが利用されないことを考慮に入れてください。MySQL ユーザーアカウント (root アカウントを含む) の設定または変更は、SQL ノードにアクセスするアプリケーションにのみ影響し、ノード間のやり取りには影響しません。詳細は、セクション18.5.11.2「MySQL Cluster と MySQL 権限」を参照してください。

SQL スクリプトをインポートする前にテーブル定義の ENGINE 句を変更しなかった場合は、この時点で次のステートメントを実行してください。

mysql> USE world;mysql> ALTER TABLE City ENGINE=NDBCLUSTER;mysql> ALTER TABLE Country ENGINE=NDBCLUSTER;mysql> ALTER TABLE CountryLanguage ENGINE=NDBCLUSTER;

データベースの選択とそのデータベース内のテーブルに対する SELECT クエリーの実行も、MySQL Monitor の終了と同様に通常の方法で行います。

mysql> USE world;mysql> SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5;+-----------+------------+
| Name | Population |
+-----------+------------+
| Bombay | 10500000 |
| Seoul | 9981619 |
| São Paulo | 9968485 |
| Shanghai | 9696300 |
| Jakarta | 9604900 |
+-----------+------------+
5 rows in set (0.34 sec)
mysql> \qBye
shell>

MySQL を使用するアプリケーションは、標準の API を使用して NDB テーブルにアクセスできます。アプリケーションは、管理ノードやデータノードではなく、SQL ノードにアクセスする必要があります。この簡単な例では、ネットワーク上の別の場所にある Web サーバーで実行されている PHP 5.X の mysqli 拡張を使用して、ここに示す SELECT ステートメントを実行する方法を示しています。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>SIMPLE mysqli SELECT</title>
</head>
<body>
<?php # connect to SQL node: $link = new mysqli('192.168.0.20', 'root', 'root_password', 'world'); # parameters for mysqli constructor are: # host, user, password, database if( mysqli_connect_errno() ) die("Connect failed: " . mysqli_connect_error()); $query = "SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5"; # if no errors... if( $result = $link->query($query) ) {
?>
<table border="1" width="40%" cellpadding="4" cellspacing ="1"> <tbody> <tr> <th width="10%">City</th> <th>Population</th> </tr>
<? # then display the results... while($row = $result->fetch_object()) printf("<tr>\n <td align=\"center\">%s</td><td>%d</td>\n</tr>\n", $row->Name, $row->Population);
?> </tbody
</table>
<? # ...and verify the number of rows that were retrieved printf("<p>Affected rows: %d</p>\n", $link->affected_rows); } else # otherwise, tell us what went wrong echo mysqli_error(); # free the result set and the mysqli connection object $result->close(); $link->close();
?>
</body>
</html>

ここでは、Web サーバーで実行されているプロセスが SQL ノードの IP アドレスに到達できると仮定します。

同様の方法で、MySQL C API、Perl-DBI、Python-mysql、または MySQL Connector を使用して、MySQL で通常実行する同じデータの定義や操作のタスクを実行できます。

18.2.7 MySQL Cluster の安全なシャットダウンと再起動

クラスタをシャットダウンするには、管理ノードをホストしているマシン上のシェルで次のコマンドを入力します。

shell> ndb_mgm -e shutdown

この -e オプションは、シェルから ndb_mgm クライアントにコマンドを渡すために使用されます。(このオプションの詳細は、セクション18.4.27「MySQL Cluster プログラムに共通するオプション — MySQL Cluster プログラムに共通するオプション」を参照してください。)このコマンドによって、ndb_mgmndb_mgmd、およびすべての ndbd または ndbmtd プロセスが適切な方法で終了します。SQL ノードは mysqladmin shutdown およびその他の方法で終了できます。Windows プラットフォームでは、SQL ノードを Windows サービスとしてインストールした場合に NET STOP MYSQL を使用できます。

Unix プラットフォームでクラスタを再起動するには、次のコマンドを実行します。

  • 管理ホスト (このセットアップ例では 192.168.0.10):

    shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
  • 個々のデータノードホスト (192.168.0.30 および 192.168.0.40):

    shell> ndbd
  • ndb_mgm クライアントを使用して、両方のデータノードが正常に起動したか確認します。

  • SQL ホスト (192.168.0.20):

    shell> mysqld_safe &

Windows プラットフォームでは、すべての MySQL Cluster プロセスをデフォルトのサービス名を使用して Windows サービスとしてインストールした場合に (セクション18.2.3.4「Windows サービスとしての MySQL Cluster プロセスのインストール」を参照してください)、次のようにクラスタを再起動できます。

  • 管理ホスト (このセットアップ例では 192.168.0.10) で、次のコマンドを実行します。

    C:\> NET START ndb_mgmd
  • 個々のデータノードホスト (192.168.0.30 および 192.168.0.40) で、次のコマンドを実行します。

    C:\> NET START ndbd
  • 管理ノードホストで、ndb_mgm クライアントを使用して管理ノードと両方のデータノードが正常に起動したか確認します (セクション18.2.3.3「Windows での MySQL Cluster の初期起動」を参照してください)。

  • SQL ノードホスト (192.168.0.20) で、次のコマンドを実行します。

    C:\> NET START mysql

本番設定では、通常、クラスタを完全にシャットダウンすることは望ましくありません。多くの場合、構成変更やクラスタのハードウェアまたはソフトウェア (あるいはその両方) のアップグレードを実行して個々のホストマシンをシャットダウンする必要が生じた場合でも、クラスタのローリング再起動を実行することで、クラスタ全体をシャットダウンせずに処理を完了できます。この実行方法の詳細は、セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください。

18.2.8 MySQL Cluster NDB 7.3 のアップグレードとダウングレード

このセクションでは、異なる MySQL Cluster NDB 7.3 リリース間でのアップグレードおよびダウングレードの実行に関する MySQL Cluster ソフトウェアおよびテーブルファイルの互換性、および互換性のマトリックスと注意事項について説明します。アップグレードまたはダウングレードを試行する前に、ユーザーは MySQL Cluster のインストールと構成にすでに習熟していることが求められます。セクション18.3「MySQL Cluster の構成」を参照してください。

重要

このセクションでは、MySQL バージョン間の NDBCLUSTER に関する互換性のみを考慮しますが、考慮すべき問題はほかにもある場合があります。ほかの MySQL ソフトウェアのアップグレードまたはダウングレードと同様に、MySQL Cluster ソフトウェアのアップグレードまたはダウングレードを試行する前に、移行先および移行元の MySQL バージョンの MySQL マニュアルの関連部分を確認することを強くお勧めしますセクション2.11.1「MySQL のアップグレード」を参照してください。

ここに示す表は、MySQL Cluster NDB 7.3 の異なるリリース間での MySQL Cluster のアップグレードおよびダウングレードの互換性に関する情報を示しています。表の直後に、MySQL Cluster NDB 7.3 リリースシリーズへの、リリースシリーズからの、またはリリースシリーズ間のアップグレードおよびダウングレードに関する追加の注意事項を示します。

MySQL Cluster NDB 7.3.x のアップグレード/ダウングレードの互換性

注意事項: MySQL Cluster NDB 7.3

サポートされるバージョン  MySQL Cluster NDB 7.3 (7.3.2 移行) へのアップグレードについては、MySQL Cluster の次のバージョンがサポートされます。

  • MySQL Cluster NDB 7.2 GA リリース (7.2.4 以降)

  • MySQL Cluster NDB 7.1 GA リリース (7.1.3 以降)

  • MySQL Cluster NDB 7.0 GA リリース (7.0.5 以降)

  • MySQL Cluster NDB 7.1 にアップグレードできる MySQL Cluster NDB 6.3 GA リリース (6.3.8 以降)

MySQL Cluster NDB 6.3 以降の最近のリリースで使用される NDB APIClusterJ、およびその他のアプリケーションは、書き換えや再コンパイルをしなくても MySQL Cluster NDB 7.3.2 以降で引き続き使用できます。

MySQL Cluster NDB 7.3.3 以降から MySQL Cluster NDB 7.3.2 以前にオンラインでダウングレードすることはできません。MySQL Cluster NDB 7.3.2 からその後の MySQL Cluster NDB 7.3 リリースへのオンラインでのアップグレードはサポートされます。

18.3 MySQL Cluster の構成

MySQL Cluster の一部である MySQL サーバーが通常の (クラスタ化されていない) MySQL サーバーと大きく異なる点は、NDB ストレージエンジンを採用していることです。このエンジンは NDBCLUSTER と呼ばれることもありますが、NDB が推奨されます。

不要なリソースの割り当てを避けるため、デフォルトでは NDB ストレージエンジンを無効にするようにサーバーが構成されます。NDB を有効にするには、サーバーの my.cnf 構成ファイルを変更するか、--ndbcluster オプションを指定してサーバーを起動する必要があります。

この MySQL サーバーはクラスタの一部であるため、管理ノードにアクセスしてクラスタ構成データを取得する方法も認識する必要があります。デフォルトの動作では、localhost 上の管理ノードを検索します。ただし、それがほかの場所であることを指定する必要がある場合は、my.cnf で、または mysql クライアントを使用してこれを行います。NDB ストレージエンジンを使用する前に、少なくとも 1 つの管理ノードと必要なデータノードが使用可能である必要があります。

--ndbcluster および MySQL Cluster に固有のその他の mysqld オプションの詳細は、セクション18.3.4.2「MySQL Cluster 用の MySQL Server オプション」を参照してください。

MySQL Cluster NDB 7.3.1 以降では、MySQL Cluster Auto-Installer を使用して、ブラウザベースの GUI を使用する 1 台以上のホストに MySQL Cluster をセットアップおよび配備できます。詳細は、セクション18.2.1「MySQL Cluster Auto-Installer」を参照してください。

MySQL Cluster のインストールに関する一般情報は、セクション18.2「MySQL Cluster のインストール」を参照してください。

18.3.1 MySQL Cluster の簡易テストセットアップ

ここでは、基本を習得するため、実用的な MySQL Cluster のもっとも簡単な構成について説明します。その後、この章の関連するほかのセクションに示した情報から、必要なセットアップを設計できるようになります。

最初に、システムの root ユーザーとして次のコマンドを実行して、/var/lib/mysql-cluster などの構成ディレクトリを作成する必要があります。

shell> mkdir /var/lib/mysql-cluster

このディレクトリで、次の情報を含む config.ini という名前のファイルを作成します。必要に応じて、HostName および DataDir をシステムの適切な値に置き換えます。

# file "config.ini" - showing minimal setup consisting of 1 data node,
# 1 management server, and 3 MySQL servers.
# The empty default sections are not required, and are shown only for
# the sake of completeness.
# Data nodes must provide a hostname but MySQL Servers are not required
# to do so.
# If you don't know the hostname for your machine, use localhost.
# The DataDir parameter also has a default value, but it is recommended to
# set it explicitly.
# Note: [db], [api], and [mgm] are aliases for [ndbd], [mysqld], and [ndb_mgmd],
# respectively. [db] is deprecated and should not be used in new installations.
[ndbd default]
NoOfReplicas= 1
[mysqld default]
[ndb_mgmd default]
[tcp default]
[ndb_mgmd]
HostName= myhost.example.com
[ndbd]
HostName= myhost.example.com
DataDir= /var/lib/mysql-cluster
[mysqld]
[mysqld]
[mysqld]

これで、ndb_mgmd 管理サーバーを起動できるようになりました。デフォルトでは現在の作業ディレクトリ内にある config.ini ファイルの読み取りが試行されるため、このファイルが配置されているディレクトリに場所を移動してから ndb_mgmd を起動します。

shell> cd /var/lib/mysql-clustershell> ndb_mgmd

次に、ndbd を実行して 1 つのデータノードを起動します。

shell> ndbd

ndbd の起動時に使用できるコマンド行オプションについては、セクション18.4.27「MySQL Cluster プログラムに共通するオプション — MySQL Cluster プログラムに共通するオプション」を参照してください。

デフォルトでは、ndbdlocalhost のポート 1186 で管理サーバーを検索します。

注記

バイナリ tarball から MySQL をインストールした場合は、ndb_mgmd および ndbd サーバーのパスを明示的に指定する必要があります。(通常、これらは /usr/local/mysql/bin にあります。)

最後に、MySQL データディレクトリ (通常は /var/lib/mysql または /usr/local/mysql/data) に場所を変更して、NDB ストレージエンジンを有効にするのに必要なオプションが my.cnf ファイルに含まれていることを確認します。

[mysqld]
ndbcluster

これで、MySQL サーバーを通常どおり起動できるようになりました。

shell> mysqld_safe --user=mysql &

しばらく待ってから、MySQL サーバーが適切に実行されていることを確認します。「mysql ended」という通知が表示された場合は、サーバーの .err ファイルをチェックして、どのような不具合があったかを調べます。

ここまで問題なく進んだ場合は、クラスタを使用し始めることができます。サーバーに接続して、NDBCLUSTER ストレージエンジンが有効になっていることを確認します。

shell> mysqlWelcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.6.23
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> SHOW ENGINES\G...
*************************** 12. row ***************************
Engine: NDBCLUSTER
Support: YES
Comment: Clustered, fault-tolerant, memory-based tables
*************************** 13. row ***************************
Engine: NDB
Support: YES
Comment: Alias for NDBCLUSTER
...

前の出力例に表示されている行番号は、サーバーの構成方法によっては、使用しているシステムで表示されるものと異なる可能性があります。

NDBCLUSTER テーブルを作成してみます。

shell> mysqlmysql> USE test;Database changed
mysql> CREATE TABLE ctest (i INT) ENGINE=NDBCLUSTER;Query OK, 0 rows affected (0.09 sec)
mysql> SHOW CREATE TABLE ctest \G*************************** 1. row *************************** Table: ctest
Create Table: CREATE TABLE `ctest` ( `i` int(11) default NULL
) ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

ノードが適切にセットアップされたことをチェックするには、管理クライアントを起動します。

shell> ndb_mgm

クラスタのステータスに関するレポートを取得するには、管理クライアント内で SHOW コマンドを使用します。

ndb_mgm> SHOWCluster Configuration
---------------------
[ndbd(NDB)] 1 node(s)
id=2 @127.0.0.1 (Version: 5.6.22-ndb-7.4.4, Nodegroup: 0, *)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @127.0.0.1 (Version: 5.6.22-ndb-7.4.4)
[mysqld(API)] 3 node(s)
id=3 @127.0.0.1 (Version: 5.6.22-ndb-7.4.4)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)

この時点で、機能する MySQL Cluster が正常にセットアップされました。これで、ENGINE=NDBCLUSTER またはそのエイリアスである ENGINE=NDB を指定して作成したテーブルを使用して、クラスタにデータを格納できます。

18.3.2 MySQL Cluster の構成ファイル

MySQL Cluster を構成するには、2 つのファイルを操作する必要があります。

  • my.cnf: MySQL Cluster のすべての実行可能ファイルのオプションを指定します。このファイルは、(これまでの MySQL の使用経験からご存じのとおり) クラスタ内で実行されている個々の実行可能ファイルからアクセスできる必要があります。

  • config.ini: このファイルは、グローバル構成ファイルとも呼ばれますが、MySQL Cluster 管理サーバーからのみ読み取られます。管理サーバーに格納された情報は、クラスタに参加しているすべてのプロセスに配布されます。config.ini には、クラスタに関与する各ノードの記述が含まれています。これには、データノードに関する構成パラメータと、クラスタ内のすべてのノード間の接続に関する構成パラメータが含まれます。このファイルに含まれる可能性があるセクションと各セクションに配置される構成パラメータの種類を簡単に確認するには、「config.ini ファイルのセクション」を参照してください。

構成データのキャッシュ  MySQL Cluster NDB 7.3 以降では、NDBステートフル構成を使用します。管理サーバーは、再起動されるたびにグローバル構成ファイルを読み取るのではなく、最初の起動時に構成をキャッシュし、その後は次の条件のいずれかが true である場合にのみグローバル構成ファイルを読み取ります。

  • --initial オプションを使用すると管理サーバーが起動します  この場合は、グローバル構成ファイルが再度読み取られ、既存のキャッシュファイルが削除され、管理サーバーによって新しい構成キャッシュが作成されます。

  • --reload オプションを使用すると管理サーバーが起動します  この場合は、管理サーバーのキャッシュとグローバル構成ファイルが比較されます。これらが異なる場合は、管理サーバーによって新しい構成キャッシュが作成されます。既存の構成キャッシュは保持されますが、使用されません。管理サーバーのキャッシュとグローバル構成ファイルに同じ構成データが含まれている場合は、既存のキャッシュが使用され、新しいキャッシュは作成されません。

  • --config-cache オプションを使用すると管理サーバーが起動します  このオプションを使用すると、管理サーバーは構成キャッシュを完全にバイパスします。この場合、管理サーバーは存在する可能性がある構成ファイルを無視し、常に config.ini ファイルからその構成データを読み取ります。

  • 構成キャッシュがみつかりません  この場合、管理サーバーはグローバル構成ファイルを読み取り、そのファイルと同じ構成データを含むキャッシュを作成します。

構成キャッシュファイル  管理サーバーは、デフォルトで MySQL インストールディレクトリ内の mysql-cluster という名前のディレクトリに構成キャッシュファイルを作成します。(Unix システムでソースから MySQL Cluster をビルドした場合、デフォルトの場所は /usr/local/mysql-cluster です。)これは、--configdir オプションを指定して管理サーバーを起動すると、実行時にオーバーライドできます。構成キャッシュファイルは、ndb_node_id_config.bin.seq_id というパターンで命名されるバイナリファイルです。node_id は管理サーバーのクラスタ内のノード ID で、seq_id はキャッシュの識別子です。キャッシュファイルには、作成された順に seq_id を使用して連番が付けられます。管理サーバーは、seq_id で特定される最新のキャッシュファイルを使用します。

注記

あとの構成キャッシュファイルを削除するか、seq_id が大きくなるように前のキャッシュファイルの名前を変更すると、前の構成にロールバックできます。ただし、構成キャッシュファイルはバイナリ形式で書き込まれるため、その内容を手動で編集しないでください。

MySQL Cluster 管理サーバーの --configdir--config-cache--initial、および --reload オプションの詳細は、セクション18.4.4「ndb_mgmd — MySQL Cluster 管理サーバーデーモン」を参照してください。

クラスタ構成の改良とこのプロセスを簡素化する試みを継続的に行なっています。下位互換性の維持に努めていますが、場合によっては互換性のない変更が行われる可能性があります。下位互換のない変更の場合には、クラスタのユーザーに事前に通知するように努めます。このような変更を発見し、それに関する情報が提供されていない場合は、セクション1.6「質問またはバグをレポートする方法」に示した手順を使用して MySQL バグデータベースに報告してください。

18.3.2.1 MySQL Cluster 構成の基本的な例

MySQL Cluster をサポートするには、次の例に示すように my.cnf を更新する必要があります。これらのパラメータを実行可能ファイルの起動時にコマンド行に指定することもできます。

注記

ここに示すオプションを、config.ini グローバル構成ファイルで使用されるものと混同しないようにしてください。グローバル構成オプションについては、このセクションで後述します。

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (valid in MySQL 5.6)
# enable ndbcluster storage engine, and provide connection string for
# management server host (default port is 1186)
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com
# provide connection string for management server host (default port: 1186)
[ndbd]
connect-string=ndb_mgmd.mysql.com
# provide connection string for management server host (default port: 1186)
[ndb_mgm]
connect-string=ndb_mgmd.mysql.com
# provide location of cluster configuration file
[ndb_mgmd]
config-file=/etc/config.ini

(接続文字列の詳細は、セクション18.3.2.3「MySQL Cluster の接続文字列」を参照してください。)

# my.cnf
# example additions to my.cnf for MySQL Cluster
# (will work on all versions)
# enable ndbcluster storage engine, and provide connection string for management
# server host to the default port 1186
[mysqld]
ndbcluster
ndb-connectstring=ndb_mgmd.mysql.com:1186
重要

前に示したように、my.cnf ファイルの [mysqld]NDBCLUSTER および ndb-connectstring パラメータを指定して mysqld プロセスを起動したあとは、クラスタを実際に起動しないと、CREATE TABLE または ALTER TABLE ステートメントを実行できません。そうでない場合、これらのステートメントはエラーで失敗します。これは意図的なものです

クラスタの my.cnf ファイルでは、すべての実行可能ファイルによって読み取られ、使用される設定で別個の [mysql_cluster] セクションを使用することもできます。

# cluster-specific settings
[mysql_cluster]
ndb-connectstring=ndb_mgmd.mysql.com:1186

my.cnf ファイルに設定できる追加の NDB 変数については、セクション18.3.4.3「MySQL Cluster のシステム変数」を参照してください。

MySQL Cluster のグローバル構成ファイルには、慣例で config.ini という名前が付けられています (ただし、これは必須ではありません)。これは、必要に応じて ndb_mgmd が起動時に読み取るため、読み取りが可能な任意の場所に配置できます。構成の場所と名前は、コマンド行の ndb_mgmd--config-file=path_name を使用して指定します。このオプションにデフォルト値はなく、ndb_mgmd で構成キャッシュを使用する場合、このオプションは無視されます。

MySQL Cluster のグローバル構成では、複数のセクションからなる INI 形式が使用されます。各セクションの先頭には (角括弧で囲まれた) セクション見出しが付き、そのあとに適切なパラメータ名と値が続きます。標準の INI 形式との違いの 1 つは、パラメータ名と値を等号 (=) だけでなくコロン (:) で区切ることもできることです (ただし、等号が推奨されます)。もう 1 つの違いは、セクションがセクション名で一意に識別されないことです。代わりに、一意のセクション (同じタイプの 2 つの異なるノードなど) はセクション内のパラメータとして指定された一意の ID で識別されます。

デフォルト値は、ほとんどのパラメータに定義されており、config.ini で指定することもできます。デフォルト値のセクションを作成するには、セクション名に default という単語を追加します。たとえば、[ndbd] セクションには特定のデータノードに適用されるパラメータが含まれていますが、[ndbd default] セクションにはすべてのデータノードに適用されるパラメータが含まれています。すべてのデータノードが同じデータメモリーサイズを使用するとします。これらすべてを構成するには、データメモリーサイズを指定する DataMemory 行を含む [ndbd default] セクションを作成します。

注記

MySQL Cluster の一部の古いリリースでは、NoOfReplicas のデフォルト値が存在しないため、常に [ndbd default] セクションに明示的にその値を指定する必要がありました。現在、このパラメータのデフォルト値はほとんどの一般的な使用シナリオでの推奨設定である 2 になっていますが、今後もこのパラメータを明示的に設定することが推奨されます。

グローバル構成ファイルでは、クラスタに関与するコンピュータとノード、およびノードをどのコンピュータに配置するかを定義する必要があります。1 つの管理サーバー、2 つのデータノード、および 2 つの MySQL サーバーで構成されるクラスタ用の簡単な構成ファイルの例をここに示します。

# file "config.ini" - 2 data nodes and 2 SQL nodes
# This file is placed in the startup directory of ndb_mgmd (the
# management server)
# The first MySQL Server can be started from any host. The second
# can be started only on the host mysqld_5.mysql.com
[ndbd default]
NoOfReplicas= 2
DataDir= /var/lib/mysql-cluster
[ndb_mgmd]
Hostname= ndb_mgmd.mysql.com
DataDir= /var/lib/mysql-cluster
[ndbd]
HostName= ndbd_2.mysql.com
[ndbd]
HostName= ndbd_3.mysql.com
[mysqld]
[mysqld]
HostName= mysqld_5.mysql.com
注記

前の例は、MySQL Cluster に習熟するために必要な最小限の初期構成であり、本番環境の設定としては不十分です。完全な初期構成例については、セクション18.3.2.2「MySQL Cluster の推奨される初期構成」を参照してください。

config.ini ファイルには、各ノードに固有のセクションがあります。たとえば、このクラスタには 2 つのデータノードがあるため、前に示した構成ファイルにはこれらのノードを定義する 2 つの [ndbd] セクションがあります。

注記

config.ini ファイルでは、セクション見出しと同じ行にコメントを配置しないでください。これを行うと、管理サーバーはこのような構成ファイルを解析できないため、起動しなくなります。

config.ini ファイルのセクション

次のリストで説明するように、config.ini 構成ファイルでは 6 つの異なるセクションを使用できます。

セクションごとに default 値を定義できます。my.cnf または my.ini ファイルに指定されるパラメータと異なり、すべてのクラスタパラメータ名は大文字と小文字を区別しません。

18.3.2.2 MySQL Cluster の推奨される初期構成

MySQL Cluster で最良のパフォーマンスを実現できるかどうかは、次を含むいくつかの要因に依存します。

  • MySQL Cluster ソフトウェアのバージョン

  • データノードおよび SQL ノードの数

  • ハードウェア

  • オペレーティングシステム

  • 格納されるデータの量

  • クラスタ稼働時の負荷のサイズとタイプ

このため、最適な構成を獲得するプロセスは反復的なものになる可能性が高く、その結果は個々の MySQL Cluster 配備によって大きく異なる可能性があります。クラスタが動作するプラットフォームや MySQL Cluster のデータを使用するアプリケーションに変更が加えられたときは、構成の変更も必要になる可能性があります。これらの理由により、すべての使用シナリオに適した単一の構成を提示することは不可能です。ただし、このセクションでは推奨されるベース構成を示します。

初期の config.ini ファイル  MySQL Cluster NDB 7.3 以降を実行するクラスタ構成の開始点として、次の config.ini ファイルを推奨します。

# TCP PARAMETERS
[tcp default]SendBufferMemory=2MReceiveBufferMemory=2M
# Increasing the sizes of these 2 buffers beyond the default values
# helps prevent bottlenecks due to slow disk I/O.
# MANAGEMENT NODE PARAMETERS
[ndb_mgmd default]DataDir=path/to/management/server/data/directory# It is possible to use a different data directory for each management
# server, but for ease of administration it is preferable to be
# consistent.
[ndb_mgmd]HostName=management-server-A-hostname# NodeId=management-server-A-nodeid[ndb_mgmd]HostName=management-server-B-hostname# NodeId=management-server-B-nodeid# Using 2 management servers helps guarantee that there is always an
# arbitrator in the event of network partitioning, and so is
# recommended for high availability. Each management server must be
# identified by a HostName. You may for the sake of convenience specify
# a NodeId for any management server, although one will be allocated
# for it automatically; if you do so, it must be in the range 1-255
# inclusive and must be unique among all IDs specified for cluster
# nodes.
# DATA NODE PARAMETERS
[ndbd default]NoOfReplicas=2
# Using 2 replicas is recommended to guarantee availability of data;
# using only 1 replica does not provide any redundancy, which means
# that the failure of a single data node causes the entire cluster to
# shut down. We do not recommend using more than 2 replicas, since 2 is
# sufficient to provide high availability, and we do not currently test
# with greater values for this parameter.LockPagesInMainMemory=1
# On Linux and Solaris systems, setting this parameter locks data node
# processes into memory. Doing so prevents them from swapping to disk,
# which can severely degrade cluster performance.DataMemory=3072MIndexMemory=384M
# The values provided for DataMemory and IndexMemory assume 4 GB RAM
# per data node. However, for best results, you should first calculate
# the memory that would be used based on the data you actually plan to
# store (you may find the ndb_size.pl utility helpful in estimating
# this), then allow an extra 20% over the calculated values. Naturally,
# you should ensure that each data node host has at least as much
# physical memory as the sum of these two values.
# ODirect=1
# Enabling this parameter causes NDBCLUSTER to try using O_DIRECT
# writes for local checkpoints and redo logs; this can reduce load on
# CPUs. We recommend doing so when using MySQL Cluster on systems running
# Linux kernel 2.6 or later.NoOfFragmentLogFiles=300DataDir=path/to/data/node/data/directoryMaxNoOfConcurrentOperations=100000SchedulerSpinTimer=400SchedulerExecutionTimer=100RealTimeScheduler=1
# Setting these parameters allows you to take advantage of real-time scheduling
# of NDB threads to achieve increased throughput when using ndbd. They
# are not needed when using ndbmtd; in particular, you should not set
# RealTimeScheduler for ndbmtd data nodes.TimeBetweenGlobalCheckpoints=1000TimeBetweenEpochs=200DiskCheckpointSpeed=10MDiskCheckpointSpeedInRestart=100MRedoBuffer=32M
# CompressedLCP=1
# CompressedBackup=1
# Enabling CompressedLCP and CompressedBackup causes, respectively, local
checkpoint files and backup files to be compressed, which can result in a space
savings of up to 50% over noncompressed LCPs and backups.
# MaxNoOfLocalScans=64MaxNoOfTables=1024MaxNoOfOrderedIndexes=256
[ndbd]HostName=data-node-A-hostname# NodeId=data-node-A-nodeidLockExecuteThreadToCPU=1LockMaintThreadsToCPU=0
# On systems with multiple CPUs, these parameters can be used to lock NDBCLUSTER
# threads to specific CPUs
[ndbd]HostName=data-node-B-hostname# NodeId=data-node-B-nodeidLockExecuteThreadToCPU=1LockMaintThreadsToCPU=0
# You must have an [ndbd] section for every data node in the cluster;
# each of these sections must include a HostName. Each section may
# optionally include a NodeId for convenience, but in most cases, it is
# sufficient to allow the cluster to allocate node IDs dynamically. If
# you do specify the node ID for a data node, it must be in the range 1
# to 48 inclusive and must be unique among all IDs specified for
# cluster nodes.
# SQL NODE / API NODE PARAMETERS
[mysqld]
# HostName=sql-node-A-hostname# NodeId=sql-node-A-nodeid[mysqld]
[mysqld]
# Each API or SQL node that connects to the cluster requires a [mysqld]
# or [api] section of its own. Each such section defines a connection
# slot; you should have at least as many of these sections in the
# config.ini file as the total number of API nodes and SQL nodes that
# you wish to have connected to the cluster at any given time. There is
# no performance or other penalty for having extra slots available in
# case you find later that you want or need more API or SQL nodes to
# connect to the cluster at the same time.
# If no HostName is specified for a given [mysqld] or [api] section,
# then any API or SQL node may use that slot to connect to the
# cluster. You may wish to use an explicit HostName for one connection slot
# to guarantee that an API or SQL node from that host can always
# connect to the cluster. If you wish to prevent API or SQL nodes from
# connecting from other than a desired host or hosts, then use a
# HostName for every [mysqld] or [api] section in the config.ini file.
# You can if you wish define a node ID (NodeId parameter) for any API or
# SQL node, but this is not necessary; if you do so, it must be in the
# range 1 to 255 inclusive and must be unique among all IDs specified
# for cluster nodes.

推奨される SQL ノードの my.cnf オプション  MySQL Cluster SQL ノードとして機能する MySQL サーバーは、常にコマンド行または my.cnf--ndbcluster および --ndb-connectstring オプションを指定して起動する必要があります。さらに、セットアップでほかのオプションを必要とする場合を除き、クラスタ内のすべての mysqld プロセスに次のオプションを設定してください。

  • --ndb-use-exact-count=0

  • --ndb-index-stat-enable=0

  • --ndb-force-send=1

  • --engine-condition-pushdown=1

18.3.2.3 MySQL Cluster の接続文字列

MySQL Cluster 管理サーバー (ndb_mgmd) を除き、MySQL Cluster の一部となる各ノードには、管理サーバーの場所を指定する接続文字列が必要です。この接続文字列は、管理サーバーとの接続を確立するときに使用されるほか、クラスタ内でのノードの役割によっては、ほかのタスクを実行するときにも使用されます。接続文字列の構文は次のとおりです。

[nodeid=node_id, ]host-definition[, host-definition[, ...]]host-definition: host_name[:port_number]

node_id は、config.ini 内のノードを識別する 1 以上の整数です。host_name は、有効なインターネット名または IP アドレスを表す文字列です。port_number は、TCP/IP ポート番号を参照する整数です。

example 1 (long): "nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
example 2 (short): "myhost1"

何も指定されなかった場合は、デフォルトの接続文字列値として localhost:1186 が使用されます。接続文字列から port_num が省略された場合、デフォルトポートは 1186 です。このポートは、この目的のために IANA によって割り当てられたものであるため、ネットワーク上で常に使用可能です (詳細は、http://www.iana.org/assignments/port-numbersを参照してください)。

複数のホスト定義を列挙すると、複数の冗長管理サーバーを指定できます。MySQL Cluster のデータまたは API ノードは、正常な接続が確立されるまで、各ホスト上の連続する管理サーバーへの接続を指定された順序で試行します。

接続文字列には、管理サーバーに接続する複数のネットワークインタフェースを持つノードで使用される 1 つ以上のバインドアドレスを指定することもできます。バインドアドレスは、ホスト名またはネットワークアドレスと、オプションのポート番号で構成されます。この拡張された接続文字列の構文をここに示します。

[nodeid=node_id, ] [bind-address=host-definition, ] host-definition[; bind-address=host-definition] host-definition[; bind-address=host-definition] [, ...]]host-definition: host_name[:port_number]

接続文字列で管理ホストを指定する前に 1 つのバインドアドレスを使用すると、そのアドレスは管理ホストのいずれかに接続するためのデフォルトとして使用されます (特定の管理サーバーにオーバーライドされた場合を除きます。例については、このセクションで後述します)。たとえば、次の接続文字列によって、このノードは接続先の管理サーバーに関係なく 192.168.178.242 を使用します。

bind-address=192.168.178.242, poseidon:1186, perch:1186

管理ホストの定義のあとにバインドアドレスを指定すると、そのアドレスはその管理ノードへの接続でのみ使用されます。次の接続文字列について考えます。

poseidon:1186;bind-address=localhost, perch:1186;bind-address=192.168.178.242

この場合、ノードは poseidon という名前のホストで実行されている管理サーバーに接続するために localhost を使用し、perch という名前のホストで実行されている管理サーバーに接続するために 192.168.178.242 を使用します。

デフォルトのバインドアドレスを指定してから、1 台以上の管理ホストにこのデフォルトをオーバーライドできます。次の例では、ホスト poseidon で実行されている管理サーバーに接続するために localhost が使用されます。192.168.178.242 は、最初に (どの管理サーバーの定義よりも前に) 指定されているため、デフォルトのバインドアドレスであり、ホスト perch および orca 上の管理サーバーに接続するために使用されます。

bind-address=192.168.178.242,poseidon:1186;bind-address=localhost,perch:1186,orca:2200

接続文字列を指定するには、いくつかの異なる方法があります。

  • 各実行可能ファイルには、起動時に管理サーバーを指定できる固有のコマンド行オプションがあります。(各実行可能ファイルのドキュメントを参照してください。)

  • 管理サーバーの my.cnf ファイルの [mysql_cluster] セクションに接続文字列を配置することで、クラスタ内のすべてのノードの接続文字列を同時に設定することもできます。

  • 下位互換性のため、同じ構文を使用するオプションがほかに 2 つ用意されています。

    1. NDB_CONNECTSTRING 環境変数を設定して、接続文字列を含めます。

    2. 各実行可能ファイル用の接続文字列を Ndb.cfg という名前のテキストファイルに記述し、このファイルを実行可能ファイルの起動ディレクトリに配置します。

    ただし、これらは現在非推奨であり、新しいインストールに使用しないでください。

推奨される接続文字列の指定方法は、各実行可能ファイルのコマンド行または my.cnf ファイルでの設定です。

18.3.2.4 MySQL Cluster 内のコンピュータの定義

[computer] セクションは、システム内の各ノードのホスト名を定義しないで済む方法を提供する以外は、基本的には重要ではありません。ここに示すすべてのパラメータは必須です。

  • Id

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0文字列[none]...IS

    これは、構成ファイルに含まれるホストコンピュータを参照するために使用する一意の識別子です。

    重要

    コンピュータ ID は、管理、API、またはデータノードに使用するノード ID とは異なります。ノード ID の場合と異なり、config.ini ファイルの [computer] セクションでは、Id の代わりに NodeId を使用できません。

  • HostName

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    これは、コンピュータのホスト名または IP アドレスです。

18.3.2.5 MySQL Cluster 管理サーバーの定義

[ndb_mgmd] セクションは、管理サーバーの動作を構成するために使用されます。複数の管理サーバーが採用されている場合は、それらのすべてに共通するパラメータを [ndb_mgmd default] セクションに指定できます。[mgm][mgm default] はこれらの古いエイリアスで、下位互換性に対応しています。

次のリストに示すパラメータはすべてオプションであり、省略した場合はデフォルト値が使用されます。

注記

ExecuteOnComputer パラメータと HostName パラメータがどちらも存在しない場合は、デフォルト値の localhost が両方に使用されます。

  • Id

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]1 - 255IS

    クラスタ内の各ノードは一意の ID を持っています。管理ノードの場合、これは 1-255 の (これらを含む) 範囲の整数値で表されます。この ID はすべての内部クラスタメッセージでノードを解決するために使用されるため、ノードのタイプに関係なく、各 MySQL Cluster ノードで一意である必要があります。

    注記

    データノードの ID は、49 未満にする必要があります。多数のデータノードを配備する予定の場合は、管理ノード (および API ノード) のノード ID を 48 より大きい値に制限することをお勧めします。

    Id パラメータを使った管理ノードの識別は、NodeId を優先するため非推奨になりました。Id は、下位互換性に引き続き対応しますが、現在は警告を生成するようになっており、MySQL Cluster の今後のバージョンで削除される予定です。

  • NodeId

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]1 - 255IS

    クラスタ内の各ノードは一意の ID を持っています。管理ノードでは、これは 1-255 の (これらを含む) 範囲の整数値で表されます。この ID はすべての内部クラスタメッセージでノードを解決するために使用されるため、ノードのタイプに関係なく、各 MySQL Cluster ノードで一意である必要があります。

    注記

    データノードの ID は、49 未満にする必要があります。多数のデータノードを配備する予定の場合は、管理ノード (および API ノード) のノード ID を 48 より大きい値に制限することをお勧めします。

    NodeId は、管理ノードを識別時の使用が推奨されるパラメータ名です。古い Id は、下位互換性に引き続き対応しますが、現在は非推奨であり、使用時に警告を生成します。また、MySQL Cluster の今後のリリースで削除される予定です。

  • ExecuteOnComputer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0name[none]...S

    これは、config.ini ファイルの [computer] セクションに定義されたいずれかのコンピュータに設定されている Id を参照します。

  • PortNumber

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし11860 - 64KN

    これは、管理サーバーが構成要求と管理コマンドを待機するポートの番号です。

  • HostName

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    このパラメータを指定すると、管理ノードを配置するコンピュータのホスト名が定義されます。localhost 以外のホスト名を指定するには、このパラメータまたは ExecuteOnComputer のどちらかが必要です。

  • LogDestination

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0{CONSOLE|SYSLOG|FILE}[テキストを参照]...N

    このパラメータは、クラスタのロギング情報の送信先を指定します。これには CONSOLESYSLOGFILE の 3 つのオプションがあり、FILE がデフォルトです。

    • CONSOLE では、stdout にログが出力されます。

      CONSOLE
    • SYSLOG では、syslog 機能にログが送信されます。指定できる値は、authauthprivcrondaemonftpkernlprmailnewssysloguseruucplocal0local1local2local3local4local5local6local7 のいずれかです。

      注記

      すべてのオペレーティングシステムで必ずしもすべての機能がサポートされるとはかぎりません。

      SYSLOG:facility=syslog
    • FILE では、クラスタのログ出力が同じマシン上の通常のファイルにパイプされます。次の値を指定できます。

      • filename: ログファイルの名前。

        MySQL Cluster NDB 7.3 以降では、このような場合に使用されるデフォルトのログファイル名は ndb_nodeid_cluster.log です (一部の古いバージョンでは、filename を設定せずに FILE を指定した場合に使用されるデフォルトのログファイル名は logger.log でした)。

      • maxsize: ロギングが新しいファイルにロールオーバーされる前のファイルの最大サイズ (バイト単位)。これが発生すると、古いログファイルの名前が変更され、ファイル名の末尾に .N が追加されます (N はこの名前に対してまだ使用されていない次の番号です)。

      • maxfiles: ログファイルの最大数。

      FILE:filename=cluster.log,maxsize=1000000,maxfiles=6

      FILE パラメータのデフォルト値は、FILE:filename=ndb_node_id_cluster.log,maxsize=1000000,maxfiles=6 です (node_id はノードの ID です)。

    ここに示すように、複数のログの保存先をセミコロンで区切って指定できます。

    CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
  • ArbitrationRank

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.00-210 - 2N

    このパラメータは、アービトレータとして機能するノードを定義するために使用されます。アービトレータにできるのは、管理ノードと SQL ノードだけです。ArbitrationRank には次のいずれかの値を指定できます。

    • 0: このノードはアービトレータとして使用できません。

    • 1: このノードは高い優先度を持っており、優先度の低いノードより優先的にアービトレータになります。

    • 2: 優先度の高いノードがこの目的で使用できない場合にのみアービトレータとして使用される、優先度の低いノードを示します。

    通常は、管理サーバーの ArbitrationRank を 1 (管理ノードのデフォルト) に設定し、すべての SQL ノードを 0 (SQL ノードのデフォルト) に設定することにより、管理サーバーをアービトレータとして構成してください。

    すべての管理および SQL ノードで ArbitrationRank を 0 に設定するか、config.ini グローバル構成ファイルの [ndbd default] セクションに Arbitration パラメータを設定することで、アービトレーションを完全に無効化できます。Arbitration を設定すると、ArbitrationRank の設定はすべて無視されます。

  • ArbitrationDelay

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒00 - 4294967039 (0xFFFFFEFF)N

    アービトレーション要求に対する管理サーバーの応答をミリ秒数だけ遅らせるための整数値。デフォルトでは、この値は 0 です。通常、これを変更する必要はありません。

  • DataDir

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0パス....N

    これは、管理サーバーの出力ファイルを配置するディレクトリを指定します。これらのファイルには、クラスタのログファイル、プロセスの出力ファイル、およびデーモンのプロセス ID (PID) ファイルが含まれます。(ログファイルでは、LogDestinationFILE パラメータをこのセクションで前述したように設定することで、この場所をオーバーライドできます。)

    このパラメータのデフォルト値は、ndb_mgmd が配置されているディレクトリです。

  • PortNumberStats

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]0 - 64KN

    このパラメータは、MySQL Cluster 管理サーバーから統計情報を取得するために使用されるポート番号を指定します。デフォルト値はありません。

  • Wan

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    WAN の TCP 設定をデフォルトとして使用します。

  • HeartbeatThreadPriority

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0文字列[none]...S

    管理および API ノードのハートビートスレッドのスケジューリングポリシーと優先度を設定します。

    このパラメータを設定するための構文をここに示します。

    HeartbeatThreadPriority = policy[, priority]policy: {FIFO | RR}

    このパラメータを設定するときは、ポリシーを指定する必要があります。これは、FIFO (先入れ先出し) または RR (ラウンドロビン) のいずれかです。オプションで、ポリシー値のあとに優先度 (整数) を指定できます。

  • TotalSendBufferMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト256K0 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、すべての構成済みトランスポータ間で共有される送信バッファーメモリーの、このノードに割り当てられるメモリー合計量を決定するために使用されます。

    このパラメータを設定する場合、許容される最小値は 256K バイト、最大値は 4294967039 です。TotalSendBufferMemory の動作と使用、および送信バッファーメモリーパラメータの構成の詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

  • HeartbeatIntervalMgmdMgmd

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒1500100 - 4294967039 (0xFFFFFEFF)N
    NDB 7.3.3ミリ秒1500100 - 4294967039 (0xFFFFFEFF)N

    別の管理ノードがこの管理ノードに接続しているかどうかを判定するために使用されるハートビートメッセージの間隔を指定します。管理ノードは、この間隔を 3 回待ったあとで接続の切断を宣言します。このため、デフォルト設定の 1500 ミリ秒では、管理ノードはおよそ 1600 ミリ秒待ってからタイムアウトします。

    このパラメータは MySQL Cluster NDB 7.3.3 で追加されました。(Bug #16426805)

注記

管理ノードの構成を変更したあとは、新しい構成を有効にするためにクラスタのローリング再起動を実行する必要があります。

実行中の MySQL Cluster に新しい管理サーバーを追加するには、既存の config.ini ファイルを変更したあとで、すべてのクラスタノードのローリング再起動を実行する必要もあります。複数の管理ノードを使用するときに発生する問題の詳細は、セクション18.1.6.10「複数の MySQL Cluster ノードに関する制限」を参照してください。

18.3.2.6 MySQL Cluster データノードの定義

クラスタのデータノードの動作を構成するには、[ndbd] および [ndbd default] セクションを使用します。

データノードのプロセスとして ndbd バイナリと ndbmtd バイナリのどちらを使用する場合でも、セクション名としては常に [ndbd][ndbd default] が使用されます。

バッファーサイズ、プールサイズ、タイムアウトなどを制御する数多くのパラメータがあります。唯一の必須パラメータは、ExecuteOnComputer または HostName のいずれかです。これは、ローカルの [ndbd] セクションで定義する必要があります。

NoOfReplicas パラメータは、すべてのクラスタデータノードに共通であるため、[ndbd default] セクションに定義してください。NoOfReplicas を設定する必要は必ずしもありませんが、これを明示的に設定することをお勧めします。

ほとんどのデータノードパラメータは [ndbd default] セクションに設定します。[ndbd] セクションでの変更が許可されるのは、ローカル値の設定を明示的に規定されているパラメータだけです。HostNameNodeId、および ExecuteOnComputer (存在する場合) は、config.ini のほかのセクションではなく、ローカルの [ndbd] で定義する必要があります。つまり、これらのパラメータの設定は 1 つのデータノードに固有のものです。

メモリー使用状況やバッファーサイズに影響を与えるパラメータでは、1024、1024 * 1024、または 1024 * 1024 * 1024 の単位を示すサフィクスとして KM、または G を使用できます。(たとえば、100K は 100 * 1024 = 102400 を意味します。)現在のところ、パラメータの名前と値では大文字と小文字を区別します。

MySQL Cluster ディスクデータのテーブルに固有の構成パラメータについては、このセクションで後述します (ディスクデータの構成パラメータを参照してください)。

これらすべてのパラメータは、ndbmtd (ndbd のマルチスレッドバージョン) にも適用されます。追加の 3 つのデータノード構成パラメータ (MaxNoOfExecutionThreadsThreadConfig、および NoOfFragmentLogParts) は、ndbmtd にのみ適用されます。これらを ndbd に使用しても、無効になります。詳細は、マルチスレッドの構成パラメータ (ndbmtd)を参照してください。セクション18.4.3「ndbmtd — MySQL Cluster データノードデーモン (マルチスレッド)」も参照してください。

データノードの識別 NodeId または Id の値 (つまり、データノードの識別子) は、ノード起動時のコマンド行、または構成ファイルで割り当てることができます。

  • Id

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]1 - 48IS

    一意のノード ID は、クラスタのすべての内部メッセージでノードのアドレスとして使用されます。データノードでは、これは 1-48 の (これらを含む) 範囲の整数です。クラスタ内の各ノードは、一意の識別子を持っている必要があります。

    NodeId は、データノードの識別時での使用が推奨されるパラメータ名です。古い Id は、下位互換性に引き続き対応しますが、現在は非推奨であり、使用時に警告を生成します。Id は MySQL Cluster の今後のリリースで削除される予定です。

  • NodeId

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]1 - 48IS

    一意のノード ID は、クラスタのすべての内部メッセージでノードのアドレスとして使用されます。データノードでは、これは 1-48 の (これらを含む) 範囲の整数です。クラスタ内の各ノードは、一意の識別子を持っている必要があります。

    NodeId は、データノードの識別時での使用が推奨されるパラメータ名です。Id は、下位互換性に引き続き対応しますが、現在は非推奨であり、使用時に警告を生成します。また、MySQL Cluster の今後のバージョンで削除される予定です。

  • ExecuteOnComputer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0name[none]...S

    これは、[computer] セクションに定義されたいずれかのコンピュータに設定されている Id を参照します。

  • HostName

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレスlocalhost...N

    このパラメータを指定すると、データノードを配置するコンピュータのホスト名が定義されます。localhost 以外のホスト名を指定するには、このパラメータまたは ExecuteOnComputer のどちらかが必要です。

  • ServerPort

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]1 - 64KN

    クラスタ内の各ノードは、ほかのノードに接続するためにポートを使用します。デフォルトでは、このポートは同じホストコンピュータ上の 2 つのノードで同じポート番号を受け取らないよう動的に割り当てられるため、通常はこのパラメータの値を指定する必要はありません。

    ただし、データノートと API ノード (SQL ノードを含む) 間の通信を許可するため、ファイアウォールで特定のポートを開く必要がある場合は、config.ini ファイルの [ndbd] セクションまたは (複数のデータノードに対してこれを行う必要がある場合は) [ndbd default] セクションでこのパラメータを必要なポートの番号に設定すると、SQL ノード、API ノード、またはその両方からの着信接続のためにその番号のポートを開くことができます。

    注記

    データノードから管理ノードへの接続は ndb_mgmd 管理ポート (管理サーバーの PortNumberセクション18.3.2.5「MySQL Cluster 管理サーバーの定義」を参照してください) を使用して行われるため、データノードからポートへの送信接続は常に許可されます。

  • TcpBind_INADDR_ANY

    このパラメータを TRUE または 1 に設定すると、IP_ADDR_ANY がバインドされ、任意の場所から接続できるようになります (自動生成接続の場合)。デフォルトは FALSE (0) です。

  • NodeGroup

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0 [none]0 - 65536IS

    このパラメータを使用して、データノードを特定のノードグループに割り当てることができます。これはクラスタを最初に起動したときは読み取り専用であり、オンラインでデータノードを別のノードグループに再割り当てすることはできません。config.ini ファイルの [ndbd default] セクションでこのパラメータを使用することは、通常望ましくありません。また、ノードをノードグループに割り当てるときは、ノードグループに無効な数のノードが割り当てられないように注意する必要があります。

    NodeGroup パラメータの主な用途は、ローリング再起動を実行せずに実行中の MySQL Cluster に新しいノードグループを追加することです。そのためには、これを 65536 (最大値) に設定します。NodeGroup の値は、すべてのクラスタデータノードではなく、あとで起動され、新しいノードグループとしてクラスタに追加されるノードにのみ設定する必要があります。詳細は、セクション18.5.13.3「MySQL Cluster データノードのオンライン追加: 詳細な例」を参照してください。

  • NoOfReplicas

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数21 - 4IS

    このグローバルパラメータは、[ndbd default] セクションでのみ設定でき、クラスタに格納されている各テーブルのレプリカの数を定義します。このパラメータは、ノードグループのサイズも指定します。ノードグループは、すべてが同じ情報を格納するノードのセットです。

    ノードグループは暗黙的に形成されます。最初のノードグループはノード ID がもっとも小さいデータノードのセットで形成され、次のノードグループはノード ID が次に小さいデータノードのセットで形成されます (以下同様)。例として、4 つのデータノードがあり、NoOfReplicas が 2 に設定されているとします。4 つのデータノードのノード ID はそれぞれ 2、3、4、および 5 です。この場合、1 つ目のノードグループはノード 2 および 3 で形成され、2 つ目のノードグループはノード 4 および 5 で形成されます。1 つのハードウェアの障害によってクラスタ全体が機能停止するため、同じノードグループ内のノードが同じコンピュータに配置されないようにクラスタを構成することが重要です。

    ノード ID が指定されていない場合は、データノードの順序がノードグループの決定要因になります。明示的な割り当てが行われたかどうかに関係なく、管理クライアントの SHOW コマンドの出力に表示されます。

    NoOfReplicas のデフォルト値は 2 です。これは、ほとんどの一般的な使用シナリオで推奨される設定です。

    指定可能な最大値は 4 ですが、現時点で実際にサポートされている値は 1 と 2 だけです

    重要

    NoOfReplicas を 1 に設定することは、すべてのクラスタデータのコピーが 1 つだけ存在することを意味します。この場合は、そのデータに格納されているデータの追加のコピーが存在しないため、1 つのデータノードの喪失によってクラスタが機能停止します。

    このパラメータの値は、クラスタ内のデータノードの数で均等に割れる必要があります。たとえば、データノードが 2 つの場合、2/3 と 2/4 はどちらも小数値になるため、NoOfReplicas は 1 または 2 である必要があります。データノードが 4 つの場合、NoOfReplicas は 1、2、または 4 である必要があります。

  • DataDir

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0パス....IN

    このパラメータは、トレースファイル、ログファイル、PID ファイル、およびエラーログが配置されるディレクトリを指定します。

    デフォルトはデータノードプロセスの作業ディレクトリです。

  • FileSystemPath

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0パスDataDir...IN

    このパラメータは、メタデータ用に作成されるすべてのファイル、Redo ログ、Undo ログ (ディスクデータテーブル用)、およびデータファイルが配置されるディレクトリを指定します。デフォルトは、DataDir で指定されたディレクトリです。

    注記

    このディレクトリは、ndbd プロセスが開始される前に存在している必要があります。

    MySQL Cluster の推奨されるディレクトリ階層には /var/lib/mysql-cluster が含まれており、この下にノードのファイルシステム用のディレクトリが作成されます。このサブディレクトリの名前にはノード ID が含まれます。たとえば、ノード ID が 2 の場合、このサブディレクトリの名前は ndb_2_fs です。

  • BackupDataDir

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0パス[テキストを参照]...IN

    このパラメータは、バックアップが配置されるディレクトリを指定します。

    重要

    この値の末尾には常に '/BACKUP' という文字列が追加されます。たとえば、BackupDataDir の値を /var/lib/cluster-data に設定すると、すべてのバックアップが /var/lib/cluster-data/BACKUP の下に格納されます。これは、事実上のデフォルトのバックアップ場所が FileSystemPath パラメータで指定された場所の下にある BACKUP という名前のディレクトリであることも意味しています。

データメモリー、インデックスメモリー、および文字列メモリー

DataMemoryIndexMemory は、実際のレコードとインデックスの格納に使用されるメモリーセグメントのサイズを指定する [ndbd] パラメータです。これらの値を設定するときは、DataMemoryIndexMemory がどのように使用されるかを理解することが重要です。これらは、通常、クラスタでの実際の使用状況を反映して更新する必要があるためです。

  • DataMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト80M1M - 1024GN

    このパラメータは、データベースレコードの格納に使用できるスペースの量 (バイト単位) を定義します。この値によって指定される量の全体がメモリー内に割り当てられるため、それに対応できるだけの十分な物理メモリーがマシンに搭載されていることが非常に重要です。

    DataMemory によって割り当てられたメモリーは、実際のレコードとインデックスの両方を格納するために使用されます。各レコードには 16 バイトのオーバーヘッドがあります。各レコードは 128 バイトのページオーバーヘッドを含む 32K バイトのページに格納されるため、レコードごとに追加の量が発生します (次を参照してください)。また、各レコードが 1 つのページのみに格納されるため、ページごとに少量の無駄が発生します。

    可変サイズのテーブル属性については、DataMemory から割り当てられた別個のデータページにデータが格納されます。可変長レコードは、可変サイズ部分を参照するための 4 バイトの追加オーバーヘッドを含む固定サイズ部分を使用します。可変サイズ部分には、2 バイトのオーバーヘッドと属性あたり 2 バイトが含まれます。

    最大レコードサイズは 14000 バイトです。

    DataMemory によって定義されたメモリースペースは、順序付けされたインデックスを格納するためにも使用されます。これには、レコードあたり約 10 バイトが使用されます。各テーブル行は順序付けされたインデックスで表されます。ユーザーの間では共通して、すべてのインデックスが IndexMemory によって割り当てられたメモリーに格納されるという誤解がありますが、これは正しくありません。主キーと一意のハッシュインデックスのみがこのメモリーを使用します。順序付けされたインデックスは、DataMemory によって割り当てられたメモリーを使用します。ただし、主キーまたは一意のハッシュインデックスを作成するときに、インデックス作成ステートメントに USING HASH を指定しなかった場合は、同じキーに対して順序付けされたインデックスも作成されます。これは、管理クライアントで ndb_desc -d db_nametable_name を実行すると確認できます。

    現在、MySQL Cluster ではハッシュインデックスにパーティションあたり最大 512M バイトを使用できます。つまり、場合によってはndb_mgm -e "ALL REPORT MEMORYUSAGE"DataMemory に大きい空き領域が示されていてもTable is fullというエラーがMySQL クライアントアプリケーションで表示されることがあります。このため、データの負荷が高いノードでデータノードを再起動するときに問題が発生する場合もあります。CREATE TABLEMAX_ROWS オプションを使用すると、MySQL Cluster のテーブルのために追加のパーティションを作成して、ハッシュインデックスに使用できるメモリーを増やすように NDB に強制できます。通常、テーブルに格納することが予期されている行数の 2 倍の数値を MAX_ROWS に設定すれば十分です。MinFreePct 構成パラメータを使用して、ノード再起動の問題を回避することもできます。(Bug #13436216)

    DataMemory によって割り当てられるメモリースペースは 32K バイトのページで構成され、テーブルのフラグメントに割り当てられます。各テーブルは、通常、クラスタ内のデータノードと同じ数のフラグメントにパーティション化されます。このため、各ノードには NoOfReplicas での設定と同じ数のフラグメントがあります。

    ページの割り当て後、テーブルを削除する以外の方法で空きページのプールに戻すことは、現在不可能です。(これは、特定のページに割り当てられた DataMemory ページをほかのテーブルで使用できないことも意味します。)データノードのリカバリを実行すると、すべてのレコードがほかの稼働しているノードから空のパーティションに挿入されるため、パーティションも圧縮されます。

    DataMemory メモリースペースには、Undo 情報も含まれています。更新のたびに、変更されていないレコードのコピーが DataMemory に割り当てられます。順序付けされたテーブルインデックスにも各コピーへの参照が含まれています。一意のハッシュインデックスは、一意のインデックスカラムが更新されたときだけ更新されます。その場合は、コミット時にインデックステーブル内の新しいエントリが挿入され、古いエントリが削除されます。このため、クラスタを使用するアプリケーションによって実行される大規模なトランザクションを処理できるだけの十分なメモリーを割り当てる必要もあります。いずれにしても、次の理由から、少数の大規模なトランザクションを実行するよりも、多数の小規模なトランザクションを使用する方がメリットがあります。

    • 大規模なトランザクションは小規模なトランザクションより高速に実行できません

    • 大規模なトランザクションでは、トランザクション障害の発生時に消失して繰り返す必要がある操作の数が多くなります

    • 大規模なトランザクションはより多くのメモリーを使用します

    DataMemory のデフォルト値は 80M バイトです。最小値は 1M バイトです。最大サイズはありませんが、実際には、制限に達したときにプロセスがスワップを開始しないように最大サイズを決定する必要があります。この制限は、マシン上の使用可能な物理 RAM 量と、オペレーティングシステムが 1 つのプロセスに振り向けることができるメモリー量によって決まります。32 ビットオペレーティングシステムでは通常プロセスあたり 2-4G バイトに制限されますが、64 ビットオペレーティングシステムではより多くのメモリーを使用できます。このため、大規模なデータベースでは 64 ビットオペレーティングシステムを使用することをお勧めします。

  • IndexMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト18M1M - 1TN

    このパラメータは、MySQL Cluster 内のハッシュインデックスに使用されるストレージの量を制御します。ハッシュインデックスは、常に主キーのインデックス、一意のインデックス、および一意の制約に使用されます。主キーまたは一意のインデックスを定義すると、2 つのインデックスが作成され、そのうちの 1 つのハッシュインデックスが、すべてのタプルへのアクセスとロックの処理に使用されます。このインデックスは、一意の制約を適用するためにも使用されます。

    ハッシュインデックスのサイズは、この式を使用して見積もることができます。

     size = ( (fragments * 32K) + (rows * 18) ) * replicas

    fragments はフラグメントの数、replicas はレプリカの数 (通常 2)、rows は行の数です。テーブルに 100 万個の行、8 個のフラグメント、2 つのレプリカが含まれる場合、予想されるインデックスのメモリー使用量は、ここに示すように計算されます。

     ((8 * 32K) + (1000000 * 18)) * 2 = ((8 * 32768) + (1000000 * 18)) * 2 = (262144 + 18000000) * 2 = 18262144 * 2 = 36524288 bytes = ~35MB

    MySQL Cluster NDB 7.2 以降では、順序付けされたインデックスのインデックス統計が (有効になっている場合は) mysql.ndb_index_stat_sample テーブルに格納されます。このテーブルにはハッシュインデックスがあるため、これによってインデックスのメモリー使用量が追加されます。特定の順序付けされたインデックスの行数の上限は、次のように計算できます。

     sample_size= key_size + ((key_attributes + 1) * 4) sample_rows = IndexStatSaveSize * ((0.01 * IndexStatSaveScale * log2(rows * sample_size)) + 1) / sample_size

    前の式で、key_size は順序付けされたインデックスキーのサイズ (バイト単位)、key_attributes は順序付けされたインデックスキー内の属性の数、rows はベーステーブルの行数です。

    テーブル t1 に、100 万個の行と、2 つの 4 バイト整数に対する ix1 という名前の順序付けされたインデックスがあるとします。また、IndexStatSaveSizeIndexStatSaveScale がこのデフォルト値 (それぞれ 32K および 100) に設定されているとします。前の 2 つの式を使用して、次のように計算できます。

     sample_size = 8 + ((1 + 2) * 4) = 20 bytes sample_rows = 32K * ((0.01 * 100 * log2(1000000*20)) + 1) / 20 = 32768 * ( (1 * ~16.811) +1) / 20 = 32768 * ~17.811 / 20 = ~29182 rows

    予想されるインデックスのメモリー使用量は 2 * 18 * 29182 = 約 1050550 バイトです。

    IndexMemory のデフォルト値は 18M バイトです。最小は 1M バイトです。

  • StringMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0% またはバイト250 - 4294967039 (0xFFFFFEFF)S

    このパラメータは、テーブル名などの文字列用に割り当てられるメモリー量を決定するもので、config.ini ファイルの [ndbd] または [ndbd default] セクションに指定されます。0 から 100 までの (これらを含む) 値は、デフォルトの最大値のパーセントとして解釈されます。デフォルトの最大値は、テーブルの数、テーブル名のサイズ、.FRM ファイルの最大サイズ、MaxNoOfTriggers、カラム名の最大サイズ、およびデフォルトの最大カラム値を含むいくつかの係数に基づいて計算されます。

    100 を超える値は、バイト数として解釈されます。

    デフォルト値は 25 (つまり、デフォルトの最大の 25%) です。

    ほとんどの状況ではデフォルト値で十分ですが、クラスタテーブルの数が非常に多い (1000 個以上) 場合は、エラー 773 Out of string memory, please modify StringMemory config parameter: Permanent error: Schema errorが発生する可能性があるので、その場合はこの値を増やすようにしてください。25 (25%) であれば、多すぎることはなく、もっとも極端な状況を除き、このエラーは繰り返し発生しません。

次の例は、1 つのテーブルでメモリーがどのように使用されるかを示しています。このテーブル定義について考えます。

CREATE TABLE example ( a INT NOT NULL, b INT NOT NULL, c INT NOT NULL, PRIMARY KEY(a), UNIQUE(b)
) ENGINE=NDBCLUSTER;

各レコードに、12 バイトのデータと 12 バイトのオーバーヘッドがあります。NULL 可能カラムがない場合は、4 バイトのオーバーヘッドを節約できます。さらに、カラム a および b に対して 2 つの順序付けされたインデックスがあり、レコードごとにおよそ 10 バイトが消費されます。ベーステーブルには主キーのハッシュインデックスがあり、レコードあたりおよそ 29 バイトが使用されます。b を主キーとし、a をカラムとする別のテーブルによって一意の制約が実装されています。この別のテーブルでは、8 バイトのレコードデータと 12 バイトのオーバーヘッドに加えて、example テーブル内のレコードあたり 29 バイトのインデックスメモリーが追加で消費されます。

したがって、100 万個のレコードに対して、主キーと一意の制約のハッシュインデックスを処理するには 58M バイトのインデックスメモリーが必要です。さらに、ベーステーブルのレコード、一意のインデックステーブル、および 2 つの順序付けされたインデックステーブルに 64M バイトが必要です。

ハッシュインデックスがかなりのメモリー量を占有しますが、データへのアクセスは非常に高速になります。これらは、MySQL Cluster では一意制約を処理するためにも使用されます。

現在、唯一のパーティション化アルゴリズムはハッシュ化であり、順序付けされたインデックスは各ノードでローカルに使用されます。したがって、一般的なケースで順序付けされたインデックスを使用して一意制約を処理することはできません。

IndexMemoryDataMemory の両方で重要な点は、各ノードグループのすべてのデータメモリーとインデックスメモリーの合計がデータベースの合計サイズになることです。各ノードグループはレプリケートされた情報の格納に使用されるため、2 つのレプリカを含むノードが 4 つある場合は、2 つのノードグループが作成されます。したがって、使用可能なデータメモリーの合計はデータノードごとに 2 * DataMemory です。

すべてのノードで DataMemoryIndexMemory を同じ値に設定することを強くお勧めします。データの分布はクラスタ内のすべてのノードで均等であるため、各ノードで使用できるスペースの最大量はクラスタ内でもっとも小さいノードの最大量と同じになります。

DataMemoryIndexMemory は変更できますが、これらのいずれかを減らすのは危険です。その場合、ノードまたは MySQL Cluster 全体がメモリースペースの不足によって再起動できなくなる可能性が高くなります。これらの値を増やすことは問題ありませんが、このようなアップグレードはソフトウェアのアップグレードと同じ方法で行うことをお勧めします。つまり、最初に構成ファイルを更新し、次に管理サーバーを起動して、各データノードを順に再起動します。

MinFreePct DataMemoryIndexMemory を含むデータノードリソースの一定割合 (デフォルトでは 5%) は、データノードが再起動するときにそのメモリーを使い果たさないように予備として残されます。これは、MinFreePct データノード構成パラメータを使用して調整できます (デフォルトは 5)。

有効なバージョン型/単位デフォルト範囲/値再起動タイプ
NDB 7.3.0符号なし50 - 100N

更新によって、使用されるインデックスメモリーの量は増えません。挿入はただちに有効になりますが、行の削除はトランザクションがコミットされるまで実際には行われません。

トランザクションパラメータ  次に説明する [ndbd] のいくつかのパラメータは、システムで処理できる並列トランザクションの数とトランザクションのサイズに影響を与えるという点で重要です。MaxNoOfConcurrentTransactions は、ノード内で実行できる並列トランザクションの数を設定します。MaxNoOfConcurrentOperations は、同時に更新フェーズに入ったり、ロックしたりできるレコードの数を設定します。

これらのパラメータはどちらも (特に MaxNoOfConcurrentOperations は)、デフォルト値を使用せずに特定の値を設定するユーザーのターゲットになる可能性があります。デフォルト値は、小規模なトランザクションを使用するシステムで過大なメモリーが使用されないように設定されています。

MaxDMLOperationsPerTransaction は、特定のトランザクションで実行できる DML 操作の最大数を設定します。

  • MaxNoOfConcurrentTransactions

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数409632 - 4294967039 (0xFFFFFEFF)N

    各クラスタデータノードには、クラスタ内の個々のアクティブなトランザクションに対するトランザクションレコードが必要です。トランザクションを調整するタスクは、すべてのデータノードに分配されます。クラスタ内のトランザクションレコードの合計数は、特定のノード内のトランザクションの数にクラスタ内のノードの数を掛けた値です。

    トランザクションレコードは、個々の MySQL サーバーに割り当てられます。MySQL サーバーへの個々の接続には、少なくとも 1 つのトランザクションレコードと、その接続でアクセスされるテーブルごとに追加のトランザクションオブジェクトが必要です。つまり、クラスタ内のトランザクション合計数の妥当な最小値を次のように表すことができます。

    MinTotalNoOfConcurrentTransactions = (maximum number of tables accessed in any single transaction + 1) * number of SQL nodes

    クラスタを使用する 10 個の SQL ノードがあるとします。10 個のテーブルが関与する 1 回の結合には、11 個のトランザクションレコードが必要です。トランザクション内にこのような結合が 10 回ある場合、このトランザクションには MySQL サーバーあたり 10 * 11 = 110 個のトランザクションレコード (または合計 110 * 10 = 1100 個のトランザクションレコード) が必要です。各データノードは、MinTotalNoOfConcurrentTransactions / データノード数が処理されます。この場合、4 個のデータノードを含む MySQL Cluster では、各データノードの MaxNoOfConcurrentTransactions を 1100/4 = 275 に設定することになります。さらに、1 つのノードグループですべての並列トランザクションに対応できるようにすることで、障害リカバリを提供します。つまり、各データノードの MaxNoOfConcurrentTransactions を、MinTotalNoOfConcurrentTransactions/ノードグループ数と同じ数のトランザクションに対応できるだけの十分な数に設定します。このクラスタにノードグループが 1 つだけある場合は、MaxNoOfConcurrentTransactions を 1100 (クラスタ全体の並列トランザクションの数と同じ) に設定するようにしてください。

    また、各トランザクションに少なくとも 1 つの操作が関与します。このため、MaxNoOfConcurrentTransactions に設定する値は常に MaxNoOfConcurrentOperations の値以下にします。

    このパラメータは、すべてのクラスタデータノードで同じ値に設定する必要があります。これは、データノードの機能停止時に、残存するもっとも古いノードが機能停止したノードで実行されていたトランザクションのトランザクション状態を再作成するためです。

    ローリング再起動を使用してこの値を変更できますが、実行中のクラスタ上のトラフィック量は、発生するトランザクションが新旧どちらか低い方のレベルを超えない程度にする必要があります。

    デフォルト値は 4096 です。

  • MaxNoOfConcurrentOperations

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数32K32 - 4294967039 (0xFFFFFEFF)N

    このパラメータの値は、トランザクションのサイズと数に合わせて調整することをお勧めします。少数の操作とレコードしか関与しないトランザクションを実行する場合は、通常、このパラメータのデフォルト値で十分です。多数のレコードが関与する大規模なトランザクションを実行する場合は、通常、その値を増やす必要があります。

    クラスタデータを更新する各トランザクションでは、トランザクションコーディネータと実際の更新が実行されるノードの両方でレコードが保持されます。これらのレコードには、ロールバック、ロックキュー、およびその他の目的に使用する Undo レコードを見つけるために必要な状態情報が含まれています。

    このパラメータは、最低でも、トランザクションで同時に更新されるレコードの数をクラスタデータノードの数で割った値に設定するようにしてください。たとえば、4 つのデータノードがあるクラスタで、トランザクションを使用して 100 万件の並列更新を処理することが予想される場合は、この値を 1000000/4 = 250000 に設定します。障害からの回復力を提供できるように、このパラメータを、個々のデータノードでノードグループの負荷を処理できる十分な大きさの値に設定することをお勧めします。つまり、並列操作の合計数/ノードグループの数と同じ値に設定するようにしてください。(ノードグループが 1 つだけの場合、これはクラスタ全体の並列操作の合計数と同じです。)

    各トランザクションには常に少なくとも 1 つの操作が関与しているため、MaxNoOfConcurrentOperations の値は常に MaxNoOfConcurrentTransactions の値以上にします。

    ロックを設定する読み取りクエリーでも、操作レコードが作成されます。ノード間の分布が完全でない場合に対応できるように、個々のノード内にある程度の追加スペースが割り当てられます。

    クエリーで一意のハッシュインデックスが使用されると、実際にはトランザクション内のレコードあたり 2 つの操作レコードが使用されます。1 つ目のレコードはインデックステーブルの読み取りを表し、2 つ目はベーステーブルに対する操作を扱います。

    デフォルト値は 32768 です。

    このパラメータは、実際には別個に構成できる 2 つの値を扱います。これらのうち 1 つ目は、トランザクションコーディネータによって配置される操作レコードの数を指定します。2 つ目の部分は、データベースにローカルに格納される操作レコードの数を指定します。

    8 ノードのクラスタで実行される非常に大規模なトランザクションでは、そのトランザクションに関与する読み取り、更新、および削除と同じ数の操作レコードがトランザクションコーディネータ内に必要です。ただし、これらの操作レコードは 8 個のノードすべてに分散しています。このため、1 つの非常に大規模なトランザクション用にシステムを構成する必要がある場合は、この 2 つの部分を別個に構成することをお勧めします。MaxNoOfConcurrentOperations は常に、ノードのトランザクションコーディネータ部分の操作レコード数を計算するために使用されます。

    操作レコードのメモリー要件を考慮することも重要です。これらは、レコードあたり約 1K バイトを消費します。

  • MaxNoOfLocalOperations

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数UNDEFINED32 - 4294967039 (0xFFFFFEFF)N

    デフォルトでは、このパラメータは 1.1 * MaxNoOfConcurrentOperations として計算されます。これは、多くの同時トランザクションを含み、そのいずれもが大規模ではないシステムに適合します。一度に 1 つの非常に大規模なトランザクションが実行され、多数のノードがある場合は、このパラメータを明示的に指定してデフォルトをオーバーライドすることをお勧めします。

  • MaxDMLOperationsPerTransaction

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0操作 (DML)429496729532 - 4294967295N

    このパラメータは、トランザクションのサイズを制限します。これを超える数の DML 操作が必要になった場合、トランザクションは中止されます。トランザクションあたりの最小操作数は 32 ですが、MaxDMLOperationsPerTransaction を 0 に設定すると、トランザクションあたりの DML 操作の数に対する制限を無効にできます。最大 (およびデフォルト) は 4294967295 です。

トランザクションの一時ストレージ  次の一連の [ndbd] パラメータは、クラスタトランザクションの一部であるステートメントの実行時に一時ストレージを決定するために使用されます。このステートメントが完了し、クラスタがコミットまたはロールバックを待機しているときに、すべてのレコードが解放されます。

これらのパラメータのデフォルト値は、ほとんどの状況に適しています。ただし、多数の行または操作が関与するトランザクションをサポートする必要がある場合は値を増やして、システム内の並列性を高める必要があることがあります。一方、比較的小規模なトランザクションを必要とするアプリケーションでは、これらの値を減らしてメモリーを節約できます。

  • MaxNoOfConcurrentIndexOperations

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数8K0 - 4294967039 (0xFFFFFEFF)N

    一意のハッシュインデックスを使用するクエリーでは、クエリーの実行フェーズで別の一時的な操作レコードのセットが使用されます。このパラメータは、そのレコードプールのサイズを設定します。このため、このレコードはクエリーの一部を実行している間だけ割り当てられます。この部分の実行が完了した直後にレコードは解放されます。中止とコミットを処理するために必要な状態では通常の操作レコードによって処理され、プールサイズは MaxNoOfConcurrentOperations パラメータで設定されます。

    このパラメータのデフォルト値は 8192 です。一意のハッシュインデックスを使用して非常に高い並列性を実現させるまれなケースでのみ、この値を増やす必要があります。クラスタに高いレベルの並列性が必要ないことを DBA が確信している場合は、小さい値を使用してメモリーを節約できます。

  • MaxNoOfFiredTriggers

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数40000 - 4294967039 (0xFFFFFEFF)N

    MaxNoOfFiredTriggers のデフォルト値は 4000 です。ほとんどの状況では、これで十分です。場合によっては、クラスタに並列性はそれほど必要ないと DBA が確信している場合は、値を減らすこともできます。

    一意のハッシュインデックスに影響を与える操作が実行されたときに、レコードが作成されます。一意のハッシュインデックスを使用してテーブル内のレコードを挿入または削除したり、一意のハッシュインデックスの一部であるカラムを更新したりすると、インデックステーブルで挿入または削除が発生します。生成されたレコードは、このインデックステーブル操作を発生させた元の操作の完了を待機している間、インデックステーブル操作を表すために使用されます。この操作は短期間ですが、一意のハッシュインデックスのセットを含むベーステーブルに対して多数の並列書き込み操作が行われる状況では、レコードプール内に多数のレコードを必要とする可能性があります。

  • TransactionBufferMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト1M1K - 4294967039 (0xFFFFFEFF)N

    このパラメータの影響を受けるメモリーは、インデックステーブルの更新と一意のインデックスの読み取り時に発生した操作を追跡するために使用されます。このメモリーは、これらの操作のキーおよびカラムの情報を格納するために使用されます。このパラメータの値をデフォルトから変更する必要があるのは、非常にまれなケースだけです。

    TransactionBufferMemory のデフォルト値は 1M バイトです。

    通常の読み取りおよび書き込み操作でも同じようなバッファーが使用されますが、その使用期間はさらに短くなります。コンパイル時のパラメータ ZATTRBUF_FILESIZE (ndb/src/kernel/blocks/Dbtc/Dbtc.hpp にあります) は 4000 * 128 バイト (500K バイト) に設定されています。キー情報用の同様のバッファー ZDATABUF_FILESIZE (これも Dbtc.hpp にあります) には、4000 * 16 = 62.5K バイトのバッファースペースが含まれています。Dbtc は、トランザクションのコーディネーションを扱うモジュールです。

スキャンとバッファリング  (ndb/src/kernel/blocks/Dblqh/Dblqh.hpp 内の) Dblqh モジュールには、読み取りと更新に影響を与える追加の [ndbd] パラメータがあります。これらには、デフォルトで 10000 * 128 バイト (1250K バイト) に設定される ZATTRINBUF_FILESIZE と、デフォルトで 10000 * 16 バイト (およそ 156K バイト) のバッファースペースに設定される ZDATABUF_FILE_SIZE が含まれます。これまでに、これらのコンパイル時制限のいずれかを増やすことを示すユーザーからの報告または弊社の大規模なテストの結果はありません。

  • MaxNoOfConcurrentScans

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数2562 - 500N

    このパラメータは、クラスタ内で実行できる並列スキャンの数を制御するために使用されます。各トランザクションコーディネータは、このパラメータで定義された数の並列スキャンを処理できます。各スキャンクエリーは、すべてのパーティションを並列でスキャンして実行されます。各パーティションスキャンでは、パーティションが配置されているノード内のスキャンレコードが使用されます。レコードの数は、このパラメータの値にノードの数を掛けた値です。クラスタは、クラスタ内のすべてのノードで同時に発生した MaxNoOfConcurrentScans 個のスキャンを維持できます。

    スキャンは、実際には 2 つのケースで実行されます。これらのうち 1 つ目のケースは、クエリーを処理するためのハッシュまたは順序付けされたインデックスが存在しないときに発生します。この場合は、フルテーブルスキャンを実行するとクエリーが実行されます。2 つ目のケースは、クエリーをサポートするハッシュインデックスが存在せず、順序付けされたインデックスが存在する場合に発生します。順序付けされたインデックスの使用は、並列の範囲スキャンの実行を意味します。この順序はローカルのパーティションでのみ維持されるため、すべてのパーティションでインデックススキャンを実行する必要があります。

    MaxNoOfConcurrentScans のデフォルト値は 256 です。最大値は 500 です。

  • MaxNoOfLocalScans

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数[テキストを参照]32 - 4294967039 (0xFFFFFEFF)N

    多くのスキャンが完全に並列化されていない場合の、ローカルスキャンレコードの数を指定します。ローカルスキャンレコードの数が指定されていない場合は、ここに示すように計算されます。

    4 * MaxNoOfConcurrentScans * [# data nodes] + 2

    最小値は 32 です。

  • BatchSizePerLocalScan

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数2561 - 992N

    このパラメータは、並列スキャン操作を処理するために使用されるロックレコードの数を計算するために使用されます。

    BatchSizePerLocalScan は、SQL ノードで定義される BatchSize と深い関係があります。

  • LongMessageBuffer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト64M512K - 4294967039 (0xFFFFFEFF)N
    NDB 7.3.1バイト4M512K - 4294967039 (0xFFFFFEFF)N
    NDB 7.3.5バイト64M512K - 4294967039 (0xFFFFFEFF)N

    これは、個々のノード内およびノード間でメッセージを渡すために使用される内部バッファーです。デフォルトは 64M バイトです。(MySQL Cluster NDB 7.3.5 より前では、これは 4M バイトでした。)

    ほとんどの場合、このパラメータをデフォルトから変更する必要はありません。

  • MaxParallelScansPerFragment

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト2561 - 4294967039 (0xFFFFFEFF)N

    順次処理のキューイングが開始される前に許可される並列スキャン (TUP スキャンおよび TUX スキャン) の最大数を構成できます。これを増やすことにより、多数のスキャンを並列で実行するときに未使用の CPU を利用して、パフォーマンスを向上させることができます。

    MySQL Cluster NDB 7.3 以降では、このパラメータのデフォルト値は 256 です。

メモリー割り当て

MaxAllocate

有効なバージョン型/単位デフォルト範囲/値再起動タイプ
NDB 7.3.0符号なし32M1M - 1GN

これは、テーブル用のメモリーを割り当てるときに使用するメモリーユニットの最大サイズです。NDBOut of memoryエラーが発生したが、クラスタログまたは DUMP 1000 (DUMP 1000を参照してください) の出力を調べると、使用可能なすべてのメモリーがまだ使用されていないことが明らかな場合は、このパラメータ (または MaxNoOfTables、あるいはその両方) の値を増やすと、NDB が十分なメモリーを使用できるようになります。

ハッシュマップサイズ

DefaultHashMapSize

有効なバージョン型/単位デフォルト範囲/値再起動タイプ
NDB 7.3.0LDM スレッド38400 - 3840N

MySQL Cluster NDB 7.2.7 以降では、前のリリース (240) より大きなテーブルハッシュマップのデフォルトサイズ (3840) が使用されます。MySQL Cluster NDB 7.2.11 以降では、このパラメータを使用して NDB が使用するテーブルハッシュマップのサイズを構成できます (以前は、この値はハードコーディングされていました)。DefaultHashMapSize には、3 つの値 (0、240、3840) のいずれかを指定できます。これらの値とその効果について、次の表で説明します。

説明/効果
0クラスタ内のすべてのデータおよび API ノードの中で、このパラメータに設定されたもっとも小さい値を (あれば) 使用します。どのデータまたは API ノードにも設定されていない場合は、デフォルト値を使用します。
240MySQL Cluster NDB 7.2.7 より前のすべての MySQL Cluster リリースでデフォルトで使用されていた元のハッシュマップサイズです。
3840MySQL Cluster NDB 7.2.7 以降でデフォルトで使用される、より大きなハッシュマップサイズ

このパラメータの主な用途は、より大きなハッシュマップサイズ (3840) がデフォルトである MySQL Cluster NDB 7.2.7 以降の MySQL Cluster バージョンと以前のリリース (デフォルトが 240 だった) との間のアップグレードと (特に) ダウングレードを容易にすることです。これは、この変更に下位互換性がない (Bug #14800539) ためです。このパラメータを 240 に設定してから、この値を使用している古いバージョンからのアップグレードを実行すると、クラスタはテーブルハッシュマップに対して引き続き小さいサイズを使用するため、アップグレード後のテーブルでも前のバージョンとの互換性が維持されます。DefaultHashMapSize は個々のデータノード、API ノード、またはその両方で設定できますが、config.ini ファイルの [ndbd default] セクションに一度だけ設定する方法をお勧めします。

このパラメータを増やしたあと、既存のテーブルで新しいサイズを利用するには、そのテーブルに対して ALTER TABLE ... REORGANIZE PARTITION を実行します。その後、そのテーブルでより大きなハッシュマップサイズを使用できるようになります。これは、ローリング再起動の実行に加えて行います。ローリング再起動を実行すると、より大きなハッシュマップを新しいテーブルで使用できるようになりますが、既存のテーブルでは使用できません。

DefaultHashMapSize を 3840 に設定してテーブルを作成または変更したあと、オンラインでこのパラメータを減らす方法は、現在サポートされていません。

ロギングとチェックポイント  次の [ndbd] パラメータは、ログとチェックポイントの動作を制御します。

  • NoOfFragmentLogFiles

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数163 - 4294967039 (0xFFFFFEFF)IN

    このパラメータは、ノードの Redo ログファイルの数 (つまり、Redo ロギングに割り当てられるスペースの量) を設定します。Redo ログファイルはリング状に編成されるため、セット内の最初と最後のログファイル (それぞれ head および tail ログファイルとも呼ばれる) が交わらないことが非常に重要です。これらが互いに近寄りすぎると、新しいログレコードを追加する余裕がないため、ノードは更新を含むすべてのトランザクションを中止し始めます。

    Redo ログレコードは、挿入されたあと、必要な数のローカルチェックポイントが完了するまで削除されません。(MySQL Cluster NDB 7.3 以降では、2 つのローカルチェックポイントのみが必要です)。チェックポイントの頻度は、この章で別途説明する固有の構成パラメータセットによって決定されます。

    デフォルトのパラメータ値は 16 です。これは、デフォルトでは 16M バイトのファイル 4 個が 16 セット (合計 1024M バイト) あることを意味します。個々のログファイルのサイズは、FragmentLogFileSize パラメータを使用して構成できます。非常に多くの更新が必要なシナリオでは、Redo ログに対して十分なスペースを提供するため、NoOfFragmentLogFiles の値を 300 以上に設定する必要がある場合があります。

    チェックポイントが遅く、データベースへの書き込みが多いためにログファイルがいっぱいになって、リカバリに悪影響を与えずにログの末尾をカットできない場合は、すべての更新トランザクションが内部エラーコード 410「Out of log file space temporarily」によって中止されます。この状態は、チェックポイントが完了してログの末尾を前に移動できるようになるまで続きます。

    重要

    このパラメータは実行中に変更できません。--initial を使用してノードを再起動する必要があります。実行中のクラスタのすべてのデータノードでこの値を変更する必要がある場合は、(各データノードの起動時に --initial を使用して) ノードのローリング再起動を使用します。

  • FragmentLogFileSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト16M4M - 1GIN

    このパラメータを設定すると、Redo ログファイルのサイズを直接制御できます。これは、MySQL Cluster が負荷の高い状態で稼働し、フラグメントログファイルを閉じるまでに時間がかかって新しいファイルを開けない (一度に開けるフラグメントログファイルは 2 つだけです) 場合に便利です。フラグメントログファイルのサイズを増やすと、クラスタ内で新しいフラグメントログファイルを開く必要が生じるまでの時間が長くなります。このパラメータのデフォルト値は 16M です。

    フラグメントログファイルの詳細は、NoOfFragmentLogFiles の説明を参照してください。

  • InitFragmentLogFiles

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0[値を参照]SPARSESPARSE、FULLIN

    デフォルトでは、データノードの初期起動の実行時はフラグメントログファイルがまばらに作成されます。つまり、使用するオペレーティングシステムとファイルシステムによって、必ずしもすべてのバイトがディスクに書き込まれるわけではありません。ただし、このパラメータを使用すると、使用されているプラットフォームやファイルシステムのタイプに関係なく、この動作をオーバーライドしてすべてのバイトが強制的に書き込まれるように設定できます。InitFragmentLogFiles は 2 つの値のいずれかを取ります。

    • SPARSE。フラグメントログファイルがまばらに作成されます。これはデフォルト値です。

    • FULL。フラグメントログファイルのすべてのバイトが強制的にディスクに書き込まれます。

    オペレーティングシステムとファイルシステムによっては、InitFragmentLogFiles=FULL を設定することで、Redo ログへの書き込み時の I/O エラーを解消できる場合があります。

  • MaxNoOfOpenFiles

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし020 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、開いたファイルに割り当てる内部スレッド数の上限を設定します。このパラメータの変更が必要な状況が発生した場合は、それをバグとして報告するようにしてください

    デフォルト値は 0 です。ただし、このパラメータに設定できる最小値は 20 です。

  • InitialNoOfOpenFiles

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ファイル2720 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、開いたファイルに割り当てる初期の内部スレッド数を設定します。

    デフォルト値は 27 です。

  • MaxNoOfSavedMessages

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数250 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、古いファイルを上書きする前に保持されるトレースファイルの最大数を設定します。トレースファイルは、何らかの理由でノードがクラッシュしたときに生成されます。

    デフォルトは 25 個のトレースファイルです。

  • MaxLCPStartDelay

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.000 - 600N

    データノードの並列リカバリでは、実際にはテーブルデータのみが並列でコピーされ、同期されます。ディクショナリ情報やチェックポイント情報などのメタデータの同期は順次に行われます。また、ディクショナリおよびチェックポイント情報のリカバリは、ローカルチェックポイントの実行と並列で実行できません。つまり、多くのデータノードを同時に起動したり再起動したりすると、データノードがローカルチェックポイントの実行中に待たされて、ノードのリカバリ時間が長くなる可能性があります。

    より多くの (場合によってはすべての) データノードでメタデータの同期を完了できるように、ローカルチェックポイントの遅延を強制できます。各データノードでメタデータの同期が完了したあとは、ローカルチェックポイントの実行中でも、すべてのデータノードで並列にテーブルデータをリカバリできます。このような遅延を強制するには、MaxLCPStartDelay を設定します。これは、データノードでメタデータの同期が継続されている間にクラスタがローカルチェックポイントの開始を待機する秒数を決定します。このパラメータは、すべてのデータノードで同じになるように config.ini ファイルの [ndbd default] セクションに設定するようにしてください。最大値は 600、デフォルトは 0 です。

  • LcpScanProgressTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0second600 - 4294967039 (0xFFFFFEFF)N
    NDB 7.3.3second600 - 4294967039 (0xFFFFFEFF)N

    ローカルチェックポイントのフラグメントスキャンウォッチドッグは、ローカルチェックポイントの一部として実行されている各フラグメントスキャンが進行していないかどうか定期的にチェックし、特定の時間が経過しても進行しない場合はそのノードをシャットダウンします。MySQL Cluster NDB 7.3.3 より前では、この間隔は常に 60 秒でした (Bug #16630410)。MySQL Cluster NDB 7.3.3 以降では、LcpScanProgressTimeout データノード構成パラメータを使用してこの間隔を設定できます。これは、LCP のフラグメントスキャンウォッチドッグがノードをシャットダウンするまでローカルチェックポイントの停滞が許可される最大時間を設定します。

    デフォルト値は 60 秒です (以前のリリースと互換性があります)。このパラメータを 0 に設定すると、LCP のフラグメントスキャンウォッチドッグが完全に無効化されます。

メタデータオブジェクト  次の一連の [ndbd] パラメータは、インデックス、イベント、およびクラスタ間のレプリケーションで使用される属性、テーブル、インデックス、およびトリガーオブジェクトの最大数を定義するために使用されるメタデータオブジェクトのプールサイズを定義します。これらはクラスタに対する推奨の役割を果たすだけであり、指定されなかったものはすべて示されたデフォルト値に戻ります。

  • MaxNoOfAttributes

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数100032 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、クラスタに定義できる属性の推奨最大数を設定します。MaxNoOfTables と同様、厳密な上限の役割を果たすためのものではありません。

    (古い MySQL Cluster リリースでは、このパラメータは特定の操作に対する厳密な制限として扱われることがありました。このため、MySQL Cluster レプリケーションでレプリケートできる数を超えるテーブルを作成したときに問題が発生し、MaxNoOfAttributes を超える数の属性を作成した (状況によってはできない) ときに混乱を招くことがありました。)

    デフォルト値は 1000 です。指定可能な最小値は 32 です。最大は 4294967039 です。すべてのメタデータがサーバー上で完全にレプリケートされるため、各属性はノードあたり 200 バイト前後のストレージを消費します。

    MaxNoOfAttributes を設定するときは、今後実行する可能性がある ALTER TABLE ステートメントを事前に用意することが重要です。これは、クラスタテーブルで ALTER TABLE の実行中に、元のテーブルに含まれる 3 倍の数の属性が使用されるためであり、この数の 2 倍を許可することをお勧めします。たとえば、属性の数がもっとも多い (greatest_number_of_attributes) MySQL Cluster テーブルに 100 個の属性がある場合、MaxNoOfAttributes の適切な初期値は 6 * greatest_number_of_attributes = 600 です。

    また、テーブルあたりの平均属性数を見積もり、それに MaxNoOfTables を掛けることもお勧めします。この値が前の段落で得られた値より大きい場合は、大きい値を使用するようにしてください。

    必要なすべてのテーブルが問題なく作成できると仮定して、パラメータの構成後に実際に ALTER TABLE を試行し、この数が十分であることを確認するようにしてください。これが成功しなかった場合は、MaxNoOfAttributes をさらに MaxNoOfTables の数だけ増やして、再度テストしてください。

  • MaxNoOfTables

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数1288 - 20320N

    テーブルオブジェクトは、クラスタ内のテーブルごと、および一意のハッシュインデックスごとに割り当てられます。このパラメータは、クラスタ全体のテーブルオブジェクトの推奨最大数を設定します。MaxNoOfAttributes と同様、厳密な上限の役割を果たすためのものではありません。

    (古い MySQL Cluster リリースでは、このパラメータは特定の操作に対する厳密な制限として扱われることがありました。このため、MySQL Cluster レプリケーションでレプリケートできる数を超えるテーブルを作成したときに問題が発生し、MaxNoOfTables を超える数のテーブルを作成した (状況によってはできない) ときに混乱を招くことがありました。)

    BLOB データ型を持つ各属性では、BLOB データの大部分を格納するために追加のテーブルが使用されます。テーブルの合計数を定義するときは、これらのテーブルも考慮に入れる必要があります。

    このパラメータのデフォルト値は 128 です。最小値は 8、最大値は 20320 です。各テーブルオブジェクトは、ノードあたりおよそ 20K バイトを消費します。

    注記

    MaxNoOfTablesMaxNoOfOrderedIndexes、および MaxNoOfUniqueHashIndexes の合計が 232 - 2 (4294967294) を超えないようにする必要があります。

  • MaxNoOfOrderedIndexes

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数1280 - 4294967039 (0xFFFFFEFF)N

    クラスタ内の順序付けされたインデックスごとに、インデックスされた内容とそのストレージセグメントを記述するオブジェクトが割り当てられます。デフォルトでは、そのように定義された各インデックスによって、順序付けされたインデックスも定義されます。個々の一意のインデックスおよび主キーには、順序付けされたインデックスとハッシュインデックスの両方が含まれています。MaxNoOfOrderedIndexes は、システム内で一度に使用できる順序付けされたインデックスの合計数を設定します。

    このパラメータのデフォルト値は 128 です。各インデックスオブジェクトは、ノードあたりおよそ 10K バイトのデータを消費します。

    注記

    MaxNoOfTablesMaxNoOfOrderedIndexes、および MaxNoOfUniqueHashIndexes の合計が 232 - 2 (4294967294) を超えないようにする必要があります。

  • MaxNoOfUniqueHashIndexes

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数640 - 4294967039 (0xFFFFFEFF)N

    主キー以外の個々の一意のインデックスには、一意キーをインデックスされたテーブルの主キーにマップする専用のテーブルが割り当てられます。デフォルトでは、個々の一意のインデックスに対して順序付けされたインデックスも定義されます。これを禁止するには、一意のインデックスを定義するときに USING HASH オプションを指定する必要があります。

    デフォルト値は 64 です。各インデックスは、ノードあたりおよそ 15K バイトを消費します。

    注記

    MaxNoOfTablesMaxNoOfOrderedIndexes、および MaxNoOfUniqueHashIndexes の合計が 232 - 2 (4294967294) を超えないようにする必要があります。

  • MaxNoOfTriggers

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数7680 - 4294967039 (0xFFFFFEFF)N

    個々の一意のハッシュインデックスには、内部更新、挿入、および削除のトリガーが割り当てられます。(これは、一意のハッシュインデックスごとに 3 つのトリガーが作成されることを意味します。)ただし、順序付けされたインデックスに必要なトリガーオブジェクトは 1 つだけです。バックアップでも、クラスタ内の通常のテーブルごとに 3 つのトリガーオブジェクトが使用されます。

    クラスタ間のレプリケーションでも、内部トリガーが使用されます。

    このパラメータは、クラスタ内のトリガーオブジェクトの最大数を設定します。

    デフォルト値は 768 です。

  • MaxNoOfIndexes

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。代わりに MaxNoOfOrderedIndexes および MaxNoOfUniqueHashIndexes を使用するようにしてください。

    このパラメータは、一意のハッシュインデックスでのみ使用されます。 クラスタ内に定義された一意のハッシュインデックスごとに 1 つのレコードがこのプールに存在している必要があります。

    このパラメータのデフォルト値は 128 です。

  • MaxNoOfSubscriptions

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし00 - 4294967039 (0xFFFFFEFF)N

    MySQL Cluster 内の各 NDB テーブルには、NDB カーネル内のサブスクリプションが必要です。一部の NDB API アプリケーションでは、このパラメータの変更が必要または望ましい場合があります。ただし、SQL ノードとして機能する MySQL サーバーを通常どおりに使用する場合は、これを行う必要はありません。

    MaxNoOfSubscriptions のデフォルト値は 0 です。これは、MaxNoOfTables と等価として扱われます。各サブスクリプションは 108 バイトを消費します。

  • MaxNoOfSubscribers

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし00 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、MySQL Cluster レプリケーションの使用時にのみ関連します。デフォルト値は 0 です。これは、2 * MaxNoOfTables として扱われます。つまり、2 つの MySQL サーバー (1 つはレプリケーションマスターとして機能し、もう 1 つはスレーブとして機能します) のそれぞれに対して NDB テーブルあたり 1 つのサブスクリプションがあります。各サブスクライバは 16 バイトのメモリーを使用します。

    循環レプリケーション、マルチマスターレプリケーション、および 3 つ以上の MySQL サーバーが関与するその他のレプリケーションセットアップを使用するときは、このパラメータをレプリケーションに含まれる mysqld プロセスの数 (これは通常 (常にではありませんが) クラスタの数と同じです) まで増やすようにしてください。たとえば、3 つの MySQL Cluster を使用する循環レプリケーションセットアップがあり、1 つの mysqld が各クラスタに接続され、これらの mysqld プロセスがそれぞれマスターおよびスレーブとして機能する場合は、MaxNoOfSubscribers3 * MaxNoOfTables に設定するようにしてください。

    詳細は、セクション18.6「MySQL Cluster レプリケーション」を参照してください。

  • MaxNoOfConcurrentSubOperations

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし2560 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、クラスタ内のすべての API ノードが一度に実行できる操作数の上限を設定します。通常の操作ではデフォルト値 (256) で十分ですが、API ノードが多数あり、それぞれが大量の操作を同時に実行しているシナリオでのみ、調整が必要になる可能性があります。

ブールパラメータ  データノードの動作は、ブール値を取る一連の [ndbd] パラメータにも影響されます。これらの各パラメータは、TRUE として指定する場合は 1 または Y に設定し、FALSE として指定する場合は 0 または N に設定します。

  • LateAlloc

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値10 - 1N

    管理サーバーへの接続が確立されたあとで、このデータノードのメモリーを割り当てます。デフォルトで有効。

  • LockPagesInMainMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値00 - 2N

    Solaris と Linux を含むいくつかのオペレーティングシステムでは、プロセスをメモリーにロックすると、ディスクへのスワップを回避できます。これを使用すると、クラスタのリアルタイム特性が保証されやすくなります。

    このパラメータは、整数値 01、または 2 のいずれかを取ります。これらの機能を次のリストに示します。

    • 0: ロックを無効にします。これはデフォルト値です。

    • 1: プロセスのメモリーを割り当てたあとでロックを実行します。

    • 2: プロセスのメモリーを割り当てる前にロックを実行します。

    権限のないユーザーがページをロックできるようにオペレーティングシステムが構成されていない場合は、このパラメータを利用するデータノードプロセスをシステムの root として実行する必要がある可能性があります。(LockPagesInMainMemory では、mlockall 関数が使用されます。Linux kernel 2.6.9 以降では、権限のないユーザーが max locked memory の制限に従ってメモリーをロックできます。詳細は、ulimit -l および http://linux.die.net/man/2/mlock を参照してください)。

    注記

    古い MySQL Cluster リリースでは、このパラメータはブール型でした。デフォルト設定だった 0 または false では、ロックが無効化されました。1 または true では、プロセスのメモリーが割り当てられたあとでそのロックが有効化されました。MySQL Cluster NDB 7.3 以降では、このパラメータの値に true または false を使用すると、エラーとして処理されます。

    重要

    glibc 2.10 以降では、glibc が共有プールでのロック競合を減らすためにスレッド単位のアリーナを使用し、これによって実メモリーが消費されます。通常、データノードプロセスは起動後にメモリー割り当てを実行しないため、スレッド単位のアリーナを必要としません。(このアロケータの違いがパフォーマンスに重大な影響を与えることはありません。)

    この glibc の動作は MALLOC_ARENA_MAX 環境変数を使用して構成できるようになっていますが、glibc 2.16 より前では、このメカニズムのバグが原因でこの変数を 8 未満に設定できなかったため、無駄になったメモリーを再利用できませんでした。(Bug #15907219。この問題の詳細は、http://sourceware.org/bugzilla/show_bug.cgi?id=13137 も参照してください。)

    この問題の考えられる回避策は、LD_PRELOAD 環境変数を使用して jemalloc メモリー割り当てライブラリをプリロードし、glibc に付属するライブラリの代わりに使用することです。

  • StopOnError

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブール10、1N

    このパラメータは、データノードプロセスでエラー状態が発生したときに、プロセスを終了するか、自動的に再起動するか指定します。

    このパラメータのデフォルト値は 1 です。これは、デフォルトで、エラー発生時にデータノードプロセスが停止することを意味します。

  • CrashOnCorruptedTuple

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールtruetrue、falseS

    このパラメータを有効にすると、破損したタプルが検出されたときにデータノードが強制的にシャットダウンされます。MySQL Cluster NDB 7.3 以降では、これはデフォルトで有効になっています。

  • Diskless

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0true|false (1|0)falsetrue、falseIS

    MySQL Cluster のテーブルをディスクレスとして指定できます。これは、テーブルがディスクにチェックポイントされず、ロギングが発生しないことを意味します。このようなテーブルはメインメモリーにのみ存在します。ディスクレステーブルを使用すると、クラッシュ発生時にテーブルもテーブル内のレコードも失われます。ただし、ディスクレスモードで動作するときは、ディスクレスコンピュータで ndbd を実行できます。

    重要

    この機能を使用すると、クラスタ全体がディスクレスモードで動作します。

    この機能を有効にすると、クラスタのオンラインバックアップが無効になります。また、クラスタの部分的起動ができなくなります。

    Diskless はデフォルトで無効になっています。

  • ODirect

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    このパラメータを有効にすると、NDB が LCP、バックアップ、および Redo ログで O_DIRECT 書き込みを試行し、多くの場合 kswapd と CPU の使用率が低下します。Linux 上で MySQL Cluster を使用するときに 2.6 以降のカーネルを使用する場合は、ODirect を有効にしてください。

    ODirect はデフォルトで無効になっています。

  • RestartOnErrorInsert

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0エラーコード20 - 4N

    この機能は、コードの個々のブロックをテストの一部として実行する際に、エラーの挿入が可能なデバッグバージョンをビルドする場合にのみ利用できます。

    この機能はデフォルトで無効になっています。

  • CompressedBackup

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    このパラメータを 1 に設定すると、バックアップファイルが圧縮されます。使用される圧縮は gzip --fast と同等であり、データノードで非圧縮バックアップファイルの格納に必要なスペースの 50% 以上を節約できます。圧縮バックアップは、個々のデータノードまたは (config.ini ファイルの [ndbd default] セクションにこのパラメータを設定することで) すべてのデータノードで有効化できます。

    重要

    圧縮バックアップを、この機能をサポートしない MySQL バージョンを実行するクラスタにリストアすることはできません。

    デフォルト値は 0 (無効) です。

  • CompressedLCP

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    このパラメータを 1 に設定すると、ローカルチェックポイントが圧縮されます。使用される圧縮は gzip --fast と同等であり、データノードで非圧縮チェックポイントファイルの格納に必要なスペースの 50% 以上を節約できます。圧縮 LCP は、個々のデータノードまたは (config.ini ファイルの [ndbd default] セクションにこのパラメータを設定することで) すべてのデータノードで有効化できます。

    重要

    圧縮ローカルチェックポイントを、この機能をサポートしない MySQL バージョンを実行するクラスタにリストアすることはできません。

    デフォルト値は 0 (無効) です。

タイムアウト、間隔、およびディスクページングの制御

クラスタデータノード内のさまざまなアクション間のタイムアウトと間隔を指定する、いくつかの [ndbd] パラメータがあります。ほとんどのタイムアウト値はミリ秒単位で指定します。この例外については、該当する箇所で説明します。

  • TimeBetweenWatchDogCheck

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒600070 - 4294967039 (0xFFFFFEFF)N

    メインスレッドがある時点で無限ループに陥ることを防ぐため、ウォッチドッグスレッドがメインスレッドをチェックします。このパラメータは、チェック間のミリ秒数を指定します。プロセスが 3 回のチェック後も同じ状態の場合、ウォッチドッグスレッドはプロセスを強制終了します。

    このパラメータは、実験のため、またはローカルの状態に合わせて簡単に変更できます。これをノード単位で指定することもできますが、指定することはほとんどありません。

    デフォルトのタイムアウトは 6000 ミリ秒 (6 秒) です。

  • TimeBetweenWatchDogCheckInitial

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒600070 - 4294967039 (0xFFFFFEFF)N

    これは TimeBetweenWatchDogCheck パラメータとほぼ同じですが、TimeBetweenWatchDogCheckInitial はメモリー割り当てが行われる初期起動段階でデータベースノード内部の実行チェック間に経過する時間を制御します。

    デフォルトのタイムアウトは 6000 ミリ秒 (6 秒) です。

  • StartPartialTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒300000 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、クラスタの初期化ルーチンが呼び出されるまでにクラスタがデータノードの起動を待つ時間を指定します。このタイムアウトは、可能なかぎり、クラスタの部分的起動を回避するために使用されます。

    このパラメータは、クラスタの初期起動または初期再起動の実行時にオーバーライドされます。

    デフォルト値は 30000 ミリ秒 (30 秒) です。0 にするとタイムアウトが無効になり、すべてのノードが使用可能な場合にのみクラスタを起動できるようになります。

  • StartPartitionedTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒600000 - 4294967039 (0xFFFFFEFF)N

    StartPartialTimeout ミリ秒の待機後にクラスタが起動できる状態になっても、まだパーティション化された状態の可能性がある場合、クラスタはこのタイムアウトが経過するまで待機します。StartPartitionedTimeout を 0 に設定すると、クラスタは無期限で待機します。

    このパラメータは、クラスタの初期起動または初期再起動の実行時にオーバーライドされます。

    デフォルトのタイムアウトは 60000 ミリ秒 (60 秒) です。

  • StartFailureTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒00 - 4294967039 (0xFFFFFEFF)N

    データノードでこのパラメータで指定された時間内に起動シーケンスが完了されなかった場合、ノードの起動は失敗します。このパラメータを 0 (デフォルト値) に設定すると、データノードのタイムアウトは適用されません。

    このパラメータでは、0 以外の値はミリ秒単位で測定されます。非常に多くのデータを含むデータノードでは、このパラメータを増やすようにしてください。たとえば、数ギガバイトのデータを含むデータノードの場合、ノードを再起動するのに 10-15 分 (つまり、600000-1000000 ミリ秒) の時間が必要です。

  • StartNoNodeGroupTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒150000 - 4294967039 (0xFFFFFEFF)N

    Nodegroup = 65536 でデータノードを構成すると、そのノードはどのノードグループにも割り当てられないものとみなされます。その場合、クラスタは StartNoNodegroupTimeout ミリ秒待機してから、そのようなノードを --nowait-nodes オプションに渡されたリストに追加されたものとして扱い、起動します。デフォルト値は 15000 です (つまり、管理サーバーは 15 秒待機します)。このパラメータを 0 に設定すると、クラスタは無期限に待機します。

    StartNoNodegroupTimeout はクラスタ内のすべてのデータノードで同じにする必要があります。そのため、これは個々のデータノードではなく、常に config.ini ファイルの [ndbd default] セクションに設定するようにしてください。

    詳細は、セクション18.5.13「MySQL Cluster データノードのオンライン追加」を参照してください。

  • HeartbeatIntervalDbDb

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒500010 - 4294967039 (0xFFFFFEFF)N

    障害の発生したノードを検出する主な方法の 1 つは、ハートビートを使用することです。このパラメータは、ハートビート信号の送信回数と予想される受信回数を指定します。3 回連続でハートビート間隔が失敗すると、そのノードはデッドと宣言されます。したがって、ハートビートメカニズムによる障害検出の最大時間は、ハートビート間隔の 4 倍になります。

    MySQL Cluster NDB 7.3 以降では、デフォルトのハートビート間隔は 5000 ミリ秒 (5 秒) です。このパラメータを大幅に変更しないでください。また、ノード間の違いが大きくならないようにしてください。あるノードが 5000 ミリ秒を使用し、それを監視するノードが 1000 ミリ秒を使用する場合、そのノードは非常に速くデッドと宣言されます。このパラメータはオンラインのソフトウェアアップグレード中に変更できますが、少しずつ増やしてください。

    ネットワーク通信と待機時間も参照してください。

  • HeartbeatIntervalDbApi

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒1500100 - 4294967039 (0xFFFFFEFF)N

    各データノードは各 MySQL サーバー (SQL ノード) にハートビート信号を送信して、接続されたままであるか確認します。MySQL サーバーが時間内にハートビートを送信できなかった場合、デッドと宣言されます。その場合、進行中のすべてのトランザクションが完了し、リソースが解放されます。以前の MySQL インスタンスによって開始されたすべてのアクティビティーが完了するまで、SQL ノードは再接続できません。この判定に使用される 3 ハートビートの条件は、HeartbeatIntervalDbDb で説明したものと同じです。

    デフォルトの間隔は 1500 ミリ秒 (1.5 秒) です。個々のデータノードはほかのすべてのデータノードと関係なく接続中の MySQL サーバーを監視するため、この間隔は各データノードで異なることがあります。

    詳細は、ネットワーク通信と待機時間を参照してください。

  • HeartbeatOrder

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値00 - 65535S

    データノードは、各データノードが直前のデータノードをモニターする循環的な方法で、相互にハートビートを送信します。ハートビートが特定のデータノードによって検出されなかった場合、このノードは循環の直前のデータノードをデッド (つまり、クラスタからアクセスできなくなった) と宣言します。データノードがデッドであるという判定はグローバルに行われます。つまり、データノードがデッドと宣言されると、そのノードはクラスタ内のすべてのノードからそのようにみなされます。

    異なるホストに配置されたデータノード間のハートビートが (たとえば、非常に長いハートビート間隔や一時的な接続の問題によって) ほかのノードペア間のハートビートに比べて遅すぎるために、データノードがまだクラスタの一部として機能しているにもかかわらず、デッドと宣言される可能性があります。

    このような状況では、データノード間のハートビートの転送順序が、特定のデータノードがデッドと宣言されるかどうかに影響している可能性があります。この宣言が不必要に発生すると、それがノードグループの損失を招き、さらにクラスタの障害につながる可能性があります。

    次の表に示すように、2 台のホストコンピュータ host1 および host2 で実行されている 4 つのデータノード A、B、C、および D があり、これらのデータノードが 2 つのノードグループを構成しているセットアップについて考えます。

    ノードグループ

    host1 で実行されているノード

    host2 で実行されているノード

    ノードグループ 0:

    ノード A

    ノード B

    ノードグループ 1:

    ノード C

    ノード D

    ハートビートが A->B->C->D->A の順に転送されるとします。この場合、ホスト間のハートビートが失われると、ノード B がノード A をデッドと宣言し、ノード C が B をデッドと宣言します。この結果、ノードグループ 0 が失われるため、クラスタが機能停止します。一方、転送の順序が A->B->D->C->A である (およびほかのすべての条件が前述のままである) 場合は、ハートビートが失われると、ノート A および D がデッドと宣言されます。この場合、各ノードグループに 1 つずつノードが残っているため、クラスタは存続します。

    HeartbeatOrder 構成パラメータは、ユーザーがハートビートの転送順序を構成できるようにします。HeartbeatOrder のデフォルト値は 0 です。すべてのデータノードでデフォルト値を使用できるようにすると、ハートビートの転送順序は NDB によって決定されます。このパラメータを使用する場合は、クラスタ内のすべてのデータノードで 0 以外の値 (最大 65535) に設定する必要があります。また、この値は各データノードで一意である必要があります。これにより、ハートビートが HeartbeatOrder 値の小さいノードから大きいノードに順に転送される (その後、HeartbeatOrder がもっとも大きいノードからもっとも小さいノードに転送され、循環が完結する) ようになります。たとえば、前述のシナリオでハートビートの転送順序 A->B->D->C->A を強制するために、値を連続させる必要はありません。ここに示すような HeartbeatOrder 値を設定できます。

    ノードHeartbeatOrder
    A10
    B20
    C30
    D25

    このパラメータを使用して実行中の MySQL Cluster 内のハートビートの転送順序を変更するには、最初にグローバル構成 (config.ini) ファイルにクラスタ内の各データノードの HeartbeatOrder を設定する必要があります。変更を有効にするには、次のいずれかを実行する必要があります。

    • クラスタ全体の完全なシャットダウンと再起動。

    • 2 回連続のクラスタのローリング再起動。両方のローリング再起動で、すべてのノードが同じ順序で再起動される必要があります

    DUMP 908 を使用すると、データノードログでこのパラメータの効果を観察できます。

  • ConnectCheckIntervalDelay

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0文字列00 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、データノード間の接続チェックを有効にします。ConnectCheckIntervalDelay 秒の間隔以内に応答できないデータノードは疑いありとみなされ、そのような間隔が 2 回続いたあとでデッドとみなされます。

    このパラメータのデフォルト値は 0 です。これは、MySQL Cluster NDB 7.1 からの変更点です。

  • TimeBetweenLocalCheckpoints

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.04 バイトワードの数 (底 2 の対数として)200 - 31N

    このパラメータは、新しいローカルポイントを開始するまでの待機時間を指定しないという点で例外です。どちらかといえば、比較的少数の更新が行われるクラスタ内でローカルチェックポイントが実行されないようにするために使用されます。更新回数が多いほとんどのクラスタでは、直前のローカルチェックポイントが完了した直後に新しいローカルチェックポイントが開始される可能性があります。

    前のローカルチェックポイントの開始以降に実行されたすべての書き込み操作のサイズが追加されます。このパラメータは、4 バイトワードの数の底 2 の対数として指定される点でも例外的です。したがって、デフォルト値の 20 は 4M バイト (4 * 220) の書き込み操作を意味し、21 は 8M バイトを意味し、最大値の 31 は 8G バイトの書き込み操作と同等です。

    クラスタ内のすべての書き込み操作がまとめて追加されます。TimeBetweenLocalCheckpoints を 6 以下に設定すると、ローカルチェックポイントはクラスタのワークロードと無関係に途切れることなく連続的に実行されます。

  • TimeBetweenGlobalCheckpoints

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒200020 - 32000N

    トランザクションがコミットされると、データがミラー化されているノードのメインメモリーでコミットされます。ただし、トランザクションログレコードはコミットの一部としてディスクにフラッシュされません。トランザクションを少なくとも 2 台の自立的なホストマシン上で安全にコミットすることで、持続性に関する妥当な基準が満たされるはずだということがこの動作の根拠です。

    また、最悪のケース (クラスタの完全なクラッシュ) も適切に処理されるようにすることが重要です。この実行を保証するために、特定の間隔以内に行われるすべてのトランザクションはグローバルチェックポイントに取り込まれます。これは、ディスクにフラッシュされたコミット済みのトランザクションとみなすことができます。つまり、トランザクションはコミットプロセスの一部としてグローバルチェックポイントグループに組み込まれます。その後、このグループのログレコードがディスクにフラッシュされると、トランザクションのグループ全体がクラスタ内のコンピュータ上のディスクに安全にコミットされます。

    このパラメータは、グローバルチェックポイント間の間隔を定義します。デフォルトは 2000 ミリ秒です。

  • TimeBetweenEpochs

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒1000 - 32000N

    このパラメータは、MySQL Cluster レプリケーションの同期エポック間の間隔を定義します。デフォルト値は 100 ミリ秒です。

    TimeBetweenEpochs は、MySQL Cluster レプリケーションのパフォーマンスを向上させるために使用できる micro-GCP の実装の一部です。

  • TimeBetweenEpochsTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒00 - 256000N

    このパラメータは、MySQL Cluster レプリケーションの同期エポックのタイムアウトを定義します。このパラメータで決定された時間内にノードがグローバルチェックポイントに参加できなかった場合、ノードはシャットダウンされます。MySQL Cluster NDB 7.3 以降では、デフォルト値は 0 です (つまり、タイムアウトは無効になっています)。

    TimeBetweenEpochsTimeout は、MySQL Cluster レプリケーションのパフォーマンスを向上させるために使用できる micro-GCP の実装の一部です。

    GCP の保存に 1 分を超える時間がかかった場合、または GCP の保存に 10 秒を超える時間がかかった場合は、常にこのパラメータの現在の値と警告がクラスタログに書き込まれます。

    このパラメータを 0 に設定すると、保存のタイムアウト、コミットのタイムアウト、またはその両方によって発生する GCP の停止を無効にします。このパラメータに指定できる最大値は 256000 ミリ秒です。

  • MaxBufferedEpochs

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0エポック1000 - 100000N

    サブスクライブするノードが遅延できる未処理のエポック数。この数を超えると、遅延するサブスクライバが切断されます。

    ほとんどの通常の操作では、デフォルト値の 100 で十分です。サブスクライブするノードの遅延によって切断が発生する場合、その原因は通常、プロセスまたはスレッドに関するネットワークまたはスケジューリングの問題です。(まれな状況ですが、NDB クライアントのバグによってこの問題が起きることもあります。)エポックが大きいときは、この値をデフォルトより小さく設定するのが望ましい場合もあります。

    切断することで、クライアントの問題によってデータノードサービスが影響を受け、データをバッファリングするためのメモリーが不足し、最終的にシャットダウンすることはなくなります。代わりに、切断の結果として (たとえば、バイナリログのギャップイベントによって) クライアントが影響を受け、クライアントは強制的にプロセスを再接続または再起動します。

  • MaxBufferedEpochBytes

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト2621440026214400 (0x01900000) - 4294967039 (0xFFFFFEFF)N

    このノードがエポックをバッファリングするために割り当てるバイトの合計数。

  • TimeBetweenInactiveTransactionAbortCheck

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒10001000 - 4294967039 (0xFFFFFEFF)N

    タイムアウトの処理は、各トランザクションのタイマーをこのパラメータで指定された間隔ごとに 1 回チェックして実行されます。したがって、このパラメータを 1000 ミリ秒に設定すると、すべてのトランザクションのタイムアウトが毎秒 1 回チェックされます。

    デフォルト値は 1000 ミリ秒 (1 秒) です。

  • TransactionInactiveTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒[テキストを参照]0 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、トランザクションが中止されるまでに、同じトランザクション内の操作間で経過が許容される最大時間を指定します。

    このパラメータのデフォルトは 4G です (最大も同じです)。トランザクションがロックを保持する期間が長すぎないようにする必要があるリアルタイムデータベースでは、このパラメータを比較的小さい値に設定するようにしてください。単位はミリ秒です。

  • TransactionDeadlockDetectionTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒120050 - 4294967039 (0xFFFFFEFF)N

    ノードは、トランザクションを含むクエリーの実行時に、クラスタ内のほかのノードが応答するのを待機してから処理を続行します。応答の失敗は、次のいずれかの理由で発生します。

    • ノードがデッドです

    • 操作がロックキューに入りました

    • アクションの実行を要求したノードに非常に高い負荷がかかっている可能性があります。

    このタイムアウトパラメータは、トランザクションが中止されるまでにトランザクションコーディネータが別のノードによるクエリーの実行を待機する時間を指定するもので、ノード障害の処理とデッドロックの検出において重要です。

    デフォルトのタイムアウト値は 1200 ミリ秒 (1.2 秒) です。

    このパラメータの最小は 50 ミリ秒です。

  • DiskSyncSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト4M32K - 4294967039 (0xFFFFFEFF)N

    これは、ローカルチェックポイントファイルにデータをフラッシュするまでに格納される最大バイト数です。これは、パフォーマンスを大幅に低下させる可能性がある書き込みバッファリングを禁止するために行われます。このパラメータは、TimeBetweenLocalCheckpoints の代わりに使用するためのものではありません

    注記

    ODirect が有効になっている場合は、DiskSyncSize を設定する必要はありません。実際、そのような場合は、その値が無視されます。

    デフォルト値は 4M (4 メガバイト) です。

  • DiskCheckpointSpeed

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト10M1M - 4294967039 (0xFFFFFEFF)N

    ローカルチェックポイント中にディスクに転送されるデータの量 (バイト/秒)。この割り当ては DML 操作とバックアップ (バックアップロギングは除く) で共有されます。これは、集約的な DML の実行中に開始されたバックアップが Redo ログバッファーの大量発生によって妨害され、競合が深刻な場合は完全に失敗する可能性があることを意味します。

    デフォルト値は 10M (10 メガバイト/秒) です。

    MySQL Cluster 7.4.1 以降では、このパラメータは非推奨であり、代わりに構成パラメータ MinDiskWriteSpeed, MaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用して LCP とバックアップの書き込み速度を制御できます。

  • DiskCheckpointSpeedInRestart

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト100M1M - 4294967039 (0xFFFFFEFF)N

    再起動操作の一部であるローカルチェックポイント中にディスクに転送されるデータの量 (バイト/秒)。

    デフォルト値は 100M (100 メガバイト/秒) です。

    MySQL Cluster 7.4.1 以降では、このパラメータは非推奨であり、代わりに構成パラメータ MinDiskWriteSpeed, MaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用して LCP とバックアップの書き込み速度を制御できます。

  • NoOfDiskPagesToDiskAfterRestartTUP

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster 7.4.1 以降では、代わりにそのリリースで導入された構成パラメータ MinDiskWriteSpeed, MaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • MaxDiskWriteSpeed

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.4.1数値20M1M - 1024GS

    この MySQL Cluster で (このデータノードまたはその他のデータノードによって) 再起動が行われていない場合に、ローカルチェックポイントおよびバックアップ操作によるディスク書き込みの最大速度 (バイト/秒) を設定します。

    このデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOwnRestart を使用します。ほかのデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOtherNodeRestart を使用します。すべての LCP およびバックアップ操作によるディスク書き込みの最小速度を調整するには、MinDiskWriteSpeed を設定します。

    MaxDiskWriteSpeed は MySQL Cluster NDB 7.4.1 で追加されました。

  • MaxDiskWriteSpeedOtherNodeRestart

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.4.1数値50M1M - 1024GS

    この MySQL Cluster に含まれるこのノード以外の 1 つ以上のデータノードが再起動している場合に、ローカルチェックポイントおよびバックアップ操作によるディスク書き込みの最大速度 (バイト/秒) を設定します。

    このデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOwnRestart を使用します。クラスタ内ではデータノードが再起動されていない場合に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeed を使用します。すべての LCP およびバックアップ操作によるディスク書き込みの最小速度を調整するには、MinDiskWriteSpeed を設定します。

    MaxDiskWriteSpeedOtherNodeRestart は MySQL Cluster NDB 7.4.1 で追加されました。

  • MaxDiskWriteSpeedOwnRestart

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.4.1数値200M1M - 1024GS

    このデータノードの再起動時の、ローカルチェックポイントおよびバックアップ操作によるディスク書き込みの最大速度 (バイト/秒) を設定します。

    ほかのデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOtherNodeRestart を使用します。クラスタ内ではデータノードが再起動されていない場合に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeed を使用します。すべての LCP およびバックアップ操作によるディスク書き込みの最小速度を調整するには、MinDiskWriteSpeed を設定します。

    MaxDiskWriteSpeedOwnRestart は MySQL Cluster NDB 7.4.1 で追加されました。

  • MinDiskWriteSpeed

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.4.1数値10M1M - 1024GS

    ローカルチェックポイントおよびバックアップ操作によるディスク書き込みの最小速度 (バイト/秒) を設定します。

    さまざまな条件下で LCP およびバックアップに許可されるディスク書き込みの最大速度は、パラメータ MaxDiskWriteSpeedMaxDiskWriteSpeedOwnRestart、および MaxDiskWriteSpeedOtherNodeRestart を使用して調整できます。詳細は、これらのパラメータの説明を参照してください。

    MinDiskWriteSpeed は MySQL Cluster NDB 7.4.1 で追加されました。

  • NoOfDiskPagesToDiskAfterRestartACC

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。MySQL Cluster NDB 7.3 では、代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster NDB 7.4.1 以降では、パラメータ MinDiskWriteSpeedMaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • NoOfDiskPagesToDiskDuringRestartTUP (非推奨)

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。MySQL Cluster NDB 7.3 では、代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster NDB 7.4.1 以降では、パラメータ MinDiskWriteSpeedMaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • NoOfDiskPagesToDiskDuringRestartACC (非推奨)

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。MySQL Cluster NDB 7.3 では、代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster NDB 7.4.1 以降では、パラメータ MinDiskWriteSpeedMaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • ArbitrationTimeout

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒750010 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、データノードがアービトレーションメッセージに対するアービトレータからの応答を待機する時間を設定します。これを超えた場合は、ネットワークが切断されたとみなされます。

    MySQL Cluster NDB 7.3 以降では、デフォルト値は 7500 ミリ秒 (7.5 秒) です。

  • Arbitration

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0列挙デフォルトデフォルト、無効、WaitExternalN

    Arbitration パラメータを使用して、このパラメータに指定できる 3 つの値のいずれかに対応するアービトレーションスキームを選択できます。

    • デフォルト  この場合は、管理および API ノードの ArbitrationRank 設定で指定されるとおりに、アービトレーションが正常に進行します。これはデフォルト値です。

    • Disabled config.ini ファイルの [ndbd default] セクションに Arbitration = Disabled を設定すると、すべての管理および API ノードで ArbitrationRank の 0 を設定した場合と同じ結果が得られます。Arbitration をこのように設定すると、ArbitrationRank の設定はすべて無視されます。

    • WaitExternal Arbitration パラメータを使用して、クラスタが内部でアービトレーションを処理する代わりに ArbitrationTimeout で指定された時間が経過するまで外部のクラスタマネージャーアプリケーションによるアービトレーションの実行を待機する方法で、アービトレーションを構成することもできます。これを行うには、config.ini ファイルの [ndbd default] セクションに Arbitration = WaitExternal を設定します。WaitExternal の設定で最良の結果を得るためには、ArbitrationTimeout を外部クラスタマネージャーがアービトレーションを実行するのに必要な間隔の 2 倍に設定することをお勧めします。

    重要

    このパラメータは、クラスタ構成ファイルの [ndbd default] セクションでのみ使用するようにしてください。Arbitration を個々のデータノードで異なる値に設定すると、クラスタの動作は不特定になります。

バッファリングとロギング  上級ユーザーは、いくつかの [ndbd] 構成パラメータを使用するとことで、ノードプロセスが使用するリソースをより細かく制御したり、必要に応じてさまざまなバッファーサイズを調整したりできます。

これらのバッファーは、ログレコードをディスクに書き込む際に、ファイルシステムに対するフロントエンドとして使用されます。ノードがディスクレスモードで実行されている場合は、NDB ストレージエンジンのファイルシステム抽象化レイヤーによってディスク書き込みが偽装されるため、ペナルティーなしでこれらのパラメータを最小値に設定できます。

  • UndoIndexBuffer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし2M1M - 4294967039 (0xFFFFFEFF)N

    このパラメータでサイズが設定される Undo インデックスバッファーは、ローカルチェックポイント中に使用されます。NDB ストレージエンジンは、使用可能な Redo ログとともに、チェックポイントの一貫性に基づくリカバリスキームを使用します。システム全体の書き込みをブロックせずに一貫性のあるチェックポイントを作成するため、ローカルチェックポイントの実行中に Undo ロギングが行われます。Undo ロギングは、一度に 1 つのテーブルフラグメントに対してアクティブ化されます。この最適化が可能なのは、テーブルが完全にメインメモリーに格納されているためです。

    Undo インデックスバッファーは、主キーのハッシュインデックスの更新で使用されます。挿入と削除では、ハッシュインデックスが再編成されます。NDB ストレージエンジンは、すべての物理的な変更をシステムの再起動時に取り消すことができるように、変更を 1 つのインデックスページにマップする Undo ログレコードを書き込みます。また、ローカルチェックポイントの開始時に、各フラグメントのアクティブな挿入操作も記録します。

    読み取りと更新では、ロックビットが設定され、ハッシュインデックスエントリのヘッダーが更新されます。これらの変更はページ書き込みアルゴリズムによって処理されるため、これらの操作に Undo ロギングは必要ありません。

    このバッファーはデフォルトで 2M バイトです。最小値は 1M バイトです。ほとんどのアプリケーションではこれで十分です。大規模なトランザクションや大規模な主キーとともに非常に大規模または多数の挿入および削除を実行するアプリケーションでは、このバッファーのサイズを増やす必要がある場合があります。このバッファーが小さすぎる場合、NDB ストレージエンジンは内部エラーコード 677「Index UNDO buffers overloaded」を発行します。

    重要

    ローリング再起動中にこのパラメータの値を減らすのは安全ではありません。

  • UndoDataBuffer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし16M1M - 4294967039 (0xFFFFFEFF)N

    このパラメータは、Undo データバッファーのサイズを設定します。Undo データバッファーは、Undo インデックスバッファーとほぼ同じ機能を実行しますが、インデックスメモリーではなくデータメモリーに関して使用されます。このバッファーは、フラグメントのローカルチェックポイントフェーズで挿入、削除、および更新のために使用されます。

    Undo ログエントリは記録される操作が増えるにつれて大きくなる傾向があるため、このバッファーも対応するインデックスメモリーより大きくなります (デフォルト値は 16M バイトです)。

    一部のアプリケーションでは、このメモリー量が不必要に大きい場合があります。そのような場合は、このサイズを最小の 1M バイトに減らすことができます。

    ほとんどの場合、このバッファーのサイズを増やす必要はありません。そのような必要がある場合は、データベースの更新アクティビティーによって発生する負荷をディスクが実際に処理できているかどうかをチェックすることをお勧めします。このバッファーのサイズを増やしても、ディスクスペースの不足を解消することはできません。

    このバッファーが小さすぎて過密状態になった場合、NDB ストレージエンジンは次の内部エラーコードを発行します: 891 (Data UNDO buffers overloaded)。

    重要

    ローリング再起動中にこのパラメータの値を減らすのは安全ではありません。

  • RedoBuffer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト32M1M - 4294967039 (0xFFFFFEFF)N

    更新アクティビティーも、すべて記録する必要があります。Redo ログにより、システムが再起動されるたびにこれらの更新を再現できるようになります。NDB のリカバリアルゴリズムは、Undo ログとともにデータのファジーチェックポイントを使用し、Redo ログを適用してリストアポイントまでのすべての変更を再現します。

    RedoBuffer は、Redo ログが書き込まれるバッファーのサイズを設定します。デフォルト値は 32M バイトです。最小値は 1M バイトです。

    このバッファーが小さすぎる場合、NDBストレージエンジンは内部エラーコード 1221 (REDO log buffers overloaded)を発行します。このため、クラスタ構成のオンライン変更の一部として RedoBuffer の値を減らそうとする場合は注意してください。

    ndbmtd は、LDM スレッドごとに別個のバッファーを割り当てます (ThreadConfig を参照してください)。たとえば、4 つの LDM スレッドがある場合、ndbmtd データノードには実際には 4 つのバッファーがあり、それぞれに RedoBuffer バイト (合計で 4 * RedoBuffer バイト) が割り当てられます。

  • EventLogBufferSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト81920 - 64KS

    データノード内部の NDB ログイベントに使用される循環バッファーのサイズを制御します。

ログメッセージの制御  クラスタの管理では、stdout に送信されるさまざまなイベントタイプのログメッセージ数を制御できることが非常に重要です。イベントカテゴリごとに、16 個の設定可能なイベントレベル (番号 0-15) があります。特定のイベントカテゴリのイベントレポートをレベル 15 に設定すると、そのカテゴリのすべてのイベントレポートが stdout に送信されます。0 に設定すると、そのカテゴリのイベントレポートがまったく行われなくなります。

デフォルトでは、起動メッセージのみが stdout に送信され、残りのイベントレポートのレベルはデフォルトの 0 に設定されます。これは、これらのメッセージが管理サーバーのクラスタログにも送信されるためです。

管理クライアントで同じようなレベルのセットを設定すると、クラスタログに記録するイベントのレベルを指定できます。

  • LogLevelStartup

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数10 - 15N

    プロセスの起動中に生成されるイベントのレポートレベル。

    デフォルトのレベルは 1 です。

  • LogLevelShutdown

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数00 - 15N

    ノードの正常なシャットダウンの一部として生成されるイベントのレポートレベル。

    デフォルトのレベルは 0 です。

  • LogLevelStatistic

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数00 - 15N

    主キー読み取りの数、更新の数、挿入の数、バッファーの使用状況に関する情報などの統計イベントのレポートレベル。

    デフォルトのレベルは 0 です。

  • LogLevelCheckpoint

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ログレベル00 - 15N

    ローカルおよびグローバルチェックポイントによって生成されるイベントのレポートレベル。

    デフォルトのレベルは 0 です。

  • LogLevelNodeRestart

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数00 - 15N

    ノード再起動中に生成されるイベントのレポートレベル。

    デフォルトのレベルは 0 です。

  • LogLevelConnection

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数00 - 15N

    クラスタノード間の接続によって生成されるイベントのレポートレベル。

    デフォルトのレベルは 0 です。

  • LogLevelError

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数00 - 15N

    クラスタ全体のエラーおよび警告によって生成されるイベントのレポートレベル。これらのエラーは、ノードの障害の原因にはなりませんが、レポートする価値はあると考えられます。

    デフォルトのレベルは 0 です。

  • LogLevelCongestion

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0levelr00 - 15N

    輻輳によって生成されるイベントのレポートレベル。これらのエラーは、ノードの障害の原因にはなりませんが、レポートする価値はあると考えられます。

    デフォルトのレベルは 0 です。

  • LogLevelInfo

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数00 - 15N

    クラスタの一般的な状態に関する情報として生成されるイベントのレポートレベル。

    デフォルトのレベルは 0 です。

  • MemReportFrequency

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし00 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、データノードのメモリー使用状況レポートをクラスタログに記録する頻度を制御します。これは、レポート間の秒数を表す整数値です。

    各データノードのデータメモリーおよびインデックスメモリーの使用状況は、config.ini ファイルに設定された DataMemory および IndexMemory の割合と 32K バイトのページ数の両方でそれぞれ記録されます。たとえば、DataMemory が 100M バイトであり、特定のデータノードがデータメモリーのストレージとして 50M バイトを使用している場合、クラスタログの対応する行はこのようになります。

    2006-12-24 01:18:16 [MgmSrvr] INFO -- Node 2: Data usage is 50%(1280 32K pages of total 2560)

    MemReportFrequency は必須のパラメータではありません。使用する場合は、config.ini[ndbd default] セクションですべてのクラスタデータノード用に設定することも、構成ファイルの対応する [ndbd] セクションで個々のデータノード用に設定またはオーバーライドすることもできます。最小値 (デフォルト値も同じ) は 0 です。この場合は、セクション18.5.6.2「MySQL Cluster ログイベント」の統計イベントの説明で指摘したように、メモリー使用量が特定の割合 (80%、90%、および 100%) に達したときにのみ、メモリーのレポートが記録されます。

  • StartupStatusReportFrequency

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.000 - 4294967039 (0xFFFFFEFF)N

    --initial を指定してデータノードを起動すると、起動フェーズ 4 (セクション18.5.1「MySQL Cluster の起動フェーズのサマリー」を参照してください) で Redo ログファイルが初期化されます。NoOfFragmentLogFilesFragmentLogFileSize、またはその両方に非常に大きな値を設定すると、この初期化に長い時間がかかることがあります。StartupStatusReportFrequency 構成パラメータを使用して、このプロセスの進行に関するレポートを定期的に記録するよう強制できます。この場合、ここに示すように、初期化されたファイルの数とスペースの量に関する進行状況がクラスタログにレポートされます。

    2009-06-20 16:39:23 [MgmSrvr] INFO -- Node 1: Local redo log file initialization status:
    #Total files: 80, Completed: 60
    #Total MBytes: 20480, Completed: 15557
    2009-06-20 16:39:23 [MgmSrvr] INFO -- Node 2: Local redo log file initialization status:
    #Total files: 80, Completed: 60
    #Total MBytes: 20480, Completed: 15570

    これらのレポートは、起動フェーズ 4 で StartupStatusReportFrequency 秒ごとに記録されます。StartupStatusReportFrequency が 0 (デフォルト) の場合は、Redo ログファイルの初期化プロセスの開始時と完了時にのみ、レポートがクラスタログに書き込まれます。

デバッグパラメータ  MySQL Cluster NDB 7.3 以降では、DictTrace を使用して、テーブルの作成および削除によって生成されたイベントのトレースを記録できます。このパラメータは、NDB のカーネルコードをデバッグする場合にのみ役立ちます。DictTrace は整数値を取ります。現在サポートされる唯一の値は 0 (デフォルト。ロギングなし) と 1 (ロギングが有効) です。

バックアップパラメータ  このセクションで説明する [ndbd] パラメータは、オンラインバックアップの実行用に確保されるメモリーバッファーを定義します。

  • BackupDataBufferSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト16M0 - 4294967039 (0xFFFFFEFF)N

    バックアップの作成では、データをディスクに転送するために使用される 2 つのバッファーがあります。バックアップデータバッファーは、ノードのテーブルをスキャンして記録されるデータを書き込むために使用されます。このバッファーへの書き込みが BackupWriteSize で指定されたレベルに達すると、ページがディスクに転送されます。バックアッププロセスでは、データをディスクにフラッシュしながら、スペースがなくなるまでこのバッファーに書き込み続けることができます。これが発生すると、バックアッププロセスでスキャンを一時停止し、ディスク書き込みがある程度完了してメモリーが解放され、スキャンを続行できるようになるまで待機します。

    このパラメータのデフォルト値は 16M バイトです。

  • BackupLogBufferSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト16M0 - 4294967039 (0xFFFFFEFF)N

    バックアップログバッファーはバックアップデータバッファーと同じような役割を果たしますが、バックアップの実行中に行われたテーブル書き込みのログを生成するために使用されます。これらのページの書き込みにはバックアップデータバッファーと同じ原則が適用されますが、バックアップログバッファーのスペースがなくなると、バックアップは失敗します。そのため、バックアップログバッファーのサイズは、バックアップ実行中の書き込みアクティビティーによって発生する負荷を処理するのに十分な大きさである必要があります。セクション18.5.3.3「MySQL Cluster バックアップ用の構成」を参照してください。

    ほとんどのアプリケーションでは、このパラメータのデフォルト値で十分です。実際、バックアップログバッファーがいっぱいになった場合より、ディスク書き込みの速度が不十分な場合の方が、バックアップが失敗する可能性は高くなります。ディスクサブシステムがアプリケーションから発生する書き込み負荷に合わせて構成されていない場合は、クラスタが必要な操作を実行できない可能性が高くなります。

    ディスクやネットワーク接続よりもプロセッサがボトルネックになるような方法でクラスタノードを構成することをお勧めします。

    このパラメータのデフォルト値は 16M バイトです。

  • BackupMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト32M0 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、単純に BackupDataBufferSizeBackupLogBufferSize の合計です。

    MySQL Cluster NDB 7.3 以降では、このパラメータのデフォルト値は 16M バイト + 16M バイト = 32M バイトです。

    重要

    BackupDataBufferSizeBackupLogBufferSize の合計が BackupMemory のデフォルト値を超える場合は、config.ini ファイルでこのパラメータをこれらの合計に明示的に設定する必要があります。

  • BackupReportFrequency

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.000 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、バックアップ中に管理クライアントでバックアップステータスレポートを発行する頻度と、そのようなレポートをクラスタログに書き込む頻度を制御します (クラスタイベントロギングで許可するように構成されている場合。ロギングとチェックポイントを参照してください)。BackupReportFrequency は、バックアップステータスレポート間の時間 (秒単位) を表します。

    デフォルト値は 0 です。

  • BackupWriteSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト256K2K - 4294967039 (0xFFFFFEFF)N

    このパラメータは、バックアップログおよびバックアップデータバッファーによってディスクに書き込まれるメッセージのデフォルトサイズを指定します。

    このパラメータのデフォルト値は 256K バイトです。

  • BackupMaxWriteSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト1M2K - 4294967039 (0xFFFFFEFF)N

    このパラメータは、バックアップログおよびバックアップデータバッファーによってディスクに書き込まれるメッセージの最大サイズを指定します。

    このパラメータのデフォルト値は 1M バイトです。

重要

これらのパラメータを指定するときは、次の関係が有効である必要があります。そうでない場合は、データノードを起動できません。

  • BackupDataBufferSize >= BackupWriteSize + 188K バイト

  • BackupLogBufferSize >= BackupWriteSize + 16K バイト

  • BackupMaxWriteSize >= BackupWriteSize

MySQL Cluster のリアルタイムパフォーマンスパラメータ

このセクションで説明する [ndbd] パラメータは、マルチプロセッサのデータノードホスト上の特定の CPU に対するスレッドのスケジューリングとロックで使用されます。

注記

これらのパラメータを使用するには、システムの root としてデータノードプロセスを実行する必要があります。

  • LockExecuteThreadToCPU

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0CPU ID64K0 - 64KN

    ndbd で使用する場合、このパラメータ (現在は文字列) は NDBCLUSTER の実行スレッドを処理するために割り当てられる CPU の ID を指定します。ndbmtd で使用する場合、このパラメータの値は実行スレッドを処理するために割り当てられる CPU ID のカンマ区切りリストです。リスト内の各 CPU ID は、0-65535 の (これらを含む) 範囲の整数にします。

    指定する ID の数は、MaxNoOfExecutionThreads によって指定される実行スレッドの数と一致するようにしてください。ただし、このパラメータを使用したときに、特定の順序でスレッドが CPU に割り当てられる保証はありません。ThreadConfig を使用すると、このようなより細かい制御が可能になります。

    LockExecuteThreadToCPU にデフォルト値はありません。

  • LockMaintThreadsToCPU

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0CPU ID[none]0 - 64KN

    このパラメータは、NDBCLUSTER の管理スレッドを処理するために割り当てられる CPU の ID を指定します。

    このパラメータの値は、0-65535 の (これらを含む) 範囲の整数です。MySQL Cluster NDB 7.3 以降では、デフォルト値はありません。

  • RealtimeScheduler

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    このパラメータを 1 に設定すると、データノードスレッドのリアルタイムスケジューリングが有効になります。

    MySQL Cluster NDB 7.3.3 より前では、このパラメータは ndbmtd を実行するノードで正常に機能しませんでした。(Bug #16961971)

    デフォルトは 0 (スケジューリングが無効) です。

  • SchedulerExecutionTimer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0マイクロ秒500 - 11000N

    このパラメータは、スレッドがスケジューラで実行されてから送信されるまでの時間 (ミリ秒) を指定します。これを 0 に設定すると、応答時間が最小化されます。スループットを向上させるため、この値を増やすことができますが、その代償として応答時間は長くなります。

    デフォルトは 50 マイクロ秒です。弊社のテストでは、これによって高負荷のケースで実質的に要求を遅延させずにスループットが若干向上することがわかっています。

  • SchedulerSpinTimer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0マイクロ秒00 - 500N

    このパラメータは、スレッドがスケジューラで実行されてからスリープ状態になるまでの時間 (ミリ秒) を指定します。

    デフォルト値は 0 です。

  • BuildIndexThreads

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値00 - 128S

    このパラメータは、システムまたはノードの起動中に順序付けされたインデックスの再構築時、および ndb_restore--rebuild-indexes の実行時に作成するスレッドの数を指定します。これは、データノードあたり複数のフラグメントがテーブルに存在するとき (たとえば、CREATE TABLEMAX_ROWS オプションが使用されたときなど) にのみサポートされます。

    このパラメータを 0 (デフォルト) に設定すると、マルチスレッドによる順序付けされたインデックスの構築が無効になります。

    このパラメータは、ndbd または ndbmtd を使用するときにサポートされます。

    データノードの初期再起動中にマルチスレッドによる構築を有効にするには、TwoPassInitialNodeRestartCopy データノード構成パラメータを TRUE に設定します。

  • TwoPassInitialNodeRestartCopy

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    データノードの初期再起動でマルチスレッドによる順序付けされたインデックスの構築を有効にするには、この構成パラメータを TRUE に設定します。これにより、ノードの初期再起動中にデータの 2 パスコピーが有効になります。

    同時に BuildIndexThreads を 0 以外の値に設定する必要があります。

  • Numa

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブール1...N

    NDB は、Non-Uniform Memory Access の設定と (発生するタイムアウトによる) マルチ CPU システムの影響をかなり受けやすくなっています。この事実と、ほとんどの MySQL Cluster ユーザーが numactl を採用しないことから、Linux システムで ndbd を実行しているときは、NUMA のサポートはデフォルトで無視されます。Linux システムが NUMA をサポートしていて、データノードのメモリーを NUMA で制御する必要がある場合は、このパラメータを 0 に設定できます。

    Numa 構成パラメータは、libnuma.so がインストールされている Linux システムでのみサポートされます。

マルチスレッドの構成パラメータ (ndbmtd) ndbmtd は、デフォルトではシングルスレッドプロセスとして動作するため、2 つの方法のいずれかを使用して、複数のスレッドを使用するように構成する必要があります。どちらの場合も、config.ini ファイルに構成パラメータを設定する必要があります。1 つ目の方法では、MaxNoOfExecutionThreads 構成パラメータに適切な値を設定します。MySQL Cluster NDB 7.3 以降では、ThreadConfig を使用して ndbmtd のマルチスレッドに関するより複雑なルールを設定できる 2 つ目の方法もサポートされます。このパラメータとマルチスレッドデータノードでの使用について、次のいくつかの段落で説明します。

  • MaxNoOfExecutionThreads

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数22 - 36IS
    NDB 7.3.3整数22 - 72IS

    このパラメータは、ndbmtd によって使用される実行スレッドの数を制御します。最大数は 72 です (MySQL Cluster NDB 7.3.3 より前では、これは 36 でした)。このパラメータは、config.ini ファイルの [ndbd] または [ndbd default] セクションに設定しますが、ndbmtd 専用であり、ndbd には適用されません。

    MaxNoOfExecutionThreads を設定すると、storage/ndb/kernel/src/vm/mt_thr_config.cpp ファイルのマトリックスで決定される各タイプのスレッド数が設定されます。この表は、MySQL Cluster NDB 7.4.3 以降で MaxNoOfExecutionThreads に指定できる値に対応するこれらのスレッド数を示しています (Bug #75220、Bug #20215689)。(以前のバージョンの MySQL Cluster に適用されるマトリックスに関する情報を示す表は、このあとにあります。)MySQL Cluster NDB 7.4.3 で変更された値を含む行は、強調表示のテキストで示しています。

    MaxNoOfExecutionThreads の値LDM スレッドTC スレッド送信スレッド受信スレッド
    0 .. 31101
    4 .. 62101
    7 .. 84101
    94201
    104211
    114311
    124312
    134322
    144422
    154522
    168312
    178412
    188422
    198522
    2010422
    2110522
    2210523
    2310623
    2412523
    2512623
    2612633
    2712733
    2812734
    2912834
    3012844
    3112944
    3216833
    3316834
    3416844
    3516944
    36161044
    37161045
    38161145
    39161155
    40201044
    41201045
    42201145
    43201155
    44201255
    45201256
    46201356
    47201366
    48241255
    49241256
    50241356
    51241366
    52241466
    53241467
    54241567
    55241577
    56241677
    57241678
    58241778
    59241788
    60241888
    61241889
    62241989
    63241999
    64321677
    65321678
    66321778
    67321788
    68321888
    69321889
    70321989
    71322089
    723220810

    次の表に、MySQL CLuster NDB 7.4.2 以前の MaxNoOfExecutionThreads の値に対応する各タイプのスレッド数を取得する方法を示します。この表は MySQL Cluster NDB 7.3.2 以前でも使用できますが、これらのバージョンでは MaxNoOfExecutionThreads の最大値が 36 であるため、この表の 36 より大きい値に対応する行は、MySQL Cluster NDB 7.3.3 より前には適用されません。

    MaxNoOfExecutionThreads の値LDM スレッドTC スレッド送信スレッド受信スレッド
    0 .. 31101
    4 .. 62101
    7 .. 84101
    94201
    104211
    114311
    124312
    134322
    144422
    154522
    168312
    178412
    188422
    198522
    208523
    218533
    228633
    238733
    2412523
    2512623
    2612633
    2712733
    2812734
    2912834
    3012844
    3112944
    3216833
    3316834
    3416844
    3516944
    36161044
    37161045
    38161145
    39161155
    40161255
    41161256
    42161356
    43161366
    44161466
    45161467
    46161567
    47161577
    48241255
    49241256
    50241356
    51241366
    52241466
    53241467
    54241567
    55241577
    56241677
    57241678
    58241778
    59241788
    60241888
    61241889
    62241989
    63241999
    64321677
    65321678
    66321778
    67321788
    68321888
    69321889
    70321989
    71322089
    723220810

    MySQL Cluster NDB 7.3 以降では、SUMA (レプリケーション) スレッドが常に 1 つ存在します。

    LDM スレッドの数が NoOfFragmentLogParts を超えないようにする必要があります。このため、このパラメータの値がデフォルト (4) の場合は、MaxNoOfExecutionThreads を 16 以上に設定したときに、この値も増やす必要があります。つまり、NoOfFragmentLogParts を、前の表に示された MaxNoOfExecutionThreads のこのパラメータの値に対応する LDM スレッド数の値に設定してください。

    スレッドタイプについては、このセクションで後述します (ThreadConfig を参照してください)。

    このパラメータを許容範囲外の値に設定すると、管理サーバーの起動が中止され、次のエラーが発生します: Error line number: Illegal value value for parameter MaxNoOfExecutionThreads

    MaxNoOfExecutionThreads では、値 0 または 1 は NDB の内部で 2 に切り上げられるため、2 がこのパラメータのデフォルト値および最小値とみなされます。

    MaxNoOfExecutionThreads は、通常、使用可能な CPU スレッド数と同じ値に設定し、各タイプのスレッド数を一般的なワークロードに合わせて割り当てることを目的としています。指定された CPU に特定のスレッドを割り当てるものではありません。提供された設定を変更することが望ましい場合や、スレッドを CPU にバインドする場合は、代わりに必要なタイプ、CPU、またはその両方に直接スレッドを割り当てることができる ThreadConfig を使用するようにしてください。

    マルチスレッドのデータノードプロセスでは、少なくともここに示す 5 個のスレッドを常に生成します。

    • 1 個のローカルクエリーハンドラ (LDM) スレッド

    • 1 個のトランザクションコーディネータ (TC) スレッド

    • 1 個の送信スレッド

      (このセクションの別の場所で説明するように、独立した送信スレッドを採用しないようにすることもできます。)

    • 1 個の受信スレッド

    • 1 個のサブスクリプションマネージャー (SUMA またはレプリケーション) スレッド

    LDM スレッドの数を変更するには、このパラメータと ThreadConfig のどちらを使用して変更する場合でも、常にシステムの再起動が必要です。クラスタの IndexMemory の使用率が 50% を超える場合、これを変更するにはクラスタの初期再起動が必要です。(このような場合は、最大で 30-35% の IndexMemory 使用率が推奨されます。)それ以外の場合は、ノード間でリソースの使用率と LDM スレッドの割り当てのバランスを取ることができず、結果として LDM スレッドの利用が不十分または過剰になり、最終的にデータノードに障害が発生します。

  • NoOfFragmentLogParts

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値44、8、12、16IN
    NDB 7.3.3数値44、8、12、16、24、32IN

    この ndbmtd に属する Redo ログのログファイルグループの数を設定します。MySQL Cluster NDB 7.3.3 より前では、この値は 4 から 16 までの (これらを含む) 4 の偶数倍である必要があります。MySQL Cluster NDB 7.3.3 以降では、最大は 32 です。以前と同様に、値は 4 の偶数倍である必要があります。

    ndbmtd が使用する LQH スレッドの数が NoOfFragmentLogParts を超えないようにする必要があります。また、MaxNoOfExecutionThreads を増やすとこの数が増える場合があります。詳細は、このパラメータの説明を参照してください。

  • ThreadConfig

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0文字列''...IS

    このパラメータは、ndbmtd で異なるタイプのスレッドを別の CPU に割り当てるために使用されます。この値は、次の構文を持つ形式の文字列です。

    ThreadConfig := entry[,entry[,...]]entry := type={param[,param[,...]]}type := ldm | main | recv | send | rep | ioparam := count=number | cpubind=cpu_list

    パラメータのリストを囲む中括弧 ({...}) は、リスト内にパラメータが 1 つしかない場合でも必要です。

    param (パラメータ) には、特定タイプのスレッドの数 (count)、特定タイプのスレッドのバインド先となる CPU (cpubind)、またはその両方を指定します。

    type 属性は、NDB のスレッドタイプを表します。MySQL Cluster NDB 7.3 以降でサポートされるスレッドタイプと各タイプで許容される count 値の範囲を、次のリストに示します。

    • ldm: データを処理するローカルクエリーハンドラ (DBLQH カーネルブロック)。使用される LDM スレッドの数が多いほど、データがより高度にパーティション化されます。各 LDM スレッドには、固有のデータおよびインデックスパーティションのセットと固有の Redo ログが保持されます。MySQL Cluster NDB 7.3.3 以降では、このようなスレッドの最大数は 32 です。MySQL Cluster NDB 7.3.2 以前では、最大は 16 です。

      重要

      LDM スレッドの数を変更するには、システムの再起動をクラスタの操作に対して効果的かつ安全に行う必要があります。(これは、MaxNoOfExecutionThreads を使用して実行する場合にもあてはまります。)IndexMemory の使用率が 50% を超える場合は、クラスタの初期再起動が必要です。このような場合は、IndexMemory の使用率を最大で 30-35% にすることをお勧めします。そうでない場合は、IndexMemory および DataMemory の使用率と LDM スレッドのノード間の割り当てのバランスが取れず、最終的にはデータノードの障害につながる可能性があります。

    • tc: 進行中のトランザクションの状態を含むトランザクションコーディネータスレッド (DBTC カーネルブロック)。MySQL Cluster NDB 7.3 では、TC スレッドの数を構成できます。MySQL Cluster NDB 7.3.3 以降では、合計 32 個が使用可能です。以前は 16 個でした。

      新しいトランザクションをそれぞれ 1 つの新しい TC スレッドに適切に割り当てることができます。ほとんどの場合、この実行が保証されるには、2 つの LDM スレッドに対して 1 つの TC スレッドで十分です。読み取りの数に比べて書き込みの数が少ないケースでは、4 つの LQH スレッドあたり 1 つの TC スレッドがあればトランザクション状態を維持できる可能性があります。逆に、非常に多くの更新を実行するアプリケーションでは、LDM スレッドに対する TC スレッドの比率を 1 に近づける (たとえば、4 つの LDM スレッドに対して TC スレッドを 3 つにする) 必要がある場合があります。

      範囲: (NDB 7.3.3 以降) 1-32、(NDB 7.3.2 以前) 1-16。

    • main: スキーマ管理を提供するデータディクショナリおよびトランザクションコーディネータ (DBDIH および DBTC カーネルブロック)。これは、常に 1 つの専用スレッドで処理されます。

      範囲: 1 のみ。

    • recv: 受信スレッド (CMVMI カーネルブロック)。各受信スレッドは、MySQL Cluster 内のほかのノードと通信するための 1 つ以上のソケット (ノードあたり 1 ソケット) を処理します。MySQL Cluster NDB 7.3 以降では、複数の受信スレッドがサポートされます。MySQL Cluster NDB 7.3.2 以前では、このようなスレッドの最大数は 8 です。MySQL Cluster NDB 7.3.3 以降では、最大は 16 です。

      範囲: (NDB 7.3.3 以降) 1-16、(NDB 7.3.2 以前) 1-8。

    • send: 送信スレッド (CMVMI カーネルブロック)。スループットを向上させるため、1 つ以上 (最大 8 個) の独立した専用スレッドから送信を実行できます。

      以前は、すべてのスレッドが自身の送信を直接処理していました。今でも、送信スレッドの数を 0 に設定することでこれを行うことができます (MaxNoOfExecutionThreads を 9 に設定した場合もこれが行われます)。これを行うと、スループットに悪影響を及ぼす可能性がありますが、場合によっては待機時間が減る可能性もあります。

      範囲: (NDB 7.3.3 以降) 0-16、(NDB 7.3.2 以前) 0-8。

    • rep: レプリケーションスレッド (SUMA カーネルブロック)。非同期のレプリケーション操作は、常に 1 つの専用スレッドで処理されます。

      範囲: 1 のみ。

    • io: ファイルシステムおよびその他の操作。これらは、要求の厳しいタスクではなく、常に 1 つの I/O 専用スレッドでまとめて処理されます。

      範囲: 1 のみ。

簡単な例:

# Example 1.
ThreadConfig=ldm={count=2,cpubind=1,2},main={cpubind=12},rep={cpubind=11}
# Example 2.
Threadconfig=main={cpubind=0},ldm={count=4,cpubind=1,2,5,6},io={cpubind=3}

通常、スレッドの使用法を構成するときは、データノードホストの 1 つ以上の CPU をオペレーティングシステムおよびその他のタスク用に確保します。したがって、24 個の CPU を搭載したホストマシンでは、20 個の CPU スレッド (8 個の LDM スレッド、4 個の TC スレッド (LDM スレッドの半分)、3 個の送信スレッド、3 個の受信スレッド、およびスキーマ管理、非同期レプリケーション、I/O 操作のそれぞれに 1 個のスレッド) を使用できます (ほかの用途のために 4 個を残します)。(これは、MaxNoOfExecutionThreads を 20 に設定したときに使用されるスレッドの分布とほぼ同じです。)次の ThreadConfig 設定では、これらの割り当てを行い、さらにこれらのスレッドを特定の CPU にバインドしています。

ThreadConfig=ldm{count=8,cpubind=1,2,3,4,5,6,7,8},main={cpubind=9},io={cpubind=9}, \
rep={cpubind=10},tc{count=4,cpubind=11,12,13,14},recv={count=3,cpubind=15,16,17}, \
send{count=3,cpubind=18,19,20}

ほとんどの場合、ここに示す例で行なったように、main (スキーマ管理) スレッドと I/O スレッドは同じ CPU にバインドできます。

ThreadConfig を使用することで得られる高い安定性を生かすには、CPU が隔離されていて、割り込みを受けたり、オペレーティングシステムによってほかのタスクをスケジュールされたりしない必要があります。多くの Linux システムでは、/etc/sysconfig/irqbalanceIRQBALANCE_BANNED_CPUS0xFFFFF0 に設定し、grub.confisolcpus ブートオプションを使用することで、これを実現できます。具体的な情報については、オペレーティングシステムまたはプラットフォームのドキュメントを参照してください。

ディスクデータの構成パラメータ  ディスクデータの動作に影響を与える構成パラメータには、次が含まれます。

  • DiskPageBufferMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト64M4M - 1TN

    これは、ディスク上のページをキャッシュするために使用されるスペースの量を指定するもので、config.ini ファイルの [ndbd] または [ndbd default] セクションで設定されます。これは、バイト単位で測定されます。各ページは最大 32K バイトを占有します。これは、常に N * 32K バイトのメモリーがクラスタディスクデータのストレージに使用されることを意味します (N は負でない整数です)。

    このパラメータのデフォルト値は 64M (32K バイトのページ 2000 個分) です。

    ndbinfo.diskpagebuffer テーブルをクエリーすると、不要なディスクシークを最小限に抑えるためにこのパラメータの値を増やすべきかどうか判定しやすくなります。詳細は、セクション18.5.10.12「ndbinfo diskpagebuffer テーブル」を参照してください。

  • SharedGlobalMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト128M0 - 64TN

    このパラメータは、テーブルスペース、ログファイルグループ、Undo ファイル、およびデータファイル用のログバッファー、ディスク操作 (ページ要求や待機キューなど)、およびメタデータに使用されるメモリーの量を指定します。この共有グローバルメモリープールから、CREATE LOGFILE GROUP および ALTER LOGFILE GROUP ステートメントで使用される INITIAL_SIZE および UNDO_BUFFER_SIZE オプション (InitialLogFileGroup データノード構成パラメータの設定によって示されるこれらのオプションのデフォルト値を含む) のメモリー要件を満たすために使用されるメモリーも提供されます。SharedGlobalMemory は、config.ini 構成ファイルの [ndbd] または [ndbd default] セクションに設定でき、バイト単位で測定されます。

    デフォルト値は 128M です。

  • DiskIOThreadPool

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0スレッド20 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、ディスクデータファイルへのアクセスに使用される未バインドスレッドの数を指定します。DiskIOThreadPool が導入される前は、ディスクデータファイルごとに 1 つのスレッドしか生成されなかったため、特に非常に大きいデータファイルを使用する場合に、パフォーマンスの問題が発生する可能性がありました。DiskIOThreadPool を使用すると、たとえば、並列で動作する複数のスレッドを使用して 1 つの大きなデータファイルにアクセスできます。

    このパラメータは、ディスクデータ I/O スレッドにのみ適用されます。

    このパラメータの最適な値は、使用しているハードウェアと構成によって異なり、次の要因を含みます。

    • ディスクデータファイルの物理的な分布  データファイル、Undo ログファイル、およびデータノードファイルシステムを別々の物理ディスクに配置することで、パフォーマンスを向上させることができます。これらの一部またはすべてのファイルを使用してこれを行う場合は、各ディスク上のファイルを別個のスレッドで処理できるようにするために、DiskIOThreadPool を大きな値に設定できます。

    • ディスクのパフォーマンスとタイプ  ディスクデータファイルの処理用に提供できるスレッドの数は、ディスクの速度とスループットにも依存します。ディスクの速度が速く、スループットが高いほど、より多くの I/O スレッドを使用できます。弊社のテスト結果では、従来のディスクよりソリッドステートディスクドライブの方が (つまり DiskIOThreadPool の値が大きいほど) はるかに多くのディスク I/O スレッドを処理できることを示しています。

    このパラメータのデフォルト値は 2 です。

  • ディスクデータのファイルシステムパラメータ  次のリストのパラメータを使用すると、シンボリックリンクを使用せずに MySQL Cluster ディスクデータのファイルを特定のディレクトリに配置できるようになります。

    • FileSystemPathDD

      有効なバージョン型/単位デフォルト範囲/値再起動タイプ
      NDB 7.3.0ファイル名[テキストを参照]...IN

      このパラメータを指定すると、MySQL Cluster ディスクデータのデータファイルと Undo ログファイルが指定されたディレクトリに配置されます。データファイル、Undo ログファイル、またはその両方をオーバーライドするには、FileSystemPathDataFilesFileSystemPathUndoFiles、またはその両方の値をこれらのパラメータの説明に従って指定します。データファイルでは CREATE TABLESPACE または ALTER TABLESPACE ステートメントの ADD DATAFILE 句にパスを指定し、Undo ログファイルでは CREATE LOGFILE GROUP または ALTER LOGFILE GROUP ステートメントの ADD UNDOFILE 句でパスを指定してオーバーライドすることもできます。FileSystemPathDD が指定されていない場合は、FileSystemPath が使用されます。

      特定のデータノードで FileSystemPathDD ディレクトリが指定された場合 (config.ini ファイルの [ndbd default] セクションでこのパラメータが指定された場合を含む)、--initial を指定してデータノードを起動すると、ディレクトリ内のすべてのファイルが削除されます。

    • FileSystemPathDataFiles

      有効なバージョン型/単位デフォルト範囲/値再起動タイプ
      NDB 7.3.0ファイル名[テキストを参照]...IN

      このパラメータを指定すると、MySQL Cluster ディスクデータのデータファイルが指定されたディレクトリに配置されます。これは、FileSystemPathDD に設定された値をオーバーライドします。特定のデータファイルのパラメータをオーバーライドするには、そのデータファイルを作成するために使用される CREATE TABLESPACE または ALTER TABLESPACE ステートメントの ADD DATAFILE 句でパスを指定します。FileSystemPathDataFiles が指定されていない場合は、FileSystemPathDD が使用されます (FileSystemPathDD も設定されていない場合は、FileSystemPath が使用されます)。

      特定のデータノードで FileSystemPathDataFiles ディレクトリが指定された場合 (config.ini ファイルの [ndbd default] セクションにこのパラメータが指定された場合を含む)、--initial を指定してそのデータノードを起動すると、ディレクトリ内のすべてのファイルが削除されます。

    • FileSystemPathUndoFiles

      有効なバージョン型/単位デフォルト範囲/値再起動タイプ
      NDB 7.3.0ファイル名[テキストを参照]...IN

      このパラメータを指定すると、MySQL Cluster ディスクデータの Undo ログファイルが指定されたディレクトリに配置されます。これは、FileSystemPathDD に設定された値をオーバーライドします。特定のデータファイルについてこのパラメータをオーバーライドするには、そのデータファイルを作成するために使用される CREATE LOGFILE GROUP または CREATE LOGFILE GROUP ステートメントの ADD UNDO 句にパスを指定します。FileSystemPathUndoFiles が指定されていない場合は、FileSystemPathDD が使用されます (FileSystemPathDD も設定されていない場合は、FileSystemPath が使用されます)。

      特定のデータノードで FileSystemPathUndoFiles ディレクトリが指定された場合 (config.ini ファイルの [ndbd default] セクションにこのパラメータが指定された場合を含む)、--initial を指定してそのデータノードを起動すると、ディレクトリ内のすべてのファイルが削除されます。

    詳細は、セクション18.5.12.1「MySQL Cluster ディスクデータオブジェクト」を参照してください。

  • ディスクデータのオブジェクト作成パラメータ  次の 2 つのパラメータを使用すると、クラスタを最初に起動したときに、SQL ステートメントを使用せずにディスクデータのログファイルグループ、テーブルスペース、またはその両方を作成できます。

    • InitialLogFileGroup

      有効なバージョン型/単位デフォルト範囲/値再起動タイプ
      NDB 7.3.0文字列[テキストを参照]...S

      このパラメータを使用して、クラスタの初期起動の実行時に作成されるログファイルグループを指定できます。InitialLogFileGroup は、ここに示すように指定されます。

      InitialLogFileGroup = [name=name;] [undo_buffer_size=size;] file-specification-listfile-specification-list: file-specification[; file-specification[; ...]]file-specification: filename:size

      ログファイルグループの name はオプションであり、デフォルト値は DEFAULT-LG です。undo_buffer_size もオプションです。省略した場合のデフォルト値は 64M です。file-specification は、それぞれ 1 つの Undo ログファイルに対応し、file-specification-list に少なくとも 1 つ指定する必要があります。Undo ログファイルは、FileSystemPathFileSystemPathDD、および FileSystemPathUndoFiles に設定された値に従って、CREATE LOGFILE GROUP または ALTER LOGFILE GROUP ステートメントの結果として作成された場合と同じように配置されます。

      次について考えます。

      InitialLogFileGroup = name=LG1; undo_buffer_size=128M; undo1.log:250M; undo2.log:150M

      これは、次の SQL ステートメントと同等です。

      CREATE LOGFILE GROUP LG1 ADD UNDOFILE 'undo1.log' INITIAL_SIZE 250M UNDO_BUFFER_SIZE 128M ENGINE NDBCLUSTER;
      ALTER LOGFILE GROUP LG1 ADD UNDOFILE 'undo2.log' INITIAL_SIZE 150M ENGINE NDBCLUSTER;

      このログファイルグループは、--initial を指定してデータノードを起動したときに作成されます。

      初期のログファイルグループのリソースは、SharedGlobalMemory データノード構成パラメータの値でサイズが決定されるグローバルメモリープールから取得されます。このパラメータの設定値が小さすぎて、ログファイルグループの初期サイズまたは Undo バッファーサイズとして InitialLogFileGroup に設定された値が大きすぎる場合は、クラスタの起動時にデフォルトのログファイルグループが作成されないか、クラスタの起動が完全に失敗する可能性があります。

      このパラメータを使用する場合は、常に config.ini ファイルの [ndbd default] セクションに設定するようにしてください。異なるデータノードに異なる値を設定した場合の MySQL Cluster の動作は定義されていません。

    • InitialTablespace

      有効なバージョン型/単位デフォルト範囲/値再起動タイプ
      NDB 7.3.0文字列[テキストを参照]...S

      このパラメータを使用して、クラスタの初期起動を実行したときに作成される MySQL Cluster ディスクデータのテーブルスペースを指定できます。InitialTablespace は、ここに示すように指定されます。

      InitialTablespace = [name=name;] [extent_size=size;] file-specification-list

      テーブルスペースの name はオプションであり、デフォルト値は DEFAULT-TS です。extent_size もオプションです。デフォルト値は 1M です。file-specification-list には、InitialLogfileGroup パラメータに示された同じ構文が使用されます。唯一の違いは、InitialTablespace で使用される file-specification がそれぞれ 1 つのデータファイルに対応することです。file-specification-list には、少なくとも 1 つを指定する必要があります。データファイルは、FileSystemPathFileSystemPathDD、および FileSystemPathDataFiles に設定された値に従って、CREATE TABLESPACE または ALTER TABLESPACE ステートメントの結果として作成された場合と同じように配置されます。

      たとえば、config.ini ファイルの [ndbd default] セクションに InitialTablespace を指定する次の行について考えます (InitialLogfileGroup と同様、異なるデータノードに異なる値を設定したときの MySQL Cluster の動作は定義されていないため、このパラメータは常に [ndbd default] セクションに設定するようにしてください)。

      InitialTablespace = name=TS1; extent_size=8M; data1.dat:2G; data2.dat:4G

      これは、次の SQL ステートメントと同等です。

      CREATE TABLESPACE TS1 ADD DATAFILE 'data1.dat' EXTENT_SIZE 8M INITIAL_SIZE 2G ENGINE NDBCLUSTER;
      ALTER TABLESPACE TS1 ADD DATAFILE 'data2.dat' INITIAL_SIZE 4G ENGINE NDBCLUSTER;

      このテーブルスペースは、--initial を指定してデータノードを起動したときに作成され、その後 MySQL Cluster ディスクデータのテーブルを作成するたびに使用できます。

ディスクデータと GCP 停止エラー ディスクデータテーブルを使用するときに発生するエラー:Node nodeid killed this node because GCP stop was detected(エラー 2303) などは、多くの場合、GCP 停止エラーと呼ばれています。このようなエラーは、Redo ログが十分な速さでディスクにフラッシュされていない場合に発生します。これは通常、ディスクの速度が低く、ディスクのスループットが十分でないことが原因です。

高速なディスクを使用し、ディスクデータファイルをデータノードファイルシステムとは別のディスクに配置することで、これらのエラーを回避しやすくなります。TimeBetweenGlobalCheckpoints の値を減らすと、グローバルチェックポイントごとに書き込まれるデータの量が減りやすくなるため、グローバルチェックポイントを書き込もうとしたときに Redo ログバッファーのオーバーフローをある程度回避できる可能性があります。ただし、この値を減らすと GCP を書き込むことができる時間も減るため、注意が必要です。

前述の DiskPageBufferMemory について示した考慮事項に加えて、DiskIOThreadPool 構成パラメータを正しく設定することも非常に重要です。DiskIOThreadPool の設定値が大きすぎると、GCP 停止エラーが発生する可能性が非常に高くなります (Bug #37227)。

GCP の停止は、保存またはコミットのタイムアウトによって発生することがあります。TimeBetweenEpochsTimeout データノード構成パラメータは、コミットのタイムアウトを指定します。ただし、このパラメータを 0 に設定することで、両方のタイプのタイムアウトを無効にできます。

送信バッファーメモリーの割り当てを構成するためのパラメータ  送信バッファーメモリーは、すべてのトランスポータ間で共有されるメモリープールから動的に割り当てられます。これは、送信バッファーのサイズを必要に応じて調整できることを意味します。(以前は、クラスタ内のすべてのノードで NDB カーネルが固定サイズの送信バッファーを使用していました。これは、ノードの起動時に割り当てられ、ノードの実行中は変更できませんでした。)TotalSendBufferMemory および OverLoadLimit データノード構成パラメータを使用して、このメモリー割り当ての制限を設定できます。これらのパラメータ (および SendBufferMemory) の使用方法の詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

  • ExtraSendBufferMemory

    このパラメータは、TotalSendBufferMemorySendBufferMemory、またはその両方を使用して設定されたメモリーに加えて割り当てられるトランスポータ送信バッファーメモリーの量を指定します。

  • TotalSendBufferMemory

    このパラメータは、MySQL Cluster NDB 6.4.0 以降で使用可能です。これは、すべての構成済みトランスポータ間で共有される送信バッファーメモリーの、このノード上で割り当てられるメモリーの合計量を指定するために使用されます。

    このパラメータを設定する場合、許容される最小値は 256K バイト、最大値は 4294967039 です。

  • ReservedSendBufferMemory

    このパラメータは、MySQL Cluster NDB 6.4.0 以降の NDBCLUSTER のソースコード内にあります。しかし、現在は有効になっていません。

    このパラメータは MySQL Cluster NDB 7.2 で非推奨になり、MySQL Cluster の今後のバージョンで削除される予定です (Bug #11760629、Bug #53053)。

TotalSendBufferMemory の動作と使用、 および MySQL Cluster での送信バッファーメモリーパラメータの構成の詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

セクション18.5.13「MySQL Cluster データノードのオンライン追加」も参照してください。

Redo ログのオーバーコミット処理  Redo ログをディスクにフラッシュする時間が長すぎる場合の、データノードによる操作の処理を制御できます。これは、特定の Redo ログのフラッシュが RedoOverCommitLimit 秒より長い時間をかけて RedoOverCommitCounter 回を超える回数分行われ、保留中のトランザクションが中止されたときに発生します。これが発生すると、トランザクションを送信した API ノードは、コミットされるはずだった操作を (DefaultOperationRedoProblemAction の指定に従って) キューに配置して再試行するか、中止することで処理できます。API ノードでこのアクションが実行される前に超過が許されるタイムアウトと回数を設定するためのデータノード構成パラメータについて、次のリストで説明します。

  • RedoOverCommitCounter

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値30 - 4294967039 (0xFFFFFEFF)N

    特定の Redo ログをディスクに書き込もうとしたときに RedoOverCommitLimit を超過した回数がこの回数を超えると、結果としてコミットされなかったトランザクションはすべて中止され、トランザクションの発生元である API ノードは、これらのトランザクションを構成する操作を DefaultOperationRedoProblemAction の値に従って (操作をキューに入れて再試行するか、中止して) 処理します。

    RedoOverCommitCounter のデフォルト値は 3 です。0 に設定すると、この制限は無効になります。

  • RedoOverCommitLimit

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0200 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、特定の Redo ログをディスクに書き込もうとしたときにタイムアウトするまでの上限 (秒単位) を設定します。データノードがこの Redo ログをフラッシュしようとして RedoOverCommitLimit よりも長い時間がかかった回数が保存され、RedoOverCommitCounter と比較されます。フラッシュにかかる時間が長すぎた回数がこのパラメータの値より多くなったときは、フラッシュタイムアウトの結果としてコミットされなかったトランザクションがすべて中止されます。これが発生すると、トランザクションの発生元である API ノードは、これらのトランザクションを構成する操作を DefaultOperationRedoProblemAction の設定に従って (操作をキューに入れて再試行するか、中止することで) 処理します。

    デフォルトでは、RedoOverCommitLimit は 20 秒です。0 に設定すると、Redo ログのフラッシュタイムアウトのチェックが無効になります。このパラメータは MySQL Cluster NDB 7.1.10 で追加されました。

再起動試行の制御 MaxStartFailRetries および StartFailRetryDelay データノード構成パラメータを使用すると、データノードによる起動失敗時の再起動試行を細かく制御できます。

MaxStartFailRetries は、データノードの起動を中止するまでに行われる再試行の合計数を制限します。StartFailRetryDelay は、再試行間の秒数を設定します。これらのパラメータをここに示します。

  • StartFailRetryDelay

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし00 - 4294967039 (0xFFFFFEFF)N

    このパラメータを使用して、データノードによる起動失敗時の再試行間の秒数を設定します。デフォルトは 0 (遅延なし) です。

    StopOnError が 0 でない場合は、このパラメータと MaxStartFailRetries の両方が無視されます。

  • MaxStartFailRetries

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし30 - 4294967039 (0xFFFFFEFF)N

    このパラメータを使用して、データノードによる起動失敗時の再試行回数を制限します。デフォルトは 3 回です。

    StopOnError が 0 でない場合は、このパラメータと StartFailRetryDelay の両方が無視されます。

NDB インデックス統計のパラメータ 次のリストのパラメータは、MySQL Cluster NDB 7.2.1 で導入された NDB インデックス統計の生成に関連しています。

  • IndexStatAutoCreate

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsefalse、trueS

    インデックスが作成されたときの自動統計収集を有効または無効にします。デフォルトで無効になっています。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatAutoUpdate

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsefalse、trueS

    インデックス変更のモニタリングを有効または無効にし、変更が検出される自動統計更新をトリガーします。更新をトリガーするために必要な変更の量およびレベルは、IndexStatTriggerPct および IndexStatTriggerScale オプションの設定によって決定されます。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatSaveSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト327680 - 4294967039 (0xFFFFFEFF)IN

    NDB システムテーブルおよび mysqld メモリーキャッシュに保存される特定のインデックスの統計に対して許容される最大スペース (バイト単位)。これは、IndexMemory を消費します。

    サイズ制限に関係なく、常に少なくとも 1 つのサンプルが生成されます。このサイズは、IndexStatSaveScale によって調整されます。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

    大規模なインデックスでは、IndexStatSaveSize に指定されたサイズが IndexStatTriggerPct に 0.01 を掛けた値によって調整されます。これは、さらにインデックスサイズの底 2 の対数で乗算されます。IndexStatTriggerPct を 0 に設定すると、この調整が無効になります。

  • IndexStatSaveScale

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0パーセンテージ1000 - 4294967039 (0xFFFFFEFF)IN

    大規模なインデックスでは、IndexStatSaveSize に指定されたサイズが IndexStatTriggerPct に 0.01 を掛けた値によって調整されます。これは、さらにインデックスサイズの底 2 の対数で乗算されます。IndexStatTriggerPct を 0 に設定すると、この調整が無効になります。

  • IndexStatTriggerPct

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0パーセンテージ1000 - 4294967039 (0xFFFFFEFF)IN

    インデックス統計更新をトリガーする更新内の変更割合。この値は、IndexStatTriggerScale によって調整されます。このトリガーを完全に無効にするには、IndexStatTriggerPct を 0 に設定します。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatTriggerScale

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0パーセンテージ1000 - 4294967039 (0xFFFFFEFF)IN

    大規模なインデックスでは、この量に 0.01 を掛けた値で IndexStatTriggerPct を調整します。値 0 で調整が無効になります。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatUpdateDelay

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0600 - 4294967039 (0xFFFFFEFF)IN

    特定のインデックスの自動インデックス統計更新間の最小遅延 (秒数)。この変数を 0 に設定すると、遅延が無効になります。デフォルトは 60 秒です。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

18.3.2.7 MySQL Cluster 内の SQL ノードおよびその他の API ノードの定義

config.ini ファイルの [mysqld] および [api] セクションでは、クラスタデータへのアクセスに使用される MySQL サーバー (SQL ノード) およびその他のアプリケーション (API ノード) が定義されます。示されているどのパラメータも必須ではありません。コンピュータ名またはホスト名が指定されていない場合は、任意のホストでこの SQL または API ノードを使用できます。

一般的には、[mysqld] セクションはクラスタへの SQL インタフェースを提供する MySQL サーバーを示すために使用され、[api] セクションはクラスタデータにアクセスする mysqld プロセス以外のアプリケーションのために使用されますが、この 2 つの指定は実際には同義です。たとえば、SQL ノードとして機能する MySQL サーバーのパラメータを [api] セクションに指定できます。

注記

MySQL Cluster 用の MySQL サーバーオプションについては、セクション18.3.4.2「MySQL Cluster 用の MySQL Server オプション」を参照してください。MySQL Cluster に関連する MySQL サーバーシステム変数については、セクション18.3.4.3「MySQL Cluster のシステム変数」を参照してください。

  • Id

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]1 - 255IS

    Id は、すべてのクラスタ内部メッセージ内でノードを識別するために使用される整数値です。許容される値の範囲は、1-255 (これらを含む) です。この値は、ノードのタイプに関係なく、クラスタ内の各ノードで一意である必要があります。

    注記

    データノード ID は、使用する MySQL Cluster のバージョンに関係なく、49 未満である必要があります。多数のデータノードを配備する予定の場合は、API ノード (および管理ノード) のノード ID を 48 より大きい値に制限することをお勧めします。

    NodeId は、API ノードを識別するときに使用することが推奨されるパラメータ名です。(Id は、下位互換性に引き続き対応しますが、現在は非推奨であり、使用時に警告を生成します。また、これは今後削除される予定です。)

  • ConnectionMap

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0文字列[none]...N

    接続するデータノードを指定します。

  • NodeId

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]1 - 255IS

    NodeId は、すべてのクラスタ内部メッセージ内でノードを識別するために使用される整数値です。許容される値の範囲は、1-255 (これらを含む) です。この値は、ノードのタイプに関係なく、クラスタ内の各ノードで一意である必要があります。

    注記

    データノード ID は、使用する MySQL Cluster のバージョンに関係なく、49 未満である必要があります。多数のデータノードを配備する予定の場合は、API ノード (および管理ノード) のノード ID を 48 より大きい値に制限することをお勧めします。

    NodeId は、管理ノードを識別するときに使用することが推奨されるパラメータ名です。MySQL Cluster の非常に古いバージョンでは、この目的のためにエイリアス (Id) が使用されていました。これは、下位互換性に引き続き対応していますが、現在は非推奨であり、使用時に警告を生成します。また、MySQL Cluster の今後のリリースで削除される予定です。

  • ExecuteOnComputer

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0name[none]...S

    これは、構成ファイルの [computer] セクションに定義されたいずれかのコンピュータ (ホスト) に設定されている Id を参照します。

  • HostName

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    このパラメータを指定すると、SQL ノード (API ノード) が配置されるコンピュータのホスト名が定義されます。ホスト名を指定するには、このパラメータまたは ExecuteOnComputer のいずれかが必要です。

    config.ini ファイルの特定の [mysql] または [api] セクションに HostName または ExecuteOnComputer が指定されていない場合、SQL または API ノードはネットワーク接続を確立できる任意のホストから対応するスロットを使用して管理サーバーホストマシンに接続できます。これは、ほかに指定されていない場合 localhostHostName として使用されるデータノードのデフォルトの動作とは異なります

  • ArbitrationRank

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.00-200 - 2N

    このパラメータは、アービトレータとして機能できるノードを定義します。管理ノードと SQL ノードの両方がアービトレータになることができます。値 0 は、指定されたノードがアービトレータとして使用されないことを意味します。値 1 は、ノードにアービトレータとしての高い優先度を与えます。値 2 は低い優先度を与えます。通常の構成では、管理サーバーの ArbitrationRank が 1 (管理ノードのデフォルト) に設定され、各 SQL ノードでは 0 (SQL ノードのデフォルト) に設定されるため、管理サーバーがアービトレータとして使用されます。

    すべての管理および SQL ノードで ArbitrationRank を 0 に設定すると、アービトレーションを完全に無効化できます。このパラメーラをオーバーライドしてアービトレーションを制御することもできます。そのためには、config.ini グローバル構成ファイルの [ndbd default] セクションに Arbitration パラメータを設定します。

  • ArbitrationDelay

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ミリ秒00 - 4294967039 (0xFFFFFEFF)N

    このパラメータを 0 (デフォルト) 以外の値に設定すると、アービトレーション要求に対するアービトレータの応答が指定されたミリ秒数だけ遅延します。通常、この値を変更する必要はありません。

  • BatchByteSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト16K1024 - 1MN

    フルテーブルスキャンまたはインデックスの範囲スキャンに変換されるクエリーでは、最良のパフォーマンスを得るため、適切にサイズ調整されたバッチでレコードをフェッチすることが重要です。レコード数 (BatchSize) とバイト数 (BatchByteSize) の両方で、適切なサイズを設定できます。実際のバッチサイズは両方のパラメータによって制限されます。

    このパラメータの設定方法によっては、クエリーの実行速度の変化率が 40% を超える可能性があります。

    このパラメータはバイト単位で測定されます。MySQL Cluster NDB 7.3 以降では、デフォルト値は 16K です。

  • BatchSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0レコード2561 - 992N

    このパラメータはレコード数で測定され、デフォルトで 256 に設定されます。最大サイズは 992 です。

  • ExtraSendBufferMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト00 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、TotalSendBufferMemorySendBufferMemory、またはその両方を使用して設定されたメモリーに加えて割り当てられるトランスポータ送信バッファーメモリーの量を指定します。

  • HeartbeatThreadPriority

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0文字列[none]...S

    このパラメータを使用して、管理および API ノードのハートビートスレッドのスケジューリングポリシーと優先度を設定します。このパラメータを設定するための構文をここに示します。

    HeartbeatThreadPriority = policy[, priority]policy: {FIFO | RR}

    このパラメータを設定するときは、ポリシーを指定する必要があります。これは、FIFO (先入れ先出し) または RR (ラウンドロビン) のいずれかです。このあとに、オプションで優先度 (整数) を指定できます。

  • MaxScanBatchSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト256K32K - 16MN

    バッチサイズは、各データノードから送信される各バッチのサイズです。多数のノードから並列で受信される過大なデータ量から MySQL サーバーを保護するため、ほとんどのスキャンは並列で実行されます。このパラメータは、すべてのノードの合計バッチサイズに対する制限を設定します。

    このパラメータのデフォルトの値は 256K バイトです。最大サイズは 16M バイトです。

  • TotalSendBufferMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト256K0 - 4294967039 (0xFFFFFEFF)N

    このパラメータは、すべての構成済みトランスポータ間で共有される送信バッファーメモリーの、このノードに割り当てられるメモリー合計量を決定するために使用されます。

    このパラメータを設定する場合、許容される最小値は 256K バイト、最大値は 4294967039 です。TotalSendBufferMemory の動作と使用、および MySQL Cluster での送信バッファーメモリーパラメータの構成の詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

  • AutoReconnect

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    このパラメータは、デフォルトで false です。これによって、切断された API ノード (SQL ノードとして機能する MySQL サーバーを含む) が既存の接続を再使用しようとせずに、クラスタへの新しい接続を強制的に使用するようになります (接続を再使用すると、動的に割り当てられたノード ID を使用するときに問題が発生することがあるため)。(Bug #45921)

    注記

    このパラメータは、NDB API を使用してオーバーライドできます。詳細は、Ndb_cluster_connection::set_auto_reconnect() および Ndb_cluster_connection::get_auto_reconnect() を参照してください。

  • DefaultOperationRedoProblemAction

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0列挙QUEUEABORT、QUEUES

    このパラメータは、(RedoOverCommitLimit および RedoOverCommitCounter とともに) Redo ログをディスクにフラッシュする時間が長すぎる場合にデータノードによる操作の処理を制御します。これは、特定の Redo ログのフラッシュが RedoOverCommitLimit 秒より長い時間をかけて RedoOverCommitCounter 回を超える回数分行われ、保留中のトランザクションが中止されたときに発生します。

    この発生時は、ノードはここに示す DefaultOperationRedoProblemAction の値に応じた 2 つの方法のいずれかで応答できます。

    • ABORT: 中止されたトランザクションに含まれる保留中の操作も中止されます。

    • QUEUE: 中止されたトランザクションに含まれる保留中の操作がキューに入れられ、再試行されます。

  • DefaultHashMapSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0LDM スレッド38400 - 3840N

    MySQL Cluster NDB 7.2.7 以降では、前のリリース (240) より大きなテーブルハッシュマップのデフォルトサイズ (3840) が使用されます。MySQL Cluster NDB 7.2.11 以降では、このパラメータを使用して NDB が使用するテーブルハッシュマップのサイズを構成できます (以前は、この値はハードコーディングされていました)。DefaultHashMapSize には、3 つの値 (0、240、3840) のいずれかを指定できます。これらの値とその効果について、次の表で説明します。

    説明/効果
    0クラスタ内のすべてのデータおよび API ノードの中で、このパラメータに設定されたもっとも小さい値を (あれば) 使用します。どのデータまたは API ノードにも設定されていない場合は、デフォルト値を使用します。
    240MySQL Cluster NDB 7.2.7 より前のすべての MySQL Cluster リリースでデフォルトで使用されていた元のハッシュマップサイズです。
    3840MySQL Cluster NDB 7.2.7 以降でデフォルトで使用される、より大きなハッシュマップサイズ

    このパラメータの主な用途は、より大きなハッシュマップサイズ (3840) がデフォルトである MySQL Cluster NDB 7.2.7 以降の MySQL Cluster バージョンと以前のリリース (デフォルトが 240 だった) との間のアップグレードと (特に) ダウングレードを容易にすることです。これは、この変更に下位互換性がない (Bug #14800539) ためです。このパラメータを 240 に設定してから、この値を使用している古いバージョンからのアップグレードを実行すると、クラスタはテーブルハッシュマップに対して引き続き小さいサイズを使用するため、アップグレード後のテーブルでも前のバージョンとの互換性が維持されます。DefaultHashMapSize は個々のデータノード、API ノード、またはその両方で設定できますが、config.ini ファイルの [ndbd default] セクションに一度だけ設定する方法をお勧めします。

    このパラメータを増やしたあと、既存のテーブルで新しいサイズを利用するには、そのテーブルに対して ALTER TABLE ... REORGANIZE PARTITION を実行します。その後、そのテーブルでより大きなハッシュマップサイズを使用できるようになります。これは、ローリング再起動の実行に加えて行います。ローリング再起動を実行すると、より大きなハッシュマップを新しいテーブルで使用できるようになりますが、既存のテーブルでは使用できません。

    DefaultHashMapSize を 3840 に設定してテーブルを作成または変更したあと、オンラインでこのパラメータを減らす方法は、現在サポートされていません。

  • Wan

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    WAN の TCP 設定をデフォルトとして使用します。

  • ConnectBackoffMaxTime

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数00 - 4294967039 (0xFFFFFEFF)N

    MySQL Cluster NDB 7.3.7 および MySQL Cluster NDB 7.4.2 以降では、MySQL Cluster 内に起動されていないデータノードが多数ある場合に、このパラメータの値を増やし、クラスタ内のまだ機能し始めていないデータノードへの接続試行を回避して、管理ノードへの大量のトラフィックを抑えることができます。API ノードが新しいデータノードに接続されていない場合は、StartConnectBackoffMaxTime パラメータの値が適用されます。それ以外の場合は、ConnectBackoffMaxTime を使用して接続試行間の待機時間の長さ (ミリ秒) が決定されます。

    このパラメータの経過時間を計算する際に、ノードの接続試行に経過する時間は考慮されません。タイムアウトは、100 ミリ秒の遅延から始まり、約 100 ミリ秒の分解能で適用されます。後続の試行のたびに、ConnectBackoffMaxTime ミリ秒 (最大 100000 ミリ秒 (100 秒)) に達するまでこの期間の長さが倍加されます。

    API ノードがデータノードに接続され、そのノードが (ハートビートメッセージで) ほかのデータノードに接続したことを報告すると、データノードに対する接続試行はこのパラメータの影響を受けなくなり、その後接続されるまで 100 ミリ秒間隔で行われます。データノードが起動すると、これが発生したことが API ノードに通知されるまでに HeartbeatIntervalDbApi を要します。

  • StartConnectBackoffMaxTime

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0整数15000 - 4294967039 (0xFFFFFEFF)N

    MySQL Cluster NDB 7.3.7 および MySQL Cluster NDB 7.4.2 以降では、MySQL Cluster 内に起動されていないデータノードが多数ある場合に、このパラメータの値を増やし、クラスタ内のまだ機能し始めていないデータノードへの接続試行を回避して、管理ノードへの大量のトラフィックを抑えることができます。API ノードが新しいデータノードに接続されていない場合は、StartConnectBackoffMaxTime パラメータの値が適用されます。それ以外の場合は、ConnectBackoffMaxTime を使用して接続試行間の待機時間の長さ (ミリ秒) が決定されます。

    このパラメータの経過時間を計算する際に、ノードの接続試行に経過する時間は考慮されません。タイムアウトは、100 ミリ秒の遅延から始まり、約 100 ミリ秒の分解能で適用されます。後続の試行のたびに、StartConnectBackoffMaxTime ミリ秒 (最大 100000 ミリ秒 (100 秒)) に達するまでこの期間の長さが倍加されます。

    API ノードがデータノードに接続され、そのノードが (ハートビートメッセージで) ほかのデータノードに接続したことを報告すると、データノードに対する接続試行はこのパラメータの影響を受けなくなり、その後接続されるまで 100 ミリ秒間隔で行われます。データノードが起動すると、これが発生したことが API ノードに通知されるまでに HeartbeatIntervalDbApi を要します。

ここに示すように、mysql クライアントの SHOW STATUS を使用して、MySQL Cluster SQL ノードとして実行されている MySQL サーバーから情報を取得することもできます。

mysql> SHOW STATUS LIKE 'ndb%';+-----------------------------+---------------+
| Variable_name | Value |
+-----------------------------+---------------+
| Ndb_cluster_node_id | 5 |
| Ndb_config_from_host | 192.168.0.112 |
| Ndb_config_from_port | 1186 |
| Ndb_number_of_storage_nodes | 4 |
+-----------------------------+---------------+
4 rows in set (0.02 sec)

このステートメントの出力に表示されるステータス変数については、セクション18.3.4.4「MySQL Cluster のステータス変数」を参照してください。

注記

実行中の MySQL Cluster の構成に新しい SQL または API ノードを追加するには、config.ini ファイル (複数の管理サーバーを使用する場合は複数のファイル) に新しい [mysqld] または [api] セクションを追加したあとで、すべてのクラスタノードのローリング再起動を実行する必要があります。これは、新しい SQL または API ノードをクラスタに接続する前に実行する必要があります。

新しい SQL または API ノードがクラスタ構成内の以前に使用されていない API スロットを使用してクラスタに接続する場合、クラスタの再起動を実行する必要はありません

18.3.2.8 MySQL クラスタの TCP/IP 接続

TCP/IP は、MySQL Cluster に含まれるノード間のすべての接続で使用されるデフォルトのトランスポートメカニズムです。通常、TCP/IP 接続を定義する必要はありません。MySQL Cluster は、すべてのデータノード、管理ノード、および SQL または API ノードに対してそのような接続を自動的に設定します。

注記

このルールの例外については、セクション18.3.2.9「直接接続を使用する MySQL Cluster の TCP/IP 接続」を参照してください。

デフォルトの接続パラメータをオーバーライドするには、config.ini ファイルで 1 つ以上の [tcp] セクションを使用して接続を定義する必要があります。各 [tcp] セクションは、2 つの MySQL Cluster クラスタノード間の TCP/IP 接続を定義します。これには、最低でも NodeId1 および NodeId2 パラメータと、オーバーライドする接続パラメータを含める必要があります。

これらのパラメータのデフォルト値を [tcp default] セクションに設定して変更することもできます。

重要

config.ini ファイル内の [tcp] セクションは、最後に (ファイル内のほかのすべてのセクションのあとで) 指定するようにしてください。ただし、[tcp default] セクションについては、これは必須ではありません。この要件は、MySQL Cluster 管理サーバーが config.ini ファイルを読み取る方法に関する既知の問題です。

config.ini ファイルの [tcp] および [tcp default] セクションに設定できる接続パラメータをここに示します。

  • NodeId1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値[none]...N

    2 つのノード間の接続を識別するには、構成ファイルの [tcp] セクションに NodeId1 および NodeId2 の値としてノード ID を指定する必要があります。これらは、各ノードに対する一意の Id 値であり、セクション18.3.2.7「MySQL Cluster 内の SQL ノードおよびその他の API ノードの定義」で説明しているものと同じです。

  • NodeId2

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値[none]...N

    2 つのノード間の接続を識別するには、構成ファイルの [tcp] セクションに NodeId1 および NodeId2 の値としてノード ID を指定する必要があります。これらは、各ノードに対する一意の Id 値であり、セクション18.3.2.7「MySQL Cluster 内の SQL ノードおよびその他の API ノードの定義」で説明しているものと同じです。

  • HostName1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    HostName1 および HostName2 パラメータを使用すると、2 つのノード間の特定の TCP 接続で使用する特定のネットワークインタフェースを指定できます。これらのパラメータに使用する値は、ホスト名または IP アドレスです。

  • HostName2

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    HostName1 および HostName2 パラメータを使用すると、2 つのノード間の特定の TCP 接続で使用する特定のネットワークインタフェースを指定できます。これらのパラメータに使用する値は、ホスト名または IP アドレスです。

  • OverloadLimit

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト00 - 4294967039 (0xFFFFFEFF)N

    送信バッファーにこれより多くの未送信バイトがあるときは、接続が過負荷状態であるとみなされます。

    このパラメータを使用すると、接続を過負荷状態であるとみなす前に送信バッファーに存在する未送信データ量を決定できます。詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

  • SendBufferMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし2M256K - 4294967039 (0xFFFFFEFF)N

    TCP トランスポータは、オペレーティングシステムに対する送信呼び出しを実行する前に、バッファーを使用してすべてのメッセージを格納します。このバッファーが 64K バイトに達すると、その内容が送信されます。これは、一連のメッセージが実行されたときにも送信されます。一時的な過負荷状態に対応するため、より大きな送信バッファーを定義することもできます。

    このパラメータが明示的に設定されている場合は、メモリーが各トランスポータ専用でなくなります。代わりに、使用された値によって、(使用可能なメモリーの合計、つまり TotalSendBufferMemory のうち) 単一のトランスポータが使用できるメモリー量に関する厳密な制限が示されます。MySQL Cluster でトランスポータ送信バッファーメモリーの動的割り当てを構成する方法の詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

    送信バッファーのデフォルトサイズは 2M バイトです。これは、ほとんどの状況で推奨されるサイズです。最小サイズは 64K バイトです。理論的な最大は 4G バイトです。

  • SendSignalId

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブール[テキストを参照]true、falseN

    配信されたメッセージデータグラムを再トレースできるようにするには、各メッセージを識別する必要があります。このパラメータを Y に設定すると、メッセージ ID がネットワーク経由で転送されます。この機能は、製品ビルドではデフォルトで無効になっており、-debug ビルドで有効になります。

  • Checksum

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    このパラメータはブールパラメータです (Y または 1 に設定すると有効になり、N または 0 に設定すると無効になります)。デフォルトでは無効になっています。有効にすると、送信バッファーに配置される前にすべてのメッセージのチェックサムが計算されます。この機能によって、メッセージが送信バッファーでの待機中に (またはトランスポートメカニズムによって) 破損していないことが確認されます。

  • PortNumber (廃止)

    以前は、ほかのノードからの接続を待機するために使用するポート番号をこれで指定していました。このパラメータは今後使用しないようにしてください。代わりに ServerPort データノード構成パラメータを使用します。

  • ReceiveBufferMemory

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト2M16K - 4294967039 (0xFFFFFEFF)N

    TCP/IP ソケットからデータを受信するときに使用するバッファーのサイズを指定します。

    このパラメータのデフォルト値は 2M バイトです。指定可能な最小値は 16K バイトです。理論的な最大は 4G バイトです。

  • TCP_RCV_BUF_SIZE

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし700801 - 2GN
    NDB 7.3.1符号なし00 - 2GN

    TCP トランスポータの初期化時に設定される受信バッファーのサイズを指定します。MySQL Cluster NDB 7.3.1 より前では、デフォルトは 70080、最小は 1 でした。MySQL Cluster NDB 7.3.1 以降では、デフォルトおよび最小値は 0 です。その場合は、オペレーティングシステムまたはプラットフォームによってこの値が設定されます。ほとんどの一般的な使用ケースでは、デフォルトが推奨されます。

  • TCP_SND_BUF_SIZE

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし715401 - 2GN
    NDB 7.3.1符号なし00 - 2GN

    TCP トランスポータの初期化時に設定される送信バッファーのサイズを指定します。MySQL Cluster NDB 7.3.1 より前では、デフォルトは 71540、最小は 1 でした。MySQL Cluster NDB 7.3.1 以降では、デフォルトおよび最小値は 0 です。その場合は、オペレーティングシステムまたはプラットフォームによってこの値が設定されます。ほとんどの一般的な使用ケースでは、デフォルトが推奨されます。

  • TCP_MAXSEG_SIZE

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし00 - 2GN

    TCP トランスポータの初期化時に設定されるメモリーのサイズを決定します。ほとんどの一般的な使用ケースでは、デフォルトが推奨されます。

  • TcpBind_INADDR_ANY

    このパラメータを TRUE または 1 に設定すると、IP_ADDR_ANY がバインドされ、任意の場所から接続できるようになります (自動生成接続の場合)。デフォルトは FALSE (0) です。

18.3.2.9 直接接続を使用する MySQL Cluster の TCP/IP 接続

データノード間の直接接続を使用するクラスタをセットアップするには、クラスタの config.ini ファイルの [tcp] セクションに、そのように接続されるデータノードのクロスオーバー IP アドレスを明示的に指定する必要があります。

次の例では、少なくとも 4 台 (管理サーバー、SQL ノード、および 2 つのデータノード用に 1 台ずつ) のホストを含むクラスタについて考えます。クラスタ全体が LAN の 172.23.72.* サブネットに配置されています。次に示すように、通常のネットワーク接続に加えて、2 つのデータノードが標準のクロスオーバーケーブルにより直接接続されており、1.1.0.* アドレス範囲内の IP アドレスを使用して相互に直接通信します。

# Management Server
[ndb_mgmd]
Id=1
HostName=172.23.72.20
# SQL Node
[mysqld]
Id=2
HostName=172.23.72.21
# Data Nodes
[ndbd]
Id=3
HostName=172.23.72.22
[ndbd]
Id=4
HostName=172.23.72.23
# TCP/IP Connections
[tcp]
NodeId1=3
NodeId2=4
HostName1=1.1.0.1
HostName2=1.1.0.2

HostName1 および HostName2 パラメータは、直接接続を指定するときにのみ使用されます。

データノード間の直接 TCP 接続を使用すると、データノードがスイッチ、ハブ、ルーターなどの Ethernet デバイスをバイパスできるようになり、クラスタの待機時間が減るため、クラスタ全体の効率が向上する可能性があります。3 つ以上のデータノードでこのような直接接続を最大限に活用するには、各データノードと同じノードグループ内のほかのすべてのデータノート間で直接接続を行う必要があります。

18.3.2.10 MySQL Cluster の共有メモリー接続

MySQL Cluster は、共有メモリートランスポータを使用し、可能な場合は自動的にそれを構成しようとします。config.ini ファイルの [shm] セクションでは、クラスタ内のノード間の共有メモリー接続を明示的に定義します。共有メモリーを接続方法として明示的に定義するときは、少なくとも NodeId1NodeId2、および ShmKey を定義する必要があります。ほかのすべてのパラメータには、ほとんどのケースで適切に機能するデフォルト値があります。

重要

SHM 機能は、あくまでも実験的なものとみなされます。これは現在のどの MySQL Cluster リリースでも公式にサポートされておらず、テスト結果から、トランスポータに TCP/IP を使用した場合に比べて SHM のパフォーマンスが明らかに優れているとは言えません。

これらの理由により、特定のケースで SHM が正しく機能するようになるかどうかは、ユーザー自身で、または無償のリソース (フォーラム、メーリングリスト) を使用して判定する必要があります。

  • NodeId1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値[none]...N

    2 つのノード間の接続を識別するには、各ノードのノード識別子を NodeId1 および NodeId2 として指定する必要があります。

  • NodeId2

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値[none]...N

    2 つのノード間の接続を識別するには、各ノードのノード識別子を NodeId1 および NodeId2 として指定する必要があります。

  • HostName1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    HostName1 および HostName2 パラメータを使用すると、2 つのノード間の特定の SHM 接続で使用する特定のネットワークインタフェースを指定できます。これらのパラメータに使用する値は、ホスト名または IP アドレスです。

  • HostName2

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    HostName1 および HostName2 パラメータを使用すると、2 つのノード間の特定の SHM 接続で使用する特定のネットワークインタフェースを指定できます。これらのパラメータに使用する値は、ホスト名または IP アドレスです。

  • OverloadLimit

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト00 - 4294967039 (0xFFFFFEFF)N

    送信バッファーにこれより多くの未送信バイトがあるときは、接続が過負荷状態であるとみなされます。

    このパラメータを使用すると、接続を過負荷状態であるとみなす前に送信バッファーに存在する未送信データ量を決定できます。詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

  • ShmKey

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]0 - 4294967039 (0xFFFFFEFF)N

    共有メモリーセグメントを設定するときは、整数で表されるノード ID を使用して、通信に使用する共有メモリーセグメントを一意に識別します。デフォルト値はありません。

  • ShmSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト1M64K - 4294967039 (0xFFFFFEFF)N

    各 SHM 接続には、送信側と読み取り側でノード間のメッセージを配置する共有メモリーセグメントがあります。このセグメントのサイズは ShmSize で定義されます。デフォルト値は 1M バイトです。

  • SendSignalId

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    配信されたメッセージの経路をたどるには、各メッセージに一意の識別子を設定する必要があります。このパラメータを Y に設定すると、メッセージ ID もネットワーク経由で転送されるようになります。この機能は、製品ビルドではデフォルトで無効になっており、-debug ビルドで有効になります。

  • Checksum

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールtruetrue、falseN

    このパラメータはブール (Y/N) パラメータであり、デフォルトで無効になっています。有効にすると、送信バッファーに配置される前にすべてのメッセージのチェックサムが計算されます。

    この機能によって、送信バッファーで待機中のメッセージの破損が回避されます。これは、トランスポート時のデータ破損に対するチェックとしても機能します。

  • SigNum

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]0 - 4294967039 (0xFFFFFEFF)N

    共有メモリートランスポータを使用すると、共有メモリー内に使用可能な新しいデータが発生したときに、プロセスからもう一方のプロセスにオペレーティングシステムシグナルが送信されます。そのシグナルが既存のシグナルと競合する場合は、このパラメータを使用して変更できます。これは、SHM の使用時に、異なるオペレーティングシステムで異なるシグナル番号が使用されるために発生する可能性があります。

    SigNum のデフォルト値は 0 です。したがって、共有メモリートランスポータの使用時にクラスタログ内のエラーを回避するために、これを設定する必要があります。通常、このパラメータは config.ini ファイルの [shm default] セクションで 10 に設定します。

18.3.2.11 MySQL Cluster での SCI トランスポート接続

config.ini ファイルの [sci] セクションでは、クラスタノード間の SCI (スケーラブルコヒーラントインタフェース) 接続が明示的に定義されます。MySQL Cluster での SCI トランスポータの使用は、--with-ndb-sci=/your/path/to/SCI を使用して MySQL バイナリがビルドされている場合にのみサポートされます。path には、最低でも SISCI のライブラリとヘッダーファイルを含む lib および include ディレクトリを含むディレクトリを指定するようにしてください。(SCI の詳細は、セクション18.3.5「MySQL Cluster での高速インターコネクトの使用」を参照してください。)

また、SCI には専用のハードウェアが必要です。

ndbd プロセス間の通信にのみ SCI トランスポータを使用することを強くお勧めします。SCI トランスポータを使用すると ndbd プロセスがスリープしないことにも注意してください。このため、ndbd プロセスが少なくとも 2 個の CPU を専用で使用できるマシンでのみ、SCI トランスポータを使用するようにしてください。ndbd プロセスごとに少なくとも 1 つの CPU と、オペレーティングシステムのアクティビティーを処理するために少なくとも 1 つの CPU を予備として残します。

  • NodeId1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値[none]...N

    2 つのノード間の接続を識別するには、各ノードのノード識別子を NodeId1 および NodeId2 として指定する必要があります。

  • NodeId2

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0数値[none]...N

    2 つのノード間の接続を識別するには、各ノードのノード識別子を NodeId1 および NodeId2 として指定する必要があります。

  • Host1SciId0

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]0 - 4294967039 (0xFFFFFEFF)N

    これは、(NodeId1 によって識別される) 1 つ目のクラスタノード上の SCI ノード ID を識別します。

  • Host1SciId1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし00 - 4294967039 (0xFFFFFEFF)N

    ノード間で別個のネットワークを使用する 2 つの SCI カード間のフェイルオーバー用に SCI トランスポータを設定できます。これは、1 つ目のノードで使用されるノード ID と 2 つ目の SCI カードを識別します。

  • Host2SciId0

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし[none]0 - 4294967039 (0xFFFFFEFF)N

    これは、(NodeId2 によって識別される) 2 つ目のクラスタノード上の SCI ノード ID を識別します。

  • Host2SciId1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし00 - 4294967039 (0xFFFFFEFF)N

    2 つの SCI カードを使用してフェイルオーバーを提供するときに、このパラメータは 2 つ目のノードで使用される 2 つ目の SCI カードを識別します。

  • HostName1

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    HostName1 および HostName2 パラメータを使用すると、2 つのノード間の特定の SCI 接続で使用する特定のネットワークインタフェースを指定できます。これらのパラメータに使用する値は、ホスト名または IP アドレスです。

  • HostName2

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0名前または IP アドレス[none]...N

    HostName1 および HostName2 パラメータを使用すると、2 つのノード間の特定の SCI 接続で使用する特定のネットワークインタフェースを指定できます。これらのパラメータに使用する値は、ホスト名または IP アドレスです。

  • SharedBufferSize

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし10M64K - 4294967039 (0xFFFFFEFF)N

    各 SCI トランスポートには、2 つのノード間の通信に使用される共有メモリーセグメントがあります。ほとんどのアプリケーションでは、このセグメントのサイズをデフォルト値の 1M バイトに設定すれば十分です。より小さい値を使用すると、多数の並列挿入を実行するときに問題が発生する可能性があります。共有バッファーが小さすぎる場合は、これによって ndbd プロセスがクラッシュする可能性もあります。

  • SendLimit

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0符号なし8K128 - 32KN

    SCI ネットワークで転送されるメッセージは、その前に SCI メディアの直前の小さなバッファーに保存されます。デフォルトでは、これは 8K バイトに設定されます。弊社のベンチマークによれば、64K バイトでパフォーマンスが最高になりますが、16K バイトではこの数パーセント以内であり、8K バイトを超える値に増やしても利点は (あるとしても) ほとんどありませんでした。

  • SendSignalId

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールtruetrue、falseN

    配信されたメッセージをトレースするには、各メッセージを一意に識別する必要があります。このパラメータを Y に設定すると、メッセージ ID がネットワーク経由で転送されます。この機能は、製品ビルドではデフォルトで無効になっており、-debug ビルドで有効になります。

  • Checksum

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0ブールfalsetrue、falseN

    このパラメータはブール値であり、デフォルトで無効になっています。Checksum を有効にすると、送信バッファーに配置される前にすべてのメッセージのチェックサムが計算されます。この機能によって、送信バッファーで待機中のメッセージの破損が回避されます。これは、トランスポート時のデータ破損に対するチェックとしても機能します。

  • OverloadLimit

    有効なバージョン型/単位デフォルト範囲/値再起動タイプ
    NDB 7.3.0バイト00 - 4294967039 (0xFFFFFEFF)N

    送信バッファーにこれより多くの未送信バイトがあるときは、接続が過負荷状態であるとみなされます。詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

18.3.2.12 MySQL Cluster の送信バッファーパラメータの構成

以前の NDB カーネルでは、クラスタ内の各ノードに対してサイズが 2M バイトに固定された送信バッファーが採用され、このバッファーはノードの起動時に割り当てられていました。このバッファーのサイズは、クラスタの起動後に変更できなかったため、事前にトランスポータソケットに対する最大負荷に対応できる十分な大きさにする必要がありました。しかし、多くの場合ほとんどのメモリーが使用されないため、これは非効率的なメモリーの使用方法であり、その結果多数の API ノードに対応して拡張したときに、大量のリソースが浪費される可能性がありました。

この問題は、最終的には (MySQL Cluster NDB 7.0 で) すべてのトランスポータが共有するプールからメモリーを動的に割り当てる統合された送信バッファーを採用することで解決されました。これにより、送信バッファーのサイズを必要に応じて調整できます。統合された送信バッファーの構成は、次のパラメータを設定すると実現できます。

  • TotalSendBufferMemory  このパラメータは、すべてのタイプの MySQL Cluster ノードに対して設定できます。つまり、config.ini ファイルの [ndbd][mgm]、および [api] (または [mysql]) セクションに設定できます。これは、各ノードによって割り当てられ、すべての構成済みトランスポータ間での使用に設定されるメモリーの合計量 (バイト単位) を表します。設定する場合、その最小は 256K バイト、最大は 4294967039 です。

    既存の構成との下位互換性を確保するため、このパラメータのデフォルト値は、すべての構成済みトランスポータの最大送信バッファーサイズの合計にトランスポータあたり 32K バイト (1 ページ) を加えた値になっています。最大は、次の表に示すように、トランスポータのタイプによって異なります。

    トランスポータ最大送信バッファーサイズ (バイト)
    TCPSendBufferMemory (デフォルト = 2M)
    SCISendLimit (デフォルト = 8K) + 16K
    SHM20K

    これにより、既存の構成が MySQL Cluster NDB 6.3 以前とほぼ同じように機能し、各トランスポータで同じ量のメモリーと送信バッファースペースを使用できます。ただし、特定のトランスポータで使用されていないメモリーは、ほかのトランスポータでも使用できません。

  • OverloadLimit  このパラメータは、config.ini ファイルの [tcp] セクションで使用され、接続が過負荷状態であるとみなされる前に送信バッファーに存在する未送信データの量 (バイト単位) を表します。このような過負荷状態が発生すると、過負荷の接続に影響を与えるトランザクションが失敗し、過負荷のステータスが終了するまで次のエラーが発生します: NDB API エラー 1218 (Send Buffers overloaded in NDB kernel)。デフォルト値は 0 です。その場合、特定の接続に対する実質的な過負荷の制限は SendBufferMemory * 0.8 として計算されます。このパラメータの最大値は 4G です。

  • SendBufferMemory  この値は、単一のトランスポータが TotalSendBufferMemory で指定されたプール全体から使用できるメモリー量に対する厳密な制限を表します。ただし、すべての構成済みトランスポータの SendBufferMemory の合計は、特定のノードに対して設定された TotalSendBufferMemory より大きくなることがあります。多数のノードが使用されているときは、すべてのトランスポータがメモリーの最大量を同時に必要としないかぎり、このような方法でメモリーが節約されます。

18.3.3 MySQL Cluster 構成パラメータの概要

次の 4 つのセクションでは、クラスタの機能を管理するために config.ini ファイルで使用される MySQL Cluster 構成パラメータのサマリー表を示します。各表は、クラスタノードプロセスのいずれかのタイプ (ndbdndb_mgmd、および mysqld) に対応するパラメータのリストであり、パラメータのタイプと、場合に応じてそのデフォルト、最小、および最大値を含んでいます。

これらの表は、特定の構成パラメータの値を変更するために必要な再起動のタイプ (ノードの再起動またはシステムの再起動) と、--initial を指定して再起動を実行する必要があるかどうかも示しています。

ノードの再起動またはノードの初期再起動を実行するときは、クラスタのすべてのデータノードを順に再起動する必要があります (ローリング再起動とも呼ばれます)。node としてマークされたクラスタ構成パラメータは、オンラインで (つまり、この方法でクラスタをシャットダウンすることなく) 更新できます。ノードの初期再起動では、--initial オプションを指定して各 ndbd プロセスを再起動する必要があります。

システムの再起動では、クラスタ全体を完全にシャットダウンして再起動する必要があります。システムの初期再起動では、クラスタのバックアップを取り、シャットダウン後にクラスタファイルシステムを消去して、再起動後にバックアップからリストアする必要があります。

どのクラスタ再起動でも、クラスタのすべての管理サーバーを再起動して、更新された構成パラメータ値を読み取ることができるようにする必要があります。

重要

数値型のクラスタパラメータの値は通常問題なく増やすことができますが、そのような調整は比較的小さいインクリメントで徐々に行うことをお勧めします。多くのパラメータは、ローリング再起動を使用してオンラインで増やすことができます。

ただし、このようなパラメータ値の削減は、ノードの再起動、ノードの初期再起動、またはクラスタの完全なシステムの再起動のどれを使用するかに関係なく、安易に行うべきではありません。その場合は、事前に入念な計画とテストを行うことをお勧めします。これは、メモリー使用やディスクスペースに関連するパラメータ (MaxNoOfTablesMaxNoOfOrderedIndexesMaxNoOfUniqueHashIndexes など) に関して特に当てはまります。さらに、一般的には、メモリーおよびディスク使用に関連する構成パラメータは単純なノードの再起動により値を増やすことができますが、値を減らすにはノードの初期再起動が必要になります。

これらのパラメータの一部は、複数のタイプのクラスタノードの構成に使用できるため、複数の表に表示されている場合があります。

注記

これらの表では、多くの場合、最大値として 4294967039 が表示されています。この値は、NDBCLUSTER のソースで MAX_INT_RNIL として定義されており、0xFFFFFEFF、または 232 - 28 - 1 と等価です。

18.3.3.1 MySQL Cluster データノードの構成パラメータ

このセクションのサマリー表では、MySQL Cluster データノードを構成するために config.ini ファイルの [ndbd] または [ndbd default] セクションで使用されるパラメータについて説明します。これらの各パラメータに関する詳しい説明およびその他の追加情報については、セクション18.3.2.6「MySQL Cluster データノードの定義」を参照してください。

これらのパラメータは、ndbd のマルチスレッドバージョンである ndbmtd にも適用されます。詳細は、セクション18.4.3「ndbmtd — MySQL Cluster データノードデーモン (マルチスレッド)」を参照してください。

再起動のタイプ  MySQL Cluster 構成パラメータの変更は、クラスタが再起動されるまで有効になりません。サマリー表では、特定のパラメータの変更に必要な再起動のタイプを次のように示します。

  • N - ノードの再起動: このパラメータは、ローリング再起動を使用して更新できます (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。

  • S - システムの再起動: このパラメータの変更を有効にするには、クラスタを完全にシャットダウンしてから再起動する必要があります。

  • I - 初期再起動: --initial オプションを使用してデータノードを再起動する必要があります。

再起動のタイプの詳細は、セクション18.3.3「MySQL Cluster 構成パラメータの概要」を参照してください。

MySQL Cluster NDB 7.3 以降では、新しいデータノードグループを実行中のクラスタにオンラインで追加する方法がサポートされます。詳細は、セクション18.5.13「MySQL Cluster データノードのオンライン追加」を参照してください。

表 18.1 データノード構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

Arbitration

列挙NNDB 7.3.0
デフォルト
デフォルト、無効、WaitExternal

ArbitrationTimeout

ミリ秒NNDB 7.3.0
7500
10 / 4294967039 (0xFFFFFEFF)

BackupDataBufferSize

バイトNNDB 7.3.0
16M
0 / 4294967039 (0xFFFFFEFF)

BackupDataDir

パスINNDB 7.3.0
FileSystemPath
...

BackupLogBufferSize

バイトNNDB 7.3.0
16M
0 / 4294967039 (0xFFFFFEFF)

BackupMaxWriteSize

バイトNNDB 7.3.0
1M
2K / 4294967039 (0xFFFFFEFF)

BackupMemory

バイトNNDB 7.3.0
32M
0 / 4294967039 (0xFFFFFEFF)

BackupReportFrequency

NNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

BackupWriteSize

バイトNNDB 7.3.0
256K
2K / 4294967039 (0xFFFFFEFF)

BatchSizePerLocalScan

整数NNDB 7.3.0
256
1 / 992

BuildIndexThreads

数値SNDB 7.3.0
0
0 / 128

CompressedBackup

ブールNNDB 7.3.0
false
true、false

CompressedLCP

ブールNNDB 7.3.0
false
true、false

ConnectCheckIntervalDelay

文字列NNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

CrashOnCorruptedTuple

ブールSNDB 7.3.0
true
true、false

DataDir

パスINNDB 7.3.0
.
...

DataMemory

バイトNNDB 7.3.0
80M
1M / 1024G

DefaultHashMapSize

LDM スレッドNNDB 7.3.0
3840
0 / 3840

DictTrace

バイトNNDB 7.3.0
未定義
0 / 100

DiskCheckpointSpeed

バイトNNDB 7.3.0
10M
1M / 4294967039 (0xFFFFFEFF)

DiskCheckpointSpeedInRestart

バイトNNDB 7.3.0
100M
1M / 4294967039 (0xFFFFFEFF)

DiskIOThreadPool

スレッドNNDB 7.3.0
2
0 / 4294967039 (0xFFFFFEFF)

Diskless

true|false (1|0)ISNDB 7.3.0
false
true、false

DiskPageBufferMemory

バイトNNDB 7.3.0
64M
4M / 1T

DiskSyncSize

バイトNNDB 7.3.0
4M
32K / 4294967039 (0xFFFFFEFF)

ExecuteOnComputer

nameSNDB 7.3.0
[none]
...

ExtraSendBufferMemory

バイトNNDB 7.3.0
0
0 / 32G

FileSystemPath

パスINNDB 7.3.0
DataDir
...

FileSystemPathDataFiles

ファイル名INNDB 7.3.0
[テキストを参照]
...

FileSystemPathDD

ファイル名INNDB 7.3.0
FileSystemPath
...

FileSystemPathUndoFiles

ファイル名INNDB 7.3.0
[テキストを参照]
...

FragmentLogFileSize

バイトINNDB 7.3.0
16M
4M / 1G

HeartbeatIntervalDbApi

ミリ秒NNDB 7.3.0
1500
100 / 4294967039 (0xFFFFFEFF)

HeartbeatIntervalDbDb

ミリ秒NNDB 7.3.0
5000
10 / 4294967039 (0xFFFFFEFF)

HeartbeatOrder

数値SNDB 7.3.0
0
0 / 65535

HostName

名前または IP アドレスNNDB 7.3.0
localhost
...

Id

符号なしISNDB 7.3.0
[none]
1 / 48

IndexMemory

バイトNNDB 7.3.0
18M
1M / 1T

IndexStatAutoCreate

ブールSNDB 7.3.0
false
false、true

IndexStatAutoUpdate

ブールSNDB 7.3.0
false
false、true

IndexStatSaveScale

パーセンテージINNDB 7.3.0
100
0 / 4294967039 (0xFFFFFEFF)

IndexStatSaveSize

バイトINNDB 7.3.0
32768
0 / 4294967039 (0xFFFFFEFF)

IndexStatTriggerPct

パーセンテージINNDB 7.3.0
100
0 / 4294967039 (0xFFFFFEFF)

IndexStatTriggerScale

パーセンテージINNDB 7.3.0
100
0 / 4294967039 (0xFFFFFEFF)

IndexStatUpdateDelay

INNDB 7.3.0
60
0 / 4294967039 (0xFFFFFEFF)

InitFragmentLogFiles

[値を参照]INNDB 7.3.0
SPARSE
SPARSE、FULL

InitialLogFileGroup

文字列SNDB 7.3.0
[テキストを参照]
...

InitialNoOfOpenFiles

ファイルNNDB 7.3.0
27
20 / 4294967039 (0xFFFFFEFF)

InitialTablespace

文字列SNDB 7.3.0
[テキストを参照]
...

LateAlloc

数値NNDB 7.3.0
1
0 / 1

LcpScanProgressTimeout

secondNNDB 7.3.3
60
0 / 4294967039 (0xFFFFFEFF)

LockExecuteThreadToCPU

CPU IDNNDB 7.3.0
64K
0 / 64K

LockMaintThreadsToCPU

CPU IDNNDB 7.3.0
[none]
0 / 64K

LockPagesInMainMemory

数値NNDB 7.3.0
0
0 / 2

LogLevelCheckpoint

ログレベルNNDB 7.3.0
0
0 / 15

LogLevelCongestion

levelrNNDB 7.3.0
0
0 / 15

LogLevelConnection

整数NNDB 7.3.0
0
0 / 15

LogLevelError

整数NNDB 7.3.0
0
0 / 15

LogLevelInfo

整数NNDB 7.3.0
0
0 / 15

LogLevelNodeRestart

整数NNDB 7.3.0
0
0 / 15

LogLevelShutdown

整数NNDB 7.3.0
0
0 / 15

LogLevelStartup

整数NNDB 7.3.0
1
0 / 15

LogLevelStatistic

整数NNDB 7.3.0
0
0 / 15

LongMessageBuffer

バイトNNDB 7.3.5
64M
512K / 4294967039 (0xFFFFFEFF)

MaxAllocate

符号なしNNDB 7.3.0
32M
1M / 1G

MaxBufferedEpochs

エポックNNDB 7.3.0
100
0 / 100000

MaxBufferedEpochBytes

バイトNNDB 7.3.0
26214400
26214400 (0x01900000) / 4294967039 (0xFFFFFEFF)

MaxDiskWriteSpeed

数値SNDB 7.4.1
20M
1M / 1024G

MaxDiskWriteSpeedOtherNodeRestart

数値SNDB 7.4.1
50M
1M / 1024G

MaxDiskWriteSpeedOwnRestart

数値SNDB 7.4.1
200M
1M / 1024G

MaxDMLOperationsPerTransaction

操作 (DML)NNDB 7.3.0
4294967295
32 / 4294967295

MaxLCPStartDelay

NNDB 7.3.0
0
0 / 600

MaxNoOfAttributes

整数NNDB 7.3.0
1000
32 / 4294967039 (0xFFFFFEFF)

MaxNoOfConcurrentIndexOperations

整数NNDB 7.3.0
8K
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfConcurrentOperations

整数NNDB 7.3.0
32K
32 / 4294967039 (0xFFFFFEFF)

MaxNoOfConcurrentScans

整数NNDB 7.3.0
256
2 / 500

MaxNoOfConcurrentSubOperations

符号なしNNDB 7.3.0
256
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfConcurrentTransactions

整数NNDB 7.3.0
4096
32 / 4294967039 (0xFFFFFEFF)

MaxNoOfFiredTriggers

整数NNDB 7.3.0
4000
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfLocalOperations

整数NNDB 7.3.0
UNDEFINED
32 / 4294967039 (0xFFFFFEFF)

MaxNoOfLocalScans

整数NNDB 7.3.0
[テキストを参照]
32 / 4294967039 (0xFFFFFEFF)

MaxNoOfOpenFiles

符号なしNNDB 7.3.0
0
20 / 4294967039 (0xFFFFFEFF)

MaxNoOfOrderedIndexes

整数NNDB 7.3.0
128
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfSavedMessages

整数NNDB 7.3.0
25
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfSubscribers

符号なしNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfSubscriptions

符号なしNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfTables

整数NNDB 7.3.0
128
8 / 20320

MaxNoOfTriggers

整数NNDB 7.3.0
768
0 / 4294967039 (0xFFFFFEFF)

MaxNoOfUniqueHashIndexes

整数NNDB 7.3.0
64
0 / 4294967039 (0xFFFFFEFF)

MaxParallelScansPerFragment

バイトNNDB 7.3.0
256
1 / 4294967039 (0xFFFFFEFF)

MaxStartFailRetries

符号なしNNDB 7.3.0
3
0 / 4294967039 (0xFFFFFEFF)

MemReportFrequency

符号なしNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

MinDiskWriteSpeed

数値SNDB 7.4.1
10M
1M / 1024G

MinFreePct

符号なしNNDB 7.3.0
5
0 / 100

NodeGroup

 ISNDB 7.3.0
[none]
0 / 65536

NodeId

符号なしISNDB 7.3.0
[none]
1 / 48

NoOfFragmentLogFiles

整数INNDB 7.3.0
16
3 / 4294967039 (0xFFFFFEFF)

NoOfReplicas

整数ISNDB 7.3.0
2
1 / 4

Numa

ブールNNDB 7.3.0
1
...

ODirect

ブールNNDB 7.3.0
false
true、false

RealtimeScheduler

ブールNNDB 7.3.0
false
true、false

RedoBuffer

バイトNNDB 7.3.0
32M
1M / 4294967039 (0xFFFFFEFF)

RedoOverCommitCounter

数値NNDB 7.3.0
3
0 / 4294967039 (0xFFFFFEFF)

RedoOverCommitLimit

NNDB 7.3.0
20
0 / 4294967039 (0xFFFFFEFF)

ReservedSendBufferMemory

バイトNNDB 7.3.0
256K
0 / 4294967039 (0xFFFFFEFF)

RestartOnErrorInsert

エラーコードNNDB 7.3.0
2
0 / 4

SchedulerExecutionTimer

マイクロ秒NNDB 7.3.0
50
0 / 11000

SchedulerSpinTimer

マイクロ秒NNDB 7.3.0
0
0 / 500

ServerPort

符号なしNNDB 7.3.0
[none]
1 / 64K

SharedGlobalMemory

バイトNNDB 7.3.0
128M
0 / 64T

StartFailRetryDelay

符号なしNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

StartFailureTimeout

ミリ秒NNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

StartNoNodeGroupTimeout

ミリ秒NNDB 7.3.0
15000
0 / 4294967039 (0xFFFFFEFF)

StartPartialTimeout

ミリ秒NNDB 7.3.0
30000
0 / 4294967039 (0xFFFFFEFF)

StartPartitionedTimeout

ミリ秒NNDB 7.3.0
60000
0 / 4294967039 (0xFFFFFEFF)

StartupStatusReportFrequency

NNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

StopOnError

ブールNNDB 7.3.0
1
0、1

StringMemory

% またはバイトSNDB 7.3.0
25
0 / 4294967039 (0xFFFFFEFF)

TcpBind_INADDR_ANY

ブールNNDB 7.3.0
false
true、false

TimeBetweenEpochs

ミリ秒NNDB 7.3.0
100
0 / 32000

TimeBetweenEpochsTimeout

ミリ秒NNDB 7.3.0
0
0 / 256000

TimeBetweenGlobalCheckpoints

ミリ秒NNDB 7.3.0
2000
20 / 32000

TimeBetweenInactiveTransactionAbortCheck

ミリ秒NNDB 7.3.0
1000
1000 / 4294967039 (0xFFFFFEFF)

TimeBetweenLocalCheckpoints

4 バイトワードの数 (底 2 の対数として)NNDB 7.3.0
20
0 / 31

TimeBetweenWatchDogCheck

ミリ秒NNDB 7.3.0
6000
70 / 4294967039 (0xFFFFFEFF)

TimeBetweenWatchDogCheckInitial

ミリ秒NNDB 7.3.0
6000
70 / 4294967039 (0xFFFFFEFF)

TotalSendBufferMemory

バイトNNDB 7.3.0
256K
0 / 4294967039 (0xFFFFFEFF)

TransactionBufferMemory

バイトNNDB 7.3.0
1M
1K / 4294967039 (0xFFFFFEFF)

TransactionDeadlockDetectionTimeout

ミリ秒NNDB 7.3.0
1200
50 / 4294967039 (0xFFFFFEFF)

TransactionInactiveTimeout

ミリ秒NNDB 7.3.0
[テキストを参照]
0 / 4294967039 (0xFFFFFEFF)

TwoPassInitialNodeRestartCopy

ブールNNDB 7.3.0
false
true、false

UndoDataBuffer

符号なしNNDB 7.3.0
16M
1M / 4294967039 (0xFFFFFEFF)

UndoIndexBuffer

符号なしNNDB 7.3.0
2M
1M / 4294967039 (0xFFFFFEFF)

表 18.2 マルチスレッドデータノード構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

MaxNoOfExecutionThreads

整数ISNDB 7.3.3
2
2 / 72

NoOfFragmentLogParts

数値INNDB 7.3.3
4
4、8、12、16、24、32

ThreadConfig

文字列ISNDB 7.3.0
''
...

18.3.3.2 MySQL Cluster 管理ノードの構成パラメータ

このセクションのサマリー表では、MySQL Cluster 管理ノードを構成するために config.ini ファイルの [ndb_mgmd] または [mgm] セクションで使用するパラメータについて説明します。各パラメータ関する詳しい説明およびその他の追加情報については、セクション18.3.2.5「MySQL Cluster 管理サーバーの定義」を参照してください。

再起動のタイプ  MySQL Cluster 構成パラメータの変更は、クラスタが再起動されるまで有効になりません。サマリー表では、特定のパラメータの変更に必要な再起動のタイプを次のように示します。

  • N - ノードの再起動: このパラメータは、ローリング再起動を使用して更新できます (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。

  • S - システムの再起動: このパラメータの変更を有効にするには、クラスタを完全にシャットダウンしてから再起動する必要があります。

  • I - 初期再起動: --initial オプションを使用してデータノードを再起動する必要があります。

再起動のタイプの詳細は、セクション18.3.3「MySQL Cluster 構成パラメータの概要」を参照してください。

表 18.3 管理ノード構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

ArbitrationDelay

ミリ秒NNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

ArbitrationRank

0-2NNDB 7.3.0
1
0 / 2

DataDir

パスNNDB 7.3.0
.
...

ExecuteOnComputer

nameSNDB 7.3.0
[none]
...

HeartbeatIntervalMgmdMgmd

ミリ秒NNDB 7.3.3
1500
100 / 4294967039 (0xFFFFFEFF)

HeartbeatThreadPriority

文字列SNDB 7.3.0
[none]
...

HostName

名前または IP アドレスNNDB 7.3.0
[none]
...

Id

符号なしISNDB 7.3.0
[none]
1 / 255

LogDestination

{CONSOLE|SYSLOG|FILE}NNDB 7.3.0
[テキストを参照]
...

MaxNoOfSavedEvents

符号なしNNDB 7.3.0
100
0 / 4294967039 (0xFFFFFEFF)

NodeId

符号なしISNDB 7.3.0
[none]
1 / 255

PortNumber

符号なしNNDB 7.3.0
1186
0 / 64K

PortNumberStats

符号なしNNDB 7.3.0
[none]
0 / 64K

TotalSendBufferMemory

バイトNNDB 7.3.0
256K
0 / 4294967039 (0xFFFFFEFF)

wan

ブールNNDB 7.3.0
false
true、false

注記

管理ノードの構成に変更を加えたあとは、新しい構成を有効にするために、クラスタのローリング再起動を実行する必要があります。詳細は、セクション18.3.2.5「MySQL Cluster 管理サーバーの定義」を参照してください。

実行中の MySQL Cluster に新しい管理サーバーを追加するには、既存の config.ini ファイルを変更したあとで、すべてのクラスタノードのローリング再起動も実行する必要があります。複数の管理ノードを使用するときに発生する問題の詳細は、セクション18.1.6.10「複数の MySQL Cluster ノードに関する制限」を参照してください。

18.3.3.3 MySQL Cluster SQL ノードおよび API ノードの構成パラメータ

このセクションのサマリー表では、MySQL Cluster SQL ノードおよび API ノードを構成するために config.ini ファイルの [mysqld] および [api] セクションで使用するパラメータについて説明します。各パラメータに関する詳しい説明およびその他の追加情報については、セクション18.3.2.7「MySQL Cluster 内の SQL ノードおよびその他の API ノードの定義」を参照してください。

注記

MySQL Cluster 用の MySQL サーバーオプションについては、セクション18.3.4.2「MySQL Cluster 用の MySQL Server オプション」を参照してください。MySQL Cluster に関連する MySQL サーバーシステム変数については、セクション18.3.4.3「MySQL Cluster のシステム変数」を参照してください。

再起動のタイプ  MySQL Cluster 構成パラメータの変更は、クラスタが再起動されるまで有効になりません。サマリー表では、特定のパラメータの変更に必要な再起動のタイプを次のように示します。

  • N - ノードの再起動: このパラメータは、ローリング再起動を使用して更新できます (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。

  • S - システムの再起動: このパラメータの変更を有効にするには、クラスタを完全にシャットダウンしてから再起動する必要があります。

  • I - 初期再起動: --initial オプションを使用してデータノードを再起動する必要があります。

再起動のタイプの詳細は、セクション18.3.3「MySQL Cluster 構成パラメータの概要」を参照してください。

表 18.4 SQL ノード/API ノード構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

ArbitrationDelay

ミリ秒NNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

ArbitrationRank

0-2NNDB 7.3.0
0
0 / 2

AutoReconnect

ブールNNDB 7.3.0
false
true、false

BatchByteSize

バイトNNDB 7.3.0
16K
1024 / 1M

BatchSize

レコードNNDB 7.3.0
256
1 / 992

ConnectBackoffMaxTime

整数NNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

ConnectionMap

文字列NNDB 7.3.0
[none]
...

DefaultHashMapSize

LDM スレッドNNDB 7.3.0
3840
0 / 3840

DefaultOperationRedoProblemAction

列挙SNDB 7.3.0
QUEUE
ABORT、QUEUE

EventLogBufferSize

バイトSNDB 7.3.0
8192
0 / 64K

ExecuteOnComputer

nameSNDB 7.3.0
[none]
...

ExtraSendBufferMemory

バイトNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

HeartbeatThreadPriority

文字列SNDB 7.3.0
[none]
...

HostName

名前または IP アドレスNNDB 7.3.0
[none]
...

Id

符号なしISNDB 7.3.0
[none]
1 / 255

MaxScanBatchSize

バイトNNDB 7.3.0
256K
32K / 16M

NodeId

符号なしISNDB 7.3.0
[none]
1 / 255

StartConnectBackoffMaxTime

整数NNDB 7.3.0
1500
0 / 4294967039 (0xFFFFFEFF)

TotalSendBufferMemory

バイトNNDB 7.3.0
256K
0 / 4294967039 (0xFFFFFEFF)

wan

ブールNNDB 7.3.0
false
true、false

注記

実行中の MySQL Cluster の構成に新しい SQL または API ノードを追加するには、config.ini ファイル (複数の管理サーバーを使用する場合は複数のファイル) に新しい [mysqld] または [api] セクションを追加したあとで、すべてのクラスタノードのローリング再起動を実行する必要があります。これは、新しい SQL または API ノードをクラスタに接続する前に実行する必要があります。

新しい SQL または API ノードがクラスタ構成内の以前に使用されていない API スロットを使用してクラスタに接続する場合、クラスタの再起動を実行する必要はありません

18.3.3.4 その他の MySQL Cluster 構成パラメータ

このセクションのサマリー表では、MySQL Cluster 管理ノードを構成するために config.ini ファイルの [computer][tcp][shm]、および [sci] セクションで使用するパラメータについて説明します。個々のパラメータに関する詳しい説明およびその他の追加情報については、セクション18.3.2.8「MySQL クラスタの TCP/IP 接続」セクション18.3.2.10「MySQL Cluster の共有メモリー接続」、またはセクション18.3.2.11「MySQL Cluster での SCI トランスポート接続」を必要に応じて参照してください。

再起動のタイプ  MySQL Cluster 構成パラメータの変更は、クラスタが再起動されるまで有効になりません。サマリー表では、特定のパラメータを変更するために必要な再起動のタイプを次のように示します。

  • N - ノードの再起動: このパラメータは、ローリング再起動を使用して更新できます (セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください)。

  • S - システムの再起動: このパラメータの変更を有効にするには、クラスタを完全にシャットダウンしてから再起動する必要があります。

  • I - 初期再起動: --initial オプションを使用してデータノードを再起動する必要があります。

再起動のタイプの詳細は、セクション18.3.3「MySQL Cluster 構成パラメータの概要」を参照してください。

表 18.5 コンピュータ構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

HostName

名前または IP アドレスNNDB 7.3.0
[none]
...

Id

文字列ISNDB 7.3.0
[none]
...

表 18.6 TCP 構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

Checksum

ブールNNDB 7.3.0
false
true、false

Group

符号なしNNDB 7.3.0
55
0 / 200

NodeId1

数値NNDB 7.3.0
[none]
...

NodeId2

数値NNDB 7.3.0
[none]
...

NodeIdServer

数値NNDB 7.3.0
[none]
...

OverloadLimit

バイトNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

PortNumber

符号なしNNDB 7.3.0
[none]
0 / 64K

Proxy

文字列NNDB 7.3.0
[none]
...

ReceiveBufferMemory

バイトNNDB 7.3.0
2M
16K / 4294967039 (0xFFFFFEFF)

SendBufferMemory

符号なしNNDB 7.3.0
2M
256K / 4294967039 (0xFFFFFEFF)

SendSignalId

ブールNNDB 7.3.0
[テキストを参照]
true、false

TCP_MAXSEG_SIZE

符号なしNNDB 7.3.0
0
0 / 2G

TCP_RCV_BUF_SIZE

符号なしNNDB 7.3.1
0
0 / 2G

TCP_SND_BUF_SIZE

符号なしNNDB 7.3.1
0
0 / 2G

TcpBind_INADDR_ANY

ブールNNDB 7.3.0
false
true、false

表 18.7 共有メモリー構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

Checksum

ブールNNDB 7.3.0
true
true、false

Group

符号なしNNDB 7.3.0
35
0 / 200

NodeId1

数値NNDB 7.3.0
[none]
...

NodeId2

数値NNDB 7.3.0
[none]
...

NodeIdServer

数値NNDB 7.3.0
[none]
...

OverloadLimit

バイトNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

PortNumber

符号なしNNDB 7.3.0
[none]
0 / 64K

SendSignalId

ブールNNDB 7.3.0
false
true、false

ShmKey

符号なしNNDB 7.3.0
[none]
0 / 4294967039 (0xFFFFFEFF)

ShmSize

バイトNNDB 7.3.0
1M
64K / 4294967039 (0xFFFFFEFF)

Signum

符号なしNNDB 7.3.0
[none]
0 / 4294967039 (0xFFFFFEFF)

表 18.8 SCI 構成パラメータ

パラメータ名型または単位再起動タイプバージョン ... (以降)
デフォルト値
最小値/最大値または許可される値

Checksum

ブールNNDB 7.3.0
false
true、false

Group

符号なしNNDB 7.3.0
15
0 / 200

Host1SciId0

符号なしNNDB 7.3.0
[none]
0 / 4294967039 (0xFFFFFEFF)

Host1SciId1

符号なしNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

Host2SciId0

符号なしNNDB 7.3.0
[none]
0 / 4294967039 (0xFFFFFEFF)

Host2SciId1

符号なしNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

NodeId1

数値NNDB 7.3.0
[none]
...

NodeId2

数値NNDB 7.3.0
[none]
...

NodeIdServer

数値NNDB 7.3.0
[none]
...

OverloadLimit

バイトNNDB 7.3.0
0
0 / 4294967039 (0xFFFFFEFF)

PortNumber

符号なしNNDB 7.3.0
[none]
0 / 64K

SendLimit

符号なしNNDB 7.3.0
8K
128 / 32K

SendSignalId

ブールNNDB 7.3.0
true
true、false

SharedBufferSize

符号なしNNDB 7.3.0
10M
64K / 4294967039 (0xFFFFFEFF)

18.3.4 MySQL Cluster 用の MySQL Server オプションおよび変数

このセクションでは、MySQL Cluster に固有の MySQL サーバーオプションとサーバーおよびステータス変数について説明します。これらの使用に関する一般情報と、MySQL Cluster に固有でないその他のオプションおよび変数については、セクション5.1「MySQL Server」を参照してください。

クラスタ構成ファイル (通常、config.ini という名前) で使用する MySQL Cluster 構成パラメータについては、セクション18.3「MySQL Cluster の構成」を参照してください。

18.3.4.1 MySQL Cluster の mysqld オプションおよび変数のリファレンス

次の表に、MySQL Cluster 内で SQL ノードとして実行されているときの mysqld に適用されるコマンド行オプションとサーバーおよびステータス変数のリストを示します。mysqld で使用できるすべてのコマンド行オプションとサーバーおよびステータス変数を示す表については、セクション5.1.1「サーバーオプションおよび変数リファレンス」を参照してください。

表 18.9  MySQL Cluster 用の MySQL Server オプションおよび変数: MySQL Cluster NDB 7.3-7.4

オプションまたは変数名
コマンド行システム変数ステータス変数
オプションファイルスコープ動的
メモ

Handler_discover

いいえいいえはい
いいえ両方いいえ

説明: テーブルが検出された回数

Ndb_api_wait_exec_complete_count_session

いいえいいえはい
いいえセッションいいえ

説明: このクライアントセッションで、操作の実行が完了するのを待機する間にスレッドがブロックされた回数。

Ndb_api_wait_exec_complete_count_slave

いいえいいえはい
いいえグローバルいいえ

説明: このスレーブによって、操作の実行が完了するのを待機する間にスレッドがブロックされた回数。

Ndb_api_wait_exec_complete_count

いいえいいえはい
いいえグローバルいいえ

説明: この MySQL Server (SQL ノード) によって、操作の実行が完了するのを待機する間にスレッドがブロックされた回数。

Ndb_api_wait_scan_result_count_session

いいえいいえはい
いいえセッションいいえ

説明: このクライアントセッションで、スキャンベースの信号を待機する間にスレッドがブロックされた回数。

Ndb_api_wait_scan_result_count_slave

いいえいいえ