基本情報のデータベース障害回復をUNDO・REDOと時系列の例で理解する

基本情報のデータベース障害回復は、まずディスク上のデータを使えるか、次に障害時点で更新がコミット済みかを確認すると整理できます。未確定の変更を取り消すのがロールバック、ログから必要な変更を再反映するのがロールフォワードです。媒体が壊れた場合は、バックアップからの復元も必要になります。

「バックは戻る、フォワードは進む」とだけ覚えると、チェックポイントをまたぐ図で迷いやすいですよね。この記事では、自作の在庫更新の例を使い、データ本体・ログ・バックアップの役割と、残すべき更新・取り消すべき更新を時系列で確認します。実製品の復旧コマンドの手順ではなく、試験問題の条件を読むための解説です。

基本情報のデータベース障害回復の仕組み

何が失われたかを先に確かめる

トランザクション障害は、一まとまりの処理が途中で正常に完了できない場合です。例えば、二つの商品を同時に引き当てる処理で、一方だけ更新した後にエラーになったとします。一連の処理を成立させないなら、片方だけを更新した中途半端な結果を残さず、必要な変更を取り消すことになります。

システム障害は、電源断などでシステムの処理が中断する場合です。メモリ上の情報が失われても、データを置く媒体や必要なログが無事なら、それらを使って整合する状態へ回復することを考えます。電源を入れ直せば、処理途中の状態も必ず正しくなるという意味ではありません。

媒体障害では、データを格納していたディスクなどが壊れ、必要な内容を読めない場合があります。その場合、無事なデータ本体を前提にするシステム障害の説明だけでは不十分です。正常なバックアップを復元し、その後の必要な更新をログから反映する、といった出発点の違いがあります。

これらの分類は、高知工科大学のデータベースシステムの講義資料でも確認できます。問題を読むときは、障害という単語だけで回復方法を決めず、メモリと媒体のどちらが使えるのか、バックアップやログが残っているのかを確認しましょう。

データ本体とログは役割が違う

データ本体は、商品や在庫など現在の情報を格納するものです。ログは、どの更新を行ったかなど、回復に必要な情報を記録するものです。バックアップは、回復の基準として利用するために保存したデータの写しです。いずれもファイルになる場合はありますが、役割は同じではありません。

DBMSは性能のため、更新をメモリ上のバッファへ保持し、後でデータファイルへ書く場合があります。そのため、アプリケーションの処理が進んだことと、変更したすべてのデータページが直ちに媒体へ書かれたことは、同じ意味ではありません。ログを利用する回復が必要になる理由の一つです。

例えば在庫100を90へ変えるなら、取り消すには元の100へ戻せる情報が必要です。一方、確定した変更をデータ本体へ再反映するには、90に更新したことを再現できる情報が必要になります。試験では、更新前ログと更新後ログという形で役割が示されることがあります。

実際のログは必ずしも単純な二つの数値だけではありません。対象を識別する情報、処理の状態、回復用の制御情報などを含み、形式は製品や方式で異なります。「ログには完成したデータベース全体が毎回入る」「ログがあればどのバックアップも不要」とは考えないようにしましょう。

UNDOとREDOで向きを分ける

UNDOは、行った変更を取り消す方向の処理です。基本情報の典型的な説明では、未コミットのトランザクションが残した更新を、更新前の情報を使って取り消すロールバックと結び付けます。商品Xの在庫を100から90へ変えたものの処理が成立しなかったなら、元の100を保つために取り消します。

REDOは、変更を再び反映する方向の処理です。コミットした更新がデータ本体へ必要な形で反映されていない場合、ログから再現することが回復に役立ちます。商品Xの在庫を90にした処理が確定しているなら、障害後に100のまま失われないよう、確定した結果を残す必要があります。

注意したいのは、どちらも「もう一度アプリケーションから同じ注文を送る」という意味ではないことです。DBMSが管理するログの回復処理と、利用者が同じ業務要求を再送することは別です。注文を無条件に再送すると、回復とは別の二重処理を発生させる可能性があります。

また、実装上のREDOが、必ずコミット済みの業務更新だけを個別に選んで実行されるとは限りません。MySQLのInnoDBでは、REDOログの適用後に未完了のトランザクションをロールバックする流れが説明されています。MySQL公式の回復処理のような実装と、試験の簡略化された図の前提を分けて理解しましょう。

ログを先に残す意味を考える

データ本体だけを先に書き換え、その後で必要なログを残そうとしたとします。二つの操作の間で障害が起きると、変更済みのデータはあるのに、元へ戻す・再現するための情報が不足するかもしれません。そこで、回復に必要な記録を適切な順で永続化することが重要になります。

WALはWrite-Ahead Loggingの略で、データファイルへ変更を書き込む前に、その変更を記述するログを永続的な記憶へ書くという考え方です。PostgreSQLの公式文書でも、この順序と、ログから変更を再現できるためコミットごとにすべてのデータページを書き出す必要がないことが説明されています。

ここで「ログをメモリへ置いた」ことと「障害後も使えるよう永続化した」ことを区別します。同じ電源断で消える記憶にだけログを残しても、障害回復の根拠として十分とは限りません。実際の耐久性は設定や記憶装置などにも関わるため、製品名だけで保証される話ではありません。

学習では、WALを細かい製品コマンドの暗記へ広げず、先に回復用の記録を確保してからデータを反映する順序として押さえれば理解が進みます。一次情報はPostgreSQLのWAL解説を参照できます。ACIDやコミット自体があいまいなら、基本情報のトランザクション処理で先に整理できます。

チェックポイントは回復の手掛かり

チェックポイントは、障害回復の際に、どこから必要なログを調べたり再適用したりするかを判断するための節目です。基本的な試験図では、データの反映と同期を取る基準として説明され、そこより前に確定済みの更新が反映されているという条件が置かれることがあります。

ただし、チェックポイントという語だけで、すべての実製品の全処理がいったん終了するとは判断できません。実行中のトランザクションを持ちながら処理する方式などがあるためです。「チェックポイントがあるから、そこをまたいだ処理は存在しない」と決め付けると、問題文の時系列を読み違えます。

特に、トランザクションの開始がチェックポイントより前でも、コミットが後なら、障害前に確定した更新をどう反映するかを確認する必要があります。反対に、前から実行していても障害時点までにコミットしていなければ、確定済みとして残してはいけません。開始位置だけで分類しないことが重要です。

バックアップもチェックポイントも「ある時点」と関係しますが、用途は違います。チェックポイントを見つけたことだけで、壊れた媒体の代わりとなるデータの写しが手に入るわけではありません。媒体を読めない場合は、どのバックアップから復元できるかという別の確認が必要です。

基本情報のデータベース障害回復を例題で解く

在庫の更新を時系列で追う

ここからは仕組みを確認するための自作例です。9時の基準点で、商品Xの在庫100、商品Yの在庫50が媒体へ反映済みで、実行中のトランザクションはなかったとします。必要な更新前後のログとコミットの記録は、障害後も読み取れる条件です。二つの商品への更新は独立し、別のデータページに記録されるものとします。

T1は9時2分にXを100から90へ変え、9時3分にコミットしました。T2は9時4分にYを50から45へ変えましたが、コミットする前の9時5分に電源断が起きました。バッファと媒体への書込みのタイミングにより、障害時点のデータファイルではXが100、Yが45だったとします。

時点	T1と商品X	T2と商品Y
9時の基準点	Xは100で反映済み	Yは50で反映済み
9時2分	100から90へ更新	まだ更新なし
9時3分	コミット済み	まだ更新なし
9時4分	確定した90を残したい	50から45へ更新し未コミット
9時5分の電源断	媒体では100だった	媒体では45だった
回復後に残す値	90	50

T1はコミット済みなので、媒体のXが100のままなら、ログから確定した変更を反映して90にします。T2は未コミットで、その変更が媒体へ出ている条件なので、更新前の情報に従ってYを50へ戻します。回復後はXが90、Yが50です。両方を元へ戻す、両方を更新後の値へする、のどちらでもありません。

この例は、コミット済みでもすべてのページがすぐ書かれるとは限らず、未コミットの変更も方式によっては媒体へ書かれる、という条件を目に見える値にしたものです。すべてのDBMSが必ずこの状態になるという主張ではありません。問題文が別の書込み方式を指定したら、その条件に従います。

開始時刻だけで分類しない

次は、10時にチェックポイント、14時にシステム障害がある自作図を、表で表したものです。ここでは、チェックポイント以前にコミットした更新は媒体へ反映済みで、その後にコミットした更新は必要に応じてログから再反映する、という簡略化された問題の条件を使います。更新のない読取り専用処理や、特殊な準備状態は含めません。

処理	開始	コミット	この問題での判断
A	8時	9時	チェックポイント以前に確定・反映済み
B	9時	11時	確定した更新を必要に応じて再反映
C	11時	13時	確定した更新を必要に応じて再反映
D	9時	障害時までなし	未確定の変更を残さない
E	12時	障害時までなし	未確定の変更を残さない

BとDはどちらもチェックポイントより前に始まっていますが、結論は違います。Bは11時にコミットしているので確定した更新を守ります。Dは14時までコミットしていないので、未確定の変更を取り消す側です。開始時刻だけを見て二つを同じ組へ分類しないようにしましょう。

また、Dのように基準点より前から実行している処理がある場合、その取消しに必要な情報は、基準点以前の記録にも関係し得ます。「チェックポイントより古いログは、理由を確認せず全部消してよい」という結論にはなりません。実際のログ管理はDBMSの方式に従い、試験では提示された状態と回復対象を読みます。

表を解く順番は、まず障害時点のコミット有無、次に基準点との位置関係です。Aは確定済みで、さらに反映済みという条件があります。BとCは確定済みですが反映を確認する側、DとEは未確定を残さない側です。何も処理しない・再反映・取消しの理由を、一行ずつ言い直すと取り違えを見つけられます。

媒体障害は復元から始める

ディスクが壊れ、商品データ本体を読めなくなった場合を考えます。正常なフルバックアップと、その取得時点から回復したい時点までの必要なログが、別の無事な場所にあるものとします。新しい媒体などへバックアップをリストアし、その後の更新をログから反映するのが基本的な考え方です。

例えばバックアップ時点のXが100で、その後に確定した更新として90、さらに95への変更があったとします。バックアップを戻すだけでは100です。更新の意味と順序に従って必要なログを反映し、回復対象時点の95を再現します。バックアップとログは代替ではなく、基準のデータとその後の差を補う役割です。

必要なログが途中で欠けていたら、その先まで安全に再現できると保証することはできません。バックアップの取得日時だけでなく、回復したい時点までの記録がそろうか、データとログの対応が取れるかを確認します。実製品の回復では、製品が用意する整合性のあるバックアップ方式と復元手順が必要です。

なお、フル・差分・増分の選び方や必要なバックアップの組は、別の論点です。そこを確認したい場合は、基本情報のバックアップ方式と復元へ進めます。ここでは「壊れたデータ本体を何から再構築するか」と「確定した更新をどこまで反映するか」を分けて押さえましょう。

自作問題で対象と目的を確認

問題1。チェックポイントより前に始まったトランザクションは、すべて回復処理の対象外でしょうか。答えは違います。開始が前でも、コミットが後なら確定した更新を再反映することがあり、障害時点で未コミットなら未確定の変更を残さない必要があります。開始と終了を別に読みます。

問題2。電源断の直前にコミットした処理は、必ずすべてのデータページが媒体へ書かれているでしょうか。答えは、そうとは限りません。ログを使う回復方式では、ログから確定した変更を再現できるようにして耐久性を支える場合があります。コミットという論理的な確定と、個別のページ書込みを区別します。

問題3。媒体が壊れましたが、直前のチェックポイントの位置が分かります。それだけでデータ全体を復元できるでしょうか。答えは、できるとは限りません。チェックポイントの位置を知ることは、失われたデータの写しがあることではないためです。バックアップや必要なログが残るかを確認します。

問題4。障害後に、アプリケーションから同じ注文をもう一度送れば、REDOと同じでしょうか。答えは違います。REDOは、DBMSが管理する回復用の記録を利用する処理です。同じ業務要求の再送は別の新しい処理となる可能性があり、重複を防ぐ契約や結果確認が別途必要になります。

問題5。商品Xの確定した変更だけを残し、未確定の商品Yの変更を取り消すことは、データベースを過去の同一時刻の写しへ丸ごと戻すことと同じでしょうか。答えは違います。一律に過去へ戻すのではなく、処理の確定状態に応じて残す結果を決めています。Xが90、Yが50となる例で違いを確かめられます。

基本情報のデータベース障害回復を復習

最初に障害の種類を確認します。処理途中の失敗なのか、メモリ上の状態が失われたのか、データ本体を読む媒体まで壊れたのかで、回復の出発点が違います。そのうえで、バックアップ、ログ、チェックポイントが何を提供するかを区別しましょう。

時系列では、障害時点でコミットしているかと、必要な更新が基準となるデータへ反映されているかを確認します。更新前の情報は取消し、更新後の情報は再反映という基本を押さえつつ、具体的な対象と順序は問題の条件やDBMSの方式に従います。

復習では、在庫の例を見ずに、Xを90、Yを50にする理由を説明してみてください。次にBとDの開始時刻が同じでも判断が違う理由を言い直せれば、チェックポイントの位置だけで機械的に分類する誤りを避けられます。