第 22章バックアップとリストア

目次
22.1. SQL によるダンプ
22.1.1. ダンプのリストア
22.1.2. pg_dumpall の使用
22.1.3. 大規模データベース
22.1.4. 警告
22.2. ファイルシステムレベルのバックアップ
22.3. リリース間の移行

貴重なデータをすべて保存しているため、 PostgreSQL データベースは定期的にバックアップされなければなりません。 バックアップの手順は基本的に簡単ですが、底流にある技術といくつかの仮定となる条件を理解することは重要です。

PostgreSQL のデータをバックアップする時には基本的に以下の異なった 2 つの手法があります。

22.1. SQL によるダンプ

SQL によるダンプ方法の背景にある考え方は SQL コマンドでテキストファイルを生成し、そのファイルをサーバが再度読み込みを行った時に、ダンプした時点と同じ状態が再構築されるということです。 この目的のため、PostgreSQL にはユーティリティプログラム pg_dump を提供しています。 このコマンドの基本となる使い方は以下のとおりです。

pg_dump dbname > outfile

見てわかるとおり、pg_dump は結果を標準出力に書き出します。 これがどのように活用できるかをこれから説明してゆきます。

pg_dumpは、(すぐれた機能をとくに発揮する)PostgreSQL の通常のクライアントアプリケーションです。 ということはデータベースに接続可能なあらゆるリモートホストからこのバックアップ手順を実行することができます。 しかし、pg_dump は特別な権限で動作しないことを覚えておいてください。 具体的にいうと、バックアップを行うすべてのテーブルに対して読み込み権限が必要となります。 ですから実際にはデータベースのスーパーユーザである必要があります。

pg_dump を行うデータベースサーバを特定するにはコマンドラインのオプション-h host-p port を使用します。 デフォルトのホストはローカルホスト、または、環境変数 PGHOST で指定されるものです。 同様に、デフォルトのポートは環境変数 PGPORT で指定されているか、うまく行かない場合にはコンパイル時の設定がデフォルトとなります。 (そこはうまくできていて、サーバは通常コンパイル時の設定をデフォルトとします)。

他の PostgreSQL のクライアントアプリケーションと同様に、pg_dump はデフォルトで、オペレーティングシステムの現在のユーザ名と同じデータベースユーザ名で接続します。 これを無効にするには -U オプションを付けるか環境変数 PGUSER を設定します。 pg_dump の接続は(第19章 で説明されている)通常のクライアント認証方法によることを思い出してください。

pg_dumpで作成されたダンプは、内部的に整合性があります。 つまり、pg_dumpが行われている際の更新はダンプには反映されないということです。 pg_dump が作動している時はデータベースに対する他の作業は妨げられません。 (VACUUM FULL などの、排他的なロックが必要な作業は例外です。)

重要項目: (たとえば外部キーのように)データベーススキーマが OID に依存している場合 pg_dump に OID も一緒にダンプするよう指定しなければなりません。 これを行うには -o コマンドラインオプションを使用します。 デフォルトで "ラージオブジェクト"もダンプされません。 ラージオブジェクトを使用する場合 pg_dump コマンドのリファレンスページを参照してください。

22.1.1. ダンプのリストア

pg_dumpで作成されたテキストファイルは psql プログラムで読み込まれることを意図しています。 以下に、ダンプをリストアする一般的な方法を示します。

psql dbname < infile

ここで infilepg_dump コマンドで outfile としたものです。 データベース dbname はこのコマンドでは作成されません。 (たとえば createdb -T template0 dbname のようにして) psql を実行する前に自分で template0 から作成してください。 psql には pg_dump と似たような、データベースサーバの場所とユーザ名を指定する機能があります。 詳細については、該当リファレンスページを参照してください。

元となるデータベース内のオブジェクトの所有権が別のユーザにあった場合ダンプは代わりに psql に対しそれぞれの所有権を持っているユーザになるように順次接続させ、適切なオブジェクトを作成させます。 この方法により、元の所有権が保たれます。 しかし、このことはすべてのユーザーがあらかじめ存在し、さらにそれぞれのユーザとして接続できる権限を持っていなければいけません。 ですから一時的にクライアント認証設定を緩める必要があるでしょう。

リストアした後、オプティマイザが有用な統計情報を持つように、各データベースに対してANALYZEを実行することを勧めます。 vacuumdb -a -zを実行して、すべてのデータベースに対してANALYZEを行なうことも可能です。

pg_dumppsql ではパイプから読み書きができるので、あるサーバから別のサーバへデータベースを直接ダンプできます。 以下に例を示します。

pg_dump -h host1 dbname | psql -h host2 dbname

重要項目: pg_dump で作成されるダンプは template0 から相対関係にあります。 つまり template1 に追加されたあらゆる言語、手順なども pg_dump によりダンプされます。 その結果としてリストアする際に、カスタマイズされた template1 を使用している場合は、上記の例のように、template0 から空のデータベースを作成する必要があります。

ティップ: リストアの性能は、sort_mem設定パラメータを増やすことで向上することができます。 (項16.4.2.1を参照してください。)

22.1.2. pg_dumpall の使用

上で説明した手法はデータベースクラスタすべてをバックアップする際に扱いにくく不適切です。 この理由で pg_dumpall プログラムが提供されています。 pg_dumpall は指定されたクラスタの各データベースのバックアップを行い、ユーザーやグループなどのクラスタ全体にわたるデータの状態が確実に保たれるようにします。 pg_dumpall の呼出し手順は単に

pg_dumpall > outfile

です。 ダンプの結果は psql でリストアできます。

psql template1 < infile

(実際、開始時に任意の既存のデータベース名を指定することができますが、空のクラスタ内に再ロードする場合は、template1が唯一の選択肢です。) ユーザとグループの情報をリストアしなければならないので、pg_dumpallのダンプをリストアする時には、データベーススーパーユーザのアクセス権限を確実に必要とします。

22.1.3. 大規模データベース

PostgreSQL はシステム上で最大可能なファイルサイズよりも大きなテーブルを扱えるので、ファイルにダンプする際に、システムで許容されているファイルサイズを越えてしまうという問題に遭遇する可能性があります。 pg_dump は標準出力に書き出しますので、この問題を解決するために Unix のツールを使用して回避できます。

圧縮ダンプの使用. gzip のような好みの圧縮プログラムを使うことができます。

pg_dump dbname | gzip > filename.gz

元に戻すには次のようにします。

createdb dbname
gunzip -c filename.gz | psql dbname

あるいはこのようにもできます。

cat filename.gz | gunzip | psql dbname

split の使用. split コマンドで結果を背後のファイルシステムで受け付けられる大きさに分割することができます。 たとえば1Mバイトずつに分割するには次のようにします。

pg_dump dbname | split -b 1m - filename

元に戻すには次のようにします。

createdb dbname
cat filename* | psql dbname

カスタムダンプ書式の使用. もし PostgreSQLzlib 圧縮ライブラリインストール済みのシステム上で構築されたのなら、カスタムダンプ書式では出力ファイルに書き出す時にデータを圧縮します。 巨大なデータベースでは gzip を使用した時と似通ったダンプサイズとなりますが、テーブルの復元を部分的に行えるという点で優れているといえます。 以下のコマンドは、カスタムダンプ書式でのデータベースのダンプを行います。

pg_dump -Fc dbname > filename

詳細はpg_dumppg_restore のリファレンスページを参照してください。

22.1.4. 警告

pg_dumppg_dumpall も連座して)にはシステムカタログからの特定の情報の復元が困難であるために生じるいくつかの制約があります。

特に、pg_dump がオブジェクトを書き出す順序は洗練されていません。 たとえば列のデフォルト値として関数が使用されている場合などで、これが問題となります。 この問題を解決するには、手作業でダンプ順序を変更する方法以外ありません。 スキーマ内で巡回依存を作成していた場合は、これ以上の作業が必要となります。

後方互換性の理由から、デフォルトで pg_dump はラージオブジェクトのダンプを行いません。 ラージオブジェクトのダンプを行うには、出力形式をカスタムもしくは TAR 書式にする必要があり、また pg_dump-b オプションを付ける必要があります。 詳細はリファレンスページを参照してください。 PostgreSQL ソースツリーの contrib/pg_dumplo ディレクトリにもラージオブジェクトをダンプするプログラムがあります。

pg_dump リファレンスページを習熟してください。