© 2023 NTT DATA Corporation
レプリケーション遅延の監視について
2023年 3月 16日 第40回PostgreSQLアンカンファレンス@オンライン
株式会社NTTデータ 技術開発本部
貞弘 泰輔

© 2023 NTT DATA Corporation 2
自己紹介
貞弘 泰輔
【経歴】
・5年くらいメインフレームのマイグレーション関連の開発を経験（PostgreSQLに触れる機会はなかった）
・5年くらいPostgreSQLを使ったシステム開発を経験
・PostgreSQLにもっと詳しくなりたいと思い研究開発チームに異動

© 2023 NTT DATA Corporation 3
本講演について
• 講演資料はNTTデータのSlideShareで公開しています。
• https://www.slideshare.net/nttdata-tech
• 本講演では、レプリケーション遅延の監視について説明します
• レプリケーション遅延監視の目的
• 遅延の確認方法（pg_stat_replicationビュー)
• レプリケーション遅延監視用SQLの例

© 2022 NTT DATA Corporation 4
© 2023 NTT DATA Corporation 4
レプリケーション遅延監視の目的

© 2023 NTT DATA Corporation 5
前提とする構成について
・プライマリ、スタンバイの2台構成
・プライマリのデータベースの更新結果をスタンバイにレプリケーション(複製)
クライアント
複製
同期or非同期レプリケーション
プライマリ スタンバイ
参照SQL
更新SQL
参照SQL
この遅延を監視したい

© 2023 NTT DATA Corporation 6
同期/非同期レプリケーションにおける遅延監視の目的について
・同期、非同期で遅延監視の目的が異なる
プライマリ スタンバイ
クライアント
レプリケーション 遅延監視の目的
同期 データ同期は保証されているため、応答時間にどの程度影響があるのかを知りたい。
非同期 どの程度プライマリとスタンバイのデータが乖離しているのかを知りたい。
例えばシステム要件のRPO(目標復旧地点）が１分以内だった場合、１分以上遅延が発生していないか等。
①更新SQL
②WAL書込 ❹WAL書込
❸WAL転送
❻応答
③応答
❺リカバリ
①更新SQL
②WAL書込 ④WAL書込
③WAL転送
⑤応答
⑥応答
❺リカバリ
同
期
非
同
期
○数字と●数字は並列処理

© 2022 NTT DATA Corporation 7
© 2023 NTT DATA Corporation 7
02
レプリケーション遅延の確認方法

© 2023 NTT DATA Corporation 8
pg_stat_replicationビューのwrite_lag、flush_lag、apply_lagについて
・pg_stat_replicationビューのwrite_lag、flush_lag、apply_lag列でレプリケーション遅延を時間単位で確認できる
列名 日本語マニュアルの説明
write_lag 最近のWALをローカルに吐き出してから、このスタンバイサーバがそれを書き出した（が、まだ吐き出したり適
用したりしていない）ことの通知を受け取るまでの経過時間です。
flush_lag 最近のWALをローカルに吐き出してから、このスタンバイサーバがそれを書き出して吐き出した（が、まだ適用
していない）ことの通知を受け取るまでの経過時間です
apply_lag 最近のWALをローカルに吐き出してから、このスタンバイサーバがそれを書き出し、吐き出し、そして適用したこ
との通知を受け取るまでの経過時間です。
■pg_stat_replicationビュー項目のマニュアルからの抜粋

© 2023 NTT DATA Corporation 9
write_lag、flush_lag、apply_lagの説明の補足
プライマリ スタンバイ
クライアント
①更新SQL
②WAL書込 ④WAL書込(write)
④’WAL書込(flush)
③WAL転送
⑤応答
⑥応答
❺リカバリ
・WAL書込にはバッファに書き込まれたが、ディスクへの書き込みが完了していない状態(WAL書込(write))とディスクへの書き込みま
で完了した状態(WAL書込(flush))がある。
・WAL書込(write)状態だとシステムクラッシュ等でデータが失われるリスクがあるが、WAL書込(flush)状態ではデータが失われない。
列名 マニュアルの説明 赤字状態の補足
write_lag 最近のWALをローカルに吐き出してから、このスタンバイサーバがそれを書き出した（が、
まだ吐き出したり適用したりしていない）ことの通知を受け取るまでの経過時間です。
④WAL書込(write)まで完了
flush_lag 最近のWALをローカルに吐き出してから、このスタンバイサーバがそれを書き出して吐き
出した（が、まだ適用していない）ことの通知を受け取るまでの経過時間です
④’WAL書込(flush)まで完了
apply_lag 最近のWALをローカルに吐き出してから、このスタンバイサーバがそれを書き出し、吐き
出し、そして適用したことの通知を受け取るまでの経過時間です。
❺リカバリまで完了(スタンバイか
らデータを参照可能になる）

© 2023 NTT DATA Corporation 10
レプリケーション遅延の計算方法と注意事項について
■レプリケーション遅延の計算方法
・「レプリケーション完了の応答メッセージをスタンバイからプライマリが受信した時刻」 - 「そのレプリケーション完了のLSN(Log
Sequence Number)のWALをプライマリが送信した時刻の近似値」
・スタンバイからレプリケーション完了の応答メッセージを受信するたびに計算される
■注意事項（遅延ポイントによっては計測できないケースがある）
・プライマリのディスクにWALが書き込まれてから、何かの問題でそのWALの送信が遅れている場合、その遅延は計測できない。
・ネットワークトラブル等でレプリケーション完了の応答メッセージがスタンバイから届かない場合、その間は更新されないため、古い
値がそのまま表示され続ける。
プライマリ スタンバイ
送信済WAL情報
(LSN,時刻)=(100,11:00),(200,12:00),(300,13:00)
LSN=100の完了メッセージを11:30に受信
例えばLSN=100の完了メッセージを11:30に受信した場合、遅延時間は11:30 – 11:00 = 30分と計算される。
※受信したLSNより前の情報が送信側(プライマリ)に残っていない場合、次のLSNの情報から時刻が近似計算される。このあたりは次の機会に詳しく解説したい。

© 2022 NTT DATA Corporation 11
© 2023 NTT DATA Corporation 11
03
レプリケーション遅延監視用SQLの例

© 2023 NTT DATA Corporation 12
SQLのサンプルについて
以下のような点を考慮して監視用のSQLを検討する
• write_lag、flush_lag、apply_lagはプライマリがスタンバイに追いつくと0ではなくNULLになる。
• write_lag、flush_lag、apply_lagの項目を監視目的、要件に応じて選定する。
➢ 単一の項目を返却してその数値を閾値と比較することでアラートをあげたい等
flush_lagの値を取得するSQLのサンプル
→flush_lagの値を閾値と比較するため、秒数で取得したい。NULLの場合は0として取得したいというケース。
SELECT EXTRACT(EPOCH FROM CASE WHEN flush_lag IS NULL THEN '00:00:00'::INTERVAL ELSE flush_lag END) AS replication_delay FROM pg_stat_replication;

© 2023 NTT DATA Corporation
その他、記載されている会社名、商品名、又はサービス名は、
各社の登録商標又は商標です。

© 2023 NTT DATA Corporation 14
参考文献
PostgreSQLマニュアル（公式ドキュメント(PG14版)、日本語ドキュメント）
• PostgreSQL: Documentation: 14: PostgreSQL 14.7 Documentation
• PostgreSQL 14.5文書