--bind-address=host

管理サーバーを特定のネットワークインタフェース (ホスト名または IP アドレス) にバインドします。 このオプションにはデフォルト値はありません。

cluster-config-suffix

my.cnf でクラスタ構成セクションを読み取るときに、デフォルトのグループサフィクスをオーバーライドします。テストで使用されます。

--config-cache

このオプション (デフォルト値は 1 (または TRUE、ON)) は、管理サーバーが起動するたびに config.ini から構成が読み取られるように (セクション23.3.3「NDB 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

構成ファイルとして使用すべきファイルを管理サーバーに指示します。 デフォルトでは、管理サーバーは ndb_mgmd 実行可能ファイルと同じディレクトリで config.ini という名前のファイルを探します。それ以外の場合は、ファイル名および場所を明示的に指定する必要があります。

このオプションにはデフォルト値はなく、--reload または --initial オプションを指定して ndb_mgmd が起動されたか、管理サーバーが構成キャッシュを見つけることができなかったために、管理サーバーが構成ファイルを読み取るように強制された場合を除き、無視されます。 このオプションは、--config-cache=OFF を指定して ndb_mgmd が開始された場合にも読み取られます。 詳細は、セクション23.3.3「NDB Cluster 構成ファイル」を参照してください。

--configdir=dir_name

クラスタ管理サーバーの構成キャッシュディレクトリを指定します。--config-dir はこのオプションのエイリアスです。

--daemon、-d

ndb_mgmd にデーモンプロセスとして開始するように指示します。 これはデフォルトの動作です。

このオプションは ndb_mgmd を Windows プラットフォームで実行している場合は効果がありません。

--initial

構成データは、管理サーバーが開始されるたびにクラスタグローバル構成ファイルから読み取られるのではなく、内部的にキャッシュされます (セクション23.3.3「NDB Cluster 構成ファイル」を参照してください)。 --initial オプションを使用するとこの動作がオーバーライドされ、管理サーバーが既存のキャッシュファイルを削除し、クラスタ構成ファイルから構成データを再度読み取り、新しいキャッシュを作成するように強制されます。

これは、2 つの点で --reload オプションと異なります。 まず、--reload を指定すると、サーバーが構成ファイルをキャッシュと照合し、ファイルの内容がキャッシュと異なる場合にのみデータをリロードすることが強制されます。 2 番目に、--reload は既存のキャッシュファイルを削除しません。

--initial を指定して ndb_mgmd が呼び出されたけれどもグローバル構成ファイルが見つからない場合、管理サーバーは起動できません。

管理サーバーは起動時に、同じ NDB Cluster 内の別の管理サーバーをチェックし、ほかの管理サーバー構成データを使用しようとします。 この動作は、複数の管理ノードを持つ NDB Cluster のローリング再起動を実行するときに影響を及ぼします。 詳細は、セクション23.5.5「NDB Cluster のローリング再起動の実行」を参照してください。

--config-file オプションとともに使用すると、キャッシュは構成ファイルが実際に見つかった場合にのみクリアされます。

--install[=name]

ndb_mgmd が Windows サービスとしてインストールされます。 必要に応じて、サービスの名前を指定できます。設定しない場合、サービス名は ndb_mgmd にデフォルト設定されます。 その他の ndb_mgmd プログラムオプションは my.ini または my.cnf 構成ファイルに指定することが推奨されますが、--install と一緒に使用できます。 ただし、そのような場合、Windows サービスのインストールが成功するには、--install オプションを最初に指定してから、ほかのオプションを指定する必要があります。

このオプションを --initial オプションと一緒に使用することは一般的にお勧めしません。サービスが停止および開始されるたびに構成キャッシュが消去されて再作成されるためです。 管理サーバーの起動に影響するほかの ndb_mgmd オプションを使用する場合にも注意すべきであり、それを行うことを十分に理解し、起こり得る結果に対して十分に準備していることをしっかりと確認してください。

--install オプションは、Windows 以外のプラットフォームでは効果がありません。

--interactive

ndb_mgmd をインタラクティブモードで開始します。つまり、管理サーバーが実行されるとすぐに ndb_mgm クライアントセッションが開始されます。 このオプションは、ほかの NDB Cluster ノードを起動しません。

--log-name=name

クラスタログでこのノードに使用される名前を指定します。

--mycnf

my.cnf ファイルから構成データを読み取ります。

--no-nodeid-checks

ノード ID のチェックを実行しません。

--nodaemon

ndb_mgmd にデーモンプロセスとして開始しないように指示します。

Windows での ndb_mgmd のデフォルト動作はフォアグラウンドでの実行であるため、Windows プラットフォームではこのオプションは必要ありません。

--nowait-nodes

NDB Cluster を 2 つの管理ノードで起動する場合、各管理サーバーは通常、ほかの ndb_mgmd も動作しているかどうか、およびほかの管理サーバー構成がそれ自体と同じかどうかを確認します。 ただし、クラスタを 1 つの管理ノードのみで起動すること (およびおそらく別の ndb_mgmd をあとで起動することを許可すること) が望ましい場合があります。 このオプションを指定すると、このオプションに渡されたノード ID を持つ別の管理ノードを管理ノードがチェックせず、起動された管理ノードのみを使用するように構成されているかのようにクラスタが起動することを許可します。

説明のために、config.ini ファイルに次の部分があるとします (ここでは、この例に関連しないほとんどの構成パラメータを省略しています)。

[ndbd]
NodeId = 1
HostName = 198.51.100.101

[ndbd]
NodeId = 2
HostName = 198.51.100.102

[ndbd]
NodeId = 3
HostName = 198.51.100.103

[ndbd]
NodeId = 4
HostName = 198.51.100.104

[ndb_mgmd]
NodeId = 10
HostName = 198.51.100.150

[ndb_mgmd]
NodeId = 11
HostName = 198.51.100.151

[api]
NodeId = 20
HostName = 198.51.100.200

[api]
NodeId = 21
HostName = 198.51.100.201

ノード ID が 10 で、IP アドレスが 198.51.100.150 のホストで動作する管理サーバーのみを使用して、このクラスタを起動するとします。 (たとえば、別の管理サーバーを実行する予定のホストコンピュータがハードウェア障害のために一時的に使用できず、それが修復されるのを待っていると想定してください)。 このようにクラスタを起動するには、198.51.100.150 のマシンのコマンド行を使用して、次のコマンドを入力します。

shell> ndb_mgmd --ndb-nodeid=10 --nowait-nodes=11

前の例に示されているように、--nowait-nodes を使用する場合は、--ndb-nodeid オプションも使用して、この ndb_mgmd プロセスのノード ID を指定する必要があります。

その後、クラスタの各データノードを通常の方法で起動できます。 最初の管理サーバーに加えて、あとでデータノードを再起動せずに 2 番目の管理サーバーを起動して使用する場合は、両方の管理サーバーを参照する接続文字列を次のように指定して、各データノードを起動する必要があります。

shell> ndbd -c 198.51.100.150,198.51.100.151

このクラスタに接続された NDB Cluster SQL ノードとして起動する mysqld プロセスで使用される接続文字列についても同様です。 詳細は、セクション23.3.3.3「NDB Cluster 接続文字列」を参照してください。

ndb_mgmd とともに使用すると、このオプションは別の管理ノードに関してのみ管理ノードの動作に影響します。 ndbd または ndbmtd (全量より少ない数のデータノードでクラスタを起動できる) に使用される --nowait-nodes オプションと混同しないでください。このオプションをデータノードに使用した場合は、ほかのデータノードに関係する動作にのみ影響します。

複数の管理ノード ID は、カンマ区切りリストとしてこのオプションに渡すことができます。 各ノード ID は、1 から 255 までである必要があります。 実際には、同じ NDB Cluster に複数の管理サーバーを使用する (または必要な場合) ことはほとんどありません。ほとんどの場合、このオプションに渡す必要があるのは、クラスタの起動時に使用しない単一の管理サーバーの単一ノード ID のみです。

--print-full-config, -P

クラスタの構成に関する詳細情報を表示します。 このオプションをコマンド行に指定すると、ndb_mgmd プロセスはクラスタ設定に関する情報 (クラスタ構成セクションの詳細なリスト、およびパラメータとその値を含む) を出力します。 通常、--config-file (-f) オプションと一緒に使用します。

--reload

NDB Cluster 構成データは、管理サーバーが起動されるたびにクラスタグローバル構成ファイルから読み取られるのではなく、内部的に格納されます (セクション23.3.3「NDB Cluster 構成ファイル」 を参照)。 このオプションを使用すると、管理サーバーが内部データストアをクラスタ構成ファイルと照合し、構成ファイルがキャッシュと一致しないことが判明した場合は、構成をリロードすることを強制します。 既存の構成キャッシュファイルは維持されますが使用されません。

これは、2 つの点で --initial オプションと異なります。 最初に、--initial ではすべてのキャッシュファイルが削除されます。 2 番目に、--initial は、グローバル構成ファイルを再度読み取って新しいキャッシュを作成することを管理サーバーに強制します。

管理サーバーがグローバル構成ファイルを見つけられない場合、--reload オプションは無視されます。

--reload を使用する場合、管理サーバーはグローバル構成ファイルを読み取ろうとする前に、クラスタ内のデータノードおよびその他の管理サーバーと通信できる必要があります。通信できない場合、管理サーバーは起動に失敗します。 これは、ノードの新しい IP アドレスやファイアウォール構成の変更など、ネットワーク環境の変更が原因で発生する可能性があります。 このような場合は、かわりに --initial を使用して、既存のキャッシュ済構成を強制的に破棄し、ファイルからリロードする必要があります。 詳細は、セクション23.5.5「NDB Cluster のローリング再起動の実行」,を参照してください。

--remove{=name]

Windows サービスとしてインストールされている管理サーバープロセスを削除します。オプションで、削除するサービスの名前を指定します。 Windows プラットフォームにのみ適用されます。

--verbose, -v

Windows サービスとしてインストールされている管理サーバープロセスを削除します。オプションで、削除するサービスの名前を指定します。 Windows プラットフォームにのみ適用されます。

config.ini は、クラスタ全体の構成ファイルです。 このファイルはユーザーが作成し、管理サーバーによって読み取られます。セクション23.3「NDB Cluster の構成」では、このファイルをセットアップする方法について説明しています。

ndb_node_id_cluster.log はクラスタイベントログファイルです。 そのようなイベントの例としては、チェックポイントの開始と完了、ノードの起動イベント、ノードの障害、およびメモリー使用率のレベルが含まれます。 クラスタイベントの完全なリストおよびその説明は、セクション23.5「NDB Cluster の管理」にあります。

デフォルトでは、クラスタログのサイズが 100 万バイトに達すると、ファイルの名前が ndb_node_id_cluster.log.seq_id に変更されます。ここで、seq_id はクラスタログファイルの順序番号です。 (たとえば、シーケンス番号 1、2、3 を持つファイルがすでに存在する場合、次のログファイルは番号 4 を使用して名前が付けられます)。 LogDestination 構成パラメータを使用して、ファイルのサイズと数、およびクラスタログのその他の特性を変更できます。

ndb_node_id_out.log は、管理サーバーがデーモンとして実行されているときに、stdout および stderr のために使用されるファイルです。

ndb_node_id.pid は、管理サーバーをデーモンとして実行しているときに使用されるプロセス ID ファイルです。