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


3.3.6 オプティミスティックバックアップの作成

オプティミスティックバックアップは、頻繁に変更されるテーブルが少数しかない大規模なデータベースのバックアップおよびリストアのパフォーマンスを改善するために MySQL Enterprise Backup 3.11 で導入された機能です。

大規模なデータベース (テラバイト単位など) のホットバックアップ中、バックアップが進行しているときに、膨大な Redo ログファイルがサーバー上で生成される場合があります。Redo ログファイルが mysqlbackup で処理できる速度よりも速く増大すると、mysqlbackup が Redo ログサイクルに追いつけず、LSN が mysqlbackup によって読み取られる前にサーバーによって上書きされたときに、バックアップ操作は実際に失敗することがあります。さらに、mysqlbackup がバックアップに適用する巨大な ibbackup_logfile ファイル (大きな Redo ログファイルから作成) を持っているときに、リストアできるようにバックアップを準備するための apply-log ステップに、非常に長い時間がかかることがあります。Redo ログの読み取りと書き込みに利用できる I/O リソースが、バックアップおよびリストアプロセス中に不足しているときに、問題は増大します。

オプティミスティックバックアップは、ユーザーには透過的である次の 2 つの内部フェーズにバックアッププロセスを分割することによって問題を軽減します。

  1. オプティミスティックフェーズ: この最初のフェーズでは、バックアッププロセス中に変更される可能性の低いテーブル (下では非アクティブテーブルと呼ばれ、optimistic-time オプションや、除外によって optimistic-busy-tables オプションでユーザーが識別します) が、MySQL インスタンスをロックせずにバックアップされます。また、これらのテーブルは、バックアップが終了するまでに変更されることはないと予想されるため、Redo ログ、Undo ログ、およびシステムテーブルスペースは、このフェーズでは mysqlbackup によってバックアップされません。

  2. 通常フェーズ: この 2 番目のフェーズでは、最初のフェーズでバックアップされていないテーブル (下ではビジーテーブルと呼ばれます) が、一般のバックアップで処理されるのと似た方法でバックアップされます。InnoDB ファイルが最初にコピーされ、続いて MySQL インスタンスがロックされた状態でほかの関連ファイルがコピーまたは処理されます。また、非アクティブテーブルの一部が、オプティミスティックフェーズでバックアップされたあとに、実際に変更されていることが判明した場合は、通常フェーズでもう一度コピーされます。Redo ログ、Undo ログ、およびシステムテーブルスペースもこのフェーズでバックアップされます。

オプティミスティックバックアップは、optimistic-time オプションまたは optimistic-busy-tables オプションが使用されているときに必ず行われます。これらのオプションの使用方法については、セクション5.1.11「パフォーマンス/スケーラビリティー/容量オプション」での詳細な説明を参照してください。予想どおりに、オプションで識別された非アクティブテーブルがバックアップ中にあまり変更されていない場合、apply-log 操作が非常に高速になるため、全体のバックアップ時間 (バックアップ操作の時間に加えて apply-log 操作の時間) は、通常のバックアップと比べ大幅に短縮される可能性があります。ただし、識別された非アクティブテーブルがバックアッププロセス中に大幅に変更されていることがわかった場合は、オプティミスティックバックアップの実行によるメリットは限られたものになり、最悪の場合、オプティミスティックバックアップの実行時間が実際に長くなることがあり、単一ファイルバックアップの場合は、バックアップのサイズが通常のバックアップと比べて増大します。したがって、ユーザーは、オプティミスティックバックアップを実行しようとするときには、どのテーブルが非アクティブで、どのテーブルがビジーかを慎重に識別する必要があります。

注記

オプティミスティックバックアップは、増分バックアップや、トランスポータブルテーブルスペース (TTS) を使用したバックアップには実行できません。

次の例で、オプティミスティックバックアップの作成方法を示します。

例 3.18 オプション optimistic-time=YYMMDDHHMMSS を使用したオプティミスティックバックアップ

この例では、2011 年 5 月 16 日の正午以降に変更されたテーブルがビジーテーブルとして扱われ、オプティミスティックバックアップの通常フェーズでバックアップされます。その他のテーブルはすべてオプティミスティックフェーズでバックアップされます。

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=110516120000 backup

例 3.19 オプション optimistic-time=now を使用したオプティミスティックバックアップ

この例では、すべてのテーブルが非アクティブテーブルとして扱われ、オプティミスティックバックアップのオプティミスティックフェーズでバックアップされます。

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=now backup

例 3.20 optimistic-busy-tables オプションを使用したオプティミスティックバックアップ

この例では、名前に mytables- のサフィクスが付けられた mydatabase 内のテーブルがビジーテーブルとして扱われ、オプティミスティックバックアップの通常フェーズでバックアップされます。その他のテーブルはすべてオプティミスティックフェーズでバックアップされます。

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables='mydatabase\.mytables-.*'  backup

optimistic-time オプションと optimistic-busy-tables オプションの両方を使用し、これらがビジーテーブルにするテーブルの決定で競合した場合、optimistic-busy-tablesoptimistic-time より優先されます。例:

例 3.21 optimistic-busy-tables オプションと optimistic-time オプションの両方を使用したオプティミスティックおよび部分バックアップ

この例では、名前に mytables- のサフィクスが付けられた mydatabase 内のテーブルがビジーテーブルとして扱われ、2010 年 5 月 16 日の optimistic-time で指定された時間以降に変更されていない場合でも、通常フェーズでバックアップされます。

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables='mydatabase\.mytables-.*'  \
--optimistic-time=100516 backup



User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
  Posted by Revathi Rangachari on April 16, 2015
A working example of optimistic backup with two tables - in RHEL 6.3, mysql 5.6.18 MEB 3.12:

./mysqlbackup --only-known-file-types --host='localhost' --user=user --password=pass --socket='/var/lib/mysql/mysql.sock' --with-timestamp --slave-info --datadir=/var/lib/mysql/datadir --backup-dir=/meb/bkp --optimistic-busy-tables='mydatabase.mytable1, mytable2' --optimistic-time=now backup-and-apply-log

Thanks Daniel, yes there is a typo there (near --socket=) which I added now. I wanted to try the command without any regex and see if backup completed successfully.
  Posted by Daniel So on March 16, 2017
The above example is wrong. There's a missing quote for --socket=, and the regex is also incorrect. It should look like this:

./mysqlbackup --only-known-file-types --host='localhost' --user=user --password=pass --socket='/var/lib/mysql/mysql.sock' --with-timestamp --slave-info --datadir=/var/lib/mysql/datadir --backup-dir=/meb/bkp --optimistic-busy-tables='mydatabase\.mytable[12]' --optimistic-time=now backup-and-apply-log
Sign Up Login You must be logged in to post a comment.