Tchater maintenant avec le support
Tchattez avec un ingénieur du support

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

NetVault Backup Plug-in for MySQL - はじめに プラグインのインストールと削除 プラグインの設定 データのバックアップ データのリストア
データのリストア:概要 MySQLにおけるデータのリストア 高度なMySQL Standard/Community用リストア手順
MySQLレプリケーションの使用 フェイルオーバー・クラスタ環境でのプラグインの使用 トラブルシューティング

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

DBAはフル・バックアップを毎週日曜日の午後11時に、差分バックアップ月~土曜の午後11時に実行するバックアップ・ポリシーを作成しました。差分バックアップを実行しているため、この形式のバックアップを実行するたびにバイナリ・ファイルが保存されます。この場合、バックアップ時間は長くなりますが、全体的なリストア時間は短くなります。

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
1
水曜日の夜からの差分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
2
すべてのリストア関連オプションをデフォルトのままにする[オプション]タブのどのオプションも使用しません
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。

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

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
1
水曜日の夜からの差分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にします。
[バイナリ・ログをリストアし適用する(時間あるいは位置が、既に判明している場合、使用される)]:このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定します。
[時間に基づくPIT]:リストア・タイプとして選択します。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[中止日/時間]を「19:59」、「2007年1月10日」(水曜日の日付の午後8:00の1分前)に設定します。

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
1
水曜日の夜からの差分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にします。
[バイナリ・ログをリストアし適用する(時間あるいは位置が、既に判明している場合、使用される)]:このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定します。
[時間に基づくPIT]:リストア・タイプとして選択します。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[中止日/時間]を「19:59」、「2007年1月10日」(水曜日の日付の午後8:00の1分前)に設定します。
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除よりの時刻と日付を[開始日/時間]オプションに入力します。最後に、リストアしたバイナリ・ログ・ファイルを最後までリカバリするために、[開始日/時間]オプションで[なし]ラジオ・ボタンを選択しました。

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
1
水曜日の夜からの差分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にします。
[バイナリ・ログをリストアし適用する(時間あるいは位置が、既に判明している場合、使用される)]:このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定します。
[現在のバイナリ・ログを含む]:水曜日にバックアップが完了してからDrop Tableコマンドを発行するまでの間に発生したエントリを適用するために、このオプションを有効にします。
[時間に基づくPIT]:リストア・タイプとして選択します。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[中止日/時間]を「5:59」、「2007年1月11日」(月曜日の日付の午前6:00の1分前)に設定します。

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。
1
水曜日の夜からの差分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にします。
[バイナリ・ログをリストアし適用する(時間あるいは位置が、既に判明している場合、使用される)]:このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定します。
[現在のバイナリ・ログを含む]:水曜日にバックアップが完了してからDrop Tableコマンドを発行するまでの間に発生したエントリを適用するために、このオプションを有効にします。
[時間に基づくPIT]:リストア・タイプとして選択します。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[中止日/時間]を「5:59」、「2007年1月11日」(月曜日の日付の午前6:00の1分前)に設定します。
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除よりの時刻と日付を[開始日/時間]オプションに入力します。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、[中止日/時間]オプションで[なし]オプションを選択しました。

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

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

データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。以下にこのプロセスを示します。

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。

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

1
水曜日の夜からの差分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。
[テンポラリ・ディレクトリへのログをリストアし、時間あるいは位置を特定する]:このオプションを選択し、水曜日の夜の差分バックアップに含まれるバイナリ・ログ・ファイルについてリストアのみを実行するよう指定します。
[時間に基づくPIT]:タイプとして選択します。ただし、[時間に基づくPITの詳細]セクションのその他すべてのオプションは選択解除したままにします。

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

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

1
水曜日の夜からの差分バックアップを選択する:データベース管理者は再度[リストア・ジョブ作成 - セーブセットの選択]タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。
[テンポラリ・ディレクトリからのバイナリ・ログを適用する]:一連の操作の最後の手順で、テンポラリ・ロケーションにリストアしたバイナリ・ログをターゲットにするために、このオプションを選択します。リストアしたバイナリ・ログ・ファイルでDrop Tableコマンドが記録されている位置を特定したため、これと同じバイナリ・ログ・ファイルがプラグインで使用されるようにこのオプションを選択します。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[停止位置]を「804」(バイナリ・ログの、mysqlbinlogで特定したDrop Tableコマンドの位置のにある位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル(MYSQLSVR-bin.000009)を選択しました。

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。

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

1
水曜日の夜からの差分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。
[テンポラリ・ディレクトリへのログをリストアし、時間あるいは位置を特定する]:このオプションを選択し、水曜日の夜の差分バックアップに含まれるバイナリ・ログ・ファイルについてリストアのみを実行するよう指定します。
[時間に基づくPIT]:タイプとして選択します。ただし、[時間に基づくPITの詳細]セクションのその他すべてのオプションは選択解除したままにします。

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

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

1
水曜日の夜からの差分バックアップを選択する:データベース管理者は再度[リストア・ジョブ作成 - セーブセットの選択]タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。
[テンポラリ・ディレクトリからのバイナリ・ログを適用する]:一連の操作の最後の手順で、テンポラリ・ロケーションにリストアしたバイナリ・ログをターゲットにするために、このオプションを選択します。リストアしたバイナリ・ログ・ファイルでDrop Tableコマンドが記録されている位置を特定したため、これと同じバイナリ・ログ・ファイルがプラグインで使用されるようにこのオプションを選択します。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[停止位置]を「804」(バイナリ・ログの、mysqlbinlogで特定したDrop Tableコマンドの位置のにある位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル(MYSQLSVR-bin.000009)を選択しました。
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]:このオプションを選択し、[開始位置]を「806」(バイナリ・ログの、mysqlbinlogで特定したDrop Tableコマンドの位置のにある位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを使用して、テンポラリ・ディレクトリにリストアしたバイナリ・ログ・ファイル(MYSQLSVR-bin.000009)を選択しました。最後に、指定したバイナリ・ログ・ファイルを最後までリカバリするために、[停止位置]オプションで[なし]ラジオ・ボタンを選択しました。

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。

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

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

1
水曜日の夜からの差分バックアップを選択する:データベース管理者は再度[リストア・ジョブ作成 - セーブセットの選択]タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日の夜のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。
[バイナリ・ログをリストアし適用する(時間あるいは位置が、既に判明している場合、使用される)]:このオプションを選択し、バックアップに含まれていたバイナリ・ログ・ファイルをプラグインで使用するよう指定します。
[現在のバイナリ・ログを含む]:このオプションを選択し、NetVault Backupで現在のバイナリ・ログを使用し、水曜日の夜の差分バックアップのに実行されたすべてのデータベース・トランザクションを適用するよう指定します。この手順により、水曜日の夜に差分バックアップが完了してからdrop tableコマンドが発行されるまでの間に実行されたすべてのトランザクションがリカバリされます。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[停止位置]804(現在のバイナリ・ログの、mysqlbinlogで特定したDrop Tableコマンドの位置のにある位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを[OTHER FILE]に設定し、現在のバイナリ・ファイルの名前(MYSQLSVR-bin.000009など)をテキスト・ボックスに入力しました。

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

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

1
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。

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

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

1
水曜日の夜からの差分バックアップを選択する:データベース管理者は再度[リストア・ジョブ作成 - セーブセットの選択]タブで、水曜日の夜に実行された差分バックアップに対応するバックアップ・セーブセットを選択します。
重要: データベース管理者は月曜日および火曜日の夜の差分バックアップをリストアする必要がありません。差分バックアップを実行するよう選択すると、毎晩のバックアップに日曜日のフル・バックアップ以降のバックアップが累積されます。つまり、水曜日の夜のバックアップには、日曜日のフル・バックアップ以降に生成された月曜日、火曜日、および水曜日のすべてのバイナリ・ログが含まれます。
2
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。
[PITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。
[バイナリ・ログをリストアし適用する(時間あるいは位置が、既に判明している場合、使用される)]:このオプションを選択し、バックアップに含まれていたバイナリ・ログ・ファイルをプラグインで使用するよう指定します。
[現在のバイナリ・ログを含む]:このオプションを選択し、NetVault Backupで現在のバイナリ・ログを使用し、水曜日の夜の差分バックアップのに実行されたすべてのデータベース・トランザクションを適用するよう指定します。この手順により、水曜日の夜に差分バックアップが完了してからdrop tableコマンドが発行されるまでの間に実行されたすべてのトランザクションがリカバリされます。
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[停止位置]804(現在のバイナリ・ログの、mysqlbinlogで特定したDrop Tableコマンドの位置のにある位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを[OTHER FILE]に設定し、現在のバイナリ・ファイルの名前(MYSQLSVR-bin.000009など)をテキスト・ボックスに入力しました。
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]:このオプションを選択し、[開始位置]を「806」(現在のバイナリ・ログの、mysqlbinlogで特定したDrop Tableコマンドの位置のにある位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを[OTHER FILE]に設定し、現在のバイナリ・ファイルの名前(MYSQLSVR-bin.000009など)をテキスト・ボックスに入力しました。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、[停止位置]オプションで[なし]ラジオ・ボタンを選択しました。

MIXEDバイナリ・ログ形式が使用され、クロスデータベースの更新が発行された場合のPITリストア

MIXEDバイナリ・ログ形式が使用され、クロスデータベースの更新が発行された場合のPITリストア
重要: サイトにMIXEDバイナリ・ログ形式を使用していて、すべてのデータベース・ユーザーとプログラムがベストプラクティスに従い、変更されたテーブルが確実にUSEによって選択されたデータベース内にあり、かつクロスデータベースの更新が実行されない場合、このトピックはそのサイトに適用されません。(詳しくは、「MIXEDバイナリ・ログ形式の使用」を参照してください。)PITリストア・ジョブを実行すると、バイナリ・ログがジョブで選択されたデータベースの指定されたポイントに再生されます。

前述のように、環境内のユーザーとプログラムが、USEによって選択されていないデータベース内のテーブルを変更し、クロスデータベースの更新を実行する場合、PITリストア・ジョブを実行したときに、指定の時間にトランザクションが再生されないことがあります。Questでは、すべてのデータベース・ユーザーとプログラムで変更されたテーブルがUSEによって選択されたデータベース内に存在すること、およびクロスデータベースの更新が実行されないことを確認することをお勧めします。このガイドラインがご使用の環境に適していない場合は、Questでは、MIXEDバイナリ・ログ形式を使用しないことをお勧めします。

重要: 次の手順では、--databaseオプションを指定せずにmysqlbinlogを使用します。したがって、バイナリ・ログのすべての内容が適用され、すべてのデータベースが変更される可能性があります。この手順を異なるMySQLサーバーに適用し、異なるMySQLサーバーから適切なデータを抽出することを検討してください。次の手順をプロダクションMySQLサーバーに適用すると、すべてのデータベースが指定したポイントにロールバックされます。すべてのMySQLサーバー・データベースを指定したポイントにロールバックする予定がない限り、プロダクション環境にこの手順を適用しないでください。
1
[ナビゲーション]パネルで、[リストア・ジョブ作成]をクリックします。
2
[リストア・ジョブ作成 - セーブセットの選択]ページで[テーブル・フィルタリング]をクリックし、[フィルタの編集]を選択します。
3
[プラグイン・タイプ]リストから[Plug‑in for MySQLを選択します。
5
[セレクション・セット作成]ページで、[バイナリ・ログ]を選択します。
6
[セレクション・セット作成]ページで、[プラグイン・オプションの編集]をクリックします。
7
[リカバリ時]タブで、[PITリカバリを実行する]および[テンポラリ・ディレクトリへのログをリストアし、時間あるいは位置を特定する]オプションを選択します。
8
mysqlbinlogコマンド・プロンプトからバイナリ・ログを手動で適用するには、次のように入力します。
"<NetVaultBackupInstallationDirectory>/tmp/mysql/<savesetName>" |
異なる増分バックアップ・セーブセットが、<NetVaultBackupInstallationDirectory>/tmp/mysqlディレクトリ内の異なるサブディレクトリにリストアされます。その後、mysqlbinlogコマンドを各ディレクトリに適用するか、すべてのバイナリ・ログを共通のディレクトリにコピーまたは移動してmysqlbinlogを実行できます。

MySQL Enterpriseバックアップ用リストア・シナリオ例

障害またはデータ損傷からリカバリするには、ジョブの設定時に、リストア対象として選択するデータおよび[オプション]タブのオプションに関してさまざまな設定を行う必要があります。

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

1
リストアする準備済みフル・バックアップを生成するには、[オプション]タブで選択した[Rawフル・バックアップをリストア、抽出し、ログを適用してTempディレクトリ内に準備済みフル・バックアップを生成]オプションを選択したジョブを実行します。
2
MySQLをシャットダウンし、MySQLサーバー・リポジトリに準備済みバックアップをコピーするには、[オプション]タブで選択した[MySQLサーバーをシャットダウンし、準備済みフル・バックアップをMySQLサーバー・リポジトリへコピー・バック]オプションを選択したジョブを実行します。
Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation