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


7.1 バックアップパフォーマンスの最適化

このセクションでは、MySQL Enterprise Backup 製品によるバックアップ操作のパフォーマンスの考慮事項について説明します。バックアップ手順を最適化し、チューニングする場合、raw パフォーマンス (バックアップの完了にかかる時間) とデータベースサーバー上のオーバーヘッドの量の両方を測定します。バックアップパフォーマンスを測定する場合、次を考慮します。

  • バックアップ手順によって課せられる制限。たとえば、バックアップを 8 時間おきに取得する場合、バックアップが終了するまで 8 時間かからないようにする必要があります。

  • ネットワークおよびストレージインフラストラクチャーによって課せられる制限。たとえば、特定のストレージデバイスに多くのバックアップを収納する必要がある場合、バックアッププロセスが遅くなっても、圧縮バックアップを使用する方がよいと考えられます。

  • バックアップ時間とリストア時間のトレードオフ。一連のオプションによって、バックアップがやや遅くなるが、リストアを大幅に速くすることができる場合、それらのオプションを選択してもよいと考えられます。リストアプロセスのパフォーマンス情報については、セクション7.2「リストアパフォーマンスの最適化」を参照してください。

フルまたは増分バックアップ

フルバックアップの取得後、変更されたデータのみがバックアップされる増分バックアップを実行することによって、後続のバックアップを迅速に実行できます。増分バックアップの場合、mysqlbackup に、--incremental または --incremental-with-redo-log-only オプションを指定します。これらのオプションについては、セクション5.1.8「増分バックアップオプション」を参照してください。増分バックアップのバックアップおよび適用段階の使用方法の指示については、セクション3.3.2「増分バックアップの作成」および例4.3「完全バックアップへの増分バックアップの適用」を参照してください。

圧縮バックアップ

バックアップデータを別のサーバーに転送する前に圧縮することは、バックアップが行われるデータベースサーバーへの追加の CPU オーバーヘッドを伴いますが、バックアップデータの最終の宛先となるサーバー上のネットワークトラフィックが減少し、ディスク I/O も減少します。圧縮を使用するかどうかを決定する場合、データベースサーバーの負荷、ネットワークの帯域幅、およびデータベースと宛先サーバーの相対容量を考慮します。圧縮バックアップの作成については、セクション3.3.3「圧縮バックアップの作成」およびセクション5.1.7「圧縮オプション」を参照してください。

圧縮には、バックアップパフォーマンスとリストアパフォーマンスのトレードオフがあります。緊急時に、バックアップデータをリストアする前に圧縮解除するために必要な時間が許容できないことがあります。また、データベースサーバーに圧縮されたバックアップと圧縮解除後のデータの両方を保持するための十分な空き領域がない場合に、ストレージの問題が発生することもあります。そのため、データが重要であるほど、圧縮を使用しないことを選択して、リストアプロセスが可能な限り高速で信頼性が高くなるように、低速で大規模なバックアップを許容することも考えられます。

単一ファイルバックアップ

単一ファイルバックアップ自体は、出力ファイルのディレクトリツリーを生成する従来のバックアップの種類より、必ずしも高速ではありません。そのパフォーマンス上の利点は、それを実行しない場合に、バックアップデータを単一の出力ファイルに組み合わせて、それを別のサーバーに転送するなど、連続して実行する必要がありそうなさまざまなステップを組み合わせることにあります。単一ファイルバックアップに関するオプションについてはセクション5.1.1.5「単一ファイルバックアップの操作」および、使用方法の指示についてはセクション3.3.5「単一ファイルバックアップの作成」を参照してください。

InnoDB 構成オプション設定

MySQL 5.5 以前では、MySQL サーバーが正常にシャットダウンせずに強制終了した場合に、起動時間が長くなるのを避けるため、Redo ログをかなり小さく維持することが一般的な方法でした。MySQL 5.5 以降では、「InnoDB 構成変数の最適化」に説明するように、クラッシュリカバリのパフォーマンスが大幅に向上しています。それらのリリースでは、Redo ログファイルを大きくすることが、バックアップ戦略やデータベースワークロードに役立つ場合に、そうすることができます。

後述するように、設定 innodb_file_per_table=1 で実行することが望ましいと考えられる理由は多数あります。

並列バックアップ

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 の数を増やさないでください。

MyISAM の考慮事項

重要
  • mysqlbackup コマンドはデータベースの使用を妨げることなく、InnoDB テーブルをバックアップしますが、InnoDB 以外のファイル (MyISAM テーブルや .frm ファイルなど) をコピーする最終段階では、ステートメント FLUSH TABLES WITH READ LOCK を使用して、一時的にデータベースを読み取り専用状態にします。バックアップパフォーマンスを最高にし、データベース処理への影響を最小にするために:

    1. バックアップの実行時に長い SELECT クエリーやその他の SQL ステートメントを実行しないでください。

    2. MyISAM テーブルを比較的小さく維持し、おもに読み取り専用または読み取りが大半の作業用にします。

    これにより、mysqlbackup 実行の最後のロックフェーズが短くなる (おそらく数秒) ため、mysqld の通常の処理をあまり妨げません。データベースアプリケーションで先述の条件が満たされない場合は、--only-innodb または --only-innodb-with-frm オプションを使用して、InnoDB テーブルのみをバックアップするか、または --no-locking オプションを使用して、InnoDB 以外のファイルをバックアップします。--no-locking 設定でコピーされる MyISAM、.frm、およびその他のファイルがバックアップの最終フェーズで更新されない場合、それらの整合性を保証できないことに注意してください。

  • 大きなデータベースの場合、バックアップの実行に長時間かかることがあります。mysqlbackup コマンドが終了コード 0 を返していることを確認するか、または mysqlbackup がテキスト mysqlbackup completed OK! を出力していることを観察して、常に mysqlbackup が正常に完了していることをチェックしてください。

  • mysqlbackup コマンドは、以前の MySQL 6.0 ソースツリーの MySQL Backup オープンソースプロジェクトとは異なります。MySQL Enterprise Backup プロジェクトは MySQL Backup イニシアチブに代わりました。

  • テーブルに関する DDL 操作が実行中でない期間に、バックアップをスケジュールしてください。DDL 操作と同時のバックアップに対する制約については、セクションA.1「MySQL Enterprise Backup の制限」を参照してください。

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

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

データサイズ

特定のテーブルやデータベースに重要度の低い情報が格納されているか、めったに更新されない場合、それらをもっとも頻繁なバックアップから除外し、もっと少ない頻度のスケジュールでバックアップするようにできます。関連オプションについては、セクション5.1.9「部分バックアップとリストアオプション」、および特定のテーブル、データベース、またはストレージエンジンからデータを除外することに関する手順については、セクション3.3.4「部分バックアップの作成」を参照してください。部分バックアップは、少量のデータをコピー、圧縮、転送するため、高速になります。

InnoDB データファイルの全体のサイズを最小にするには、MySQL 構成オプション innodb_file_per_table を有効にすることを考慮してください。このオプションは、いくつかの点で、InnoDB テーブルのデータサイズを最小にすることができます。

  • これは、InnoDB システムのテーブルスペースのサイズの拡大を防ぎ、後で MySQL によってのみ使用可能なディスク領域を割り当てます。たとえば、大量のデータが一時的にのみ必要になったり、誤ってまたは試験中にロードされたりすることがあります。innodb_file_per_table オプションを使用しないと、システムテーブルスペースがこのすべてのデータを保持するために拡張し、その後縮小することはありません。

  • これは、テーブルが削除されるか、切り捨てられると、InnoDB テーブルとそのインデックスによって使用されているディスク領域をすぐに解放します。各テーブルとその関連付けられたインデックスは、これらの DDL 操作によって削除されるか、空にされる .ibd ファイルによって表されます。

  • これにより、大量のデータが削除されるか、インデックスが削除された場合に、.ibd ファイル内の未使用の領域が OPTIMIZE TABLE ステートメントによって回収されます。

  • これにより、セクション3.3.4「部分バックアップの作成」に説明するように、一部の InnoDB テーブルをバックアップし、その他をバックアップしない部分バックアップが可能になります。

クエリーで使用されていないインデックスの作成を避けます。インデックスはバックアップデータの領域を占めるため、不要なインデックスによってバックアッププロセスが遅くなります。(mysqlbackup によって使用されるコピーおよびスキャンメカニズムでは、それらの作業の実行にインデックスに依存しません。)たとえば、クエリーによって使用されるインデックスは 1 つだけであるため、テーブルのカラムごとにインデックスを作成しても一般に役立ちません。プライマリキーカラムは各 InnoDB セカンダリインデックスに含まれるため、多数または著しく長いカラムや、同じカラムのさまざまな配列の複数のセカンダリインデックスから構成されるプライマリキーを定義する領域を無駄にします。

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 フェーズを実行します。