Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.1Mb
EPUB - 7.5Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


18.3.2.6 MySQL Cluster データノードの定義

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

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

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

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

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

メモリー使用状況やバッファーサイズに影響を与えるパラメータでは、1024、1024 * 1024、または 1024 * 1024 * 1024 の単位を示すサフィクスとして KM、または G を使用できます。(たとえば、100K は 100 * 1024 = 102400 を意味します。)現在のところ、パラメータの名前と値では大文字と小文字を区別します。

MySQL Cluster ディスクデータのテーブルに固有の構成パラメータについては、このセクションで後述します (ディスクデータの構成パラメータを参照してください)。

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

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

  • Id

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし [none] 1 - 48 IS

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

    NodeId は、データノードの識別時での使用が推奨されるパラメータ名です。古い Id は、下位互換性に引き続き対応しますが、現在は非推奨であり、使用時に警告を生成します。Id は MySQL Cluster の今後のリリースで削除される予定です。

  • NodeId

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし [none] 1 - 48 IS

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

    NodeId は、データノードの識別時での使用が推奨されるパラメータ名です。Id は、下位互換性に引き続き対応しますが、現在は非推奨であり、使用時に警告を生成します。また、MySQL Cluster の今後のバージョンで削除される予定です。

  • ExecuteOnComputer

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 name [none] ... S

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

  • HostName

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 名前または IP アドレス localhost ... N

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

  • ServerPort

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし [none] 1 - 64K N

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

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

    注記

    データノードから管理ノードへの接続は ndb_mgmd 管理ポート (管理サーバーの PortNumberセクション18.3.2.5「MySQL Cluster 管理サーバーの定義」を参照してください) を使用して行われるため、データノードからポートへの送信接続は常に許可されます。

  • TcpBind_INADDR_ANY

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

  • NodeGroup

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0   [none] 0 - 65536 IS

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

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

  • NoOfReplicas

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 2 1 - 4 IS

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

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

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

    NoOfReplicas のデフォルト値は 2 です。これは、ほとんどの一般的な使用シナリオで推奨される設定です。

    指定可能な最大値は 4 ですが、現時点で実際にサポートされている値は 1 と 2 だけです

    重要

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

    このパラメータの値は、クラスタ内のデータノードの数で均等に割れる必要があります。たとえば、データノードが 2 つの場合、2/3 と 2/4 はどちらも小数値になるため、NoOfReplicas は 1 または 2 である必要があります。データノードが 4 つの場合、NoOfReplicas は 1、2、または 4 である必要があります。

  • DataDir

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 パス . ... IN

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

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

  • FileSystemPath

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 パス DataDir ... IN

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

    注記

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

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

  • BackupDataDir

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 パス [テキストを参照] ... IN

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

    重要

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

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

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

  • DataMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 80M 1M - 1024G N

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

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

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

    最大レコードサイズは 14000 バイトです。

    DataMemory によって定義されたメモリースペースは、順序付けされたインデックスを格納するためにも使用されます。これには、レコードあたり約 10 バイトが使用されます。各テーブル行は順序付けされたインデックスで表されます。ユーザーの間では共通して、すべてのインデックスが IndexMemory によって割り当てられたメモリーに格納されるという誤解がありますが、これは正しくありません。主キーと一意のハッシュインデックスのみがこのメモリーを使用します。順序付けされたインデックスは、DataMemory によって割り当てられたメモリーを使用します。ただし、主キーまたは一意のハッシュインデックスを作成するときに、インデックス作成ステートメントに USING HASH を指定しなかった場合は、同じキーに対して順序付けされたインデックスも作成されます。これは、管理クライアントで ndb_desc -d db_name table_name を実行すると確認できます。

    現在、MySQL Cluster ではハッシュインデックスにパーティションあたり最大 512M バイトを使用できます。つまり、場合によってはndb_mgm -e "ALL REPORT MEMORYUSAGE"DataMemory に大きい空き領域が示されていてもTable is fullというエラーがMySQL クライアントアプリケーションで表示されることがあります。このため、データの負荷が高いノードでデータノードを再起動するときに問題が発生する場合もあります。CREATE TABLEMAX_ROWS オプションを使用すると、MySQL Cluster のテーブルのために追加のパーティションを作成して、ハッシュインデックスに使用できるメモリーを増やすように NDB に強制できます。通常、テーブルに格納することが予期されている行数の 2 倍の数値を MAX_ROWS に設定すれば十分です。MinFreePct 構成パラメータを使用して、ノード再起動の問題を回避することもできます。(Bug #13436216)

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

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

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

    • 大規模なトランザクションは小規模なトランザクションより高速に実行できません

    • 大規模なトランザクションでは、トランザクション障害の発生時に消失して繰り返す必要がある操作の数が多くなります

    • 大規模なトランザクションはより多くのメモリーを使用します

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

  • IndexMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 18M 1M - 1T N

    このパラメータは、MySQL Cluster 内のハッシュインデックスに使用されるストレージの量を制御します。ハッシュインデックスは、常に主キーのインデックス、一意のインデックス、および一意の制約に使用されます。主キーまたは一意のインデックスを定義すると、2 つのインデックスが作成され、そのうちの 1 つのハッシュインデックスが、すべてのタプルへのアクセスとロックの処理に使用されます。このインデックスは、一意の制約を適用するためにも使用されます。

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

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

    fragments はフラグメントの数、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 Cluster NDB 7.2 以降では、順序付けされたインデックスのインデックス統計が (有効になっている場合は) 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 という名前の順序付けされたインデックスがあるとします。また、IndexStatSaveSizeIndexStatSaveScale がこのデフォルト値 (それぞれ 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 バイトです。

    IndexMemory のデフォルト値は 18M バイトです。最小は 1M バイトです。

  • StringMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 % またはバイト 25 0 - 4294967039 (0xFFFFFEFF) S

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

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

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

    ほとんどの状況ではデフォルト値で十分ですが、クラスタテーブルの数が非常に多い (1000 個以上) 場合は、エラー 773 Out of string memory, please modify StringMemory config parameter: Permanent error: Schema errorが発生する可能性があるので、その場合はこの値を増やすようにしてください。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 バイトが必要です。

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

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

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

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

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

MinFreePct  DataMemoryIndexMemory を含むデータノードリソースの一定割合 (デフォルトでは 5%) は、データノードが再起動するときにそのメモリーを使い果たさないように予備として残されます。これは、MinFreePct データノード構成パラメータを使用して調整できます (デフォルトは 5)。

有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
NDB 7.3.0 符号なし 5 0 - 100 N

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

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

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

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

  • MaxNoOfConcurrentTransactions

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 4096 32 - 4294967039 (0xFFFFFEFF) N

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

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

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

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

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

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

    デフォルト値は 4096 です。

  • MaxNoOfConcurrentOperations

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 32K 32 - 4294967039 (0xFFFFFEFF) N

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

    クラスタデータを更新する各トランザクションでは、トランザクションコーディネータと実際の更新が実行されるノードの両方でレコードが保持されます。これらのレコードには、ロールバック、ロックキュー、およびその他の目的に使用する 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 7.3.0 整数 UNDEFINED 32 - 4294967039 (0xFFFFFEFF) N

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

  • MaxDMLOperationsPerTransaction

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 操作 (DML) 4294967295 32 - 4294967295 N

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

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

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

  • MaxNoOfConcurrentIndexOperations

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 8K 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • MaxNoOfFiredTriggers

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 4000 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • TransactionBufferMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 1M 1K - 4294967039 (0xFFFFFEFF) N

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

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

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

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

  • MaxNoOfConcurrentScans

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 256 2 - 500 N

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

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

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

  • MaxNoOfLocalScans

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 [テキストを参照] 32 - 4294967039 (0xFFFFFEFF) N

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

    4 * MaxNoOfConcurrentScans * [# data nodes] + 2
    

    最小値は 32 です。

  • BatchSizePerLocalScan

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 256 1 - 992 N

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

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

  • LongMessageBuffer

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 64M 512K - 4294967039 (0xFFFFFEFF) N
    NDB 7.3.1 バイト 4M 512K - 4294967039 (0xFFFFFEFF) N
    NDB 7.3.5 バイト 64M 512K - 4294967039 (0xFFFFFEFF) N

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

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

  • MaxParallelScansPerFragment

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 256 1 - 4294967039 (0xFFFFFEFF) N

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

    MySQL Cluster NDB 7.3 以降では、このパラメータのデフォルト値は 256 です。

メモリー割り当て

MaxAllocate

有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
NDB 7.3.0 符号なし 32M 1M - 1G N

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

ハッシュマップサイズ

DefaultHashMapSize

有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
NDB 7.3.0 LDM スレッド 3840 0 - 3840 N

MySQL Cluster NDB 7.2.7 以降では、前のリリース (240) より大きなテーブルハッシュマップのデフォルトサイズ (3840) が使用されます。MySQL Cluster NDB 7.2.11 以降では、このパラメータを使用して NDB が使用するテーブルハッシュマップのサイズを構成できます (以前は、この値はハードコーディングされていました)。DefaultHashMapSize には、3 つの値 (0、240、3840) のいずれかを指定できます。これらの値とその効果について、次の表で説明します。

説明/効果
0 クラスタ内のすべてのデータおよび API ノードの中で、このパラメータに設定されたもっとも小さい値を (あれば) 使用します。どのデータまたは API ノードにも設定されていない場合は、デフォルト値を使用します。
240 MySQL Cluster NDB 7.2.7 より前のすべての MySQL Cluster リリースでデフォルトで使用されていた元のハッシュマップサイズです。
3840 MySQL Cluster NDB 7.2.7 以降でデフォルトで使用される、より大きなハッシュマップサイズ

このパラメータの主な用途は、より大きなハッシュマップサイズ (3840) がデフォルトである MySQL Cluster NDB 7.2.7 以降の MySQL Cluster バージョンと以前のリリース (デフォルトが 240 だった) との間のアップグレードと (特に) ダウングレードを容易にすることです。これは、この変更に下位互換性がない (Bug #14800539) ためです。このパラメータを 240 に設定してから、この値を使用している古いバージョンからのアップグレードを実行すると、クラスタはテーブルハッシュマップに対して引き続き小さいサイズを使用するため、アップグレード後のテーブルでも前のバージョンとの互換性が維持されます。DefaultHashMapSize は個々のデータノード、API ノード、またはその両方で設定できますが、config.ini ファイルの [ndbd default] セクションに一度だけ設定する方法をお勧めします。

このパラメータを増やしたあと、既存のテーブルで新しいサイズを利用するには、そのテーブルに対して ALTER TABLE ... REORGANIZE PARTITION を実行します。その後、そのテーブルでより大きなハッシュマップサイズを使用できるようになります。これは、ローリング再起動の実行に加えて行います。ローリング再起動を実行すると、より大きなハッシュマップを新しいテーブルで使用できるようになりますが、既存のテーブルでは使用できません。

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

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

  • NoOfFragmentLogFiles

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 16 3 - 4294967039 (0xFFFFFEFF) IN

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

    Redo ログレコードは、挿入されたあと、必要な数のローカルチェックポイントが完了するまで削除されません。(MySQL Cluster NDB 7.3 以降では、2 つのローカルチェックポイントのみが必要です)。チェックポイントの頻度は、この章で別途説明する固有の構成パラメータセットによって決定されます。

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

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

    重要

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

  • FragmentLogFileSize

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 16M 4M - 1G IN

    このパラメータを設定すると、Redo ログファイルのサイズを直接制御できます。これは、MySQL Cluster が負荷の高い状態で稼働し、フラグメントログファイルを閉じるまでに時間がかかって新しいファイルを開けない (一度に開けるフラグメントログファイルは 2 つだけです) 場合に便利です。フラグメントログファイルのサイズを増やすと、クラスタ内で新しいフラグメントログファイルを開く必要が生じるまでの時間が長くなります。このパラメータのデフォルト値は 16M です。

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

  • InitFragmentLogFiles

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 [値を参照] SPARSE SPARSE、FULL IN

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

    • SPARSE。フラグメントログファイルがまばらに作成されます。これはデフォルト値です。

    • FULL。フラグメントログファイルのすべてのバイトが強制的にディスクに書き込まれます。

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

  • MaxNoOfOpenFiles

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 0 20 - 4294967039 (0xFFFFFEFF) N

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

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

  • InitialNoOfOpenFiles

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ファイル 27 20 - 4294967039 (0xFFFFFEFF) N

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

    デフォルト値は 27 です。

  • MaxNoOfSavedMessages

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 25 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • MaxLCPStartDelay

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 0 0 - 600 N

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

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

  • LcpScanProgressTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 second 60 0 - 4294967039 (0xFFFFFEFF) N
    NDB 7.3.3 second 60 0 - 4294967039 (0xFFFFFEFF) N

    ローカルチェックポイントのフラグメントスキャンウォッチドッグは、ローカルチェックポイントの一部として実行されている各フラグメントスキャンが進行していないかどうか定期的にチェックし、特定の時間が経過しても進行しない場合はそのノードをシャットダウンします。MySQL Cluster NDB 7.3.3 より前では、この間隔は常に 60 秒でした (Bug #16630410)。MySQL Cluster NDB 7.3.3 以降では、LcpScanProgressTimeout データノード構成パラメータを使用してこの間隔を設定できます。これは、LCP のフラグメントスキャンウォッチドッグがノードをシャットダウンするまでローカルチェックポイントの停滞が許可される最大時間を設定します。

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

メタデータオブジェクト  次の一連の [ndbd] パラメータは、インデックス、イベント、およびクラスタ間のレプリケーションで使用される属性、テーブル、インデックス、およびトリガーオブジェクトの最大数を定義するために使用されるメタデータオブジェクトのプールサイズを定義します。これらはクラスタに対する推奨の役割を果たすだけであり、指定されなかったものはすべて示されたデフォルト値に戻ります。

  • MaxNoOfAttributes

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 1000 32 - 4294967039 (0xFFFFFEFF) N

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

    (古い MySQL Cluster リリースでは、このパラメータは特定の操作に対する厳密な制限として扱われることがありました。このため、MySQL Cluster レプリケーションでレプリケートできる数を超えるテーブルを作成したときに問題が発生し、MaxNoOfAttributes を超える数の属性を作成した (状況によってはできない) ときに混乱を招くことがありました。)

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

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

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

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

  • MaxNoOfTables

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 128 8 - 20320 N

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

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

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

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

    注記

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

  • MaxNoOfOrderedIndexes

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 128 0 - 4294967039 (0xFFFFFEFF) N

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

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

    注記

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

  • MaxNoOfUniqueHashIndexes

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 64 0 - 4294967039 (0xFFFFFEFF) N

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

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

    注記

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

  • MaxNoOfTriggers

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 768 0 - 4294967039 (0xFFFFFEFF) N

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

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

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

    デフォルト値は 768 です。

  • MaxNoOfIndexes

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。代わりに MaxNoOfOrderedIndexes および MaxNoOfUniqueHashIndexes を使用するようにしてください。

    このパラメータは、一意のハッシュインデックスでのみ使用されます。 クラスタ内に定義された一意のハッシュインデックスごとに 1 つのレコードがこのプールに存在している必要があります。

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

  • MaxNoOfSubscriptions

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 0 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • MaxNoOfSubscribers

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 0 0 - 4294967039 (0xFFFFFEFF) N

    このパラメータは、MySQL Cluster レプリケーションの使用時にのみ関連します。デフォルト値は 0 です。これは、2 * MaxNoOfTables として扱われます。つまり、2 つの MySQL サーバー (1 つはレプリケーションマスターとして機能し、もう 1 つはスレーブとして機能します) のそれぞれに対して NDB テーブルあたり 1 つのサブスクリプションがあります。各サブスクライバは 16 バイトのメモリーを使用します。

    循環レプリケーション、マルチマスターレプリケーション、および 3 つ以上の MySQL サーバーが関与するその他のレプリケーションセットアップを使用するときは、このパラメータをレプリケーションに含まれる mysqld プロセスの数 (これは通常 (常にではありませんが) クラスタの数と同じです) まで増やすようにしてください。たとえば、3 つの MySQL Cluster を使用する循環レプリケーションセットアップがあり、1 つの mysqld が各クラスタに接続され、これらの mysqld プロセスがそれぞれマスターおよびスレーブとして機能する場合は、MaxNoOfSubscribers3 * MaxNoOfTables に設定するようにしてください。

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

  • MaxNoOfConcurrentSubOperations

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 256 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • LateAlloc

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 数値 1 0 - 1 N

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

  • LockPagesInMainMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 数値 0 0 - 2 N

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

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

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

    • 1: プロセスのメモリーを割り当てたあとでロックを実行します。

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

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

    注記

    古い MySQL Cluster リリースでは、このパラメータはブール型でした。デフォルト設定だった 0 または false では、ロックが無効化されました。1 または true では、プロセスのメモリーが割り当てられたあとでそのロックが有効化されました。MySQL Cluster NDB 7.3 以降では、このパラメータの値に 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 に付属するライブラリの代わりに使用することです。

  • StopOnError

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール 1 0、1 N

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

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

  • CrashOnCorruptedTuple

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール true true、false S

    このパラメータを有効にすると、破損したタプルが検出されたときにデータノードが強制的にシャットダウンされます。MySQL Cluster NDB 7.3 以降では、これはデフォルトで有効になっています。

  • Diskless

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 true|false (1|0) false true、false IS

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

    重要

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

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

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

  • ODirect

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール false true、false N

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

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

  • RestartOnErrorInsert

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 エラーコード 2 0 - 4 N

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

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

  • CompressedBackup

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール false true、false N

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

    重要

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

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

  • CompressedLCP

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール false true、false N

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

    重要

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

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

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

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

  • TimeBetweenWatchDogCheck

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 6000 70 - 4294967039 (0xFFFFFEFF) N

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

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

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

  • TimeBetweenWatchDogCheckInitial

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 6000 70 - 4294967039 (0xFFFFFEFF) N

    これは TimeBetweenWatchDogCheck パラメータとほぼ同じですが、TimeBetweenWatchDogCheckInitial はメモリー割り当てが行われる初期起動段階でデータベースノード内部の実行チェック間に経過する時間を制御します。

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

  • StartPartialTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 30000 0 - 4294967039 (0xFFFFFEFF) N

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

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

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

  • StartPartitionedTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 60000 0 - 4294967039 (0xFFFFFEFF) N

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

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

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

  • StartFailureTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 0 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • StartNoNodeGroupTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 15000 0 - 4294967039 (0xFFFFFEFF) N

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

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

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

  • HeartbeatIntervalDbDb

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 5000 10 - 4294967039 (0xFFFFFEFF) N

    障害の発生したノードを検出する主な方法の 1 つは、ハートビートを使用することです。このパラメータは、ハートビート信号の送信回数と予想される受信回数を指定します。3 回連続でハートビート間隔が失敗すると、そのノードはデッドと宣言されます。したがって、ハートビートメカニズムによる障害検出の最大時間は、ハートビート間隔の 4 倍になります。

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

    ネットワーク通信と待機時間も参照してください。

  • HeartbeatIntervalDbApi

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 1500 100 - 4294967039 (0xFFFFFEFF) N

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

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

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

  • HeartbeatOrder

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 数値 0 0 - 65535 S

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

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

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

    次の表に示すように、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 値を設定できます。

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

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

    • クラスタ全体の完全なシャットダウンと再起動。

    • 2 回連続のクラスタのローリング再起動。両方のローリング再起動で、すべてのノードが同じ順序で再起動される必要があります

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

  • ConnectCheckIntervalDelay

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 文字列 0 0 - 4294967039 (0xFFFFFEFF) N

    このパラメータは、データノード間の接続チェックを有効にします。ConnectCheckIntervalDelay 秒の間隔以内に応答できないデータノードは疑いありとみなされ、そのような間隔が 2 回続いたあとでデッドとみなされます。

    このパラメータのデフォルト値は 0 です。これは、MySQL Cluster NDB 7.1 からの変更点です。

  • TimeBetweenLocalCheckpoints

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 4 バイトワードの数 (底 2 の対数として) 20 0 - 31 N

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

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

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

  • TimeBetweenGlobalCheckpoints

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 2000 20 - 32000 N

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

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

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

  • TimeBetweenEpochs

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 100 0 - 32000 N

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

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

  • TimeBetweenEpochsTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 0 0 - 256000 N

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

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

    GCP の保存に 1 分を超える時間がかかった場合、または GCP の保存に 10 秒を超える時間がかかった場合は、常にこのパラメータの現在の値と警告がクラスタログに書き込まれます。

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

  • MaxBufferedEpochs

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 エポック 100 0 - 100000 N

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

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

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

  • MaxBufferedEpochBytes

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 26214400 26214400 (0x01900000) - 4294967039 (0xFFFFFEFF) N

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

  • TimeBetweenInactiveTransactionAbortCheck

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 1000 1000 - 4294967039 (0xFFFFFEFF) N

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

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

  • TransactionInactiveTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 [テキストを参照] 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • TransactionDeadlockDetectionTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 1200 50 - 4294967039 (0xFFFFFEFF) N

    ノードは、トランザクションを含むクエリーの実行時に、クラスタ内のほかのノードが応答するのを待機してから処理を続行します。応答の失敗は、次のいずれかの理由で発生します。

    • ノードがデッドです

    • 操作がロックキューに入りました

    • アクションの実行を要求したノードに非常に高い負荷がかかっている可能性があります。

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

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

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

  • DiskSyncSize

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 4M 32K - 4294967039 (0xFFFFFEFF) N

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

    注記

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

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

  • DiskCheckpointSpeed

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 10M 1M - 4294967039 (0xFFFFFEFF) N

    ローカルチェックポイント中にディスクに転送されるデータの量 (バイト/秒)。この割り当ては DML 操作とバックアップ (バックアップロギングは除く) で共有されます。これは、集約的な DML の実行中に開始されたバックアップが Redo ログバッファーの大量発生によって妨害され、競合が深刻な場合は完全に失敗する可能性があることを意味します。

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

    MySQL Cluster 7.4.1 以降では、このパラメータは非推奨であり、代わりに構成パラメータ MinDiskWriteSpeed, MaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用して LCP とバックアップの書き込み速度を制御できます。

  • DiskCheckpointSpeedInRestart

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 100M 1M - 4294967039 (0xFFFFFEFF) N

    再起動操作の一部であるローカルチェックポイント中にディスクに転送されるデータの量 (バイト/秒)。

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

    MySQL Cluster 7.4.1 以降では、このパラメータは非推奨であり、代わりに構成パラメータ MinDiskWriteSpeed, MaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用して LCP とバックアップの書き込み速度を制御できます。

  • NoOfDiskPagesToDiskAfterRestartTUP

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster 7.4.1 以降では、代わりにそのリリースで導入された構成パラメータ MinDiskWriteSpeed, MaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • MaxDiskWriteSpeed

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.4.1 数値 20M 1M - 1024G S

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

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

    MaxDiskWriteSpeed は MySQL Cluster NDB 7.4.1 で追加されました。

  • MaxDiskWriteSpeedOtherNodeRestart

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.4.1 数値 50M 1M - 1024G S

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

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

    MaxDiskWriteSpeedOtherNodeRestart は MySQL Cluster NDB 7.4.1 で追加されました。

  • MaxDiskWriteSpeedOwnRestart

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.4.1 数値 200M 1M - 1024G S

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

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

    MaxDiskWriteSpeedOwnRestart は MySQL Cluster NDB 7.4.1 で追加されました。

  • MinDiskWriteSpeed

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.4.1 数値 10M 1M - 1024G S

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

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

    MinDiskWriteSpeed は MySQL Cluster NDB 7.4.1 で追加されました。

  • NoOfDiskPagesToDiskAfterRestartACC

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。MySQL Cluster NDB 7.3 では、代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster NDB 7.4.1 以降では、パラメータ MinDiskWriteSpeedMaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • NoOfDiskPagesToDiskDuringRestartTUP (非推奨)

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。MySQL Cluster NDB 7.3 では、代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster NDB 7.4.1 以降では、パラメータ MinDiskWriteSpeedMaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • NoOfDiskPagesToDiskDuringRestartACC (非推奨)

    このパラメータは非推奨であり、MySQL Cluster の今後のバージョンで削除される予定です。MySQL Cluster NDB 7.3 では、代わりに DiskCheckpointSpeedInRestart および DiskSyncSize を使用してください。MySQL Cluster NDB 7.4.1 以降では、パラメータ MinDiskWriteSpeedMaxDiskWriteSpeedMaxDiskWriteSpeedOtherNodeRestart、および MaxDiskWriteSpeedOwnRestart を使用するようにしてください。

  • ArbitrationTimeout

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ミリ秒 7500 10 - 4294967039 (0xFFFFFEFF) N

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

    MySQL Cluster NDB 7.3 以降では、デフォルト値は 7500 ミリ秒 (7.5 秒) です。

  • Arbitration

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 列挙 デフォルト デフォルト、無効、WaitExternal N

    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 を個々のデータノードで異なる値に設定すると、クラスタの動作は不特定になります。

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

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

  • UndoIndexBuffer

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 2M 1M - 4294967039 (0xFFFFFEFF) N

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

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

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

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

    重要

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

  • UndoDataBuffer

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 16M 1M - 4294967039 (0xFFFFFEFF) N

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

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

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

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

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

    重要

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

  • RedoBuffer

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 32M 1M - 4294967039 (0xFFFFFEFF) N

    更新アクティビティーも、すべて記録する必要があります。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 7.3.0 バイト 8192 0 - 64K S

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

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

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

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

  • LogLevelStartup

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 1 0 - 15 N

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

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

  • LogLevelShutdown

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 0 0 - 15 N

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

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

  • LogLevelStatistic

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 0 0 - 15 N

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

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

  • LogLevelCheckpoint

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ログレベル 0 0 - 15 N

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

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

  • LogLevelNodeRestart

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 0 0 - 15 N

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

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

  • LogLevelConnection

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 0 0 - 15 N

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

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

  • LogLevelError

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 0 0 - 15 N

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

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

  • LogLevelCongestion

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 levelr 0 0 - 15 N

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

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

  • LogLevelInfo

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 0 0 - 15 N

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

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

  • MemReportFrequency

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 0 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • StartupStatusReportFrequency

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 0 0 - 4294967039 (0xFFFFFEFF) N

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

デバッグパラメータ  MySQL Cluster NDB 7.3 以降では、DictTrace を使用して、テーブルの作成および削除によって生成されたイベントのトレースを記録できます。このパラメータは、NDB のカーネルコードをデバッグする場合にのみ役立ちます。DictTrace は整数値を取ります。現在サポートされる唯一の値は 0 (デフォルト。ロギングなし) と 1 (ロギングが有効) です。

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

  • BackupDataBufferSize

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 16M 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • BackupLogBufferSize

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 16M 0 - 4294967039 (0xFFFFFEFF) N

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

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

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

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

  • BackupMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 32M 0 - 4294967039 (0xFFFFFEFF) N

    このパラメータは、単純に BackupDataBufferSizeBackupLogBufferSize の合計です。

    MySQL Cluster NDB 7.3 以降では、このパラメータのデフォルト値は 16M バイト + 16M バイト = 32M バイトです。

    重要

    BackupDataBufferSizeBackupLogBufferSize の合計が BackupMemory のデフォルト値を超える場合は、config.ini ファイルでこのパラメータをこれらの合計に明示的に設定する必要があります。

  • BackupReportFrequency

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 0 0 - 4294967039 (0xFFFFFEFF) N

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

    デフォルト値は 0 です。

  • BackupWriteSize

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 256K 2K - 4294967039 (0xFFFFFEFF) N

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

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

  • BackupMaxWriteSize

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 1M 2K - 4294967039 (0xFFFFFEFF) N

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

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

重要

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

  • BackupDataBufferSize >= BackupWriteSize + 188K バイト

  • BackupLogBufferSize >= BackupWriteSize + 16K バイト

  • BackupMaxWriteSize >= BackupWriteSize

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

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

注記

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

  • LockExecuteThreadToCPU

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 CPU ID 64K 0 - 64K N

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

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

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

  • LockMaintThreadsToCPU

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 CPU ID [none] 0 - 64K N

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

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

  • RealtimeScheduler

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール false true、false N

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

    MySQL Cluster NDB 7.3.3 より前では、このパラメータは ndbmtd を実行するノードで正常に機能しませんでした。(Bug #16961971)

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

  • SchedulerExecutionTimer

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 マイクロ秒 50 0 - 11000 N

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

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

  • SchedulerSpinTimer

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 マイクロ秒 0 0 - 500 N

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

    デフォルト値は 0 です。

  • BuildIndexThreads

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 数値 0 0 - 128 S

    このパラメータは、システムまたはノードの起動中に順序付けされたインデックスの再構築時、および ndb_restore --rebuild-indexes の実行時に作成するスレッドの数を指定します。これは、データノードあたり複数のフラグメントがテーブルに存在するとき (たとえば、CREATE TABLEMAX_ROWS オプションが使用されたときなど) にのみサポートされます。

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

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

    データノードの初期再起動中にマルチスレッドによる構築を有効にするには、TwoPassInitialNodeRestartCopy データノード構成パラメータを TRUE に設定します。

  • TwoPassInitialNodeRestartCopy

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール false true、false N

    データノードの初期再起動でマルチスレッドによる順序付けされたインデックスの構築を有効にするには、この構成パラメータを TRUE に設定します。これにより、ノードの初期再起動中にデータの 2 パスコピーが有効になります。

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

  • Numa

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール 1 ... N

    NDB は、Non-Uniform Memory Access の設定と (発生するタイムアウトによる) マルチ CPU システムの影響をかなり受けやすくなっています。この事実と、ほとんどの MySQL Cluster ユーザーが numactl を採用しないことから、Linux システムで ndbd を実行しているときは、NUMA のサポートはデフォルトで無視されます。Linux システムが NUMA をサポートしていて、データノードのメモリーを NUMA で制御する必要がある場合は、このパラメータを 0 に設定できます。

    Numa 構成パラメータは、libnuma.so がインストールされている Linux システムでのみサポートされます。

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

  • MaxNoOfExecutionThreads

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 整数 2 2 - 36 IS
    NDB 7.3.3 整数 2 2 - 72 IS

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

    MaxNoOfExecutionThreads を設定すると、storage/ndb/kernel/src/vm/mt_thr_config.cpp ファイルのマトリックスで決定される各タイプのスレッド数が設定されます。この表は、MySQL Cluster NDB 7.4.3 以降で MaxNoOfExecutionThreads に指定できる値に対応するこれらのスレッド数を示しています (Bug #75220、Bug #20215689)。(以前のバージョンの MySQL Cluster に適用されるマトリックスに関する情報を示す表は、このあとにあります。)MySQL Cluster NDB 7.4.3 で変更された値を含む行は、強調表示のテキストで示しています。

    MaxNoOfExecutionThreads の値 LDM スレッド TC スレッド 送信スレッド 受信スレッド
    0 .. 3 1 1 0 1
    4 .. 6 2 1 0 1
    7 .. 8 4 1 0 1
    9 4 2 0 1
    10 4 2 1 1
    11 4 3 1 1
    12 4 3 1 2
    13 4 3 2 2
    14 4 4 2 2
    15 4 5 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

    次の表に、MySQL CLuster NDB 7.4.2 以前の MaxNoOfExecutionThreads の値に対応する各タイプのスレッド数を取得する方法を示します。この表は MySQL Cluster NDB 7.3.2 以前でも使用できますが、これらのバージョンでは MaxNoOfExecutionThreads の最大値が 36 であるため、この表の 36 より大きい値に対応する行は、MySQL Cluster NDB 7.3.3 より前には適用されません。

    MaxNoOfExecutionThreads の値 LDM スレッド TC スレッド 送信スレッド 受信スレッド
    0 .. 3 1 1 0 1
    4 .. 6 2 1 0 1
    7 .. 8 4 1 0 1
    9 4 2 0 1
    10 4 2 1 1
    11 4 3 1 1
    12 4 3 1 2
    13 4 3 2 2
    14 4 4 2 2
    15 4 5 2 2
    16 8 3 1 2
    17 8 4 1 2
    18 8 4 2 2
    19 8 5 2 2
    20 8 5 2 3
    21 8 5 3 3
    22 8 6 3 3
    23 8 7 3 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 16 12 5 5
    41 16 12 5 6
    42 16 13 5 6
    43 16 13 6 6
    44 16 14 6 6
    45 16 14 6 7
    46 16 15 6 7
    47 16 15 7 7
    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

    MySQL Cluster NDB 7.3 以降では、SUMA (レプリケーション) スレッドが常に 1 つ存在します。

    LDM スレッドの数が NoOfFragmentLogParts を超えないようにする必要があります。このため、このパラメータの値がデフォルト (4) の場合は、MaxNoOfExecutionThreads を 16 以上に設定したときに、この値も増やす必要があります。つまり、NoOfFragmentLogParts を、前の表に示された MaxNoOfExecutionThreads のこのパラメータの値に対応する LDM スレッド数の値に設定してください。

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

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

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

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

    マルチスレッドのデータノードプロセスでは、少なくともここに示す 5 個のスレッドを常に生成します。

    • 1 個のローカルクエリーハンドラ (LDM) スレッド

    • 1 個のトランザクションコーディネータ (TC) スレッド

    • 1 個の送信スレッド

      (このセクションの別の場所で説明するように、独立した送信スレッドを採用しないようにすることもできます。)

    • 1 個の受信スレッド

    • 1 個のサブスクリプションマネージャー (SUMA またはレプリケーション) スレッド

    LDM スレッドの数を変更するには、このパラメータと ThreadConfig のどちらを使用して変更する場合でも、常にシステムの再起動が必要です。クラスタの IndexMemory の使用率が 50% を超える場合、これを変更するにはクラスタの初期再起動が必要です。(このような場合は、最大で 30-35% の IndexMemory 使用率が推奨されます。)それ以外の場合は、ノード間でリソースの使用率と LDM スレッドの割り当てのバランスを取ることができず、結果として LDM スレッドの利用が不十分または過剰になり、最終的にデータノードに障害が発生します。

  • NoOfFragmentLogParts

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 数値 4 4、8、12、16 IN
    NDB 7.3.3 数値 4 4、8、12、16、24、32 IN

    この ndbmtd に属する Redo ログのログファイルグループの数を設定します。MySQL Cluster NDB 7.3.3 より前では、この値は 4 から 16 までの (これらを含む) 4 の偶数倍である必要があります。MySQL Cluster NDB 7.3.3 以降では、最大は 32 です。以前と同様に、値は 4 の偶数倍である必要があります。

    ndbmtd が使用する LQH スレッドの数が NoOfFragmentLogParts を超えないようにする必要があります。また、MaxNoOfExecutionThreads を増やすとこの数が増える場合があります。詳細は、このパラメータの説明を参照してください。

  • ThreadConfig

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 文字列 '' ... IS

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

    ThreadConfig := entry[,entry[,...]]
    
    entry := type={param[,param[,...]]}
    
    type := ldm | main | recv | send | rep | io
    
    param := count=number | cpubind=cpu_list
    

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

    param (パラメータ) には、特定タイプのスレッドの数 (count)、特定タイプのスレッドのバインド先となる CPU (cpubind)、またはその両方を指定します。

    type 属性は、NDB のスレッドタイプを表します。MySQL Cluster NDB 7.3 以降でサポートされるスレッドタイプと各タイプで許容される count 値の範囲を、次のリストに示します。

    • ldm: データを処理するローカルクエリーハンドラ (DBLQH カーネルブロック)。使用される LDM スレッドの数が多いほど、データがより高度にパーティション化されます。各 LDM スレッドには、固有のデータおよびインデックスパーティションのセットと固有の Redo ログが保持されます。MySQL Cluster NDB 7.3.3 以降では、このようなスレッドの最大数は 32 です。MySQL Cluster NDB 7.3.2 以前では、最大は 16 です。

      重要

      LDM スレッドの数を変更するには、システムの再起動をクラスタの操作に対して効果的かつ安全に行う必要があります。(これは、MaxNoOfExecutionThreads を使用して実行する場合にもあてはまります。)IndexMemory の使用率が 50% を超える場合は、クラスタの初期再起動が必要です。このような場合は、IndexMemory の使用率を最大で 30-35% にすることをお勧めします。そうでない場合は、IndexMemory および DataMemory の使用率と LDM スレッドのノード間の割り当てのバランスが取れず、最終的にはデータノードの障害につながる可能性があります。

    • tc: 進行中のトランザクションの状態を含むトランザクションコーディネータスレッド (DBTC カーネルブロック)。MySQL Cluster NDB 7.3 では、TC スレッドの数を構成できます。MySQL Cluster NDB 7.3.3 以降では、合計 32 個が使用可能です。以前は 16 個でした。

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

      範囲: (NDB 7.3.3 以降) 1-32、(NDB 7.3.2 以前) 1-16。

    • main: スキーマ管理を提供するデータディクショナリおよびトランザクションコーディネータ (DBDIH および DBTC カーネルブロック)。これは、常に 1 つの専用スレッドで処理されます。

      範囲: 1 のみ。

    • recv: 受信スレッド (CMVMI カーネルブロック)。各受信スレッドは、MySQL Cluster 内のほかのノードと通信するための 1 つ以上のソケット (ノードあたり 1 ソケット) を処理します。MySQL Cluster NDB 7.3 以降では、複数の受信スレッドがサポートされます。MySQL Cluster NDB 7.3.2 以前では、このようなスレッドの最大数は 8 です。MySQL Cluster NDB 7.3.3 以降では、最大は 16 です。

      範囲: (NDB 7.3.3 以降) 1-16、(NDB 7.3.2 以前) 1-8。

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

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

      範囲: (NDB 7.3.3 以降) 0-16、(NDB 7.3.2 以前) 0-8。

    • rep: レプリケーションスレッド (SUMA カーネルブロック)。非同期のレプリケーション操作は、常に 1 つの専用スレッドで処理されます。

      範囲: 1 のみ。

    • io: ファイルシステムおよびその他の操作。これらは、要求の厳しいタスクではなく、常に 1 つの I/O 専用スレッドでまとめて処理されます。

      範囲: 1 のみ。

簡単な例:

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

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

ディスクデータの構成パラメータ  ディスクデータの動作に影響を与える構成パラメータには、次が含まれます。

  • DiskPageBufferMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 64M 4M - 1T N

    これは、ディスク上のページをキャッシュするために使用されるスペースの量を指定するもので、config.ini ファイルの [ndbd] または [ndbd default] セクションで設定されます。これは、バイト単位で測定されます。各ページは最大 32K バイトを占有します。これは、常に N * 32K バイトのメモリーがクラスタディスクデータのストレージに使用されることを意味します (N は負でない整数です)。

    このパラメータのデフォルト値は 64M (32K バイトのページ 2000 個分) です。

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

  • SharedGlobalMemory

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 128M 0 - 64T N

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

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

  • DiskIOThreadPool

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 スレッド 2 0 - 4294967039 (0xFFFFFEFF) N

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

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

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

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

    • ディスクのパフォーマンスとタイプ  ディスクデータファイルの処理用に提供できるスレッドの数は、ディスクの速度とスループットにも依存します。ディスクの速度が速く、スループットが高いほど、より多くの I/O スレッドを使用できます。弊社のテスト結果では、従来のディスクよりソリッドステートディスクドライブの方が (つまり DiskIOThreadPool の値が大きいほど) はるかに多くのディスク I/O スレッドを処理できることを示しています。

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

  • ディスクデータのファイルシステムパラメータ  次のリストのパラメータを使用すると、シンボリックリンクを使用せずに MySQL Cluster ディスクデータのファイルを特定のディレクトリに配置できるようになります。

    • FileSystemPathDD

      有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
      NDB 7.3.0 ファイル名 [テキストを参照] ... IN

      このパラメータを指定すると、MySQL Cluster ディスクデータのデータファイルと Undo ログファイルが指定されたディレクトリに配置されます。データファイル、Undo ログファイル、またはその両方をオーバーライドするには、FileSystemPathDataFilesFileSystemPathUndoFiles、またはその両方の値をこれらのパラメータの説明に従って指定します。データファイルでは 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 7.3.0 ファイル名 [テキストを参照] ... IN

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

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

    • FileSystemPathUndoFiles

      有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
      NDB 7.3.0 ファイル名 [テキストを参照] ... IN

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

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

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

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

    • InitialLogFileGroup

      有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
      NDB 7.3.0 文字列 [テキストを参照] ... S

      このパラメータを使用して、クラスタの初期起動の実行時に作成されるログファイルグループを指定できます。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 ログファイルは、FileSystemPathFileSystemPathDD、および 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 データノード構成パラメータの値でサイズが決定されるグローバルメモリープールから取得されます。このパラメータの設定値が小さすぎて、ログファイルグループの初期サイズまたは Undo バッファーサイズとして InitialLogFileGroup に設定された値が大きすぎる場合は、クラスタの起動時にデフォルトのログファイルグループが作成されないか、クラスタの起動が完全に失敗する可能性があります。

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

    • InitialTablespace

      有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
      NDB 7.3.0 文字列 [テキストを参照] ... S

      このパラメータを使用して、クラスタの初期起動を実行したときに作成される MySQL 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 つを指定する必要があります。データファイルは、FileSystemPathFileSystemPathDD、および FileSystemPathDataFiles に設定された値に従って、CREATE TABLESPACE または ALTER TABLESPACE ステートメントの結果として作成された場合と同じように配置されます。

      たとえば、config.ini ファイルの [ndbd default] セクションに InitialTablespace を指定する次の行について考えます (InitialLogfileGroup と同様、異なるデータノードに異なる値を設定したときの MySQL 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 を指定してデータノードを起動したときに作成され、その後 MySQL Cluster ディスクデータのテーブルを作成するたびに使用できます。

ディスクデータと GCP 停止エラー  ディスクデータテーブルを使用するときに発生するエラー:Node nodeid killed this node because GCP stop was detected(エラー 2303) などは、多くの場合、GCP 停止エラーと呼ばれています。このようなエラーは、Redo ログが十分な速さでディスクにフラッシュされていない場合に発生します。これは通常、ディスクの速度が低く、ディスクのスループットが十分でないことが原因です。

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

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

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

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

  • ExtraSendBufferMemory

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

  • TotalSendBufferMemory

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

    このパラメータを設定する場合、許容される最小値は 256K バイト、最大値は 4294967039 です。

  • ReservedSendBufferMemory

    このパラメータは、MySQL Cluster NDB 6.4.0 以降の NDBCLUSTER のソースコード内にあります。しかし、現在は有効になっていません。

    このパラメータは MySQL Cluster NDB 7.2 で非推奨になり、MySQL Cluster の今後のバージョンで削除される予定です (Bug #11760629、Bug #53053)。

TotalSendBufferMemory の動作と使用、 および MySQL Cluster での送信バッファーメモリーパラメータの構成の詳細は、セクション18.3.2.12「MySQL Cluster の送信バッファーパラメータの構成」を参照してください。

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

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

  • RedoOverCommitCounter

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 数値 3 0 - 4294967039 (0xFFFFFEFF) N

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

    RedoOverCommitCounter のデフォルト値は 3 です。0 に設定すると、この制限は無効になります。

  • RedoOverCommitLimit

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 20 0 - 4294967039 (0xFFFFFEFF) N

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

    デフォルトでは、RedoOverCommitLimit は 20 秒です。0 に設定すると、Redo ログのフラッシュタイムアウトのチェックが無効になります。このパラメータは MySQL Cluster NDB 7.1.10 で追加されました。

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

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

  • StartFailRetryDelay

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 0 0 - 4294967039 (0xFFFFFEFF) N

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

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

  • MaxStartFailRetries

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 符号なし 3 0 - 4294967039 (0xFFFFFEFF) N

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

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

NDB インデックス統計のパラメータ  次のリストのパラメータは、MySQL Cluster NDB 7.2.1 で導入された NDB インデックス統計の生成に関連しています。

  • IndexStatAutoCreate

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール false false、true S

    インデックスが作成されたときの自動統計収集を有効または無効にします。デフォルトで無効になっています。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatAutoUpdate

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 ブール false false、true S

    インデックス変更のモニタリングを有効または無効にし、変更が検出される自動統計更新をトリガーします。更新をトリガーするために必要な変更の量およびレベルは、IndexStatTriggerPct および IndexStatTriggerScale オプションの設定によって決定されます。

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatSaveSize

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 バイト 32768 0 - 4294967039 (0xFFFFFEFF) IN

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

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

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

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

  • IndexStatSaveScale

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 パーセンテージ 100 0 - 4294967039 (0xFFFFFEFF) IN

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

  • IndexStatTriggerPct

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 パーセンテージ 100 0 - 4294967039 (0xFFFFFEFF) IN

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

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatTriggerScale

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 パーセンテージ 100 0 - 4294967039 (0xFFFFFEFF) IN

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

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。

  • IndexStatUpdateDelay

    有効なバージョン 型/単位 デフォルト 範囲/値 再起動タイプ
    NDB 7.3.0 60 0 - 4294967039 (0xFFFFFEFF) IN

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

    このパラメータは MySQL Cluster NDB 7.2.1 で追加されました。


User Comments
Sign Up Login You must be logged in to post a comment.