DBアタマアカデミー
第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(3)
リカバリ
障害のレベル
システム障害には,大きく3つのレベルがあります。それに応じて必要とされるリカバリのレベルも変わってきます(図8)。
論理障害
まず,最も上位レベルでの障害としては,論理障害,いわゆるアプリケーションのクラッシュがあります。OSごと落ちてしまう,ということもありますが,その場合でも次節に述べるファイルレベルの障害が起きなければこのカテゴリに属します。このレベルの障害では,ユーザ側で明示的なリカバリは必要ありません。前回も取り上げたように,システムの再起動時に自動的にロールバック/ロールフォワード処理が実行されてデータの整合性が保証されます。
ファイル障害
それより一段低いレベルの障害としては,データなどを含むファイルが破損する,あるいは失われるなどして,データ損失が起きたり,整合性が取れなくなるといった,ファイルシステムレベルの障害があります。この場合,DBMSはファイルの復旧まではできないので,ユーザの明示的なリカバリが必要になります。このレベルの障害には適当な名前が見つからないため,便宜的に「ファイル障害」としておきましょう。
物理障害
最下層レベルの障害としては,物理障害,つまりストレージなど記憶媒体そのものが壊れるケースがあります。この場合,データが含まれたファイルも一緒に壊れてしまうため,やはりユーザによる明示的なリカバリが必要です。この場合は,リカバリの前にそもそもハードウェア自体のリプレースや修理も必要になります。
リストアとリカバリ
さて,不運にもファイル障害または物理障害が発生してしまい,リカバリが必要になったとしましょう。このとき,具体的にどのような手順でデータの復元を行うのでしょうか。
この場合の手順には,大きく2つあります。それがリストアとリカバリです。この2つはちょうど差分/増分バックアップと同じように区別されずに使われることもありますが,厳密には異なる操作を指します。リストアとリカバリのイメージを図9に示します。
まずリストアとは,バックアップファイルをデータベースに適用することです。「ファイルを戻す」などとも言われます。このリストアされた状態は,いわばロールフォワード前の状態です。
リカバリとは,そのあとにトランザクションログを適用することでロールフォワードを行い,データを最新の状態にアップデートすることを指します。そのため,実行の順番としては常にリストア→リカバリとなります。通常のロールフォワードとの違いは,適用するログファイルが,オンラインのものか,それともバックアップで取得したオフラインのものか,という点だけです。
- データベースの基本精神
- 復旧手順は常にリストア→リカバリ
まとめ
本稿では,バックアップ/リカバリについてのしくみと実装について解説してきました。実際のところ,リカバリというのは行わないで済むならそれに越したことはないものです。防災訓練をやることはあっても,本当に災害に遭遇するのは誰だって遠慮したいでしょう。その意味で,コラム「リカバリなんてしたくない!」にも書いたように,リカバリまで行き着かないための方法を考えるということも,非常に重要なポイントです。
しかし一方で,データ保護に関して高い要件が求められるシステムにおいては,強固なバックアップ/リカバリのプランを持っておくことは必須です。そして,本稿を通して明らかになったように,このプランの策定に最大の影響を及ぼすのが,やはりトレードオフの原理なのです。バックアップ媒体はどの程度の容量を用意できるか? バックアップウィンドウとリカバリウィンドウの長さは? いつ時点のデータに復旧すればよいのか?
システム開発とは,こうしたトレードオフのパズルを,全体として整合するように1つ1つ解いていく地道な作業だということが,本連載をとおしてみなさんにもわかり始めたのではないでしょうか。
それでは,今回のポイントをまとめましょう。
- バックアップの分類はフル/差分/増分の3種類が基本
- フルバックアップはすべてのプランの基礎となるため必須
- 差分/増分バックアップを取得するかどうかはさまざまな要件次第
- リカバリをしないですむ努力も同時に必要
- この世は(非常に残念だが)やっぱりトレードオフの原理に支配されている
今回の演習問題は次のものです。
演習問題の解答は,筆者のWebサイトおよび技術評論社のサイトで公開します。それでは,次回またお会いしましょう。
- 演習問題
- あなたの使うDBMSで差分/増分バックアップを行うために必要な設定を調べなさい。
参考資料
- 『Database Management Systems 3rd ed.』
(Raghu Ramakrishnan,Johannes Gehrke著,McGraw Hill Higher Education,2002年)
- 「18 Crash Recovery」で,リカバリ時にDBMSが実行する手順について詳しくまとめられています。なお,本書はあまりバックアップについては触れられていません。
- 「一からはじめるNetVault (Linux編)」「第3回 バックアップを極める!(前編)」
- http://www.bakbone.co.jp/support/netvault_lesson/nvls200312.html
- 「DB2のインクリメンタルバックアップの使用」
(Blair Adamache)[日本語訳版]
- http://www.ibm.com/developerworks/jp/data/library/dataserver/techdoc/incremental.html
バックアップについては,上記「一からはじめるNetVault (Linux編)」と「DB2のインクリメンタルバックアップの使用」の文書が充実しています。実装依存の部分もありますが,一般的な観点からも参考になる内容です。
リカバリなんてしたくない!
リカバリというのは,データを復旧させるための最後の砦であり,あまりこの砦を見る経験はしたくありません。特に,差分/増分バックアップで運用している場合,リカバリに時間がかかるため,極力避けたいものです。そこで,近年ではたとえ物理障害が発生したとしても,リカバリの手前でデータを救う手段が多く採用されています。その方法とは,データの冗長化です。この方法には物理レベルで行うRAID(Redundant Arrays of Inexpensive Disks)と,論理レベルで行うレプリケーションがあります。
RAID
RAIDの場合は,ディスクをミラーリング(冗長化)して,単一障害によるデータ損失を防止します。
冗長化されたディスクであれば,単一障害の時点ではまだ復旧が可能です。そのため,壊れたディスクをすばやくスペアに交換し,残っているディスクから再同期を行うことで,リカバリせずにすみます。最近は,システムを停止せずにディスクを交換するホットスワップが可能な製品も出ています。
レプリケーション
一方,レプリケーションとは,同一のデータを保持するデータベースシステムそのものを冗長化し,定期的にデータの同期を取りながら運用する方法です。MySQL などで主に利用されています。実装のしくみとしては,トランザクションログをマスタのデータベースからスレーブのデータベースへ反映するものですので,イメージとしてはこまめにリカバリ処理をやっているようなもの,と言えるかもしれません。
もちろん,こうした冗長化を施していても,二重障害が発生すれば,結局リカバリへ突入することになるのですが,リカバリをしないで済む可能性を高められるならば,二重三重にセーフティネットを張っておくという選択肢も十分に検討の対象になります。
DBアタマアカデミー
- 最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(3)
- 最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(2)
- 最終回 治療としてのパフォーマンスチューニング―システムの病気はどう治す?(1)
- 第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(3)
- 第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(2)
- 第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(1)
- 第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(3)
- 第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(2)
- 第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(1)
- 第2回 トランザクションを知ればデータベースがわかる―「データ復旧」「同時実行制御」を行う“不完全な”しくみ(3)


