レプリケーション遅延の監視について（第40回PostgreSQLアンカンファレンス@オンライン 発表資料）
- 1. © 2023 NTT DATA Corporation レプリケーション遅延の監視について 2023年 3月 16日 第40回PostgreSQLアンカンファレンス@オンライン 株式会社NTTデータ 技術開発本部 貞弘 泰輔
- 2. © 2023 NTT DATA Corporation 2 自己紹介 貞弘 泰輔 【経歴】 ・5年くらいメインフレームのマイグレーション関連の開発を経験（PostgreSQLに触れる機会はなかった） ・5年くらいPostgreSQLを使ったシステム開発を経験 ・PostgreSQLにもっと詳しくなりたいと思い研究開発チームに異動
- 3. © 2023 NTT DATA Corporation 3 本講演について • 講演資料はNTTデータのSlideShareで公開しています。 • https://www.slideshare.net/nttdata-tech • 本講演では、レプリケーション遅延の監視について説明します • レプリケーション遅延監視の目的 • 遅延の確認方法（pg_stat_replicationビュー) • レプリケーション遅延監視用SQLの例
- 4. © 2022 NTT DATA Corporation 4 © 2023 NTT DATA Corporation 4 レプリケーション遅延監視の目的
- 5. © 2023 NTT DATA Corporation 5 前提とする構成について ・プライマリ、スタンバイの2台構成 ・プライマリのデータベースの更新結果をスタンバイにレプリケーション(複製) クライアント 複製 同期or非同期レプリケーション プライマリ スタンバイ 参照SQL 更新SQL 参照SQL この遅延を監視したい
- 6. © 2023 NTT DATA Corporation 6 同期/非同期レプリケーションにおける遅延監視の目的について ・同期、非同期で遅延監視の目的が異なる プライマリ スタンバイ クライアント レプリケーション 遅延監視の目的 同期 データ同期は保証されているため、応答時間にどの程度影響があるのかを知りたい。 非同期 どの程度プライマリとスタンバイのデータが乖離しているのかを知りたい。 例えばシステム要件のRPO(目標復旧地点）が１分以内だった場合、１分以上遅延が発生していないか等。 ①更新SQL ②WAL書込 ❹WAL書込 ❸WAL転送 ❻応答 ③応答 ❺リカバリ ①更新SQL ②WAL書込 ④WAL書込 ③WAL転送 ⑤応答 ⑥応答 ❺リカバリ 同 期 非 同 期 ○数字と●数字は並列処理
- 7. © 2022 NTT DATA Corporation 7 © 2023 NTT DATA Corporation 7 02 レプリケーション遅延の確認方法
- 8. © 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ビュー項目のマニュアルからの抜粋
- 9. © 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をローカルに吐き出してから、このスタンバイサーバがそれを書き出し、吐き 出し、そして適用したことの通知を受け取るまでの経過時間です。 ❺リカバリまで完了(スタンバイか らデータを参照可能になる）
- 10. © 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の情報から時刻が近似計算される。このあたりは次の機会に詳しく解説したい。
- 11. © 2022 NTT DATA Corporation 11 © 2023 NTT DATA Corporation 11 03 レプリケーション遅延監視用SQLの例
- 12. © 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;
- 13. © 2023 NTT DATA Corporation その他、記載されている会社名、商品名、又はサービス名は、 各社の登録商標又は商標です。
- 14. © 2023 NTT DATA Corporation 14 参考文献 PostgreSQLマニュアル（公式ドキュメント(PG14版)、日本語ドキュメント） • PostgreSQL: Documentation: 14: PostgreSQL 14.7 Documentation • PostgreSQL 14.5文書