NodeId

一意のノード ID は、クラスタのすべての内部メッセージでノードのアドレスとして使用されます。 データノードでは、これは 1-144 の (これらを含む) 範囲の整数です。 (NDB 8.0.17 以前では、これは 1 から 48 でした。) クラスタ内の各ノードは、一意の識別子を持っている必要があります。

NodeId は、データノードを識別するときに使用できる唯一のパラメータ名です。

ExecuteOnComputer

これは、[computer] セクションに定義されたいずれかのコンピュータに設定されている Id を参照します。

このノードのノード ID は、明示的にリクエストする接続にのみ指定できます。 ノード ID をリクエストする管理サーバーは、このノード ID を使用できません。 このパラメータは、同じホストで複数の管理サーバーを実行していて、HostName でプロセスを区別するのに十分でない場合に使用できます。 テストで使用するためのものです。

HostName

このパラメータを指定すると、データノードを配置するコンピュータのホスト名が定義されます。 localhost 以外のホスト名を指定するには、このパラメータまたは ExecuteOnComputer のどちらかが必要です。

ServerPort

クラスタ内の各ノードは、ほかのノードに接続するためにポートを使用します。 デフォルトでは、このポートは同じホストコンピュータ上の 2 つのノードで同じポート番号を受け取らないよう動的に割り当てられるため、通常はこのパラメータの値を指定する必要はありません。

ただし、データノートと API ノード (SQL ノードを含む) 間の通信を許可するため、ファイアウォールで特定のポートを開く必要がある場合は、config.ini ファイルの [ndbd] セクションまたは (複数のデータノードに対してこれを行う必要がある場合は) [ndbd default] セクションでこのパラメータを必要なポートの番号に設定すると、SQL ノード、API ノード、またはその両方からの着信接続のためにその番号のポートを開くことができます。

TcpBind_INADDR_ANY

このパラメータを TRUE または 1 に設定すると、IP_ADDR_ANY がバインドされ、任意の場所から接続できるようになります (自動生成接続の場合)。 デフォルトは FALSE (0) です。

NodeGroup

このパラメータを使用して、データノードを特定のノードグループに割り当てることができます。 これはクラスタを最初に起動したときは読み取り専用であり、オンラインでデータノードを別のノードグループに再割り当てすることはできません。 config.ini ファイルの [ndbd default] セクションでこのパラメータを使用することは、通常望ましくありません。また、ノードをノードグループに割り当てるときは、ノードグループに無効な数のノードが割り当てられないように注意する必要があります。

NodeGroup パラメータは主に、ローリング再起動を実行せずに、実行中の NDB Cluster に新しいノードグループを追加するために使用されます。 そのためには、これを 65536 (最大値) に設定します。 NodeGroup の値は、すべてのクラスタデータノードではなく、あとで起動され、新しいノードグループとしてクラスタに追加されるノードにのみ設定する必要があります。 詳細は、セクション23.5.7.3「NDB Cluster データノードのオンラインでの追加: 詳細な例」を参照してください。

LocationDomainId

クラウド内の特定の「可用性ドメイン」 (可用性ゾーンとも呼ばれる) にデータノードを割り当てます。 どのノードがどの可用性ドメインにあるかを NDB に通知することで、次の方法でクラウド環境のパフォーマンスを向上させることができます:

LocationDomainId は 0 以上 16 以下の整数値を取り、0 がデフォルトです。0 を使用することは、パラメータを未設定のままにすることと同じです。

NoOfReplicas

このグローバルパラメータは、[ndbd default]セクションでのみ設定でき、クラスタに格納されている各テーブルのフラグメントレプリカの数を定義します。 このパラメータは、ノードグループのサイズも指定します。 ノードグループは、すべてが同じ情報を格納するノードのセットです。

ノードグループは暗黙的に形成されます。 最初のノードグループはノード ID がもっとも小さいデータノードのセットで形成され、次のノードグループはノード ID が次に小さいデータノードのセットで形成されます (以下同様)。 例として、4 つのデータノードがあり、NoOfReplicas が 2 に設定されているとします。 4 つのデータノードのノード ID はそれぞれ 2、3、4、および 5 です。 この場合、1 つ目のノードグループはノード 2 および 3 で形成され、2 つ目のノードグループはノード 4 および 5 で形成されます。 1 つのハードウェアの障害によってクラスタ全体が機能停止するため、同じノードグループ内のノードが同じコンピュータに配置されないようにクラスタを構成することが重要です。

ノード ID が指定されていない場合、データノードの順序はノードグループの決定要素になります。 明示的な割当てが行われたかどうかにかかわらず、管理クライアントの SHOW コマンドの出力に表示できます。

NoOfReplicas のデフォルト値は 2 です。 これはほとんどの本番環境で推奨される値であり、NDB 8.0.18 より前はサポートされていた最大値でした。 NDB 8.0.19 以降では、このパラメータ値を 3 または 4 に設定すると、本番で完全にテストされ、サポートされます。

クラスタ内のデータノードの数は、このパラメータの値で均等に割り切れる必要があります。 たとえば、データノードが 2 つある場合、2/3 と 2/4 の両方で小数値が生成されるため、NoOfReplicas は 1 または 2 のいずれかである必要があります。4 つのデータノードがある場合、NoOfReplicas は 1、2 または 4 である必要があります。

DataDir

このパラメータは、トレースファイル、ログファイル、PID ファイル、およびエラーログが配置されるディレクトリを指定します。

デフォルトはデータノードプロセスの作業ディレクトリです。

FileSystemPath

このパラメータは、メタデータ用に作成されるすべてのファイル、Redo ログ、Undo ログ (ディスクデータテーブル用)、およびデータファイルが配置されるディレクトリを指定します。 デフォルトは、DataDir で指定されたディレクトリです。

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

BackupDataDir

このパラメータは、バックアップが配置されるディレクトリを指定します。

DataMemory

このパラメータは、データベースレコードの格納に使用できるスペースの量 (バイト単位) を定義します。 この値によって指定される量の全体がメモリー内に割り当てられるため、それに対応できるだけの十分な物理メモリーがマシンに搭載されていることが非常に重要です。

DataMemory によって割り当てられたメモリーは、実際のレコードとインデックスの両方を格納するために使用されます。 各レコードには 16 バイトのオーバーヘッドがあります。各レコードは 128 バイトのページオーバーヘッドを含む 32K バイトのページに格納されるため、レコードごとに追加の量が発生します (次を参照してください)。 また、各レコードが 1 つのページのみに格納されるため、ページごとに少量の無駄が発生します。

可変サイズのテーブル属性については、DataMemory から割り当てられた別個のデータページにデータが格納されます。 可変長レコードは、可変サイズ部分を参照するための 4 バイトの追加オーバーヘッドを含む固定サイズ部分を使用します。 可変サイズ部分には、2 バイトのオーバーヘッドと属性あたり 2 バイトが含まれます。

NDB 8.0.18 の時点では、最大レコードサイズは 30000 バイトです。 以前は 14000 バイトでした。

DataMemory に割り当てられたリソースは、すべてのデータおよびインデックスの格納に使用されます。 (IndexMemory として構成されたメモリーは、DataMemory が共通リソースプールを形成するために使用するメモリーに自動的に追加されます。)

現在、NDB Cluster はパーティションあたりのハッシュインデックスに最大 512 MB を使用できます。つまり、ndb_mgm -e "ALL REPORT MEMORYUSAGE"がかなりの空き DataMemory を示していても、MySQL クライアントアプリケーションで「テーブルがいっぱいです」エラーが発生する可能性があります。 このため、データの負荷が高いノードでデータノードを再起動するときに問題が発生する場合もあります。

特定のテーブルのローカルデータマネージャごとのパーティション数を制御するには、テーブルの作成時に、LDM ごとにそれぞれ 1、2、3 または 4 つのパーティションに対して、NDB_TABLE オプション PARTITION_BALANCE を FOR_RA_BY_LDM, FOR_RA_BY_LDM_X_2, FOR_RA_BY_LDM_X_3 または FOR_RA_BY_LDM_X_4 のいずれかの値に設定します (セクション13.1.20.11「NDB_TABLE オプションの設定」 を参照)。

MinFreePct 構成パラメータを使用して、ノード再起動の問題を回避することもできます。

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

ページの割り当て後、テーブルを削除する以外の方法で空きページのプールに戻すことは、現在不可能です。 (これは、特定のページに割り当てられた DataMemory ページをほかのテーブルで使用できないことも意味します。) データノードのリカバリを実行すると、すべてのレコードがほかの稼働しているノードから空のパーティションに挿入されるため、パーティションも圧縮されます。

DataMemory メモリー領域には UNDO 情報も含まれています: 更新ごとに、変更されていないレコードのコピーが DataMemory に割り当てられます。 順序付けされたテーブルインデックスにも各コピーへの参照が含まれています。 一意のハッシュインデックスは、一意のインデックスカラムが更新されたときだけ更新されます。その場合は、コミット時にインデックステーブル内の新しいエントリが挿入され、古いエントリが削除されます。 このため、クラスタを使用するアプリケーションによって実行される大規模なトランザクションを処理できるだけの十分なメモリーを割り当てる必要もあります。 いずれにしても、次の理由から、少数の大規模なトランザクションを実行するよりも、多数の小規模なトランザクションを使用する方がメリットがあります。

NDB 8.0 での DataMemory のデフォルト値は 98MB です。 最小値は 1MB です。 最大サイズはありませんが、実際には、制限に達したときにプロセスがスワップを開始しないように最大サイズを決定する必要があります。 この制限は、マシン上の使用可能な物理 RAM 量と、オペレーティングシステムが 1 つのプロセスに振り向けることができるメモリー量によって決まります。32 ビットオペレーティングシステムでは通常プロセスあたり 2-4G バイトに制限されますが、64 ビットオペレーティングシステムではより多くのメモリーを使用できます。 このため、大規模なデータベースでは 64 ビットオペレーティングシステムを使用することをお勧めします。

IndexMemory

IndexMemory パラメータは非推奨になりました (将来の削除の対象となります)。IndexMemory に割り当てられたメモリーは、かわりに DataMemory と同じプールに割り当てられます。これは、データおよびインデックスをメモリーに格納するために必要なすべてのリソースのみを担当します。 NDB 8.0 では、クラスタ構成ファイルで IndexMemory を使用すると、管理サーバーから警告がトリガーされます。

ハッシュインデックスのサイズは、この式を使用して見積もることができます。

  size  = ( (fragments * 32K) + (rows * 18) )
          * fragment_replicas

fragments はフラグメントの数、fragment_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.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 という名前の順序付けされたインデックスがあるとします。 また、IndexStatSaveSize と IndexStatSaveScale がこのデフォルト値 (それぞれ 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 バイトです。

NDB 8.0 では、このパラメータの最小値とデフォルト値は 0 (ゼロ) です。

StringMemory

このパラメータは、テーブル名などの文字列用に割り当てられるメモリー量を決定するもので、config.ini ファイルの [ndbd] または [ndbd default] セクションに指定されます。 0 から 100 までの (これらを含む) 値は、デフォルトの最大値のパーセントとして解釈されます。デフォルトの最大値は、テーブルの数、テーブル名のサイズ、.FRM ファイルの最大サイズ、MaxNoOfTriggers、カラム名の最大サイズ、およびデフォルトの最大カラム値を含むいくつかの係数に基づいて計算されます。

100 を超える値は、バイト数として解釈されます。

デフォルト値は 25 (つまり、デフォルトの最大の 25%) です。

ほとんどの場合、デフォルト値で十分ですが、多数の NDB テーブル (1000 以上) がある場合は、エラー 773 「文字列メモリー不足です。StringMemory 構成パラメータを変更してください: 永続エラー: スキーマエラー」が発生する可能性があり、その場合はこの値を増やす必要があります。25 (25%) は過剰ではないため、このエラーが最も極端な状況を除くすべての状況で繰り返されるのを防ぐ必要があります。

MaxNoOfConcurrentTransactions

各クラスタデータノードには、クラスタ内の個々のアクティブなトランザクションに対するトランザクションレコードが必要です。 トランザクションを調整するタスクは、すべてのデータノードに分配されます。 クラスタ内のトランザクションレコードの合計数は、特定のノード内のトランザクションの数にクラスタ内のノードの数を掛けた値です。

トランザクションレコードは、個々の MySQL サーバーに割り当てられます。 MySQL サーバーへの個々の接続には、少なくとも 1 つのトランザクションレコードと、その接続でアクセスされるテーブルごとに追加のトランザクションオブジェクトが必要です。 つまり、クラスタ内のトランザクション合計数の妥当な最小値を次のように表すことができます。

TotalNoOfConcurrentTransactions =
    (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 個のトランザクションレコード) が必要です。 各データノードは、TotalNoOfConcurrentTransactions / データノードの数を処理することが期待されます。 4 つのデータノードを持つ NDB Cluster の場合、これは各データノードの MaxNoOfConcurrentTransactions を 1100 / 4 = 275 に設定することを意味します。 また、単一ノードグループがすべての同時トランザクションに対応できるようにすることで、障害リカバリを提供する必要があります。つまり、各データノード MaxNoOfConcurrentTransactions では、TotalNoOfConcurrentTransactions / ノードグループの数と等しいトランザクションの数を十分に処理できます。 このクラスタにノードグループが 1 つだけある場合は、MaxNoOfConcurrentTransactions を 1100 (クラスタ全体の並列トランザクションの数と同じ) に設定するようにしてください。

また、各トランザクションに少なくとも 1 つの操作が関与します。このため、MaxNoOfConcurrentTransactions に設定する値は常に MaxNoOfConcurrentOperations の値以下にします。

このパラメータは、すべてのクラスタデータノードで同じ値に設定する必要があります。 これは、データノードの機能停止時に、残存するもっとも古いノードが機能停止したノードで実行されていたトランザクションのトランザクション状態を再作成するためです。

ローリング再起動を使用してこの値を変更できますが、実行中のクラスタ上のトラフィック量は、発生するトランザクションが新旧どちらか低い方のレベルを超えない程度にする必要があります。

デフォルト値は 4096 です。

MaxNoOfConcurrentOperations

このパラメータの値は、トランザクションのサイズと数に合わせて調整することをお勧めします。 少数の操作とレコードしか関与しないトランザクションを実行する場合は、通常、このパラメータのデフォルト値で十分です。 多数のレコードが関与する大規模なトランザクションを実行する場合は、通常、その値を増やす必要があります。

クラスタデータを更新する各トランザクションでは、トランザクションコーディネータと実際の更新が実行されるノードの両方でレコードが保持されます。 これらのレコードには、ロールバック、ロックキュー、およびその他の目的に使用する Undo レコードを見つけるために必要な状態情報が含まれています。

このパラメータは、最低でも、トランザクションで同時に更新されるレコードの数をクラスタデータノードの数で割った値に設定するようにしてください。 たとえば、4 つのデータノードがあるクラスタで、トランザクションを使用して 100 万件の並列更新を処理することが予想される場合は、この値を 1000000/4 = 250000 に設定します。 障害からの回復力を提供できるように、このパラメータを、個々のデータノードでノードグループの負荷を処理できる十分な大きさの値に設定することをお勧めします。 つまり、並列操作の合計数/ノードグループの数と同じ値に設定するようにしてください。 (ノードグループが 1 つだけの場合、これはクラスタ全体の並列操作の合計数と同じです。)

各トランザクションには常に少なくとも 1 つの操作が関与しているため、MaxNoOfConcurrentOperations の値は常に MaxNoOfConcurrentTransactions の値以上にします。

ロックを設定する読み取りクエリーでも、操作レコードが作成されます。 ノード間の分布が完全でない場合に対応できるように、個々のノード内にある程度の追加スペースが割り当てられます。

クエリーで一意のハッシュインデックスが使用されると、実際にはトランザクション内のレコードあたり 2 つの操作レコードが使用されます。 1 つ目のレコードはインデックステーブルの読み取りを表し、2 つ目はベーステーブルに対する操作を扱います。

デフォルト値は 32768 です。

このパラメータは、実際には別個に構成できる 2 つの値を扱います。 これらのうち 1 つ目は、トランザクションコーディネータによって配置される操作レコードの数を指定します。 2 つ目の部分は、データベースにローカルに格納される操作レコードの数を指定します。

8 ノードのクラスタで実行される非常に大規模なトランザクションでは、そのトランザクションに関与する読み取り、更新、および削除と同じ数の操作レコードがトランザクションコーディネータ内に必要です。 ただし、これらの操作レコードは 8 個のノードすべてに分散しています。 このため、1 つの非常に大規模なトランザクション用にシステムを構成する必要がある場合は、この 2 つの部分を別個に構成することをお勧めします。 MaxNoOfConcurrentOperations は常に、ノードのトランザクションコーディネータ部分の操作レコードの数を計算するために使用されます。

操作レコードのメモリー要件を考慮することも重要です。 これらは、レコードあたり約 1K バイトを消費します。

MaxNoOfLocalOperations

デフォルトでは、このパラメータは 1.1 * MaxNoOfConcurrentOperations として計算されます。 これは、多くの同時トランザクションを含み、そのいずれもが大規模ではないシステムに適合します。 一度に 1 つの非常に大規模なトランザクションが実行され、多数のノードがある場合は、このパラメータを明示的に指定してデフォルトをオーバーライドすることをお勧めします。

このパラメータは NDB 8.0.19 の時点では非推奨であり、将来の NDB Cluster リリースで削除される予定です。 また、このパラメータは TransactionMemory パラメータと互換性がありません。クラスタ構成ファイル (config.ini) で両方のパラメータの値を設定しようとすると、管理サーバーは起動を拒否します。

MaxDMLOperationsPerTransaction

このパラメータは、トランザクションのサイズを制限します。 これを超える数の DML 操作が必要になった場合、トランザクションは中止されます。 トランザクションあたりの最小操作数は 32 ですが、MaxDMLOperationsPerTransaction を 0 に設定すると、トランザクションあたりの DML 操作の数に対する制限を無効にできます。 最大 (およびデフォルト) は 4294967295 です。

このパラメータの値は、MaxNoOfConcurrentOperations に設定されている値を超えることはできません。

MaxNoOfConcurrentIndexOperations

一意のハッシュインデックスを使用するクエリーでは、クエリーの実行フェーズで別の一時的な操作レコードのセットが使用されます。 このパラメータは、そのレコードプールのサイズを設定します。 このため、このレコードはクエリーの一部を実行している間だけ割り当てられます。 この部分の実行が完了した直後にレコードは解放されます。 中止とコミットを処理するために必要な状態では通常の操作レコードによって処理され、プールサイズは MaxNoOfConcurrentOperations パラメータで設定されます。

このパラメータのデフォルト値は 8192 です。 一意のハッシュインデックスを使用して非常に高い並列性を実現させるまれなケースでのみ、この値を増やす必要があります。 クラスタに高いレベルの並列性が必要ないことを DBA が確信している場合は、小さい値を使用してメモリーを節約できます。

このパラメータは NDB 8.0.19 の時点では非推奨であり、将来の NDB Cluster リリースで削除される予定です。 また、このパラメータは TransactionMemory パラメータと互換性がありません。クラスタ構成ファイル (config.ini) で両方のパラメータの値を設定しようとすると、管理サーバーは起動を拒否します。

MaxNoOfFiredTriggers

MaxNoOfFiredTriggers のデフォルト値は 4000 です。ほとんどの状況では、これで十分です。 場合によっては、クラスタに並列性はそれほど必要ないと DBA が確信している場合は、値を減らすこともできます。

一意のハッシュインデックスに影響を与える操作が実行されたときに、レコードが作成されます。 一意のハッシュインデックスを使用してテーブル内のレコードを挿入または削除したり、一意のハッシュインデックスの一部であるカラムを更新したりすると、インデックステーブルで挿入または削除が発生します。 生成されたレコードは、このインデックステーブル操作を発生させた元の操作の完了を待機している間、インデックステーブル操作を表すために使用されます。 この操作は短期間ですが、一意のハッシュインデックスのセットを含むベーステーブルに対して多数の並列書き込み操作が行われる状況では、レコードプール内に多数のレコードを必要とする可能性があります。

このパラメータは NDB 8.0.19 の時点では非推奨であり、将来の NDB Cluster リリースで削除される予定です。 また、このパラメータは TransactionMemory パラメータと互換性がありません。クラスタ構成ファイル (config.ini) で両方のパラメータの値を設定しようとすると、管理サーバーは起動を拒否します。

TransactionBufferMemory

このパラメータの影響を受けるメモリーは、インデックステーブルの更新と一意のインデックスの読み取り時に発生した操作を追跡するために使用されます。 このメモリーは、これらの操作のキーおよびカラムの情報を格納するために使用されます。 このパラメータの値をデフォルトから変更する必要があるのは、非常にまれなケースだけです。

TransactionBufferMemory のデフォルト値は 1M バイトです。

通常の読み取りおよび書き込み操作でも同じようなバッファーが使用されますが、その使用期間はさらに短くなります。 コンパイル時のパラメータ ZATTRBUF_FILESIZE (ndb/src/kernel/blocks/Dbtc/Dbtc.hpp にあります) は 4000 * 128 バイト (500K バイト) に設定されています。 キー情報用の同様のバッファー ZDATABUF_FILESIZE (これも Dbtc.hpp にあります) には、4000 * 16 = 62.5K バイトのバッファースペースが含まれています。 Dbtc は、トランザクションのコーディネーションを扱うモジュールです。

ReservedConcurrentIndexOperations

1 つのデータノード上に専用リソースを持つ同時インデックス操作の数。

ReservedConcurrentOperations

単一のデータノード上のトランザクションコーディネータに専用のリソースを持つ同時操作の数。

ReservedConcurrentScans

1 つのデータノード上に専用のリソースを持つ同時スキャンの数。

ReservedConcurrentTransactions

単一のデータノード上に専用リソースを持つ同時トランザクションの数。

ReservedFiredTriggers

単一の ndbd(DB) ノードに専用のリソースを持つトリガーの数。

ReservedLocalScans

1 つのデータノード上に専用のリソースを持つ同時フラグメントスキャンの数。

ReservedTransactionBufferMemory

各データノードに割り当てられたキーおよび属性データの動的バッファ領域 (バイト単位)。

TransactionMemory

このパラメータは、各データノードのトランザクションに割り当てられるメモリー (バイト単位) を決定します。 トランザクションメモリーの設定は、次の 3 つの方法のいずれかで処理できます:

TransactionMemory と互換性のないパラメータ.  次のパラメータは TransactionMemory と同時に使用できず、NDB 8.0.19 の時点で非推奨になりました:

TransactionMemory がクラスタ構成ファイル (config.ini) にも設定されている場合、リストされているパラメータのいずれかを明示的に設定すると、管理ノードは起動しません。

NDB Cluster データノードでのリソース割り当ての詳細は、セクション23.3.3.13「データノードのメモリー管理」 を参照してください。

BatchSizePerLocalScan

このパラメータは、並列スキャン操作を処理するために使用されるロックレコードの数を計算するために使用されます。

BatchSizePerLocalScan は、SQL ノードで定義される BatchSize と深い関係があります。

NDB 8.0.19 の時点では非推奨です。

LongMessageBuffer

これは、個々のノード内およびノード間でメッセージを渡すために使用される内部バッファーです。 デフォルトは 64M バイトです。

ほとんどの場合、このパラメータをデフォルトから変更する必要はありません。

MaxFKBuildBatchSize

外部キーの作成に使用される最大スキャンバッチサイズ。 このパラメータに設定された値を増やすと、進行中のトラフィックへの影響が大きくなるため、外部キービルドの構築が高速化される場合があります。

MaxNoOfConcurrentScans

このパラメータは、クラスタ内で実行できる並列スキャンの数を制御するために使用されます。 各トランザクションコーディネータは、このパラメータで定義された数の並列スキャンを処理できます。 各スキャンクエリーは、すべてのパーティションを並列でスキャンして実行されます。 各パーティションスキャンでは、パーティションが配置されているノード内のスキャンレコードが使用されます。レコードの数は、このパラメータの値にノードの数を掛けた値です。 クラスタは、クラスタ内のすべてのノードで同時に発生した MaxNoOfConcurrentScans 個のスキャンを維持できます。

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

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

MaxNoOfLocalScans

多くのスキャンが完全に並列化されていない場合の、ローカルスキャンレコードの数を指定します。 ローカルスキャンレコードの数が指定されていない場合は、ここに示すように計算されます。

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

このパラメータは NDB 8.0.19 の時点では非推奨であり、将来の NDB Cluster リリースで削除される予定です。 また、このパラメータは TransactionMemory パラメータと互換性がありません。クラスタ構成ファイル (config.ini) で両方のパラメータの値を設定しようとすると、管理サーバーは起動を拒否します。

MaxParallelCopyInstances

このパラメータは、ノードの再起動またはシステムの再起動のコピーフェーズで使用されるパラレル化を設定します。現在起動中のノードが、最新のノードから変更されたレコードをコピーすることによって、現在のデータを持つノードと同期化されている場合です。 このような場合、完全な並列性によって過負荷状態が発生する可能性があるため、MaxParallelCopyInstances ではそれを減らす手段が提供されます。 このパラメータのデフォルト値は 0 です。 この値は、有効な並列性が、ノードを更新するノードだけでなく、ノード内の LDM インスタンスの数と同じであることを意味します。

MaxParallelScansPerFragment

順次処理のキューイングが開始される前に許可される並列スキャン (TUP スキャンおよび TUX スキャン) の最大数を構成できます。 これを増やすことにより、多数のスキャンを並列で実行するときに未使用の CPU を利用して、パフォーマンスを向上させることができます。

MaxReorgBuildBatchSize

テーブルパーティションの再編成に使用される最大スキャンバッチサイズ。 このパラメータに設定された値を増やすと、進行中のトラフィックへの影響が大きくなるため、再編成が高速化される場合があります。

MaxUIBuildBatchSize

一意キーの作成に使用される最大スキャンバッチサイズ。 このパラメータに設定された値を増やすと、進行中のトラフィックへの影響が大きくなるため、このようなビルドが高速化される可能性があります。

FragmentLogFileSize

このパラメータを設定すると、Redo ログファイルのサイズを直接制御できます。 これは、NDB Cluster が高負荷で動作しており、新しいフラグメントログファイルを開こうとする前にフラグメントログファイルを十分に迅速に閉じることができない (一度に開くことができるフラグメントログファイルは 2 つだけです)、フラグメントログファイルのサイズを増やすと、新しいフラグメントログファイルを開く前にクラスタの時間が長くなる可能性があります。 このパラメータのデフォルト値は 16M です。

フラグメントログファイルの詳細は、NoOfFragmentLogFiles の説明を参照してください。

InitialNoOfOpenFiles

このパラメータは、開いたファイルに割り当てる初期の内部スレッド数を設定します。

デフォルト値は 27 です。

InitFragmentLogFiles

デフォルトでは、データノードの初期起動の実行時はフラグメントログファイルがまばらに作成されます。つまり、使用するオペレーティングシステムとファイルシステムによって、必ずしもすべてのバイトがディスクに書き込まれるわけではありません。 ただし、このパラメータを使用すると、使用されているプラットフォームやファイルシステムのタイプに関係なく、この動作をオーバーライドしてすべてのバイトが強制的に書き込まれるように設定できます。 InitFragmentLogFiles は 2 つの値のいずれかを取ります。

オペレーティングシステムとファイルシステムによっては、InitFragmentLogFiles=FULL を設定することで、Redo ログへの書き込み時の I/O エラーを解消できる場合があります。

EnablePartialLcp

true の場合、部分的なローカルチェックポイントを有効にします: これは、各 LCP がデータベース全体の一部のみを記録し、最後の LCP 以降に変更された行を含むレコードのみを記録することを意味します。変更された行がない場合、LCP は LCP 制御ファイルのみを更新し、データファイルは更新しません。

EnablePartialLcp が無効 (false) の場合、各 LCP は単一のファイルのみを使用し、完全チェックポイントを書き込みます。これには LCP に必要なディスク容量が最小限ですが、LCP ごとに書き込み負荷が増加します。 デフォルト値は enabled (true) です。 部分 LCPS で使用される領域の割合は、RecoveryWork 構成パラメータの設定によって変更できます。

LCP 全体および一部に使用されるファイルおよびディレクトリの詳細は、NDB Cluster Data Node File System Directory を参照してください。

このパラメータを false に設定すると、適応 LCP 制御メカニズムで使用されるディスク書込み速度の計算も無効になります。

LcpScanProgressTimeout

ローカルチェックポイントのフラグメントスキャンウォッチドッグは、ローカルチェックポイントの一部として実行されている各フラグメントスキャンが進行していないかどうか定期的にチェックし、特定の時間が経過しても進行しない場合はそのノードをシャットダウンします。 この間隔は、LCP フラグメントスキャンウォッチドッグがノードを停止するまでにローカルチェックポイントを停止できる最大時間を設定する LcpScanProgressTimeout データノード構成パラメータを使用して設定できます。

デフォルト値は 60 秒です (以前のリリースと互換性があります)。 このパラメータを 0 に設定すると、LCP のフラグメントスキャンウォッチドッグが完全に無効化されます。

MaxNoOfOpenFiles

このパラメータは、開いたファイルに割り当てる内部スレッド数の上限を設定します。 このパラメータの変更が必要な状況が発生した場合は、それをバグとして報告するようにしてください。

デフォルト値は 0 です。 ただし、このパラメータに設定できる最小値は 20 です。

MaxNoOfSavedMessages

このパラメータは、エラーログに書き込まれるエラーの最大数と、既存のトレースファイルを上書きする前に保持されるトレースファイルの最大数を設定します。 トレースファイルは、何らかの理由でノードがクラッシュしたときに生成されます。

デフォルトは 25 で、これらの最大値は 25 個のエラーメッセージおよび 25 個のトレースファイルに設定されます。

MaxLCPStartDelay

データノードの並列リカバリでは、実際にはテーブルデータのみが並列でコピーされ、同期されます。ディクショナリ情報やチェックポイント情報などのメタデータの同期は順次に行われます。 また、ディクショナリおよびチェックポイント情報のリカバリは、ローカルチェックポイントの実行と並列で実行できません。 つまり、多くのデータノードを同時に起動したり再起動したりすると、データノードがローカルチェックポイントの実行中に待たされて、ノードのリカバリ時間が長くなる可能性があります。

より多くの (場合によってはすべての) データノードでメタデータの同期を完了できるように、ローカルチェックポイントの遅延を強制できます。各データノードでメタデータの同期が完了したあとは、ローカルチェックポイントの実行中でも、すべてのデータノードで並列にテーブルデータをリカバリできます。 このような遅延を強制するには、MaxLCPStartDelay を設定します。これは、データノードでメタデータの同期が継続されている間にクラスタがローカルチェックポイントの開始を待機する秒数を決定します。 このパラメータは、すべてのデータノードで同じになるように config.ini ファイルの [ndbd default] セクションに設定するようにしてください。 最大値は 600、デフォルトは 0 です。

NoOfFragmentLogFiles

このパラメータは、ノードの Redo ログファイルの数 (つまり、Redo ロギングに割り当てられるスペースの量) を設定します。 Redo ログファイルはリング状に編成されるため、セット内の最初と最後のログファイル (それぞれ 「head」 および 「tail」 ログファイルとも呼ばれる) が交わらないことが非常に重要です。 これらが互いに近寄りすぎると、新しいログレコードを追加する余裕がないため、ノードは更新を含むすべてのトランザクションを中止し始めます。

REDO ログレコードは、そのログレコードが挿入されてから、両方の必要なローカルチェックポイントが完了するまで削除されません。 チェックポイントの頻度は、この章で別途説明する固有の構成パラメータセットによって決定されます。

デフォルトのパラメータ値は 16 です。これは、デフォルトでは 16M バイトのファイル 4 個が 16 セット (合計 1024M バイト) あることを意味します。 個々のログファイルのサイズは、FragmentLogFileSize パラメータを使用して構成できます。 非常に多くの更新が必要なシナリオでは、Redo ログに対して十分なスペースを提供するため、NoOfFragmentLogFiles の値を 300 以上に設定する必要がある場合があります。

チェックポイントが遅く、データベースへの書き込みが多いためにログファイルがいっぱいになって、リカバリに悪影響を与えずにログの末尾をカットできない場合は、すべての更新トランザクションが内部エラーコード 410「Out of log file space temporarily」によって中止されます。 この状態は、チェックポイントが完了してログの末尾を前に移動できるようになるまで続きます。

RecoveryWork

LCP ファイルの記憶域オーバーヘッドの割合。 このパラメータは、EnablePartialLcp が true の場合、つまり部分的なローカルチェックポイントが有効な場合にのみ有効です。 値が大きいほど、次のことを意味します:

RecoveryWork の値が小さいほど、次のことを意味します:

たとえば、RecoveryWork を 60 に設定すると、LCP の合計サイズは、チェックポイントするデータのサイズの約 1 倍 0.6 = 1.6 倍になります。 つまり、再起動のリストアフェーズでは、フルチェックポイントを使用する再起動時に実行される作業と比較して 60% 多くの作業が必要になります。 (これは、部分 LCP を使用している場合でも完全 LCP を使用している場合よりも再起動全体が高速になるように、再起動の他のフェーズで補正されるよりも多くあります。) redo ログをいっぱいにしないためには、チェックポイント中のデータ変更率の 1 + (1 / RecoveryWork) 回書き込む必要があります。したがって、RecoveryWork = 60,では、変更率の約 1 + (1 / 0.6) = 2.67 回書き込む必要があります。 つまり、変更が毎秒 10 MByte で書き込まれる場合、チェックポイントはおおよその 26.7 MByte/秒で書き込む必要があります。

RecoveryWork = 40 を設定すると、LCP の合計サイズの 1.4 倍のみが必要になります (したがって、リストアフェーズにかかる時間は 10 から 15% 短縮されます)。 この場合、チェックポイント書込み率は変更率の 3.5 倍です。

NDB ソース配布には、LCP をシミュレートするためのテストプログラムが含まれています。lcp_simulator.cc は、storage/ndb/src/kernel/blocks/backup/にあります。 Unix プラットフォームでコンパイルおよび実行するには、次に示すコマンドを実行します:

shell> gcc lcp_simulator.cc
shell> ./a.out

このプログラムには stdio.h 以外の依存関係はなく、NDB クラスタまたは MySQL サーバーへの接続は必要ありません。 デフォルトでは、300 LCP (それぞれ挿入、更新、削除で構成される 100 LCP の 3 つのセット) がシミュレートされ、各 LCP の後に LCP のサイズがレポートされます。 シミュレーションを変更するには、ソースで recovery_work、insert_work および delete_work の値を変更し、再コンパイルします。 詳細は、プログラムのソースを参照してください。

InsertRecoveryWork

挿入された行に使用される RecoveryWork の割合。 値を大きくすると、ローカルチェックポイント中の書き込み数が増加し、LCP の合計サイズが減少します。 値を小さくすると LCP 中の書込み数が減りますが、LCP に使用される領域が増えるため、リカバリに時間がかかります。 このパラメータは、EnablePartialLcp が true の場合、つまり部分的なローカルチェックポイントが有効な場合にのみ有効です。

EnableRedoControl

redo ログの使用を制御するための適応チェックポイント処理速度を有効にします。 無効にするには、false に設定します (デフォルト)。 EnablePartialLcp を false に設定すると、適応計算も無効になります。

EnableRedoControl を有効にすると、LCP をディスクに書き込む速度に関して、データノードの柔軟性が向上します。 具体的には、このパラメータを有効にすると、LCP が完了し、redo ログがより迅速にトリミングされるように、書込み率が高くなり、リカバリ時間とディスク領域要件が削減されます。 この機能により、データノードは、Non-Volatile Memory Express (NVMe) を使用して、ソリッドステートドライブ (SSD) などの最新のソリッドステートストレージデバイスおよびプロトコルから使用可能なより高い速度の I/O およびより高い帯域幅をより効果的に使用できます。

従来のハードディスク (HDD) を使用するシステムなど、ソリッドステートテクノロジを採用するシステムに対して I/O または帯域幅が制約されているシステムに NDB がまだ広くデプロイされているため、このパラメータは現在 false (無効) にデフォルト設定されています。 このような設定では、EnableRedoControl メカニズムによって I/O サブシステムが飽和状態になり、データノードの入出力の待機時間が長くなる可能性があります。 特に、これにより、制約付き IO サブシステムをデータノード LCP および redo ログファイルと共有しているテーブルスペースまたはログファイルグループを持つ「NDB ディスクデータ」テーブルで問題が発生する可能性があります。このような問題には、GCP 停止エラーによるノードまたはクラスタの障害が含まれる可能性があります。

MaxNoOfAttributes

このパラメータは、クラスタに定義できる属性の推奨最大数を設定します。MaxNoOfTables と同様、厳密な上限の役割を果たすためのものではありません。

(古い NDB Cluster リリースでは、このパラメータは特定の操作の強い制限として扱われることがありました。 これにより、NDB Cluster レプリケーションでは、レプリケート可能な数より多くのテーブルを作成できる場合に問題が発生し、状況によっては可能なときに混乱することがあります (または不可能な場合によっては、MaxNoOfAttributes 属性を複数作成することもあります)。)

デフォルト値は 1000 です。指定可能な最小値は 32 です。 最大値は 4294967039 です。 すべてのメタデータがサーバー上で完全にレプリケートされるため、各属性はノードあたり 200 バイト前後のストレージを消費します。

MaxNoOfAttributes を設定するときは、今後実行する可能性がある ALTER TABLE ステートメントを事前に用意することが重要です。 これは、クラスタテーブルで ALTER TABLE の実行中に、元のテーブルに含まれる 3 倍の数の属性が使用されるためであり、この数の 2 倍を許可することをお勧めします。 たとえば、属性 (greatest_number_of_attributes) の数が最大の「NDB Cluster」テーブルに 100 個の属性がある場合、MaxNoOfAttributes の値の適切な開始点は 6 * greatest_number_of_attributes = 600 になります。

また、テーブルあたりの平均属性数を見積もり、それに MaxNoOfTables を掛けることもお勧めします。 この値が前の段落で得られた値より大きい場合は、大きい値を使用するようにしてください。

必要なすべてのテーブルが問題なく作成できると仮定して、パラメータの構成後に実際に ALTER TABLE を試行し、この数が十分であることを確認するようにしてください。 これが成功しなかった場合は、MaxNoOfAttributes をさらに MaxNoOfTables の数だけ増やして、再度テストしてください。

MaxNoOfTables

テーブルオブジェクトは、クラスタ内のテーブルごと、および一意のハッシュインデックスごとに割り当てられます。 このパラメータは、クラスタ全体のテーブルオブジェクトの推奨最大数を設定します。MaxNoOfAttributes と同様、厳密な上限の役割を果たすためのものではありません。

(古い NDB Cluster リリースでは、このパラメータは特定の操作の強い制限として扱われることがありました。 これにより、NDB Cluster レプリケーションで、レプリケート可能な数より多くのテーブルを作成できた場合に問題が発生し、状況によっては、MaxNoOfTables テーブルを複数作成するために可能な場合 (または不可能な場合) に混乱することがありました。)

BLOB データ型を持つ各属性では、BLOB データの大部分を格納するために追加のテーブルが使用されます。 テーブルの合計数を定義するときは、これらのテーブルも考慮に入れる必要があります。

このパラメータのデフォルト値は 128 です。 最小値は 8、最大値は 20320 です。 各テーブルオブジェクトは、ノードあたりおよそ 20K バイトを消費します。

MaxNoOfOrderedIndexes

クラスタ内の順序付けされたインデックスごとに、インデックスされた内容とそのストレージセグメントを記述するオブジェクトが割り当てられます。 デフォルトでは、そのように定義された各インデックスによって、順序付けされたインデックスも定義されます。 個々の一意のインデックスおよび主キーには、順序付けされたインデックスとハッシュインデックスの両方が含まれています。 MaxNoOfOrderedIndexes は、システム内で一度に使用できる順序付けされたインデックスの合計数を設定します。

このパラメータのデフォルト値は 128 です。 各インデックスオブジェクトは、ノードあたりおよそ 10K バイトのデータを消費します。

MaxNoOfUniqueHashIndexes

主キー以外の個々の一意のインデックスには、一意キーをインデックスされたテーブルの主キーにマップする専用のテーブルが割り当てられます。 デフォルトでは、個々の一意のインデックスに対して順序付けされたインデックスも定義されます。 これを禁止するには、一意のインデックスを定義するときに USING HASH オプションを指定する必要があります。

デフォルト値は 64 です。 各インデックスは、ノードあたりおよそ 15K バイトを消費します。

MaxNoOfTriggers

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

クラスタ間のレプリケーションでも、内部トリガーが使用されます。

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

デフォルト値は 768 です。

MaxNoOfSubscriptions

NDB Cluster 内の各 NDB テーブルには、NDB カーネルでのサブスクリプションが必要です。 一部の NDB API アプリケーションでは、このパラメータの変更が必要または望ましい場合があります。 ただし、SQL ノードとして機能する MySQL サーバーを通常どおりに使用する場合は、これを行う必要はありません。

MaxNoOfSubscriptions のデフォルト値は 0 です。これは、MaxNoOfTables と等価として扱われます。 各サブスクリプションは 108 バイトを消費します。

MaxNoOfSubscribers

このパラメータは NDB Cluster レプリケーションを使用している場合にのみ重要です。 デフォルト値は 0 です。 NDB 8.0.25 より前は、これは 2 * MaxNoOfTables として扱われていました。NDB 8.0.25 以降は、2 * MaxNoOfTables + 2 * [number of API nodes]として扱われます。 各 MySQL サーバー (レプリケーションソースとして機能するサーバーとレプリカとして機能するサーバー) には、NDB テーブルごとに 1 つのサブスクリプションがあります。 各サブスクライバは 16 バイトのメモリーを使用します。

循環レプリケーション、マルチソースレプリケーションおよび 2 台を超える MySQL サーバーを含むその他のレプリケーション設定を使用する場合は、このパラメータをレプリケーションに含まれる mysqld プロセスの数に増やす必要があります (多くの場合、これは常にクラスタの数と同じではありません)。 たとえば、3 つの NDB Cluster を使用して循環レプリケーション設定があり、各クラスタに 1 つの mysqld が接続されており、これらの各 mysqld プロセスがソースおよびレプリカとして機能する場合は、MaxNoOfSubscribers を 3 * MaxNoOfTables と同等に設定するようにしてください。

詳細は、セクション23.6「NDB Cluster レプリケーション」を参照してください。

MaxNoOfConcurrentSubOperations

このパラメータは、クラスタ内のすべての API ノードが一度に実行できる操作数の上限を設定します。 通常の操作ではデフォルト値 (256) で十分ですが、API ノードが多数あり、それぞれが大量の操作を同時に実行しているシナリオでのみ、調整が必要になる可能性があります。

CompressedLCP

このパラメータを 1 に設定すると、ローカルチェックポイントが圧縮されます。 使用される圧縮は gzip --fast と同等であり、データノードで非圧縮チェックポイントファイルの格納に必要なスペースの 50% 以上を節約できます。 圧縮 LCP は、個々のデータノードまたは (config.ini ファイルの [ndbd default] セクションにこのパラメータを設定することで) すべてのデータノードで有効化できます。

デフォルト値は 0 (無効) です。

CrashOnCorruptedTuple

このパラメータを有効にすると (デフォルト)、破損したタプルが検出されるたびにデータノードが強制的にシャットダウンされます。

Diskless

「NDB Cluster」テーブルをディスクレスとして指定できます。つまり、テーブルはディスクにチェックポイントされず、ロギングも行われません。 このようなテーブルはメインメモリーにのみ存在します。 ディスクレステーブルを使用すると、クラッシュ発生時にテーブルもテーブル内のレコードも失われます。 ただし、ディスクレスモードで動作するときは、ディスクレスコンピュータで ndbd を実行できます。

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

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

LateAlloc

管理サーバーへの接続が確立されたあとで、このデータノードのメモリーを割り当てます。 デフォルトで有効。

LockPagesInMainMemory

Solaris と Linux を含むいくつかのオペレーティングシステムでは、プロセスをメモリーにロックすると、ディスクへのスワップを回避できます。 これを使用すると、クラスタのリアルタイム特性が保証されやすくなります。

このパラメータは、整数値 0、1、または 2 のいずれかを取ります。これらの機能を次のリストに示します。

権限のないユーザーがページをロックできるようにオペレーティングシステムが構成されていない場合は、このパラメータを利用するデータノードプロセスをシステムの root として実行する必要がある可能性があります。 (LockPagesInMainMemory では、mlockall 関数が使用されます。 Linux kernel 2.6.9 以降では、権限のないユーザーが max locked memory の制限に従ってメモリーをロックできます。 詳細は、ulimit -l および http://linux.die.net/man/2/mlock を参照してください)。

ODirect

このパラメータを有効にすると、NDB が LCP、バックアップ、および Redo ログで O_DIRECT 書き込みを試行し、多くの場合 kswapd と CPU の使用率が低下します。 Linux で NDB Cluster を使用しているときに、2.6 以降のカーネルを使用している場合は ODirect を有効にします。

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

ODirectSyncFlag

このパラメータを有効にすると、完了した各ファイルシステム書込みが fsync へのコールとして処理されるように redo ログ書込みが実行されます。 次のいずれかの条件が満たされている場合、このパラメータの設定は無視されます:

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

RestartOnErrorInsert

この機能は、コードの個々のブロックをテストの一部として実行する際に、エラーの挿入が可能なデバッグバージョンをビルドする場合にのみ利用できます。

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

StopOnError

このパラメータは、データノードプロセスでエラー状態が発生したときに、プロセスを終了するか、自動的に再起動するか指定します。

このパラメータのデフォルト値は 1 です。これは、デフォルトでは、エラーによってデータノードのプロセスが停止することを意味します。

エラーが発生し、StopOnError が 0 の場合は、データノードプロセスが再起動されます。

MySQL Cluster Manager のユーザーは、StopOnError が 1 の場合、これにより、MySQL Cluster Manager エージェントが独自の再起動およびリカバリを実行した後にデータノードを再起動できないことに注意する必要があります。 詳しくはStarting and Stopping the Agent on Linux,をご覧ください。

UseShm

このデータノードと、このホストでも実行されている API ノードとの間の共有メモリー接続を有効にします。 有効にするには 1 に設定します。

TimeBetweenWatchDogCheck

メインスレッドがある時点で無限ループに陥ることを防ぐため、「ウォッチドッグ」スレッドがメインスレッドをチェックします。 このパラメータは、チェック間のミリ秒数を指定します。 プロセスが 3 回のチェック後も同じ状態の場合、ウォッチドッグスレッドはプロセスを強制終了します。

このパラメータは、実験のため、またはローカルの状態に合わせて簡単に変更できます。 これをノード単位で指定することもできますが、指定することはほとんどありません。

デフォルトのタイムアウトは 6000 ミリ秒 (6 秒) です。

TimeBetweenWatchDogCheckInitial

これは TimeBetweenWatchDogCheck パラメータと似ていますが、メモリーが割り当てられる最早開始フェーズで、TimeBetweenWatchDogCheckInitial がストレージノード内の実行チェック間の経過時間を制御する点が異なります。

デフォルトのタイムアウトは 6000 ミリ秒 (6 秒) です。

StartPartialTimeout

このパラメータは、クラスタの初期化ルーチンが呼び出されるまでにクラスタがデータノードの起動を待つ時間を指定します。 このタイムアウトは、可能なかぎり、クラスタの部分的起動を回避するために使用されます。

このパラメータは、クラスタの初期起動または初期再起動の実行時にオーバーライドされます。

デフォルト値は 30000 ミリ秒 (30 秒) です。0 にするとタイムアウトが無効になり、すべてのノードが使用可能な場合にのみクラスタを起動できるようになります。

StartPartitionedTimeout

StartPartialTimeout ミリ秒の待機後にクラスタが起動できる状態になっても、まだパーティション化された状態の可能性がある場合、クラスタはこのタイムアウトが経過するまで待機します。 StartPartitionedTimeout が 0 に設定されている場合、クラスタは無期限に待機します (2³²−1 ミリ秒または約 49.71 日)。

このパラメータは、クラスタの初期起動または初期再起動の実行時にオーバーライドされます。

StartFailureTimeout

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

このパラメータでは、0 以外の値はミリ秒単位で測定されます。 非常に多くのデータを含むデータノードでは、このパラメータを増やすようにしてください。 たとえば、数ギガバイトのデータを含むデータノードの場合、ノードを再起動するのに 10-15 分 (つまり、600000-1000000 ミリ秒) の時間が必要です。

StartNoNodeGroupTimeout

Nodegroup = 65536 でデータノードを構成すると、そのノードはどのノードグループにも割り当てられないものとみなされます。 その場合、クラスタは StartNoNodegroupTimeout ミリ秒待機してから、そのようなノードを --nowait-nodes オプションに渡されたリストに追加されたものとして扱い、起動します。 デフォルト値は 15000 です (つまり、管理サーバーは 15 秒待機します)。 このパラメータを 0 に設定すると、クラスタは無期限に待機します。

StartNoNodegroupTimeout はクラスタ内のすべてのデータノードで同じにする必要があります。そのため、これは個々のデータノードではなく、常に config.ini ファイルの [ndbd default] セクションに設定するようにしてください。

詳細は、セクション23.5.7「NDB Cluster データノードのオンラインでの追加」を参照してください。

HeartbeatIntervalDbDb

障害の発生したノードを検出する主な方法の 1 つは、ハートビートを使用することです。 このパラメータは、ハートビート信号の送信回数と予想される受信回数を指定します。 ハートビートは無効にできません。

行に 4 つのハートビート間隔がない場合、ノードは dead と宣言されます。 したがって、ハートビートメカニズムを使用して障害を検出する最大時間は、ハートビート間隔の 5 倍です。

デフォルトのハートビート間隔は 5000 ミリ秒 (5 秒) です。 このパラメータを大幅に変更しないでください。また、ノード間の違いが大きくならないようにしてください。 あるノードが 5000 ミリ秒を使用し、それを監視しているノードが 1000 ミリ秒を使用している場合、明らかにノードは非常に迅速に dead と宣言されます。 このパラメータはオンラインのソフトウェアアップグレード中に変更できますが、少しずつ増やしてください。

ネットワーク通信と待機時間 および ConnectCheckIntervalDelay 構成パラメータの説明も参照してください。

HeartbeatIntervalDbApi

各データノードは各 MySQL サーバー (SQL ノード) にハートビート信号を送信して、接続されたままであるか確認します。 MySQL サーバーが時間内にハートビートを送信できなかった場合、「デッド」と宣言されます。その場合、進行中のすべてのトランザクションが完了し、リソースが解放されます。 以前の MySQL インスタンスによって開始されたすべてのアクティビティーが完了するまで、SQL ノードは再接続できません。 この判定に使用される 3 ハートビートの条件は、HeartbeatIntervalDbDb で説明したものと同じです。

デフォルトの間隔は 1500 ミリ秒 (1.5 秒) です。 個々のデータノードはほかのすべてのデータノードと関係なく接続中の MySQL サーバーを監視するため、この間隔は各データノードで異なることがあります。

詳細は、ネットワーク通信と待機時間を参照してください。

HeartbeatOrder

データノードは、各データノードが直前のデータノードをモニターする循環的な方法で、相互にハートビートを送信します。 ハートビートが特定のデータノードによって検出されなかった場合、このノードは循環の直前のデータノードを「デッド」 (つまり、クラスタからアクセスできなくなった) と宣言します。 データノードがデッドであるという判定はグローバルに行われます。つまり、データノードがデッドと宣言されると、そのノードはクラスタ内のすべてのノードからそのようにみなされます。

異なるホストに配置されたデータノード間のハートビートが (たとえば、非常に長いハートビート間隔や一時的な接続の問題によって) ほかのノードペア間のハートビートに比べて遅すぎるために、データノードがまだクラスタの一部として機能しているにもかかわらず、デッドと宣言される可能性があります。

このような状況では、データノード間のハートビートの転送順序が、特定のデータノードがデッドと宣言されるかどうかに影響している可能性があります。 この宣言が不必要に発生すると、それがノードグループの損失を招き、さらにクラスタの障害につながる可能性があります。

次の表に示すように、2 台のホストコンピュータ host1 および host2 で実行されている 4 つのデータノード A、B、C、および D があり、これらのデータノードが 2 つのノードグループを構成しているセットアップについて考えます。

ハートビートが 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 値を設定します:

このパラメータを使用して実行中の NDB Cluster 内のハートビート転送順序を変更するには、まずグローバル構成 (config.ini) ファイル内のクラスタ内のデータノードごとに HeartbeatOrder を設定する必要があります。 変更を有効にするには、次のいずれかを実行する必要があります。

DUMP 908 を使用すると、データノードログでこのパラメータの効果を観察できます。

ConnectCheckIntervalDelay

このパラメータは、データノードのいずれかがハートビートチェックに失敗したあと、最大 HeartbeatIntervalDbDb ミリ秒の 5 つの間隔でデータノード間の接続チェックを有効にします。

ConnectCheckIntervalDelay ミリ秒の間隔内でさらに応答に失敗したこのようなデータノードは疑わしいとみなされ、このような間隔が 2 回続くとデッドとみなされます。 これは、待機時間の既知の問題がある設定で役立ちます。

このパラメータのデフォルト値は 0 (無効) です。

TimeBetweenLocalCheckpoints

このパラメータは、新しいローカルポイントを開始するまでの待機時間を指定しないという点で例外です。どちらかといえば、比較的少数の更新が行われるクラスタ内でローカルチェックポイントが実行されないようにするために使用されます。 更新回数が多いほとんどのクラスタでは、直前のローカルチェックポイントが完了した直後に新しいローカルチェックポイントが開始される可能性があります。

前のローカルチェックポイントの開始以降に実行されたすべての書き込み操作のサイズが追加されます。 このパラメータは、4 バイトワードの数の底 2 の対数として指定される点でも例外的です。したがって、デフォルト値の 20 は 4M バイト (4 * 2²⁰) の書き込み操作を意味し、21 は 8M バイトを意味し、最大値の 31 は 8G バイトの書き込み操作と同等です。

クラスタ内のすべての書き込み操作がまとめて追加されます。 TimeBetweenLocalCheckpoints を 6 以下に設定すると、クラスタのワークロードに関係なく、ローカルチェックポイントが一時停止せずに継続的に実行されます。

TimeBetweenGlobalCheckpoints

トランザクションがコミットされると、データがミラー化されているノードのメインメモリーでコミットされます。 ただし、トランザクションログレコードはコミットの一部としてディスクにフラッシュされません。 トランザクションを少なくとも 2 台の自立的なホストマシン上で安全にコミットすることで、持続性に関する妥当な基準が満たされるはずだということがこの動作の根拠です。

また、最悪のケース (クラスタの完全なクラッシュ) も適切に処理されるようにすることが重要です。 この実行を保証するために、特定の間隔以内に行われるすべてのトランザクションはグローバルチェックポイントに取り込まれます。これは、ディスクにフラッシュされたコミット済みのトランザクションとみなすことができます。 つまり、トランザクションはコミットプロセスの一部としてグローバルチェックポイントグループに組み込まれます。 その後、このグループのログレコードがディスクにフラッシュされると、トランザクションのグループ全体がクラスタ内のコンピュータ上のディスクに安全にコミットされます。

NDB 8.0.19 以降では、この値を減らす「ディスクデータ」テーブルでソリッドステートディスク (特に NVMe を採用しているディスク) を使用する場合に推奨されます。 このような場合は、MaxDiskDataLatency が適切なレベルに設定されていることも確認する必要があります。

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

TimeBetweenGlobalCheckpointsTimeout

このパラメータは、グローバルチェックポイント間の最小タイムアウトを定義します。 デフォルトは 120000 ミリ秒です。

TimeBetweenEpochs

このパラメータは、NDB Cluster レプリケーションの同期エポック間の間隔を定義します。 デフォルト値は 100 ミリ秒です。

TimeBetweenEpochs は、NDB Cluster レプリケーションのパフォーマンスを向上させるために使用できる 「micro-GCPs」 の実装の一部です。

TimeBetweenEpochsTimeout

このパラメータは、NDB Cluster レプリケーションの同期エポックのタイムアウトを定義します。 このパラメータで決定された時間内にノードがグローバルチェックポイントに参加できなかった場合、ノードはシャットダウンされます。 デフォルト値は 0 です。つまり、タイムアウトは無効になります。

TimeBetweenEpochsTimeout は、NDB Cluster レプリケーションのパフォーマンスを向上させるために使用できる 「micro-GCPs」 の実装の一部です。

GCP 保存に 1 分より長い時間がかかるか、GCP コミットに 10 秒より長い時間がかかると、このパラメータの現在の値および警告がクラスタログに書き込まれます。

このパラメータを 0 に設定すると、保存のタイムアウト、コミットのタイムアウト、またはその両方によって発生する GCP の停止を無効にします。 このパラメータに指定できる最大値は 256000 ミリ秒です。

MaxBufferedEpochs

サブスクライブするノードが遅延できる未処理のエポック数。 この数を超えると、遅延するサブスクライバが切断されます。

ほとんどの通常の操作では、デフォルト値の 100 で十分です。 サブスクライブするノードの遅延によって切断が発生する場合、その原因は通常、プロセスまたはスレッドに関するネットワークまたはスケジューリングの問題です。 (まれな状況ですが、NDB クライアントのバグによってこの問題が起きることもあります。) エポックが大きいときは、この値をデフォルトより小さく設定するのが望ましい場合もあります。

切断することで、クライアントの問題によってデータノードサービスが影響を受け、データをバッファリングするためのメモリーが不足し、最終的にシャットダウンすることはなくなります。 代わりに、切断の結果として (たとえば、バイナリログのギャップイベントによって) クライアントが影響を受け、クライアントは強制的にプロセスを再接続または再起動します。

MaxBufferedEpochBytes

このノードがエポックをバッファリングするために割り当てるバイトの合計数。

TimeBetweenInactiveTransactionAbortCheck

タイムアウトの処理は、各トランザクションのタイマーをこのパラメータで指定された間隔ごとに 1 回チェックして実行されます。 したがって、このパラメータが 1000 ミリ秒に設定されている場合、すべてのトランザクションのタイムアウトが毎秒 1 回チェックされます。

デフォルト値は 1000 ミリ秒 (1 秒) です。

TransactionInactiveTimeout

このパラメータは、トランザクションが中止されるまでに、同じトランザクション内の操作間で経過が許容される最大時間を指定します。

このパラメータのデフォルトは 4G です (最大も同じです)。 トランザクションがロックを保持する期間が長すぎないようにする必要があるリアルタイムデータベースでは、このパラメータを比較的小さい値に設定するようにしてください。 0 に設定すると、アプリケーションはタイムアウトしません。 単位はミリ秒です。

TransactionDeadlockDetectionTimeout

ノードは、トランザクションを含むクエリーの実行時に、クラスタ内のほかのノードが応答するのを待機してから処理を続行します。 このパラメータは、トランザクションがデータノード内での実行に費やすことができる時間、つまり、トランザクションに参加している各データノードがリクエストを実行するまでトランザクションコーディネータが待機する時間を設定します。

応答の失敗は、次のいずれかの理由で発生します。

このタイムアウトパラメータは、トランザクションが中止されるまでにトランザクションコーディネータが別のノードによるクエリーの実行を待機する時間を指定するもので、ノード障害の処理とデッドロックの検出において重要です。

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

このパラメータの最小は 50 ミリ秒です。

DiskSyncSize

これは、ローカルチェックポイントファイルにデータをフラッシュするまでに格納される最大バイト数です。 これは、パフォーマンスを大幅に低下させる可能性がある書き込みバッファリングを禁止するために行われます。 このパラメータは、TimeBetweenLocalCheckpoints の代わりに使用するためのものではありません。

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

MaxDiskWriteSpeed

この NDB Cluster で (このデータノードまたはその他のデータノードによって) 再起動が行われない場合の、ローカルチェックポイントおよびバックアップ操作によるディスクへの書き込みの最大速度 (バイト/秒) を設定します。

このデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOwnRestart を使用します。 ほかのデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOtherNodeRestart を使用します。 すべての LCP およびバックアップ操作によるディスク書き込みの最小速度を調整するには、MinDiskWriteSpeed を設定します。

MaxDiskWriteSpeedOtherNodeRestart

この NDB Cluster 内の 1 つ以上のデータノードがこのノード以外で再起動されているときの、ローカルチェックポイントおよびバックアップ操作によるディスクへの書き込みの最大速度をバイト/秒単位で設定します。

このデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOwnRestart を使用します。 クラスタ内ではデータノードが再起動されていない場合に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeed を使用します。 すべての LCP およびバックアップ操作によるディスク書き込みの最小速度を調整するには、MinDiskWriteSpeed を設定します。

MaxDiskWriteSpeedOwnRestart

このデータノードの再起動時の、ローカルチェックポイントおよびバックアップ操作によるディスク書き込みの最大速度 (バイト/秒) を設定します。

ほかのデータノードの再起動中に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeedOtherNodeRestart を使用します。 クラスタ内ではデータノードが再起動されていない場合に許可されるディスク書き込みの最大速度を設定するには、MaxDiskWriteSpeed を使用します。 すべての LCP およびバックアップ操作によるディスク書き込みの最小速度を調整するには、MinDiskWriteSpeed を設定します。

MinDiskWriteSpeed

ローカルチェックポイントおよびバックアップ操作によるディスク書き込みの最小速度 (バイト/秒) を設定します。

さまざまな条件下で LCP およびバックアップに許可されるディスク書き込みの最大速度は、パラメータ MaxDiskWriteSpeed、MaxDiskWriteSpeedOwnRestart、および MaxDiskWriteSpeedOtherNodeRestart を使用して調整できます。 詳細は、これらのパラメータの説明を参照してください。

ArbitrationTimeout

このパラメータは、データノードがアービトレーションメッセージに対するアービトレータからの応答を待機する時間を設定します。 これを超えた場合は、ネットワークが切断されたとみなされます。

デフォルト値は 7500 ミリ秒 (7.5 秒) です。

Arbitration

Arbitration パラメータを使用して、このパラメータに指定できる 3 つの値のいずれかに対応するアービトレーションスキームを選択できます。

RestartSubscriberConnectTimeout

このパラメータは、サブスクライブしている API ノードの接続をデータノードが待機する時間を決定します。 このタイムアウトに達すると、「「欠落」」 API ノードはクラスタから切断されます。 このタイムアウトを無効にするには、RestartSubscriberConnectTimeout を 0 に設定します。

このパラメータはミリ秒単位で指定されますが、タイムアウト自体は次に作成される秒単位に解決されます。

UndoIndexBuffer

このパラメータでサイズが設定される Undo インデックスバッファーは、ローカルチェックポイント中に使用されます。 NDB ストレージエンジンは、使用可能な Redo ログとともに、チェックポイントの一貫性に基づくリカバリスキームを使用します。 システム全体の書き込みをブロックせずに一貫性のあるチェックポイントを作成するため、ローカルチェックポイントの実行中に Undo ロギングが行われます。 Undo ロギングは、一度に 1 つのテーブルフラグメントに対してアクティブ化されます。 この最適化が可能なのは、テーブルが完全にメインメモリーに格納されているためです。

Undo インデックスバッファーは、主キーのハッシュインデックスの更新で使用されます。 挿入と削除では、ハッシュインデックスが再編成されます。NDB ストレージエンジンは、すべての物理的な変更をシステムの再起動時に取り消すことができるように、変更を 1 つのインデックスページにマップする Undo ログレコードを書き込みます。 また、ローカルチェックポイントの開始時に、各フラグメントのアクティブな挿入操作も記録します。

読み取りと更新では、ロックビットが設定され、ハッシュインデックスエントリのヘッダーが更新されます。 これらの変更はページ書き込みアルゴリズムによって処理されるため、これらの操作に Undo ロギングは必要ありません。

このバッファーはデフォルトで 2M バイトです。 最小値は 1M バイトです。ほとんどのアプリケーションではこれで十分です。 大規模なトランザクションや大規模な主キーとともに非常に大規模または多数の挿入および削除を実行するアプリケーションでは、このバッファーのサイズを増やす必要がある場合があります。 このバッファーが小さすぎる場合、NDB ストレージエンジンは内部エラーコード 677「Index UNDO buffers overloaded」を発行します。

UndoDataBuffer

このパラメータは、Undo データバッファーのサイズを設定します。Undo データバッファーは、Undo インデックスバッファーとほぼ同じ機能を実行しますが、インデックスメモリーではなくデータメモリーに関して使用されます。 このバッファーは、フラグメントのローカルチェックポイントフェーズで挿入、削除、および更新のために使用されます。

Undo ログエントリは記録される操作が増えるにつれて大きくなる傾向があるため、このバッファーも対応するインデックスメモリーより大きくなります (デフォルト値は 16M バイトです)。

一部のアプリケーションでは、このメモリー量が不必要に大きい場合があります。 そのような場合は、このサイズを最小の 1M バイトに減らすことができます。

ほとんどの場合、このバッファーのサイズを増やす必要はありません。 そのような必要がある場合は、データベースの更新アクティビティーによって発生する負荷をディスクが実際に処理できているかどうかをチェックすることをお勧めします。 このバッファーのサイズを増やしても、ディスクスペースの不足を解消することはできません。

このバッファーが小さすぎて過密状態になった場合、NDB ストレージエンジンは次の内部エラーコードを発行します: 891 (Data UNDO buffers overloaded)。

RedoBuffer

更新アクティビティーも、すべて記録する必要があります。 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 ログイベントに使用される循環バッファーのサイズを制御します。

LogLevelStartup

プロセスの起動中に生成されるイベントのレポートレベル。

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

LogLevelShutdown

ノードの正常なシャットダウンの一部として生成されるイベントのレポートレベル。

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

LogLevelStatistic

主キー読み取りの数、更新の数、挿入の数、バッファーの使用状況に関する情報などの統計イベントのレポートレベル。

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

LogLevelCheckpoint

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

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

LogLevelNodeRestart

ノード再起動中に生成されるイベントのレポートレベル。

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

LogLevelConnection

クラスタノード間の接続によって生成されるイベントのレポートレベル。

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

LogLevelError

クラスタ全体のエラーおよび警告によって生成されるイベントのレポートレベル。 これらのエラーは、ノードの障害の原因にはなりませんが、レポートする価値はあると考えられます。

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

LogLevelCongestion

輻輳によって生成されるイベントのレポートレベル。 これらのエラーは、ノードの障害の原因にはなりませんが、レポートする価値はあると考えられます。

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

LogLevelInfo

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

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

MemReportFrequency

このパラメータは、データノードのメモリー使用状況レポートをクラスタログに記録する頻度を制御します。これは、レポート間の秒数を表す整数値です。

各データノードのデータメモリーとインデックスメモリーの使用量は、config.ini ファイルに設定されている DataMemory のパーセンテージと 32 KB ページの両方として記録されます。 たとえば、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 です。この場合は、セクション23.5.3.2「NDB Cluster ログイベント」の統計イベントの説明で指摘したように、メモリー使用量が特定の割合 (80%、90%、および 100%) に達したときにのみ、メモリーのレポートが記録されます。

StartupStatusReportFrequency

--initial を指定してデータノードを起動すると、起動フェーズ 4 (セクション23.5.4「NDB Cluster 起動フェーズのサマリー」を参照してください) で Redo ログファイルが初期化されます。 NoOfFragmentLogFiles、FragmentLogFileSize、またはその両方に非常に大きな値を設定すると、この初期化に長い時間がかかることがあります。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 ログファイルの初期化プロセスの開始時と完了時にのみ、レポートがクラスタログに書き込まれます。

DictTrace

DictTrace を使用してテーブルを作成および削除することで、生成されたイベントのトレースをロギングできます。 このパラメータは、NDB のカーネルコードをデバッグする場合にのみ役立ちます。 DictTrace は整数値を取ります。デフォルトは 0 で、ロギングは実行されません。1 はトレースロギングを有効にし、2 は追加の DBDICT デバッグ出力のロギングを有効にします。

WatchdogImmediateKill

WatchdogImmediateKill データノード構成パラメータを有効にすると、ウォッチドッグの問題が発生するたびにスレッドがただちに強制終了されるようにできます。 このパラメータは、デバッグまたはトラブルシューティング時にのみ使用し、実行が中止された瞬間の発生を正確にレポートするトレースファイルを取得します。

BackupDataBufferSize

バックアップの作成では、データをディスクに転送するために使用される 2 つのバッファーがあります。 バックアップデータバッファーは、ノードのテーブルをスキャンして記録されるデータを書き込むために使用されます。 このバッファーへの書き込みが BackupWriteSize で指定されたレベルに達すると、ページがディスクに転送されます。 バックアッププロセスでは、データをディスクにフラッシュしながら、スペースがなくなるまでこのバッファーに書き込み続けることができます。 これが発生すると、バックアッププロセスでスキャンを一時停止し、ディスク書き込みがある程度完了してメモリーが解放され、スキャンを続行できるようになるまで待機します。

このパラメータのデフォルト値は 16M バイトです。 最小値は 512K です。

BackupDiskWriteSpeedPct

通常の操作中、データノードはローカルチェックポイントおよびバックアップに使用されるディスク書き込み速度を最大化しようとしますが、MinDiskWriteSpeed および MaxDiskWriteSpeed によって設定された範囲内に残ります。 ディスク書き込みスロットルにより、各 LDM スレッドに合計予算の均等なシェアが与えられます。 これにより、ディスク I/O 予算を超えずにパラレル LCP を実行できます。 バックアップは 1 つの LDM スレッドによってのみ実行されるため、事実上、これによって予算の停止が発生し、バックアップ完了時間が長くなります。また、バックアップログバッファの充填率が達成可能な書込み率よりも高い場合に、変更率が十分に高くなってバックアップを完了できない場合です。

この問題に対処するには、LCP の LDM スレッド間で残りの予算を共有する前に予約されているノード最大書込みレート予算の割合として解釈される、0-90 (含む) の範囲の値をとる BackupDiskWriteSpeedPct 構成パラメータを使用します。 バックアップを実行している LDM スレッドは、バックアップの書き込みレート予算全体と、ローカルチェックポイントの書き込みレート予算の (削減された) シェアを受け取ります。

このパラメータのデフォルト値は 50 (50% として解釈) です。

BackupLogBufferSize

バックアップログバッファーはバックアップデータバッファーと同じような役割を果たしますが、バックアップの実行中に行われたテーブル書き込みのログを生成するために使用されます。 これらのページの書き込みにはバックアップデータバッファーと同じ原則が適用されますが、バックアップログバッファーのスペースがなくなると、バックアップは失敗します。 そのため、バックアップログバッファーのサイズは、バックアップ実行中の書き込みアクティビティーによって発生する負荷を処理するのに十分な大きさである必要があります。 セクション23.5.8.3「NDB Cluster バックアップの構成」を参照してください。

ほとんどのアプリケーションでは、このパラメータのデフォルト値で十分です。 実際、バックアップログバッファーがいっぱいになった場合より、ディスク書き込みの速度が不十分な場合の方が、バックアップが失敗する可能性は高くなります。 ディスクサブシステムがアプリケーションから発生する書き込み負荷に合わせて構成されていない場合は、クラスタが必要な操作を実行できない可能性が高くなります。

ディスクやネットワーク接続よりもプロセッサがボトルネックになるような方法でクラスタノードを構成することをお勧めします。

このパラメータのデフォルト値は 16M バイトです。

BackupMemory

このパラメータは非推奨であり、NDB Cluster の将来のバージョンで削除される可能性があります。 設定はすべて無視されます。

BackupReportFrequency

このパラメータは、バックアップ中に管理クライアントでバックアップステータスレポートを発行する頻度と、そのようなレポートをクラスタログに書き込む頻度を制御します (クラスタイベントロギングで許可するように構成されている場合。ロギングとチェックポイントを参照してください)。 BackupReportFrequency は、バックアップステータスレポート間の時間 (秒単位) を表します。

デフォルト値は 0 です。

BackupWriteSize

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

このパラメータのデフォルト値は 256K バイトです。

BackupMaxWriteSize

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

このパラメータのデフォルト値は 1M バイトです。

CompressedBackup

このパラメータを有効にすると、バックアップファイルが圧縮されます。 使用される圧縮は gzip --fast と同等であり、データノードで非圧縮バックアップファイルの格納に必要なスペースの 50% 以上を節約できます。 圧縮バックアップは、個々のデータノードまたは (config.ini ファイルの [ndbd default] セクションにこのパラメータを設定することで) すべてのデータノードで有効化できます。

デフォルト値は 0 (無効) です。

RequireEncryptedBackup

1 に設定した場合、バックアップを暗号化する必要があります。 このパラメータはデータノードごとに個別に設定できますが、config.ini グローバル構成ファイルの[ndbd default]セクションで設定することをお勧めします。 暗号化バックアップの実行の詳細は、セクション23.5.8.2「NDB Cluster 管理クライアントを使用したバックアップの作成」 を参照してください。

NDB 8.0.22 に追加されました。

BackupDataBufferSize >= BackupWriteSize + 188K バイト

BackupLogBufferSize >= BackupWriteSize + 16K バイト

BackupMaxWriteSize >= BackupWriteSize

BuildIndexThreads

このパラメータは、システムまたはノードの起動中に順序付けされたインデックスの再構築時、および ndb_restore --rebuild-indexes の実行時に作成するスレッドの数を指定します。 これは、データノードごとにテーブルに複数のフラグメントがある場合 (たとえば、COMMENT="NDB_TABLE=PARTITION_BALANCE=FOR_RA_BY_LDM_X_2"が CREATE TABLE とともに使用されている場合) にのみサポートされます。

このパラメータを 0 (デフォルト) に設定すると、順序付けられたインデックスのマルチスレッド作成が無効になります。

このパラメータは、ndbd または ndbmtd を使用するときにサポートされます。

TwoPassInitialNodeRestartCopy データノード構成パラメータを TRUE に設定することで、データノードの初期再起動時にマルチスレッドビルドを有効にできます。

LockExecuteThreadToCPU

ndbd で使用する場合、このパラメータ (現在は文字列) は NDBCLUSTER の実行スレッドを処理するために割り当てられる CPU の ID を指定します。 ndbmtd で使用する場合、このパラメータの値は実行スレッドを処理するために割り当てられる CPU ID のカンマ区切りリストです。 リスト内の各 CPU ID は、0-65535 の (これらを含む) 範囲の整数にします。

指定する ID の数は、MaxNoOfExecutionThreads によって指定される実行スレッドの数と一致するようにしてください。 ただし、このパラメータを使用したときに、特定の順序でスレッドが CPU に割り当てられる保証はありません。 ThreadConfig を使用すると、このようなより細かい制御が可能になります。

LockExecuteThreadToCPU にデフォルト値はありません。

LockMaintThreadsToCPU

このパラメータは、NDBCLUSTER の管理スレッドを処理するために割り当てられる CPU の ID を指定します。

このパラメータの値は、0-65535 の (これらを含む) 範囲の整数です。 デフォルト値はありません。

Numa

このパラメータは、Non-Uniform Memory Access (NUMA) がオペレーティングシステムまたはデータノードプロセスのどちらによって制御されるかを決定します (データノードで ndbd と ndbmtd のどちらを使用するか)。 デフォルトでは、NDB は、ホストオペレーティングシステムが NUMA サポートを提供する任意のデータノードでインターリーブ NUMA メモリー割当てポリシーを使用しようとします。

Numa = 0 を設定することは、datanode プロセス自体がメモリー割当てのポリシーを設定しようとせず、この動作をオペレーティングシステムによって決定できることを意味します。これは、別の numactl ツールによってさらにガイドされる場合があります。 つまり、Numa = 0 ではシステムのデフォルト動作が生成されますが、これは numactl でカスタマイズできます。 多くの Linux システムでは、システムのデフォルトの動作は、ソケットローカルメモリーを割当て時に任意のプロセスに割り当てることです。 これは、ndbmtd の使用時に問題になる可能性があります。これは、特にメインメモリー内のページをロックするときに、nbdmtd が起動時にすべてのメモリーを割り当てるため、不均衡になり、ソケットごとに異なるアクセス速度が与えられるためです。

Numa = 1 を設定することは、データノードプロセスが libnuma を使用してインターリーブされたメモリー割り当てを要求することを意味します。 (これは、numactl を使用して、オペレーティングシステムレベルで手動で実行することもできます。) インターリーブ割り当てを有効に使用すると、データノードプロセスは不均一なメモリーアクセスを無視するように指示されますが、高速なローカルメモリーを利用しようとすることはありません。代わりに、データノードプロセスは、低速なリモートメモリーによる不均衡を回避しようとします。 インターリーブ割当てが望ましくない場合は、オペレーティングシステムレベルで目的の動作を決定できるように、Numa を 0 に設定します。

Numa 構成パラメータは、libnuma.so が使用可能な Linux システムでのみサポートされます。

RealtimeScheduler

このパラメータを 1 に設定すると、データノードスレッドのリアルタイムスケジューリングが有効になります。

デフォルトは 0 (スケジューリングが無効) です。

SchedulerExecutionTimer

このパラメータは、スレッドがスケジューラで実行されてから送信されるまでの時間 (ミリ秒) を指定します。 これを 0 に設定すると、応答時間が最小化されます。スループットを向上させるため、この値を増やすことができますが、その代償として応答時間は長くなります。

デフォルトは 50 マイクロ秒です。弊社のテストでは、これによって高負荷のケースで実質的に要求を遅延させずにスループットが若干向上することがわかっています。

SchedulerResponsiveness

速度とスループットのバランスを NDB スケジューラで設定します。 このパラメータは、値が 0-10 の範囲の整数を取ります。デフォルトは 5 です。 値を大きくすると、スループットと比較してレスポンス時間が向上します。 値を小さくするとスループットが向上しますが、レスポンス時間は長くなります。

SchedulerSpinTimer

このパラメータは、スレッドがスケジューラで実行されてからスリープ状態になるまでの時間 (ミリ秒) を指定します。

NDB 8.0.20 以降では、SpinMethod が設定されている場合、このパラメータの設定は無視されます。

SpinMethod

このパラメータは、次のリストに示すように、スピンパラメータ値に事前設定された 4 つの値を使用して、データノード上の適応スピンを制御する単純なインタフェースを提供します:

次のリストに、SpinMethod によって変更されるスピンパラメータを示します:

PowerPC や一部の SPARC プラットフォームなど、使用可能なスピン命令がないプラットフォームでは、スピン時間はすべての状況で 0 に設定され、StaticSpinning 以外の SpinMethod の値は無視されます。

TwoPassInitialNodeRestartCopy

順序付けされたインデックスのマルチスレッド構築は、この構成パラメータを true (デフォルト値) に設定することで、データノードの初期再起動のために有効にできます。これにより、ノードの初期再起動時にデータの 2 パスコピーが可能になります。

同時に BuildIndexThreads を 0 以外の値に設定する必要があります。

AutomaticThreadConfig

1 に設定すると、taskset、numactl、仮想マシン、Docker など、特定のアプリケーションで使用可能な CPU の制限を考慮して、データノードで使用可能な CPU の数を自動的に使用可能にします (Windows プラットフォームでは、自動スレッド構成はオンラインのすべての CPU を使用します)。または、NumCPUs を必要な CPU の数 (最大 1024、自動スレッド構成で処理可能な CPU の最大数) に設定できます。 ThreadConfig および MaxNoOfExecutionThreads の設定は無視されます。

ClassicFragmentation

有効 (true に設定) にすると、NDB は LDM 間でのテーブルの断片の柔軟な分散を使用します。 つまり、ノードごとのデフォルトのパーティション数は、データノードごとの LDM スレッドの最小数ではなく PartitionsPerNode と等しくなり、各テーブルのパーティション数はデータノードの数の 4 倍 (PartitionsPerNode のデフォルト) になります。

NDB 8.0.22 以前へのダウングレードが発生することが予想されない新しいクラスタの場合は、クラスタを最初に設定するときに ClassicFragmentation を false に設定することをお勧めします。これにより、すべてのパーティションがすべての LDM 間で均等に分散されます。

MaxNoOfExecutionThreads

このパラメータは、ndbmtd で使用される実行スレッドの数を最大 72 まで直接制御します。 このパラメータは、config.ini ファイルの [ndbd] または [ndbd default] セクションに設定しますが、ndbmtd 専用であり、ndbd には適用されません。

MaxNoOfExecutionThreads を設定すると、ファイル storage/ndb/src/kernel/vm/mt_thr_config.cpp のマトリックスによって決定されるタイプごとのスレッド数が設定されます。 このテーブルは、MaxNoOfExecutionThreads の可能な値に対するこれらのスレッド数を示しています。

SUMA (レプリケーション) スレッドは常に 1 つです。

NoOfFragmentLogParts は、このパラメータの設定によって決定される、ndbmtd で使用される LDM スレッドの数と同じに設定する必要があります。 この比率は 4:1 以下にする必要があります。このような場合の構成は特に禁止されています。

LDM スレッドの数によって、明示的にパーティション化されていない NDB テーブルで使用されるパーティションの数も決まります。これは、LDM スレッドの数にクラスタ内のデータノードの数を掛けた数です。 (ndbmtd ではなくデータノードで ndbd が使用されている場合、常に単一の LDM スレッドが存在します。この場合、自動的に作成されるパーティションの数はデータノードの数と同じになります。 詳しくはセクション23.1.2「NDB Cluster ノード、ノードグループ、フラグメントレプリカ、およびパーティション」,をご覧ください。

デフォルト数を超える LDM スレッドを使用している場合に「ディスクデータ」テーブルに大きなテーブルスペースを追加すると、ディスクページバッファが十分に大きくないと、リソースおよび CPU 使用率に問題が発生する可能性があります。詳細は、DiskPageBufferMemory 構成パラメータの説明を参照してください。

スレッドタイプについては、このセクションで後述します (ThreadConfig を参照してください)。

このパラメータを許容範囲外の値に設定すると、管理サーバーの起動が中止され、次のエラーが発生します: Error line number: Illegal value value for parameter MaxNoOfExecutionThreads。

MaxNoOfExecutionThreads では、値 0 または 1 は NDB の内部で 2 に切り上げられるため、2 がこのパラメータのデフォルト値および最小値とみなされます。

MaxNoOfExecutionThreads は、通常、使用可能な CPU スレッド数と同じ値に設定し、各タイプのスレッド数を一般的なワークロードに合わせて割り当てることを目的としています。 指定された CPU に特定のスレッドを割り当てるものではありません。 提供された設定を変更することが望ましい場合や、スレッドを CPU にバインドする場合は、代わりに必要なタイプ、CPU、またはその両方に直接スレッドを割り当てることができる ThreadConfig を使用するようにしてください。

マルチスレッドデータノードプロセスは常に、少なくとも次のスレッドを生成します:

MaxNoOfExecutionThreads 値が 8 以下の場合、TC スレッドは作成されず、かわりに TC 処理がメインスレッドによって実行されます。

LDM スレッドの数を変更するには、通常、このパラメータを使用して変更するか ThreadConfig を使用して変更するかに関係なく、システムの再起動が必要ですが、次の 2 つの条件が満たされている場合は、ノードの初期再起動 (NI) を使用して変更を有効にできます:

NDB 8.0 では、NDB Cluster の一部の古いバージョンであったため、このパラメータの変更を有効にするために初期再起動は必要ありません。

NoOfFragmentLogParts

この ndbmtd に属する Redo ログのログファイルグループの数を設定します。 このパラメータの値は、MaxNoOfExecutionThreads の設定によって決定される、ndbmtd で使用される LDM スレッドの数と同じに設定する必要があります。 LDM ごとに 4 つ以上の redo ログ部分を使用する構成は許可されていません。

詳細は、MaxNoOfExecutionThreads の説明を参照してください。

NumCPUs

自動スレッド構成では、この数の CPU のみが使用されます。 AutomaticThreadConfig が有効になっていない場合は無効です。

PartitionsPerNode

新しい NDB テーブルの作成時に各ノードで使用されるパーティションの数を設定します。 これにより、ローカルデータマネージャ (LDM) の数が増加した場合に、テーブルを過剰な数のパーティションに分割することを回避できます。

このパラメータは異なるデータノード上で異なる値に設定でき、そのための既知の問題はありませんが、グローバル config.ini ファイルの[ndbd default]セクションですべてのデータノードに対して一度だけ設定することをお勧めします。

ThreadConfig

このパラメータは、ndbmtd で異なるタイプのスレッドを別の CPU に割り当てるために使用されます。 この値は、次の構文を持つ形式の文字列です。

ThreadConfig := entry[,entry[,...]]

entry := type={param[,param[,...]]}

type (NDB 8.0.22 and earlier) := ldm | main | recv | send | rep | io | tc | watchdog | idxbld

type (NDB 8.0.23 and later) := ldm | query | recover | main | recv | send | rep | io | tc | watchdog | idxbld

param := count=number
  | cpubind=cpu_list
  | cpuset=cpu_list
  | spintime=number
  | realtime={0|1}
  | nosend={0|1}
  | thread_prio={0..10}
  | cpubind_exclusive=cpu_list
  | cpuset_exclusive=cpu_list

リストにパラメータが 1 つしかない場合でも、パラメータのリストを囲む中カッコ ({...}) は必須です。

param (パラメータ) は、次の情報のいずれかまたはすべてを指定します:

プラットフォーム別の thread_prio の設定および効果.  thread_prio の実装は、Linux/FreeBSD、Solaris および Windows で異なります。 次のリストでは、これらの各プラットフォームへの影響について順に説明します:

type 属性は、NDB のスレッドタイプを表します。 次のリストに、サポートされるスレッドタイプと、それぞれに許可される count 値の範囲を示します:

ThreadCOnfig を変更するには通常、システムの初期再起動が必要ですが、この要件は特定の状況下で緩和できます:

それ以外の場合は、このパラメータを変更するためにシステムの初期再起動が必要です。

NDB では、次の両方の基準によってスレッドタイプを区別できます:

簡単な例:

# 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 にバインドできます。

次の例では、cpuset と cpubind の両方を使用して定義された CPU のグループ、およびスレッド優先順位付けの使用を組み込みます。

ThreadConfig=ldm={count=4,cpuset=0-3,thread_prio=8,spintime=200}, \
ldm={count=4,cpubind=4-7,thread_prio=8,spintime=200}, \
tc={count=4,cpuset=8-9,thread_prio=6},send={count=2,thread_prio=10,cpubind=10-11}, \
main={count=1,cpubind=10},rep={count=1,cpubind=11}

この場合、2 つの LDM グループを作成します。最初の LDM グループは cpubind を使用し、2 つ目の LDM グループは cpuset を使用します。thread_prio と spintime は、グループごとに同じ値に設定されます。 これは、LDM スレッドの合計が 8 つあることを意味します。 (NoOfFragmentLogParts も 8 に設定されていることを確認してください。) 4 つの TC スレッドは 2 つの CPU のみを使用します。cpuset を使用して、グループ内のスレッドより少ない CPU を指定することは可能です。 (これは、cpubind には当てはまりません。) 送信スレッドは、cpubind を使用してこれらのスレッドを CPU 10 および 11 にバインドする 2 つのスレッドを使用します。 メインスレッドおよびレポートスレッドは、これらの CPU を再利用できます。

この例では、オペレーティングシステムの機能および割込みで CPU 10、11、22 および 23 を使用可能なままにして、ハイパースレッドを使用する 24 CPU ホストに ThreadConfig および NoOfFragmentLogParts を設定する方法を示します:

NoOfFragmentLogParts=10
ThreadConfig=ldm={count=10,cpubind=0-4,12-16,thread_prio=9,spintime=200}, \
tc={count=4,cpuset=6-7,18-19,thread_prio=8},send={count=1,cpuset=8}, \
recv={count=1,cpuset=20},main={count=1,cpuset=9,21},rep={count=1,cpuset=9,21}, \
io={count=1,cpuset=9,21,thread_prio=8},watchdog={count=1,cpuset=9,21,thread_prio=9}

次のいくつかの例には、idxbld の設定が含まれます。 これらのうち最初の 2 つは、idxbld に定義された CPU セットが他の (永続的な) スレッドタイプに指定された CPU セットとオーバーラップする方法を示しています。最初に cpuset を使用し、次に cpubind を使用します:

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
io={cpubind=8},idxbld={cpuset=1-8}

ThreadConfig=main,ldm={count=1,cpubind=1},idxbld={count=1,cpubind=1}

次の例では、I/O スレッドの CPU を指定しますが、インデックス構築スレッドの CPU は指定しません:

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
io={cpubind=8}

ThreadConfig 設定では、1 から 8 の番号が付けられた 8 つのコアにスレッドがロックされるため、ここに示す設定と同等です:

ThreadConfig=main,ldm={count=4,cpuset=1-4},tc={count=4,cpuset=5,6,7}, \
io={cpubind=8},idxbld={cpuset=1,2,3,4,5,6,7,8}

ThreadConfig を使用することで得られる高い安定性を生かすには、CPU が隔離されていて、割り込みを受けたり、オペレーティングシステムによってほかのタスクをスケジュールされたりしない必要があります。 多くの Linux システムでは、/etc/sysconfig/irqbalance の IRQBALANCE_BANNED_CPUS を 0xFFFFF0 に設定し、grub.conf の isolcpus ブートオプションを使用することで、これを実現できます。 具体的な情報については、オペレーティングシステムまたはプラットフォームのドキュメントを参照してください。

DiskPageBufferEntries

これは、割り当てるページエントリ (ページ参照) の数です。 これは、DiskPageBufferMemory で 32K ページの数として指定されます。 ほとんどの場合、デフォルトで十分ですが、「ディスクデータ」テーブルで非常に大きなトランザクションに問題が発生した場合は、このパラメータの値を増やす必要があります。 各ページエントリには約 100 バイトが必要です。

DiskPageBufferMemory

これは、ディスク上のページをキャッシュするために使用されるスペースの量を指定するもので、config.ini ファイルの [ndbd] または [ndbd default] セクションで設定されます。

ThreadConfig ({ldm=6...} など) でデフォルト数を超える LDM スレッドを使用する場合に DiskPageBufferMemory の値が小さすぎると、大きな (500G などの) データファイルをディスクベースの NDB テーブルに追加しようとしたときに問題が発生することがあり、CPU コアのいずれかを占有している間、プロセスが無限に長くなる可能性があります。

これは、テーブルスペースへのデータファイルの追加の一環としてエクステントページが PGMAN ワーカースレッドでメモリーにロックされ、メタデータにすばやくアクセスできるためです。 大きいファイルを追加する場合、このワーカーにはすべてのデータファイルメタデータに対して十分なメモリーがありません。 このような場合は、DiskPageBufferMemory を増やすか、小さいテーブルスペースファイルを追加する必要があります。 DiskPageBufferEntries の調整が必要になる場合もあります。

ndbinfo.diskpagebuffer テーブルをクエリーすると、不要なディスクシークを最小限に抑えるためにこのパラメータの値を増やすべきかどうか判定しやすくなります。 詳細は、セクション23.5.14.27「ndbinfo diskpagebuffer テーブル」を参照してください。

SharedGlobalMemory

このパラメータは、テーブルスペース、ログファイルグループ、Undo ファイル、およびデータファイル用のログバッファー、ディスク操作 (ページ要求や待機キューなど)、およびメタデータに使用されるメモリーの量を指定します。 共有グローバルメモリープールは、CREATE LOGFILE GROUP および ALTER LOGFILE GROUP ステートメントで使用される UNDO_BUFFER_SIZE オプションのメモリー要件を満たすために使用されるメモリーも提供します。これには、InitialLogFileGroup データノード構成パラメータの設定によってこのオプションに暗黙的に指定されるデフォルト値も含まれます。 SharedGlobalMemory は、config.ini 構成ファイルの [ndbd] または [ndbd default] セクションに設定でき、バイト単位で測定されます。

デフォルト値は 128M です。

DiskIOThreadPool

このパラメータは、ディスクデータファイルへのアクセスに使用される未バインドスレッドの数を指定します。 DiskIOThreadPool が導入される前は、ディスクデータファイルごとに 1 つのスレッドしか生成されなかったため、特に非常に大きいデータファイルを使用する場合に、パフォーマンスの問題が発生する可能性がありました。 DiskIOThreadPool を使用すると、たとえば、並列で動作する複数のスレッドを使用して 1 つの大きなデータファイルにアクセスできます。

このパラメータは、ディスクデータ I/O スレッドにのみ適用されます。

このパラメータの最適な値は、使用しているハードウェアと構成によって異なり、次の要因を含みます。

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

ディスクデータのファイルシステムパラメータ.  次のリストのパラメータを使用すると、シンボリックリンクを使用しなくても NDB Cluster ディスクデータファイルを特定のディレクトリに配置できます。

詳細は、セクション23.5.10.1「NDB Cluster ディスクデータオブジェクト」を参照してください。

ディスクデータのオブジェクト作成パラメータ.  次の 2 つのパラメータを使用すると、クラスタを最初に起動したときに、SQL ステートメントを使用せずにディスクデータのログファイルグループ、テーブルスペース、またはその両方を作成できます。

ディスクデータ待機時間パラメータ.  ここにリストされている 2 つのパラメータを使用して、「NDB Cluster ディスクデータ」テーブルの待機時間の問題の処理を改善できます。

ExtraSendBufferMemory

このパラメータは、TotalSendBufferMemory、SendBufferMemory、またはその両方を使用して設定されたメモリーに加えて割り当てられるトランスポータ送信バッファーメモリーの量を指定します。

TotalSendBufferMemory

このパラメータは、すべての構成済みトランスポータ間で共有される送信バッファーメモリーの、このノードに割り当てられるメモリー合計量を決定するために使用されます。

このパラメータが設定されている場合、許可される最小値は 256KB です。0 はパラメータが設定されていないことを示します。 詳細は、セクション23.3.3.14「NDB Cluster 送信バッファーパラメータの構成」 を参照してください。

RedoOverCommitCounter

特定の Redo ログをディスクに書き込もうとしたときに RedoOverCommitLimit を超過した回数がこの回数を超えると、結果としてコミットされなかったトランザクションはすべて中止され、トランザクションの発生元である API ノードは、これらのトランザクションを構成する操作を DefaultOperationRedoProblemAction の値に従って (操作をキューに入れて再試行するか、中止して) 処理します。

RedoOverCommitLimit

このパラメータは、特定の Redo ログをディスクに書き込もうとしたときにタイムアウトするまでの上限 (秒単位) を設定します。 データノードがこの Redo ログをフラッシュしようとして RedoOverCommitLimit よりも長い時間がかかった回数が保存され、RedoOverCommitCounter と比較されます。フラッシュにかかる時間が長すぎた回数がこのパラメータの値より多くなったときは、フラッシュタイムアウトの結果としてコミットされなかったトランザクションがすべて中止されます。 これが発生すると、トランザクションの発生元である API ノードは、これらのトランザクションを構成する操作を DefaultOperationRedoProblemAction の設定に従って (操作をキューに入れて再試行するか、中止することで) 処理します。

StartFailRetryDelay

このパラメータを使用して、データノードによる起動失敗時の再試行間の秒数を設定します。 デフォルトは 0 (遅延なし) です。

StopOnError が 0 でない場合は、このパラメータと MaxStartFailRetries の両方が無視されます。

MaxStartFailRetries

このパラメータを使用して、データノードによる起動失敗時の再試行回数を制限します。 デフォルトは 3 回です。

StopOnError が 0 でない場合は、このパラメータと StartFailRetryDelay の両方が無視されます。

IndexStatAutoCreate

インデックスの作成時に自動統計収集を有効 (1 に設定) または無効 (0 に設定) にします。 デフォルトで無効になっています。

IndexStatAutoUpdate

インデックスの変更の監視を有効化 (1 に設定) または無効化 (0 に設定) し、これらの自動統計更新をトリガーします。 更新をトリガーするために必要な変更の量およびレベルは、IndexStatTriggerPct および IndexStatTriggerScale オプションの設定によって決定されます。

IndexStatSaveSize

NDB システムテーブルおよび mysqld メモリーキャッシュに保存される特定のインデックスの統計に対して許容される最大スペース (バイト単位)。

サイズ制限に関係なく、常に少なくとも 1 つのサンプルが生成されます。 このサイズは、IndexStatSaveScale によってスケーリングされます。

大規模なインデックスでは、IndexStatSaveSize に指定されたサイズが IndexStatTriggerPct に 0.01 を掛けた値によって調整されます。 これにはさらに、インデックスサイズの 2 を底とする対数が乗算されます。 IndexStatTriggerPct を 0 に設定すると、この調整が無効になります。

IndexStatSaveScale

大規模なインデックスでは、IndexStatSaveSize に指定されたサイズが IndexStatTriggerPct に 0.01 を掛けた値によって調整されます。 これにはさらに、インデックスサイズの 2 を底とする対数が乗算されます。 IndexStatTriggerPct を 0 に設定すると、この調整が無効になります。

IndexStatTriggerPct

インデックス統計更新をトリガーする更新内の変更割合。 この値は、IndexStatTriggerScale によって調整されます。 このトリガーを完全に無効にするには、IndexStatTriggerPct を 0 に設定します。

IndexStatTriggerScale

大規模なインデックスでは、この量に 0.01 を掛けた値で IndexStatTriggerPct を調整します。 値 0 で調整が無効になります。

IndexStatUpdateDelay

特定のインデックスの自動インデックス統計更新間の最小遅延 (秒数)。 この変数を 0 に設定すると、遅延が無効になります。 デフォルトは 60 秒です。