1 |
2 |
デフォルト設定を使用しない場合は、[ジョブ名]に、ジョブの名前を指定します。 |
重要: ターゲットOSのファイル名としてサポートされていない特殊文字を使用しないよう注意してください。たとえば、Windowsでは/、\、*、@などの文字は使用できません。これは、Plug‑in for MySQLがデータを一時的にリストアするために、[ジョブ・タイトル]と同じ名前のフォルダを作成しようとするからです。 |
3 |
[クライアント指定]リストで、データをリストアするマシンを選択します。 |
4 |
5 |
[保存]または[保存 & 実行]の、どちらか適切な方をクリックします。 |
重要: LinuxまたはUNIX環境でMySQL Enterpriseバックアップを使用している場合は、リストアされたデータのファイル所有権および権限情報が、データのバックアップ前と一致していることを確認します。mysqlbackupユーティリティは、バックアップ・プロセス中にこの情報を記録しないため、リストアの完了後に情報が異なっている場合があります。詳細は、「https://docs.oracle.com/cd/E17952_01/mysql-enterprise-backup-3.11-en/bugs.backup.html」を参照してください。 |
障害またはデータ損傷から正しくリカバリするには、ジョブの設定時に、リストア対象として選択するデータおよび[オプション]タブのオプションに関してさまざまな設定を行う必要があります。以降のトピックでは、さまざまなタイプのリカバリ例を示し、必要となるオプションについて説明します。
以下の例で、MySQL管理者は毎晩午後11:00にフル・バックアップを実行するバックアップ・ポリシーを設定しました。
データベース管理者は月曜日の午前9:00に、ユーザーがOrdersテーブルで「table not found(テーブルが見つかりません)」エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の月曜日午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。つまり、データベース管理者は日曜日の夜に実行されたフル・バックアップをリストアし、現在のバイナリ・ログを使用してPITリカバリを実行する必要があります。
1 |
日曜日の夜からのフル・リストアを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。 |
• |
[現在のバイナリ・ログでPITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。 |
• |
[時間に基づくPIT]:リストア・タイプとして選択します。 |
• |
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、誤った/不良のSQLステートメントの後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。
1 |
日曜日の夜からのフル・リストアを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。 |
• |
[現在のバイナリ・ログでPITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。 |
• |
[時間に基づくPIT]:リストア・タイプとして選択します。 |
• |
• |
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]:Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除より後の時刻と日付を[開始日/時間]オプションに入力します。最後に、指定したバイナリ・ログ・ファイルを最後までリカバリするために、[開始日/時間]オプションで[なし]ラジオ・ボタンを選択しました。 |
データベース管理者は月曜日の午前9:00に、ユーザーがOrdersテーブルで「table not found(テーブルが見つかりません)」エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の月曜日午前6:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は日曜日のフル・バックアップをリストアし、現在のバイナリ・ログを使用してPITリカバリを実行する必要があります。
1 |
[リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する]:リストアしないdrop table SQLステートメントの位置を特定するために、この手順をNetVault Backupの外で実行します(この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください)。この処理で、データベース管理者はdrop tableステートメントがMYSQLSVR-bin.000009バイナリ・ログの805の位置にあることを特定しました。 |
2 |
日曜日の夜からのフル・リストアを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
3 |
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。 |
• |
[現在のバイナリ・ログでPITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。 |
• |
[位置に基づくPIT]:リストア・タイプとして選択します。 |
• |
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[停止位置]を「804」(mysqlbinlogで特定した位置の前の位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを[OTHER FILE]に設定し、ターゲット・バイナリ・ファイルの名前(MYSQLSVR-bin.000009など)をテキスト・ボックスに入力しました。 |
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、Ordersテーブルが削除された時点の後の特定時点から現在のバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。これにより、削除されたテーブルに加え、可能な限り多くのトランザクションをリカバリすることができます。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は日曜日のフル・バックアップをリストアし、現在のバイナリ・ログを使用してPITリカバリを実行する必要があります。
1 |
[リストアされたバイナリ・ログに対してmysqlbinlogユーティリティを使用する]:リストアしないdrop table SQLステートメントの位置を特定するために、この手順をNetVault Backupの外で実行します(この処理の手順およびこのユーティリティの使用方法については、『MySQLリファレンス・マニュアル』を参照してください)。この処理で、データベース管理者はdrop tableステートメントがMYSQLSVR-PM-bin.000009バイナリ・ログの805の位置にあることを特定しました。 |
2 |
日曜日の夜からのフル・リストアを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
3 |
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。 |
• |
[現在のバイナリ・ログでPITリカバリを実行する]:このオプションを選択し、このリストア形式と、関連するすべてのオプションを有効にします。 |
• |
[位置に基づくPIT]:リストア・タイプとして選択します。 |
• |
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[停止位置]を「804」(mysqlbinlogで特定した位置の前の位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを[OTHER FILE]に設定し、ターゲット・バイナリ・ファイルの名前(MYSQLSVR-PM-bin.000009など)をテキスト・ボックスに入力しました。 |
• |
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]:このオプションを選択し、[開始位置]を「806」(mysqlbinlogで特定した位置の後の位置)に設定します。[開始位置を含むバイナリ・ログ]ドロップダウンを[OTHER FILE]に設定し、ターゲット・バイナリ・ファイルの名前(MYSQLSVR-bin.000009など)をテキスト・ボックスに入力しました。最後に、指定したバイナリ・ログ・ファイルを最後までリカバリするために、[停止位置]オプションで[なし]ラジオ・ボタンを選択しました。 |
DBAはフル・バックアップを毎週日曜日の午後11時に、増分バックアップを月~土曜の午後11時に実行するバックアップ・ポリシーを作成しました。DBAは増分バックアップを実行しているため、各増分バックアップの実行後バイナリ・ログは削除されます。このプロセスにより、全体的なバックアップ時間は短くなりますが、リストアにはより多くの時間と手順が必要になります。
データベース管理者は木曜日の午前9:00に、ユーザーがOrdersテーブルで「table not found(テーブルが見つかりません)」エラーに遭遇しているという通知を受けました。調査の結果、データベース管理者の出勤前の木曜日午前に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、最後の増分バックアップ、つまり水曜日の夜に実行されたバックアップの時点までを完全にリカバリすることを決定しました。
1 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
[水曜日の夜からの増分バックアップを選択する]:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
以降の例では、フル/増分バックアップ・シナリオを取り上げます。データベース管理者はデータを特定時点にリカバリしようと考えています。
データベース管理者は木曜日の午前9:00に、ユーザーがOrdersテーブルで「table not found(テーブルが見つかりません)」エラーに遭遇しているという通知を受けました。調査の結果、水曜日の午後8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が水曜日の午後8:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。このことから、以下の手順を実行します。
1 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
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 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
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 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
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 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
[水曜日の夜からの増分バックアップを選択する]:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。 |
• |
[PITリカバリを実行する]:このオプションを選択してPITリカバリを指定し、関連するすべてのオプションを有効にします。 |
• |
[バイナリ・ログをリストアし適用する(時間あるいは位置が、既に判明している場合、使用される)]:このオプションを選択し、バックアップに含まれているバイナリ・ログを使用するよう指定します。 |
• |
[現在のバイナリ・ログを含む]:水曜日にバックアップが完了してからDrop Tableコマンドを発行するまでの間に発生したエントリを適用するために、このオプションを有効にします。 |
• |
[時間に基づくPIT]:リストア・タイプとして選択します。 |
• |
[誤った/不良のSQLステートメントの前に、リカバリを可能にする]:このオプションを選択し、[中止日/時間]を「5:59」、「2007年1月11日」(月曜日の日付の午前6:00の1分前)に設定します。 |
• |
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]:Orderテーブルの削除後に実行されたトランザクションをリカバリするために、このオプションを選択し、削除より後の時刻と日付を[開始日/時間]オプションに入力します。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、[中止日/時間]オプションで[なし]オプションを選択しました。 |
データベース管理者は木曜日の午前9:00に、ユーザーがOrdersテーブルで「table not found(テーブルが見つかりません)」エラーに遭遇しているという通知を受けました。調査の結果、水曜日の午後8:00に開発者が無意識のうちにOrdersテーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、drop tableコマンドが実行される直前の特定時点までをリカバリすることを決定しました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。
1 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
[水曜日の夜からの増分バックアップを選択する]:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。 |
• |
[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テーブルが削除された時点の後の特定時点からバックアップされたバイナリ・ログの最後まで、残りのテーブルに実行されたトランザクションをリカバリしようと考えました。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。
1 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
[水曜日の夜からの増分バックアップを選択する]:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、水曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
リストア関連の[オプション]タブのオプション設定:データベース管理者は以下のオプションを選択します。 |
• |
[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にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。
1 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
[リストアされたバイナリ・ログに対して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テーブルを削除したために、このテーブルが存在しなくなっていることが判明しました。
データベース管理者は、開発者が木曜日の午前6:00にテーブルを削除した直前の特定時点までデータベースをリストアするようリカバリを実行する必要があります。また、開発者がテーブルを削除した時刻の推定以上に正確なリカバリを実行することを決定しました。このことから、データベース管理者は位置に基づくリカバリを使用することにしました。このプロセスを行うには、データベース管理者は、日曜日のフル・バックアップと、月曜日および火曜日に実行された増分バックアップをリストアしてから、水曜日に実行された増分バックアップを使用して位置に基づくPITリカバリを実行する必要があります。以下にこのプロセスを示します。
1 |
日曜日の夜からのフル・バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、日曜日の夜に実行されたフル・バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
月曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、月曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
1 |
火曜日の夜からの増分バックアップを選択する:データベース管理者は[リストア・ジョブ作成 - セーブセットの選択]ページで、火曜日の夜に実行された増分バックアップに対応するバックアップ・セーブセットを選択します。 |
2 |
すべてのリストア関連オプションをデフォルトのままにする:どのオプションも使用しません。 |
[リストアされたバイナリ・ログに対して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など)をテキスト・ボックスに入力しました。 |
• |
[誤った/不良のSQLステートメントの後に、リカバリを可能にする]:このオプションを選択し、[開始位置]を「806」(現在のバイナリ・ログの、mysqlbinlogで特定したDrop Tableコマンドの位置の後にある位置)に設定します。[終了位置を含むバイナリ・ログ]ドロップダウンを[OTHER FILE]に設定し、現在のバイナリ・ファイルの名前(MYSQLSVR-bin.000009など)をテキスト・ボックスに入力しました。最後に、現在のバイナリ・ログ・ファイルを最後までリカバリするために、[停止位置]オプションで[なし]ラジオ・ボタンを選択しました。 |
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback 使用条款 隐私 Cookie Preference Center