無料PHPプログラム

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」 参照。

この例では、弊社のアプリケーションは以下のオペレーションの種類を毎時実行すると想定しています。

弊社ではまたアプリケーションで使用されるデータについては以下想定しています。

よい出発点はローカル チェックポイント （LCP) 間の経過時間を決定することです。システムの再起動時には何の価値もありませんが、REDO ログを実行するためにこのインターバルの 40-60 パーセントを使います。 ? 例えば、LCP 間の時間が 5 分 (300 秒) だとすると、REDO の読み込みに 2 ～ 3 分 (120 ～ 180 秒) かかります。

ノード毎の最大データ量は DataMemory パラメータのサイズによって想定できます。この例では、それは 2 GB と想定しています。NoOfDiskPagesToDiskAfterRestartTUP パラメータはユニット時間でのデータがチェックポイントされる量を表します。? しかし、このパラメータは実際は １00 ミリセカンドでチェックポイントされる 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 ログ レコード、データが常駐する各ノードにあります。このセクションで以前設定したオペレーション数を使用すると、以下が得られます。

ですから 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 割り当てるのが賢明です。