MySQL Cluster のローカル
チェックポイントの設定に使用される
Logging
and Checkpointing および
Data
Memory, Index Memory, and String Memory
は分離しては存在しませんが、むしろお互い非常に依存しています。このセクションでは—
DataMemory
、IndexMemory
、NoOfDiskPagesToDiskAfterRestartTUP
、NoOfDiskPagesToDiskAfterRestartACC
、および
NoOfFragmentLogFiles
—
を含むこれらのパラメータがどのように実際のクラスタでお互いに関連しているかについて説明します。
重要NoOfDiskPagesToDiskAfterRestartTUP
および NoOfDiskPagesToDiskAfterRestartACC
のパラメータは MySQL 5.1.6
では少なくなっています。MySQL 5.1.6 から 5.1.111
では、LCP
の際のディスクの書き込みは可能な最高速度で行われます。MySQL
5.1.12 からは、LCP
の速度およびスループットはパラメータ
DiskSyncSize
、DiskCheckpointSpeed
、および
DiskCheckpointSpeedInRestart
を使用して管理しています。項14.4.4.5. 「Defining Data Nodes」
参照。
この例では、弊社のアプリケーションは以下のオペレーションの種類を毎時実行すると想定しています。
50000 選択
15000 挿入
15000 更新
15000 削除
弊社ではまたアプリケーションで使用されるデータについては以下想定しています。
40 カラムを持つ1 つのテーブルを現在開発中です。
各カラムは 32 バイトのデータを保持できます。
アプリケーションによる一般的な
UPDATE
の実行では 5
カラムの値に影響します。
アプリケーションでは NULL
の値は挿入されません。
よい出発点はローカル チェックポイント (LCP) 間の経過時間を決定することです。システムの再起動時には何の価値もありませんが、REDO ログを実行するためにこのインターバルの 40-60 パーセントを使います。 — 例えば、LCP 間の時間が 5 分 (300 秒) だとすると、REDO の読み込みに 2 ~ 3 分 (120 ~ 180 秒) かかります。
ノード毎の最大データ量は
DataMemory
パラメータのサイズによって想定できます。この例では、それは
2 GB
と想定しています。NoOfDiskPagesToDiskAfterRestartTUP
パラメータはユニット時間でのデータがチェックポイントされる量を表します。—
しかし、このパラメータは実際は 100
ミリセカンドでチェックポイントされる 8K
メモリのページ数で表されます。300 秒で 2 GB
がおよそ 1 秒間に 6.8 MB、あるいは 100
ミリセカンドで 700 KB では 100
ミリセカンドでおよそ 85 ページです。
同様に、NoOfDiskPagesToDiskAfterRestartACC
をインデックスに必要なローカルのチェックポイントに時間およびメモリの量で計算できます。—
つまり、IndexMemory
です。インデックスに 512 MB
を用意すると、このパラメータに対しこれはおよそ
100 ミリセカンドで 20 8-KB ページになります。
次に、必要なREDO ログ
ファイル数を決める必要があります。—
つまり、フラグメント ログ ファイル—
相当するパラメータであるNoOfFragmentLogFiles
。少なくとも
3 つのローカル
チェックポイントの記録を維持できる十分な
REDO ログ
ファイルがあることを確認する必要があります。生産の設定では、常に不安定要素—
例えばディスクが常に最高速度あるいは最大のスループットで動作するのかわかりません。このため、最悪の状況をを想定しte仕様を強化し、6
つのローカル
チェックポイントをカバーしたレコードを十分に維持できるフラグメント
ログ ファイルを計算します。
ディスクが REDO ログ および UNDO
ログへの書き込みもまた処理していることを忘れないことも大切です。ディスクに書き込まれているデータ量が
NoOfDiskPagesToDiskAfterRestartACC
および
NoOfDiskPagesToDiskAfterRestartTUP
の値で決められた量がディスクの利用できる帯域量に近づいたら、ローカル チェックポイント間の時間を長くしたくなるかもしれません。
ローカル ポイント毎に 5 分 (300 秒) とすると、書き込みログ レコードを最大速度 6 * 300 = 1800 秒でサポートする必要があります。REDO ログ レコードのサイズは 72 バイトに更新されカラム値毎に 4 バイト、それに更新されたカラムの最大サイズを加えると、それにトランザクションで更新された各テーブル レコードに 1 つの REDO ログ レコード、データが常駐する各ノードにあります。このセクションで以前設定したオペレーション数を使用すると、以下が得られます。
毎時 50000 選択オペレーションで 0 のログ
レコード (よって 0 バイト)
ですので、SELECT
ステートメントは REDO
ログには記録されません。
毎時 15000 DELETE
ステートメントはおよそ 毎秒 5
削除オペレーションです。(見積もりにおいては控えめにしたいので、ここでまとめると、以下の計算になります。)カラムが削除によって更新されませんので、これらのステートメントはオペレーションごとに
5 オペレーション * 72 バイト = 毎秒 360
バイトになります。
毎時 15000 UPDATE
ステートメントはおよそ毎秒 5
回の更新に相当します。各更新に 72
バイト、それにカラム毎に 4バイト * 5
カラムの更新、さらにカラム毎に 32 バイト *
5 カラム— つまりオペレーション毎に 72 +
20 + 160 = 252 バイトになります。これを毎秒 5
オペレーションを乗算すると毎秒 1260
バイトになります。
毎秒 15000 INSERT
ステートメントは毎秒 5
挿入オペレーションに相当します。各挿入は
REDO ログ スペース 72
バイトが必要で、それに レコード * 40
カラム毎に 4 バイト、およびカラム * 40
カラム毎に 32 バイトで 72 + 160 + 1280 = 1512
バイト/オペレーションになります。これに 5
オペレーション/秒で 7560
バイト/秒になります。
ですから 1 秒に書き込まれる REDO
ログの合計はおよそ 0 + 360 + 1260 + 7560 = 9180
バイトになります。これを 1800 秒で換算すると
16524000 バイトが REDO
ロギングに必要になります。およそ 15.75
MB です。NoOfFragmentLogFiles
に使用される単位は 4 16-MB ログ ファイル—
つまり、64 MB
になります。このように、パラメータの最小値
(3)
はこの例で示したシナリオに十分で、ですから
64 の 3 倍 = 192 MB、あるいは 12
倍が要求された場合、デフォルトの 8 (あるいは
512 MB)
はこのケースでは必要を満たすに十分です。
変更したテーブルのレコードのコピーは UNDO ログにあります。上記で説明したシナリオでは、UNDO ログはデフォルトの設定で提供された以上のスペースは必要ありません。しかしながら、ディスクのサイズの場合には少なくとも 1 GB 割り当てるのが賢明です。