PostgreSQLレプリケーション10周年！徹底紹介！ （PostgreSQL Conference Japan 2019講演資料） NTTデータ 技術開発本部 藤井 雅雄 (PostgreSQLコミッタ)

1. © 2019 NTT DATA Corporation 1 © 2019 NTT DATA Corporation
PostgreSQL Conference Japan 2019
PostgreSQLレプリケーション10周年！徹底紹介！！
2019年11月15日
株式会社NTTデータ PostgreSQLコミッタ 藤井雅雄 @fujii_masao

2. © 2019 NTT DATA Corporation 2
藤井 雅雄 @fujii_masao
PostgreSQLエンジニア @ NTTデータ
社内 PostgreSQL 技術支援・営業
PostgreSQLコミッタ
レプリケーション(非同期 / 同期 / カスケード / クォーラムコミット)
WAL圧縮
pg_bigm(全文検索モジュール)コミッタ
自己紹介

3. © 2019 NTT DATA Corporation 3
【宣伝】 PostgreSQL 12 対応の pg_bigm 1.2 最新マイナーバージョンリリース!!
pg_bigm
https://pgbigm.osdn.jp/
https://github.com/pgbigm/pg_bigm
PostgreSQL上で全文検索機能を提供するOSSモジュール
「OSS」を含むタイトルの書籍情報を検索したい！
SELECT * FROM book WHERE title LIKE ‘%OSS%’
シーケンシャル
スキャン
インデックス
スキャン
pg_bigm導入で高速に! 通常、インデックス使えず低速

4. © 2019 NTT DATA Corporation 4
本講演について
講演資料は、後日、NTTデータのSlideShareアカウント上で公開予定です。
https://www.slideshare.net/nttdata-tech
特に断りのないかぎり、講演で取り上げる機能や仕様は PostgreSQL 12 のものになります。

5. © 2019 NTT DATA Corporation 5
アジェンダ
レプリケーションとは
ストリーミングレプリケーションの基本
ストリーミングレプリケーションの非同期・同期
スタンバイでのSQL実行
ストリーミングレプリケーションの監視
PostgreSQL12以降でストリーミングレプリケーションを使うときの注意
最後に

6. © 2019 NTT DATA Corporation 6
レプリケーションとは

7. © 2019 NTT DATA Corporation 7
レプリケーションとは？
クライアントクライアント
更新更新
DBサーバ
更新
複製
DBサーバ
更新
中継サーバ
複数のサーバにデータベースを自動的に複製する機能

8. © 2019 NTT DATA Corporation 8
なぜレプリケーションが必要か？
24時間365日システムを安定運用するのに必要!
高可用性
負荷分散
1台が故障しても、別サーバが処理を引き継げる
システム全体としてDBサービスが停止するのを回避できる
SQL実行の負荷を複数のサーバに分散できる
負荷が一箇所に集中しないので、システム全体として性能向上できる
クライアントクライアント
SQL SQLSQL
高可用 負荷分散
DBサーバ DBサーバ

9. © 2019 NTT DATA Corporation 9
PostgreSQLで利用可能なレプリケーション
ストリーミングレプリケーション (物理レプリケーション)
2010年リリースのPostgreSQL9.0から利用可能
ロジカルレプリケーション (論理レプリケーション)
2017年リリースのPostgreSQL10から利用可能
PostgreSQL関連製品によるレプリケーション
例えば、pgpool-II、Slonyなど
その他製品によるレプリケーション
例えば、DRBDのディスク同期によるレプリケーションなど
今回は、10周年記念のストリーミングレプリケーションについて徹底紹介します！

10. © 2019 NTT DATA Corporation 10
ストリーミングレプリケーションの基本

11. © 2019 NTT DATA Corporation 11
マスタ・スタンバイ方式
クライアントクライアント
DBサーバ
複製
マスタ
中継サーバ
スタンバイ
• マスタでのデータベースの更新結果をスタンバイにレプリケーション(複製)
• マスタでは、更新SQLと参照SQLを実行可能
• スタンバイでは、参照SQLのみ実行可能
更新SQL
参照SQL
参照SQL更新SQL
参照SQL
更新SQL
参照SQL
更新SQL
参照SQL
マスタ・スタンバイ方式

12. © 2019 NTT DATA Corporation 12
シングルマスタ・マルチスタンバイ構成
• マスタは1台のみ、スタンバイは複数台
• カスケードレプリケーション(スタンバイからスタンバイへのレプリケーション)
• 更新SQLを実行可能なマスタは1台のみのため、更新スケールアウトには使えない
• 参照SQLを実行可能なスタンバイは複数台構成できるため、参照スケールアウトには使える
シングルマスタ
マルチスタンバイ マルチスタンバイ
複製 複製
更新SQL
参照SQL
参照SQL
参照SQLクライアント

13. © 2019 NTT DATA Corporation 13
ログシッピング
• マスタは、データベースの変更情報としてトランザクションログ(WAL)をスタンバイに転送
• スタンバイは、転送されたWALをリカバリすることでデータベースを複製
マスタとスタンバイのデータベースの内容は物理的に同じ
⑤リカバリ
マスタ スタンバイ
クライアント①更新SQL
②WAL書込
③WAL転送
④WAL書込

14. © 2019 NTT DATA Corporation 14
ログシッピングによるストリーミングレプリケーションの制約
• マスタとスタンバイで以下2点が同じでなければならない
ハードウェアやOSのアーキテクチャ
PostgreSQLのメジャーバージョン
• 異なる環境間のレプリケーションにはロジカルレプリケーションを利用
マスタ
スタンバイ
64ビットOS
PostgreSQL12.0
PostgreSQL11.0
32ビットOS
64ビットOS
PostgreSQL12.1
NG
NG
OK

15. © 2019 NTT DATA Corporation 15
データベースクラスタ単位のレプリケーション
• すべてのデータベースオブジェクトが基本的にレプリケーション対象
• テーブル単位のレプリケーション指定は不可
• テーブル単位のレプリケーションにはロジカルレプリケーションを利用
データベースクラスタ単位 テーブル単位
マスタ スタンバイ マスタ スタンバイ

16. © 2019 NTT DATA Corporation 16
スタンバイのマスタへの昇格
• スタンバイはいつでもマスタに昇格可能
• 新しいスタンバイをいつでも構成に組み込むことが可能
マスタ スタン
バイ
レプリケーション構成
スタンバイ単独
停止 スタン
バイ
停止 マスタ
マスタ単独
マスタ故障
マスタへの昇格
スタンバイ
再組み込み
マスタ
レプリケーション構成
スタン
バイ

17. © 2019 NTT DATA Corporation 17
フェイルオーバ
PostgreSQLは自動的なフェイルオーバ機能を提供しない
• 自動的なフェイルオーバにはクラスタソフトと要連携
クライアントクライアント
マスタ
pgpool-II
スタンバイマスタ スタンバイ
Pacemaker pgpool-II
VIP

18. © 2019 NTT DATA Corporation 18
PG-REX
• PostgreSQLの同期レプリケーションにPacemakerを組み合わせた高可用ソリューション
• NTT OSSセンタが、PG-REXの設定・運用のための利用マニュアルや補助ツールなどを公開
https://ja.osdn.net/projects/pg-rex/
クライアント
マスタ スタンバイ
PG-REX
VIP
同期

19. © 2019 NTT DATA Corporation 19
アーキテクチャ
walsender walreceiver startup
データベース
クライアント
②変更
③書き込み
WAL WAL
⑤読み込み
⑥WAL転送
⑦書き込み ❾読み込み
❿リカバリ
⓬参照
①更新Tx ⓫参照Tx
backendbackendbackend
backendbackendbackend
マスタ スタンバイ
データベース
ディスク領域メモリ領域プロセス
凡例
⑩応答
⑨応答 ⑧応答
④通知
❽通知
⓭結果

20. © 2019 NTT DATA Corporation 20
簡単セットアップ
手軽にシングルサーバ内でレプリケーション構成をセットアップ可能
マスタをセットアップ
initdb -D data
pg_ctl -D data start
※マスタに必要な最低限のパラメータはデフォルトで有効化
スタンバイをセットアップ
pg_basebackup -D sby –R
echo “port = 9999” >> sby/postgresql.conf
pg_ctl -D sby start
※-Rオプションにより、バックアップ取得時に、スタンバイに必要なパラメータも自動的に設定
※同一サーバ内で2インスタンス起動するため、片方のportを変更する必要がある

21. © 2019 NTT DATA Corporation 21
ストリーミングレプリケーションの
非同期・同期

22. © 2019 NTT DATA Corporation 22
非同期・同期レプリケーションの概要
マスタ
マスタ
スタンバイ
スタンバイ
クライアント
クライアント
非同期はスタンバイへのレプリケーション完了を待たない
同期はスタンバイへのレプリケーション完了を待つ
①更新
②複製
③成功応答
④複製完了
①更新
②複製
③複製完了
④成功応答

23. © 2019 NTT DATA Corporation 23
同期レプリケーション
• COMMIT時にレプリケーションの完了を待つ
• COMMIT成功時にWALがマスタ・スタンバイ両方に書き込み済と保証
• フェイルオーバ時にCOMMIT済データを失わない!
• レプリケーション完了を待つので比較的低性能
リカバリ
マスタ スタンバイ
クライアント①COMMIT
②WAL書込
③WAL転送
④WAL書込
⑥OK
⑤応答



24. © 2019 NTT DATA Corporation 24
非同期レプリケーション
• COMMIT時にレプリケーションの完了を待たない
• COMMIT成功時にWALがスタンバイに届いている保証なし
フェイルオーバ時にCOMMIT済データを失う可能性あり
レプリケーション完了を待たないので比較的高性能!


⑥リカバリ
マスタ スタンバイ
クライアント①COMMIT
②WAL書込
④WAL転送
⑤WAL書込
③OK
③と④の間で
フェイルオーバが発生すると、
COMMIT済データを失う

25. © 2019 NTT DATA Corporation 25
非同期・同期レプリケーションの使い分け例
同期マスタ
高可用向けスタンバイ
負荷分散向けスタンバイ
災対向けスタンバイ
非同期 非同期
フェイルオーバ時に
データを失わないように、
高可用向けには
同期レプリケーションを利用
データセンタ(ローカル) データセンタ(遠隔地)
更新SQL
参照SQL
少し古いデータを参照できれば十分であれば、
負荷分散向けには性能オーバーヘッドの小さい
非同期レプリケーションを利用
参照SQL
クライアント
遠隔へのレプリケーションを待つと
性能が大幅劣化するため、
災対向けには非同期レプリケーションを利用
災対向けスタンバイ

26. © 2019 NTT DATA Corporation 26
synchronous_standby_names
どのスタンバイを同期レプリケーションの対象とするかは synchronous_standby_names で設定
synchronous_standby_names = '[FIRST | ANY ] NUM (NAME1, NAME2, ...)‘
同期スタンバイの台数 同期スタンバイの名前のリスト同期スタンバイを選ぶ方式
※名前のないスタンバイは非同期

27. © 2019 NTT DATA Corporation 27
synchronous_standby_namesの設定例1
synchronous_standby_names = 'FIRST 1 (S1, S2, S3)'
待たない
待つ S1
S2 待つ
S1
S2
故障
復旧
待たない S3 待たない S3
優先度の高いS1が
同期スタンバイとして選ばれる
スタンバイ
マスタ
スタンバイ
マスタ
次に優先度の高いS2
が同期スタンバイとして
選ばれる
現在稼働中のスタンバイから、S1、S2、S3の優先順位で
1台を同期スタンバイとして選ぶ

28. © 2019 NTT DATA Corporation 28
synchronous_standby_namesの設定例2
synchronous_standby_names = 'ANY 1 (S1, S2, S3)'
S1
S2
待つかも
待つかも
S3待つかも
スタンバイ
マスタ
待つかも
S1
S2
待つかも S3
スタンバイ
マスタ
故障
復旧
S1～S3のどれか1台に
レプリケーションが完了
するまで待つ
S2、S3のどちらか1台に
レプリケーションが完了す
るまで待つ
S1、S2、S3のスタンバイのうち少なくとも1台に
レプリケーションが完了するのを待つ

29. © 2019 NTT DATA Corporation 29
FIRSTとANYの使い分け
待たない
待つ S1
S2
S1
S2
待つかも
待つかも
待たない S3
スタンバイ
マスタ
S3待つかも
スタンバイ
マスタ
synchronous_standby_names = 'FIRST 1 (S1, S2, S3)'
synchronous_standby_names = 'ANY 1 (S1, S2, S3)'
特定のスタンバイ(S1)を同期スタンバイとして固定したい。
同期スタンバイ(S1)が遅延した場合、性能が引きずられるのは致し方
ない。
同期スタンバイの固定は不要で、どれか1台に複製できていれば十分。
特定のスタンバイに性能が引きずられるのは避けたい。

30. © 2019 NTT DATA Corporation 30
synchronous_standby_namesの設定例3
• 1台のスタンバイ S1 に対して同期レプリケーションを設定
synchronous_standby_names = 'FIRST 1 (S1)' または
'ANY 1 (S1)'
マスタ スタンバイ
同期
S1

31. © 2019 NTT DATA Corporation 31
synchronous_commit
synchronous_
commit
マスタ スタンバイ
WAL書込
(write+fsync)
WAL書込
(write)
WAL書込
(fsync)
リカバリ
off 待たない 待たない 待たない 待たない
local 待つ 待たない 待たない 待たない
remote_write 待つ 待つ 待たない 待たない
on 待つ 待つ 待つ 待たない
remote_apply 待つ 待つ 待つ 待つ
⑥リカバリマスタ スタンバイクライアント
②WAL書込
(write+fsync)
③WAL転送
④WAL書込(write)
応答
⑤WAL書込(fsync)
高性能
保護レベル高
①COMMIT
OK
synchronous_commitで同期レプリケーションのレベルを細かく設定可能

32. © 2019 NTT DATA Corporation 32
スタンバイでのSQL実行

33. © 2019 NTT DATA Corporation 33
マスタ・スタンバイ方式(再掲)
クライアントクライアント
DBサーバ
複製
マスタ
中継サーバ
スタンバイ
• マスタでのデータベースの更新結果をスタンバイにレプリケーション(複製)
• マスタでは、更新SQLと参照SQLを実行可能
• スタンバイでは、参照SQLのみ実行可能
更新SQL
参照SQL
参照SQL更新SQL
参照SQL
更新SQL
参照SQL
更新SQL
参照SQL
マスタ・スタンバイ方式

34. © 2019 NTT DATA Corporation 34
スタンバイで実行可能/不可能なSQL
実行可能
クエリ・アクセス
– SELECT, COPY TO
– カーソル操作
実行不可能
データ操作言語(DML)
– INSERT, UPDATE, DELETE
– SELECT FOR UPDATE
データ定義言語(DDL)
– CREATE, DROP, ALTER
一時テーブル
オンライン・バックアップ
– (論理) pg_dump
– (物理) pg_basebackup
トランザクション
– READ COMMITTED
– REPEATABLE READ
メンテナンス・コマンド
– VACUUM, ANALYZE
※マスタからメンテナンスの実行結果が複製
されるため、スタンバイでは実行不要
トランザクション
– SERIALIZABLE
– 二相コミット

35. © 2019 NTT DATA Corporation 35
スタンバイで参照できるデータ
• スタンバイで参照できるデータが古い(COMMIT済の最新データは見えない)可能性がある
• COMMIT済の最新データをすぐにスタンバイで参照するには、
synchronous_commit = remote_apply の同期レプリケーションを利用する
⑦リカバリ
マスタ スタンバイ
クライアント①COMMIT
③WAL転送
⑤OK
④応答
⑥参照SQL
⑤でCOMMIT完了とクライアントが認識した
データについて、⑦のリカバリが未実施のため、
⑥の参照SQLでは参照できない

36. © 2019 NTT DATA Corporation 36
スタンバイでのSQL実行とリカバリの競合
スタンバイ上でSQL実行とリカバリが競合することがある
• SQLが完了するまでリカバリが待たされる。設定によっては、リカバリを優先するために一定時間経過後にSQLがキャンセル
• リカバリが完了するまでSQL実行が待たされる
例えば、以下の競合が発生しやすい
• VACUUM起因の競合: スタンバイでアクセス中のレコードについて、マスタで完全削除(DELETE + VACUUM)
• ロック起因の競合: スタンバイでアクセス中のテーブルに対して、マスタでDDLを実行してロック(ACCESS EXCLUSIVE)を取得
マスタ スタンバイ
レコード(id=3)を参照
SELECT * FROM test WHERE id = 3;
①レコード(id=3)を削除
DELETE FROM test WHERE id = 3;
②
ゴミレコード(id=3)をVACUUMで回収
VACUUM test;
③
VACUUMのWAL転送④
ゴミレコード(id=3)をVACUUMする⑤
WALのリカバリを試みる…
id = 3 id = 3
競合⑥
レコード(id=3)を参照するトランザク
ション(①)が完了するまでリカバリは
待ち

37. © 2019 NTT DATA Corporation 37
スタンバイでのSQL実行とリカバリの競合
競合によりリカバリが進まないと、
• スタンバイで参照できるデータが古いまま
• マスタ昇格時にリカバリしなければならないWALが増えて、フェイルオーバ時間が増加
• synchronous_commit = remote_applyの同期レプリケーションが停止
競合をできる限り発生させないことが重要
• hot_standby_feedback = on により、VACUUM起因の競合を回避
• スタンバイ上のSQL実行と同じタイミングでDDL実行しないように運用して、ロック起因の競合を回避
マスタ スタンバイ
レコード(id=3)を参照
SELECT * FROM test WHERE id = 3;
①
レコード(id=3)を削除
DELETE FROM test WHERE id = 3;
②
スタンバイの状況からゴミレコード(id=3)は回収で
きないと判断してVACUUMをスキップ
VACUUM test;
③
id = 3 id = 3
スタンバイの状況をフィードバック
hot_standby_feedback = on
ゴミレコード(id=3)は、①のトランザク
ション終了後にVACUUMが走ると回収。
スタンバイでロングトランザクションがある
と、VACUUMできないゴミレコードがた
まり続けるため注意。

38. © 2019 NTT DATA Corporation 38
vacuum_truncate
VACUUMやautovacuumが勝手にACCESS EXCLUSIVEロックを取得して、ロック起因の競合を引き起こすことがある
• VACUUMは、通常、強いロックを取得せずにゴミレコードを回収するだけ
• ただし、ゴミレコードの回収によりテーブル末尾に空き領域ができた場合に限り、ACCESS EXCLUSIVEロックを取得して末尾の
空き領域を物理的に削除する
VACUUMに「ロックを取得してテーブル末尾の空き領域を物理削除」させるかどうかをvacuum_truncateで設定可能
• vacuum_truncateはPostgreSQL12から利用可能
• ロック起因の競合を避けたいテーブルに対しては、vacuum_truncate = off と設定する
ALTER TABLE test SET (vacuum_truncate = off);
• VACUUM (TRUNCATE off);
ゴミ
ゴミ
空き
空き
①ゴミレコードの回収
ACCESS EXCLUSIVE
ロックの取得
③空き領域の物理削除
②

39. © 2019 NTT DATA Corporation 39
ストリーミングレプリケーションの
監視

40. © 2019 NTT DATA Corporation 40
pg_stat_replication - マスタから見たレプリケーションの状況の確認
=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid | 39835
usesysid | 10
usename | postgres
application_name | sby1
client_addr | (null)
client_hostname | (null)
client_port | -1
backend_start | 2019-11-13 18:56:14.796913+09
backend_xmin | 497
state | streaming
sent_lsn | 0/A9FFF40
write_lsn | 0/A9FFF40
flush_lsn | 0/A9FFF40
replay_lsn | 0/A9FA228
write_lag | 00:00:00.000258
flush_lag | 00:00:00.000521
replay_lag | 00:02:01.671144
sync_priority | 1
sync_state | sync
reply_time | 2019-11-13 19:00:09.798971+09
レプリケーションの進捗
マスタはどこまでWALを送信したか?
スタンバイがどこまでWALを
書き込み(write/fsync)、リカバリしたか?
レプリケーション接続情報
スタンバイのIPアドレス、ポート番号、
レプリケーションに使用するユーザ名、
レプリケーションの開始日時など
レプリケーションの状態
レプリケーションは非同期か？同期か？
優先度は？
レプリケーションの遅延
マスタでのWAL生成から、スタンバイでのWALの
書き込み(write/fsync)、リカバリまで
どれぐらいタイムラグがあるか？

41. © 2019 NTT DATA Corporation 41
pg_stat_wal_receiver - スタンバイから見たレプリケーションの状況の確認
=# SELECT * FROM pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+------------------------
pid | 39834
status | streaming
receive_start_lsn | 0/2000000
receive_start_tli | 1
received_lsn | 0/A9FFF40
received_tli | 1
last_msg_send_time | 2019-11-13 19:00:09.799079+09
last_msg_receipt_time | 2019-11-13 19:00:09.799135+09
latest_end_lsn | 0/A9FFF40
latest_end_time | 2019-11-13 18:58:09.473889+09
slot_name | (null)
sender_host | /tmp
sender_port | 5432
conninfo | user=postgres passfile=/Users/postgres/.pgpass channel_binding=disable
dbname=replication port=5432 application_name=sby1 fallback_application_name=walreceiver sslmode=disable
sslcompression=0 gssencmode=disable target_session_attrs=any
レプリケーションの進捗
スタンバイがどこまでWALを書き込み(write/fsync)
したか？
マスタとスタンバイの間で送受信された最新メッセージの
送信時刻と受信時刻など
レプリケーション接続情報
マスタ(カスケードレプリケーションの場合はスタンバイ)
のIPアドレス、ポート番号、接続情報

42. © 2019 NTT DATA Corporation 42
PostgreSQL12以降で
ストリーミングレプリケーションを
使うときの注意

43. © 2019 NTT DATA Corporation 43
recovery.confの廃止
PostgreSQL12から、設定ファイルrecovery.confが廃止になり、スタンバイの設定方法が変わる。
recovery.conf を意識しているスクリプトやジョブなどあれば、PostgreSQL12以降で動かすために改修が必要。
PostgreSQL11以前
• 設定ファイルrecovery.confで standby_mode = on と設定
recovery.confの存在かつstandby_mode = onの設定が、サーバをスタンバイとして稼働させることを意味する。
• スタンバイ関連のパラメータをrecovery.confに設定
PostgreSQL12以降
• standby.signalファイル(空ファイルでよい)を作成
standby.signalファイルの存在が、サーバをスタンバイとして稼働させることを意味する
• スタンバイ関連のパラメータをpostgresql.confに設定

44. © 2019 NTT DATA Corporation 44
最後に

45. © 2019 NTT DATA Corporation 45
最後に
ストリーミングレプリケーションは10周年記念
10年間で、機能がノウハウなど揃いつつある
しかし、まだ機能不足や使いづらい点もあり、、、
次の10年間の開発に向けて、レプリケーションに関する要望などについてぜひ会話させてください！

46. © 2019 NTT DATA Corporation本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。

47. © 2019 NTT DATA Corporation 47
その他機能

48. © 2019 NTT DATA Corporation 48
旧マスタの再組み込み
9.4以前では、旧マスタの再組み込みにはフルバックアップの転送が必須
レプリケー
ション
マスタ スタン
バイ
停止 マスタ
マスタスタン
バイ
レプリケー
ション
停止 マスタ
両系稼働
マスタ単独稼働
両系稼働
フルバックアップ転送
マスタ故障により
フェイルオーバ
旧マスタの再組込み
フル
バック
アップ

49. © 2019 NTT DATA Corporation 49
旧マスタの再組み込み(pg_rewind)
9.5以降では、pg_rewindにより、旧マスタの再組み込み時にDBデータを差分バックアップ転送できる
レプリケー
ション
マスタ スタン
バイ
停止 マスタ
マスタスタン
バイ
レプリケー
ション
停止 マスタ
差分
バック
アップ
両系稼働
マスタ単独稼働
両系稼働
差分バックアップ転送
マスタ故障により
フェイルオーバ
pg_rewind
旧マスタの再組込み

50. © 2019 NTT DATA Corporation 50
遅延レプリケーション
• デフォルトでは、スタンバイは、受信したWALを可能なかぎり早くリカバリする
• 遅延レプリケーションでは、WALがマスタで生成された時刻から、recovery_min_apply_delayで指定された
時間以上経過するまで、スタンバイがそのWALをリカバリするのを待たせることができる
待つのはリカバリのみで、WALの受信や書き込みは待たないことに注意
synchronous_commit=remote_applyとの相性が悪い。。
• 重要なテーブルのTRUNCATEなどオペミスがマスタで発生したとき、スタンバイでリカバリを待っている間に何らかの
対処が可能
マスタ スタンバイクライアント
WAL書込
WAL転送
WAL書込
応答
COMMIT
OK
recovery_min_apply_delay = '5min'
13:00
WAL生成
13:05以降
リカバリ
WAL生成時刻13:00の5分後の
13:05になるまで、
そのWALのリカバリは待たされる

51. © 2019 NTT DATA Corporation 51
リカバリの一時停止・再開
• pg_wal_replay_pause() - 関数実行により、即座にリカバリを一時停止する
一時停止するのはリカバリのみで、WALの受信や書き込みは停止しない
synchronous_commit=remote_applyとの相性が悪い。。
• pg_wal_replay_resume() - 関数実行により、一時停止しているリカバリを再開する
• 例えば、スタンバイのデータベースを特定の状態のまま固定化して、その上で処理を行いたい場合に有用

52. © 2019 NTT DATA Corporation 52
トランザクションログ(WAL)圧縮
WALを圧縮してWALサイズを縮小可能に！
性能改善、ディスク領域削減、レプリケーションに有用
wal_compression = off(デフォルト) / on
WAL … WAL … WAL WAL
… …
OFF
ON
WALサイズを
縮小
圧縮
WAL
圧縮
WAL
圧縮
WAL
圧縮
WAL

53. © 2019 NTT DATA Corporation 53
pg_receivewal
• マスタに接続して、WALの受信と書き込みを繰り返すクライアントツール
• スタンバイから walreceiver だけをツール化したイメージ
• 例えば、リアルタイムなWALのアーカイブに利用できる
walsender pg_receivewal
データベース
クライアント
変更
書き込み
WAL
読み込み
WAL転送
書き込み
更新Tx backendbackendbackend
サーバ
応答
通知
ｱｰｶｲﾌﾞ

54. © 2019 NTT DATA Corporation 54
pg_stat_database_conflicts
=# SELECT * FROM pg_stat_database_conflicts WHERE datname = 'postgres';
-[ RECORD 1 ]----+---------
dated | 12923
datname | postgres
confl_tablespace| 0
confl_lock | 10
confl_snapshot | 22
confl_bufferpin | 3
confl_deadlock | 0
データベース毎の競合の発生回数を種類別に確認できるビュー
VACUUM起因の競合はconfl_snapshotカラム、
ロック起因の競合はconfl_lockカラムで発生回数を
確認できる