Chat now with support
Chat with Support

NetVault Plug-in for MySQL 4.4 - ユーザーズ・ガイド

Dell™ NetVault™ Backup Plug-in for MySQL － はじめに プラグインのインストールと削除 プラグインの設定 データのバックアップ データのリストア MySQLレプリケーションの使用 フェイルオーバ・クラスタ環境でのプラグインの使用 トラブルシューティング Dellについて

バックアップ計画の策定

MySQLバックアップ戦略を定義する際、以下の点を明確にする必要があります。
•
［MySQL Standard/Community］オプションまたは［MySQL Enterpriseバックアップ］オプションのどちらを使用するか環境に両方のバージョンを導入している場合でも、プラグインでは1つの計画のみを使用することができます。MEBベース方法またはmysqldumpベース方法のいずれかを使用する必要があり、両方を併用することはできない点に注意してください。
MEBベース・オプションを使用すると、バックアップに選択したすべてのデータベース・オブジェクトに対してmysqlbackupコマンドが1度実行され、ジョブ・ログ内にmysqlbackupログが出力されます。データのバックアップには2つのステージが含まれます。最初のステージでは、すべてのInnoDBテーブルがコピーされます。2番目のステージでは、すべてのテーブル・タイプがコピーされます。InnoDBテーブルのホット・バックアップをサポートするだけでなく、MEBベース・オプションはバックアップ・パフォーマンスを向上させます。
mysqldumpベース・オプションを使用する場合、各テーブル、トリガ、およびストアド・プロシージャに対してコマンドが実行されます（ホット・バックアップはサポートされません）。
•
フル・バックアップ時にインスタンス全体の読取り専用アクセスが必要なことを認識した上で、フル・バックアップをどのような頻度で実行するか
•
バックアップの速度とリストアの速度のどちらを重視するか
•
許容できる最大データ損失量
上記の点を明確にしておくと、実装するバックアップ・タイプおよび頻度を定義する際に役立ちます。
•
MySQL Standard/Community用バックアップ・タイプの確認
•
MySQL Enterpriseバックアップ用バックアップ・タイプの確認
•
MySQL Standard/Community用バックアップ・シーケンス例

MySQL Standard/Community用バックアップ・タイプの確認

［MySQL Standard/Community］オプションを使用する場合、本プラグインはmysqldumpを使用して以下のタイプのバックアップを実行します。
•
フル・バックアップ
•
増分バックアップ
•
差分バックアップ
•
個々のデータベース/テーブル・コピーのみのバックアップ
各MySQLインスタンスのデータ保護要件に適したバックアップ・シーケンスを選択するには、まずこれらのバックアップの違いを理解する必要があります。
フル・バックアップ
［MySQL Standard/Community］オプション用フル・バックアップの場合、本プラグインはmysqldumpユーティリティを使用して、インスタンスに含まれるすべてのデータベースをバックアップします。フル・バックアップはほぼすべてのリストア・シナリオの起点になるため、あらゆるバックアップ戦略の基盤となります。プラグインで生成されたフル・バックアップを使用して、インスタンス全体、個々または複数のデータベース、個々または複数のテーブルをリストアできます。
［MySQLレプリケーションを可能にする］オプションが無効化され、［特定時点リカバリを可能にする］オプションが有効化されている場合、［フルまたはインクリメンタル・バックアップ後、バイナリ・ログをパージ］オプションはデフォルトで有効化されますが、フルまたは増分バックアップ後にMySQLバイナリ・ログをパージする必要があります。
［フルまたはインクリメンタル・バックアップ後、バイナリ・ログをパージ］オプションを選択しない場合、プラグインは設定ファイルで最終バックアップのログを追跡し続けます。これにより必要に応じてバイナリ・ログを手動でパージすることができます。例えば、MySQLレプリケーション環境で、バイナリ・ログがスレーブ・インスタンスにレプリケートされるまで、バイナリ・ログをマスタ・インスタンスからパージしたくない場合などは、ユーザはバイナリ・ログを手動でパージする必要があります。
増分バックアップ
増分バックアップでは、最後のフルまたは増分バックアップ以降に生成されたバイナリ（トランザクション）・ログをバックアップし、次にバイナリ・ログをパージします。バイナリ・ログはインスタンスに基づくため、すべてのデータベースのトランザクション・ログがまとめてバックアップされ、パージされます。
増分バックアップを使用すると、不正な更新やテーブルの削除などのデータ損傷の前および後の時点にリストアできるため、メディア障害またはデータ損傷の発生後のデータ損失を低減する上で重要です。フル・バックアップとは異なり、増分バックアップはバックアップ中に読み取り専用アクセスを必要としません。
MySQLの増分バックアップを実行するには、バイナリ・ログを有効にする-log-binオプションを使用してMySQLインスタンスを開始する必要があります。この手順は、MySQLサーバでのバイナリ・ログの有効化（MySQL Standard/Communityオプションのみ）で概説しています。詳しくは、『MySQLリファレンス・マニュアル』のバイナリ・ログに関するセクションを参照してください。
上記で説明したように、［フルまたはインクリメンタル・バックアップ後、バイナリ・ログをパージ］オプションを使用して、フルまたはインクリメンタル・バックアップ後にバイナリ・ログをパージする必要があります。このオプションを使用しない場合は、本プラグインは設定ファイルで最終バックアップのログを追跡し続けます。これにより必要に応じてバイナリ・ログを手動でパージすることができます。
差分バックアップ
差分バックアップでは、最後のフルまたは増分バックアップ以降に生成されたバイナリ（トランザクション）・ログをバックアップします。ただし、この形式のバックアップでは、完了時にバイナリ・ログがパージされません。このため、各差分バックアップには、前の差分バックアップにも含まれていたバイナリ・ログおよび前の差分バックアップ以降に生成されたバイナリ・ログが含まれることになり、以降の差分バックアップのサイズが大きくなるだけでなく、その時間も長くなります。例えば、月曜日から金曜日までの差分バックアップを伴って、日曜日にフル・バックアップの実行がスケジュールされている場合、月曜日の差分には日曜日のフル･バックアップ以降生成されたトランザクション・ログ・ファイルが含まれます。一方、火曜日の差分には、月曜日に生成されたバイナリ・ログ・ファイルだけでなく、火曜日に生成されたバイナリ・ログ・ファイルも含まれます。水曜日の差分バックアップには、月曜日、火曜日、および水曜日のバイナリ・ログが含まれる、というようになります。
増分バックアップと同様に、差分バックアップを使用すると、メディア障害またはデータ損傷が発生した場合のデータ損失を低減でき、障害/損傷の前および後の時点にリストアできます。フル・バックアップとは異なり、差分バックアップはバックアップ中に読み取り専用アクセスを必要としません。
差分バックアップを実行するには、バイナリ・ログを有効にする-log-binオプションを使用してMySQLインスタンスを開始する必要があります。この手順は、MySQLサーバでのバイナリ・ログの有効化（MySQL Standard/Communityオプションのみ）で概説しています。詳しくは、『MySQLリファレンス・マニュアル』のバイナリ・ログに関するセクションを参照してください。
増分バックアップと差分バックアップの比較
増分バックアップでは、バイナリ・ログがバックアップ後にパージされ、最後の増分バックアップ後に作成されたバイナリ・ログのみがバックアップされるため、以降の増分バックアップの実行時間は短くなります。ただし、増分バックアップを使用するリストア・シーケンスでは、フル・バックアップから障害時点までに実行されたすべての増分バックアップを継続してリストアする必要があります。このため、複数のリストア・ジョブを開始するためにデータベース管理者に必要な操作が多くなり、リストアに長い時間がかかる可能性があります。
差分バックアップでは、バイナリ・ログがバックアップ後にパージされず、最後のフル・バックアップ後に作成されたすべてのバイナリ・ログがバックアップの対象となるため、以降の各差分バックアップの実行時間は長くなります。ただし、差分バックアップを使用するリストア・シーケンスでは、フル・バックアップのリストア後に差分バックアップを1つのみリストアするだけで済みます。このため、リストア・プロセスでデータベース管理者に必要な操作が少なくなり、リストア時間は短くなります。
個々のデータベース/テーブル・コピーのみのバックアップ
場合によっては、データベース全体の包括的なバックアップおよびリストア手順に影響を与えることなく、特殊な目的でバックアップを実行しなければならないことがあります。たとえば、バックアップをテスト環境のソースにしたり、レプリケーション・スレーブ・インスタンスの初期同期用に使用する場合などです。個々のデータベース/テーブル・コピーのみのバックアップは、このような特殊な目的のために設計されており、MySQL環境をコピーすることができます。コピーのみのバックアップは、設定されたバックアップ・シーケンスから独立しているため、フル、増分、または差分バックアップのリカバリ可能性には影響しません。ただし、フル・バックアップの代わりとして使用することはできません。

MySQL Enterpriseバックアップ用バックアップ・タイプの確認

［MySQL Enterpriseバックアップ］オプションについて、本プラグインは選択されたすべてのデータベース・オブジェクトに対してmysqlbackupコマンドを1度実行し、以下のタイプのバックアップをアーカイブします。フルと増分。
フル・バックアップ
［MySQL Enterpriseバックアップ］オプション用フル・バックアップの場合、本プラグインはmysqldumpユーティリティを使用して、インスタンスに含まれるすべてのデータベース・オブジェクトをバックアップします。フル・バックアップはほぼすべてのリストア・シナリオの起点になるため、あらゆるバックアップ戦略の基盤となります。プラグインで生成されたフル・バックアップを使用して、インスタンス全体、個々または複数のデータベース、個々または複数のテーブルをリストアできます。
増分バックアップ
InnoDBテーブルについて、最後のフルまたは増分バックアップ以降に変更が加わったデータのみがバックアップされます。非InnoDBテーブルの場合、最後のフルまたは増分バックアップ以降に何かテーブル内で変更された場合、テーブル全体がバックアップされます。

MySQL Standard/Community用バックアップ・シーケンス例

以下のセクションで、さまざまなバックアップ・シーケンスを示します。
フル・バックアップのみ
ビジネス要件で前日までのデータ保護が保証されており、読み取り専用アクセスが毎日許容される場合（勤務時間外など）、フル・バックアップのみを毎日実行すれば十分でしょう。データベース管理者は、データベースを最後のフル・バックアップ時点にリカバリすることはできますが、MySQLサーバに存在しているバイナリ・ログを使用してPITリカバリを実行することはできません。
フル・バックアップと増分バックアップ
ビジネス要件で前日までのデータ保護が保証されているが、ターゲットMySQLインスタンスへの読み取り専用アクセスが断続的にのみ許容され（週1回または隔週の勤務時間外など）、バックアップ時間をできる限り短縮する必要がある場合、フル・バックアップと増分バックアップの組合せが最適です。たとえば、毎週日曜日の夜11:00にフル・バックアップが実行され、さらに月曜日から土曜日の午後11:00にトランザクション・ログ・ファイルのバックアップが実行されているとします。この場合、各増分バックアップには、前夜のバックアップ、すなわち日曜日の夜に実行されたフル・バックアップまたはいずれかの増分バックアップ以降に生成されたバイナリ・ログが含まれます。
このバックアップ・タイプ・シーケンスのリストアには、より長い時間がかかることに注意してください。たとえば、火曜日にリカバリを実行する場合、日曜日のフル・バックアップと月曜日の増分バックアップをリストアする必要があります。また、木曜日にリカバリを実行する場合は、日曜日のフル・バックアップに続いて、月曜日、火曜日、および水曜日の増分バックアップをリストアする必要があります。バックアップ時間は短くなりますが、複数のリストア・ジョブを実行するために必要な操作が多くなるため、リストア時間は長くなる可能性があります。
フル・バックアップと差分バックアップ
ビジネス要件で前日までのデータ保護が保証されているが、ターゲットMySQLインスタンスへの読み取り専用アクセスが断続的にのみ許容され（週1回または隔週の勤務時間外など）、リストア時間をできる限り短縮する必要がある場合、フル・バックアップと差分バックアップの組合せが最適です。たとえば、フル・バックアップを毎週日曜日の夜11:00に実行し、差分バックアップを月曜日から土曜日の午後11:00に実行します。各差分バックアップには、最後のフル・バックアップ以降に生成されたバイナリ・ログが含まれます。前述のように、この場合の全体的なバックアップ時間は長くなります。
リカバリする必要のある特定時点に関わらず、必要なリストア・ジョブの数は同じです。たとえば、火曜日にリカバリを実行する場合、日曜日のフル・バックアップと月曜日の差分バックアップをリストアする必要があります。また、木曜日にリカバリを実行する場合は、日曜日のフル・バックアップに続いて水曜日の差分バックアップをリストアする必要があります。以降の差分バックアップはサイズが大きくなり、時間も長くなりますが、実行する必要のあるリストア・ジョブの数は少なくなるため、リストア時間は短くなります。
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating