PostgreSQLはストリーミングレプリケーションと呼ばれるデータコピーの仕組みがあります。3台以上のプライマリ/スレーブ構成を紹介し、ストリーミングレプリケーションの障害復旧について説明します。
- 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 スロークエリの調査方法
動作確認構成
以下の環境で動作確認を行います。
+----------+ +----------+
| | | |
| centos10 +-----+------+ centos11 |
| (primary)| | | (standby)|
+----------+ | +----------+
192.168.56.10/24 | 192.168.56.11/24
|
| +----------+
| | |
+------+ centos12 |
| | (standby)|
| +----------+
| 192.168.56.12/24
|
| +----------+
| | |
+------+ centos13 |
| (standby)|
+----------+
192.168.56.13/24
事前準備
マスターサーバの構築
postgresql.confおよびpg_hba.confに以下を加筆します。スタンバイ機は3台構成とし、そのうち2台まではWALが同期している状態とします。
NFSサーバを構築しNFS上にWALのアーカイビングを出力する構成とします。
cat << EOF >> /var/lib/pgsql/13/data/postgresql.conf listen_addresses = '0.0.0.0' archive_mode = on archive_command = 'cp -p %p /nfs/postgres/wal/%f' archive_timeout = 60 max_wal_senders = 10 synchronous_commit = 'remote_write' synchronous_standby_names = 'ANY 2 (centos11,centos12,centos13)' EOF cat << EOF >> /var/lib/pgsql/13/data/pg_hba.conf host replication postgres 192.168.56.0/24 trust EOF
再起動し設定を反映させます。
systemctl restart postgresql-13.service
スタンバイサーバの構築
pg_basebackupコマンドを使用して、プライマリサーバのデータを1台目スタンバイサーバへコピーします。
1台目スタンバイサーバのデータを2,3台目へコピーします。コピー方法は環境に応じて適宜変更ください。
pg_basebackup -R -D ${PGDATA} -h 192.168.56.10
rsync -av root@192.168.56.11:/var/lib/pgsql/13/data/ ${PGDATA}
rsync -av root@192.168.56.11:/var/lib/pgsql/13/data/ ${PGDATA}
postgresql.auto.confのsynchronous_standby_namesにapplication_nameを加筆します。application_nameの値はスタンバイ機によって適宜変更してください。
# vi /var/lib/pgsql/13/data/postgresql.auto.conf primary_conninfo = 'user=postgres <omitted> application_name=centos11'
# vi /var/lib/pgsql/13/data/postgresql.auto.conf primary_conninfo = 'user=postgres <omitted> application_name=centos12'
# vi /var/lib/pgsql/13/data/postgresql.auto.conf primary_conninfo = 'user=postgres <omitted> application_name=centos13'
postgresql.confのプライマリ固有の設定をコメントアウトします。
# vi /var/lib/pgsql/13/data/postgresql.conf #listen_addresses = '0.0.0.0' #max_wal_senders = 10 #synchronous_commit = 'remote_write' #synchronous_standby_names = 'ANY 2 (centos11,centos12,centos13)'
postgresqlを起動し、レプリケーションを開始します。
systemctl start postgresql-13.service
レプリケーションが開始された旨のログを確認します。
[root@centos11 ~]# tail -n 3 /var/lib/pgsql/13/data/log/postgresql-Sat.log 2020-12-26 16:39:48.679 JST [1670] LOG: 0/19000000 でリカバリの一貫性が確保されました 2020-12-26 16:39:48.680 JST [1667] LOG: データベースシステムはリードオンリー接続の受け付け準備ができました 2020-12-26 16:39:48.876 JST [1674] LOG: プライマリのタイムライン1の 0/1B000000からでWALストリーミングを始めます
[root@centos12 ~]# tail -n 3 /var/lib/pgsql/13/data/log/postgresql-Sat.log 2020-12-26 16:36:05.152 JST [1491] LOG: 0/19000000 でリカバリの一貫性が確保されました 2020-12-26 16:36:05.153 JST [1488] LOG: データベースシステムはリードオンリー接続の受け付け準備ができました 2020-12-26 16:36:05.253 JST [1495] LOG: プライマリのタイムライン1の 0/19000000からでWALストリーミングを始めます
[root@centos13 ~]# tail -n 3 /var/lib/pgsql/13/data/log/postgresql-Sat.log 2020-12-26 16:36:15.984 JST [1184] LOG: 0/19000000 でリカバリの一貫性が確保されました 2020-12-26 16:36:15.985 JST [1181] LOG: データベースシステムはリードオンリー接続の受け付け準備ができました 2020-12-26 16:36:16.079 JST [1188] LOG: プライマリのタイムライン1の 0/19000000からでWALストリーミングを始めます
スタンバイサーバの障害復旧
WALが残存している場合
スタンバイ機のうち1つに障害を発生させます。
systemctl stop postgresql-13.service
障害が発生した機器はチェックポイントとなるWALからの復旧を試みます。
[postgres@centos11 ~]$ /usr/pgsql-13/bin/pg_controldata pg_control version number: 1300 Catalog version number: 202007201 Database system identifier: 6910180416328971117 Database cluster state: in archive recovery pg_control last modified: Sat 26 Dec 2020 04:53:24 PM JST Latest checkpoint location: 0/21000098 Latest checkpoint's REDO location: 0/21000060 Latest checkpoint's REDO WAL file: 000000010000000000000021 Latest checkpoint's TimeLineID: 1 Latest checkpoint's PrevTimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0:193643 Latest checkpoint's NextOID: 24607 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: 193643 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: Sat 26 Dec 2020 04:49:07 PM JST Fake LSN counter for unlogged rels: 0/3E8 Minimum recovery ending location: 0/22000000 <omitted>
プライマリサーバにWALが残っている場合は、このWALを使って復旧します。
[postgres@centos10 ~]$ ls -l 13/data/pg_wal/ total 163840 -rw-------. 1 postgres postgres 16777216 Dec 26 16:52 000000010000000000000021 -rw-------. 1 postgres postgres 16777216 Dec 26 16:55 000000010000000000000022 -rw-------. 1 postgres postgres 16777216 Dec 26 16:56 000000010000000000000023 -rw-------. 1 postgres postgres 16777216 Dec 26 16:39 000000010000000000000024 -rw-------. 1 postgres postgres 16777216 Dec 26 16:40 000000010000000000000025 -rw-------. 1 postgres postgres 16777216 Dec 26 16:42 000000010000000000000026 -rw-------. 1 postgres postgres 16777216 Dec 26 16:43 000000010000000000000027 -rw-------. 1 postgres postgres 16777216 Dec 26 16:46 000000010000000000000028 -rw-------. 1 postgres postgres 16777216 Dec 26 16:47 000000010000000000000029 -rw-------. 1 postgres postgres 16777216 Dec 26 16:48 00000001000000000000002A drwx------. 2 postgres postgres 80 Dec 26 16:55 archive_status
この場合は、スタンバイサーバを起動するのみで復旧可能です。
systemctl start postgresql-13.service
WALが消失している場合 – 復旧不能の確認
前述のシナリオはWALが残存している場合です。WALが消失してしまった場合は、スタンバイ機の構築手順同様にpg_basebackupコマンドなどを利用すれば復旧が可能です。
しかし、高負荷でプライマリサーバに余力がない場合はpg_backbackupによる復旧が出来ない場合もありえるかもしれません。このような時の回避策として、WALアーカイビングを使用した復旧方法を説明します。
まず、スタンバイ機の1台に障害を発生させます。
systemctl stop postgresql-13.service
プライマリ機に充分な更新処理を発生させ、WALをローテートさせ、復旧不能の状態にします。
createdb test /usr/pgsql-13/bin/pgbench -i test /usr/pgsql-13/bin/pgbench -c 5 -t 10000 test
スタンバイ機のチェックポイントを確認します。この場合は、000000010000000000000026である事が分かります。
[postgres@centos11 ~]$ /usr/pgsql-13/bin/pg_controldata pg_control version number: 1300 Catalog version number: 202007201 Database system identifier: 6910180416328971117 Database cluster state: shut down in recovery pg_control last modified: Sat 26 Dec 2020 05:06:04 PM JST Latest checkpoint location: 0/290CAC40 Latest checkpoint's REDO location: 0/2626B8D8 Latest checkpoint's REDO WAL file: 000000010000000000000026 Latest checkpoint's TimeLineID: 1 Latest checkpoint's PrevTimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0:219133 <omitted>
チェックポイントである000000010000000000000026以降は、スタンバイ機自身が保持するWALを用いて復旧させます。しかし、WALは00000001000000000000002Aまでしか持っていない事が分かります。
PostgreSQL停止中の状態でどこまでWALが書かれているかを判断するにはタイムスタンプに着目すると手っ取り早く判断できます。もし、ダメ押しの確認をしたいならば、pg_waldumpコマンドなどを併用しましょう。
[postgres@centos11 ~]$ ls -l /var/lib/pgsql/13/data/pg_wal/ total 163840 -rw-------. 1 postgres postgres 16777216 Dec 26 17:04 000000010000000000000026 -rw-------. 1 postgres postgres 16777216 Dec 26 17:04 000000010000000000000027 -rw-------. 1 postgres postgres 16777216 Dec 26 17:04 000000010000000000000028 -rw-------. 1 postgres postgres 16777216 Dec 26 17:04 000000010000000000000029 -rw-------. 1 postgres postgres 16777216 Dec 26 17:04 00000001000000000000002A -rw-------. 1 postgres postgres 16777216 Dec 26 16:52 00000001000000000000002B -rw-------. 1 postgres postgres 16777216 Dec 26 16:55 00000001000000000000002C -rw-------. 1 postgres postgres 16777216 Dec 26 16:56 00000001000000000000002D -rw-------. 1 postgres postgres 16777216 Dec 26 16:57 00000001000000000000002E -rw-------. 1 postgres postgres 16777216 Dec 26 16:58 00000001000000000000002F drwx------. 2 postgres postgres 154 Dec 26 17:06 archive_status [postgres@centos11 ~]$ [postgres@centos11 ~]$ [postgres@centos11 ~]$ cd /var/lib/pgsql/13/data/pg_wal/ [postgres@centos11 pg_wal]$ /usr/pgsql-13/bin/pg_waldump 00000001000000000000002A | tail -n 3 rmgr: Transaction len (rec/tot): 194/ 194, tx: 264037, lsn: 0/2A3BCAF8, prev 0/2A3BCA38, desc: COMMIT 2020-12-26 17:03:24.329152 JST; inval msgs: catcache 58 catcache 58 catcache 58 catcache 58 catcache 58 catcache 58 catcache 50 catcache 49 relcache 16385 rmgr: Standby len (rec/tot): 50/ 50, tx: 0, lsn: 0/2A3BCBC0, prev 0/2A3BCAF8, desc: RUNNING_XACTS nextXid 264038 latestCompletedXid 264037 oldestRunningXid 264038 rmgr: XLOG len (rec/tot): 24/ 24, tx: 0, lsn: 0/2A3BCBF8, prev 0/2A3BCBC0, desc: SWITCH [postgres@centos11 pg_wal]$ [postgres@centos11 pg_wal]$ [postgres@centos11 pg_wal]$ /usr/pgsql-13/bin/pg_waldump 00000001000000000000002B | tail pg_waldump: fatal: could not find a valid record after 0/2B000000 [postgres@centos11 pg_wal]$
スタンバイ機は自分が持つWALで00000001000000000000002Aまで復旧させます。その後は、プライマリ機が持つWALを問い合わせに行きますが、プライマリ機は00000001000000000000002Bを持っていない事が分かります。
このような場合は、単純にPostgreSQLを起動しても復旧できない事が予想できます。
[postgres@centos10 ~]$ ls -l /var/lib/pgsql/13/data/pg_wal/ total 163840 -rw-------. 1 postgres postgres 16777216 Dec 26 17:09 00000001000000000000002E -rw-------. 1 postgres postgres 16777216 Dec 26 17:10 00000001000000000000002F -rw-------. 1 postgres postgres 16777216 Dec 26 17:11 000000010000000000000030 -rw-------. 1 postgres postgres 16777216 Dec 26 17:12 000000010000000000000031 -rw-------. 1 postgres postgres 16777216 Dec 26 17:12 000000010000000000000032 -rw-------. 1 postgres postgres 16777216 Dec 26 17:02 000000010000000000000033 -rw-------. 1 postgres postgres 16777216 Dec 26 17:03 000000010000000000000034 -rw-------. 1 postgres postgres 16777216 Dec 26 17:06 000000010000000000000035 -rw-------. 1 postgres postgres 16777216 Dec 26 17:07 000000010000000000000036 -rw-------. 1 postgres postgres 16777216 Dec 26 17:08 000000010000000000000037 drwx------. 2 postgres postgres 154 Dec 26 17:12 archive_status [postgres@centos10 ~]$
確かにスタンバイ側のPostgreSQLを起動しても、レプリケーションが再開できないログが出力されています。
[root@centos11 ~]# systemctl start postgresql-13.service [root@centos11 ~]# [root@centos11 ~]# tail -n 3 /var/lib/pgsql/13/data/log/postgresql-Sat.log 2020-12-26 17:24:47.281 JST [1167] FATAL: WAL ストリームからデータを受信できませんでした: ERROR: 要求された WAL セグメント 00000001000000000000002B はすでに削除されています 2020-12-26 17:24:52.272 JST [1172] LOG: プライマリのタイムライン1の 0/2B000000からでWALストリーミングを始めます 2020-12-26 17:24:52.272 JST [1172] FATAL: WAL ストリームからデータを受信できませんでした: ERROR: 要求された WAL セグメント 00000001000000000000002B はすでに削除されています
プライマリ機側でもエラーが出力されています。
[postgres@centos10 ~]$ tail -n 3 /var/lib/pgsql/13/data/log/postgresql-Sat.log 2020-12-26 17:26:02.353 JST [1994] ERROR: 要求された WAL セグメント 00000001000000000000002B はすでに削除されています 2020-12-26 17:26:07.355 JST [1995] ERROR: 要求された WAL セグメント 00000001000000000000002B はすでに削除されています 2020-12-26 17:26:12.369 JST [1996] ERROR: 要求された WAL セグメント 00000001000000000000002B はすでに削除されています
WALが消失している場合 – アーカイビングによる復旧
アーカイビングに保存されているWALをスタンバイ機にコピーすれば復旧させる事ができます。手作業でWALをコピーしても復旧できますが、手作業は事故の元ですので、restore_commadを/var/lib/pgsql/13/data/postgresql.auto.confに設定しましょう。
vi /var/lib/pgsql/13/data/postgresql.auto.conf # Do not edit this file manually! # It will be overwritten by the ALTER SYSTEM command. primary_conninfo = 'user=postgres passfile=''/var/lib/pgsql/.pgpass'' channel_binding=prefer host=192.168.56.10 port=5432 sslmode=prefer sslcompression=0 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres target_session_attrs=any application_name=centos11' restore_command = 'cp /nfs/postgres/wal/%f %p'
スタンバイ機のPostgreSQLを再起動します。
systemctl restart postgresql-13.service
ストリーミグレプリケーションが再開された事を確認します。
[root@centos11 ~]# tail -f /var/lib/pgsql/13/data/log/postgresql-Sat.log 2020-12-26 17:29:27.092 JST [1308] LOG: ログファイル"00000001000000000000002F"をアーカイブからリストアしました 2020-12-26 17:29:27.689 JST [1308] LOG: ログファイル"000000010000000000000030"をアーカイブからリストアしました 2020-12-26 17:29:28.001 JST [1308] LOG: ログファイル"000000010000000000000031"をアーカイブからリストアしました 2020-12-26 17:29:28.229 JST [1308] LOG: ログファイル"000000010000000000000032"をアーカイブからリストアしました 2020-12-26 17:29:28.642 JST [1308] LOG: ログファイル"000000010000000000000033"をアーカイブからリストアしました 2020-12-26 17:29:29.119 JST [1308] LOG: ログファイル"000000010000000000000034"をアーカイブからリストアしました 2020-12-26 17:29:29.531 JST [1308] LOG: ログファイル"000000010000000000000035"をアーカイブからリストアしました 2020-12-26 17:29:29.587 JST [1308] LOG: ログファイル"000000010000000000000036"をアーカイブからリストアしました cp: '/nfs/postgres/wal/000000010000000000000037' を stat できません: No such file or directory 2020-12-26 17:29:29.678 JST [1332] LOG: プライマリのタイムライン1の 0/37000000からでWALストリーミングを始めます
プライマリサーバの障害復旧
プライマリサーバが完全に消失し、スタンバイサーバの１つをプラマリサーバに昇格せざるを得ないような状況を想定します。
+----------+ +----------+
| | | |
| centos10 +-----+------+ centos11 |
| (消失) | | | (primary)|
+----------+ | +----------+
192.168.56.10/24 | 192.168.56.11/24
|
| +----------+
| | |
+------+ centos12 |
| | (standby)|
| +----------+
| 192.168.56.12/24
|
| +----------+
| | |
+------+ centos13 |
| (standby)|
+----------+
192.168.56.13/24
プライマリへの昇格
プライマリに必要なパラメタをpostgresql.confおよびpg_bha.confに加筆します。
cat << EOF >> /var/lib/pgsql/13/data/postgresql.conf listen_addresses = '0.0.0.0' archive_mode = on archive_command = 'cp -p %p /nfs/postgres/wal/%f' archive_timeout = 60 max_wal_senders = 10 synchronous_commit = 'remote_write' synchronous_standby_names = 'ANY 1 (centos12,centos13)' EOF cat << EOF >> /var/lib/pgsql/13/data/pg_hba.conf host replication postgres 192.168.56.0/24 trust EOF
スタンバイ機としてのパラメタをコメントアウトまたは削除します。
# vi /var/lib/pgsql/13/data/postgresql.auto.conf #primary_conninfo = 'user=postgres passfile=''/var/lib/pgsql/.pgpass'' channel_binding=prefer host=192.168.56.10 port=5432 sslmode=prefer sslcompression=0 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres target_session_attrs=any application_name=centos11'
再起動により設定を反映させます。
systemctl restart postgresql-13.service
スタンバイサーバをプライマリサーバに昇格させるには、pg_ctl promoteを実行します。
[postgres@centos11 ~]$ /usr/pgsql-13/bin/pg_ctl promote waiting for server to promote.... done server promoted [postgres@centos11 ~]$
ログを見るとプライマリへ昇格し、タイムラインが1から2へ変わった事が分かります。
[postgres@centos11 ~]$ tail -n 10 13/data/log/postgresql-Sun.log 2020-12-27 13:08:35.473 JST [1092] ヒント: データベースサーバはpg_walサブディレクトリに置かれたファイルを定期的に確認します。 2020-12-27 13:08:35.474 JST [1092] LOG: スタンバイモードに入ります 2020-12-27 13:08:35.484 JST [1092] LOG: 0/370000A0 でリカバリの一貫性が確保されました 2020-12-27 13:08:35.484 JST [1092] LOG: 0/370000A0のレコード長が不正です:長さは24である必要がありますが、実際は0でした 2020-12-27 13:08:35.485 JST [1089] LOG: データベースシステムはリードオンリー接続の受け付け準備ができました 2020-12-27 13:08:51.818 JST [1092] LOG: 昇格要求を受信しました 2020-12-27 13:08:51.818 JST [1092] LOG: REDOは必要ありません 2020-12-27 13:08:51.818 JST [1092] LOG: 新しいタイムラインIDを選択: 2 2020-12-27 13:08:51.868 JST [1092] LOG: アーカイブリカバリが完了しました 2020-12-27 13:08:51.915 JST [1089] LOG: データベースシステムの接続受け付け準備が整いました
WALを見ると、タイムラインが2であるWALが出力されるようになった事が分かります。
[postgres@centos11 ~]$ ls -l 13/data/pg_wal/ total 196612 -rw-------. 1 postgres postgres 16777216 Dec 26 17:30 000000010000000000000037.partial -rw-------. 1 postgres postgres 16777216 Dec 27 13:08 000000020000000000000037 -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 000000020000000000000038 -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 000000020000000000000039 -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 00000002000000000000003A -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 00000002000000000000003B -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 00000002000000000000003C -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 00000002000000000000003D -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 00000002000000000000003E -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 00000002000000000000003F -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 000000020000000000000040 -rw-------. 1 postgres postgres 16777216 Dec 26 17:29 000000020000000000000041 -rw-------. 1 postgres postgres 42 Dec 27 13:08 00000002.history drwx------. 2 postgres postgres 80 Dec 27 13:08 archive_status
スタンバイ機の設定変更
postgresql.auto.confに記載されているprimary_conninfoについて、宛先ホストを変更します。
$ vi /var/lib/pgsql/13/data/postgresql.auto.conf primary_conninfo = '<omitted> host=192.168.56.11 <omitted>'
$ vi /var/lib/pgsql/13/data/postgresql.auto.conf primary_conninfo = '<omitted> host=192.168.56.11 <omitted>'
再起動で設定を反映させます。
systemctl restart postgresql-13.service
ログファイルを閲覧し、タイムライン2のWALを適用している事を読み取ります。
[root@centos12 ~]# tain -n 10 /var/lib/pgsql/13/data/log/postgresql-Sun.log 2020-12-27 13:11:14.879 JST [1127] LOG: 0/370000A0 でリカバリの一貫性が確保されました 2020-12-27 13:11:14.879 JST [1127] LOG: 0/370000A0のレコードの後方リンク5C7502DB/A60が不正です 2020-12-27 13:11:14.882 JST [1124] LOG: データベースシステムはリードオンリー接続の受け付け準備ができました 2020-12-27 13:11:15.171 JST [1131] LOG: プライマリサーバからライムライン2用のタイムライン履歴ファイルを取り込みしています 2020-12-27 13:11:15.176 JST [1131] LOG: プライマリのタイムライン1の 0/37000000からでWALストリーミングを始めます 2020-12-27 13:11:15.178 JST [1131] FATAL: WAL ストリームからデータを受信できませんでした: ERROR: 要求された WAL セグメント 000000010000000000000037 はすでに削除されています 2020-12-27 13:11:15.179 JST [1127] LOG: 新しい目標タイムラインは2です 2020-12-27 13:11:15.266 JST [1135] LOG: プライマリのタイムライン2の 0/37000000からでWALストリーミングを始めます 2020-12-27 13:11:15.349 JST [1127] LOG: REDOを0/370000A0から開始します [root@centos12 ~]#
プライマリサーバで更新処理を発生させます。
createdb test2
スタンバイサーバに更新が反映されている事を確認します。
[postgres@centos12 ~]$ psql -l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
postgres | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 |
template0 | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
test | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 |
test2 | postgres | UTF8 | ja_JP.UTF-8 | ja_JP.UTF-8 |
(5 rows)
