多くのユーザーが利用する大規模ECサイトでは、バックアップを取得している間も、注文登録や在庫更新が続きます。
このようなシステムでは、午前0時台にバックアップを取得しても、データベースの状態はその直後から変わっていきます。
たとえば、午後3時にデータファイルが失われたとします。バックアップからデータファイルを書き戻せば、失われたファイル自体は復元できます。しかし、そのバックアップだけでは、取得後に行われた注文登録やステータス変更までは戻りません。
では、午前0時台のバックアップから、障害発生前の状態へどのように進めるのでしょうか。
前回の記事では、バックアップを単なるデータの保管ではなく、必要な状態を再構築するための仕組みとして整理しました。
今回はその一般論をOracle AI Databaseに当てはめ、RMAN、リストア、リカバリ、REDOの関係を見ていきます。
バックアップを置き直しても、時間は進んでいない
Oracle AI Databaseで使われるRMANは、Recovery Managerの略称です。
RMANはOracle AI Databaseのバックアップ、リストア、リカバリを管理するためのツールで、データファイル、制御ファイル、サーバー・パラメータ・ファイル、アーカイブREDOログなどをバックアップできます。
ここで混同しやすいのが、リストアとリカバリです。
どちらも日本語では「戻す」「復旧する」と説明されることがありますが、担当する工程は異なります。
リストアは、バックアップからデータファイルなどのデータベース・ファイルを取り出し、利用できる場所へ書き戻す工程です。本記事では、データファイルのリストアを例に説明します。
午前0時台のバックアップを午後3時にリストアしても、ファイルの中身が自動的に午後3時の状態になるわけではありません。バックアップ取得後に発生した更新を反映するには、その更新履歴を使ったリカバリが必要です。
リストアは、復旧の土台となるデータファイルをバックアップから取り出す工程です。リカバリは、その土台へ変更履歴を適用し、データベースを必要な状態へ進める工程です。
この二つを分けると、「バックアップをリストアしただけでは、なぜ復旧が終わらない場合があるのか」が見えてきます。
注：実際のバックアップには取得時間の幅があるため、図は概念を単純化したもの
REDOは、バックアップの後に起きたことを再現する
データファイルのバックアップには、バックアップ取得後に発生した更新は含まれていません。
そこでリカバリに使われるのがREDOです。
REDOには、データベースへ加えられた変更を再現するための情報が記録されます。
データファイルのバックアップを過去の土台と考えるなら、REDOは、その土台から時間を前へ進めるための更新履歴です。RMANはリカバリを実行するとき、利用可能なアーカイブREDOログや増分バックアップなどを使い、リストアされたデータファイルをロールフォワードします。
たとえば、午前0時台に取得したバックアップと、その後午後3時までに必要となるREDOが利用できれば、バックアップ後の更新を順番に適用できる可能性があります。
反対に、必要なREDOや増分バックアップなど、リカバリに必要な変更情報がそろっていなければ、想定した時点まで進められない場合があります。
つまり、戻せる範囲は「バックアップファイルが存在するか」だけでは決まりません。
- どの時点のバックアップが残っているか
- その後のREDOが必要な範囲で利用できるか
- バックアップや必要なREDOをリカバリ処理から利用できるか
- 暗号化されたデータの場合、必要なキーストアなどを利用できるか
こうした材料と前提がそろって、初めて想定したリカバリを検討できます。
REDOの適用は、ゲームのセーブデータを読み込んだあと、記録された行動を順番に再現して、より新しい状態まで進める作業に似ています。
ゲームに例えると、リストアは過去のセーブデータを読み込む処理に近いものです。午後3時にセーブデータを読み込んでも、キャラクターの状態が自動的に午後3時になるわけではありません。
セーブ後に記録された変更を順番に反映し、必要な地点まで進め直す処理が、REDOを適用するリカバリに相当します。
ただし、実際のREDOに記録されるのは、ゲーム内の行動や業務操作そのものではなく、Oracle Database内部で変更を再現するための情報です。動画を巻き戻すのではなく、過去の状態を起点に変更を前方向へ適用すると考えるほうが正確です。
なお、ここでいう「午前0時台のバックアップから午後3時時点まで進める」は、説明を単純化した例です。どの時点まで進めるか、どこでリカバリを止めるかという判断は、次の記事で改めて扱います。
RMANとOSのファイルコピーは何が違うのか
ここで押さえておきたいのはRMANの特徴を、「専用形式でファイルをコピーすること」だけで説明するのは十分ではないということです。
RMANは、独自形式のバックアップセットだけでなく、データファイルなどをビット単位で複製したイメージコピーも作成できます。そのため、RMANとOSのファイルコピーの違いは、コピーされたファイルの見た目だけでは判断できません。
重要なのは、RMANがOracle AI Databaseの構造を理解して処理することです。
RMANはOracle AI Databaseのデータブロック形式を認識し、バックアップやリストアの際にブロックを検査します。また、どのデータファイルをいつバックアップしたか、どのバックアップセットやイメージコピーが存在するかといったメタデータをRMANリポジトリで管理します。
平たくいうと、「いつ、何を、どこへ、どのような形式でバックアップしたか」を記録する管理台帳のようなものです。
OSのコピー機能などで作成した適切なデータファイル・コピーを、RMANのCATALOGコマンドによってイメージコピーとしてRMANリポジトリへ登録できる場合もあります。
RMANリポジトリの情報は、ターゲット・データベースの制御ファイルに記録されます。構成によっては、独立したリカバリ・カタログにも保持できます。
ただし、カタログへの登録は、そのコピーが適切な手順で作成されたことや、すべてのブロックに破損がないことを保証するものではありません。RMANから参照できることと、実際に復旧へ利用できることは分けて確認する必要があります。
この情報があることで、RMANはバックアップを単なるファイルの集合としてではなく、リストアやリカバリに利用する候補として扱えます。
ただし、OSコピーやストレージスナップショットが一律に復旧へ使えないわけではありません。Oracle AI Databaseの整合性要件を満たし、必要なREDOや管理手順を含めて設計されていれば、復旧手段の一部として利用できる場合があります。
見るべきなのは、専用ツールか汎用ツールかという分類ではなく、次の点です。
Oracle AI Databaseの構造を考慮して取得され、必要な更新履歴と組み合わせて、実際にリカバリできる状態で管理されているか。
RMANは、その工程をOracle AI Database側から管理するための仕組みだと考えると分かりやすくなります。
オンラインバックアップでは、リカバリが前提になる
Oracle AI DatabaseをSHUTDOWN NORMAL、SHUTDOWN IMMEDIATE、またはSHUTDOWN TRANSACTIONALで正常停止すると、すべてのREDOがデータファイルへ適用された一貫性のある状態になります。この状態で取得するバックアップが、一貫性バックアップです。
一貫性バックアップをリストアし、そのバックアップ時点を復旧の終点とする場合、原則としてメディア・リカバリを行わずにデータベースを開けます。ただし、バックアップ取得後に発生したトランザクションは失われます。
一方、データベースを稼働させたまま取得するオンラインバックアップは、一般に非一貫性バックアップです。
「非一貫性」という言葉から、壊れたバックアップのように見えるかもしれません。
しかし、ここでいう非一貫性は、バックアップ中もデータベースが更新されているため、複数のデータファイルやブロックの状態が同じ時点にそろっていないことを意味します。
ARCHIVELOGモードで必要なアーカイブREDOログを保護していれば、リストア後にREDOを適用し、データベースを整合した状態へ進められます。
つまり、稼働中に取得したバックアップでは、リストアとリカバリを組み合わせることが復旧設計の前提になります。
「バックアップジョブが成功した」という結果だけを見るのではなく、リカバリに必要なREDOまで含めて保護できているかを確認する必要があります。
RMANが守るのは、業務再開までのすべてではない
ここまでの説明では、データベースのファイルをリストアし、REDOを適用してリカバリする流れを見てきました。
ただし、RMANによるデータベースのリカバリが完了しても、それだけで業務を再開できるとは限りません。
たとえば、次の確認はRMANの外側に残ります。
- 障害発生時に処理中だった業務要求について、再送や再実行が必要か
- コミット結果をアプリケーションや外部システムから確認できるか
RMANが主に担うのは、Oracle AI Databaseのバックアップ、リストア、リカバリです。アプリケーション、関連システム、運用判断まで含めた業務再開には、別の設計と確認が必要です。
また、RMANではネットワーク構成ファイル、パスワード・ファイル、Oracleホームの内容など、バックアップ対象にできないファイルもあります。データベース以外の構成情報をどのように保護するかも、システム全体の復旧設計では考えなければなりません。
RMANは「バックアップファイルを作るツール」というより、バックアップ、リストア、リカバリという一連の復旧工程を管理するための仕組みです。
一方で、REDOが残っているところまで進められることと、そこまで進めるのが正しいことは同じではありません。
通常のログ対象となる操作であれば、誤操作や不正な更新であっても、データベースに対する変更としてREDOへ記録されます。そのため、最新時点までリカバリすると、障害やデータ不整合の原因となった更新まで再現する可能性があります。
次に考える必要があるのは、「どこまで戻せるか」ではなく、「どの時点へ戻すのが安全なのか」です。
参考資料
- Backup and Recovery User's Guide Release 26
- Backup and Recovery Reference Release 26
- Oracle AI Database MAA Best Practices
免責
本記事は筆者個人の見解であり、所属組織の公式見解ではありません。筆者はOracleに所属していますが、本記事は公開情報をもとに、可用性設計の観点で個人的に整理したものです。製品・サービスの仕様は変更される可能性があるため、最終的な判断は公式ドキュメントをご確認ください。