PDF (US Ltr)- 1.3Mb
PDF (A4)- 1.3Mb
オプティミスティックバックアップは、頻繁に変更されるテーブルが少数しかない大規模なデータベースのバックアップおよびリストアのパフォーマンスを改善するために MySQL Enterprise Backup 3.11 で導入された機能です。
大規模なデータベース (テラバイト単位など) のホットバックアップ中、バックアップが進行しているときに、膨大な Redo ログファイルがサーバー上で生成される場合があります。Redo ログファイルがmysqlbackupで処理できる速度よりも速く増大すると、mysqlbackupが Redo ログサイクルに追いつけず、LSN がmysqlbackupによって読み取られる前にサーバーによって上書きされたときに、バックアップ操作は実際に失敗することがあります。さらに、mysqlbackupがバックアップに適用する巨大なibbackup_logfileファイル (大きな Redo ログファイルから作成) を持っているときに、リストアできるようにバックアップを準備するためのapply-logステップに、非常に長い時間がかかることがあります。Redo ログの読み取りと書き込みに利用できる I/O リソースが、バックアップおよびリストアプロセス中に不足しているときに、問題は増大します。
オプティミスティックバックアップは、ユーザーには透過的である次の 2 つの内部フェーズにバックアッププロセスを分割することによって問題を軽減します。
オプティミスティックフェーズ: この最初のフェーズでは、バックアッププロセス中に変更される可能性の低いテーブル (下では「非アクティブテーブル」と呼ばれ、
optimistic-timeオプションや、除外によってoptimistic-busy-tablesオプションでユーザーが識別します) が、MySQL インスタンスをロックせずにバックアップされます。また、これらのテーブルは、バックアップが終了するまでに変更されることはないと予想されるため、Redo ログ、Undo ログ、およびシステムテーブルスペースは、このフェーズではmysqlbackupによってバックアップされません。通常フェーズ: この 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.20optimistic-busy-tablesオプションを使用したオプティミスティックバックアップ
この例では、名前にmytables-のサフィクスが付けられたmydatabase内のテーブルがビジーテーブルとして扱われ、オプティミスティックバックアップの通常フェーズでバックアップされます。その他のテーブルはすべてオプティミスティックフェーズでバックアップされます。
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables='mydatabase\.mytables-.*' backupoptimistic-timeオプションとoptimistic-busy-tablesオプションの両方を使用し、これらがビジーテーブルにするテーブルの決定で競合した場合、optimistic-busy-tablesがoptimistic-timeより優先されます。例:
例 3.21optimistic-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