PostgreSQLレプリケーション10周年！徹底紹介！（PostgreSQL Conference Japan 2019講演資料）
•
12 likes•12,682 views
PostgreSQLレプリケーション10周年！徹底紹介！ （PostgreSQL Conference Japan 2019講演資料） NTTデータ 技術開発本部 藤井 雅雄 (PostgreSQLコミッタ)
Report
Share
PostgreSQLレプリケーション10周年！徹底紹介！（PostgreSQL Conference Japan 2019講演資料）
- 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カラムで発生回数を 確認できる