• [COMPUTER]:クラスタのホストを定義します。これは実際の MySQL クラスタの設定には必要ありませんが、大きなクラスタを設定する際に使用すると便利です。詳細については、項14.4.4.3. 「クラスタ コンピュータの定義」 をご参照してください。

• [NDBD]:クラスタ データノード (ndbd プロセス) の定義します。詳細は、項14.4.4.5. 「Defining Data Nodes」 を参照してください。

• [MYSQLD]:クラスタ MySQL サーバーノード (SQL または API ノードとも呼ばれている) を定義します。SQL ノード設定の説明については 項14.4.4.6. 「SQL および他の API ノードの定義」 を参照してください。

• [MGM] あるいは [NDB_MGMD]:クラスタ マネジメント サーバー (MGM) ノードを定義します。MGM ノードの設定に関する情報は 項14.4.4.4. 「マネジメント サーバーの定義」 を参照してください。

• [TCP]:TCP/IPがデフォルトの接続プロトコルの場合のクラスタ ノード間の TCP/IP 接続を定義します。通常、[TCP] あるいは [TCP DEFAULT] セクションは、クラスタが自動的にこれを行うので MySQL Cluster の設定には必要はありませんが、クラスタにより提供されたデフォルトをオーバーライドする際に必要になる場合があります。利用できる TCP/IP の設定パラメータおよびその使用方法については 項14.4.4.7. 「Cluster TCP/IP Connections」 を参照してください。(項14.4.4.8. 「直接接続を使用した TCP/IP の接続」 にもこのTCP/IP に関する情報を載せてあります。）

• [SHM]:ノード間の共有メモリの接続を定義します。MySQL 5.1 では、それはデフォルトで有効になっていますが現在はまだ試験段階です。SHM のインターコネクトの説明に付いては 項14.4.4.9. 「共有メモリ接続」 を参照してください。

• [SCI]:クラスタノード間のスケーラブル コヒーラント インターフェースの接続を定義します。そのような接続に MySQL Sluster のディストリビューションには含まれていないが、自由に入手できるソフトウェアと特定のハードウェアが必要です。SCI のインターコネクトに関する詳細は 項14.4.4.10. 「SCI トランスポート接続」 を参照してください。

• 各実行ファイルにはそれ自身のコマンドラインのオプションがあり、起動時にマネジメント サーバーを指定します。(それぞれの実行ファイルについてはその説明書を参照してください。)

• 接続文字列をマネジメント サーバー my.cnf ファイルの [mysql_cluster] セクションに置くことで接続文字列をクラスタのすべてのノードに一度に設定することもできます。

• 以前のバージョンへの互換性につい打ては、同じ構文を使用して他の 2 つのオプションが利用できます。

  1. NDB_CONNECTSTRING 環境変数を設定して接続文字列を含みます。

  2. 各実行ファイルに接続文字列を書きそれを Ndb.cfg 名のテキスト ファイルに入れこのファイルを実行ファイルの起動ディレクトリに入れます。

  しかし、これらは現在あまり利用されていないため新しいインストールには使用されません。

• Id

  これは整数値で、設定ファイルのホスト コンピュータを参照するために使用します。この ID はノード ID とは同じではありません。

• HostName

  これはコンピュータのホスト名あるいは IP アドレスです。

• Id

  クラスタの各ノードにはそれぞれ一意の ID があり、1 〜63 の整数値で表されます。この ID はすべての内部のクラスタ メッセージでノードを示すために使用されます。

• ExecuteOnComputer

  これは config.ini ファイルの [COMPYUTER] セクションで定義されたコンピュータの中の 1 台の コンピュータの id セットの意味します。

• PortNumber

  これはポート番号でこれによりマネジメント サーバーが設定要求およびマネジメント コマンドを受け取ります。

• HostName

  このパラメータを指定するとマネジメント ノードが常駐するコンピュータのホスト名を定義します。localhost 以外のホスト名を指定するには、このパラメータあるいは ExecuteOnComputer のいずれかが必要です。

• LogDestination

  このパラメータはクラスタのログインの情報をどこに送るかを指定します。この点に関しては ? FILE をデフォルトとして CONSOLE、SYSLOG? および FILE の 3 つのオプションがあります。

  • CONSOLE はログをstdout に出力します。

    CONSOLE
    

  • SYSLOG はログを syslog ファシリティに送ります。可能な値はこれら auth、authpriv、cron、daemon、ftp、kern、lpr、mail、 news、syslog、user、uucp、local0、local1、local2、local3、local4、local5、local6 あるいは local7 の内の１つです。

    注:すべてのファシリティが必ずしもすべてのオペレーティング システムでサポートされる必要はありません。

    SYSLOG:facility=syslog
    

  • FILE クラスタのログ出力を同じマシンの通常のファイル送ります。以下の値を指定できます。

    • filename:ログ ファイルの名前です。

    • 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

  このパラメータはどのノードがアービトレーターとしての役割を果たすかを定義します。MGM ノードおよび SQL ノードのみがアービトレーターになれます。ArbitrationRank は以下の値の １ つを取ることができます。

  • 0: このノードはアービトレーターとしては使用されません。

  • 1: このノードは優先度が高く、つまり、低い優先度のノードに対してアービトレーターとしての優先されます。

  • 2: は優先度の低いノードを意味し、優先度の高いノードがその目的に利用できないときにのみアービトレーターとして使用されます。

  通常、マネジメント サーバーはその ArbitrationRank で 1 (デフォルトの値) でアービトレーターとして設定され、ＳＱＬ ノードは 0 に設定されます。

• ArbitrationDelay

  マネジメント サーバーのアービトレーションの要求への応答をミリセカンドの数値で遅延させる整数値ですデフォルトではこの値は 0 です。通常はこの値を変更する必要はありません。

• DataDir

  これはマネジメント サーバーの出力ファイルを格納するディレクトリを指定します。これらのファイルはクラスタ ログ　ファイル、プロセス出力ファイル、およびデーモンのプロセス ID (PID) ファイルを含んでいます。(ログ ファイルでは、このロケーションはこの項で以前説明したように FILE パラメータを LogDestination に設定すると書き換えらえます。

  このパラメータのデフォルトの値はディレクトリで、その中に ndb_mgmd があります。

• ExecuteOnComputer あるいは HostName のいずれかは、[NDBD] セクションで定義される必要があります。

• パラメータ NoOfReplicas はそれがすべてのクラスタ データ ノードに共通なため、 [NDBD DEFAULT] セクションで定義する必要があります。

• Id

  これはすべてのクラスタの内部メッセージのノードのアドレスとして使用されるノード ID です。これは 1 〜 63 までの整数です。クラスタの各ノードは一意の ID を持つ必要があります。

• ExecuteOnComputer

  これは [ＣＯＭＰＵＴＥＲ] セクションで定義されたコンピュータの ld セットです。

• HostName

  このパラメータを指定するとデータ ノードが常駐するコンピュータのホスト名を定義します。localhost 以外のホスト名を指定するには、このパラメータあるいは ExecuteOnComputer のいずれかが必要です。

• ServerPort (旧式)

  クラスタの各ノードは他のノードに接続するためにポートを使用しています。このポートはまた接続設定段階の非 ＴＣＰ トランスポーターに使用されています。デフォルトのポートは同じコンピュータ上の 2 つのノードが同じポート番号を受信しないようにダイナミックに割り当てられているため、通常このパラメータの値を指定する必要はありません。

• NoOfReplicas

  このグローバル パラメータは [NDBD DEFAULT] セクションでのみ設定され、クラスタに保持された各テーブルのレプリカを番号を定義します。このパラメータはまたノード グループのサイズを指定します。ノード グループはすべて同じ情報を保持した一連のノードです。

  ノード グループは明示的に形成されます。最初のノード グループは最も低いノード ID を持つデータ ノードのセットで形成され、次のノード グループは次に最も低いノード ＩＤ のデータ セットで形成されます。参考例として、NoOfReplicas が 2 に設定された 4 つのデータ ノードがあるとします。その 4 つのデータ ノードのノード ID を 2, 3, 4 および 5 とします。すると最初のノード グループはノードの 2 および 3 から形成され、2 番目のノード グループのノードは 4 と 5 になります。同じノード グループのノードは同じコンピュータには使用しないようにクラスタを設定する必要があります。というのは、１ つのハードウェアの不具合がクラスタ全体のクラッシュにつながるからです。

  ノード ID が提供されていない場合、データノードの順序はノード グループの決定要素になります。明示の割り当てがされるされないに拘わらす、それらはマネジメント クライアントの SHOW ステートメントの出力に表示されます。

  NoOfReplicas にはデフォルトの値はありません。最大の可能な値は 4 です。

  重要このパラメータの値はクラスタのデータ ノード数に同等に分けられる必要があります。例えば、2 つのデータ ノードがあるとすると、NoOfReplicas は 1 あるいは 2 のいずれかに同じで、2/3 および 2/4 は両方とも機能的な値になります。4 つのデータ ノードがあるとすると、NoOfReplicas は 1、2、あるいは 4 に同じになります。

• DataDir

  このパラメータはトレース ファイル、pid ファイルおよびエラーファイルを格納するディレクトリを指定します。

• FileSystemPath

  このパラメータはメタデータ、REDO ログ、UNDO ログおよびデータ ファイルに作成されたすべてのファイルを格納するディレクトリを指定します。デフォルトは DataDir で指定されたディレクトリです。注:このディレクトリは ndbd プロセスが実行される前に存在する必要があります。

  MySQL Cluster の推奨されるディレクトリの階層には /var/lib/mysql-cluster が含まれます。そこでノードのファイル システムのディレクトリが作成されます。このサブディレクトリの名前にはノード ID が含まれます。例えば、ノード ID が 2 の場合、このサブディレクトリの名前は ndb_2_fs となります。

• BackupDataDir

  このパラメータはバックアップを格納するディレクトリを指定します。省略された場合、デフォルトのバックアップ ロケーションは FileSystemPath パラメータで指定されたロケーションの下のBACKUP の名前のディレクトリになります。(上記参照。)

• DataMemory

  このパラメータはデータベースのレコードを保持するスペース（バイト表示）を定義します。この値で指定される全体量はメモリで割り当てられます。ですからマシンにそれを収容できる十分な物理メモリがあることが非常に重要です。

  DataMemory で割り当てられたメモリは実際のレコードおよびインデックスの保持に使用されます。各レコードには 16 バイトのオーバーヘッドがあります。各レコードはそれが 32KB ページで 128 バイト ページのオーバーヘッドに保持されるのでさらに使用できないスペースが増えます。 (下参照）。各レコードは 1 ページにしか保存されないので、各ページ毎に使用できないスペース少しずつあります。

  MySQL 5.1 の可変サイズ テーブル属性により、データは DataMemory から割り当てられた個別のデータページに保持されます。可変長レコードには 4 バイトのオーバーヘッドの固定サイズ部分を使用し可変サイズ部分を参照します。可変サイズ部分には 2 バイトのオーバーヘッドと属性毎に 2 バイトのオーバーヘッドがあります。

  最大のレコード サイズは現在 8052 バイトです。

  DataMemory で定義されたメモリ スペースは、レコード毎に 10 バイトを使用する順序付けされたインデックスの保持にも使用されます。各テーブル行は順序づけされたインデックスで表されます。ユーザー間での共通のエラーはすべてのインデックスは IndexMemory で割り当てられたメモリに保持されるためと想定できるが、これがすべてではありません。プライマリ キーと一意のハッシュ インデックスのみがこのメモリを使用します。順序付けされたインデックスは DataMemory で割り当てられたメモリを使用します。しかし、プライマリ キーあるいは一意のハッシュ インデックスを作成すると インデックス作成ステートメントの USING HASH を指定しない限り同じキーで順序付けされたインデックスも作成されます。これはマネジメント クライアントの ndb_desc -d db_name table_name を実行してと検証できます。

  DataMemory で割り当てられたメモリ スペースはテーブル フラグメントに割り当てられた 32KB のページで構成されます。各テーブルはクラスタにデータ ノードがあるため通常同じ数のフラグメントにパーテッションされます。このように、各ノードに対して、NoOfReplicas で設定された同数のフラグメントがあります。

  ページが割り当てられると、テーブルを削除する以外にフリーページのプールに戻すことは現在できません。(このことは DataMemory ページが一度所定のテーブルに割り当てられると他のテーブルで使用できないということを意味しています。)すべてのレコードが他の生きたノードから空のパーティッションに挿入されるため、ノードのリカバリを実行するとパーテッションを圧縮します。

  DataMemory メモリ スペースはまた UNDO 情報を含んでいます。更新毎に、変更されないレコードのコピーが DataMemory で割り当てられます。順序付けされたテーブル インデックスに各コピーの参照があります。一意のハッシュ インデックスは一意のインデックスのカラムが更新されたときのみ更新されます。その場合、インデックス テーブルでの新しいエントリが挿入されその挿入によって古いエントリは削除されます。このため、クラスタを使用したアプリケーションの大きなトランザクションを扱うのに十分なメモリを割り当てることも重要です。いずれにしても、いくつかの大きなトランザクションを実行することは、以下の理由によって多くの小さなトランザクションを実行するのに対して優位性がある訳ではありません。

  • 大きなトランザクションは小さなトランザクションより早い訳ではない

  • 大きなトランザクションは失われるオペレーション数が増えるので、トランザクションが失敗した場合には繰返す必要がある

  • 大きなトランザクションは多くのメモリを使用する

  DataMemory のデフォルトの値は 80MBです。最小は 1 MB です。最大サイズはありませんが、現実的には制限に達したときプロセスがスワップしないように最大サイズを決める必要があります。制限はマシンで利用できる物理 RAM の容量およびオペレーティング システムがプロセスの実行に必要な容量によって決まります。32 ビットのオペレーティング システムは一般的にはプロセス毎では 2?4GB ですので、64 ビットのオペレーティング システムはさらに多くのメモリを使用できます。この理由により大きなデータベースの場合、64 ビットのオペレーティング システムの使用が望まれます。

• IndexMemory

  このメモリは MySQL のハッシュ インデックスに使用されるストレージ量を管理します。ハッシュ インデックスは常にプライマリ キーのインデックス、独自のインデックス、および独自の制約に使用されます。プライマリ キーおよび独自のインデックスを定義する際、2 つのインデックスが作成され、その １ つがすべての tuple アクセスおよびロックの取扱いに使用されるハッシュのインデックスです。それはまた独自の制約の強化にも使用されます。

  ハッシュ インデックスのサイズはレコード毎に 25 バイトで、それにプライマリ キーのサイズが加わります。32 バイト以上のプライマリ キーには別に 8 バイト追加されます。

  IndexMemory のデフォルトの値は 18MB です。最低は 1MB です。

• StringMemory

  このパラメータは例えばテーブル名などの文字列に使用されるメモリ容量に割り当てを決定し、config.ini　の [NDBD] あるいは [NDBD DEFAULT] セクションで指定されます。0 および 100 の間の値は最大のデフォルトの値のパーセントで、テーブル数、最大のテーブル名のサイズ、最大の .FRM ファイル、MaxNoOfTriggers、最大のカラム名のサイズ、および最大のデフォルトのカラムの値などを含む多くの要素に基づいて算出されます。一般的には1000 のテーブルを持つ MySQL Cluster の場合の最大のデフォルト値はおよそ 5 MB にすると安全です。

  100 より大きい値はバイト数を意味します。

  デフォルトの値が 5 ? の場合、つまりデフォルトの最大の 5 パーセントあるいはおよそ 5 KB です。(これが MySQL Cluster の以前のバージョンからの変更点です。)

  ほとんどの環境で、そのデフォルト値で十分ですが、非常に大きなクラスタ テーブル （1000 あるいはそれ以上） の場合、エラー 773 が出る場合があります。文字列メモリで、ＳtringMemory config のパラメータを変更してください。恒久的なエラー：スキーマのエラー で、この場合この値を｢増やします。25 (25 パーセント) でも良いでしょう。これですべてのしかも最も極端が場合のエラーの再発を妨げる必要があります。

• MaxNoOfConcurrentTransactions

  クラスタのアクテイブなそれぞれトランザクションはクラスタ ノードの 1 つにレコードを持つ必要があります。協調的なトランザクションはノード間で実行されます。クラスタのトランザクション レコードの合計数はクラスタの所定のノードのトランザクション数にノードを乗算した数になります。

  トランザクション レコードは個々の MySQL サーバーに割り当てられます。通常は、少なくてもクラスタのテーブルを使用している少なくても １ つのトランザクション レコードが接続毎に割り当てられます。このため、クラスタのトランザクション レコード数がクラスタの すべての MySQL サーバーに同時接続している数よりも多いことを確認する必要があります。

  このパラメータは全てのクラスタ ノードに対し同じ値を設定する必要があります。

  このパラメータを変更することは安全ではなく、変更することによってクラスタがクラッシュする場合があります。ノードがクラッシュすると、ノードの １ つ (実際は一番最後までクラッシュしないで残ったノード） がクラッシュしたときにクラッシュしたノードで進行中のすべてのトランザクションの状態に戻します。ですからこのノードが失敗したノードの出来るだけ多くのレコードを持っていることが重要です。

  デフォルトの値は 4096 です。

• MaxNoOfConcurrentOperations

  このパラメータの値をトランザクション数やサイズに基づいて調整することはいい考えです。少数のオペレーションをそれぞれあまり多くのレコードを使用しないでトランザクションを実行するときには、このパラメータを高く設定する必要はありません。多くのレコードを含む大きなトランザクションを実行するするときにはこのパラメータを高く設定する必要があります。

  レコードは各トランザクション毎に記録され、トランザクション コーディネーターおよび実際の更新が行われるノードでクラスタのデータを更新します。このレコードにはロールバック、ロック キュー、およびその他の目的のための UNDO レコードの検索に必要なステート情報が含まれます。

  このパラメータはクラスタのデータ ノード数で除算した、トランザクションで同時に更新されるレコードの数に設定する必要があります。例えば、4 つのデータ ノードを持ち 1,000,000 の同時更新をトランザクションで処理するクラスタでは、この値を 1000000 / 4 = 250000 に設定する必要があります。

  ロックを設定するクエリの読み込みでもオペレーション レコードが作成されます。ノードへの配布が完全でない場合にそれに対処するためにいくつかの予備のスペースが個々のノード内で割り当てられます。

  クエリが独自のハッシュ インデックスを使用する場合、 トランザクションで実際にレコード毎に使用される 2 つのオペレーション レコードがあります。最初のレコードはインデックス テーブルの読み込みを行い、2 番目はベース テーブルのオペレーションを処理します。

  デフォルトの値は 32768 です。

  このパラメータは個別に設定される 2 つの値を扱います。これらの最初の値はトランザクション コーディネーターに配置するトランザクション レコード数を指定します。2 番目の値はデータベースに対してローカルにするオペレーション レコード数を指定します。

  8 つのノードを使用したクラスタで実行される非常に大きなトランザクションのトランザクション コーディネーターにはトランザクションでの読み込み、更新、削除に相当するオペレーション レコードが必要です。しかし、オペレーション レコードは 8 つのノードすべて使用されます。このように、システムを １ つの非常に大きなトランザクションに設定する必要がある場合には、2 つの部分を個別に設定するほうが良いでしょう。MaxNoOfConcurrentOperations はトランザクション コーディネーターのノード部分のオペレーション レコード数の算出に使用されます。

  オペレーション レコードにはメモリ要件を考慮に入れることも重要です。これらはレコード毎に約 1KB 使用します。

• MaxNoOfLocalOperations

  デフォルトでは、このパラメータは 1.1 × MaxNoOfConcurrentOperations で算出されます。これはトランザクションがそれほど大きくない多くのトランザクションを同時に行うシステムに向いています。一度に非常に大きなトランザクションを扱う必要がある場合には、このパラメータを明示的に指定してデフォルト値をオーバーライドするのがいいでしょう。

• MaxNoOfConcurrentIndexOperations

  独自のハッシュ インデックスを使用したクエリでは、オペレーション レコードの別のテンポラリ セットがクエリの実行フェーズで使用されます。このパラメータセットはレコードのプール サイズを設定します。このように、レコードはクエリの一部を実行中にのみ割り当てられます。この部分が実行されるとすぐ、レコードがリリースされます。失敗や実行の処理に必要なステートは通常おオペレーション レコードで扱われ、プール サイズはパラメータ MaxNoOfConcurrentOperations で設定されます。

  このパラメータのデフォルトの値は 8192 です。ごく稀に独自のハッシュ インデックスを使用した極端に高い並列仕様においてはこの値を上げる必要があります。DBA がクラスタに高度な並列が要求されないことを確認できる場合、小さい値が可能でメモリを節約できます。

• MaxNoOfFiredTriggers

  MaxNoOfFiredTriggers のデフォルトの値は 4000 です。これで殆どの状態に十分です。DBA がクラスタの並列仕様が高くないと確認できた場合、場合によっては値を下げることもできます。

  独自のハッシュ インデックスに影響を及ぼすオペレーションが実行されるとレコードが作成されます。独自のハッシュ インデックスでテーブルにレコードを挿入あるいは削除するあるいは独自のハッシュ インデックスの一部のカラムを更新するとインデックス テーブルの挿入や削除が無効になります。その結果のレコードは完了するためにオペレーションを無効にした元のオペレーションを待つ間にこのインデックス テーブルのオペレーションを代わりをするために使用されます。このオペレーションは短命ですが、それでも一連の独自のハッシュ インデックスのを含むベース テーブルで多くの並列書き込みオペレーションに対応するプールで多数のレコードを必要とします。

• TransactionBufferMemory

  このパラメータで影響を受けたメモリはインデックス テーブルの更新や独自にインデックスを読み込むときに無効になったオペレーションの追跡に使用されます。このメモリはこれらのオペレーションのキーおよびカラムの情報を保持するために使用されます。このパラメータの値をデフォルトの値からの変更を必要とするケースは非常に稀です。

  TransactionBufferMemory のデフォルトの値は 1MB です

  通常の読み込み書き込みのオペレーションは同様のバッファを 1 つ使用します。その使用はもっと短命です。コンパイル時間のパラメータ ZATTRBUF_FILESIZE (ndb/src/kernel/blocks/Dbtc/Dbtc.hpp に表示) は 4000 × 128 バイト (500KB) に設定します。キー情報の同様のバッファは、ZDATABUF_FILESIZE (Dbtc.hpp に表示) は 4000 × 16 = 62.5KB のバッファ スペースを含みます。Dbtc はトランザクションのコーディネーションを扱うモジュールです。

Dblqh モジュール (ndb/src/kernel/blocks/Dblqh/Dblqh.hpp にあります) に読み込みと更新に影響を及ぼす追加の [NDBD] パラメータがあります。これらはデフォルトで 10000 × 128 バイト (1250KB) および ZDATABUF_FILE_SIZE 、デフォルトで 10000*16 バイト (およそ 156KB) のバッファ スペースに設定された ZATTRINBUF_FILESIZE を含みます。現在までのところ、これらのコンパイル時間制限を増やすべきだという弊社のユーザーおよび弊社の広範なテストでの結果もありません。

• MaxNoOfConcurrentScans

  このパラメータはクラスタで実行される並列スキャン数の管理のために使用されます。各トランザクション コーディネーターはこのパラメータに定義された数の並列スキャンを処理します。各スキャンのクエリは並列の全てのパーティションをスキャンすることで実行できます。各パーティション スキャンはパーティションがあるノードのスキャン レコード、このパラメータの値であるレコード数にノード数を乗算したレコード数を使用します。クラスタは MaxNoOfConcurrentScans スキャンをクラスタの全てのノードと同時に維持する必要があります。

  スキャンは実際には 2 つのケースで実行されます。この最初のケースはクエリを扱うハッシュあるいは順序付けされたインデックスが存在しないとき、クエリがテーブルのフル ャンを実行することで実行されます。2 番目のケースはクエリをサポートするハッシュ インデックスが無くて順序付けされたインデックスがある場合にスキャンが実行されます。順序付けされたインデックスを使用するということは並列の範囲スキャンを実行することを意味します。その順序はローカルのパーティッションにのみ維持されるので、すべてのパーティッションにインデックスのスキャンが行う必要があります。

  MaxNoOfConcurrentScans のデフォルトの値は 256 です。最大値は 500 です。

  このパラメータはトランザクションのコーディネーターでの可能なスキャン数を指定します。ローカル スキャン数が提供されていない場合、MaxNoOfConcurrentScans およびシステムのデータ ノード数の積にによって計算されます。

• MaxNoOfLocalScans

  多くのスキャンが完全に並列化されない場合にローカルのスキャン レコード数を指定します。

• BatchSizePerLocalScan

  このパラメータは多くの同時スキャン オペレーションを扱うロック レコード数の計算に使用されます。

  デフォルトの値は 64 です。この値は SQL ノードで定義された ScanBatchSize と強い関連があります。

• LongMessageBuffer

  これは内部のバッファーで個々のノード内およびノード間でメッセージを渡すために使用されます。これを変更する必要は殆ど考えられませんが、設定はできます。デフォルトでは 1MB に設定されます。

• NoOfFragmentLogFiles

  このパラメータはノードの REDO (やり直し） ログ ファイル数を設定し、この様にREDO ロギングにスペースが割り当てられます。REDO ログ ファイルはリングに環状に構成されますので、そのセットの最初および最後のログ ファイル （それぞれ 「頭」 および 「尻尾」 ログ ファイルとも呼ばれる）が一致しないように設定することが非常に重要です。これらが互いにあまりも近づくと、新しいログ レコードのスペースが足りないためにノードが更新に関わるすべてのトランザクションを中断させる場合があります。

  REDO ログ ファイルはそのログ レコードが挿入されてから 3 回のローカル チェックポイントが完了するまで削除できません。チェックポイントの頻度はこの章の別の場所で説明したように、それ自身の一連の設定パラメータで決定されます。

  これらのパラメータの相互作用およびその設定については 項14.4.6. 「ローカル チェックポイントのパラメータの設定」 で説明しています。

  デフォルトのパラメータ値は 8 ですので 8 セットの 4 16MB ファイルで合計 512MB になります。換言すれば、REDO ログ スペースは 64MB のブロックに割り当てられる必要があります。非常に多くの更新が要求される場合には、REDO ログに十分なスペースを提供するには NoOfFragmentLogFiles の値は 300 あるいはそれ以上に高く設定する必要があります。

  チェックポイントが遅く、データベースへの書き込み数がログ ファイルが一杯になりログの尻尾がリカバリの悪化なしにカットできなくなるほど多い場合、すべての更新トランザクションは内部のエラーコード 410 (Out of log file space temporarily) によって中断されます。この状態はチェックポイントが完了しログの尻尾が前進できるようになるまで続きます。

  重要このパラメータは 「稼働中」 には変更できません。 --initial を使用してノードを再起動する必要があります。この値をクラスタの稼働中の変更を希望する場合には、動作中のノードを再起動します。

• MaxNoOfOpenFiles

  このパラメータはオープン ファイルに内部スレッド割り当て上限を設定します。このパラメータの変更が必要な状況が発生した場合にはバグ として報告お願いします。

  デフォルトの値は 40 です。

• MaxNoOfSavedMessages

  このパラメータは古い値が書き換えられるまでのトレース ファイルの最大数を設定します。トレース ファイルは、どのような理由であれ、ノードがクラッシュすると生成されます。

  デフォルトは 25 トレース ファイルです。

• MaxNoOfAttributes

  クラスタで定義される属性数を定義します。

  デフォルトの値は 1000 で、最大の可能な値は 32 です。最大は 4294967039。すべてのメタデータはサーバーで完全にレプリケート （複製） されるため各属性はノード毎に約 200 バイトのストレージを使用します。

  MaxNoOfAttributes を設定する前に、将来実行を希望するであろう ALTER TABLE ステートメントを事前に用意することが重要です。これは クラスタ テーブルで ALTER TABLE を実行中に、元のテーブル 3 倍の属性が使用されるからです例えば、テーブルが 100 の属性を必要し、その変更を後で希望する場合、MaxNoOfAttributes の値を 300 に設定する必要があります。希望するすべてのテーブルを問題無く作成できるとして、経験則では念のために一番大きなテーブルで 2 倍の属性を MaxNoOfAttributes に追加します。パラメータを設定した後に実際の ALTER TABLE を試してこの数字が十分であるか検証できます。その数字でうまくいかない場合、MaxNoOfAttributes を元の値の数倍に増やしてももう一度試してみます。

• MaxNoOfTables

  各テーブル、独自のハッシュ インデックス、および順序付けられたインデックスにテーブル オブジェクトを割り当てられます。このパラメータは全体としてクラスタにテーブル オブジェクトの最大数を設定します。

  BLOB のデータ タイプを持つ各属性に対して、ほとんどの BLOB データを保持するために予備のテーブルが使用されます。これらのテーブルはテーブルの合計数を決める場合に考慮する必要があります。

  このパラメータのデフォルトの値は 128 です。最小は 8 で最大は 1600 です。各テーブル オブジェクトはおよそノード毎に 20KB を使用します。

• MaxNoOfOrderedIndexes

  クラスタの順番付けされたインデックスに対し、何にインデックスするかおよびそのストレージ セグメントを記述したオブジェクトが 1 つ割り当てられます。デフォルトでは、そのように定義された各インデックスはまた順番付けされたインデックスを定義します。それぞれの独自のインデックスおよびプライマリ キーは順序付けされたインデックスおよびハッシュ インデックスの両方を持っています。

  このパラメータのデフォルトの値は 128 です。各オブジェクトはノード毎におよそ 10KB のデータを使用します。

• MaxNoOfUniqueHashIndexes

  プライマリ キー以外の各独自のインデックスに対して、独自のキーをインデックスの付いたテーブルのプライマリ キーマップする特別なテーブルが割り当てられます。デフォルトでは、順序付けされたインデックスもまた各独自のインデックスに定義されます。これを防ぐには、独自のインデックスを定義する際に USING HASH オプションを指定する必要があります。

  デフォルトの値は 64です。各インデックスはノード毎におよそ 15KB 使用します。

• MaxNoOfTriggers

  内部のトリガの更新、挿入、および削除が各独自のハッシュ インデックスに割り当てられます。(これは 3 つのトリガが各独自のハッシュ インデックスに作成されることを意味します。)しかし、順序付けされた インデックスにはシングルのトリガ オブジェクトのみ必要です。バックアップもまた 3 つのトリガ オブジェクトをクラスタの各通常のテーブルに使用します。

  クラスタ間のレプリケーションもまた内部のトリガを使用します。

  このパラメータはクラスタのトリガ オブジェクトの最大数を設定します。

  デフォルトの値は 768 です。

• MaxNoOfIndexes

  このパラメータは MySQL 5.1 は使用されない方向にあります。代わりに MaxNoOfOrderedIndexes および MaxNoOfUniqueHashIndexes を使用する必要があります。

  このパラメータは独自のハッシュ インデックスのみで使用されます。このプールではクラスタで定義された各独自のインデックスに対しレコードが 1 つ必要です。

  このパラメータのデフォルトの値は 128 です。

• LockPagesInMainMemory

  Solaris および Linux を含む多くのオペエーティング システムで、プロセスをメモリにロックしてディスクへのスワップを回避することができます。これはクラスタのリアルタイム特性を保証するために使用されます。

  MySQL 5.1.15 以降の場合、このパラメータは 0、1、あるいは 2 のいずれかの整数値を取ります。それぞれ以下の役割があります。

  • 0: ロックを無効にします。これはデフォルトの値です。

  • 1: メモリをプロセスに割り当てた後にロックを実行します。

  • 2: メモリをプロセスに割り当てる前にロックを実行します。

  以前は、このパラメータは Boolean　でした。0 あるいは false はデフォルトに設定で、ロックを無効にしました。1 あるいは true はメモリが割り当てられたあとのプロセスのロックを有効にしました。重要MySQL 5.1.15 以降では、true あるいは false をもはやこのパラメータに使用できません。以前のバージョンからアアップグレードする場合には、その値を 0、1、あるいは 2 に変更する必要があります。

• StopOnError

  このパラメータはエラーが発生した場合に ndbd プロセスを終了するかあるいは自動的に再起動させるかを指定します。

  この機能はデフォルトで有効になっています。

• Diskless

  MySQL クラスタのテーブルを テーブルがディスクにチェックポイントされずロギングも発生しないDisklessに指定できます。そのようなテーブルは主メモリにのみ存在します。ディスク無しのテーブルを使用することによってそれらのテーブルのテーブルあるいはレコードのどちらもクラッシュの影響を受けないことを意味しています。.しかし、ディスク無しモードを起動中に、ディスク無しコンピュータで ndbd を実行できます。

  重要この機能によりクラスタ 全体 をディスク無しモードで稼動できます。

  この機能を有効にすると、クラスタのオンラインバックアップは無効になります。さらに、クラスタの部分的な起動が出来なくなります。

  Diskless はデフォルトで無効になっています。

• RestartOnErrorInsert

  この機能はデバッグ バージョンを作成中にのみアクセスでき、そこでエラーをコードの個々のブロックにテストの一部として挿入できます。

  この機能はデフォルトで無効になっています。

• TimeBetweenWatchDogCheck

  主スレッドの無限ループのある地点でのスタックを避けるために、「監視」 スレッドが主スレッドをチェックします。このパラメータはチェック間のミリセカンド数を指定します。プロセスが 3 回のチェックの後でも同じ状態が続くようであれば、監視スレッドがそれを停止します。

  パラメータは試験用あるいはローカル条件を採用するために簡単に変更できます。それは特にノード単位で指定する意味もないのだがノード単位で指定できます。

  デフォルトのタイムアウトは 4000 ミリセカンド (4 秒) です。

• StartPartialTimeout

  このパラメータはクラスタの初期化ルーチンが起動される前のクラスタのすべてのノードが起動するまでの待機時間を指定します。このタイムアウトは必要に応じてクラスタの部分的起動を避けるために使用されます。

  デフォルトの値は 30000 ミリセカンド(30 秒) です。0 でタイムアウトを無効にします。この場合クラスタはすべてのノードが利用できる段階で起動します。

• StartPartitionedTimeout

  クラスタが StartPartialTimeout ミリセカンドの待機後に起動の用意が出来ても、まだパーティションの状態である場合、クラスタはこのタイムアウトが経過するまで待ちます。

  デフォルトのタイムアウトは 60000 ミリセカンド (60 秒) です。

• StartFailureTimeout

  データノードがこのパラメータで指定された時間内にその起動シーケンスを完了できない場合、そのノードの起動は失敗します。このパラメータを 0 (デフォルトの値) に設定するとデータ ノードのタイムアウトが適用されないことを意味します。

  0 以外の値の場合、このパラメータはミリセカンドで測定されます。極端い大きな量のデータを含むデータ ノードには、このパラメータを大きくします。例えば、数ギガ バイトのデータを含むデータノードの場合、ノードの再起動を実行するには 10?15 分 (つまり、600000 から 1000000 ミリセカンド) が必要になります。

• HeartbeatIntervalDbDb

  失敗したノードを見つける主な方法の １ つにハートビートを使用する方法があります。このパラメータはハートビート信号の送受信の頻度を指定します。続けて 3 回ハートビート インターバルに失敗した場合、そのノードはデッドを宣言されます。このように、ハートビート メカニズムを使用した不具合発見の最大の回数はハートビート インターバルの 4 倍です。

  デフォルトのハートビート インターバルは 1500 ミリセカンド (1.5 秒) です。.このパラメータを大幅に変更したりまたはノード間で大きく違わないようにします。1 つのノードが 5000 ミリセカンドを使用しそれを監視するノードが 1000 ミリセカンドを使用した場合、明らかにノードは直ちにデッドを宣言されます。このパラメータはオンラインのソフトウェアのアップグレード時に変更できますが、ほんの小さな増分だけです。

• HeartbeatIntervalDbApi

  各データノードはハートビート信号を各 MySQL サーバー (SQL ノード) に送って接続されていることを確認します。MySQL サーバーがハートビートを時間内に送信できない場合 「デッド」 を宣言され、その場合すべての実行中のトランザクションは完了してすべてのリソースがリリースされます。SQL ノードは以前の MySQL インスタンスで始められたすべての操作が完了するまで再接続できません。この測定の 3 回のハートビート基準は HeartbeatIntervalDbDb の説明と同じです。

  デフォルトのインターバルは 1500 ミリセカンド (1.5 秒) です。インターバルは個々のデータ ノード別にすることも出来ます。というのは、各ノードは接続された MySQL サーバーを監視し、他のすべてのデータ ノードから独立しているからです。

• TimeBetweenLocalCheckpoints

  このパラメータはその例外で新しいローカルチェックポイントの起動までの待機時間を設定しません。これはむしろ、ローカルチェックポイントは比較的少ない更新が実行されるクラスタでは実行されないことを確認するために使用されます。更新回数が多い多くのクラスタでは、おそらく新しいローカル チェックポイントは前のチェックポイントが完了すると直ぐに開始されるからです。

  前のローカル チェックポイントが開始されてから実行されたすべての書き込み操作のサイズが追加されます。このパラメータもその例外で 4 バイトの単語の基数 2 対数で指定されますので、デフォルト値の 20 は 4MB (4 × 2²⁰) の書き込み操作を意味し、21 は 8MB で、8 GB の書き込み操作に相当する最大値 31 まで続きます。

  クラスタのすべての書き込み操作はが一緒に追加されます。TimeBetweenLocalCheckpoints を 6 あるいはそれ以下に設定することはローカルのチェックポイントが、クラスタの負荷に関係なく休みなく継続的に実行されることを意味します。

• TimeBetweenGlobalCheckpoints

  トランザクションがコミットされると、データがミラーされているすべてのノードの主メモリでコミットされます。しかし、トランザクションのルグ レコードはそのコミットの一部としてディスクにフラッシュされません。この振る舞いの背後にある論法はトランザクションを少なくとも 2 台の自律型ホスト マシン上で成功裏に実行するには持続性に於ける合理的な基準を満たす必要があるからです。

  最悪の場合?クラスタの完全なクラッシュ?でも適切に処理されることを確認することも重要です。これを保証するには、所定のインターバル内に実行されるすべてのトランザクションをグローバル チェックポイントに設定すると、それがディスクにフラッシュされコミットされたとトランザクションのセットとして考慮されます。換言すれば、コミット プロセスの一部として、トランザクションがグローバル チェックポイントに組み入れられます。後でこのグループのログ レコードがディスクにフラッシュされ、トランザクション グループ全体がクラスタのすべてのコンピュータ上のディスクでコミットされます。

  このパラメータはグローバル チェックポイント間のインターバルを定義します。デフォルトは 2000 ミリセカンドです。

• TimeBetweenInactiveTransactionAbortCheck

  タイムアウトの処理はこのパラメータで指定されたインターバル毎に各トランザクションのタイマーを一度チェックすることで実行されます。この様に、このパラメータを 1000 ミリセカンドに設定すると、すべてのトランザクションは 1 秒毎にタイムアウトをチェックします。

  デフォルトの値は 1000 ミリセカンド (1 秒) です。

• TransactionInactiveTimeout

  このパラメータはトランザクションが中断される前の同じトランザクションのオペレーション間に許容された最大の経過時間を表します。

  このパラメータのデフォルトはゼロ (タイムアウト無し) です。トランザクションのロックをあまり長くしないことを確認する必要のあるリアルタイムのデータベースでは、このパラメータは非常に小さい値に設定する必要があります。単位はミリセカンドです。

• TransactionDeadlockDetectionTimeout

  ノードがトランザクションに関わるクエリを実行するとき、そのノードは継続する前にクラスタの他のノードが応答するまで待ちます。応答の失敗は以下の理由のいずれかで起こります。

  • そのノードが 「デッド」状態にある

  • オペレーションがロック キュウーの状態にある

  • アクションの実行をリクエストしたノードが過負荷にある

  このタイムアウトのパラメータはトランザクション コーディネーターがトランザクションの中断にいたるまでの別のノードによるクエリを実行するまでの待機時間を示したもので、ノードの中断処理およびデッドロック検知の両方に重要です。その設定が高すぎるとデッドロックおよびノード中断を含む状態において望まない振る舞いを引き起こします。

  デフォルトのタイムアウトは 1200 ミリセカンド (1.2 秒) です。

• DiskSyncSize

  データをローカルのチェックポイント ファイルにフラッシュする前に保持するする最大バイト数です。

  デフォルトの値は 4M (4 メガバイト) です。

  このパラメータは MySQL 5.1.12 に追加されています。

• DiskCheckpointSpeed

  ローカル チェックポイント中に転送されるデータ量をバイト/秒で表したものです。

  デフォルトの値は 10M (10 メガバイト/秒) です。

  このパラメータは MySQL 5.1.12 に追加されています。

• DiskCheckpointSpeedInRestart

  ローカル チェックポイント中に再起動の操作の一部とし転送されるデータ量をバイト/秒で表したものです。

  デフォルトの値は 100M (100 メガバイト/秒) です。

  このパラメータは MySQL 5.1.12 に追加されています。

• NoOfDiskPagesToDiskAfterRestartTUP

  ローカル チェックポイント実行中に、アルゴリズムがすべてのデータページをディスクにフラッシュします。軽減策なしで単にそのように素早く行うのは過剰な負荷をプロセッサ、ネットワーク、およびディスクにかける場合があります。書き込み速度を管理するために、このパラメータは 100 ミリセカンド毎の書き込みページ数を指定します。ここでは 1 「 ページ」 は 8KB に定義されています。このパラメータは 80KB/秒単位で指定され、NoOfDiskPagesToDiskAfterRestartTUP を 20 の値に設定するとローカル チェックポイント中のデータページでのディスクへの書き込み速度 1.6MB/秒を意味します。この値には UNDO ログ レコードのデータ ページへの書き込みが含まれています。つまり、このパラメータはデータ メモリの書き込み数の制限を扱っています。インデックス ページの UNDO ログ レコードはパラメータ NoOfDiskPagesToDiskAfterRestartACC で処理されます。(インデックス ページに関する情報 IndexMemory は入力を参照してください。)

  要するに、このパラメータはローカル チェックポイントをどれだけ速く実施するかを指定します。それは NoOfFragmentLogFiles、DataMemory、および IndexMemoryと一緒に使用されます。

  これのパラメータのインターラクションおよびそれらの適切な値の選択肢に関する情報は、項14.4.6. 「ローカル チェックポイントのパラメータの設定」 を参照してください。

  デフォルトの値は 40 (3.2MB/秒のデータ ページ) です。

  注:このパラメータは MySQL 5.1.6 では使用頻度が下がっています。それはMySQL 5.1.12 およびそれ以降のバージョンは、 DiskCheckpointSpeed および DiskSyncSize を使用しているからです。.

• NoOfDiskPagesToDiskAfterRestartACC

  このパラメータは NoOfDiskPagesToDiskAfterRestartTUP と同じ単位を使用し同じ役割を果たしますが、インデックス メモリからインデックス ページの書き込み速度を制限します。

  このパラメータのデフォルト値は 20 (1.6MB/秒 のインデックス メモリ ページ）。

  注:このパラメータは MySQL 5.1.6 では使用頻度が下がっています。それはMySQL 5.1.12 およびそれ以降のバージョンは、 DiskCheckpointSpeed および DiskSyncSize を使用しているからです。.

• NoOfDiskPagesToDiskDuringRestartTUP

  このパラメータは NoOfDiskPagesToDiskAfterRestartTUP および NoOfDiskPagesToDiskAfterRestartACC と同じ役割を果たしますが、ノードが再起動されて時にノードで実行されるローカルのチェックポイントに関してのみそのように振舞います。ローカル チェックポイントは常にすべてのノードの再起動の一部として実行されます。ノードの再起動中にはノードで実行される作業量が少ないため他の場合より高速でディスクに書き込みできます。

  このパラメータはデータ メモリで書き込まれたページをカバーしています。

  デフォルトの値は 40 (3.2MB/秒) です。

  注:このパラメータは MySQL 5.1.6 では使用頻度が減っています。それはMySQL 5.1.12 およびそれ以降のバージョンは、 DiskCheckpointSpeedInRestart および DiskSyncSize を使用しているからです。.

• NoOfDiskPagesToDiskDuringRestartACC

  ノードの再起動時のローカル チェックポイント中にディスク書き込まれるインデックスのメモリ ページ数を管理します。

  NoOfDiskPagesToDiskAfterRestartTUP および NoOfDiskPagesToDiskAfterRestartACC と同じで、このパラメータ値は 100 ミリセカンド （80KB/秒） で書き込まれた 8KB ページを表します。

  デフォルトの値は 20 (1.6MB/秒) です。

  注:このパラメータは MySQL 5.1.6 では使用頻度が減っています。。それは MySQL 5.1.12 およびそれ以降のバージョンは、 DiskCheckpointSpeedInRestart および DiskSyncSize を使用しているからです。.

• ArbitrationTimeout

  このパラメータはデータ ノードのアービトレーターからアービトレーション メッセージへの応答の待機時間を指定します。この待機時間を過ぎると、ネットワークは切断されたものとみなされます。

  デフォルトの値は 1000 ミリセカンド (1 秒) です。

• LogLevelStartup

  プロセスの起動時に生成されたイベントのレポート レベルです。

  デフォルトのレベルは 1 です。

• LogLevelShutdown

  ノードの優雅なシャットダウンの一部として生成されたイベントのレポート レベルです。

  デフォルトのレベルは 0 です。

• LogLevelStatistic

  プライマリ キーの読み込み、更新数、挿入数、バッファ使用に関する情報など統計的なイベントのレポート レベルです。

  デフォルトのレベル 0 です。

• LogLevelCheckpoint

  ローカルおよびグローバル チェックポイントにより生成されたイベントのレポート レベル。

  デフォルトのレベルは 0 です。

• LogLevelNodeRestart

  ノード再起動時に生成されたイベントのレポート レベルです。

  デフォルトのレベルは 0 です。

• LogLevelConnection

  クラスタ ノード間の接続で生成されたイベントのレポート レベルです。

  デフォルトのレベル 0 です。

• LogLevelError

  全体としてクラスタによるエラーおよび警告により生成されたイベントのレポート レベルです。これらのエラーはノード障害に結びつくものではないが報告すべきだ思われるエラーです。

  デフォルトのレベルは 0 です。

• LogLevelInfo

  クラスタの一般的な状態に関する情報に生成されたイベントのレポート レベルです。

  デフォルトのレベルは 0 です。

• BackupDataBufferSize

  バックアップの作成においては、データをディスクに転送する 2 種類のバッファがあります。バックアップのデータ バッファはノード テーブルのスキャンにより記録されたデータを書き込みむために使用されます。このバッファが BackupWriteSize (以下参照) で指定されたレベルまで書き込まれると、そのページはディスクに転送されます。データをディスクに書き込んでいる間に、バックアップ プロセスではスペースがなくなるまでこのバッファに書き込みを続けます。スペースが無くなると、バックアップ プロセスがスキャンを停止し、ディスクへに書き込みによってメモリが増えてスキャンを継続できるようになるまで待ちます。

  デフォルトの値は 2MB です。

• BackupLogBufferSize

  バックアップ ログのバッファはバックアップの実行中にそれがすべてのテーブルの書き込みのログ生成に使用されることを除いてバックアップ データ バッファと同様の役割を果たします。同様の原則が、バックアップ ログ バッファにスペースが無いときを除いてバックアップ データ バッファと同じようにこれらの ページの書き込みに適用されて、そのバックアップは失敗します。その理由により、バックアップ ログ バッファのサイズはバックアップ中の書き込みの負荷を処理するだけの十分な大きさが必要です。項14.8.4. 「クラスタ バックアップの設定」 参照。

  このパラメータのデフォルトの値は殆どのアプリケーションに十分なものでなければなりません。実際のところ、バックアップの失敗はディスクへの書き込み速度が遅いよりはバックアップ ログ バッファが満杯になることによりよく起こります。ディスクのサブシステムがアプリケーションによる書き込み負荷対応するように設定されていない場合、クラスタは所定の作業を実行できなくなります。

  クラスタ ノードの設定ではディスクあるいはネットワーク接続をボトルネックにするよりはプロセッサがボトルネックになるように構成するほうが望まれます。

  デフォルトの値は 2MB です。

• BackupMemory

  このパラメータは単純に BackupDataBufferSize と BackupLogBufferSize の合計です。

  デフォルトの値は 2MB + 2MB = 4MB です。

  重要BackupDataBufferSize および BackupLogBufferSize の合計が 4MB 以上の場合、このパラメータは config.ini ファイルでその合計として明示的に設定される必要があります。

• BackupWriteSize

  このパラメータはバックアップ ログおよびバンクアップ データ バッファによってディスクに書き込まれたメッセージのデフォルトサイズを指定します。

  デフォルトの値は 32KB です。

• BackupMaxWriteSize

  このパラメータはバックアップ ログおよびバンクアップ データ バッファによってディスクに書き込まれたメッセージの最大サイズを指定します。

  デフォルトの値は 256KB です。

• BackupDataBufferSize >= BackupWriteSize + 188KB

• BackupLogBufferSize >= BackupWriteSize + 16KB

• BackupMaxWriteSize >= BackupWriteSize

• Id

  Id 値はすべてのクラスタの内部メッセージのノードを識別するために使用されます。それは 1 〜 63 の整数で、クラスタ無いのすべてのノード ID に対して一意出なければなりません。

• ExecuteOnComputer

  これは config.ini ファイルの [COMPYUTER] セクションで定義されたコンピュータ (ホスト） の id セットのことを意味します。

• HostName

  このパラメータを指定することで SQL ノード （API ノード） が常駐するコンピュータのホスト名を定義します。localhost 以外のホスト名を指定するには、このパラメータあるいは ExecuteOnComputer のいずれかが必要です。

• ArbitrationRank

  このパラメータはどのノードがアービトレーターとしての役割を果たすかを定義します。MGM ノードおよび SQL ノードの両方がアービトレーターになれます。0 の値は所定のノードがアービトレータとして使用されないことを意味し、1 の値はアービトレーターとしての優先度が高く、2 の値は優先度が低いことをいみします。通常の設定ではマネジメント サーバーをアービトレーターとして使用し、ArbitrationRank を 1 (デフォルトt) に、すべての SQL ノードに対しては 0 に設定します。

• ArbitrationDelay

  この値を 0 (デフォルト) 以外に設定するとアービトレーション要求に対するアービトレーターの応答は指定されたミリセカンド数によって遅延されます。通常この値を変更する必要はありません。

• BatchByteSize

  インデックスのフル テーブルあるいは範囲スキャンに翻訳されたクエリに対しては、レコードを適切なサイズで取り出すことがベスト パフォーマンスには重要です。適切なサイズをレコード数 (BatchSize) およびバイト (BatchByteSize) の両方で設定できます。実際のバッチ サイズは両方のパラメータで制限されます。

  クエリが実行去れる速度はこのパラメータの設定によって 40% 以上変化します。今後のリリースでは、MySQL Server にクエリのの種類に基づいた適切なバッチ サイズに関するパラメータの設定を取り入れます。

  このパラメータはバイト数で測定され、そのデフォルトの値は 32KB です。

• BatchSize

  このパラメータはレコード数で測定されそのデフォルトの設定値は 64 です。最大サイズは 992 です。

• MaxScanBatchSize

  バッチ サイズは各データ ノードから送られる各バッチのサイズです。多くのスキャンは MySQL Server を並列の多くのノードからデータを余り多く受け取らないようにするために並列で行われます。このパラメータはすべてのノードに対してバッチの合計を制限します。

  このパラメータのデフォルトの値は 256KB です。最大のサイズは 16MB です。

• NodeId1、NodeId2

  2 つのノード間での接続を認識するには設定ファイルの [TCP] セクションでそれらのノード ID を提供します。これらは 項14.4.4.6. 「SQL および他の API ノードの定義」 の説明にあるようにそれぞれのこれらのノードに対して同じ一意 Id 値をしています。

• SendBufferMemory

  TCP トランスポーターはオペレーティング システムに送信呼び出しを実行する前にバッファを使用してすべてのメッセージを保存します。このバッファが 64KB になると、そのコンテンツを送信します。これらはまた一通りのメッセージが完了すると送信されます。一時的な過負荷状態を処理するために、大きな送信バッファを定義することも出来ます。送信バッファのデフォルトのサイズは 256KB です。

• SendSignalId

  配布されたメッセージのダイアグラムを調べるには、各メッセージを認識する必要があります。このパラメータを Y に設定すると、メッセージ ID がネットワーク上に転送されます。この機能は生産ビルドでデフォルトによって無効にできます。-debug ビルドで有効にします。

• Checksum

  このパラメータはブール パラメータ (Y あるいは 1 に設定して有効にする。無効にするには N あるいは 0) に設定します。デフォルトでそれを無効に出来ます。有効にすると、すべてのメッセージのチェックサムが送信場ファに格納される前に計算されます。この機能によりメッセージが送信バッファで待機している間に、あるいは転送メカニズムで転化してないか確認します。

• PortNumber (OBSOLETE)

  これは他のノードの接続の確認に使用されるポート番号を正式に指定します。このパラメータはもはや使用されません。

• ReceiveBufferMemory

  データを TCP/IP ソケットから受信するときにバッファのサイズを指定するために使用されます。メモリを節約するとき以外に、このパラメータをそのデフォルトの値の 64KB からめったに変更する必要はありません。

• NodeId1、NodeId2

  2 つのノード間の接続を識別するには、NodeId1 および NodeId2 としてそれぞれにノード識別子を提供する必要があります。

• ShmKey

  共有メモリのセグメントを設定する場合には、整数として表されるノード ID を使用して個別に共有メモリのセグメントを通信に使用するために認識します。デフォルトの値はありません。

• ShmSize

  各 SHM 接続には共有メモリのセグメントがあり、ノード間のメッセージは送信者のよって送られ受信者によって読まれます。このセグメントのサイズは ShmSize によって認識されます。デフォルトの値は 1MB　です。

• SendSignalId

  配布したメッセージのパスを辿るには、各メッセージに一意の識別子を付ける必要があります。このパラメータを Y に設定するとこれらのメッセージ ID をネットワーク上でも転送できます。この機能は生産ビルドでデフォルトによって無効にできます。-debug ビルドで有効にします。

• Checksum

  このパラメータは boolean (Y/N) パラメータでデフォルトで無効にできます。有効にすると、すべてのメッセージのチェックサムが送信バッファ格納される前に計算されます。

  この機能により送信バッファで待機中のメッセージの破損を防ぎます。またそれによって転送中のデータの破損をチェックすることもできます。

• NodeId1、NodeId2

  2 つのノード間の接続を識別するには、NodeId1 および NodeId2 としてそれぞれにノード識別子を提供する必要があります。

• Host1SciId0

  これにより最初のクラスタ ノード (NodeId1 による識別) 上で SCI ノード ID を識別します。

• Host1SciId1

  SCI トランスポーターをノード間の個別のネットワークを使用する 2 枚の SCI カード間のファールオーバーに設定できます。これによってノード ID および最初のノードに使用される 2 番目の SCI カードを認識します。

• Host2SciId0

  これにより 2 番目のクラスタ ノード (NodeId2 により識別される) の SCI ノード　ID を認識します。

• Host2SciId1

  フェールオーバーを提供するために 2 つの SCI カードを使用する時は、このパラメータが 2 番目のノードに使用される 2 番目の SCI カードを認識します。

• SharedBufferSize

  各 SCI トランスポートにはノード間の通信に使用される共有メモリのセグメントがあります。このセグメントのサイズをフォルト値の 1MB に設定すると殆どのアプリケーションに十分です。その値を小さく設定すると並列で多くの挿入を行う場合問題が出る場合があります。共有バッファが小さ過ぎると ndbd プロセスでクラッシュする場合があります。

• SendLimit

  SCI メディアの前にある小さなバッファが SCI ネットワークにメッセージを転送する前にメッセージを保存します。デフォルトでは 8KB に設定されています。弊社のベンチマークでは 64KB でパフォーマンスはベストですが、16KB ではこの数パーセントにしか届きませんが、それを 8KB 以上にした場合でも殆ど利点はありませんでした。

• SendSignalId

  配布したメッセージをトレースするには各メッセージを独自に認識する必要があります。このパラメータを Y に設定すると、メッセージ ID がネットワーク上に転送されます。この機能は生産ビルドでデフォルトによって無効にできます。-debug ビルドで有効にします。

• Checksum

  このパラメータは boolean 値で、デフォルトで無効にできます。Checksum が有効にすると、チェックサムは送信バッファに格納される前にすべてのメッセージに対して計算されます。この機能により 2 番目の送信バッファで待機中のメッセージの破損を防ぎます。またそれによって転送中のデータの破損をチェックすることもできます。

• N:ノードの再起動

• IN:最初のノードの再起動

• S:システムの再起動

• IS:最初のシステムの再起動

• N:ノードの再起動

• IN:最初のノードの再起動

• S:システムの再起動

• IS:最初のシステムの再起動

• N:ノードの再起動

• IN:最初のノードの再起動

• S:システムの再起動

• IS:最初のシステムの再起動

• --ndb-connectstring=connect_string

  NDB Cluster ストレージ オプションを使用する際、このオプションはクラスタの設定データを配布するマネジメント サーバーを指定します。

• --ndbcluster

  MySQL を使用するには NDB Cluster ストレージ エンジンが必要です。mysqld バイナリが NDB Cluster ストレージ エンジンのサポートを含む場合、このエンジンはデフォルトで無効になります。有効にするには --ndbcluster オプションを使用します。そのエンジンを明示的に無効にするには --skip-ndbcluster を使用します。

• --bind-address

  ndbd を特定のネットワーク インターフェースに結合します。このオプションにはデフォルトの値はありません。

  このオプションは MySQL 5.1.12 に追加されています。

• --daemon, -d

  ndbd に daemon プロセスの実行を指示します。これはデフォルトの振る舞いです。--nodaemon はプロセスが daemon　として実行されないようにします。

• --initial

  ndbd に初期の実行を指示します。初期の実行により以前の ndbd のインスタンスでリカバリ目的に作成されたファイルを消去します。またリカバリ ログ ファイルを再度作成します。使用しているオペレーティング システムによってはこのプロセスにはかなり長い時間がかかります。

  --initial の実行はそれを実行することによって Cluster のファイルシステムのすべてのファイルを削除し、新たにすべての REDO ファイルを作成するため ndbd プロセスが実行される一番最初にのみ使用されます。この規則に対する例外は:

  • ファイルのコンテンツを変更したソフトウェアのアップグレードを行うとき。

  • ノードを ndbd の新しいバージョンで再起動するとき。

  • 何かの理由でノードあるいはシステムの再起動が繰り返し失敗したときの最後のレポートの方法として。この場合、データ ファイルの破壊によりこのノードはデータの復旧にその後使用できなくなることに注意してください。

  このオプションは以下のいずれにも影響は及ぼしません。

  • 影響されたノードにより既に作成されたバックアップ ファイル

  • Cluster ディスク データ ファイル (項14.11. 「MySQL Cluster ディスク データ ストレージ」 参照)。

  そのデータ ノード ? で作成されたバックアップを維持し ndbd を --initial オプションを使用せずに実行するには、DataDir のBACKUP の可能な例外によってデータ ノード DataDir のすべてのファイルおよびディレクトリを別の方法 (rm -r -f などを使用して) によって削除することで同じ効果を得ることができます。これは Cluster の管理タスクを記述する際に役に立ちます。

• --initial-start

  このオプションはクラスタを部分的に初期起動する際に使用します。各ノードおよび --no-wait-nodes はこのオプションで起動します。

  例えば、データ ノードの ID が 2、3、4、および 5 を持つ 4-ノード クラスタを持っているとします。それをノードの 2、4、および 5 のみを使用して部分的な初期の起動をする場合。? つまりノード 3 を除く:

  ndbd --ndbd-nodeid=2 --no-wait-nodes=3 --initial-start
  ndbd --ndbd-nodeid=4 --no-wait-nodes=3 --initial-start
  ndbd --ndbd-nodeid=5 --no-wait-nodes=3 --initial-start
  

  このオプションは MySQL 5.1.9 に追加されています。

• --nowait-nodes=node_id_1[, node_id_2[, ...]]

  このオプションはクラスタが起動前に待たないデータ ノードのリストを扱っています。

  これをクラスタが分割した状態での起動に使用できます。例えば、クラスタを 4-ノード クラスタを稼動しているデータ ノードの半分だけ (ノード 2、3、4、および 5) で起動するには、かく ndbd プロセスを --nowait-nodes=3,5 で実行します。この場合、クラスタはノード 2 および 4 が接続すると直ぐ起動し、ノード 3 および 5 が接続するまで StartPatitionedTimeout ミリセカンドをまちません 。

  前の例の同じクラスタを 1 つの ndbd ? 無しで起動したい場合、例えば、ノード 3 のホスト マシンのハードウェアに問題があり ? ノード 2、4、および 5 を --no-wait-nodes=3 で起動する場合。次にクラスタが直ぐにノード 2、4、および 5 を接続しノード 3 の起動を待たない場合。

  このオプションは MySQL 5.1.9 に追加されています。

• --nodaemon

  ndbd に daemon プロセスとして実行しないよう指示を出します。これは ndbd がデバッグされて出力を画面に向ける場合に有効です。

• --nostart, -n

  ndbd に自動的に実行しないよう指示をだします。このオプションを使用すると、ndbd がマネジメント サーバーに接続して、マネジメント サーバーから設定データを取得し、通信オブジェクトを初期化します。しかし、それはマネジメント サーバーによって特にそうするように要求されるまで実行エンジンを起動しません。これはマネジメント クライアントで適切な START コマンドを出すと実行されます (項14.7.2. 「マネジメント クライアントのコマンド」 参照)。

• --config-file=filename, -f filename

  マネジメント サーバーにその設定ファイルにどのファイルを使用するかを指示します。このオプションは指定する必要があります。そのファイル名は config.ini に既定です。

  注:このオプションには -c file_nameを付けることもできますが、このショートカットは既に陳腐なため新しいインストールでは使用していません。

• --daemon, -d

  ndb_mgmd に daemon プロセスを実行する指示を出します。これはデフォルトの操作です。

• --nodaemon

  ndb_mgmd に daemon daemon として開始しないように指示します。

• --try-reconnect=number

  マネジメント サーバーへの接続が切断された場合、ノードは接続できるまで 5 秒ごとに接続を試みます。このオプションを使用して、再接続の回数を number に制限して再接続を止めエラーとして報告することもできます。

• CLUSTERLOG ON

  クラスタのログをオンにします。

• CLUSTERLOG OFF

  クラスタのログをオフにします。

• CLUSTERLOG INFO

  クラスタのログ設定に関する情報を提供します。

• node_id CLUSTERLOG category=threshold

  ログの category イベントでクラスタ ログの threshold 以下あるいは同等のイベントです。

• CLUSTERLOG FILTER severity_level

  severity_level で指定されたイベントのクラスタ ログを切り換えます。