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

ジョブのファイナライズと実行

最終ステップには、［スケジュール］、［ソース・オプション］、および［詳細設定］ページの追加オプション設定、ジョブの実行、および［ジョブ・ステータス］と［ログ参照］ページからの進捗状況の監視が含まれています。これらのページとオプションは、すべてのNetVault Backupプラグインに共通しています。詳しくは、『QuestNetVault Backupアドミニストレーターズ・ガイド』を参照してください。

重要： ターゲットOSのファイル名としてサポートされていない特殊文字を使用しないよう注意してください。たとえば、Windowsでは/、\、*、@などの文字は使用できません。これは、Plug‑in for MySQLがデータを一時的にリストアするために、［ジョブ・タイトル］と同じ名前のフォルダを作成しようとするからです。

ヒント： ［選択］をクリックして、［クライアント指定選択］ダイアログ・ボックスから適切なクライアントを検索、選択することもできます。

重要： MySQL EnterpriseバックアップをLinuxまたはUNIX環境で使用している場合は、リストアしたデータのファイル所有権とパーミッション情報がデータをバックアップする前の状態と一致しているか確認します。Mysqlbackupユーティリティは、バックアップ・プロセス中、データのファイル所有権とパーミッション情報については記録しないため、リストアが完了した後、これらの情報が異なる場合があります。詳しくは、https://docs.oracle.com/cd/E17952_01/mysql-enterprise-backup-3.11-en/bugs.backup.htmlを参照してください。

MySQL Standard/Community用リストア・シナリオ例

障害またはデータ損傷から正しくリカバリするには、ジョブの設定時に、リストア対象として選択するデータおよび［オプション］タブのオプションに関してさまざまな設定を行う必要があります。以降のトピックでは、さまざまなタイプのリカバリ例を示し、必要となるオプションについて説明します。

フル・バックアップのみによるリストア・シナリオ

以下の例で、MySQL管理者は毎晩午後11：00にフル･バックアップを実行するバックアップ・ポリシーを設定しました。

データベース管理者は月曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の月曜日午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。つまり、データベース管理者は日曜日の夜に実行されたフル・バックアップをリストアし、現在のバイナリ・ログを使用してPITリカバリを実行する必要があります。

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、誤った/不良のSQLステートメントの後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。

データベース管理者は月曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の月曜日午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は日曜日のフル・バックアップをリストアし、現在のバイナリ・ログを使用してPITリカバリを実行する必要があります。

重要： 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は日曜日のフル・バックアップをリストアし、現在のバイナリ・ログを使用してPITリカバリを実行する必要があります。

重要： 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。

フルおよび増分バックアップによるリストア・シナリオ

DBAはフル・バックアップを毎週日曜日の午後11時に、増分バックアップを月～土曜の午後11時に実行するバックアップ・ポリシーを作成しました。DBAは増分バックアップを実行しているため、各増分バックアップの実行後バイナリ・ログは削除されます。このプロセスにより、全体的なバックアップ時間は短くなりますが、リストアにはより多くの時間と手順が必要になります。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の木曜日午前に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、最後の増分バックアップ、つまり水曜日の夜に実行されたバックアップの時点までを完全にリカバリすることを決定しました。

以降の例では、フル/増分バックアップ・シナリオを取り上げます。データベース管理者はデータを特定時点にリカバリしようと考えています。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、水曜日の午後8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、開発者が水曜日の午後8:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、水曜日の午後8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、午後8:00にDrop Tableコマンドが実行された直前の特定時点までリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点からバックアップされたバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。このことから、以下の手順を実行します。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、開発者が木曜日の午前6:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。このことから、以下の手順を実行します。

以降の例では、フル/増分バックアップ・シナリオを取り上げます。データベース管理者は、より確実な方法で時刻を特定し、データを特定時点にリカバリしようと考えています。このリカバリは、MySQLバイナリ・ログ・ファイル内で特定した位置の値を使用して行います。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、水曜日の午後8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。

この手順では、水曜日の夜の増分バックアップに記録されたバイナリ・ログについてテンポラリ・ロケーションへのリストアのみを実行します。このプロセスにより、データベース管理者はログで、Ordersテーブルが削除された時のマークが付けられた位置を見つけることができます。

［リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する］：リストアしないdrop table SQLステートメントの位置を特定するために、この手順をNetVault Backupの外で実行します（この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください）。この処理で、データベース管理者は、drop tableステートメントが、MySQLサーバーのテンポラリ・ロケーションにリストアされたMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました（また、これらの両方の値をメモしました）。

リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、水曜日の午後8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点からバックアップされたバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。

この手順では、水曜日の夜の増分バックアップに記録されたバイナリ・ログについてテンポラリ・ロケーションへのリストアのみを実行します。この手順により、データベース管理者はログで、Ordersテーブルが削除された時のマークが付けられた位置を見つけることができます。

［リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する］：リストアしないdrop table SQLステートメントの位置を特定するために、この手順をNetVault Backupの外で実行します（この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください）。この処理で、データベース管理者は、drop tableステートメントが、MySQLサーバーのテンポラリ・ロケーションにリストアされたMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました（また、これらの両方の値をメモしました）。

リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。

重要： 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、開発者が木曜日の午前6:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。

［リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する］：リストアしないdrop table SQLステートメントの位置を特定するために、この手順をNetVault Backupの外で実行します（この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください）。この処理で、データベース管理者はdrop tableコマンドが現在のバイナリ・ログMYSQLSVR-bin.000009の805の位置にあることを特定しました。

リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。

データベース管理者は木曜日の午前9：00に、ユーザーがOrdersテーブルで「table not found（テーブルが見つかりません）」エラーに遭遇しているという通知を受けました。調査の結果、木曜日の午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。

データベース管理者は、開発者が木曜日の午前6:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。

［リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する］：リストアしないdrop table SQLステートメントの位置を特定するために、この手順をNetVault Backupの外で実行します（この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください）。この処理で、データベース管理者はdrop tableコマンドが現在のバイナリ・ログMYSQLSVR-bin.000009の805の位置にあることを特定しました。

リストアされたバイナリ・ログで特定した位置をもとに、水曜日に実行された増分バックアップを使用してPITリストアを実行します。

重要： 停止位置と開始位置には、不要なトランザクションの位置より大きい任意の数値ではなく、バイナリ・ログ・ファイルに記録されている実際の位置を指定してください。