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

データのバックアップ：概要

バックアップを完了する前に、以下のトピックの情報を確認します。

半角英数字およびアンダースコアを除くその他すべての文字は、特殊文字として扱われます。ハイフンなどの特殊文字を含むデータベースが環境内に存在する場合、以下の制限事項に注意する必要があります。

［MySQL Enterpriseバックアップ］オプションを使用する場合、以下のガイドラインと情報について確認する必要があります。

バックアップ戦略の策定

MySQLバックアップ戦略を定義する際、以下の点を明確にしておきます。

上記の点を明確にしておくと、実装するバックアップ・タイプおよび頻度を定義する際に役立ちます。

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

［MySQL Standard/Community］オプションを使用する場合、本プラグインはmysqldumpを使用して以下のタイプのバックアップを実行します。

各MySQLインスタンスのデータ保護要件に適したバックアップ・シーケンスを選択するには、まずこれらのバックアップの違いを理解する必要があります。

［MySQL Standard/Community］オプション用フル・バックアップの場合、本プラグインはmysqldumpユーティリティを使用して、インスタンスに含まれるすべてのデータベースをバックアップします。フル・バックアップはほぼすべてのリストア・シナリオの起点になるため、あらゆるバックアップ戦略の基盤となります。プラグインで生成されたフル・バックアップを使用して、インスタンス全体、個々または複数のデータベース、個々または複数のテーブルをリストアできます。

［フルまたはインクリメンタル・バックアップ後、バイナリ・ログをパージ］オプションを使用して、フルまたは増分バックアップ後にバイナリ・ログをパージする必要があります。［MySQLレプリケーションを可能にする］が無効化され、［特定時点リカバリを可能にする］が有効化されている標準のMySQLサーバー設定でプラグインを使用する場合、このオプションはデフォルトで有効化されています。プラグインをクラスタに接続すると、このオプションは無効化されます。バイナリ・ログのパージはプラグインの外で管理する必要があります。

重要： NetVault Backupサーバーがクラスタ化されたMySQLサーバーと標準のMySQLサーバー両方を管理するような混合環境では、標準の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テーブルの場合、最後のフルまたは増分バックアップ以降に何かテーブル内で変更された場合、テーブル全体がバックアップされます。