pg_dumpはPostgreSQLデータベースをバックアップするユーティリティです。 データベースを使用中であっても一貫性のあるバックアップを作成することができます。 pg_dumpは他のユーザによるデータベースへのアクセス(読み書き)をブロックしません。
ダンプはスクリプト形式、または、アーカイブファイル形式で出力することができます。 スクリプトダンプは、保存した時点の状態のデータベースを再構成するために必要なSQLコマンドが書き込まれた平文ファイルです。 このスクリプトを使ってリストアを行うにはpsqlを使用します。 スクリプトファイルを使えば、ダンプを行ったのとは別のマシンや別のアーキテクチャ上でも、データベースを再構築することができます。 また、多少編集すれば他のSQLデータベース製品上でもデータベースの再構築が可能です。
もう1つの形式であるアーカイブファイル形式を使ってデータベースを再構築するには、pg_restoreを使用しなければなりません。 このファイルを使用すると、pg_restoreがリストア対象を選択したり、リストアするアイテムを並び替えたりできます。 アーカイブファイルもまた、アーキテクチャを越えて移植できるように設計されています。
いずれかのアーカイブファイル形式をpg_restoreと組み合わせて使用する場合は、pg_dumpの柔軟なアーカイブ/転送機構が利用できます。 具体的には、pg_dumpを使用してデータベース全体をバックアップし、pg_restoreを使用して、アーカイブの内容を検査したり、データベースの一部を選択してリストアしたりすることができます。 最も柔軟な出力ファイル形式は"custom"形式(-Fc)です。 この形式ではデフォルトで圧縮されます。また、保存された項目の選択や並び換えを行うことができます。
pg_dumpの実行中は、標準エラーに出力される警告(特に後述の制限に関する警告)が出力されていないか確認してください。
以下のコマンドラインオプションは出力形式とその内容を制御します。
ダンプするデータベースの名前を指定します。 指定されていない場合はPGDATABASE環境変数が使われます。 この変数も設定されていない場合は、接続のために指定されたユーザ名が使用されます。
データのみをダンプし、スキーマ(データ定義)はダンプしません。 テーブルデータ、ラージオブジェクト、シーケンス値がダンプされます。
このオプションは--section=dataを指定することと似ていますが、歴史的な理由で同一ではありません。
ラージオブジェクトをダンプに含めます。 これはデフォルトの動作ですが、--schema、--table、--schema-onlyが指定された場合は例外です。 したがって、-bオプションは選択的なダンプにラージオブジェクトを追加する場合にのみ有用です。
データベースオブジェクトを作成するコマンドの前に、データベースオブジェクトを整理(削除)するコマンドを書き出します。 (対象のデータベースの中にオブジェクトがまったくない場合でも、リストア時に害がないエラーがいくつか発生するかもしれません。)
このオプションは平文形式の場合にのみ有効です。 アーカイブ形式では、pg_restoreを呼び出す時にこのオプションを指定することができます。
初めにデータベース自体を作成するコマンドを出力し、その後、作成したデータベースに接続するコマンドを出力します (このようなスクリプトを使用すると、スクリプトを実行する前に対象のインストレーションの中のどのデータベースに接続すればよいかという問題を考える必要がなくなります)。 --cleanも同時に指定されている場合、このスクリプトは接続する前に対象データベースを削除し再作成します。
このオプションは平文形式の場合にのみ有効です。 アーカイブ形式では、pg_restoreを呼び出す時にこのオプションを指定することができます。
指定した文字セット符号化方式でダンプを作成します。 デフォルトではダンプはデータベースの符号化方式で作成されます。 (PGCLIENTENCODING環境変数を好みのダンプ時の符号化方式に設定することで、同じ結果を得ることができます。)
出力を指定のファイルに送ります。 ファイルを基にする出力形式ではこのパラメータは省くことができます。 省略時は標準出力が使用されます。 しかしディレクトリ出力形式の場合は、省略することはできず、ファイルではなく対象ディレクトリを指定します。 この場合、ディレクトリはpg_dumpが生成しますので、事前に存在してはなりません。
出力形式を選択します。 formatには以下のいずれかを取ることができます。
平文のSQLスクリプトファイルを出力します(デフォルト)。
pg_restoreへの入力に適したカスタム形式アーカイブを出力します。 ディレクトリ出力形式と一緒に使用する場合、リストア時に手作業で保管された項目の選択、再順序付けできますので、これはもっとも柔軟な出力形式です。 また、この形式はデフォルトで圧縮されます。
pg_restoreへの入力に適したディレクトリ形式のアーカイブを出力します。 これは、ダンプされる各テーブルおよびblobごとに1つのファイル、さらに、pg_restoreから読み取り可能な、機械的に読み取り易い書式でダンプしたオブジェクトを記述する目次ファイルと呼ばれるファイルを持つディレクトリを作成します。 ディレクトリ形式アーカイブは標準Unixツールで操作することができます。 例えば、未圧縮アーカイブ内のファイルをgzipツールを使用して圧縮することができます。 この形式はデフォルトで圧縮されます。
pg_restoreへの入力に適したtar形式のアーカイブを出力します。 このtar形式はディレクトリ形式と互換性があります。 tar形式アーカイブを展開すると、有効なディレクトリ形式のアーカイブを生成します。 しかしtar形式は圧縮をサポートせず、個々のテーブルのサイズに関して8ギガバイトという上限があります。 またリストア時にテーブルデータ項目の相対的な順序を変更することはできません。
廃止されたオプションであり、現在は無視されます。
schemaに一致するスキーマのみをダンプします。 これはスキーマ自体とそこに含まれるオブジェクトすべてを選択します。 このオプションが指定されなければ、対象データベース内にあるシステム以外のスキーマ全てがダンプされます。 複数の-nオプションを記述することで、複数のスキーマを選択することができます。 また、schemaパラメータはpsqlの\dコマンドと同じ規則に従うパターン(パターン参照)として解釈されます。 ですので、ワイルドカード文字をパターン内に記述することで、複数のスキーマを選択することもできます。 ワイルドカードを使用する時は、シェルによりそのワイルドカードを展開させないように、パターンを引用符で括ってください。 例を参照してください。
注意: -nが指定されると、pg_dumpは選択したスキーマ内のオブジェクトが依存する可能性がある、その他のデータベースオブジェクトのダンプを行いません。 したがって、スキーマ指定のダンプ結果を初期状態のデータベースに正常にリストアできるかどうかの保証はありません。
注意: -nが指定されると、blobなどの非スキーマオブジェクトはダンプされません。 --blobsオプションをつけてダンプを行うことでblobも追加されます。
schemaパターンに一致するスキーマをダンプしません。 このパターンは-nと同様の規則に従って解釈されます。 -Nを複数指定して、複数のパターンのいずれかに一致するスキーマを除外することができます。
-nと-Nの両方が指定された場合、少なくとも1つの-nに一致し-Nオプションに一致しないスキーマだけがダンプされます。 -nなしで-Nが指定された場合、-Nに一致するスキーマが通常のダンプから除外されます。
各テーブルのオブジェクト識別子(OID)をデータの一部としてダンプします。 アプリケーションでOID列を(外部キー制約など)何らかの形で使用している場合は、このオプションを使用してください。 その他の場合は、このオプションは使用しないでください。
オブジェクトの所有権を元のデータベースに一致させるためのコマンドを出力しません。 デフォルトでは、pg_dumpは、ALTER OWNER文またはSET SESSION AUTHORIZATION文を発行して、作成したデータベースオブジェクトの所有権を設定します。 スーパーユーザ(もしくは、そのスクリプト内の全てのオブジェクトを所有するユーザ)以外のユーザがスクリプトを実行した場合、これらの文は失敗します。 任意のユーザがリストアできるスクリプトを作成するには、-Oを指定してください。 ただし、この場合は、全てのオブジェクトの所有者がリストアしたユーザとなってしまいます。
このオプションは平文形式の場合にのみ有効です。 アーカイブ形式では、pg_restoreを呼び出す時にこのオプションを指定することができます。
このオプションは廃止されましたが、後方互換性を保持するため受け入れられます。
データ定義(スキーマ)のみをダンプし、データはダンプしません。
このオプションは--data-onlyの逆です。 これは--section=pre-data --section=post-dataを指定することと似ていますが、歴史的な理由のため同一ではありません。
(これと--schemaオプションと混乱しないでください。"schema"という単語を異なる意味で使用しています。)
データベース内の一部のみのテーブルのテーブルデータを除外するためには--exclude-table-dataを参照してください。
トリガを無効にする場合に使用する、スーパーユーザのユーザ名を指定します。 これは--disable-triggersを使う場合にのみ使用されます。 (通常は このオプションを使うよりも、出力されたスクリプトをスーパーユーザ権限で実行する方が良いでしょう。)
tableに一致するテーブル(またはビュー、シーケンス、外部テーブル)のみをダンプします。 複数の-tオプションを記述することで複数のテーブルを選択することができます。 また、tableパラメータはpsqlの \dコマンドで使用される規則(パターン参照)と同じ規則に従うパターンとして解釈されます。 ですので、ワイルドカード文字をパターン内に記述することで、複数のテーブルを選択することもできます。 ワイルドカードを使用する時は、シェルによりそのワイルドカードを展開させないように、パターンを引用符で括ってください。 例を参照してください。
-tが使用されると、-nおよび-Nオプションの効果はなくなります。 -tで選択したテーブルが、これらのオプションとは関係なくダンプされ、また、非テーブルオブジェクトはダンプされないためです。
注意: -tが指定されると、pg_dumpは選択したテーブル内のオブジェクトが依存する可能性がある他のデータベースオブジェクトのダンプを行いません。 したがって、テーブル指定のダンプ結果を初期化されたデータベースに正常にリストアできるかどうかの保証はありません。
注意: -tオプションの動作は8.2より前のバージョンのPostgreSQLと完全な互換性はありません。 以前は、-t tabと記述することでtabという名前のテーブルをすべてダンプしていました。 しかし現在は、デフォルトの検索パスで可視のものだけがダンプされます。 過去の動作を行うためには、-t '*.tab'と記述してください。 また、特定のスキーマ内のテーブルを選択するためには、以前は-n sch -t tabと記述していましたが、-t sch.tabなどと記述しなければなりません。
tablesパターンに一致するテーブルをまったくダンプしません。 このパターンは-tと同じ規則に従って解釈されます。 -Tを複数指定することで、複数のパターンに一致するテーブルを除外させることができます。
-tと-Tの両方が指定された場合、少なくとも1つの-tオプションに一致し、-Tオプションに一致しないテーブルのみがダンプされます。 -tなしで-Tが指定された場合、通常のダンプから-Tに一致するテーブルが除外されます。
冗長モードを指定します。 これを指定すると、pg_dumpは、詳細なオブジェクトコメント、開始時刻、終了時刻をダンプファイルに、進行状況メッセージを標準エラーに出力します。
pg_dumpのバージョンを表示し、終了します。
アクセス権限(grant/revokeコマンド)のダンプを抑制します。
使用する圧縮レベルを指定します。 ゼロは圧縮無しを意味します。 カスタムアーカイブ形式では、これは個々のテーブルデータセグメントの圧縮を指定するもので、デフォルトでは中間レベルで圧縮されます。 平文出力では、非ゼロの圧縮レベルの指定によりあたかもgzipに渡されたかのように出力ファイル全体が圧縮されます。 しかしデフォルトは圧縮無しです。 tarアーカイブ形式では現在圧縮を全くサポートしていません。
このオプションは現位置でのアップグレード用のユーティリティにより使用されるものです。 他の目的での使用は推奨されませんし、サポートもされません。 このオプションの動作は、将来注意することなく変更される可能性があります。
明示的に列名を付けたINSERTコマンド(INSERT INTO table (column, ...)VALUES...)としてデータをダンプします。 これによりリストアは非常に遅くなります。 主にPostgreSQL以外のデータベースへロード可能なダンプを作成する時に有用です。 しかし、このオプションは各行に対して別々のコマンドを生成しますので、一行を再ロードする時にエラーになったとしても、テーブルの内容まるごと失われることなく、一行のみが失われるだけです。
このオプションは、関数本体用のドル引用符の使用を無効にし、強制的に標準SQLの文字列構文を使用した引用符付けを行います。
このオプションは、データのみのダンプを作成する場合にしか適用されません。 データの再ロード中に、pg_dumpに対し、対象テーブル上のトリガを一時的に無効にするコマンドを出力するよう指示します。 このオプションは、データの再ロード中には呼び出したくない参照整合性検査やその他のトリガがテーブル上にある場合に使用します。
現在のところ、--disable-triggersを指定してコマンドを実行するのは、スーパーユーザでなければなりません。 そのため、ユーザは-Sでスーパーユーザを指定するか、あるいは、十分に注意してスーパーユーザ権限でスクリプトを開始する必要があります(後者の方がより望ましい方法です)。
このオプションは平文形式の場合にのみ有効です。 他の形式では、pg_restoreを呼び出す時にこのオプションを指定することができます。
tableに一致するすべてのテーブルのデータをダンプしません。 パターンは-t用の規則と同じ規則にしたがって解釈されます。 複数のパターンのいずれかに一致するテーブルを除外することができるように、--exclude-table-dataを複数回与えることができます。 このオプションは、特定のテーブルに関してデータを格納する必要がないがテーブル定義が必要である場合に有用です。
データベース内のすべてのテーブルに関してデータを除外するためには、--schema-onlyを参照してください。
データを(COPYではなく)INSERTコマンドの形式でダンプします。 これを行うとリストアに非常に時間がかかります。 主にPostgreSQL以外のデータベースへロード可能なダンプを作成する時に有用です。 しかし、このオプションは各行に対して別々のコマンドを生成しますので、一行を再ロードする時にエラーになったとしても、テーブルの内容まるごと失われることなく、一行のみが失われるだけです。 列の順序を変更した場合はリストアが失敗する可能性があることに注意してください。 --column-insertsの方がより処理が遅くなりますが、列の順序変更に対して安全です。
ダンプの開始時に共有テーブルのロックを永遠に待ちません。 代わりに指定したtimeout内にテーブルロックを獲得できなければ失敗します。 タイムアウトにはSET statement_timeoutで受け付けられるすべての書式を指定できます。 (使用可能な値はダンプの元となるサーバのバージョンに依存して異なります。 しかし、7.3以降ではミリ秒単位の整数値を受け付けられます。 7.3より前のサーバからダンプする場合、このオプションは無視されます。)
セキュリティラベルをダンプしません。
テーブル空間を選択するコマンドを出力しません。 このオプションを使用すると、すべてのオブジェクトはリストア時のデフォルトのテーブル空間の中に作成されます。
このオプションは平文書式でのみ有意です。 アーカイブ書式では、pg_restoreを呼び出す時にこのオプションを指定することができます。
ログを取らないテーブルの内容をダンプしません。 このオプションはテーブル定義(スキーマ)をダンプするかどうかには影響しません。 そのテーブルデータのダンプを抑制するだけです。 スタンバイサーバからダンプを行う場合、ログを取らないテーブル内のデータは常に除外されます。
強制的にすべての識別子に引用符を付与します。 追加のキーワードが導入されている可能性がある将来のバージョンへの移行用にデータベースをダンプする場合に有用かもしれません。
指名した部分のみをダンプします。 部分名はpre-data、data、post-dataのいずれかを取ることができます。 複数の部分を選択するために、このオプションは複数回指定することができます。 デフォルトではすべての部分をダンプします。
data部分には、実際のテーブルデータとラージオブジェクトの中身、シーケンス値が含まれます。 Post-data項目は、インデックス定義、トリガ定義、ルール定義、有効化された検査制約以外の制約定義が含まれます。 Pre-data項目は、他のすべてのデータ定義項目が含まれます。
使用されるスナップショットがその後のデータベース状態と一貫性を持つことを保証するために、ダンプ時にserializableトランザクションを使用します。 ダンプが失敗したり、serialization_failureにより他のトランザクションがロールバックしたりする危険がないように、トランザクションストリーム内で異常が発生することがない時点まで待つことでこれを行います。 トランザクション隔離および同時実行性の制御については第13章を参照してください。
このオプションは障害対策のリカバリのみを目的とするダンプでは利点はありません。 元のデータベースを継続して更新しながら、レポート処理や他の読み取りのみの負荷分散のためにデータベースのコピーをロードするために使用されるダンプとして有用になります。 こうしないと、ダンプには 何らかのトランザクションの直列実行が結局コミットした状態と一貫性がない状態が反映される可能性があります。 例えば、バッチ処理技術が使用される場合、 バッチは、バッチ内で存在するすべての項目を持たないダンプ内でクローズしたものと表示される可能性があります。
pg_dumpを始めた時に読み書きを行うトランザクションが存在しない場合、このオプションには違いはありません。 読み書きを行うトランザクションが活動している場合、ダンプの起動が確定できない期間、遅延される可能性があります。 動き出してからの性能は、このスイッチがある場合とない場合とで違いはありません。
オブジェクトの所有権を決定するために、ALTER OWNERコマンドの代わりに標準SQLのSET SESSION AUTHORIZATIONコマンドを出力します。 これにより、ダンプの標準への互換性が高まりますが、ダンプ内のオブジェクトの履歴によっては正しくリストアされない可能性が生じます。 また、SET SESSION AUTHORIZATIONを使用したダンプを正しくリストアするためには、確実にスーパーユーザ権限が必要となります。 ALTER OWNERで必要な権限はこれよりも少なくなります。
pg_dumpのコマンドライン引数の使用方法を表示し、終了します。
以下のコマンドラインオプションは、データベース接続パラメータを制御します。
サーバが稼働しているマシンのホスト名を指定します。 この値がスラッシュから始まる場合、Unixドメインソケット用のディレクトリとして使用されます。 デフォルトは、設定されていればPGHOST環境変数から取得されます。 設定されていなければ、Unixドメインソケット接続と仮定されます。
サーバが接続を監視するTCPポートもしくはローカルUnixドメインソケットファイルの拡張子を指定します。 デフォルトは、設定されている場合、PGPORT環境変数の値となります。設定されていなければ、コンパイル時のデフォルト値となります。
接続ユーザ名です。
パスワードの入力を促しません。 サーバがパスワード認証を必要とし、かつ、.pgpassファイルなどの他の方法が利用できない場合、接続試行は失敗します。 バッチジョブやパスワードを入力するユーザが存在しない場合にこのオプションは有用かもしれません。
データベースに接続する前に、pg_dumpは強制的にパスワード入力を促します。
サーバがパスワード認証を要求する場合pg_dumpは自動的にパスワード入力を促しますので、これが重要になることはありません。 しかし、pg_dumpは、サーバにパスワードが必要かどうかを判断するための接続試行を無駄に行います。 こうした余計な接続試行を防ぐために-Wの入力が有意となる場合もあります。
ダンプを作成する際に使用するロール名を指定します。 このオプションによりpg_dumpはデータベースに接続した後にSET ROLE rolenameコマンドを発行するようになります。 認証に使用したユーザ(-Uで指定されたユーザ)がpg_dumpで必要とされる権限を持たないが、必要な権限を持つロールに切り替えることができる場合に有用です。 一部のインストレーションではスーパーユーザとして直接ログインさせないポリシーを取ることがありますが、このオプションを使用することでポリシーに反することなくダンプを作成することができます。
デフォルトの接続パラメータです。
また、このユーティリティは、他のほとんどのPostgreSQLユーティリティと同様、libpqでサポートされる環境変数を使用します(項31.14を参照してください)。
pg_dumpは内部でSELECT文を実行します。 pg_dumpの実行時に問題が発生する場合は、psqlなどを使用して、そのデータベースから情報を選択できることを確認してください。 また、libpqフロントエンドライブラリで使用されるデフォルトの接続設定や環境変数も適用されます。
通常pg_dumpのデータベースに対する活動は統計情報コレクタにより収集されます。 これを望まない場合、PGOPTIONSまたはALTER USERコマンドを使用してtrack_countsパラメータを偽に設定してください。
データベースクラスタにおいてtemplate1データベースに対し独自の変更を行っている場合、pg_dumpの出力は、確実に空のデータベースにリストアするように注意してください。 そうしないと、おそらく追加されたオブジェクトの重複定義によってエラーが発生します。 独自の追加が反映されていない空のデータベースを作成するには、template1ではなくtemplate0をコピーしてください。 以下に例を示します。
CREATE DATABASE foo WITH TEMPLATE template0;
--disable-triggersオプションを使用し、データのみのダンプを行う場合、pg_dumpはデータを挿入する前にユーザテーブルにトリガを無効にする問い合わせを発行し、データの挿入が完了した後で、それらを再び有効にする問い合わせを発行します。 リストアが途中で停止した場合、システムカタログが不適切な状態のままになっている可能性があります。
tarアーカイブのメンバのサイズは、8ギガバイト未満に制限されています (これはtarファイル形式自体が持っている制限です)。 そのため、いずれか1つのテーブルのテキスト表現がこのサイズを越える場合、この形式は使用できません。 tarアーカイブとその他の出力形式の合計サイズには制限がありません。 ただしオペレーティングシステムによる制限がある場合があります。
pg_dumpが生成するダンプファイルには、オプティマイザが問い合わせ計画を決定する際に使用される統計情報が含まれていません。 そのため、最適な性能を発揮するために、ダンプファイルからリストアした後でANALYZEを実行することをお勧めします。 詳しくは項23.1.3および項23.1.6を参照してください。 ダンプファイルはまたALTER DATABASE ... SETコマンドがまったく含まれません。 これらの設定はデータベースユーザと他のインストレーション全体の設定に従って pg_dumpallによってダンプされます。
pg_dumpは新しいバージョンのPostgreSQLへのデータ移行に使用されますので、pg_dumpの出力はpg_dumpのバージョンより新しいバージョンのPostgreSQLデータベースへロード可能と想定できるようになっています。 また、pg_dumpは自身より古いバージョンのPostgreSQLデータベースを読み取ることもできます。 (現在はバージョン7.0までのサーバをサポートします。) しかし、pg_dumpはそのメジャーバージョンより新しいPostgreSQLサーバのダンプを取ることはできません。 試そうとしても、無効なダンプが作成される危険はなく、失敗します。 また、pg_dumpの出力がメジャーバージョンが古いサーバにロードできるとは、たとえ同じバージョンのサーバから取得したダンプであっても、保証されていません。 より古いサーバへのダンプファイルのロードには、古いサーバでは理解できない構文を削除するために、ダンプファイルの手作業による修正が必要になることがあります。
mydbという名前のデータベースをSQLスクリプトファイルにダンプします。
$ pg_dump mydb > db.sql
newdbという名前の(新規に作成した)データベースにスクリプトを再ロードします。
$ psql -d newdb -f db.sql
カスタム形式のアーカイブファイルにデータベースをダンプします。
$ pg_dump -Fc mydb > db.dump
ディレクトリ形式アーカイブにデータベースをダンプします。
$ pg_dump -Fd mydb -f dumpdir
newdbという名前の(新規に作成した)データベースにアーカイブファイルを再ロードします。
$ pg_restore -d newdb db.dump
mytabという名前の単一のテーブルをダンプします。
$ pg_dump -t mytab mydb > db.sql
detroitスキーマ内のempから始まる名前のテーブルをすべてダンプします。 ただし、employee_logという名前のテーブルは除きます。
$ pg_dump -t 'detroit.emp*' -T detroit.employee_log mydb > db.sql
eastまたはwestで始まりgsmで終わるスキーマをすべてダンプします。 ただし、testという単語を含む場合は除きます。
$ pg_dump -n 'east*gsm' -n 'west*gsm' -N '*test*' mydb > db.sql
正規表現記法を使用してオプションをまとめた形で同じことを行います。
$ pg_dump -n '(east|west)*gsm' -N '*test*' mydb > db.sql
ts_から始まる名前のテーブルを除き、すべてのデータベースオブジェクトをダンプします。
$ pg_dump -T 'ts_*' mydb > db.sql
大文字または大文字小文字混在の名前を-tなどのスイッチに指定するには、名前を二重引用符で括らなければなりません。 さもないと小文字に変換されます。(パターンを参照してください。) しかし、二重引用符はシェルでも特別に扱われますので、これも引用符で括らなければなりません。 したがって、大文字小文字混在の名前を持つテーブルを1つダンプするには、以下のようにしなければなりません。
$ pg_dump -t '"MixedCaseName"' mydb > mytab.sql