管理サーバーは、クラスタ構成ファイルを読み取り、この情報を要求したクラスタ内のすべてのノードにそれを配布するプロセスです。また、これはクラスタのアクティビティーに関するログを管理します。管理クライアントは、管理サーバーに接続してクラスタのステータスをチェックできます。
次の表には、MySQL Cluster 管理サーバープログラム ndb_mgmd に固有のオプションが含まれています。追加説明が表のあとにあります。ほとんどの MySQL Cluster プログラム (ndb_mgmd を含む) に共通するオプションについては、セクション18.4.27「MySQL Cluster プログラムに共通するオプション — MySQL Cluster プログラムに共通するオプション」を参照してください。
表 18.79 この表は、ndb_mgmd プログラムのコマンド行オプションについて説明しています
形式 | 説明 | 追加または削除 |
---|---|---|
クラスタ構成ファイルを指定します。NDB 6.4.0 以降では、構成キャッシュをオーバーライドする (ある場合) には --reload または --initial が必要となります |
すべての MySQL 5.6 ベースリリース |
|
クラスタ管理サーバーの構成キャッシュディレクトリを指定します |
すべての MySQL 5.6 ベースリリース |
|
ローカルバインドアドレス |
すべての MySQL 5.6 ベースリリース |
|
すべての構成を出力して終了します |
すべての MySQL 5.6 ベースリリース |
|
ndb_mgmd をデーモンモードで実行します (デフォルト) |
すべての MySQL 5.6 ベースリリース |
|
ndb_mgmd をデーモンとして実行しません |
すべての MySQL 5.6 ベースリリース |
|
ndb_mgmd をインタラクティブモードで実行します (本番では正式にサポートされていません。テストのためのみです) |
すべての MySQL 5.6 ベースリリース |
|
このノードに適用されるメッセージをクラスタログに書き込むときに使用される名前。 |
すべての MySQL 5.6 ベースリリース |
|
ノード ID チェックを提供しません |
すべての MySQL 5.6 ベースリリース |
|
my.cnf ファイルからクラスタ構成データを読み取ります |
すべての MySQL 5.6 ベースリリース |
|
管理サーバーが構成ファイルを構成キャッシュと比較します |
すべての MySQL 5.6 ベースリリース |
|
管理サーバーが構成キャッシュをバイパスして、構成データを構成ファイルからリロードします |
すべての MySQL 5.6 ベースリリース |
|
この管理サーバーを起動するときに、これらの管理ノードを待機しません。--ndb-nodeid も使用する必要があります。 |
すべての MySQL 5.6 ベースリリース |
|
管理サーバー構成キャッシュを有効にします。デフォルトは TRUE です。 |
すべての MySQL 5.6 ベースリリース |
|
管理サーバープロセスを Windows サービスとしてインストールするために使用します。Windows 以外のプラットフォームには該当しません。 |
すべての MySQL 5.6 ベースリリース |
|
以前 Windows サービスとしてインストールされた管理サーバープロセスを削除するために使用します。必要に応じて、削除するサービスの名前を指定します。Windows 以外のプラットフォームには該当しません。 |
すべての MySQL 5.6 ベースリリース |
-
コマンド行形式 --bind-address=ip_address
型 文字列 デフォルト [none]
このオプションを指定すると、管理クライアントによる管理サーバーへの接続が、指定したホスト名または IP アドレス (およびポート (指定された場合)) のクライアントに制限されます。その場合、ほかのアドレスから管理サーバーに接続しようとする管理クライアントは、次のエラーが発生して失敗します。Unable to setup port:
host
:port
!port
を指定しない場合、管理クライアントはポート 1186 を使用することを試みます。 -
コマンド行形式 --no-nodeid-checks
型 ブール デフォルト FALSE
ノード ID のチェックを実行しません。
-
コマンド行形式 --configdir=directory
--config-dir=directory
型 ファイル名 デフォルト $INSTALLDIR/mysql-cluster
クラスタ管理サーバーの構成キャッシュディレクトリを指定します。
--config-dir
はこのオプションのエイリアスです。 -
コマンド行形式 --config-cache[=TRUE|FALSE]
型 ブール デフォルト TRUE
このオプション (デフォルト値は
1
(またはTRUE
、ON
)) は、管理サーバーが起動するたびにconfig.ini
から構成が読み取られるように (セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください) その構成キャッシュを無効にするために使用できます。これを行うには、次のいずれかのオプションを指定して ndb_mgmd プロセスを開始します。一覧したいずれかのオプションの使用が有効となるのは、管理サーバーが開始されたときに格納されている構成がない場合のみです。管理サーバーが構成キャッシュファイルを見つけると、
--config-cache
オプションまたは--skip-config-cache
オプションは無視されます。このため、構成キャッシュを無効にするには、管理サーバーを最初に起動するときにこのオプションを使用してください。それ以外の場合、つまり、構成キャッシュがすでに作成されている管理サーバーの構成キャッシュを無効にする場合は、管理サーバーを停止して、既存の構成キャッシュファイルを手動で削除してから、--skip-config-cache
を指定して (または--config-cache
に 0、OFF
、またはFALSE
を設定して) 管理サーバーを再起動する必要があります。構成キャッシュファイルは通常、インストールディレクトリの下の
mysql-cluster
という名前のディレクトリに作成されます (--configdir
オプションを使用してこの場所がオーバーライドされていない場合)。管理サーバーが構成データを更新するたびに、新しいキャッシュファイルが生成されます。このファイルは、次の形式を使用して作成順に連続した名前が付けられます。ndb_node-id_config.bin.seq-number
node-id
は管理サーバーのノード ID であり、seq-number
は 1 から始まるシーケンス番号です。たとえば、管理サーバーのノード ID が 5 の場合、最初の 3 つの構成キャッシュファイルが作成されるときにndb_5_config.bin.1
、ndb_5_config.bin.2
、およびndb_5_config.bin.3
という名前が付けられます。実際にキャッシュを無効にせずに、構成キャッシュをパージまたはリロードする場合は、
--skip-config-cache
オプションの代わりに--reload
オプションまたは--initial
オプションのいずれかを指定して ndb_mgmd を開始してください。構成キャッシュを再度有効にするには、構成キャッシュを無効にするために前に使用した
--config-cache
オプションまたは--skip-config-cache
オプションを指定せずに管理サーバーを再起動します。--skip-config-cache
が使用された場合、ndb_mgmd は構成ディレクトリ (--configdir
) をチェックせずに作成しようとします。(Bug#13428853) -
--config-file=
、filename
-f
filename
コマンド行形式 --config-file=file
型 ファイル名 デフォルト [none]
構成ファイルとして使用すべきファイルを管理サーバーに指示します。デフォルトでは、管理サーバーは ndb_mgmd 実行可能ファイルと同じディレクトリで
config.ini
という名前のファイルを探します。それ以外の場合は、ファイル名および場所を明示的に指定する必要があります。このオプションにはデフォルト値はなく、
--reload
または--initial
オプションを指定して ndb_mgmd が起動されたか、管理サーバーが構成キャッシュを見つけることができなかったために、管理サーバーが構成ファイルを読み取るように強制された場合を除き、無視されます。このオプションは、--config-cache=OFF
を指定して ndb_mgmd が開始された場合にも読み取られます。詳細は、セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください。以前は、このオプションを
--initial
と一緒に使用すると、ファイルが見つからなくても構成キャッシュが削除されました。この問題は MySQL Cluster NDB 7.3.2 で解決されました。(Bug #1299289) -
コマンド行形式 --mycnf
型 ブール デフォルト FALSE
my.cnf
ファイルから構成データを読み取ります。 -
コマンド行形式 --daemon
型 ブール デフォルト TRUE
ndb_mgmd にデーモンプロセスとして開始するように指示します。これはデフォルトの動作です。
このオプションは ndb_mgmd を Windows プラットフォームで実行している場合は効果がありません。
-
コマンド行形式 --interactive
型 ブール デフォルト FALSE
ndb_mgmd をインタラクティブモードで開始します。つまり、管理サーバーが実行されるとすぐに ndb_mgm クライアントセッションが開始されます。このオプションはほかの MySQL Cluster ノードを起動しません。
-
コマンド行形式 --initial
型 ブール デフォルト FALSE
構成データは、管理サーバーが開始されるたびにクラスタグローバル構成ファイルから読み取られるのではなく、内部的にキャッシュされます (セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください)。
--initial
オプションを使用するとこの動作がオーバーライドされ、管理サーバーが既存のキャッシュファイルを削除し、クラスタ構成ファイルから構成データを再度読み取り、新しいキャッシュを作成するように強制されます。これは、2 つの点で
--reload
オプションと異なります。まず、--reload
を指定すると、サーバーが構成ファイルをキャッシュと照合し、ファイルの内容がキャッシュと異なる場合にのみデータをリロードすることが強制されます。2 番目に、--reload
は既存のキャッシュファイルを削除しません。--initial
を指定して ndb_mgmd が呼び出されたけれどもグローバル構成ファイルが見つからない場合、管理サーバーは起動できません。管理サーバーが起動されると、同じ MySQL Cluster 内の別の管理サーバーをチェックし、ほかの管理サーバーの構成データを使用することを試みます。ndb_mgmd は、それが実行されている唯一の管理サーバーである場合を除き、
--initial
を無視します。この動作は、複数の管理ノードを持つ MySQL Cluster でローリング再起動を実行するときにも影響します。詳細は、セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください。以前は、このオプションを
--config-file
オプションと一緒に使用すると、ファイルが見つからなくても構成キャッシュが削除されました。MySQL Cluster NDB 7.3.2 以降では、構成ファイルが実際に見つかった場合にのみ、キャッシュがそのようにクリアされます。(Bug #1299289) -
コマンド行形式 --log-name=name
型 文字列 デフォルト MgmtSrvr
クラスタログでこのノードに使用される名前を指定します。
-
コマンド行形式 --nodaemon
型 ブール デフォルト FALSE
ndb_mgmd にデーモンプロセスとして開始しないように指示します。
Windows での ndb_mgmd のデフォルト動作はフォアグラウンドでの実行であるため、Windows プラットフォームではこのオプションは必要ありません。
-
コマンド行形式 --print-full-config
型 ブール デフォルト FALSE
クラスタの構成に関する詳細情報を表示します。このオプションをコマンド行に指定すると、ndb_mgmd プロセスはクラスタ設定に関する情報 (クラスタ構成セクションの詳細なリスト、およびパラメータとその値を含む) を出力します。通常、
--config-file
(-f
) オプションと一緒に使用します。 -
コマンド行形式 --reload
型 ブール デフォルト FALSE
MySQL Cluster NDB 7.3 では、構成データは、管理サーバーが起動されるたびにクラスタグローバル構成ファイルから読み取られるのではなく、内部に格納されます (セクション18.3.2「MySQL Cluster の構成ファイル」を参照してください)。このオプションを使用すると、管理サーバーが内部データストアをクラスタ構成ファイルと照合し、構成ファイルがキャッシュと一致しないことが判明した場合は、構成をリロードすることを強制します。既存の構成キャッシュファイルは維持されますが使用されません。
これは、2 つの点で
--initial
オプションと異なります。最初に、--initial
ではすべてのキャッシュファイルが削除されます。2 番目に、--initial
は、グローバル構成ファイルを再度読み取って新しいキャッシュを作成することを管理サーバーに強制します。管理サーバーがグローバル構成ファイルを見つけられない場合、
--reload
オプションは無視されます。管理サーバーが起動されると、同じ MySQL Cluster 内の別の管理サーバーをチェックして、ほかの管理サーバーの構成データを使用することを試みます。ndb_mgmd は、それが実行されている唯一の管理サーバーである場合を除き、
--reload
を無視します。この動作は、複数の管理ノードを持つ MySQL Cluster でローリング再起動を実行するときにも影響します。詳細は、セクション18.5.5「MySQL Cluster のローリング再起動の実行」を参照してください。 -
コマンド行形式 --nowait-nodes=list
型 数値 デフォルト 最小値 1
最大値 255
MySQL Cluster は、起動されると 2 つの管理ノードで構成され、通常、各管理サーバーは別の ndb_mgmd も動作しているかどうか、および別の管理サーバーの構成がそれ自体の構成と同じであるかどうかを確認します。ただし、クラスタを 1 つの管理ノードのみで起動すること (およびおそらく別の ndb_mgmd をあとで起動することを許可すること) が望ましい場合があります。このオプションを指定すると、このオプションに渡されたノード ID を持つ別の管理ノードを管理ノードがチェックせず、起動された管理ノードのみを使用するように構成されているかのようにクラスタが起動することを許可します。
説明のために、
config.ini
ファイルに次の部分があるとします (ここでは、この例に関連しないほとんどの構成パラメータを省略しています)。[ndbd] NodeId = 1 HostName = 192.168.0.101 [ndbd] NodeId = 2 HostName = 192.168.0.102 [ndbd] NodeId = 3 HostName = 192.168.0.103 [ndbd] NodeId = 4 HostName = 192.168.0.104 [ndb_mgmd] NodeId = 10 HostName = 192.168.0.150 [ndb_mgmd] NodeId = 11 HostName = 192.168.0.151 [api] NodeId = 20 HostName = 192.168.0.200 [api] NodeId = 21 HostName = 192.168.0.201
ノード ID が
10
で、IP アドレスが 192.168.0.150 のホストで動作する管理サーバーのみを使用して、このクラスタを起動するとします。(たとえば、別の管理サーバーを実行する予定のホストコンピュータがハードウェア障害のために一時的に使用できず、それが修復されるのを待っていると想定してください)。このようにクラスタを起動するには、192.168.0.150 のマシンのコマンド行を使用して、次のコマンドを入力します。shell> ndb_mgmd --ndb-nodeid=10 --nowait-nodes=11
前の例に示されているように、
--nowait-nodes
を使用する場合は、--ndb-nodeid
オプションも使用して、この ndb_mgmd プロセスのノード ID を指定する必要があります。その後、クラスタの各データノードを通常の方法で起動できます。最初の管理サーバーに加えて、あとでデータノードを再起動せずに 2 番目の管理サーバーを起動して使用する場合は、両方の管理サーバーを参照する接続文字列を次のように指定して、各データノードを起動する必要があります。
shell> ndbd -c 192.168.0.150,192.168.0.151
mysqld プロセスのうち、このクラスタに接続される MySQL Cluster SQL ノードとして起動するものに使用される接続文字列に関しても同様です。詳細は、セクション18.3.2.3「MySQL Cluster の接続文字列」を参照してください。
ndb_mgmd とともに使用すると、このオプションは別の管理ノードに関してのみ管理ノードの動作に影響します。ndbd または ndbmtd (全量より少ない数のデータノードでクラスタを起動できる) に使用される
--nowait-nodes
オプションと混同しないでください。このオプションをデータノードに使用した場合は、ほかのデータノードに関係する動作にのみ影響します。複数の管理ノード ID は、カンマ区切りリストとしてこのオプションに渡すことができます。各ノード ID は、1 から 255 までである必要があります。実際には、同じ MySQL Cluster に 3 つ以上の管理サーバーを使用することは (または、そのようにする必要性があることは) きわめてまれです。ほとんどの場合、このオプションに渡す必要があるのは、クラスタの起動時に使用しない 1 つの管理サーバーの単一ノード ID のみです。
注記「欠けている」管理サーバーをあとで起動する場合は、クラスタですでに使用されている管理サーバーと構成が一致している必要があります。そうしないと、既存の管理サーバーによって実行される構成チェックで失敗して起動されません。
管理サーバーを起動するときに、接続文字列を必ず指定する必要があるわけではありません。ただし、複数の管理サーバーを使用している場合は、接続文字列を指定して、クラスタ内の各ノードにノード ID を明示的に指定してください。
接続文字列の使用方法については、セクション18.3.2.3「MySQL Cluster の接続文字列」を参照してください。セクション18.4.4「ndb_mgmd — MySQL Cluster 管理サーバーデーモン」では、ndb_mgmd のその他のオプションについて説明しています。
次のファイルは、起動ディレクトリにある ndb_mgmd によって作成または使用され、config.ini
構成ファイルに指定されている DataDir
に配置されます。次のリストでは、node_id
は一意のノード識別子です。
config.ini
はクラスタ全体の構成ファイルです。このファイルはユーザーが作成し、管理サーバーによって読み取られます。セクション18.3「MySQL Cluster の構成」では、このファイルをセットアップする方法について説明しています。-
ndb_
はクラスタイベントログファイルです。そのようなイベントの例としては、チェックポイントの開始と完了、ノードの起動イベント、ノードの障害、およびメモリー使用率のレベルが含まれます。クラスタイベントの完全なリストおよびその説明は、セクション18.5「MySQL Cluster の管理」にあります。node_id
_cluster.logクラスタログのサイズが百万バイトに達すると、ファイルが
ndb_
に名前変更されます。ここで、node_id
_cluster.log.seq_id
seq_id
はクラスタログファイルのシーケンス番号です(たとえば、シーケンス番号 1、2、3 を持つファイルがすでに存在する場合、次のログファイルは番号4
を使用して名前が付けられます)。 ndb_
は、管理サーバーがデーモンとして実行されているときに、node_id
_out.logstdout
およびstderr
のために使用されるファイルです。ndb_
は、管理サーバーをデーモンとして実行しているときに使用されるプロセス ID ファイルです。node_id
.pid-
コマンド行形式 --install[=name]
プラットフォーム固有 Windows 型 文字列 デフォルト ndb_mgmd
ndb_mgmd が Windows サービスとしてインストールされます。必要に応じて、サービスの名前を指定できます。設定しない場合、サービス名は
ndb_mgmd
にデフォルト設定されます。その他の ndb_mgmd プログラムオプションはmy.ini
またはmy.cnf
構成ファイルに指定することが推奨されますが、--install
と一緒に使用できます。ただし、そのような場合、Windows サービスのインストールが成功するには、--install
オプションを最初に指定してから、ほかのオプションを指定する必要があります。このオプションを
--initial
オプションと一緒に使用することは一般的にお勧めしません。サービスが停止および開始されるたびに構成キャッシュが消去されて再作成されるためです。管理サーバーの起動に影響するほかの ndb_mgmd オプションを使用する場合にも注意すべきであり、それを行うことを十分に理解し、起こり得る結果に対して十分に準備していることをしっかりと確認してください。--install
オプションは、Windows 以外のプラットフォームでは効果がありません。 -
コマンド行形式 --remove[=name]
プラットフォーム固有 Windows 型 文字列 デフォルト ndb_mgmd
Windows サービスとして以前にインストールされた ndb_mgmd プロセスが削除されます。必要に応じて、アンインストールするサービスの名前を指定できます。設定しない場合、サービス名は
ndb_mgmd
にデフォルト設定されます。--remove
オプションは、Windows 以外のプラットフォームでは効果がありません。