PostgreSQLのバックアップ操作およびリストア操作についてまとめます。このページでは「オンライン物理バックアップ」の操作を説明します。オンライン物理バックアップはバックアップ取得時点だけでなく障害直前までのリストアが可能です。任意の時点への戻しが可能であるため、PITR(Point In Time Recovery)とも呼ばれます。
比較的低難度の「論理バックアップ」「オフライン物理バックアップ」についてはPostgreSQL バックアップとリストアを参照ください。
- PostgreSQL インストール
- PostgreSQL データベースの作成
- PostgreSQL contribモジュールの使い方
- PostgreSQL パラメタの設定方法
- PostgreSQL ベンチマークツールの紹介
- PostgreSQL WAL(Write Ahead Log)の基本説明
- PostgreSQL バックアップとリストア
- PostgreSQL PITR(Point In Time Recovery)基本概念の説明 (いまここ)
- PostgreSQL PITR(Point In Time Recovery)操作方法の説明
- PostgreSQL PITR(Point In Time Recovery)タイムライン操作
- PostgreSQL ストリーミングレプリケーションの最小構成
- PostgreSQL ストリーミングレプリケーションのパラメタ説明
- PostgreSQL ストリーミングレプリケーションの障害復旧
- PostgreSQL ストリーミングレプリケーションの多段構成
- PostgreSQL ストリーミングレプリケーションのDR向け設定
- PostgreSQL ストリーミングレプリケーションのコンフリクト
- PostgreSQL 自動バキューム(AUTO VACUUM)
- PostgreSQL HOT(Heap Only Tuple)
- PostgreSQL インデックスのメンテナンス
- PostgreSQL 統計情報の更新
- PostgreSQL 実行計画
- PostgreSQL スロークエリの調査方法
バックアップ操作概要
PostgreSQLのバックアップ操作は、「論理バックアップ」「オフライン物理バックアップ」「オンライン物理バックアップ」の3つがあります。
バックアップ操作 | 停止要否 | 復旧時点 |
---|---|---|
論理バックアップ | 稼働中 | バックアップ時点 |
オフライン物理バックアップ | 停止中 | バックアップ時点 |
オンライン物理バックアップ | 稼働中 | バックアップ時点から障害発生直前まで |
事前準備 アーカイブの出力
アーカイブの出力先としてNFSサーバを構築し、そこにWAL出力先用途のディレクトリを作成します。
NFSサーバの構築方法については説明を省略します。
mkdir -p /nfs/postgres/wal chown -R postgres:postgres /nfs/postgres
postgresql.confを以下のように編集します。
# vi /var/lib/pgsql/13/data/postgresql.conf <omitted> archive_mode = on archive_command = 'cp -p %p /nfs/postgres/wal/%f' archive_timeout = 60
設定を反映させます。
systemctl restart postgresql-13.service
バックアップの取得
pg_start_backup
PITRを実行するには、まずstart_backup()を実行し、バックアップを取得した時の整合性を保つような処理を実施します。pg_start_backup()実行時に行われる処理は以下の通りです。
実践でpg_start_backupを使う事は少ないでしょう。ここでは仕様理解のために敢えてpg_start_backup()を使います。pg_start_backup(), バックアップ処理, pg_stop_backup()の一連の操作を行うpg_backbackupという便利なコマンドもあります。
- 共有メモリ上のステータスを「バックアップ中」にする
- WALをスイッチする
- チェックポイントを発行し、その位置(LSN:Log Sequence Number)を保持する
- LSNを元にWALファイルを特定し、その情報をbackup_labelに書き出す
- LSNを返却する
pg_start_backup()を実行してみます。pg_start_backup()は引数にラベル名を指定します。ラベル名は任意の名前で差し支えございませんが、何か分かりやすい名前をつけておくと運用しやすいでしょう。
以下はpg_start_backup()の実行例です。実運用では不要ですが、仕様理解のためにWALがスイッチしている事を確かめられるよう、pg_start_backup()前後でWALの位置を確かめる処理を実行しています。
[postgres@centos10 ~]$ psql << EOF > \x > SELECT pg_walfile_name(pg_current_wal_lsn()); > SELECT pg_start_backup('test_backup01'); > SELECT pg_walfile_name(pg_current_wal_lsn()); > EOF Expanded display is on. -[ RECORD 1 ]---+------------------------- pg_walfile_name | 000000010000000000000002 -[ RECORD 1 ]---+---------- pg_start_backup | 0/3000028 -[ RECORD 1 ]---+------------------------- pg_walfile_name | 000000010000000000000003 [postgres@centos10 ~]$
pg_start_backup()を実行すると、ステータスが「バックアップ中」となり、backup_labelというファイルが作成れます。backup_labelにはLSNやラベル名が含まれています。
[postgres@centos10 ~]$ cat 13/data/backup_label START WAL LOCATION: 0/3000028 (file 000000010000000000000003) CHECKPOINT LOCATION: 0/3000060 BACKUP METHOD: pg_start_backup BACKUP FROM: master START TIME: 2020-12-21 11:57:52 JST LABEL: test_backup01 START TIMELINE: 1
ステータスが「バックアップ中」の時はバックアップが排他的な状態になっており、二重ではバックアップを取得できないようになっています。試しにpg_start_backup()を実行すると、エラーを返されるのが分かります。
[postgres@centos10 ~]$ psql -c "SELECT pg_start_backup('test_backup02');" ERROR: すでにバックアップが進行中です HINT: pg_stop_backup()を実行後に再試行してください [postgres@centos10 ~]$
バックアップの取得
バックアップを取得し、NFSのような共有領域へコピーします。操作例は以下の通りです。
WALやpidファイルなど一部バックアップに不要なファイル群をコピー対象外にしている事に留意ください。
mkdir /nfs/postgres/backup chown postgres:postgres /nfs/postgres/backup rsync -av --delete \ --exclude=pg_wal/* \ --exclude=postmaster.pid \ /var/lib/pgsql/13/data/* /nfs/postgres/backup <h3>pg_stop_backup</h3> バックアップが完了したらpg_stop_backup()を実行します。pg_stop_backup()実行時に行われる処理は以下の通りです。 <ul> <li>共有メモリ上のステータスを元に戻す</li> <li>backup_labelを読み込み、開始位置(LSN:Log Sequence Number)を取得する</li> <li>LSNをWALレコードに書き出す</li> <li>WALをスイッチする</li> <li>WALの履歴を書き出す</li> <li>アーカイビングが出力されるのを待つ</li> </ul> 以下はpg_stop_backup()の実行例です。実運用では不要ですが、仕様理解のためにWALがスイッチしている事を確かめられるよう、pg_stop_backup()前後でWALの位置を確かめる処理を実行しています。 [postgres@centos10 ~]$ psql << EOF > \x > SELECT pg_walfile_name(pg_current_wal_lsn()); > SELECT pg_stop_backup(); > SELECT pg_walfile_name(pg_current_wal_lsn()); > EOF Expanded display is on. -[ RECORD 1 ]---+------------------------- pg_walfile_name | 000000010000000000000003 NOTICE: 必要なすべての WAL セグメントがアーカイブされました -[ RECORD 1 ]--+---------- pg_stop_backup | 0/4000050 -[ RECORD 1 ]---+------------------------- pg_walfile_name | 000000010000000000000005 [postgres@centos10 ~]$
バックアップが完了すると、backup_labelファイルが削除され、pg_wal配下に.backupというファイルが作成されます。この.backupファイルにはラベル名やLSNが含まれています。PITRを使用する場合は、このLSN以降のアーカイビングを適用する事によって、任意の時刻までの復旧が可能になります。
[postgres@centos10 ~]$ cat 13/data/backup_label cat: 13/data/backup_label: No such file or directory [postgres@centos10 ~]$ ls -l 13/data/backup_label ls: cannot access '13/data/backup_label': No such file or directory [postgres@centos10 ~]$ [postgres@centos10 ~]$ [postgres@centos10 ~]$ ls -l 13/data/pg_wal/ total 49156 -rw-------. 1 postgres postgres 16777216 Dec 21 11:58 000000010000000000000003 -rw-------. 1 postgres postgres 332 Dec 21 12:12 000000010000000000000003.00000028.backup -rw-------. 1 postgres postgres 16777216 Dec 21 12:12 000000010000000000000004 -rw-------. 1 postgres postgres 16777216 Dec 21 12:12 000000010000000000000005 drwx------. 2 postgres postgres 133 Dec 21 12:12 archive_status [postgres@centos10 ~]$ [postgres@centos10 ~]$ [postgres@centos10 ~]$ cat 13/data/pg_wal/000000010000000000000003.00000028.backup START WAL LOCATION: 0/3000028 (file 000000010000000000000003) STOP WAL LOCATION: 0/4000050 (file 000000010000000000000004) CHECKPOINT LOCATION: 0/3000060 BACKUP METHOD: pg_start_backup BACKUP FROM: master START TIME: 2020-12-21 11:57:52 JST LABEL: test_backup01 START TIMELINE: 1 STOP TIME: 2020-12-21 12:12:15 JST STOP TIMELINE: 1 [postgres@centos10 ~]$
pg_start_backup()実行時点までのWALがアーカイビングされている事を確認します。
[root@centos10 ~]# ls -l /nfs/postgres/wal/ 合計 131076 -rw-------. 1 postgres postgres 16777216 12月 21 11:52 000000010000000000000001 -rw-------. 1 postgres postgres 16777216 12月 21 11:53 000000010000000000000002 -rw-------. 1 postgres postgres 16777216 12月 21 11:58 000000010000000000000003 -rw-------. 1 postgres postgres 332 12月 21 12:12 000000010000000000000003.00000028.backup -rw-------. 1 postgres postgres 16777216 12月 21 12:12 000000010000000000000004
リストアの実行
テストデータの作成
任意の時刻へのリストアが可能である事を実験するために、pg_stop_backup()実行後に何らかの更新処理を発生させます。
以下はpgbenchコマンドを使用した更新処理の操作例です。
createdb test /usr/pgsql-13/bin/pgbench -i test /usr/pgsql-13/bin/pgbench -c 5 -t 10000 test
上記操作によって新たなWALがアーカイビングされている事を確認します。
[postgres@centos10 ~]$ ls -l /nfs/postgres/wal/ total 163844 -rw-------. 1 postgres postgres 16777216 Dec 21 11:52 000000010000000000000001 -rw-------. 1 postgres postgres 16777216 Dec 21 11:53 000000010000000000000002 -rw-------. 1 postgres postgres 16777216 Dec 21 11:58 000000010000000000000003 -rw-------. 1 postgres postgres 332 Dec 21 12:12 000000010000000000000003.00000028.backup -rw-------. 1 postgres postgres 16777216 Dec 21 12:12 000000010000000000000004 -rw-------. 1 postgres postgres 16777216 Dec 21 12:15 000000010000000000000005 -rw-------. 1 postgres postgres 16777216 Dec 21 12:16 000000010000000000000006 -rw-------. 1 postgres postgres 16777216 Dec 21 12:17 000000010000000000000007 -rw-------. 1 postgres postgres 16777216 Dec 21 12:17 000000010000000000000008
リストアデータの配置
NFSのような共有領域からデータをリストアします。
rsync -av --delete /nfs/postgres/backup/* /var/lib/pgsql/13/data/ chown postgres:postgres /var/lib/pgsql/13/data chmod 700 /var/lib/pgsql/13/data
リストアデータの設定
postgresql.confにどのようにリストアを実行するかの設定を記載します。
設定すべきパラメタを以下にまとめます。
パラメタ | 意味 |
---|---|
restore_command | アーカイビングされたWALをどのようにコピーするかのコマンドを指定。%fはアーカイビングのファイル名で、%pはリストア先のファイル名 |
recovery_target_action | リストア完了後にサーバの状態をどうするかを定義。デフォルトのpauseはリストア完了後に参照クエリのみを受け付ける。shutdownはリストア完了後にシャットダウンし、promoteはリストア完了後に更新クエリも受け付ける |
recovery_target_time | どこまでリストアするかを時刻で指定する |
recovery_target_lsn | どこまでリストアするかをLSNで指定する |
recovery_target_xid | どこまでリストアするかをxidで指定する |
どこまでリストアすべきかをWALを見て調査します。WALはバイナリファイルで、中身を見るためにはpg_waldumpというコマンドが必要です。
以下8行目のlsn:0/05015048, 2020-12-21 12:15:06.487599 JSTまでをリストアする操作を説明します。
[postgres@centos10 ~]$ /usr/pgsql-13/bin/pg_waldump /nfs/postgres/wal/000000010000000000000005 | egrep "Xid|COMMIT" rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/05000028, prev 0/04000050, desc: RUNNING_XACTS nextXid 676 latestCompletedXid 675 oldestRunningXid 676 rmgr: Standby len (rec/tot): 54/ 54, tx: 0, lsn: 0/050007F8, prev 0/05000730, desc: RUNNING_XACTS nextXid 677 latestCompletedXid 675 oldestRunningXid 676; 1 xacts: 676 rmgr: Standby len (rec/tot): 54/ 54, tx: 0, lsn: 0/050008D8, prev 0/050008A8, desc: RUNNING_XACTS nextXid 677 latestCompletedXid 675 oldestRunningXid 676; 1 xacts: 676 rmgr: Transaction len (rec/tot): 66/ 66, tx: 676, lsn: 0/05000988, prev 0/05000910, desc: COMMIT 2020-12-21 12:14:43.217404 JST; inval msgs: catcache 21; sync rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/050009D0, prev 0/05000988, desc: RUNNING_XACTS nextXid 677 latestCompletedXid 676 oldestRunningXid 677 rmgr: Transaction len (rec/tot): 565/ 565, tx: 677, lsn: 0/05013A50, prev 0/05013A20, desc: COMMIT 2020-12-21 12:15:06.484644 JST; inval msgs: catcache 75 catcache 74 catcache 75 catcache 74 catcache 50 catcache 49 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 snapshot 2608 relcache 16714 rmgr: Transaction len (rec/tot): 501/ 501, tx: 678, lsn: 0/05015048, prev 0/05015018, desc: COMMIT 2020-12-21 12:15:06.487599 JST; inval msgs: catcache 75 catcache 74 catcache 75 catcache 74 catcache 50 catcache 49 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 snapshot 2608 relcache 16717 rmgr: Transaction len (rec/tot): 501/ 501, tx: 679, lsn: 0/05016600, prev 0/050165D0, desc: COMMIT 2020-12-21 12:15:06.490934 JST; inval msgs: catcache 75 catcache 74 catcache 75 catcache 74 catcache 50 catcache 49 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 snapshot 2608 relcache 16720 rmgr: Transaction len (rec/tot): 469/ 469, tx: 680, lsn: 0/05017A70, prev 0/05017A40, desc: COMMIT 2020-12-21 12:15:06.492613 JST; inval msgs: catcache 75 catcache 74 catcache 75 catcache 74 catcache 50 catcache 49 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 snapshot 2608 relcache 16723 rmgr: Standby len (rec/tot): 54/ 54, tx: 0, lsn: 0/058E5840, prev 0/058E57F0, desc: RUNNING_XACTS nextXid 682 latestCompletedXid 680 oldestRunningXid 681; 1 xacts: 681 rmgr: Transaction len (rec/tot): 297/ 297, tx: 681, lsn: 0/05A54518, prev 0/05A53C18, desc: COMMIT 2020-12-21 12:15:06.748253 JST; rels: base/16713/16717 base/16713/16714 base/16713/16723 base/16713/16720; inval msgs: catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 relcache 16717 relcache 16714 relcache 16723 relcache 16720 rmgr: Transaction len (rec/tot): 98/ 98, tx: 682, lsn: 0/05A5E8B0, prev 0/05A5E870, desc: COMMIT 2020-12-21 12:15:06.771915 JST; inval msgs: catcache 58 catcache 58 catcache 58 rmgr: Transaction len (rec/tot): 114/ 114, tx: 683, lsn: 0/05A63118, prev 0/05A630D8, desc: COMMIT 2020-12-21 12:15:06.776512 JST; inval msgs: catcache 58 catcache 58 catcache 58 catcache 58 rmgr: Transaction len (rec/tot): 114/ 114, tx: 684, lsn: 0/05A7F458, prev 0/05A7F418, desc: COMMIT 2020-12-21 12:15:06.866056 JST; inval msgs: catcache 58 catcache 58 catcache 58 catcache 58 rmgr: Transaction len (rec/tot): 293/ 293, tx: 685, lsn: 0/05A84788, prev 0/05A846C8, desc: COMMIT 2020-12-21 12:15:06.876087 JST; inval msgs: catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 7 catcache 6 catcache 32 catcache 19 relcache 16723 relcache 16730 relcache 16730 relcache 16723 snapshot 2608 rmgr: Transaction len (rec/tot): 293/ 293, tx: 686, lsn: 0/05A854B0, prev 0/05A853F0, desc: COMMIT 2020-12-21 12:15:06.881833 JST; inval msgs: catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 7 catcache 6 catcache 32 catcache 19 relcache 16717 relcache 16732 relcache 16732 relcache 16717 snapshot 2608 rmgr: Transaction len (rec/tot): 293/ 293, tx: 687, lsn: 0/05C78A60, prev 0/05C789A0, desc: COMMIT 2020-12-21 12:15:07.018590 JST; inval msgs: catcache 50 catcache 49 catcache 50 catcache 49 catcache 50 catcache 49 catcache 7 catcache 6 catcache 32 catcache 19 relcache 16720 relcache 16734 relcache 16734 relcache 16720 snapshot 2608
postgresql.confにリストアに関する設定を加筆し、アーカイビングに関する設定をコメントアウトします。
vi /var/lib/pgsql/13/data/postgresql.conf #archive_mode = on #archive_command = 'cp -p %p /nfs/postgres/wal/%f' #archive_timeout = 60 restore_command = 'cp /nfs/postgres/wal/%f %p' recovery_target_action = 'pause' recovery_target_lsn = '0/05015048'
リストアシグナル
PostgreSQLのglobalディレクトリにはPostgreSQLの現在の状態が記録されています。
[postgres@centos11 ~]$ ls -l 13/data/global/ total 564 -rw-------. 1 postgres postgres 8192 Dec 21 11:49 1213 -rw-------. 1 postgres postgres 24576 Dec 21 11:49 1213_fsm -rw-------. 1 postgres postgres 8192 Dec 21 11:49 1213_vm -rw-------. 1 postgres postgres 8192 Dec 21 11:49 1214 -rw-------. 1 postgres postgres 24576 Dec 21 11:49 1214_fsm -rw-------. 1 postgres postgres 8192 Dec 21 11:49 1214_vm <omitted>
これらファイルはバイナリですので状態を見るには、pg_controldataというコマンドを使用します。このコマンドを使用して状態を確認すると、Database cluster stateが「in production」である事が分かります。これはPostgreSQLが起動中(オンライン)の状態でバックアップを取得した事を意味します。
[postgres@centos11 ~]$ /usr/pgsql-13/bin/pg_controldata pg_control version number: 1300 Catalog version number: 202007201 Database system identifier: 6908536247329030256 Database cluster state: in production pg_control last modified: Mon 21 Dec 2020 11:57:52 AM JST Latest checkpoint location: 0/3000060 Latest checkpoint's REDO location: 0/3000028 Latest checkpoint's REDO WAL file: 000000010000000000000003 Latest checkpoint's TimeLineID: 1 Latest checkpoint's PrevTimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0:676 Latest checkpoint's NextOID: 24576 Latest checkpoint's NextMultiXactId: 1 Latest checkpoint's NextMultiOffset: 0 Latest checkpoint's oldestXID: 479 Latest checkpoint's oldestXID's DB: 1 Latest checkpoint's oldestActiveXID: 676 Latest checkpoint's oldestMultiXid: 1 Latest checkpoint's oldestMulti's DB: 1 Latest checkpoint's oldestCommitTsXid:0 Latest checkpoint's newestCommitTsXid:0 Time of latest checkpoint: Mon 21 Dec 2020 11:56:45 AM JST Fake LSN counter for unlogged rels: 0/3E8 Minimum recovery ending location: 0/0 Min recovery ending loc's timeline: 0 Backup start location: 0/0 Backup end location: 0/0 End-of-backup record required: no wal_level setting: replica wal_log_hints setting: off max_connections setting: 100 max_worker_processes setting: 8 max_wal_senders setting: 10 max_prepared_xacts setting: 0 max_locks_per_xact setting: 64 track_commit_timestamp setting: off Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Maximum size of a TOAST chunk: 1996 Size of a large-object chunk: 2048 Date/time type storage: 64-bit integers Float8 argument passing: by value Data page checksum version: 0 Mock authentication nonce: 1cf8ea824b3545f66fab2fbcebc415e983cf9a9d09966c616e3b2380ea288daa
起動中(オンライン)状態のPostgreSQLから復旧する場合は、その旨をPostgreSQLに教えてあげる必要があります。/var/lib/pgsql/13/data/recovery.signalというファイルを作成する事でPostgreSQLはオンライン状態のデータからの復旧を試みるようになります。
touch /var/lib/pgsql/13/data/recovery.signal
リストアデータの実行
ここまでの準備が整いましたら、PostgreSQLを起動する事でリストアができます。
systemctl start postgresql-13.service
起動時には以下のようなログが出力されます。これを見ると、WAL000000010000000000000003の状態でリストアされ、その後、WAL000000010000000000000004とWAL000000010000000000000005の更新処理が適用され、LSN"0/5015048"で停止した事が分かります。
[root@centos11 ~]# cat /var/lib/pgsql/13/data/log/postgresql-Wed.log 2020-12-23 12:16:38.409 JST [2367] LOG: PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5), 64-bit を起動しています 2020-12-23 12:16:38.410 JST [2367] LOG: IPv6アドレス"::1"、ポート5432で待ち受けています 2020-12-23 12:16:38.410 JST [2367] LOG: IPv4アドレス"127.0.0.1"、ポート5432で待ち受けています 2020-12-23 12:16:38.413 JST [2367] LOG: Unixソケット"/var/run/postgresql/.s.PGSQL.5432"で待ち受けています 2020-12-23 12:16:38.418 JST [2367] LOG: Unixソケット"/tmp/.s.PGSQL.5432"で待ち受けています 2020-12-23 12:16:38.422 JST [2370] LOG: データベースシステムは中断されました: 2020-12-21 11:57:52 JST まで動作していたことは確認できます cp: '/nfs/postgres/wal/00000002.history' を stat できません: No such file or directory 2020-12-23 12:16:38.657 JST [2370] LOG: WAL位置(LSN) "0/5015048"までのポイントインタイムリカバリを開始します 2020-12-23 12:16:38.667 JST [2370] LOG: ログファイル"000000010000000000000003"をアーカイブからリストアしました 2020-12-23 12:16:38.709 JST [2370] LOG: REDOを0/3000028から開始します 2020-12-23 12:16:38.720 JST [2370] LOG: ログファイル"000000010000000000000004"をアーカイブからリストアしました 2020-12-23 12:16:38.756 JST [2370] LOG: 0/4000050 でリカバリの一貫性が確保されました 2020-12-23 12:16:38.757 JST [2367] LOG: データベースシステムはリードオンリー接続の受け付け準備ができました 2020-12-23 12:16:38.768 JST [2370] LOG: ログファイル"000000010000000000000005"をアーカイブからリストアしました 2020-12-23 12:16:38.961 JST [2370] LOG: リカバリ処理はWAL位置(LSN)"0/5015048"の後で停止します 2020-12-23 12:16:38.961 JST [2370] LOG: リカバリ完了位置で一時停止しています 2020-12-23 12:16:38.961 JST [2370] ヒント: 再開するには pg_wal_replay_resume() を実行してください [root@centos11 ~]#
更新処理の再開
デフォルト設定のrecovery_target_action='pause'では、リストア直後は更新処理を受け付けません。これは想定通りの時刻にリストアされたを確認してからの更新処理を受け付けたい場合に使用する設定です。
動作確認のために更新処理を試みると、確かに拒否される事が分かります。
[postgres@centos11 ~]$ psql test -c "CREATE TABLE tmp (id int);" ERROR: リードオンリーのトランザクションでは CREATE TABLE を実行できません [postgres@centos11 ~]$
pg_wal_replay_resume()を実行すると、更新処理が可能になります。
[postgres@centos11 ~]$ psql -c "SELECT pg_wal_replay_resume();" pg_wal_replay_resume ---------------------- (1 row) [postgres@centos11 ~]$ psql test -c "CREATE TABLE tmp (id int);" CREATE TABLE [postgres@centos11 ~]$