WAL 二重化

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

バックアップ設定

PowerGres Plus では PowerGres Administration Tool を利用して、「新しいサーバ」を登録する際に「バックアップディレクトリ」を指定しますと、以下の設定が行われます。 「新しいサーバ」の登録方法については、PowerGres Administration Tool マニュアルの「サーバ管理」をご覧ください

backup_destination

PowerGres Administration Tool で指定した「バックアップディレクトリ」が設定されます。

二重化された WAL は「バックアップディレクトリ」内の online_wal に作成されます。

wal_level

replica が設定されます。

アーカイブされた WAL を利用した復旧を行うためには、replica または logical を設定しておく必要があります。

archive_mode

on が設定されます。

archive_command

PowerGres Administration Tool で指定した「バックアップディレクトリ」内の archive_wal が指定されます。

データベースを起動しますと、WAL の二重化と WAL のアーカイブが開始されます。

初期バックアップ

データベースサーバを作成しサーバ起動後は、pgx_dmpall を使った初期バックアップを行ってください。

PowerGres Administration Tool から実行する場合は、PowerGres Administration Tool マニュアルの「バックアップ・リストア」をご覧ください。

コマンドラインから実行する場合は、pgx_dumpall コマンドを利用します。

実行例
$ pgx_dmpall -D <データベースディレクトリ>
データベースと設定ファイルのバックアップを開始します...
パスワード:
バックアップモードを開始します...
データファイルをコピーしています...
必要なトランザクションログファイルがアーカイブされるのを待機しています...
データベースと設定ファイルのバックアップが正常に完了しました。

初期バックアップの取得までが正常に完了しますと、バックアップディレクトリ内は以下の構成となります。

archived_wal

アーカイブ済みの WAL が格納されます。

online_wal

二重化された WAL が格納されます。

conf_directory

最新の設定ファイルが保管されます。

YYYY-MM-DD_HH-MM-SS

pgx_dmpall が実行された日時で、バックアップデータが格納されます。

Backupmanage

バックアップ履歴が記録されます。

backup_destination を設定しない運用

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

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

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

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

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

リカバリ

pgx_rcvall コマンドを使うと、単一のコマンド実行でデータベース全体を簡単に復旧することができます。 pgx_rcvall は、pgx_dmpall で作成したバックアップをリストアし、バックアップ格納ディレクトリ内のアーカイブ WAL と多重化された WAL を適用することにより、データベースを最新状態に復旧できます。 また、誤ってデータを削除または更新してしまった場合にデータベースを過去のある時点に戻すこともできます。

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

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

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

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

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

  3. リカバリの実行

    PowerGres Administration Tool から実行する場合は「バックアップ・リストア」メニューの「オンラインバックアップジョブ」にバックアップの一覧が表示されますので、「リカバリ」を押下して行います。

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

    実行例
    pgx_rcvall -B <バックアップディレクトリ>

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

    PowerGres Administration Tool から実行する場合は、「サーバ」メニューよりデータベースサーバを起動し、業務を再開します。

    コマンドラインから実行する場合は、pg_ctl コマンドを使って起動してください。

    実行例
    pg_ctl -D <データベースディレクトリ>

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

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_walcopy.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_wal に保持されます。 この設定方法は、バックアップ以外のファイルを削除することでバックアップ格納ディスクの空き容量を増やせる場合に用います。

  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_wal に保持することである。

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

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

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

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

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

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

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

pgx_walcopy.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 の多重化とアーカイブを再開します。

Streaming Replication の利用

PowerGres Administration Tool から構築する場合は、「レプリケーション」メニューより構築できます。 コマンドラインで構築する場合は、以下をご参考ください。

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

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

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

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

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

    その他、wal_keep_segmentsやwal_sender_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_walcopy.cmd <バックアップ格納ディレクトリ>/archived_wal/%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 [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 オプションを使用して上書きすることができます。

注釈

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

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

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

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

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

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

例

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

$ pgx_dmpall

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 により作成します。 同じ名前を持つ複数のリストアポイントを作成した場合、バックアップ取得以降の最初のリストアポイントがリカバリに使用されます。 指定したリストアポイントが存在しない場合、すべてのアーカイブ済み WAL を適用します。 -e および -p オプションと同時に指定することはできません。

-p

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

-s connection_string

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

-x

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

--keystore-passphrase

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

環境変数
PGDATA

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

PGPORT

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

PGUSER

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

バックアップデータの情報
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_pause_wal_multiplexing() void WAL 多重化を停止する
pgx_resume_wal_multiplexing() void WAL 多重化を再開する
pgx_is_wal_multiplexing_paused() boolean WAL の多重化が停止されていれば真を返す

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

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

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