MySQL 5.1 リファレンスマニュアル :: 14 MySQL Cluster :: 14.4 MySQL Cluster の設定 :: 14.4.4 設定ファイル :: 14.4.4.5 Defining Data Nodes
« 14.4.4.4 マネジメント サーバーの定義
14.4.4.6 SQL および他の API ノードの定義 »
Section Navigation      [Toggle]

14.4.4.5. Defining Data Nodes

[NDBD] および [NDBD DEFAULT] セクションはクラスタのデータノードの振る舞いを設定するために使用されます。バッファ サイズ、プール サイズ、タイムアウトなどを管理する多くのパラメータがあります。唯一必須のパラメータは:

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

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

ほとんどのデータ ノードのパラメータは [NDBD DEFAULT] セクションで設定されます。ローカル値を設定できる明示的に指定されたパラメータのみが [NDBD] セクションで変更できます。存在する場合、HostName、Id および ExecuteOnComputer はローカルの [NDBD] セクションで定義され、config.ini の他のセクションでは定義されません。換言すれば、これらのパラメータは 1 つのデータ ノード固有のものです。

メモリの使用およびバッファ サイズに影響を及ぼすパラメータは、K、M、あるいはG を 1024、1024×1024、あるいは 1024×1024×1024 の単位を示す接尾辞として使用できます。 (例えば、100K は 100 × 1024 = 102400 の意味です。)パラメータ名および値は現在ケース センシティブです。

データ ノードの認識

Id 値 (つまり、データ ノードの識別子) はノードが起動されたときあるいは設定ファイルでコマンドラインに割り当てることができます。

  • Id

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

  • ExecuteOnComputer

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

  • HostName

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

  • ServerPort (旧式)

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

  • NoOfReplicas

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

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

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

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

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

  • DataDir

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

  • FileSystemPath

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

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

  • BackupDataDir

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

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

DataMemory および IndexMemory は [NDBD] パラメータで、実際のレコードおよびそれらのインデックスを保持するメモリ シグメントのサイズを指定します。これらの値を設定する際に、DataMemory および IndexMemory がどのように使われるかを知っておくことが重要です。なぜなら、それらはクラスタの実際の使用を反映して更新される必要があるからです。

  • DataMemory

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

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

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

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

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

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

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

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

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

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

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

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

  • IndexMemory

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

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

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

  • StringMemory

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

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

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

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

以下の例でテーブルにメモリがどのように使用され手いるか説明します。このテーブルの定義を考慮します。 

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

各レコードには 12 バイトのデータと 12 バイトのオーバーヘッドがあります。無効なカラムを無くすと 4 バイトのオーバーヘッドを節約できます。さらに、カラム a と b にレコード毎におよそ 10 バイト使用する順序付けされた 2 つのインデックスがあります。ベース テーブルにレコード毎におよそ 29 バイト使用するプライマリ キーのハッシュ インデックスがあります。独自の制約はプライマリ キーとして b およびカラムとして a を持つ個別のテーブルにより課されます。この他のテーブルは example テーブルでさらにレコード毎に 29 バイトのインデックス メモリおよびレコード データに 8 バイトおよびオーバーヘッドに 12 バイト使用します。

このように、100 万のレコードでは、プライマリ キーと独自の制約のハッシュ インデックス処理に 58MB のインデックス メモリが必要です。さらに、ベース テーブルと独自のインデックス テーブル、および 2 つの順序付けされたインデックス テーブルのレコードに 64MB 必要です。

この様にハッシュ インデックスはかなりのメモリ スペースを必要としますが、その代わりに高速のデータ アクセスを提供します。それらはまた独自の制約を処理するために MySQL で使用されています。

現在、パーテッション アルゴリズムはハッシュのみで順序付けされたインデックスは各ノードに対してローカルです。このように、順序付けされたインデックスは一般的には独自の制約の処理には使用できません。

IndexMemory および DataMemory の重要な点は、各ノード グループのデータベース サイズの合計はすべてのデータ メモリおよびすべてのインデックス メモリの合計であるということです。各ノード グループはレプリケート （複製) された情報の保持に使用されますので、 2 つのレプリカを持つ 4 つのノードがあれば、2 つのノード グループがあることになります。このように、利用可能なデータ メモリの合計は各データ ノードに対して 2 × DataMemory です。

DataMemory と IndexMemory を全てのノードに対して同じ値で設定するよう強くお勧めします。クラスタではデータの配布はすべてのノードで同一ですので、各ノードの最大利用可能スペースはクラスタで一番小さいノード　スペースより大きくなることはできません。

DataMemory と IndexMemory は変更できますが、これらのいずれかを少なくすることは危険で、そうすることによってノードあるいは MySQL Cluster 全体がメモリ スペースの不足によって再起動できなくなります。これらの値を増やすことは容認できますが、そのようなアップグレードをする場合にはソフトウェアのアップグレードと同じ方法で、つまり設定ファイルのアップグレード、次に各データ ノードを順番に再起動してからマネジメント サーバーを再起動するようお勧めします。

アップグレードによって使用できるインデックス メモリの量は増えません。挿入は直ぐできます。しかし、行はトランザクションが実施されるまで実際は削除されません。

トランザクション パラメータ

これから説明する次の 3 つの [NDBD] パラメータは重要です。なぜなら、それらはシステムが処理する並列トランザクション数およびトランザクションのサイズに影響を及ぼすからです。MaxNoOfConcurrentTransactions はノードで可能な並列トランザクション数を設定します。MaxNoOfConcurrentOperations は更新段階およびあるいは同時ロック時のレコード数を設定します。

これらのパラメータはどちらも (特に MaxNoOfConcurrentOperations は) 特定の値をしかもデフォルトの値を使用しないで設定する ユーザーにとっては目標値になると思われます。デフォルトの値はこれらの値が過剰なメモリを使用しないように確認するために、小さなトランザクションを使用してシステムに設定されます。

  • MaxNoOfConcurrentTransactions

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

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

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

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

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

  • MaxNoOfConcurrentOperations

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

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

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

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

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

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

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

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

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

  • MaxNoOfLocalOperations

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

トランザクションのテンポラリ ストレージ

次の [NDBD] パラメータ セットはクラスタ トランザクションの一部のステートメントを実行する際のテンポラリのストレージを決定するために使用されます。すべてのレコードがステートメントが完了しクラスタが実行あるいはロールバックを待っているときにリリースされます。

これらのパラメータのデフォルト値で殆どの状況をカバーします。しかし、多くの行数やオペレーションが絡むトランザクションのサポートが必要なユーザーはシステムの並列効果を高めるためにこれらの値を増やす必要がある場合があります。一方、トランザクション数が少ないアプリケーションのユーザーはメモリを節約するためにその値を下げることができます。

  • MaxNoOfConcurrentIndexOperations

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

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

  • MaxNoOfFiredTriggers

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

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

  • TransactionBufferMemory

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

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

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

スキャンとバッファリング

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

  • MaxNoOfConcurrentScans

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

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

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

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

  • MaxNoOfLocalScans

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

  • BatchSizePerLocalScan

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

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

  • LongMessageBuffer

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

ロギングとチェックポイント

これらの [NDBD] パラメータはログおよびチェックポイントの振る舞いを管理します。

  • NoOfFragmentLogFiles

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

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

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

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

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

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

  • MaxNoOfOpenFiles

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

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

  • MaxNoOfSavedMessages

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

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

Metadata Objects

次の [NDBD] パラメータ セットはメタデータ オブジェクトのプール サイズを定義し、インデックス、イベント、およびクラスタ間のレプリケーションに使用される属性、テーブル、インデックス、およびトリガ オブジェクトの最大数の定義に使用されます。これらはクラスタへの単なる 「助言」 で、ここに指定されない値は以下のデフォルトの値になります。

  • MaxNoOfAttributes

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

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

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

  • MaxNoOfTables

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

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

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

  • MaxNoOfOrderedIndexes

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

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

  • MaxNoOfUniqueHashIndexes

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

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

  • MaxNoOfTriggers

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

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

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

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

  • MaxNoOfIndexes

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

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

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

Boolean パラメータ

データ ノードの振る舞いも boolean 値に使用された [NDBD] パラメータ セットの影響を受けます。これらのパラメータはそれそれ 1 あるいは Y に設定すると TRUE、および 0 あるいは N に設定すると FALSE を指定できます。

  • LockPagesInMainMemory

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

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

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

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

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

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

  • StopOnError

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

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

  • Diskless

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

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

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

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

  • RestartOnErrorInsert

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

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

タイムアウト、インターバル、およびディスク ページングの管理

クラスタ データ ノードの様々な操作でのタイムアウトやインターバルを指定する多くの [NDBD] パラメータがあります。ほとんどのタイムアウトの値はミリセカンドで指定されます。値がミリセカンドでない場合にはその都度説明します。

  • TimeBetweenWatchDogCheck

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

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

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

  • StartPartialTimeout

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

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

  • StartPartitionedTimeout

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

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

  • StartFailureTimeout

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

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

  • HeartbeatIntervalDbDb

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

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

  • HeartbeatIntervalDbApi

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

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

  • TimeBetweenLocalCheckpoints

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

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

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

  • TimeBetweenGlobalCheckpoints

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

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

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

  • TimeBetweenInactiveTransactionAbortCheck

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

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

  • TransactionInactiveTimeout

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

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

  • TransactionDeadlockDetectionTimeout

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

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

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

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

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

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

  • DiskSyncSize

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

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

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

  • DiskCheckpointSpeed

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

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

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

  • DiskCheckpointSpeedInRestart

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

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

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

  • NoOfDiskPagesToDiskAfterRestartTUP

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

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

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

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

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

  • NoOfDiskPagesToDiskAfterRestartACC

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

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

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

  • NoOfDiskPagesToDiskDuringRestartTUP

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

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

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

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

  • NoOfDiskPagesToDiskDuringRestartACC

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

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

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

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

  • ArbitrationTimeout

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

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

バッファリングとロギング

RedoBuffer

すべての更新はログに記録する必要があります。REDO ログはこれらの更新をシステムが再起動されたときにはいつでも実行できるようにします。NDB リカバリ アルゴリズムはデータの 「ファジー」 チェックポイントを UNDO ログと一緒に使用し、REDO ログを使用してすべての変更を修復ポイントまで再現します。

RedoBuffer は REDO ログが書き込まれるバッファのサイズを設定します。デフォルトでは 8MB です。このバッファは REDO ログのレコードをディスクに書き込む際のファイル システムへのフロント エンドとして使用されます。このバッファが小さ過ぎると、NDB ストレージ エンジンがエラーコード 1221 (REDO log buffers overloaded を発行します)。

最小値は 1MB です。ノードがディスク無しの状態で実行されると、ディスクの書き込みが NDB ストレージ エンジンのファイルシステム抽出レイヤによって 「フェイク」 されるため、これらのパラメータはペナルティ無しで最小値に設定されます。

重要ローリングの再起動時にこのパラメータを下げることは安全ではありません。

注:MySQL の以前のバージョンの UndoIndexBuffer および UndoDataBuffer パラメータは MySQL 5.1 ではもはや必要なくなりました（あったにしても）。

ログ メッセージの管理

クラスタの管理においては、様々なイベントに関して stdout に送られたログ メッセージ数を管理できることが非常に重要です。各イベント カテゴリでは、16 の実行可能なイベント レベル （0～15 番まで） あります。イベントのレポートを所定のイベント カテゴリのレベル 15 設定するとそのカテゴリのすべてのイベント レポートが stdout に送られます。0 に設定するとそのカテゴリにはイベント レポートが無いことを意味します。

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

相似性のレベルをマネジメント クライアントに設定してどのイベント レベルをクラスタ ログでレコードするかを決めることができます。

  • LogLevelStartup

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

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

  • LogLevelShutdown

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

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

  • LogLevelStatistic

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

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

  • LogLevelCheckpoint

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

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

  • LogLevelNodeRestart

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

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

  • LogLevelConnection

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

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

  • LogLevelError

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

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

  • LogLevelInfo

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

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

バックアップ パラメータ

この項で説明した[NDBD] パラメータはオンライン バックアップの実行用に確保するメモリ バッファを定義します。

  • BackupDataBufferSize

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

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

  • BackupLogBufferSize

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

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

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

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

  • BackupMemory

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

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

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

  • BackupWriteSize

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

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

  • BackupMaxWriteSize

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

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

重要これらのパラメータを指定する際は、以下の関係が真であることが必要です。そうでない場合、データ ノードは起動しません。

  • BackupDataBufferSize >= BackupWriteSize + 188KB

  • BackupLogBufferSize >= BackupWriteSize + 16KB

  • BackupMaxWriteSize >= BackupWriteSize

Copyright © 1997, 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices
Top / / / Up / Table of Contents