Documentation Home
MySQL Enterprise Backup ユーザーズガイド (バージョン 3.11)
Download this Manual
PDF (US Ltr) - 1.3Mb
PDF (A4) - 1.3Mb
HTML Download (TGZ) - 164.9Kb
HTML Download (Zip) - 191.2Kb


7.2 リストアパフォーマンスの最適化

このセクションでは、MySQL Enterprise Backup 製品によるリストア操作のパフォーマンスの考慮事項について説明します。このサブジェクトは、次の理由で、バックアップパフォーマンスの議論と別に、独自のセクションに値するほど重要です。

  • リストア操作は、バックアップ方法の違いによってきわめて大きく異なる傾向があるバックアップとリストアサイクルのフェーズです。たとえば、mysqldump を使用したバックアップパフォーマンスが許容できても、mysqldump では一般にリストア操作に MySQL Enterprise Backup よりはるかに時間がかかります。

  • リストア操作は多くの場合、アプリケーションや Web サイトの停止時間を最小にすることがきわめて重要である緊急時に実行されます。

  • リストア操作は、常にデータベースサーバーがシャットダウンした状態で実行されます。

  • リストア操作は、ファイルを転送する場合の I/O とネットワーク速度、およびデータを圧縮解除する場合の CPU 速度、プロセッサコアなどの低レベルの考慮事項におもに依存します。

リストアジョブに指定できるオプションの組み合わせについては、セクション5.1.1.3「既存のバックアップのリストア」を参照してください。

さまざまなクラスのバックアップデータのリストア

部分バックアップのリストアは、物理的にコピーするデータが少ないため、フルバックアップのリストアより時間がかかりません。部分バックアップの作成については、セクション5.1.9「部分バックアップとリストアオプション」を参照してください。

圧縮バックアップのリストアは、データの圧縮解除に必要な時間が、一般にネットワーク経由で転送されるデータが少ないことによって節約される時間より大きくなるため、非圧縮バックアップのリストアより時間がかかります。バックアップをリストアする前に、ストレージを再整理して、バックアップを圧縮解除するための十分な領域を解放する必要がある場合、必要な合計時間の見積もりに、その管理作業を含めます。緊急時に、バックアップデータをリストアする前に圧縮解除するために必要な時間が許容できないことがあります。データベースサーバーに圧縮されたバックアップと圧縮解除後のデータの両方を保持するための十分な空き領域がない場合。そのため、データが重要であるほど、圧縮を使用しないことを選択して、リストアプロセスが可能な限り高速で信頼性が高くなるように、低速で大規模なバックアップを許容することも考えられます。圧縮バックアップの作成については、セクション5.1.7「圧縮オプション」を参照してください。

単一ファイルバックアップをリストアするためのアンパックプロセスは、一般に実効速度や余分なストレージの点で、コストがかかりません。各ファイルは、その最終の宛先に直接アンパックされ、個別にコピーされた場合と同じです。そのため、単一ファイルバックアップを使用することで、バックアップを大幅に高速化したり、そのストレージ要件を削減したりできる場合、それは一般にリストア時間とのトレードオフが発生しません。単一ファイルバックアップの作成については、セクション5.1.1.5「単一ファイルバックアップの操作」を参照してください。

Apply-Log フェーズ

別個のマシンにバックアップデータを格納し、そのマシンがデータベースサーバーをホストするマシンほどビジーでない場合、一部の後処理の作業 (apply-log フェーズ) をその別個のマシンにオフロードできます。セクション5.1.1.2「既存のバックアップデータの apply-log 操作」

初期バックアップ後すぐに apply-log フェーズを実行する (リストアを高速にする) か、またはリストア直前まで延期する (バックアップを高速にする) かには、常にパフォーマンスのトレードオフがあります。緊急時に、リストアパフォーマンスはもっとも重要な考慮事項です。そのため、データが重要であるほど、apply-log フェーズをバックアップ直後に実行することが重要になります。backup-and-apply-log オプションを指定して、同じサーバーでバックアップフェーズと apply-log フェーズを組み合わせるか、または高速の初期バックアップを実行し、バックアップデータを別のサーバーに転送してから、セクション5.1.1.2「既存のバックアップデータの apply-log 操作」のいずれかのオプションを使用して、apply-log フェーズを実行します。

セクション5.1.1.2「既存のバックアップデータの apply-log 操作」

ネットワークパフォーマンス

データ処理操作で、データベースとの通信に Unix ソケットの方が TCP/IP より高速であるという伝統的なアドバイスをご存知かもしれません。mysqlbackup コマンドはオプション --protocol=tcp--protocol=socket、および --protocol=pipe をサポートしていますが、これらのオプションはバックアップやリストアのパフォーマンスに重大な影響を与えません。これらのプロセスには、クライアント/サーバーネットワークトラフィックよりも、ファイルコピー操作がかかわります。--protocol オプションによって制御されるデータベース通信は少量です。たとえば、mysqlbackup はデータベース接続経由でデータベースパラメータに関する情報を取得しますが、テーブルまたはインデックスデータは取得しません。

並列リストア

mysqlbackup コマンドは最新のマルチコア CPU およびオペレーティングシステムスレッドを利用して、バックアップ操作を並列で実行できます。リストアプロセスのさまざまな側面に使用されるスレッド数を制御するオプションについては、セクション5.1.11「パフォーマンス/スケーラビリティー/容量オプション」を参照してください。リストア時に未使用のシステム容量があることがわかっている場合、これらのオプションの値を増加し、そうすることによって、リストアのパフォーマンスが向上するかどうかをテストすることを考慮してください。

  • RAID ストレージ構成を使用して、バックアップパフォーマンスをチューニングし、テストする場合、オプション設定 --read-threads=3 --process-threads=6 --write-threads=3 の組み合わせを考慮してください。組み合わせ --read-threads=1 --process-threads=6 --write-threads=1 と比較します。

  • 非 RAID ストレージ構成を使用して、バックアップパフォーマンスをチューニングし、テストする場合、オプション設定 --read-threads=1 --process-threads=6 --write-threads=1 の組み合わせを考慮してください。

  • 3 つのスレッドオプションのいずれかの値を増やす場合は、--limit-memory オプションの値も増やして、追加のスレッドに、作業の実行に十分なメモリーを与えます。

  • CPU があまりビジーでない (80% 未満の CPU 利用率) 場合は、--process-threads オプションの値を増やします。

  • リストア元のストレージデバイス (ソースドライブ) でもっと多くの I/O リクエストを処理できる場合は、--read-threads オプションの値を増やします。

  • リストア先のストレージデバイス (宛先ドライブ) でもっと多くの I/O リクエストを処理できる場合は、--write-threads オプションの値を増やします。

オペレーティングシステムに応じて、topiostatsardtrace などのコマンド、またはグラフィカルパフォーマンスモニターを使用して、リソース利用率を測定できます。システム iowait 値が約 20% に達したら、読み取りまたは書き込みスレッド iowait の数を増やさないでください。