初めに
前回の続きです。
障害管理について
DBには、もしもの時の障害に備えた機能が備わっています。
例えば、定期的にバックアップを取ったり、DB更新前後の状態をジャーナルと呼ばれるログファイルに記録したりです。
このように実際に障害が発生した場合は、これらのファイルを使って
障害回復処理を行い、元の状態に復旧します。
コミットとロールバック
前回の記事でも言いましたが、DBはトランザクション単位で更新処理を管理します。
例えば、「AさんからBさんにお金を振り込む」処理を想像してみて下さい。
①Aさんの口座残高を確認する
↓
②Aさんの口座残高から1000円減らす
↓
③Bさんの口座残高を確認する
↓
④Bさんの口座残高を1000円増やす
この①〜④が1つのトランザクションでしたね。
この中で、どこかの処理が上手くいかなくて「Aさんの口座残高は減額しているのに、Bさんの残高は増えていない」という状態では大問題です。
そのため、DBでは更新内容を反映させるのは
全ての処理が正常に更新された時でないといけません。
トランザクションの処理が問題なく完了できた際、最後に
その更新を確定することでDBへ更新内容を反映させます。
これをコミットと呼びます。
一方、トランザクション処理中に何らかの障害が発生した場合は
そこまでに行った処理をすべてリセットします。
でないと、データの不整合が引き起こされてしまうからです。
①Aさんの口座残高を確認する
↓
②Aさんの口座残高から1000円減らす
↓
③Bさんの口座残高を確認する
↓
❌障害発生
④Bさんの口座残高を1000円増やす
↓
①〜④の処理全てをリセットする
そこでこのような場合では、DB更新前の状態を更新前ジャーナルから取得して
トランザクション開始直前の状態にまで巻き戻す処理を行います。
これをロールバックと呼びます。
このようにDBでは「トランザクション内の更新全てを反映する」もしくは
「トランザクション内の更新全てを取り消す」のどちらかしかないという訳です。
分散データベースと2相コミット
ネットワーク上に複数存在するDBを1つのDBMSが管理している形態を分散DBと呼びます。
支社などの複数の場所にDBを分散して業務を統合する方式で、集中管理しているDBと比べて通信負荷の軽減や１つに障害が発生しても全体の機能が失われないというメリットがあります。
しかし、デメリットもあってトランザクション処理が別々のDBで行われるので
全体の同期をとってコミットやロールバックをしないとデータの不整合が起こってしまいます。
そこで2相コミットという方式が役に立ちます。
コミット前に分散しているDBに「コミットできる？」かと問い合わせて、OKなら一斉にデータを更新し、どこか１つでも障害が発生していればロールバックを行うといった方式です。
これにより、各DBの整合性を保っているという訳です。
ロールフォワード
DBの障害はなにもトランザクション処理中だけではありません。
データが記録されているハードディスクが故障してしまうなど
物理的な障害が発生してしまう事だってあります。
その場合、定期的に保存してあるバックアップファイルからデータを復元しますが
それだけだとバックアップ後の更新情報が復元できません。
そこで、DBに行なった更新情報をバックアップ以降の更新後ジャーナルから取得し、障害発生直前の状態に復旧させます。
このようにバックアップによる復元から、更新後ジャーナルでバックアップ以降の更新情報を復元する一連の処理をロールフォワードと呼びます。
このようにDBを復旧する方法として
・ロールバック
・ロールフォワード
の2つがあります。
※この2つの違いを分かりやすく解説している記事があったので載せておきます↓
「ロールバック」と「ロールフォワード」の違い
おわりに
データベース編はここで終わりです。
次は、ネットワーク編を書こうと思ってます。
間違っている部分や気になるところがあれば
コメントして下さると有り難いです。