データベースには重要なデータが入っているので、万一のデータ障害などに備えてバックアップを取得することは非常に重要です。しかし、データベースのバックアップはいくつかの理由で簡単ではありません。
その理由の1つとして、データベースは常に更新され続けている、ということがあります。例えば、毎週日曜日にバックアップを取得しているとして、金曜日にデータベースが壊れたとしましょう。バックアップからデータを戻すだけでは、月曜日から木曜日までのデータ更新が失われてしまいます。バックアップ以降に実施された更新について復旧させる何らかの手段も必要となります。
また別の理由として、データベースの最新情報は、ファイルではなくメモリ上にある、ということが挙げられます。従って、データベースを構成するファイルをコピーするだけでは、バックアップにはならないことに注意が必要です。
PostgreSQLでは、目的に応じていくつかのバックアップ手法があります。
最も簡単で確実な方法はコールドバックアップと呼ばれる方法です。これはデータベースのサーバプロセスを停止して、データベースクラスタ全体をOSのコピーコマンドなどを用いてコピーする方法です。
データベースが動いているときは、メモリ上に最新のデータがありますが、止めてしまえばファイル上のデータが最新ですので、これをコピーすればバックアップになります。プロセスが動いていない、冷たい状態でのバックアップなので、コールド(cold)バックアップ、と呼ばれます。
データベースを止めることができない場合は、この手法を取ることはできません。また、バックアップ取得後に実行されたデータ更新を復旧するための手段が別途、必要になります。
データベースのサーバプロセスを止めずにバックアップを取得する方法もあります。プロセスが動いている、熱い状態でのバックアップなので、ホット(hot)バックアップと呼ばれますが、pg_dump および pg_dumpall がそのためのコマンドです。
pg_dump はデータベースクラスタ内の特定のデータベースについて、データベース全体、あるいはテーブル単位でホットバックアップを取得します。
pg_dumpall はデータベースクラスタ全体、あるいはグローバルオブジェクトについてホットバックアップを取得します。
データベースを止める必要がないので、いつでもバックアップを取得できるのが利点です。
また、メジャーアップグレードの場合は、データベースの論理的なバックアップが必要になるので、アップグレード用のユーティリティを使うのでなければ、 pg_dump や pg_dumpall でバックアップを取ることになります。
なお、バックアップ取得後に実行されたデータ更新を復旧するための手段が必要なのは、コールドバックアップの場合と同じです。
ポイントインタイムリカバリ(PITR)という方法を使って運用すると、データベースがクラッシュした直前の状態にまで復旧させることもできます。
このためには、まず、ある時点のクラスタ全体のバックアップを取得します。これをベースバックアップと呼びます。
次に、ベースバックアップ取得後のトランザクションのログファイル(WALファイルと呼ばれます)をアーカイブして保存しておきます。
万一、データベースが破損して復旧が必要になったときは、ベースバックアップにアーカイブしておいたWALファイル(アーカイブログ)をすべて適用すれば、クラッシュ直前の状態に戻ります。
もちろん、アーカイブログの量が多ければそれだけ復旧に時間がかかりますし、またそれを保存するためのディスクも必要になるので、ベースバックアップは定期的に再取得するようにします。再取得すれば、それ以前の古いアーカイブログは廃棄して構いません。
なお、PITRのための設定や詳細な手順についてはマニュアルを参照してください。
http://www.postgresql.jp/document/current/html/continuous-archiving.html
PostgreSQL 9.0でサポートされたストリーミングレプリケーションはPITRと同じ原理によりデータベースの複製を作成しています。
バックアップなどを使ってデータを復旧することを、リストア、あるいはリカバリ、と呼びます。通常、リストアとは、バックアップのデータをインストールして、バックアップと同じ状態に戻すことを指します。リカバリと言ったときは、リストアしたデータ、あるいは破損したデータに対して何らかの処理をして最新の状態、あるいは正常な状態に復旧させることを指します。
コールドバックアップや pg_dump のバックアップを戻すのはリストアです。例えば、pg_dump コマンドで作成したバイナリ形式のバックアップを戻すときに使われるコマンドは pg_restore ですね。
一方、PITR はバックアップにログファイルを適用することで最新の状態にするのでリカバリです。PITR の R はリカバリ(recovery)の略ですね。
また、データベースを immediate モードで停止した場合、最新の更新がデータファイルに書き込まれずに終了するため、次回の起動時にログファイルの内容をデータファイルに反映させる処理が動きますが、これもリカバリ処理などと呼ばれます。
データベースのバックアップ、リストア、リカバリの方法は、RDBMSによって異なりますが、基本的な考え方には共通しているものがあります。
例えば、データベースプロセスを止めればファイルコピーによりコールドバックアップが取得できるが、動いている状態でファイルをコピーしてもバックアップにならないことは同じです。
ホットバックアップのためのコマンドはRDBMSの種類によって異なりますが、どのRDBMSもそのためのコマンドを用意しています。
PITRという用語はPostgreSQL独自のものですが、ベースバックアップにトランザクションログを適用することでデータベースを復旧させることができる、という機能は、他の多くのRDBMSにもあります。
というわけで、個々の機能の使い方や設定方法をマスターするのはもちろん重要ですが、それと同時に、動作原理についても理解するようにしましょう。これは単に、他のRDBMSを利用するときに役に立つ、というだけでなく、通常の運用管理において何に注意すべきか、また万一のトラブル発生時に何ができるか、何をすべきかを把握するのに非常に重要であり、有能なデータベース管理者かどうかの境目でもあります。
解説:松田神一
© EDUCO All Rights Reserved.