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

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

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

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

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

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

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

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

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

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

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

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

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

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

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