MySQL :: MySQL 8.0 リファレンスマニュアル :: 23.3.3.6 NDB Cluster データノードの定義

9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / ... / NDB Cluster データノードの定義

このページは機械翻訳したものです。

23.3.3.6 NDB Cluster データノードの定義

クラスタのデータノードの動作を構成するには、[ndbd] および [ndbd default] セクションを使用します。

データノードのプロセスとして ndbd バイナリと ndbmtd バイナリのどちらを使用する場合でも、セクション名としては常に [ndbd] と [ndbd default] が使用されます。

バッファーサイズ、プールサイズ、タイムアウトなどを制御する数多くのパラメータがあります。唯一の必須パラメータは、ExecuteOnComputer または HostName のいずれかです。これは、ローカルの [ndbd] セクションで定義する必要があります。

NoOfReplicas パラメータは、すべてのクラスタデータノードに共通であるため、[ndbd default] セクションに定義してください。 NoOfReplicas を設定する必要は必ずしもありませんが、これを明示的に設定することをお勧めします。

ほとんどのデータノードパラメータは [ndbd default] セクションに設定します。 [ndbd] セクションでの変更が許可されるのは、ローカル値の設定を明示的に規定されているパラメータだけです。 HostName、NodeId、および ExecuteOnComputer (存在する場合) は、config.ini のほかのセクションではなく、ローカルの [ndbd] で定義する必要があります。つまり、これらのパラメータの設定は 1 つのデータノードに固有のものです。

メモリー使用状況やバッファーサイズに影響を与えるパラメータでは、1024、1024 * 1024、または 1024 * 1024 * 1024 の単位を示すサフィクスとして K、M、または G を使用できます。 (たとえば、100K は 100 * 1024 = 102400 を意味します。)

MySQL Server my.cnf または my.ini ファイルで使用されている場合を除き、パラメータ名および値では大/小文字が区別されません。

「NDB Cluster ディスクデータ」テーブルに固有の構成パラメータの詳細は、このセクション (ディスクデータの構成パラメータを参照) で後述します。

これらのパラメータはすべて、ndbmtd (ndbd のマルチスレッドバージョン) にも適用されます。追加の 3 つのデータノード構成パラメータ (MaxNoOfExecutionThreads、ThreadConfig、および NoOfFragmentLogParts) は、ndbmtd にのみ適用されます。これらを ndbd に使用しても、無効になります。詳細は、マルチスレッドの構成パラメータ (ndbmtd)を参照してください。セクション23.4.3「ndbmtd — NDB Cluster データノードデーモン (マルチスレッド)」も参照してください。

データノードの識別. NodeId または Id の値 (つまり、データノードの識別子) は、ノード起動時のコマンド行、または構成ファイルで割り当てることができます。

NodeId

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	[...]
範囲	1 - 48
バージョン (またはそれ以降)	NDB 8.0.18
タイプまたは単位	unsigned
デフォルト	[...]
範囲	1 - 144
再起動タイプ	IS (NDB 8.0.13)

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

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

ExecuteOnComputer

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	name
デフォルト	[...]
範囲	...
非推奨	Yes (in NDB 7.5)
再起動タイプ	S (NDB 8.0.13)

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

重要

このパラメータは非推奨であり、将来のリリースで削除される予定です。かわりに HostName パラメータを使用してください。

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

HostName

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	name or IP address
デフォルト	localhost
範囲	...
再起動タイプ	N (NDB 8.0.13)

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

ServerPort

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	[...]
範囲	1 - 64K
再起動タイプ	S (NDB 8.0.13)

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

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

注記

データノードから管理ノードへの接続は、ndb_mgmd 管理ポート (管理サーバー PortNumber) を使用して行われるため、任意のデータノードからそのポートへの送信接続は常に許可されます。

TcpBind_INADDR_ANY

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

NodeGroup

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	[...]
範囲	0 - 65536
再起動タイプ	IS (NDB 8.0.13)

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

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

LocationDomainId

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 16
再起動タイプ

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

リクエストされたデータが同じノードで見つからない場合、読取りは同じ可用性ドメイン内の別のノードに転送できます。
異なる可用性ドメイン内のノード間の通信では、それ以上の手動操作なしで NDB トランスポータ WAN サポートを使用することが保証されています。
トランスポータグループ番号は、SQL および他の API ノードが可能な場合は常に同じ可用性ドメイン内のローカルデータノードと通信するように、使用される可用性ドメインに基づくことができます。
アービトレータは、データノードが存在しない可用性ドメインから選択することも、そのような可用性ドメインが見つからない場合は 3 番目の可用性ドメインから選択することもできます。

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

NoOfReplicas

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	2
範囲	1 - 2
バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	integer
デフォルト	2
範囲	1 - 4
再起動タイプ	IS (NDB 8.0.13)

このグローバルパラメータは、[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 に設定すると、本番で完全にテストされ、サポートされます。

警告

NoOfReplicas を 1 に設定することは、すべてのクラスタデータのコピーが 1 つだけ存在することを意味します。この場合は、そのデータに格納されているデータの追加のコピーが存在しないため、1 つのデータノードの喪失によってクラスタが機能停止します。

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

DataDir

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	path
デフォルト	.
範囲	...
再起動タイプ	IN (NDB 8.0.13)

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

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

FileSystemPath

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	path
デフォルト	DataDir
範囲	...
再起動タイプ	IN (NDB 8.0.13)

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

注記

このディレクトリは、ndbd プロセスが開始される前に存在している必要があります。

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

BackupDataDir

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	path
デフォルト	FileSystemPath
範囲	...
再起動タイプ	IN (NDB 8.0.13)

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

重要

この値の末尾には常に '/BACKUP' という文字列が追加されます。たとえば、BackupDataDir の値を /var/lib/cluster-data に設定すると、すべてのバックアップが /var/lib/cluster-data/BACKUP の下に格納されます。これは、事実上のデフォルトのバックアップ場所が FileSystemPath パラメータで指定された場所の下にある BACKUP という名前のディレクトリであることも意味しています。

データメモリー、インデックスメモリー、および文字列メモリー

DataMemory と IndexMemory は、実際のレコードとインデックスの格納に使用されるメモリーセグメントのサイズを指定する [ndbd] パラメータです。これらの値を設定する場合、DataMemory の使用方法を理解することが重要です。これは通常、クラスタによる実際の使用状況を反映するために更新する必要があるためです。

注記

IndexMemory は非推奨であり、NDB Cluster の将来のバージョンで削除される可能性があります。詳細は、次の説明を参照してください。

DataMemory

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	98M
範囲	1M - 1T
バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	bytes
デフォルト	98M
範囲	1M - 16T
再起動タイプ	N (NDB 8.0.13)

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

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 オプションの設定」を参照)。

注記

以前のバージョンの「NDB Cluster」では、「NDB Cluster」テーブルに追加のパーティションを作成できるため、CREATE TABLE の MAX_ROWS オプションを使用してハッシュインデックスに使用可能なメモリーを増やすことができました。下位互換性のために引き続きサポートされていますが、この目的で MAX_ROWS を使用することは非推奨です。かわりに PARTITION_BALANCE を使用する必要があります。

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

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

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

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

大規模なトランザクションは小規模なトランザクションより高速に実行できません
大規模なトランザクションでは、トランザクション障害の発生時に消失して繰り返す必要がある操作の数が多くなります
大規模なトランザクションはより多くのメモリーを使用します

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

IndexMemory

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	0
範囲	1M - 1T
非推奨	Yes (in NDB 7.6)
再起動タイプ	N (NDB 8.0.13)

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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	% or bytes
デフォルト	25
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	S (NDB 8.0.13)

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

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

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

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

次の例は、1 つのテーブルでメモリーがどのように使用されるかを示しています。このテーブル定義について考えます。

CREATE TABLE example (
  a INT NOT NULL,
  b INT NOT NULL,
  c INT NOT NULL,
  PRIMARY KEY(a),
  UNIQUE(b)
) ENGINE=NDBCLUSTER;

各レコードに、12 バイトのデータと 12 バイトのオーバーヘッドがあります。 NULL 可能カラムがない場合は、4 バイトのオーバーヘッドを節約できます。さらに、カラム a および b に対して 2 つの順序付けされたインデックスがあり、レコードごとにおよそ 10 バイトが消費されます。ベーステーブルには主キーのハッシュインデックスがあり、レコードあたりおよそ 29 バイトが使用されます。 b を主キーとし、a をカラムとする別のテーブルによって一意の制約が実装されています。この別のテーブルでは、8 バイトのレコードデータと 12 バイトのオーバーヘッドに加えて、example テーブル内のレコードあたり 29 バイトのインデックスメモリーが追加で消費されます。

したがって、100 万個のレコードに対して、主キーと一意の制約のハッシュインデックスを処理するには 58M バイトのインデックスメモリーが必要です。さらに、ベーステーブルのレコード、一意のインデックステーブル、および 2 つの順序付けされたインデックステーブルに 64M バイトが必要です。

ハッシュインデックスがかなりのメモリー量を占有しますが、データへのアクセスは非常に高速になります。また、NDB Cluster で一意性制約を処理するためにも使用されます。

現在、唯一のパーティション化アルゴリズムはハッシュ化であり、順序付けされたインデックスは各ノードでローカルに使用されます。したがって、一般的なケースで順序付けされたインデックスを使用して一意制約を処理することはできません。

IndexMemory と DataMemory の両方で重要な点は、各ノードグループのすべてのデータメモリーとインデックスメモリーの合計がデータベースの合計サイズになることです。各ノードグループはレプリケートされた情報の格納に使用されるため、2 つのフラグメントレプリカを持つ 4 つのノードがある場合は、2 つのノードグループがあります。したがって、使用可能なデータメモリーの合計はデータノードごとに 2 * DataMemory です。

すべてのノードで DataMemory と IndexMemory を同じ値に設定することを強くお勧めします。データの分布はクラスタ内のすべてのノードで均等であるため、各ノードで使用できるスペースの最大量はクラスタ内でもっとも小さいノードの最大量と同じになります。

DataMemory は変更できますが、それを減らすとリスクが高くなる可能性があります。そうすると、メモリー領域が不足しているためにノードまたは NDB Cluster 全体が再起動できなくなる可能性があります。これらの値を増やすことは問題ありませんが、このようなアップグレードはソフトウェアのアップグレードと同じ方法で行うことをお勧めします。つまり、最初に構成ファイルを更新し、次に管理サーバーを起動して、各データノードを順に再起動します。

MinFreePct. DataMemory を含むデータノードリソースの比率 (デフォルトでは 5%) は、再起動の実行時にデータノードがメモリーを使い果たさないように予約されています。これは、MinFreePct データノード構成パラメータを使用して調整できます (デフォルトは 5)。

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	5
範囲	0 - 100
再起動タイプ	N (NDB 8.0.13)

更新によって、使用されるインデックスメモリーの量は増えません。挿入はただちに有効になりますが、行の削除はトランザクションがコミットされるまで実際には行われません。

トランザクションパラメータ. 次に説明する [ndbd] のいくつかのパラメータは、システムで処理できる並列トランザクションの数とトランザクションのサイズに影響を与えるという点で重要です。 MaxNoOfConcurrentTransactions は、ノード内で実行できる並列トランザクションの数を設定します。 MaxNoOfConcurrentOperations は、同時に更新フェーズに入ったり、ロックしたりできるレコードの数を設定します。

これらのパラメータはどちらも (特に MaxNoOfConcurrentOperations は)、デフォルト値を使用せずに特定の値を設定するユーザーのターゲットになる可能性があります。デフォルト値は、小規模なトランザクションを使用するシステムで過大なメモリーが使用されないように設定されています。

MaxDMLOperationsPerTransaction は、特定のトランザクションで実行できる DML 操作の最大数を設定します。

MaxNoOfConcurrentTransactions

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	4096
範囲	32 - 4294967039 (0xFFFFFEFF)
非推奨	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

トランザクションレコードは、個々の 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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	32K
範囲	32 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

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

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

デフォルト値は 32768 です。

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

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

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

MaxNoOfLocalOperations

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	UNDEFINED
範囲	32 - 4294967039 (0xFFFFFEFF)
非推奨	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

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

MaxDMLOperationsPerTransaction

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	operations (DML)
デフォルト	4294967295
範囲	32 - 4294967295
再起動タイプ	N (NDB 8.0.13)

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

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

トランザクションの一時ストレージ. 次の一連の [ndbd] パラメータは、クラスタトランザクションの一部であるステートメントの実行時に一時ストレージを決定するために使用されます。このステートメントが完了し、クラスタがコミットまたはロールバックを待機しているときに、すべてのレコードが解放されます。

これらのパラメータのデフォルト値は、ほとんどの状況に適しています。ただし、多数の行または操作が関与するトランザクションをサポートする必要がある場合は値を増やして、システム内の並列性を高める必要があることがあります。一方、比較的小規模なトランザクションを必要とするアプリケーションでは、これらの値を減らしてメモリーを節約できます。

MaxNoOfConcurrentIndexOperations

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	8K
範囲	0 - 4294967039 (0xFFFFFEFF)
非推奨	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

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

MaxNoOfFiredTriggers

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	4000
範囲	0 - 4294967039 (0xFFFFFEFF)
非推奨	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

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

TransactionBufferMemory

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	1M
範囲	1K - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

トランザクションリソース割当てパラメータ. 次のリストのパラメータは、トランザクションコーディネータ (DBTC) でトランザクションリソースを割り当てるために使用されます。これらのいずれかをデフォルト (0) に設定したままにすると、対応するリソースの推定合計データノード使用量の 25% のトランザクションメモリー専用になります。これらのパラメータに指定できる実際の最大値は、通常、データノードで使用可能なメモリー量によって制限されます。これらの値を設定しても、データノードに割り当てられるメモリーの合計量には影響しません。また、MaxDMLOperationsPerTransaction, MaxNoOfConcurrentIndexOperations, MaxNoOfConcurrentOperations, MaxNoOfConcurrentScans, MaxNoOfConcurrentTransactions, MaxNoOfFiredTriggers, MaxNoOfLocalScans または TransactionBufferMemory の設定に関係なく、データノード用に予約された内部レコードの数を制御することに注意する必要があります (トランザクションパラメータおよびトランザクションの一時ストレージを参照)。

ReservedConcurrentIndexOperations

バージョン (またはそれ以降)	NDB 8.0.16
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
追加	NDB 8.0.16
再起動タイプ	N (NDB 8.0.13)

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

ReservedConcurrentOperations

バージョン (またはそれ以降)	NDB 8.0.16
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
追加	NDB 8.0.16
再起動タイプ	N (NDB 8.0.13)

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

ReservedConcurrentScans

バージョン (またはそれ以降)	NDB 8.0.16
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
追加	NDB 8.0.16
再起動タイプ	N (NDB 8.0.13)

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

ReservedConcurrentTransactions

バージョン (またはそれ以降)	NDB 8.0.16
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
追加	NDB 8.0.16
再起動タイプ	N (NDB 8.0.13)

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

ReservedFiredTriggers

バージョン (またはそれ以降)	NDB 8.0.16
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
追加	NDB 8.0.16
再起動タイプ	N (NDB 8.0.13)

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

ReservedLocalScans

バージョン (またはそれ以降)	NDB 8.0.16
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
追加	NDB 8.0.16
再起動タイプ	N (NDB 8.0.13)

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

ReservedTransactionBufferMemory

バージョン (またはそれ以降)	NDB 8.0.16
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
追加	NDB 8.0.16
非推奨	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

TransactionMemory

バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	bytes
デフォルト	0
範囲	0 - 16384G
追加	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

多くの構成パラメータは、TransactionMemory と互換性がありません。これらのいずれかが設定されている場合、トランザクションメモリーは NDB 8.0.19 より前の状態で計算されます。これらのパラメータのいずれも TransactionMemory と同時に設定できないことに注意してください。設定しようとすると、管理サーバーを起動できません (TransactionMemory と互換性のないパラメータを参照)。
TransactionMemory が設定されている場合、この値はトランザクションメモリーの決定に使用されます。
互換性のないパラメータも TransactionMemory も設定されていない場合、トランザクションメモリーは NDB によって DataMemory 構成パラメータの値の 10% に設定されます。

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

MaxNoOfConcurrentIndexOperations
MaxNoOfFiredTriggers
MaxNoOfLocalOperations
MaxNoOfLocalScans

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

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

スキャンとバッファリング. (ndb/src/kernel/blocks/Dblqh/Dblqh.hpp 内の) Dblqh モジュールには、読み取りと更新に影響を与える追加の [ndbd] パラメータがあります。これらには、デフォルトで 10000 * 128 バイト (1250K バイト) に設定される ZATTRINBUF_FILESIZE と、デフォルトで 10000 * 16 バイト (およそ 156K バイト) のバッファースペースに設定される ZDATABUF_FILE_SIZE が含まれます。これまでに、これらのコンパイル時制限のいずれかを増やすことを示すユーザーからの報告または弊社の大規模なテストの結果はありません。

BatchSizePerLocalScan

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	256
範囲	1 - 992
非推奨	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

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

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

LongMessageBuffer

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	64M
範囲	512K - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

MaxFKBuildBatchSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	64
範囲	16 - 512
再起動タイプ

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

MaxNoOfConcurrentScans

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	256
範囲	2 - 500
再起動タイプ	N (NDB 8.0.13)

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

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

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

MaxNoOfLocalScans

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	4 * MaxNoOfConcurrentScans * [# of data nodes] + 2
範囲	32 - 4294967039 (0xFFFFFEFF)
非推奨	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

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

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

MaxParallelCopyInstances

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 64
再起動タイプ

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

MaxParallelScansPerFragment

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	256
範囲	1 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

MaxReorgBuildBatchSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	64
範囲	16 - 512
再起動タイプ

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

MaxUIBuildBatchSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	64
範囲	16 - 512
再起動タイプ

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

メモリー割り当て

MaxAllocate

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	32M
範囲	1M - 1G
再起動タイプ	N (NDB 8.0.13)

これは、テーブル用のメモリーを割り当てるときに使用するメモリーユニットの最大サイズです。 NDB で「メモリー不足」エラーが発生したが、使用可能なすべてのメモリーがまだ使用されていないことをクラスタログまたは DUMP 1000 の出力を調べることで明らかになる場合は、このパラメータの値 (MaxNoOfTables またはその両方) を増やして、NDB で十分なメモリーを使用できるようにすることができます。

複数のトランスポータ

バージョン 8.0.20 以降、NDB はデータノードのペア間の通信に複数のトランスポータを割り当てます。このように割り当てられたトランスポータの数は、そのリリースで導入された NodeGroupTransporters パラメータに適切な値を設定することによって影響を受ける可能性があります。

NodeGroupTransporters

バージョン (またはそれ以降)	NDB 8.0.20
タイプまたは単位	integer
デフォルト	0
範囲	0 - 32
追加	NDB 8.0.20
再起動タイプ	N (NDB 8.0.13)

このパラメータは、同じノードグループ内のノード間で使用されるトランスポータの数を決定します。デフォルト値 (0) は、使用されるトランスポータの数がノード内の LDM の数と同じであることを意味します。ほとんどのユースケースではこれで十分です。したがって、この値をデフォルトから変更する必要はほとんどありません。

NodeGroupTransporters を LDM スレッドの数または TC スレッドの数 (いずれか大きい方) より大きい値に設定すると、NDB はこれらの 2 つのスレッドの最大数を使用します。つまり、これより大きい値は事実上無視されます。

ハッシュマップサイズ

DefaultHashMapSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	LDM threads
デフォルト	240
範囲	0 - 3840
再起動タイプ	N (NDB 8.0.13)

このパラメータの元の使用目的は、アップグレードを容易にし、特にデフォルトのハッシュマップサイズが異なる非常に古いリリースとの間のダウングレードを容易にすることでした。 NDB Cluster 7.3 以降から新しいバージョンにアップグレードする場合、これは問題ではありません。

DefaultHashMapSize を 3840 に設定してテーブルを作成または変更したあと、オンラインでこのパラメータを減らす方法は、現在サポートされていません。

ロギングとチェックポイント. 次の [ndbd] パラメータは、ログとチェックポイントの動作を制御します。

FragmentLogFileSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	16M
範囲	4M - 1G
再起動タイプ	IN (NDB 8.0.13)

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

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

InitialNoOfOpenFiles

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	files
デフォルト	27
範囲	20 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

デフォルト値は 27 です。

InitFragmentLogFiles

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	[see values]
デフォルト	SPARSE
範囲	SPARSE, FULL
再起動タイプ	IN (NDB 8.0.13)

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

SPARSE フラグメントログファイルがまばらに作成されます。これはデフォルト値です。
FULL。フラグメントログファイルのすべてのバイトが強制的にディスクに書き込まれます。

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

EnablePartialLcp

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	true
範囲	...
再起動タイプ	N (NDB 8.0.13)

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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	second
デフォルト	60
範囲	0 - 4294967039 (0xFFFFFEFF)
バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	second
デフォルト	180
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

MaxNoOfOpenFiles

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	0
範囲	20 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

MaxNoOfSavedMessages

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	25
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

MaxLCPStartDelay

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	seconds
デフォルト	0
範囲	0 - 600
再起動タイプ	N (NDB 8.0.13)

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

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

NoOfFragmentLogFiles

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	16
範囲	3 - 4294967039 (0xFFFFFEFF)
再起動タイプ	IN (NDB 8.0.13)

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

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

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

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

重要

このパラメータは「実行中に」変更できません。--initial を使用してノードを再起動する必要があります。実行中のクラスタのすべてのデータノードでこの値を変更する必要がある場合は、(各データノードの起動時に --initial を使用して) ノードのローリング再起動を使用します。

RecoveryWork

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	60
範囲	25 - 100
再起動タイプ	N (NDB 8.0.13)

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

LCP ごとに書き込まれるレコードが少なくなり、LCP はより多くの領域を使用
再起動中にさらに作業が必要

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

LCP ごとに書き込まれるレコードは増えますが、LCP で必要なディスク上の領域は少なくなります。
再起動中の作業が少なくなり、通常の操作中の作業が増えますが、再起動が速くなります

たとえば、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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	40
範囲	0 - 70
再起動タイプ	N (NDB 8.0.13)

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

EnableRedoControl

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	...
再起動タイプ	N (NDB 8.0.13)

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 停止エラーによるノードまたはクラスタの障害が含まれる可能性があります。

メタデータオブジェクト. 次の一連の [ndbd] パラメータは、インデックス、イベント、およびクラスタ間のレプリケーションで使用される属性、テーブル、インデックス、およびトリガーオブジェクトの最大数を定義するために使用されるメタデータオブジェクトのプールサイズを定義します。

注記

これらはクラスタに対する「「提案」」としてのみ機能し、指定されていないものは表示されているデフォルト値に戻ります。

MaxNoOfAttributes

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	1000
範囲	32 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

このパラメータは、クラスタに定義できる属性の推奨最大数を設定します。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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	128
範囲	8 - 20320
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

注記

MaxNoOfTables、MaxNoOfOrderedIndexes、および MaxNoOfUniqueHashIndexes の合計が 2³² - 2 (4294967294) を超えないようにする必要があります。

MaxNoOfOrderedIndexes

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	128
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

注記

MaxNoOfTables、MaxNoOfOrderedIndexes、および MaxNoOfUniqueHashIndexes の合計が 2³² - 2 (4294967294) を超えないようにする必要があります。

MaxNoOfUniqueHashIndexes

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	64
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

注記

MaxNoOfTables、MaxNoOfOrderedIndexes、および MaxNoOfUniqueHashIndexes の合計が 2³² - 2 (4294967294) を超えないようにする必要があります。

MaxNoOfTriggers

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	768
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

デフォルト値は 768 です。

MaxNoOfSubscriptions

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

MaxNoOfSubscribers

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

このパラメータは 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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	256
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

ブールパラメータ. データノードの動作は、ブール値を取る一連の [ndbd] パラメータにも影響されます。これらの各パラメータは、TRUE として指定する場合は 1 または Y に設定し、FALSE として指定する場合は 0 または N に設定します。

CompressedLCP

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
再起動タイプ	N (NDB 8.0.13)

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

重要

圧縮ローカルチェックポイントを、この機能をサポートしない MySQL バージョンを実行するクラスタにリストアすることはできません。

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

CrashOnCorruptedTuple

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	true
範囲	true, false
再起動タイプ

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

Diskless

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	true\|false (1\|0)
デフォルト	false
範囲	true, false
再起動タイプ	IS (NDB 8.0.13)

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

重要

この機能を使用すると、クラスタ全体がディスクレスモードで動作します。

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

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

LateAlloc

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	1
範囲	0 - 1
再起動タイプ	N (NDB 8.0.13)

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

LockPagesInMainMemory

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 2
再起動タイプ	N (NDB 8.0.13)

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

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

0: ロックを無効にします。これはデフォルト値です。
1: プロセスのメモリーを割り当てたあとでロックを実行します。
2: プロセスのメモリーを割り当てる前にロックを実行します。

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

注記

古い NDB Cluster リリースでは、このパラメータはブールでした。0 または false がデフォルト設定で、ロックが無効になっています。1 または true は、メモリーの割当て後にプロセスのロックを有効にしました。 NDB Cluster 8.0 は、このパラメータの値として true または false をエラーとして扱います。

重要

glibc 2.10 以降では、glibc が共有プールでのロック競合を減らすためにスレッド単位のアリーナを使用し、これによって実メモリーが消費されます。通常、データノードプロセスは起動後にメモリー割り当てを実行しないため、スレッド単位のアリーナを必要としません。 (このアロケータの違いがパフォーマンスに重大な影響を与えることはありません。)

この glibc の動作は MALLOC_ARENA_MAX 環境変数を使用して構成できるようになっていますが、glibc 2.16 より前では、このメカニズムのバグが原因でこの変数を 8 未満に設定できなかったため、無駄になったメモリーを再利用できませんでした。 (Bug #15907219。この問題の詳細は、http://sourceware.org/bugzilla/show_bug.cgi?id=13137 も参照してください。)

この問題の考えられる回避策は、LD_PRELOAD 環境変数を使用して jemalloc メモリー割り当てライブラリをプリロードし、glibc に付属するライブラリの代わりに使用することです。

ODirect

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
再起動タイプ	N (NDB 8.0.13)

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

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

ODirectSyncFlag

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
再起動タイプ	N (NDB 8.0.13)

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

ODirect が有効になっていません。
InitFragmentLogFiles は SPARSE に設定されています。

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

RestartOnErrorInsert

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	error code
デフォルト	2
範囲	0 - 4
再起動タイプ	N (NDB 8.0.13)

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

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

StopOnError

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	1
範囲	0, 1
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

UseShm

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
再起動タイプ

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

タイムアウト、間隔、およびディスクページングの制御

クラスタデータノード内のさまざまなアクション間のタイムアウトと間隔を指定する、いくつかの [ndbd] パラメータがあります。ほとんどのタイムアウト値はミリ秒単位で指定します。この例外については、該当する箇所で説明します。

TimeBetweenWatchDogCheck

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	6000
範囲	70 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

TimeBetweenWatchDogCheckInitial

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	6000
範囲	70 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

StartPartialTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	30000
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

StartPartitionedTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

StartFailureTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

StartNoNodeGroupTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	15000
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

HeartbeatIntervalDbDb

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	5000
範囲	10 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

HeartbeatIntervalDbApi

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	1500
範囲	100 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

HeartbeatOrder

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	0
範囲	0 - 65535
再起動タイプ	S (NDB 8.0.13)

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

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

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

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

表 23.10 2 台のホストコンピュータ host1、host2 で実行されている 4 つのデータノード A、B、C、D。各データノードは、2 つのノードグループのいずれかに属します。

ノードグループ	`host1` で実行されているノード	`host2` で実行されているノード
ノードグループ 0:	ノード A	ノード B
ノードグループ 1:	ノード C	ノード D

ハートビートが A->B->C->D->A の順に転送されるとします。この場合、ホスト間のハートビートが失われると、ノード B がノード A をデッドと宣言し、ノード C が B をデッドと宣言します。この結果、ノードグループ 0 が失われるため、クラスタが機能停止します。一方、転送の順序が A->B->D->C->A である (およびほかのすべての条件が前述のままである) 場合は、ハートビートが失われると、ノート A および D がデッドと宣言されます。この場合、各ノードグループに 1 つずつノードが残っているため、クラスタは存続します。

HeartbeatOrder 構成パラメータは、ユーザーがハートビートの転送順序を構成できるようにします。 HeartbeatOrder のデフォルト値は 0 です。すべてのデータノードでデフォルト値を使用できるようにすると、ハートビートの転送順序は NDB によって決定されます。このパラメータを使用する場合は、クラスタ内のすべてのデータノードで 0 以外の値 (最大 65535) に設定する必要があります。また、この値は各データノードで一意である必要があります。これにより、ハートビートが HeartbeatOrder 値の小さいノードから大きいノードに順に転送される (その後、HeartbeatOrder がもっとも大きいノードからもっとも小さいノードに転送され、循環が完結する) ようになります。値は連続している必要はありません。たとえば、前述のシナリオでハートビート転送順序 A->B->D->C->A を強制するには、次に示すように HeartbeatOrder 値を設定します:

表 23.11 A->B->D->C->A のハートビート遷移順序を強制する HeartbeatOrder 値。

ノード	`HeartbeatOrder` 値
A	10
B	20
C	30
D	25

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

クラスタ全体の完全なシャットダウンと再起動。
2 回連続のクラスタのローリング再起動。 両方のローリング再起動で、すべてのノードが同じ順序で再起動される必要があります。

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

ConnectCheckIntervalDelay

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

TimeBetweenLocalCheckpoints

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	number of 4-byte words, as base-2 logarithm
デフォルト	20
範囲	0 - 31
再起動タイプ	N (NDB 8.0.13)

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

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

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

TimeBetweenGlobalCheckpoints

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	2000
範囲	20 - 32000
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

TimeBetweenGlobalCheckpointsTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	120000
範囲	10 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

TimeBetweenEpochs

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	100
範囲	0 - 32000
再起動タイプ	N (NDB 8.0.13)

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

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

TimeBetweenEpochsTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	0
範囲	0 - 256000
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

MaxBufferedEpochs

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	epochs
デフォルト	100
範囲	0 - 100000
再起動タイプ	N (NDB 8.0.13)

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

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

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

MaxBufferedEpochBytes

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	26214400
範囲	26214400 (0x01900000) - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

TimeBetweenInactiveTransactionAbortCheck

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	1000
範囲	1000 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

TransactionInactiveTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	4294967039 (0xFFFFFEFF)
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

TransactionDeadlockDetectionTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	1200
範囲	50 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

ノードが「デッド」です
操作がロックキューに入りました
アクションの実行を要求したノードに非常に高い負荷がかかっている可能性があります。

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

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

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

DiskSyncSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	4M
範囲	32K - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

注記

ODirect が有効になっている場合は、DiskSyncSize を設定する必要はありません。実際、そのような場合は、その値が無視されます。

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

MaxDiskWriteSpeed

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	20M
範囲	1M - 1024G
再起動タイプ	S (NDB 8.0.13)

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

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

MaxDiskWriteSpeedOtherNodeRestart

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	50M
範囲	1M - 1024G
再起動タイプ	S (NDB 8.0.13)

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

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

MaxDiskWriteSpeedOwnRestart

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	200M
範囲	1M - 1024G
再起動タイプ	S (NDB 8.0.13)

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

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

MinDiskWriteSpeed

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	10M
範囲	1M - 1024G
再起動タイプ	S (NDB 8.0.13)

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

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

ArbitrationTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	milliseconds
デフォルト	7500
範囲	10 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

Arbitration

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	enumeration
デフォルト	Default
範囲	Default, Disabled, WaitExternal
再起動タイプ	N (NDB 8.0.13)

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

デフォルト. この場合は、管理および API ノードの ArbitrationRank 設定で指定されるとおりに、アービトレーションが正常に進行します。これはデフォルト値です。
Disabled. config.ini ファイルの [ndbd default] セクションに Arbitration = Disabled を設定すると、すべての管理および API ノードで ArbitrationRank の 0 を設定した場合と同じ結果が得られます。 Arbitration をこのように設定すると、ArbitrationRank の設定はすべて無視されます。
WaitExternal. Arbitration パラメータを使用して、クラスタが内部でアービトレーションを処理する代わりに ArbitrationTimeout で指定された時間が経過するまで外部のクラスタマネージャーアプリケーションによるアービトレーションの実行を待機する方法で、アービトレーションを構成することもできます。これを行うには、config.ini ファイルの [ndbd default] セクションに Arbitration = WaitExternal を設定します。 WaitExternal の設定で最良の結果を得るためには、ArbitrationTimeout を外部クラスタマネージャーがアービトレーションを実行するのに必要な間隔の 2 倍に設定することをお勧めします。

重要

このパラメータは、クラスタ構成ファイルの [ndbd default] セクションでのみ使用するようにしてください。 Arbitration を個々のデータノードで異なる値に設定すると、クラスタの動作は不特定になります。

RestartSubscriberConnectTimeout

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	ms
デフォルト	12000
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ

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

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

バッファリングとロギング. 上級ユーザーは、いくつかの [ndbd] 構成パラメータを使用するとことで、ノードプロセスが使用するリソースをより細かく制御したり、必要に応じてさまざまなバッファーサイズを調整したりできます。

これらのバッファーは、ログレコードをディスクに書き込む際に、ファイルシステムに対するフロントエンドとして使用されます。ノードがディスクレスモードで実行されている場合は、NDB ストレージエンジンのファイルシステム抽象化レイヤーによってディスク書き込みが「偽装」されるため、ペナルティーなしでこれらのパラメータを最小値に設定できます。

UndoIndexBuffer

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	2M
範囲	1M - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

重要

ローリング再起動中にこのパラメータの値を減らすのは安全ではありません。

UndoDataBuffer

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	16M
範囲	1M - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

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

重要

ローリング再起動中にこのパラメータの値を減らすのは安全ではありません。

RedoBuffer

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	32M
範囲	1M - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

更新アクティビティーも、すべて記録する必要があります。 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 8.0.13
タイプまたは単位	bytes
デフォルト	8192
範囲	0 - 64K
再起動タイプ	S (NDB 8.0.13)

データノード内部の NDB ログイベントに使用される循環バッファーのサイズを制御します。

ログメッセージの制御. クラスタの管理では、stdout に送信されるさまざまなイベントタイプのログメッセージ数を制御できることが非常に重要です。イベントカテゴリごとに、16 個の設定可能なイベントレベル (番号 0-15) があります。特定のイベントカテゴリのイベントレポートをレベル 15 に設定すると、そのカテゴリのすべてのイベントレポートが stdout に送信されます。0 に設定すると、そのカテゴリのイベントレポートは作成されません。

デフォルトでは、起動メッセージのみが stdout に送信され、残りのイベントレポートのレベルはデフォルトの 0 に設定されます。これは、これらのメッセージが管理サーバーのクラスタログにも送信されるためです。

管理クライアントで同じようなレベルのセットを設定すると、クラスタログに記録するイベントのレベルを指定できます。

LogLevelStartup

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	1
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelShutdown

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelStatistic

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelCheckpoint

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	log level
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelNodeRestart

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelConnection

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelError

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelCongestion

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	level
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

LogLevelInfo

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0 - 15
再起動タイプ	N (NDB 8.0.13)

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

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

MemReportFrequency

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

各データノードのデータメモリーとインデックスメモリーの使用量は、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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	seconds
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

--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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	undefined
範囲	0 - 100
再起動タイプ	N (NDB 8.0.13)

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

WatchdogImmediateKill

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
再起動タイプ

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

バックアップパラメータ. このセクションで説明する [ndbd] パラメータは、オンラインバックアップの実行用に確保されるメモリーバッファーを定義します。

BackupDataBufferSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	16M
範囲	512K - 4294967039 (0xFFFFFEFF)
非推奨	Yes (in NDB 7.6)
再起動タイプ	N (NDB 8.0.13)

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

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

BackupDiskWriteSpeedPct

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	percent
デフォルト	50
範囲	0 - 90
再起動タイプ	N (NDB 8.0.13)

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

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

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

BackupLogBufferSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	16M
範囲	2M - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

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

BackupMemory

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	32M
範囲	0 - 4294967039 (0xFFFFFEFF)
非推奨	Yes (in NDB 7.4)
再起動タイプ	N (NDB 8.0.13)

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

BackupReportFrequency

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	seconds
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

デフォルト値は 0 です。

BackupWriteSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	256K
範囲	32K - 4294967039 (0xFFFFFEFF)
非推奨	Yes (in NDB 7.6)
再起動タイプ	N (NDB 8.0.13)

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

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

BackupMaxWriteSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	1M
範囲	256K - 4294967039 (0xFFFFFEFF)
非推奨	Yes (in NDB 7.6)
再起動タイプ	N (NDB 8.0.13)

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

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

CompressedBackup

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
再起動タイプ	N (NDB 8.0.13)

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

重要

圧縮バックアップを、この機能をサポートしない MySQL バージョンを実行するクラスタにリストアすることはできません。

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

RequireEncryptedBackup

バージョン (またはそれ以降)	NDB 8.0.22
タイプまたは単位	integer
デフォルト	0
範囲	0 - 1
追加	NDB 8.0.22
再起動タイプ	N (NDB 8.0.13)

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

NDB 8.0.22 に追加されました。

注記

バックアップファイルの場所は、BackupDataDir データノード構成パラメータによって決まります。

追加要件. これらのパラメータを指定するときは、次の関係が有効である必要があります。そうしないと、データノードを起動できません。

BackupDataBufferSize >= BackupWriteSize + 188K バイト
BackupLogBufferSize >= BackupWriteSize + 16K バイト
BackupMaxWriteSize >= BackupWriteSize

NDB Cluster のリアルタイムパフォーマンスパラメータ

このセクションで説明する [ndbd] パラメータは、マルチプロセッサのデータノードホスト上の特定の CPU に対するスレッドのスケジューリングとロックで使用されます。

注記

これらのパラメータを使用するには、システムの root としてデータノードプロセスを実行する必要があります。

BuildIndexThreads

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	128
範囲	0 - 128
再起動タイプ

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

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

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

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

LockExecuteThreadToCPU

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	set of CPU IDs
デフォルト	0
範囲	...
再起動タイプ	N (NDB 8.0.13)

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

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

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

LockMaintThreadsToCPU

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	CPU ID
デフォルト	0
範囲	0 - 64K
再起動タイプ	N (NDB 8.0.13)

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

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

Numa

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	1
範囲	...
再起動タイプ	N (NDB 8.0.13)

このパラメータは、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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
再起動タイプ	N (NDB 8.0.13)

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

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

SchedulerExecutionTimer

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	µs
デフォルト	50
範囲	0 - 11000
再起動タイプ	N (NDB 8.0.13)

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

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

SchedulerResponsiveness

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	5
範囲	0 - 10
再起動タイプ

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

SchedulerSpinTimer

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	µs
デフォルト	0
範囲	0 - 500
再起動タイプ	N (NDB 8.0.13)

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

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

SpinMethod

バージョン (またはそれ以降)	NDB 8.0.20
タイプまたは単位	enumeration
デフォルト	StaticSpinning
範囲	CostBasedSpinning, LatencyOptimisedSpinning, DatabaseMachineSpinning, StaticSpinning
追加	NDB 8.0.20
再起動タイプ	N (NDB 8.0.13)

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

StaticSpinning (default) : EnableAdaptiveSpinning を false に、SchedulerSpinTimer を 0 に設定します。 (この場合、SetAllowedSpinOverhead は関係ありません。)
CostBasedSpinning : EnableAdaptiveSpinning を true、SchedulerSpinTimer を 100、SetAllowedSpinOverhead を 200 に設定します。
LatencyOptimisedSpinning : EnableAdaptiveSpinning を true、SchedulerSpinTimer を 200、SetAllowedSpinOverhead を 1000 に設定します。
DatabaseMachineSpinning : EnableAdaptiveSpinning を true、SchedulerSpinTimer を 500、SetAllowedSpinOverhead を 10000 に設定します。これは、スレッドが独自の CPU を所有する場合に使用することを目的としています。

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

SchedulerSpinTimer : これは、その名前のデータノード構成パラメータと同じです。 SpinMethod によってこのパラメータに適用された設定は、config.ini ファイルに設定された値をオーバーライドします。
EnableAdaptiveSpinning: 適応スピンを有効または無効にします。これを無効にすると、CPU リソースのチェックを行わずにスピンが実行されます。このパラメータはクラスタ構成ファイルで直接設定することはできず、ほとんどの状況では有効にする必要はありませんが、DUMP 104004 1 を使用して直接有効にするか、ndb_mgm 管理クライアントで DUMP 104004 0 を使用して無効にできます。
SetAllowedSpinOverhead: 待機時間を取得できる CPU 時間を設定します。このパラメータは、config.ini ファイルで直接設定できません。ほとんどの場合、SpinMethod によって適用される設定は十分ですが、直接変更する必要がある場合は、DUMP 104002 overhead を使用して変更できます。ここで、overhead は 0 から 10000 の範囲の値です。詳細は、示された DUMP コマンドの説明を参照してください。

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

TwoPassInitialNodeRestartCopy

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	boolean
デフォルト	true
範囲	true, false
再起動タイプ	N (NDB 8.0.13)

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

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

マルチスレッドの構成パラメータ (ndbmtd). ndbmtd は、デフォルトではシングルスレッドプロセスとして動作するため、2 つの方法のいずれかを使用して、複数のスレッドを使用するように構成する必要があります。どちらの場合も、config.ini ファイルに構成パラメータを設定する必要があります。 1 つ目の方法では、MaxNoOfExecutionThreads 構成パラメータに適切な値を設定します。別の方法として、ThreadConfig を使用して ndbmtd マルチスレッドのより複雑なルールを設定できます。次のいくつかの段落では、これらのパラメータおよびマルチスレッドデータノードでのそれらの使用に関する情報を提供します。

注記

データノードで並列性を使用したバックアップでは、バックアップを取得する前に、クラスタ内のすべてのデータノードで複数の LDM が使用されている必要があります。詳細は、セクション23.5.8.5「並列データノードを使用した NDB バックアップの作成」およびセクション23.4.23.3「パラレルで作成されたバックアップからのリストア」を参照してください。

AutomaticThreadConfig

バージョン (またはそれ以降)	NDB 8.0.23
タイプまたは単位	boolean
デフォルト	false
範囲	true, false
追加	NDB 8.0.23
再起動タイプ	IS (NDB 8.0.13)

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

ClassicFragmentation

バージョン (またはそれ以降)	NDB 8.0.23
タイプまたは単位	boolean
デフォルト	true
範囲	true, false
追加	NDB 8.0.23
再起動タイプ	N (NDB 8.0.13)

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

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

MaxNoOfExecutionThreads

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	2
範囲	2 - 72
再起動タイプ	IS (NDB 8.0.13)

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

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

表 23.12 スレッドタイプ別の MaxNoOfExecutionThreads 値および対応するスレッド数 (LQH、TC、送信、受信)。

`MaxNoOfExecutionThreads` の値	LDM スレッド	TC スレッド	送信スレッド	受信スレッド
0 .. 3	1	0	0	1
4 .. 6	2	0	0	1
7 .. 8	4	0	0	1
9	4	2	0	1
10	4	2	1	1
11	4	3	1	1
12	6	2	1	1
13	6	3	1	1
14	6	3	1	2
15	6	3	2	2
16	8	3	1	2
17	8	4	1	2
18	8	4	2	2
19	8	5	2	2
20	10	4	2	2
21	10	5	2	2
22	10	5	2	3
23	10	6	2	3
24	12	5	2	3
25	12	6	2	3
26	12	6	3	3
27	12	7	3	3
28	12	7	3	4
29	12	8	3	4
30	12	8	4	4
31	12	9	4	4
32	16	8	3	3
33	16	8	3	4
34	16	8	4	4
35	16	9	4	4
36	16	10	4	4
37	16	10	4	5
38	16	11	4	5
39	16	11	5	5
40	20	10	4	4
41	20	10	4	5
42	20	11	4	5
43	20	11	5	5
44	20	12	5	5
45	20	12	5	6
46	20	13	5	6
47	20	13	6	6
48	24	12	5	5
49	24	12	5	6
50	24	13	5	6
51	24	13	6	6
52	24	14	6	6
53	24	14	6	7
54	24	15	6	7
55	24	15	7	7
56	24	16	7	7
57	24	16	7	8
58	24	17	7	8
59	24	17	8	8
60	24	18	8	8
61	24	18	8	9
62	24	19	8	9
63	24	19	9	9
64	32	16	7	7
65	32	16	7	8
66	32	17	7	8
67	32	17	8	8
68	32	18	8	8
69	32	18	8	9
70	32	19	8	9
71	32	20	8	9
72	32	20	8	10

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 を使用するようにしてください。

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

1 個のローカルクエリーハンドラ (LDM) スレッド
1 個の受信スレッド
1 個のサブスクリプションマネージャー (SUMA またはレプリケーション) スレッド

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

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

各 LDM スレッドは最大 8 つのフラグメントを処理
テーブルフラグメントの合計数は、LDM スレッドの数の整数倍です。

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

NoOfFragmentLogParts

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	4
範囲	4, 6, 8, 10, 12, 16, 20, 24, 32
再起動タイプ	IN (NDB 8.0.13)

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

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

NumCPUs

バージョン (またはそれ以降)	NDB 8.0.23
タイプまたは単位	integer
デフォルト	0
範囲	0 - 1024
追加	NDB 8.0.23
再起動タイプ	IS (NDB 8.0.13)

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

PartitionsPerNode

バージョン (またはそれ以降)	NDB 8.0.23
タイプまたは単位	integer
デフォルト	2
範囲	1 - 32
追加	NDB 8.0.23
再起動タイプ	N (NDB 8.0.13)

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

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

ThreadConfig

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	string
デフォルト	''
範囲	...
再起動タイプ	IS (NDB 8.0.13)

このパラメータは、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 (パラメータ) は、次の情報のいずれかまたはすべてを指定します:

指定されたタイプ (count) のスレッド数。
特定のタイプのスレッドが非排他的にバインドされる CPU のセット。これは、cpubind または cpuset のいずれかによって決定されます。cpubind では、各スレッドがセット内の CPU に (非排他的に) バインドされます。cpuset では、各スレッドが指定された CPU のセットに (非排他的に) バインドされます。

Solaris では、かわりに、特定のタイプのスレッドが排他的にバインドされる CPU のセットを指定できます。cpubind_exclusive では、各スレッドがセット内の CPU に排他的にバインドされます。cpuset_exclsuive では、各スレッドが指定された CPU のセットに排他的にバインドされます。

単一の構成で指定できるのは、cpubind, cpuset, cpubind_exclusive または cpuset_exclusive のいずれかのみです。
spintime は、スリープする前にスレッドがスピンする待機時間をマイクロ秒単位で決定します。

spintime のデフォルト値は、SchedulerSpinTimer データノード構成パラメータの値です。

spintime は、I/O スレッド、ウォッチドッグまたはオフラインインデックス構築スレッドには適用されないため、これらのスレッドタイプには設定できません。
realtime は 0 または 1 に設定できます。 1 に設定すると、スレッドはリアルタイム優先度で実行されます。これは、thread_prio を設定できないことも意味します。

realtime パラメータは、デフォルトで RealtimeScheduler データノード構成パラメータの値に設定されます。

オフラインインデックス構築スレッドには realtime を設定できません。
nosend を 1 に設定すると、main, ldm, rep または tc スレッドが送信スレッドを支援できなくなります。このパラメータはデフォルトでは 0 で、他のタイプのスレッドでは使用できません。
thread_prio は、0 から 10 の範囲で設定できるスレッド優先度レベルで、10 は最大の優先度を表します。デフォルトは 5 です。このパラメータの正確な効果はプラットフォーム固有であり、このセクションの後半で説明します。

スレッド優先度レベルは、オフラインインデックス構築スレッドには設定できません。

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

Linux および FreeBSD: thread_prio を nice システムコールに提供される値にマップします。プロセスの有効性の値が低いほどプロセスの優先度が高くなるため、thread_prio を増やすと nice 値が小さくなります。

表 23.13 Linux および FreeBSD での nice 値への thread_prio のマッピング

`thread_prio` 値	`nice` 値
0	19
1	16
2	12
3	8
4	4
5	0
6	-4
7	-8
8	-12
9	-16
10	-20

一部のオペレーティングシステムでは、最大プロセスの有効性レベルが 20 になる場合がありますが、これはすべてのターゲットバージョンでサポートされているわけではありません。このため、設定可能な最大 nice 値として 19 を選択します。

Solaris : Solaris で thread_prio を設定すると、次のテーブルに示すマッピングを使用して Solaris FX 優先度が設定されます:

表 23.14 Solaris での thread_prio から FX への優先度のマッピング

`thread_prio` 値	Solaris `FX` の優先度
0	15
1	20
2	25
3	30
4	35
5	40
6	45
7	50
8	55
9	59
10	60

thread_prio 設定 9 は、Solaris で特別な FX 優先度値 59 にマップされます。これは、オペレーティングシステムが独自の CPU コアでスレッドを強制的に単独で実行しようとすることを意味します。

Windows: thread_prio を、Windows API SetThreadPriority() 関数に渡される Windows スレッド優先度値にマップします。このマッピングを次のテーブルに示します:

表 23.15 thread_prio から Windows スレッド優先度へのマッピング

`thread_prio` 値	Windows スレッドの優先順位
0 - 1	`THREAD_PRIORITY_LOWEST`
2 - 3	`THREAD_PRIORITY_BELOW_NORMAL`
4 - 5	`THREAD_PRIORITY_NORMAL`
6 - 7	`THREAD_PRIORITY_ABOVE_NORMAL`
8 - 10	`THREAD_PRIORITY_HIGHEST`

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

ldm: データを処理するローカルクエリーハンドラ (DBLQH カーネルブロック)。使用される LDM スレッドの数が多いほど、データがより高度にパーティション化されます。各 LDM スレッドには、固有のデータおよびインデックスパーティションのセットと固有の Redo ログが保持されます。 NDB 8.0.23 より前では、ldm の値セットは 1、2、4、6、8、12、16、24、または 32 のいずれかである必要があります。 In NDB 8.0.23 and later, it is possible to set ldm to any value in the range 1 to 332 inclusive; it also becomes possible to set it to 0, provided that main, rep, and tc are also 0, and that recv is set to 1; doing this causes ndbmtd to emulate ndbd.

LDM スレッドの数を変更するには、通常、クラスタ操作を有効かつ安全に行うためにシステムの再起動が必要です。この要件は、このセクションの後半で説明するように、特定の状況で緩和されます。これは、MaxNoOfExecutionThreads を使用して実行する場合にも当てはまります。

デフォルト数を超える LDM を使用している場合に「ディスクデータ」テーブルに大きなテーブルスペース (数百 GB 以上) を追加すると、DiskPageBufferMemory が十分に大きくないと、リソースおよび CPU の使用率に問題が発生する可能性があります。
query (NDB 8.0.23 で追加): クエリースレッドは LDM に関連付けられ、LDM グループを形成します。READ COMMITTED クエリーに対してのみ機能します。クエリースレッドの数は、LDM スレッドの数の 0、1、2 または 3 倍に設定する必要があります。これが query をゼロ以外の値に設定するか、AutomaticThreadConfig パラメータを有効にすることによってオーバーライドされないかぎり、クエリースレッドは使用されません。この場合、LDM は NDB 8.0.23 の前と同じように動作します。

クエリースレッドもリカバリスレッドとして機能しますが (次の項目を参照)、その逆は当てはまりません。

クエリースレッドの数を変更するには、ノードの再起動が必要です。
recover (NDB 8.0.23 で追加): 回復スレッドは、LCP の一部としてフラグメントからデータを復元します。

リカバリスレッドの数を変更するには、ノードの再起動が必要です。
tc: 進行中のトランザクションの状態を含むトランザクションコーディネータスレッド (DBTC カーネルブロック)。 NDB 8.0.23 以降では、TC スレッドの最大数は 128 で、以前は 32 でした。

新しいトランザクションをそれぞれ 1 つの新しい TC スレッドに適切に割り当てることができます。ほとんどの場合、この実行が保証されるには、2 つの LDM スレッドに対して 1 つの TC スレッドで十分です。読み取りの数に比べて書き込みの数が少ないケースでは、4 つの LQH スレッドあたり 1 つの TC スレッドがあればトランザクション状態を維持できる可能性があります。逆に、非常に多くの更新を実行するアプリケーションでは、LDM スレッドに対する TC スレッドの比率を 1 に近づける (たとえば、4 つの LDM スレッドに対して TC スレッドを 3 つにする) 必要がある場合があります。

tc を 0 に設定すると、TC 処理がメインスレッドによって実行されます。ほとんどの場合、これは事実上 1 に設定することと同じです。

Range: 0-64( NDB 8.0.22 以前: 0 - 32)
main: スキーマ管理を提供するデータディクショナリおよびトランザクションコーディネータ (DBDIH および DBTC カーネルブロック)。 NDB 8.0.23 より前は、これは NDB 8.0.23 から始まる単一の専用スレッドによって常に処理されていましたが、ゼロまたは 2 つのメインスレッドを指定することもできました。

範囲:
- NDB 8.0.22 以前: 1 only.
  
  NDB 8.0.23 以降: 0-2。
  
  main を 0 に、rep を 1 に設定すると、main ブロックが rep スレッドに配置されます。結合されたスレッドは、ndbinfo.threads テーブルに main_rep として表示されます。これは事実上、rep を 1 に、main を 0 に設定することと同じです。
  
  main と rep の両方を 0(ゼロ) に設定することもできます。この場合、両方のスレッドが最初の recv スレッドに配置され、結果として生成される結合スレッドの名前は threads テーブルで main_rep_recv になります。
recv: 受信スレッド (CMVMI カーネルブロック)。各受信スレッドは、NDB Cluster 内のほかのノードと通信するための 1 つ以上のソケットを、ノードごとに 1 つのソケットで処理します。 NDB Cluster は複数の受信スレッドをサポートします。このようなスレッドの最大数は 16 です。

範囲:
- NDB 8.0.22 以前: 1 - 16
- NDB 8.0.23 以降: 1 - 64
send: 送信スレッド (CMVMI カーネルブロック)。スループットを向上させるため、1 つ以上 (最大 8 個) の独立した専用スレッドから送信を実行できます。

NDB 8.0.20 以降では、マルチスレッド実装が変更されたため、多くの送信スレッドを使用すると、スケーラビリティーに悪影響を与える可能性があります。

以前は、すべてのスレッドが独自の送信を直接処理していました。これは、送信スレッドの数を 0 に設定することで実行できます (MaxNoOfExecutionThreads が 10 未満に設定されている場合にも発生します)。これを行うと、スループットに悪影響を及ぼす可能性がありますが、場合によっては待機時間が減る可能性もあります。

範囲:
- NDB 8.0.22 以前: 0 - 16
- NDB 8.0.23 以降: 0 - 64
rep: レプリケーションスレッド (SUMA カーネルブロック)。 NDB 8.0.23 より前では、非同期レプリケーション操作は常に単一の専用スレッドによって処理されます。 NDB 8.0.23 以降では、このスレッドをメインスレッドと組み合わせることができます (範囲情報を参照)。

範囲:
- NDB 8.0.22 以前: 1 only.
- NDB 8.0.23 以降: 0-1。
  
  rep を 0 に、main を 1 に設定すると、rep ブロックが main スレッドに配置されます。結合されたスレッドは、ndbinfo.threads テーブルに main_rep として表示されます。これは事実上、main を 1 に、rep を 0 に設定することと同じです。
  
  main と rep の両方を 0(ゼロ) に設定することもできます。この場合、両方のスレッドが最初の recv スレッドに配置され、結果として生成される結合スレッドの名前は threads テーブルで main_rep_recv になります。
io: ファイルシステムおよびその他の操作。これらは、要求の厳しいタスクではなく、常に 1 つの I/O 専用スレッドでまとめて処理されます。

範囲: 1 のみ。
watchdog: このタイプに関連付けられたパラメータ設定は、実際には複数のスレッドに適用され、それぞれに特定の用途があります。これらのスレッドには、他のノードから接続設定を受信する SocketServer スレッド、他のノードへの接続を設定しようとする SocketClient スレッド、およびスレッドが進行中であることを確認するスレッドウォッチドッグスレッドが含まれます。

範囲: 1 のみ。
idxbld: オフラインインデックス構築スレッド。前述の永続的な他のスレッドタイプとは異なり、これらは、ノードまたはシステムの再起動時、または ndb_restore --rebuild-indexes の実行時にのみ作成および使用される一時スレッドです。永続スレッドタイプにバインドされた CPU セットと重複する CPU セットにバインドできます。

thread_prio、realtime および spintime の値は、オフラインインデックス構築スレッドには設定できません。また、このタイプのスレッドでは、count は無視されます。

idxbld が指定されていない場合、デフォルトの動作は次のとおりです:
- オフラインインデックス構築スレッドは、I/O スレッドもバインドされておらず、これらのスレッドが使用可能なコアを使用している場合はバインドされません。
- I/O スレッドがバインドされている場合、オフラインインデックス構築スレッドはバインドされたスレッドのセット全体にバインドされます。これは、これらのスレッドが実行する他のタスクがないためです。
Range: 0 - 1。

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

変更後も LDM スレッドの数が以前と同じである場合は、変更を実装するために単純なノードの再起動 (ローリング再起動または N) 以外は必要ありません。
それ以外の場合 (つまり、LDM スレッドの数が変更された場合)、次の 2 つの条件が満たされていれば、ノードの初期再起動 (NI) を使用して変更を有効にできます:
1. 各 LDM スレッドは最大 8 つのフラグメントを処理
2. テーブルフラグメントの合計数は、LDM スレッドの数の整数倍です。

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

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

スレッドが実行スレッドかどうか。 main, ldm, query タイプ (NDB 8.0.23 以降)、recv, rep, tc、および send は実行スレッドです。io、recover (NDB 8.0.23 以降)、watchdog、および idxbld スレッドは実行スレッドとみなされません。
特定のタスクへのスレッドの割当てが永続的か一時的か。現在、idxbld 以外のすべてのスレッドタイプは永続とみなされます。idxbld スレッドは一時スレッドとみなされます。

簡単な例:

# 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

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	32K pages
デフォルト	10
範囲	1 - 1000
バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	bytes
デフォルト	64MB
範囲	4MB - 16TB
再起動タイプ	N (NDB 8.0.13)

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

DiskPageBufferMemory

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	64M
範囲	4M - 1T
バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	bytes
デフォルト	64M
範囲	4M - 16T
再起動タイプ	N (NDB 8.0.13)

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

注記

以前は、このパラメータは 32 KB のページ数として指定されていました。 NDB 8.0.19 以降では、バイト数として指定されます。

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

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

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

SharedGlobalMemory

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	128M
範囲	0 - 64T
再起動タイプ	N (NDB 8.0.13)

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

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

DiskIOThreadPool

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	threads
デフォルト	2
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

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

ディスクデータファイルの物理的な分布. データファイル、Undo ログファイル、およびデータノードファイルシステムを別々の物理ディスクに配置することで、パフォーマンスを向上させることができます。これらのファイルセットの一部またはすべてでこれを行う場合は、DiskIOThreadPool をより高く設定して、個別のスレッドで各ディスク上のファイルを処理できるようにすることができます。

NDB 8.0.19 以降では、「ディスクデータ」ファイル用に別のディスクを使用する場合も DiskDataUsingSameDisk を無効にするようにしてください。これにより、「ディスクデータ」テーブルスペースのチェックポイントを実行できる速度が向上します。
ディスクのパフォーマンスとタイプ. ディスクデータファイルの処理用に提供できるスレッドの数は、ディスクの速度とスループットにも依存します。ディスクの速度が速く、スループットが高いほど、より多くの I/O スレッドを使用できます。弊社のテスト結果では、従来のディスクよりソリッドステートディスクドライブの方が (つまり DiskIOThreadPool の値が大きいほど) はるかに多くのディスク I/O スレッドを処理できることを示しています。

ソリッドステートディスクドライブ (特に NVMe を使用するディスクドライブ) を使用する場合は、TimeBetweenGlobalCheckpoints を減らすこともお薦めします。ディスクデータ待機時間パラメータも参照してください。

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

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

FileSystemPathDD

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	filename
デフォルト	FileSystemPath
範囲	...
再起動タイプ	IN (NDB 8.0.13)

このパラメータが指定されている場合、NDB Cluster ディスクデータデータファイルと undo ログファイルは指定されたディレクトリに配置されます。データファイル、Undo ログファイル、またはその両方をオーバーライドするには、FileSystemPathDataFiles、FileSystemPathUndoFiles、またはその両方の値をこれらのパラメータの説明に従って指定します。データファイルでは CREATE TABLESPACE または ALTER TABLESPACE ステートメントの ADD DATAFILE 句にパスを指定し、Undo ログファイルでは CREATE LOGFILE GROUP または ALTER LOGFILE GROUP ステートメントの ADD UNDOFILE 句でパスを指定してオーバーライドすることもできます。 FileSystemPathDD が指定されていない場合は、FileSystemPath が使用されます。

特定のデータノードで FileSystemPathDD ディレクトリが指定された場合 (config.ini ファイルの [ndbd default] セクションでこのパラメータが指定された場合を含む)、--initial を指定してデータノードを起動すると、ディレクトリ内のすべてのファイルが削除されます。

FileSystemPathDataFiles

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	filename
デフォルト	FileSystemPathDD
範囲	...
再起動タイプ	IN (NDB 8.0.13)

このパラメータが指定されている場合、NDB Cluster ディスクデータファイルは指定されたディレクトリに配置されます。これは、FileSystemPathDD に設定された値をオーバーライドします。特定のデータファイルのパラメータをオーバーライドするには、そのデータファイルを作成するために使用される CREATE TABLESPACE または ALTER TABLESPACE ステートメントの ADD DATAFILE 句でパスを指定します。 FileSystemPathDataFiles が指定されていない場合は、FileSystemPathDD が使用されます (FileSystemPathDD も設定されていない場合は、FileSystemPath が使用されます)。

特定のデータノードで FileSystemPathDataFiles ディレクトリが指定された場合 (config.ini ファイルの [ndbd default] セクションにこのパラメータが指定された場合を含む)、--initial を指定してそのデータノードを起動すると、ディレクトリ内のすべてのファイルが削除されます。

FileSystemPathUndoFiles

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	filename
デフォルト	FileSystemPathDD
範囲	...
再起動タイプ	IN (NDB 8.0.13)

このパラメータが指定されている場合、NDB Cluster Disk Data undo ログファイルは指定されたディレクトリに配置されます。これは、FileSystemPathDD に設定された値をオーバーライドします。特定のデータファイルの作成に使用する CREATE LOGFILE GROUP ステートメントまたは ALTER LOGFILE GROUP ステートメントの ADD UNDO 句にパスを指定することで、そのデータファイルのこのパラメータをオーバーライドできます。 FileSystemPathUndoFiles が指定されていない場合は、FileSystemPathDD が使用されます (FileSystemPathDD も設定されていない場合は、FileSystemPath が使用されます)。

特定のデータノードで FileSystemPathUndoFiles ディレクトリが指定された場合 (config.ini ファイルの [ndbd default] セクションにこのパラメータが指定された場合を含む)、--initial を指定してそのデータノードを起動すると、ディレクトリ内のすべてのファイルが削除されます。

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

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

InitialLogFileGroup

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	string
デフォルト	[see documentation]
範囲	...
再起動タイプ	S (NDB 8.0.13)

このパラメータを使用して、クラスタの初期起動の実行時に作成されるログファイルグループを指定できます。 InitialLogFileGroup は、ここに示すように指定されます。

InitialLogFileGroup = [name=name;] [undo_buffer_size=size;] file-specification-list

file-specification-list:
    file-specification[; file-specification[; ...]]

file-specification:
    filename:size

ログファイルグループの name はオプションであり、デフォルト値は DEFAULT-LG です。 undo_buffer_size もオプションです。省略した場合のデフォルト値は 64M です。 file-specification は、それぞれ 1 つの Undo ログファイルに対応し、file-specification-list に少なくとも 1 つ指定する必要があります。 Undo ログファイルは、FileSystemPath、FileSystemPathDD、および FileSystemPathUndoFiles に設定された値に従って、CREATE LOGFILE GROUP または ALTER LOGFILE GROUP ステートメントの結果として作成された場合と同じように配置されます。

次について考えます。

InitialLogFileGroup = name=LG1; undo_buffer_size=128M; undo1.log:250M; undo2.log:150M

これは、次の SQL ステートメントと同等です。

CREATE LOGFILE GROUP LG1
    ADD UNDOFILE 'undo1.log'
    INITIAL_SIZE 250M
    UNDO_BUFFER_SIZE 128M
    ENGINE NDBCLUSTER;

ALTER LOGFILE GROUP LG1
    ADD UNDOFILE 'undo2.log'
    INITIAL_SIZE 150M
    ENGINE NDBCLUSTER;

このログファイルグループは、--initial を指定してデータノードを起動したときに作成されます。

初期ログファイルグループのリソースは、SharedGlobalMemory の値で示されるリソースとともにグローバルメモリープールに追加されます。

このパラメータを使用する場合は、常に config.ini ファイルの [ndbd default] セクションに設定するようにしてください。異なるデータノードに異なる値が設定されている場合の NDB Cluster の動作は定義されません。

InitialTablespace

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	string
デフォルト	[see documentation]
範囲	...
再起動タイプ	S (NDB 8.0.13)

このパラメータを使用して、クラスタの初期起動時に作成される「NDB Cluster ディスクデータ」テーブルスペースを指定できます。 InitialTablespace は、ここに示すように指定されます。

InitialTablespace = [name=name;] [extent_size=size;] file-specification-list

テーブルスペースの name はオプションであり、デフォルト値は DEFAULT-TS です。 extent_size もオプションです。デフォルト値は 1M です。 file-specification-list には、InitialLogfileGroup パラメータに示された同じ構文が使用されます。唯一の違いは、InitialTablespace で使用される file-specification がそれぞれ 1 つのデータファイルに対応することです。 file-specification-list には、少なくとも 1 つを指定する必要があります。データファイルは、FileSystemPath、FileSystemPathDD、および FileSystemPathDataFiles に設定された値に従って、CREATE TABLESPACE または ALTER TABLESPACE ステートメントの結果として作成された場合と同じように配置されます。

たとえば、config.ini ファイルの[ndbd default]セクションで InitialTablespace を指定する次の行を考えてみます (InitialLogfileGroup の場合と同様に、異なるデータノードに異なる値が設定されている場合の NDB Cluster の動作として、このパラメータは常に[ndbd default]セクションで設定するようにしてください):

InitialTablespace = name=TS1; extent_size=8M; data1.dat:2G; data2.dat:4G

これは、次の SQL ステートメントと同等です。

CREATE TABLESPACE TS1
    ADD DATAFILE 'data1.dat'
    EXTENT_SIZE 8M
    INITIAL_SIZE 2G
    ENGINE NDBCLUSTER;

ALTER TABLESPACE TS1
    ADD DATAFILE 'data2.dat'
    INITIAL_SIZE 4G
    ENGINE NDBCLUSTER;

このテーブルスペースは、データノードが --initial で起動されたときに作成され、その後に「NDB Cluster ディスクデータ」テーブルを作成するたびに使用できます。

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

MaxDiskDataLatency

バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	ms
デフォルト	0
範囲	0 - 8000
追加	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

このパラメータは、ディスクアクセスの最大許容平均レイテンシ (最大 8000 ミリ秒) を制御します。この制限に達すると、ディスクデータ I/O サブシステムの圧力を下げるために、NDB はトランザクションの中断を開始します。 0 を使用して、待機時間チェックを無効にします。

DiskDataUsingSameDisk

バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	boolean
デフォルト	true
範囲	...
追加	NDB 8.0.19
再起動タイプ	N (NDB 8.0.13)

「ディスクデータ」テーブルスペースで個別のディスクが使用されている場合は、このパラメータを false に設定します。これにより、ディスクの共有時に通常使用されるよりも高い速度でテーブルスペースへのチェックポイントを実行できます。

DiskDataUsingSameDisk が true の場合、NDB では、インメモリーチェックポイントの進行中は常にディスクデータチェックポイントの速度が低下するため、ディスク負荷を一定に保つことができます。

ディスクデータと GCP 停止エラー. 「GCP 停止が検出されたため、ノード nodeid はこのノードを強制終了しました」 (エラー 2303) などの「ディスクデータ」テーブルの使用時に発生するエラーは、多くの場合「「GCP 停止エラー」」と呼ばれます。このようなエラーは、Redo ログが十分な速さでディスクにフラッシュされていない場合に発生します。これは通常、ディスクの速度が低く、ディスクのスループットが十分でないことが原因です。

高速なディスクを使用し、ディスクデータファイルをデータノードファイルシステムとは別のディスクに配置することで、これらのエラーを回避しやすくなります。 TimeBetweenGlobalCheckpoints の値を減らすと、グローバルチェックポイントごとに書き込まれるデータの量が減りやすくなるため、グローバルチェックポイントを書き込もうとしたときに Redo ログバッファーのオーバーフローをある程度回避できる可能性があります。ただし、この値を減らすと GCP を書き込むことができる時間も減るため、注意が必要です。

前述の DiskPageBufferMemory について示した考慮事項に加えて、DiskIOThreadPool 構成パラメータを正しく設定することも非常に重要です。DiskIOThreadPool の設定値が大きすぎると、GCP 停止エラーが発生する可能性が非常に高くなります (Bug #37227)。

GCP の停止は、保存またはコミットのタイムアウトによって発生することがあります。TimeBetweenEpochsTimeout データノード構成パラメータは、コミットのタイムアウトを指定します。ただし、このパラメータを 0 に設定することで、両方のタイプのタイムアウトを無効にできます。

送信バッファーメモリーの割り当てを構成するためのパラメータ. 送信バッファーメモリーは、すべてのトランスポータ間で共有されるメモリープールから動的に割り当てられます。これは、送信バッファーのサイズを必要に応じて調整できることを意味します。 (以前は、クラスタ内のすべてのノードで NDB カーネルが固定サイズの送信バッファーを使用していました。これは、ノードの起動時に割り当てられ、ノードの実行中は変更できませんでした。) TotalSendBufferMemory および OverLoadLimit データノード構成パラメータを使用して、このメモリー割り当ての制限を設定できます。これらのパラメータ (および SendBufferMemory) の使用方法の詳細は、セクション23.3.3.14「NDB Cluster 送信バッファーパラメータの構成」を参照してください。

ExtraSendBufferMemory

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

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

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

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

Redo ログのオーバーコミット処理. Redo ログをディスクにフラッシュする時間が長すぎる場合の、データノードによる操作の処理を制御できます。これは、特定の Redo ログのフラッシュが RedoOverCommitLimit 秒より長い時間をかけて RedoOverCommitCounter 回を超える回数分行われ、保留中のトランザクションが中止されたときに発生します。これが発生すると、トランザクションを送信した API ノードは、コミットされるはずだった操作を (DefaultOperationRedoProblemAction の指定に従って) キューに配置して再試行するか、中止することで処理できます。 API ノードでこのアクションが実行される前に超過が許されるタイムアウトと回数を設定するためのデータノード構成パラメータについて、次のリストで説明します。

RedoOverCommitCounter

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	numeric
デフォルト	3
範囲	1 - 4294967039 (0xFFFFFEFF)
バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	numeric
デフォルト	3
範囲	1 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

RedoOverCommitLimit

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	seconds
デフォルト	20
範囲	1 - 4294967039 (0xFFFFFEFF)
バージョン (またはそれ以降)	NDB 8.0.19
タイプまたは単位	seconds
デフォルト	20
範囲	1 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

再起動試行の制御. MaxStartFailRetries および StartFailRetryDelay データノード構成パラメータを使用すると、データノードによる起動失敗時の再起動試行を細かく制御できます。

MaxStartFailRetries は、データノードの起動を中止するまでに行われる再試行の合計数を制限します。StartFailRetryDelay は、再試行間の秒数を設定します。これらのパラメータをここに示します。

StartFailRetryDelay

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	0
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

MaxStartFailRetries

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	unsigned
デフォルト	3
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	N (NDB 8.0.13)

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

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

NDB インデックス統計のパラメータ. 次のリストのパラメータは NDB インデックス統計の生成に関連しています。

IndexStatAutoCreate

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0, 1
再起動タイプ

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

IndexStatAutoUpdate

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	integer
デフォルト	0
範囲	0, 1
再起動タイプ

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

IndexStatSaveSize

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	bytes
デフォルト	32768
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	IN (NDB 8.0.13)

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

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

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

IndexStatSaveScale

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	percentage
デフォルト	100
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	IN (NDB 8.0.13)

IndexStatTriggerPct

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	percentage
デフォルト	100
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	IN (NDB 8.0.13)

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

IndexStatTriggerScale

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	percentage
デフォルト	100
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	IN (NDB 8.0.13)

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

IndexStatUpdateDelay

バージョン (またはそれ以降)	NDB 8.0.13
タイプまたは単位	seconds
デフォルト	60
範囲	0 - 4294967039 (0xFFFFFEFF)
再起動タイプ	IN (NDB 8.0.13)

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

再起動のタイプ. このセクションのパラメータの説明で使用される再起動タイプに関する情報を次のテーブルに示します:

表 23.16 NDB Cluster の再起動タイプ

シンボル	再起動タイプ	説明
N	ノード	パラメータはローリング再起動を使用して更新できます (セクション23.5.5「NDB Cluster のローリング再起動の実行」を参照)
S	システム	このパラメータの変更を有効にするには、すべてのクラスタノードを完全に停止してから再起動する必要があります
I	Initial	`--initial` オプションを使用してデータノードを再起動する必要があります

PREV HOME UP NEXT