PostgreSQL13でのレプリケーション関連の改善について（第14回PostgreSQLアンカンファレンス@オンライン）

© 2020 NTT DATA Corporation 1 © 2020 NTT DATA Corporation
第14回 PostgreSQLアンカンファレンス@オンライン
PostgreSQL13での
レプリケーション関連の改善について
2020年6月25日
株式会社NTTデータ藤井雅雄 @fujii_masao

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

本講演について
講演資料は、後日、NTTデータのSlideShareアカウント上で公開予定です。
https://www.slideshare.net/nttdata-tech
以前のアンカンファレンスの講演資料は公開済です。
PostgreSQL 13 での pg_stat_statements の改善について
PostgreSQL 13 での pg_basebackup の改善について

PostgreSQL13 での
レプリケーション関連の改善について

PostgreSQL 13
• 現在コミュニティで開発中の最新バージョン
• 5月21日 β1リリース。機能一覧はリリースノートから
https://postgresql.org/docs/devel/release-13.html
• 10～11月に正式リリースの予定
今日紹介する内容は、正式リリースまでの間に
変更となる可能性があることにご注意ください！！

ストリーミングレプリケーション (物理レプリケーション)
マスタでのデータベースの更新結果を、WALでスタンバイにレプリケーション(複製)
マスタでは更新・参照SQL、スタンバイでは参照SQLのみ実行可能
⑤リカバリ
マスタスタンバイ
クライアント①更新SQL
②WAL書込
③WAL転送
④WAL書込

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

レプリケーション接続先の設定
スタンバイ側で、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'
接続に成功するまで、
設定された接続先へ
の接続を順番に試す

新機能(2)
レプリケーションスロットで保持できる
WALの最大サイズを設定可能に

レプリケーションで発生するエラー
ERROR: requested WAL segment 0000000100000000000000A7 has already been removed
☞スタンバイに未転送のWALファイルをマスタが削除したため、レプリケーションを継続できない
WAL転送
接続要求
スタンバイにどのWALファイルまで
転送済か考慮することなく、
古い不要なWALファイルを判断して削除

エラーを回避するための対策その① (v9.0以降)
wal_keep_segmentsパラメータで最低限保持するWALファイルの数を指定
☞マスタ/スタンバイ間の差分がwal_keep_segments内に収まればエラーを回避できる
WAL転送
接続要求
wal_keep_segmentsで指定された個数分は
WALファイルが残るように考慮して、
古い不要なWALファイルを削除

エラーを回避するための対策その① (v9.0以降)
wal_keep_segmentsの課題
① エラーを完全には回避できない。
マスタ/スタンバイ間の差分がwal_keep_segmentsを超えると、未転送
のWALファイルがマスタで削除されて、レプリケーションを継続できない
② スタンバイがマスタに十分追いついているとき、転送済の古いWALファイルは
削除してもよいのに、wal_keep_segmentsの設定により削除できない
(保持される)

エラーを回避するための対策その② (v9.4以降)
スタンバイにどのWALファイルまで転送済みかをレプリケーションスロットで管理
WAL転送
接続要求
スタンバイにどのWALファイルまで
転送済か考慮して、
レプリケーションスロットの作成
SELECT pg_create_physical_replication_slot('repslot');
レプリケーションスロット利用の設定
primary_slot_name = 'repslot'

エラーを回避するための対策その② (v9.4以降)
レプリケーションスロットの課題
① 未転送のWALファイルをずっと削除できない。
スタンバイが遅延/停止すると、未転送のため削除できないWALファイルがマ
スタ側に蓄積され続ける。
WALの書き出し先がディスクフルになると、マスタ側のPostgreSQLは
PANIC終了する。

エラーを回避するための対策その③ (v13以降)
レプリケーションスロットで保持できるWALファイルの最大サイズを
max_slot_wal_keep_sizeパラメータで設定可能に！
WAL転送
接続要求
スタンバイにどのWALファイルまで転送済かと
マスタ側で保持できるWALファイル数を考慮して、
レプリケーションスロットの作成とWALファイル保持上限の設定
SELECT pg_create_physical_replication_slot('repslot');
max_slot_wal_keep_size = '1GB'
レプリケーションスロット利用の設定
primary_slot_name = 'repslot'

エラーを回避するための対策の比較
対策
利用できる
バージョン
未転送WALの削除
を回避できるか？
未転送WALを上限
なく保持するか？
転送済WALをすぐ
に削除できるか？
wal_keep_segments 9.0以降
できないこともある
⇨ レプリケーション
失敗のリスクあり
上限がある
できない
⇨ 必要以上にディ
スク消費あり
レプリケーションスロット 9.4以降完全にできる
上限はない
⇨ マスタPANIC終
了のリスクあり
できる
レプリケーションスロット +
max_slot_wal_keep_size
13以降
できないこともある
⇨ レプリケーション
失敗のリスクあり
上限があるできる

まとめ

まとめ
PostgreSQL13から、レプリケーション関連で
1. レプリケーション接続先を手軽に再設定
2. レプリケーションスロットで保持できる
WALの最大サイズを設定
できるようになります。
v13βで、ぜひ機能をお試しいただければ！！

PostgreSQL13でのレプリケーション関連の改善について（第14回PostgreSQLアンカンファレンス@オンライン）

More Related Content

What's hot

Similar to PostgreSQL13でのレプリケーション関連の改善について（第14回PostgreSQLアンカンファレンス@オンライン）

More from NTT DATA Technology & Innovation

Recently uploaded

PostgreSQL13でのレプリケーション関連の改善について（第14回PostgreSQLアンカンファレンス@オンライン）