祝！PostgreSQLレプリケーション10周年！徹底紹介！！

© 2020 NTT DATA Corporation 1 © 2020 NTT DATA Corporation
オープンソースカンファレンス2020 Online/Fall
祝！PostgreSQLレプリケーション10周年！徹底紹介！！
2020年10月23日
株式会社NTTデータ藤井雅雄 @fujii_masao

© 2020 NTT DATA Corporation 22© 2020 NTT DATA Corporation
自己紹介
藤井雅雄
Database Technical Lead @ NTTデータ
データベース研究開発
PostgreSQL 技術支援
PostgreSQLコミッタ
レプリケーション
WAL圧縮、バックアップ進捗
pg_bigm(全文検索モジュール)コミッタ
@fujii_masao

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

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

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

レプリケーションとは

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

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

PostgreSQLで利用可能なレプリケーション
ストリーミングレプリケーション (物理レプリケーション)
2010年リリースのPostgreSQL9.0から利用可能
ロジカルレプリケーション (論理レプリケーション)
2017年リリースのPostgreSQL10から利用可能
PostgreSQL関連製品によるレプリケーション
例えば、pgpool-II、Slonyなど
その他製品によるレプリケーション
例えば、DRBDのディスク同期によるレプリケーションなど

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

ストリーミングレプリケーションの基本

プライマリ・スタンバイ方式
DBサーバ
複製
プライマリ
中継サーバ
スタンバイ
プライマリでのデータベースの更新結果をスタンバイにレプリケーション(複製)
 プライマリでは、更新SQLと参照SQLを実行可能
 スタンバイでは、参照SQLのみ実行可能
更新SQL
参照SQL
参照SQL更新SQL
参照SQL
更新SQL
参照SQL
更新SQL
参照SQL

シングルプライマリ・マルチスタンバイ構成
プライマリは1台のみ、スタンバイは複数台
 更新SQLを実行可能なプライマリは1台のみのため、更新スケールアウトには使えない
 参照SQLを実行可能なスタンバイは複数台構成できるため、参照スケールアウトには使える
複製
参照と更新
プライマリスタンバイ1 スタンバイ2 スタンバイ3
複製
複製
参照のみ参照のみ参照のみ

カスケードレプリケーション
スタンバイからスタンバイへのレプリケーションが可能
 プライマリに直接接続のスタンバイ台数を減らすことで、プライマリの負荷を低減できる
プライマリ
マルチスタンバイマルチスタンバイ
複製複製
クライアント
複製

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

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

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

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

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

スタンバイのプライマリへの昇格
 スタンバイはいつでもプライマリに昇格可能
 新しいスタンバイをいつでも構成に組み込むことが可能
プライ
マリ
スタン
バイ
スタンバイ単独
停止スタン
バイ
停止プライ
マリ
プライマリ単独
プライマリ故障
プライマリへの昇格
スタンバイ
再組み込み
プライ
マリ
スタン
バイ

フェイルオーバ
PostgreSQLは自動的なフェイルオーバ機能を提供しない
• 自動的なフェイルオーバにはクラスタソフトと要連携
プライマリ
pgpool-II
スタンバイプライマリスタンバイ
Pacemaker pgpool-II
VIP

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

簡単セットアップ
手軽にシングルサーバ内でレプリケーション構成をセットアップ可能
プライマリをセットアップ
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を変更する必要がある

ストリーミングレプリケーションの
非同期・同期

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

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

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

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

synchronous_standby_names
どのスタンバイを同期レプリケーションの対象とするかは synchronous_standby_names で設定
synchronous_standby_names = '[FIRST | ANY ] NUM (NAME1, NAME2, ...)‘
同期スタンバイの台数同期スタンバイの名前のリスト同期スタンバイを選ぶ方式
オンラインでいつでも
設定変更可能

synchronous_standby_namesの設定例1
synchronous_standby_names = 'FIRST 2 (S1, S2, S3)'
現在稼働中のスタンバイから、S1、S2、S3の優先順位で2台を同期スタンバイとして選ぶ
プライマリ
S1
S2
S3
スタンバイ
同期
非同期
同期優先度の高いS1とS2が
同期スタンバイとして
選ばれる

synchronous_standby_names = 'ANY 2 (S1, S2, S3)'
S1、S2、S3のスタンバイのうち少なくとも2台にレプリケーションが完了するのを待つ
プライマリ
S1
S2
S3
スタンバイ
同期かも
S1～S3のどれか2台に
レプリケーションが
完了するまで待つ
同期かも
同期かも

FIRSTとANYの使い分け
同期
同期 S1
S2
S1
S2
同期かも
同期かも
非同期 S3
スタンバイ
プライ
マリ
S3同期かも
スタンバイ
プライ
マリ
FIRST
 同期レプリケーションのスタンバイを固定したい
 同期スタンバイに全体性能が引きずられる
ANY
 特定スタンバイに全体性能が引きずられるのを避け
たい
 同期スタンバイは固定化できない

1台のスタンバイ S1 に対して同期レプリケーションを設定
synchronous_standby_names = 'FIRST 1 (S1)' または 'ANY 1 (S1)'
同期
S1

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で同期レプリケーションのレベルを細かく設定可能

遅延レプリケーション
recovery_min_apply_delayの指定時間だけ、スタンバイによるWALのリカバリを遅延させられる
 重要なテーブルのTRUNCATEなどオペミスがプライマリで発生したとき、スタンバイでリカバリを遅延され
ている間に何らかの対処が可能
 synchronous_commit=remote_applyの場合は、レプリケーションはリカバリの遅延分まで待
つことになる
プライマリスタンバイクライアント
WAL書込
WAL転送
WAL書込
応答
COMMIT
OK
recovery_min_apply_delay = '5min'
13:00
WAL生成
13:05以降
リカバリ
WAL生成時刻13:00の5分後の
13:05になるまで、
そのWALのリカバリは待たされる

スタンバイでのSQL実行

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

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

SQL
• SELECT, COPY TO
一時テーブル
運用
• VACUUM, ANALYZE
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

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

ストリーミングレプリケーションの
監視

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アドレス、ポート番号、接続情報

PostgreSQL12以降で
ストリーミングレプリケーションを
使うときの注意

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

最後に

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

(付録)
PostgreSQL13新機能
レプリケーション接続先を手軽に再設定

レプリケーション接続先の設定
スタンバイ側で、primary_conninfoパラメータに
レプリケーション接続先を設定
$ cat $PGDATA/postgresql.conf
primary_conninfo = 'host=x.x.x.x port=5432 user=repuser'
マスタスタンバイ
WAL転送
接続要求
x.x.x.x:5432

レプリケーション接続先を再設定するときの課題 (v12以前)
マスタ
スタンバイ
新マスタ
フェイル
オーバ
WAL転送
接続要求
レプリケーション接続先を再設定するには、スタンバイの再起動が必要
x.x.x.x:5432
y.y.y.y:9999
primary_conninfo = 'host=y.y.y.y port=9999 user=repuser'
再起動

レプリケーション接続先を手軽に再設定 (v13以降)
マスタ
スタンバイ
新マスタ
フェイル
オーバ
WAL転送
接続要求
v13から、設定ファイルの再読み込みで、レプリケーション接続先を再設定可能に！
x.x.x.x:5432
y.y.y.y:9999
primary_conninfo = 'host=y.y.y.y port=9999 user=repuser'
設定ファイル再読み込み
$ pg_ctl $PGDATA reload

レプリケーション接続先を手軽に再設定 (v13以降)
primary_conninfoを空にして設定ファイルを再読み込みすることで、
スタンバイ側でWAL受信を一時停止(walreceiverを停止)可能に！
マスタスタンバイ
WAL転送
接続要求
x.x.x.x:5432
primary_conninfo = ''
設定ファイル再読み込み
$ pg_ctl $PGDATA reload
一時停止

(参考) 複数のレプリケーション接続先の設定
マスタ
スタンバイ
新マスタ
フェイル
オーバ
WAL転送
接続要求
v10から、複数のレプリケーション接続先を事前に設定して、
自動的に接続先を切り替えることも可能
x.x.x.x:5432
y.y.y.y:9999
primary_conninfo = 'host=x.x.x.x,y.y.y.y port=5432,9999 user=repuser'
接続に成功するまで、
設定された接続先へ
の接続を順番に試す

(付録)
スタンバイでの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)を参照するトランザク
ション(①)が完了するまでリカバリは
待ち

競合によりリカバリが進まないと、
• スタンバイで参照できるデータが古いまま
• プライマリ昇格時にリカバリしなければならない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できないゴミレコードがた
まり続けるため注意。

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
ロックの取得
③空き領域の物理削除
②

(付録)
レプリケーションのアーキテクチャ

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

祝！PostgreSQLレプリケーション10周年！徹底紹介！！

祝！PostgreSQLレプリケーション10周年！徹底紹介！！

More Related Content

What's hot

Similar to 祝！PostgreSQLレプリケーション10周年！徹底紹介！！

More from NTT DATA Technology & Innovation

祝！PostgreSQLレプリケーション10周年！徹底紹介！！