データベースバックアップの種類、復旧方法、チェックポイントを解説

データベース

データベースのバックアップや復旧(リカバリ)は、システム運用で重要な知識です。
本記事では、フルバックアップ・差分バックアップ・増分バックアップの違いや、トランザクションログ、ロールフォワード、PITRまで初心者向けに図解で解説します。

データベース障害の種類と原因

代表的な障害

データベースには主に次のような障害があります。

  • ハードウェア障害(ディスク故障など)
  • ソフトウェア障害(DBMSクラッシュ)
  • ユーザー操作ミス(誤削除、誤更新など)
  • 災害・外部要因(地震、台風など)
データベース障害

障害が与える影響

データベース障害により、データ消失、サービス停止(ダウンタイム)、ビジネス損失などといった影響があります。

データベースのバックアップ方式

上の章で説明した障害に備えデータベースのバックアップを取ることが重要です。
バックアップの方式はフルバックアップ、差分バックアップ、増分バックアップなどがあります。

フルバックアップとは

フルバックアップはバックアップ実施時点のデータベースを丸ごとバックアップします。

復旧の際、フルバックアップデータから復元をするだけで完了となるのでこの後説明する差分バックアップや増分バックアップと比べて復元の手間はかかりません。

フルバックアップはバックアップの時間が長いのがデメリットです。

差分バックアップとは

差分バックアップは、最後のフルバックアップから変わった分だけをバックアップします。

差分バックアップ

復旧の際は、フルバックアップデータ + 差分バックアップデータ(1つだけ)を使って復元します。
上の例ので火曜日時点に復元する場合、日曜日のフルバックアップデータと、火曜日の差分バックアップデータを使って復元します。

増分バックアップとは

増分バックアップは、直前のフルバックアップまたは増分バックアップからの追加または変更分をバックアップします。

復旧の際は、フルバックアップデータ + 増分バックアップデータを全文順番に使って復元します。
上の例ので火曜日時点に復元する場合、日曜日のフルバックアップデータと、月曜日の増加バックアップデータと、火曜日の増分バックアップデータを使って復元します。

フル・差分・増分バックアップの比較

種類バックアップデータ容量バックアップ速度復元速度
フル×:多い
(毎日フルバックアップといった場合)
×:遅い
(毎回フルバックアップ)
◎:とても速い
(1回の復元だけで完了)
差分△:多め
(フル + フルからの差分)
〇:速い
(フルバックアップからの差分)
〇:速い
(フル+差分の2回で復元)
増分〇:少ない
(フル+前回からの増分)
◎:とても早い
(前回からの増分)
×:遅い
(フル+増分(全て)で復元)

トランザクションログとデータ復旧の仕組み

データベースの障害復旧を理解するうえで最も重要なのが、「トランザクション」と「ログ」の仕組みです。
これらは、単にデータを保存するだけでなく、「正しい状態に戻すための仕組み」として機能します。

トランザクションとは

トランザクションとは、データベースに対する一連の処理を「ひとまとまり」として扱う単位のことです。

例えば、銀行の振込処理で口座Aから口座Bへ1,000円振込する場合を考えてみてください。
この場合、次の2つはセットで成功しなければなりません。

  • 口座Aから残高を減らす
  • 口座Bに残高を増やす
トランザクション

実務を考えると、さらに「取引履歴テーブル」のようなテーブルにもデータを追加することなどが考えられますが、今回の例では省略します。

ログの役割

トランザクションログとは、データベースに対する更新を記録したファイルです。
障害復旧において、最も重要な役割を担います。

ログに記録される内容

ログに記録される内容は次の内容になります。

  • どのデータが変更されたか
  • 変更前の値(Before Image)
  • 変更後の値(After Image)
トランザクションログ

なぜログが必要なのか?

更新途中でサーバが停止やクラッシュした場合、このときログがないと、「どこまで処理されたか」が分かりません。
この場合、以下の対処をします。

  • ロールバック・・・障害発生時に未完了だった処理を取り消す(トランザクションの取り消し)
  • ロールフォワード・・・バックアップ取得後の更新内容をログから再適用する

ロールフォワードは、次の章で説明をします。

トランザクションログの呼び方

トランザクションログ周りはDBMSごとに用語差があります。

  • Oracle → REDOログ / ARCHIVELOG
  • SQL Server → トランザクションログ
  • PostgreSQL → WAL
  • MySQL → binlog / redo log

データベースの復旧方法(リカバリ手法)

トランザクションログを活用した復旧方法(リカバリ手法)を説明します。

ロールフォワード

ロールフォワードとは、バックアップ取得後にコミットされたトランザクションの処理だけをログから再実行し、データベースを復旧する方法です。
正常だった時点からデータを前進(Forward)させて最新状態に戻すので、前進復帰とも呼ばれます。

ロールフォワードによる復旧の流れ

バックアップデータから復元し、ログを順番に適用します。
これにより、コミット済みの処理を再実行し、ログの中から、正常に完了(COMMIT)している処理だけを反映します。

ロールフォワード

ロールフォワードが可能なタイミング

ロールフォワードでは、トランザクションログに記録されたCOMMIT済みの処理のみが再実行されます。
未完了(未コミット)の処理は復旧対象になりません。

ロールフォワードが可能なタイミング

チェックポイントとは

チェックポイントの仕組み

一般的なデータベースは、データの更新内容をすぐディスクへ書かず、まずメモリ上で処理します。
メモリ上の内容は、チェックポイントが発動するとディスクのデータファイルへ反映されます。

チェックポイントの仕組み

データ本体を書く前に、ログを先に保存する方式をWAL(Write Ahead Log)といいます。

チェックポイントとロールフォワード

障害によるデータベース停止が発生した場合、トランザクションはチェックポイント済みであればデータはディスクへ書き込まれているのでロールフォワードが不要ですが、チェックポイント発動前の場合はロールフォワードで復元が必要です。

チェックポイントとロールフォワード

なお、データファイルが破損してしまった場合は、チェックポイント実施に関係なく、バックアップデータからの復元とログによるロールフォワードで復旧が必要です。

実際、データベースでは、データページのディスク書き込みはチェックポイント時だけではなく、バックグラウンドで常に少しずつ行われています。
チェックポイントの本質は、「この時点以前の更新については、どこまでディスク反映済みか」を記録し、障害復旧時に必要なログの範囲を限定することです。
つまり、「ここ以降のログを見れば復旧できる」という復旧開始位置を決める仕組みです。

ポイントインタイムリカバリ(PITR)

ポイントインタイムリカバリ(PITR: Point In Time Recovery)とは、データベースを、過去の特定時点の状態まで戻す復旧方式

ポイントインタイムリカバリ(PITR)

まとめ

  • バックアップには「フルバックアップ」「差分バックアップ」「増分バックアップ」の3種類がある
  • フルバックアップは復旧しやすいが、保存容量が大きくなりやすい
  • 差分バックアップは「前回のフルバックアップからの差分」を保存する方式
  • 増分バックアップは「直前のバックアップからの差分」を保存する方式
  • 差分バックアップは復旧が比較的簡単、増分バックアップは保存容量を抑えやすい
  • トランザクションログは、データベースへの変更内容を時系列で記録したログ
  • ログを利用することで、バックアップ取得後の更新内容も復元できる
  • ロールフォワードは、ログを適用して障害発生直前までデータを復旧する処理
  • チェックポイントは、復旧時に必要となるログ量を減らし、リカバリを高速化する仕組み
  • PITR(ポイントインタイムリカバリ)を利用すると、特定時点までデータベースを復旧できる

コメント

タイトルとURLをコピーしました