無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

24.1. 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 の出力は一般に新しいバージョンの PostgreSQL に再ロードできるということです。一方、ファイルレベルのバックアップと継続的アーカイブは両方とも非常にサーバ、バージョン依存です。 pg_dump は、32ビットから64ビットのサーバに移行するなどの異なるマシンアーキテクチャにデータベースを移す場合に上手くいく唯一の方法でもあります。

pg_dump で作成されたダンプは、内部的に整合性があります。つまり、ダンプは pg_dump が開始された際のデータベースのスナップショットを示しています。 pg_dump の操作はデータベースに対する他の作業を妨げません( ALTER TABLE のほとんどの形態であるような排他的ロックが必要な作業は例外です)。

重要項目: (例えば外部キーのように)データベーススキーマがOIDに依存している場合、 pg_dump にOIDも一緒にダンプするよう指定しなければなりません。これを行うには -o コマンドラインオプションを使用します。

24.1.1. ダンプのリストア

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

psql 

dbname

 < 

infile

ここで infile pg_dump コマンドにより出力されたファイルです。 dbname データベースはこのコマンドでは作成されません。 (例えば createdb -T template0 dbname のようにして) psql を実行する前に自分で template0 から作成してください。 psql pg_dump と似たような、接続データベースサーバと使用するユーザ名を指定するオプションに対応しています。詳細については、 psql のリファレンスページを参照してください。

SQLダンプのリストアを実行する前に、ダンプされたデータベース内のオブジェクトを所有するユーザやそのオブジェクト上に権限を与えられたユーザも存在しなければなりません。 存在していない場合、リストアはそのオブジェクトの元々の所有権や付与された権限を再作成することができません (このようにしたい場合もあるでしょうが、通常そうではありません)。

デフォルトで psql スクリプトは、SQLエラーが起きた後も実行を継続します。 ON_ERROR_STOP 変数を設定して psql を実行することで、その動作を変更し、SQLエラーが起きた場合に psql が、終了ステータス3で終了するようにしたいと思うかもしれません。

psql --set ON_ERROR_STOP=on dbname < infile

どちらにしても、部分的にリストアされたデータベースにしかなりません。 他に、ダンプ全体を1つのトランザクションとしてリストアするように指定することができます。 こうすれば、リストアが完全に終わるか、完全にロールバックされるかのどちらかになります。 このモードは、 psql のコマンドラインオプションに -1 または --single-transaction を渡すことで指定できます。 このモードを使用する場合、数時間かけて実行していたリストアが軽微なエラーでロールバックしてしまうことに注意してください。しかし、部分的にリストアされたダンプから手作業で複雑なデータベースを整理するよりまだましかもしれません。

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

pg_dump -h 

host1

 

dbname

 | psql -h 

host2

 

dbname

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

バックアップをリストアした後、問い合わせオプティマイザが有用な統計情報を使用できるように、各データベースに対して ANALYZE を実行することを勧めます。 より詳しくは、 項23.1.3 項23.1.6 を参照してください。 効率的に大規模なデータを PostgreSQL にロードする方法に関するより多くの勧告については、 項14.4 を参照してください。

24.1.2. pg_dumpall の使用

pg_dump は同時に単一のデータベースのみをダンプします。 また、ロールやテーブル空間についての情報はダンプしません。 (これらはテーブル毎ではなくクラスタ全体のものだからです。) データベースクラスタの全内容の簡便なダンプをサポートするために、 pg_dumpall プログラムが提供されています。 pg_dumpall は指定されたクラスタの各データベースのバックアップを行い、そして、ロールやテーブル空間定義などのクラスタ全体にわたるデータを保存します。 このコマンドの基本的な使用方法は

pg_dumpall > 

outfile

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

psql -f 

infile

 postgres

(実際、開始時に任意の既存のデータベース名を指定することができますが、空のクラスタ内にロードする場合は、通常 postgres を使用すべきです。) ロールやテーブル空間の情報をリストアしなければならないので、 pg_dumpall のダンプをリストアする時には、データベーススーパーユーザのアクセス権限を確実に必要とします。 テーブル空間を使用している場合、ダンプ内のテーブル空間のパスが新しいインストレーションで適切であることを確認してください。

pg_dumpall はコマンドを発令することによりロール、テーブル空間、およびデータベースを再作成し、それぞれのデータベースに対して pg_dump を起動します。このことは、それぞれのデータベースには内部的に矛盾がない一方、異なるデータベースのスナップショットは完全に同期しない可能性があることを示しています。

24.1.3. 大規模データベースの扱い

オペレーティングシステムの中には最大ファイルサイズに制限があるものがあり、大きな pg_dump 出力ファイルを作成しているときに問題を引き起こします。 幸運なことに、 pg_dump は標準出力に書き出すことができますので、Unix標準のツールを使ってこの潜在的な問題を解決できます。取りうる方法がいくつか存在します。

圧縮ダンプの使用. たとえば、自分が愛用している gzip のような圧縮プログラムが使えます。

pg_dump 

dbname

 | gzip > 

filename

.gz

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

gunzip -c 

filename

.gz | psql 

dbname

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

cat 

filename

.gz | gunzip | psql 

dbname

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

pg_dump 

dbname

 | split -b 1m - 

filename

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

cat 

filename

* | psql 

dbname

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

pg_dump -Fc 

dbname

 > 

filename

カスタム書式のダンプは psql 用のスクリプトではありませんので、代わりに pg_restore でリストアしなければなりません。例えば以下のようにします。

pg_restore -d 

dbname

 

filename

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

巨大なデータベースに対しては、そのほかの2つの手法のうちの1つと一緒に split を組み合わせる必要があるかもしれません。

pg_dump の並列実行. pg_dump を並列実行することで、大きなデータベースのダンプを高速に実行することができます。これは同時に複数表のダンプを実行します。並列度は -j パラメータを指定することで制御できます。並列ダンプはディレクトリダンプ書式のみサポートします。

pg_dump -j 

num

 -F d -f 

out.dir

 

dbname

pg_restore -j コマンドでダンプファイルを並列でリストアすることができます。これは pg_dump -j でダンプファイルが作成されたか、否かにかかわらず、カスタムもしくはディレクトリダンプ書式で作成されたダンプファイルに使用できます。


powered by SEO.CUG.NET