MySQL Enterprise Backup ユーザーズガイド (バージョン 3.11)  /  ...  /  バックアップのパフォーマンスおよび容量に関する考慮事項の概要

1.3 バックアップのパフォーマンスおよび容量に関する考慮事項の概要

バックアップ戦略では、パフォーマンスとストレージ領域が重要な側面になります。ユーザーは、データベースサーバーでの CPU オーバーヘッドを小さくして、バックアップを迅速に完了させることを希望しています。また、バックアップデータをコンパクトにして、即座にリストアできるように複数のバックアップを手元に用意しておくことも希望しています。別のシステムへのバックアップデータの転送は、迅速で便利に行えることが必要です。このようなすべての側面は、mysqlbackup コマンドのオプションによって制御されます。

場合によっては、さまざまな種類のオーバーヘッド (CPU サイクル、ストレージ領域、ネットワークトラフィック) のバランスをとる必要があります。計画メンテナンス中、または災害が発生したときにデータのリストアに要する時間を必ず意識してください。たとえば、MySQL Enterprise Backup の主要ないくつかの機能について、次のような検討要素があります。

  • 並列バックアップは、MySQL Enterprise Backup 3.8 でデフォルトであり、以前の MySQL Enterprise Backup リリースに対してパフォーマンスを大きく改善しています。読み取り、処理、および書き込みが、すべての MEB 操作の主な下位操作になります。たとえば、バックアップ操作で、MySQL Enterprise Backup は最初に、ディスクからデータを読み取り、続いてこのデータを処理し、データをディスクに書き込み、再度データを読み取って検証します。MySQL Enterprise Backup では、これらの下位操作が互いに独立しており、並列して実行できるため、パフォーマンスが向上します。読み取り、処理、および書き込みの下位操作は、同じ種類の複数のスレッド (複数の読み取りスレッド、複数の処理スレッド、および複数の書き込みスレッド) を使用して並列的に実行され、その結果パフォーマンスが向上します。パフォーマンスの向上は通常、ソースデバイスとターゲットデバイスの両方で RAID アレイが使用される場合と、より多くの CPU サイクルを並列して使用できる圧縮バックアップの場合に大きくなります。

    並列バックアップは、16M バイトのブロックを使用したブロックレベルの並列処理を採用しています。異なるスレッドは、単一ファイル内の別々の 16M バイトのチャンクに対して読み取り、処理、および書き込みを行えます。並列バックアップは、インスタンスに単一の大きなシステムテーブルスペースが含まれているか、(innodb_file_per_table モードで作成された .ibd ファイルによって表される) 小さな多数のテーブルスペースが含まれているかにかかわらず、操作のパフォーマンスを改善します。

  • 増分バックアップは完全バックアップより高速で、データベースサーバー上のストレージ領域を節約し、別のサーバーにバックアップデータを転送するネットワークトラフィックを軽減します。増分バックアップでは、リストアできるようにバックアップを準備しておく追加処理が必要になります。この処理は別のシステムで実行できるため、データベースサーバーでの CPU オーバーヘッドを最小限に抑えることができます。

  • 圧縮バックアップ は InnoDB テーブル用のストレージ領域を節約し、バックアップデータを別のサーバーに転送するネットワークトラフィックを軽減します。このバックアップでは、非圧縮バックアップより多くの CPU オーバーヘッドが発生します。リストア中、圧縮されたデータと圧縮解除されたデータが同時に必要になるため、この追加ストレージ領域とデータを圧縮解除する時間を考慮に入れてください。

    InnoDB テーブル内のデータを圧縮する以外に、圧縮バックアップは、InnoDB テーブルスペースファイル内の未使用領域のスキップも行います。非圧縮バックアップにはこの未使用領域が含まれます。

  • 領域が限られている場合や、安価で大容量だが速度が遅いテープなどのストレージデバイスを使用している場合は、パフォーマンスと領域に関する考慮事項は異なります。できるだけ高速なバックアップを目的とせず、データベースサーバーにバックアップデータの中間コピーを格納しないようにしたい場合があります。MySQL Enterprise Backup は、単一ファイルのバックアップを生成して、そのファイルをほかのサーバーまたはデバイスに直接ストリーミングすることができます。バックアップデータはローカルシステムに一切保存されないため、データベースサーバーでの領域オーバーヘッドが回避されます。また、一連のバックアップファイルを保存し、続いて別のサーバーまたはストレージデバイスへの転送用にそれらをアーカイブにまとめるというパフォーマンスオーバーヘッドも回避されます。詳細は、セクション3.3.5.1「別のデバイスまたはサーバーへのバックアップデータのストリーミング」を参照してください。

    圧縮を行うためのデータベースサーバーでの CPU オーバーヘッドが、テープデバイス上でのストレージ領域の追加よりも高価なため、バックアップデータをテープにストリーミングするときに通常はバックアップを圧縮しません。別のサーバーにバックアップデータをストリーミングするときに、どのサーバーに CPU 能力の余裕が多いか、圧縮によってどれだけのネットワークトラフィックを軽減できるかに応じて、元のサーバーで圧縮することも、ストリーミング先のサーバーで圧縮することもできます。または、即座にリストアできるように、バックアップデータをストリーミング先のサーバーで圧縮せずに保存しておくこともできます。

データをリカバリする速度が重要である障害リカバリの場合、重要なバックアップデータを準備して圧縮解除された状態にしておくと、リストア操作のステップ数を最小限に抑えることができます。

速度が非常に重要になるのは障害リカバリ中です。たとえば、mysqldump コマンドで実行された論理バックアップは、MySQL Enterprise Backup 製品を使用した物理バックアップとほぼ同じ時間がかかりますが (少なくとも小さなデータベースの場合)、リストア操作は通常、MySQL Enterprise Backup のほうが速くなります。実際のデータファイルをコピーしてデータディレクトリに戻すと、mysqldump 出力から SQL ステートメントを再実行して生じる、行を挿入しインデックスを更新するというオーバーヘッドはスキップされます。

Linux システムと Unix システムでのサーバーパフォーマンスへのあらゆる影響を最小限に抑えるために、MySQL Enterprise Backup は、posix_fadvise() システムコールを使用することによって、オペレーティングシステムのディスクキャッシュに格納せずにバックアップデータを書き込みます。この手法は、バックアップデータを大量に 1 回限り読み取る操作で、頻繁にアクセスされるデータがディスクキャッシュからフラッシュされないようにすることにより、バックアップ操作後の速度低下を最小限に抑えます。

手法の詳細と、バックアップおよびリストアのパフォーマンスにかかわるトレードオフの詳細は、第7章「MySQL Enterprise Backup のパフォーマンスに関する考慮事項を参照してください。