WAL 二重化に基づくバックアップ / リカバリ

WAL の二重化とは、データベースが使用している WAL と全く同じ WAL を別のディスクに出力することです。 これにより、ディスク破壊でデータベースとともに使用中の WAL が失われても、バックアップディレクトリに保管している、多重化された WAL を使用して、最新状態に復旧する事が可能となります。

セットアップの手順

データベースの作成から運用を開始するまでの手順を示します。 すでにデータベース格納ディスクとバックアップ格納ディスクは準備しているものとします。

  1. データベースクラスタの作成

    initdb を実行し、データベースクラスタを作成します。

    例:
    $ initdb -E UTF8 --locale=C

  2. バックアップ格納ディレクトリの作成

    空のバックアップ格納ディレクトリを作成します。 データベースサーバを起動するユーザのみがアクセスできるように許可を設定しておきます。

    例:
    # mkdir /backup/dir
# chown postgres:postgres /backup/dir
# chmod 700 /backup/dir

  3. postgresql.conf の編集

    WAL の 二重化およびバックアップ / リカバリのために以下のパラメータを設定します。

    backup_destination

    バックアップ格納ディレクトリを指定します。 バックアップは必ずデータベース格納ディスクとは別ディスクとする必要があります。 また、この backup_destination を設定するには、WAL アーカイブが有効であることが必須です。

    例 (Linux):
    backup_destination = '/backup/dir'
    例 (Windows):
    backup_destination = 'd:\\backup\\dir'
    wal_level

    archive または hot_standby を指定します。

    archive_mode

    on を指定します。

    archive_command

    使用済み WAL の保管用コマンドを設定します。 保管用のコマンドには pgx_xlogcopy.cmd を使用します。 使用済み WAL ファイルの出力先は「backup_destination に指定したディレクトリ/archived_xlog/%f」に設定する必要があります。 以下に設定例を記述します。

    例 (Linux):
    archive_command = '<インストール・ディレクトリ>/bin/pgx_xlogcopy.cmd "%p" "/backup/dir/archived_xlog/%f"'
    例 (Windows):
    archive_command = '"<インストール・ディレクトリ>\\bin\\pgx_xlogcopy.cmd" "%p" "d:\\backup\\dir\\archived_xlog\\%f"'

    注意: コピー先に同一のファイル名が存在していた場合、pgx_xlogcopy.cmd は上書きを行います。

  4. データベースサーバの起動

    データベースサーバを起動します。

    例:
    $ pg_ctl -D /data/dir start

    もし存在しない場合、以下のディレクトリがバックアップ格納ディレクトリ内に自動的に作成されます。

    archived_xlog: アーカイブ済み WAL を格納するディレクトリ
    online_xlog: 多重化された WAL を格納するディレクトリ

  5. 初期バックアップの取得

    データベースサーバの起動後にバックアップを取得します。 バックアップの取得には必ず pgx_dmpall を使用します。 pgx_dmpall を使用すると、バックアップ格納ディレクトリ内に必要なディレクトリ、およびファイルがすべて自動的に作成されます。

    バックアップの取得が正常にできたら、セットアップが完了して運用を開始できる状態になったとみなします。

    例:
    $ pgx_dmpall -D /data/dir

メディアリカバリ

pgx_rcvall コマンドを使うと、単一のコマンドの実行でデータベース全体を簡単に復旧することができます。 pgx_rcvall は、pgx_dmpall で作成したバックアップをリストアし、それからバックアップ格納ディレクトリ内のアーカイブ WAL と多重化された WAL を適用することにより、メディアリカバリを実行します。

データベース格納ディスクが故障した場合にデータベースを最新状態に復旧するためにも、誤ってデータを削除または更新してしまった場合にデータベースを過去の時点に戻すためにも、pgx_rcvall を用いることができます。

以下に復旧手順を示します。

  1. データベース格納ディスクの交換

    もし故障した場合には、データベース格納ディスクを交換します。

  2. リストア先ディレクトリを配置するファイルシステムの準備

    pgx_rcvall は、バックアップをリストアするディレクトリを自動的に作成します。 PostgreSQL ユーザが必要なディレクトリを作成できるようにするため、それらのディレクトリを配置するファイルシステムをあらかじめマウントし、適切な権限を設定しておきます。 PostgreSQL ユーザとは、pgx_rcvall を実行したり、データベースサーバを起動するユーザのことです。

  3. リカバリの実行

    pgx_rcvall コマンドを実行してメディアリカバリを行います。 まず、pgx_rcvall はバックアップからデータファイルをリストアします。 次に、pgx_rcvall はデータベースサーバを起動してメディアリカバリを実行します。 最後に、pgx_rcvall はデータベースサーバを停止します。

    例:
    $ pgx_rcvall -B /backup/dir

  4. データベースサーバの起動

    データベースサーバを起動し、業務を再開します。

    例:
    $ pg_ctl -D /data/dir start

WAL のエラー発生時の動作とその復旧手順

WAL および多重化された WAL にてエラーが発生した場合、データベースは下記に示した状態となります。 管理者は、それぞれの復旧手順に従って、データベースを復旧させる必要があります。

エラー発生箇所 データベースの動作 復旧手順
WAL DB は停止する。 (異常終了) データベース格納ディスクの復旧を行う。
多重化された WAL 設定に従い、DB は稼働を継続するか停止する。 バックアップ先ディスクの復旧を行う。

WAL への書き込みが失敗した場合

WAL でエラーが検出された場合、データディレクトリが破壊されていると判断して、データベースは停止します。 ユーザはデータベース格納ディスクが破壊された場合の対処に従って復旧処理を行います。

多重化された WAL への書き込みが失敗した場合

バックアップ格納ディスクが故障したり、空き容量が不足すると、多重化された WAL への書き込みが失敗します。 そのときのデータベースサーバの振る舞いと復旧方法を示します。

データベースサーバの振る舞い

postgresql.conf のパラメータ exit_on_wal_multiplexing_error が false に設定されている場合、データベースサーバは多重化された WAL への書き込みを停止して稼働を継続します。 引き続き更新トランザクションは実行可能です。 この設定は可用性を重視する場合に用います。 以降に生成された WAL がバックアップ格納ディレクトリに保存されないため、バックアップから最新状態へリカバリすることはできません。 これがデフォルトの振る舞いです。

WAL の多重化が停止されているかどうかは、次のように SQL 関数を実行することで知ることができます。

postgres=# SELECT pgx_is_wal_multiplexing_paused();
 pgx_is_wal_multiplexing_paused
--------------------------------
 t
(1 row)

パラメータ exit_on_wal_multiplexing_error が true に設定されている場合、データベースサーバは停止します。 これは、バックアップ格納ディレクトリを復旧してデータベースサーバを再起動するまで、保存されない WAL の生成を防止するためです。 この設定はデータ保護を重視する場合に用います。

多重化 WAL への書き込み失敗時にデータベースサーバを継続して稼働させた場合の復旧

以下に、WAL のアーカイブに失敗したときに、手動で WAL アーカイブを停止・再開する場合の流れを示します。 代わりに、pgx_xlogcopy.cmd の機能により、自動的に WAL アーカイブを停止・再開させることもできます。 それについては後続の WAL アーカイブの自動的な停止と再開 を参照してください。

  1. WAL アーカイブの停止

    バックアップ格納ディレクトリへの WAL のアーカイブを停止するために、postgresql.conf のパラメータ archive_command を変更し、設定ファイルを再読み込みします。 設定ファイルを再読み込みするには pg_ctl reload コマンド、または SQL 関数 pg_reload_conf を実行します。

    archive_command の設定のしかたには 2 通りあります。 1 つは、echo skipped archiving WAL file %f や /bin/true などを指定します。 echo で出力したメッセージは PostgreSQL のサーバログファイルに書き出されるため、何らかの調査に役立つ可能性があります。 このように設定すると、WAL はアーカイブされたものとして破棄されます。 この設定方法は、バックアップ格納ディスクの故障と空き領域不足の両方の場合に用いることができます。

    もう 1 つの方法は、archive_command に空文字列 ('') を設定することです。 この場合、WAL はアーカイブされるまで $PGDATA/pg_xlog に保持されます。 この設定方法は、バックアップ以外のファイルを削除することでバックアップ格納ディスクの空き容量を増やせる場合に用います。

  2. バックアップ格納ディスクの交換とディレクトリの作成

    バックアップ格納ディスクが故障した場合は、ディスクを取り替えて、バックアップ格納ディレクトリを作成します。 バックアップ格納ディスクの空き容量が不足した場合は、バックアップ格納ディレクトリ以外の不要なファイルを削除するか、バックアップ格納ディレクトリを空にします (削除して再作成してもよいです)。 この時ディレクトリの権限を PostgreSQL 管理者権限 (Linux では 700) に変更する必要があります。

  3. WAL アーカイブの再開

    archive_command の設定を元に戻し、設定ファイルを再読み込みします。

  4. WAL 多重化の再開

    SQL 関数 pgx_resume_wal_multiplexing を実行します。

    例:
    SELECT pgx_resume_wal_multiplexing()

    このとき、バックアップ格納ディレクトリには必要なディレクトリが作成されます。 (作成されるディレクトリについては サーバ起動時に自動的に作成されるディレクトリ を参照してください)

  5. バックアップの取得

    バックアップを取得します。 バックアップが正常に取得できた時点で、運用を再開させます。

WAL アーカイブの自動的な停止と再開

バックアップ格納ディスクの故障や空き容量不足など、何らかの理由で WAL のアーカイブに失敗したときに、自動的に WAL アーカイブを停止させることができる。 ここでいう停止とは、再び WAL ファイルをアーカイブできるようになるまで、WAL ファイルを破棄するか $PGDATA/pg_xlog に保持することである。

WALのアーカイブに失敗した場合の動作は、pgx_xlogcopy.cmd の第 3 パラメータで指定します。 破棄する場合には discard を、保持する場合には keep を指定します。

また、第 4 パラメータには通知ファイルのパスを指定します。 WAL アーカイブに失敗した場合、指定された動作 (discard または keep) がこの通知ファイルに書き出されます。 通知ファイルの内容はこの 1 行のみです (将来、2 行目以降に情報が追加される可能性があることに注意してください)。 外部の監視ツールは通知ファイルの有無と内容を調べることで、アーカイブ WAL の一部が失われたこと、つまり、バックアップから最新状態にリカバリできなくなったことを知ることができます。

例: WAL のアーカイブに失敗した場合に WAL ファイルを破棄し、そのことを通知ファイル /tmp/waldiscard.txt に書き出す。
archive_command = '<インストール・ディレクトリ>/bin/pgx_xlogcopy.cmd "%p" "/backup/dir/archived_xlog/%f" discard /tmp/waldiscard.txt'
注釈

discard と keep のいずれが指定された場合も、WAL ファイルのアーカイブはアーカイブ失敗後も継続して試みられます。 具体的には、新しい WAL セグメントが一杯になるか、または 1 分おきに archive_command が呼び出され、ファイルのコピーが施行されます。 そのため、アーカイブ処理の失敗を示すメッセージがサーバログファイルや syslog などに出力されます。

discard が指定された場合、pgx_xlogcopy.cmd はアーカイブ処理が失敗しても、成功したものとして正常に復帰します。 その結果、WAL が破棄されるため、$PGDATA/pg_xlog が膨張し続けるのを防げます。

keep が指定された場合、pgx_xlogcopy.cmd は異常復帰します。 その結果、アーカイブに失敗した WAL セグメントは $PGDATA/pg_xlog に蓄積されていきます。 これらの蓄積された WAL セグメントは、アーカイブ先が正常に戻ると自動的にアーカイブされ、チェックポイント時に $PGDATA/pg_xlog から削除されます。

ディスク交換や空き容量の確保によりバックアップ格納ディレクトリが正常な状態に戻ると、次回の WAL アーカイブが成功します。 このとき、keep の場合、通知ファイルは削除されます。 discard の場合、一部の WAL が失われたことを示すために、通知ファイルは残されます。 そのため、利用者はアーカイブ先の復旧後に通知ファイルを削除する必要があります。

pgx_xlogcopy.cmd の第 3 パラメータ以降を省略した場合、keep と同じく、アーカイブに失敗した WAL セグメントを保持します。 通知ファイルは作成されません。

多重化 WAL への書き込み失敗時にデータベースサーバを停止させた場合の復旧

  1. バックアップ格納ディスクの交換とディレクトリの作成

    バックアップ格納ディスクが故障した場合は、ディスクを取り替えて、バックアップ格納ディレクトリを作成します。 バックアップ格納ディスクの空き容量が不足した場合は、バックアップ格納ディレクトリ以外の不要なファイルを削除するか、バックアップ格納ディレクトリを空にします (削除して再作成してもよいです)。 この時ディレクトリの権限を PostgreSQL 管理者権限 (Linux では 700) に変更する必要があります。

  2. データベースサーバの起動

    データベースサーバを起動します。 バックアップ格納ディレクトリには、必要なディレクトリが自動で作成されます。 (作成されるディレクトリについては サーバ起動時に自動的に作成されるディレクトリ を参照してください)

  3. バックアップの取得

    データベースサーバが起動したら、バックアップを取得します。 バックアップが正常に取得できた時点で、運用を再開させます。

データベースサーバの停止後に即座に運用を再開させるには

データベースサーバが停止した後に、バックアップ格納ディレクトリを復旧せずに即座に運用を再開させることもできます。 それには 2 つの方法があります。

1 つは、backup_destination をコメント化し、かつ、WAL アーカイブを無効にしてデータベースサーバを起動します。 この方法では、復旧後にバックアップを取得できるよう backup_destination を再設定するために、データベースサーバを再起動する必要があります。

もう 1 つの方法は、WAL 多重化を無効にするために exit_on_wal_multiplexing_error を true に設定します。 また、WAL アーカイブを無効にしておきます。 バックアップ格納ディスクの復旧後は、多重化 WAL への書き込み失敗時にデータベースサーバを継続して稼働させた場合の復旧 と同じように、WAL の多重化とアーカイブを再開します。

backup_destination を設定しない運用

backup_destination を設定せずに運用した場合 (片肺運用) の振る舞いについて記述します。

データベースサーバの起動

データベースサーバの起動は正常に行われます。

バックアップコマンド (pgx_dmpall) の実行

backup_destination が設定されていない状態で、バックアップコマンド (pgx_dmpall) が実行された場合は、backup_destination が設定されていない旨のメッセージを出力し、コマンドの異常終了とします。

ストリーミングレプリケーション使用時の使い方

プライマリサーバでのストリーミングレプリケーションの準備

純正 PostgreSQL と特に変わりありません。

  1. スタンバイサーバからのレプリケーション接続を受け付けるようにプライマリサーバで認証を設定します。 つまり、レプリケーション用のユーザを作成し、そのユーザからのレプリケーション接続を受け付けるように pg_hba.conf を設定します。

  2. postgresql.conf に次のパラメータを設定します。

    synchronous_standby_names = '...' (同期レプリケーションを使う場合)
hot_standby = on (ホット・スタンバイを使う場合)

    その他、wal_keep_segments や replication_timeout など

  3. 変更した設定ファイルをバックアップするために pgx_dmpall -c を実行します。

スタンバイサーバの追加

下記のように、純正 PostgreSQL と同じ方法でスタンバイ・サーバを追加できる。

  1. プライマリサーバと既存のスタンバイサーバの postgresql.conf で、max_wal_senders と max_connections に 1 を追加します。

  2. 次の方法でプライマリサーバからスタンバイサーバを作成します。

    スタンバイサーバで pg_basebackup を実行します。 そして、空のバックアップ格納ディレクトリを作成します。

  3. スタンバイサーバの recovery.conf に次のパラメータを設定します。

    standby_mode = 'on'
primary_conninfo = 'host=PRIMARY_HOST port=primary_port user=<レプリケーション用ユーザ名> password=<レプリケーション用ユーザのパスワード> application_name=<スタンバイサーバ名>'
restore_command = '<インストール・ディレクトリ>/bin/pgx_xlogcopy.cmd <バックアップ格納ディレクトリ>/archived_xlog/%f %p'
recovery_target_timeline = 'LATEST'

  4. スタンバイサーバを起動するために pg_ctl start を実行します。

上記のように pg_basebackup を用いる方法は、プライマリサーバでのデータファイルの読み込みやスタンバイサーバへのデータ転送、バックアップ・モード中の WAL の増加などにより、プライマリサーバに大きな負荷を与えます。

この負荷を軽減するために、すでに取得してあるバックアップからスタンバイサーバを構築することができます。 具体的には、スタンバイサーバからバックアップにアクセスできるようにしておきます。 たとえば、SAN や NAS 上のディスクにバックアップ格納ディレクトリを配置します。 両方のサーバから同時にバックアップ格納ディレクトリにアクセスできるようにするために、NFS や CIFS などのネットワーク・ファイルシステムや、OCFS2 や Red Hat GFS2 などのクラスタ・ファイルシステムを用います。 そして、そのバックアップを用いて pgx_rcvall でスタンバイサーバを作成します。

スタンバイサーバを追加する方法は次のようになります。

  1. プライマリサーバと既存のスタンバイサーバの postgresql.conf で、max_wal_senders と max_connections に 1 を追加します。

  2. 次の方法でバックアップからスタンバイサーバを作成します。

    スタンバイサーバで pgx_rcvall を実行します。 このとき、プライマリサーバに接続するための接続文字列を指定します。 これは recovery.conf の primary_conninfo パラメータに指定するものと同じです。

    $ pgx_rcvall -B バックアップ格納ディレクトリ -s "host=PRIMARY_HOST port=primary_port user=<レプリケーション用ユーザ名> password=<レプリケーション用ユーザのパスワード> application_name=<スタンバイサーバ名>"

    pgx_rcvall はスタンバイサーバ上にバックアップをリストアします。 それから、pgx_rcvall は自動的に、データディレクトリにスタンバイサーバ用の recovery.conf を作成します。 その内容は次のパラメータ指定を含みます。

    primary_conninfo = 'pgx_rcvall に指定した接続文字列'
standby_mode = 'on'
restore_command = 'アーカイブ WAL をリストアするためのコマンド文字列'
recovery_target_timeline = 'latest'

  3. 必要に応じて、スタンバイサーバの recovery.conf にその他のパラメータを設定します。

  4. スタンバイサーバを起動するために pg_ctl start を実行します。

フェイルオーバと計画切り替え、旧プライマリの組み込み

純正 PostgreSQL と同じく、pg_ctl promote を実行します。 旧プライマリ・インスタンスをスタンバイとして組み込むには、純正 PostgreSQL と同様に recovery.conf を作成してインスタンスを起動するのみです。

バックアップ / リカバリ

ストリーミングレプリケーションの有無でバックアップ/リカバリの方法に違いはありません。 ただし、スタンバイサーバではバックアップを実行できません。 これは純正 PostgreSQL と同じです。

リファレンス

実行時パラメータ

backup_destination (string)

pgx_dmpall がバックアップデータを格納するディレクトリを絶対パスで指定します。 他のデータベースクラスタとは異なる場所を指定してください。 このパラメータはサーバ起動時のみ設定可能です。

このディレクトリは、バックアップするデータディレクトリやテーブル空間ディレクトリとは異なるディスク上に配置してください。 このディレクトリの内容はデータベースシステムが管理するため、利用者は任意のファイルを格納しないように注意してください。

exit_on_wal_multiplexing_error (boolean)

多重化された WAL への書き込みが失敗したときにデータベースサーバを停止するかどうかを指定します。 true を指定した場合はデータベースサーバが停止します。 false を指定した場合、多重化 WAL への書き込みを停止し、データベースサーバの稼働を継続します。 この場合、更新トランザクションは引き続き実行可能です。 デフォルトは false です。

このパラメータはサーバ起動時のみ設定可能です。

サーバアプリケーション

pgx_dmpall

名前

pgx_dmpall – データディレクトリ、テーブル空間および設定ファイルのバックアップ

概要
pgx_dmpall [option...]
説明

データディレクトリ、テーブル空間、および設定ファイルをバックアップします。 バックアップデータの格納先は、postgresql.conf の backup_destination パラメータで指定したバックアップ格納ディレクトリです。 また、バックアップの正常終了時に不要なアーカイブ済み WAL を削除します。

オプション
-c

設定ファイルのみをバックアップします。 設定ファイルは以下の 3 ファイルです。

  • postgresql.conf ファイル (postgresql.conf)
  • ホストベース認証用ファイル (pg_hba.conf)
  • ident 認証用設定ファイル (pg_ident.conf)

なお、postgresql.conf の include など、外部参照が設定されている場合は、参照先のファイルもバックアップします。

-C fast|spread
--checkpoint=fast|spread

チェックポイントを fast または spread (デフォルト) に設定します。 fast を指定すると、バックアップ開始時のチェックポイント処理は高速になりますが、集中した I/O のために動作中のアプリケーションへの性能の影響が大きくなります。 spread ではチェックポイントはゆっくり実行されるためアプリケーションへの影響は小さいですが、バックアップに時間がかかります。

-D datadir

データディレクトリを指定します。 省略時は、環境変数 PGDATA が有効となります。

-f config_file

設定ファイル postgresql.conf を指定します。 postgresql.conf ファイルの data_directory パラメータに設定したデータディレクトリと設定ファイルを、異なるディレクトリで運用している場合に設定します。

-U username
--username=username

データベースのスーパーユーザのユーザ名を指定します。 このコマンドを実行している実効ユーザの名前がデフォルトです。

-w
--no-password

パスワードの入力を促しません。 サーバがパスワード認証を必要とし、かつ、.pgpass ファイルなどの他の方法が利用できない場合、接続試行は失敗します。 バッチジョブやパスワードを入力するユーザが存在しない場合にこのオプションは有用かもしれません。

-W
--password

データベースに接続する前に、pgx_dmpall は強制的にパスワード入力を促します。

サーバがパスワード認証を要求する場合 pgx_dmpall は自動的にパスワード入力を促しますので、これが重要になることはありません。 しかし、pgx_dmpall は、サーバにパスワードが必要かどうかを判断するための接続試行を無駄に行います。 こうした余計な接続試行を防ぐために -W の入力が有意となる場合もあります。

--maintenance-db=dbname

接続先となるデータベースの名前を指定します。 指定がなければ、postgres データベースが使用されます。 もし存在しなければ template1 が使用されます。

環境
PGDATA

データディレクトリを指定します。 -D オプションを使用して上書きすることができます。

診断
0: 正常終了
0 以外: 異常終了
注釈

このコマンドは、データベースサーバの稼働中にのみ実行できます。

このコマンドは、PostgreSQL ユーザアカウントで実行してください。

バックアップ格納ディレクトリ内のファイルを更新、および削除しないでください。 データディレクトリを復旧できなくなる可能性があります。

バックアップ格納ディレクトリには、ほかのファイルを格納しないでください。

このコマンドはデータベースに接続するため、接続を 1 つ使用します。 接続を確立するために、Windows では IPv4 のループバック・アドレス 127.0.0.1 を、それ以外の OS では UNIX ドメイン・ソケットを使用します。 そのため、pg_hba.conf ファイルでこれらの接続を許可してください。

このコマンドはスタンバイサーバでは実行できません。

例

以下は、データディレクトリ、テーブル空間および設定ファイルをバックアップする例です。 このとき、バックアップにより不要になったアーカイブ済み WAL も破棄されます。

$ pgx_dmpall
関連項目

pgx_rcvall

pgx_rcvall

名前

pgx_rcvall – データディレクトリ、テーブル空間および設定ファイルのリカバリ

概要
pgx_rcvall [option...]
説明

pgx_dmpall コマンドでバックアップしたデータとアーカイブ済み WAL を使用して、データディレクトリ、テーブル空間および設定ファイルをリカバリします。 復旧時点を示すオプションのいずれも指定しない場合、すべてのアーカイブ済み WAL を適用して、最新状態にデータをリカバリします。

オプション
-B backupdir

バックアップ格納ディレクトリを指定します。 データディレクトリが破壊されている場合、本オプションを省略することはできません。

-D datadir

データディレクトリを指定します。 省略時は、環境変数 PGDATA が有効となります。

-e target_time [-x]

復旧時点を指定してリカバリする場合に指定します。 本オプションを省略すると、最新の状態にリカバリされます。 -p および -n オプションと同時に指定することはできません。

target_time

データを復旧する日時を指定します。 指定形式は以下のとおりです。

'YYYY-MM-DD HH:MM:SS'
-l

pgx_dmpall コマンドで取得したバックアップ格納ディレクトリ内のバックアップデータの情報を一覧で表示します。 -p、-e または -n オプションと同時に指定することはできません。

-n restore_point

データディレクトリ、テーブル空間、および設定ファイルを、指定したリストアポイントの時点にリカバリする場合に指定します。 リストアポイントは SQL 関数 pg_create_restore_point により作成します。 同じ名前を持つ複数のリストアポイントを作成した場合、バックアップ取得以降の最初のリストアポイントがリカバリに使用されます。 -e および -p オプションと同時に指定することはできません。

-p

データディレクトリ、テーブル空間、および設定ファイルをバックアップ時点にリカバリする場合に指定します。 -e および -n オプションと同時に指定することはできません。

-s connection_string

pgx_dmpall で作成したバックアップからスタンバイサーバを構築します。 引数として、プライマリサーバに接続するための接続文字列を指定します。 これは recovery.conf の primary_conninfo パラメータに指定するものと同じです。 -D または -B 以外のオプションと同時に指定することはできません。

-x

-e オプションに指定した時刻にコミットしたトランザクションをリカバリに含めない場合に指定します。

--keystore-passphrase

キーストアをオープンするためのパスフレーズの入力を促します。

環境
PGDATA

データディレクトリを指定します。 -D オプションを使用して上書きすることができます。

PGPORT

データベースへ接続するためのポート番号を指定します。

PGUSER

データベースのスーパーユーザのユーザ名を指定します。 このコマンドを実行している実効ユーザの名前がデフォルトです。

診断
0: 正常終了
0 以外: 異常終了
バックアップデータの情報
Date

pgx_dmpall コマンドによりバックアップデータを作成した年月日

Dir

バックアップデータが格納されている、バックアップ格納ディレクトリ内のディレクトリ名

ディレクトリの命名形式: 日時形式 (YYYY-MM-DD_HH-MM-SS)

Status

pgx_dmpall コマンドで取得したバックアップデータの状態

COMPLETE: 完了
INCOMPLETE: 未完了
注釈

このコマンドは、-l オプション指定での実行以外は、データベースサーバの停止時にのみ実行できます。

このコマンドは、PostgreSQL ユーザアカウントで実行してください。

リカバリに使用するバックアップデータは、リカバリの対象となるデータディレクトリから取得したものを使用してください。

このコマンドを実行する前に、データベースへ接続を行うすべてのアプリケーションを切断してください。 また、リカバリ実行中はデータベースへの接続は行わないようにしてください。

このコマンドでは、ハッシュインデックスを正しく復旧できません。 ハッシュインデックスを使用している場合は、このコマンド終了後に該当するインデックスに対して、REINDEX を実行してください。

設定ファイルは、pgx_dmpall コマンド (-c オプションを含む) で、最後に取得した設定ファイルの状態に復旧されます。

このコマンドでは、リカバリの終了判定の際に、データベースへ接続します。 このため、複数のインスタンスが存在する環境では、リカバリ対象のインスタンスに接続するよう、環境変数 PGPORT でポート番号を設定してください。

pgx_rcvall と pgx_dmpall を実行するときの OS の時間帯設定を、postgresql.conf の timezone パラメータで指定されている時間帯に一致させるようにしてください。 さもないと、-e または -p オプションを指定した場合に、データが意図しない時刻に復旧されてしまうことがあります。

過去の時点に復旧した場合、その復旧時点を起点とする新たな時系列 (データベース更新の歴史) が始まります。 リカバリが完了したときには、その復旧時点が新たな時系列における最新地点です。 以後、最新状態にリカバリする場合には、この新たな時系列上のデータベース更新が再実行されます。

有効なリストアポイントは、バックアップを取得した時系列上で作成したものです。 つまり、過去の時点に復旧した場合、以降に設定したリストアポイントは利用できません。 したがって、望みの過去データを復元できたら、バックアップを取得してください。

例

以下は、データディレクトリ、テーブル空間、および設定ファイルを復旧する例です。

$ pgx_rcvall -B /home/pgsql/Backupdir

以下は、2007 年 3 月 20 日 10 時 0 分 0 秒の時点にデータディレクトリ、およびテーブル空間を復旧する例です。 設定ファイルは、最後に取得した時点に復旧されます。

$ pgx_rcvall -B /home/pgsql/Backupdir -e '2007-03-20 10:00:00'

以下は、リストアポイント before_match_20120705_1 の時点にデータディレクトリ、およびテーブル空間を復旧する例です。 設定ファイルは、最後に取得した時点に復旧されます。

$ pgx_rcvall -B /home/pgsql/Backupdir -n before_match_20120705_1

以下は、バックアップ格納ディレクトリに取得されているバックアップデータの情報を一覧で表示させる例です。

$ pgx_rcvall -l
関連項目

pgx_dmpall

システム管理関数

名前 戻り型 説明
pgx_pause_wal_multiplexing() void WAL 多重化を停止する
pgx_resume_wal_multiplexing() void WAL 多重化を再開する
pgx_is_wal_multiplexing_paused() boolean WAL の多重化が停止されていれば真を返す

WAL の多重化が構成されていない場合、これらの関数はエラーを報告します。 postgresql.conf の backup_destination パラメータを設定すると、WAL の多重化が構成されます。

ストリーミングレプリケーションのスタンバイサーバでは、これらの関数を実行できません。

スーパーユーザのみがこれらの関数を実行可能です。