Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)

1,296 views

Published on

PostgreSQLレプリケーション10周年!徹底紹介!
(PostgreSQL Conference Japan 2019講演資料)

NTTデータ 技術開発本部
藤井 雅雄 (PostgreSQLコミッタ)

Published in: Technology
  • Personally I would choose her over any of the therapists I have seen over the years that I was willing to pay $25+ an hour for. You get the help from a person who has been there and done that, and you also get the opportunity to be social with a group of ladies who are right there with you. Two things I think are extremely important. ▲▲▲ http://t.cn/A6Pq6OB6
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)

  1. 1. © 2019 NTT DATA Corporation 1 © 2019 NTT DATA Corporation PostgreSQL Conference Japan 2019 PostgreSQLレプリケーション10周年!徹底紹介!! 2019年11月15日 株式会社NTTデータ PostgreSQLコミッタ 藤井雅雄 @fujii_masao
  2. 2. © 2019 NTT DATA Corporation 2 藤井 雅雄 @fujii_masao PostgreSQLエンジニア @ NTTデータ 社内 PostgreSQL 技術支援・営業 PostgreSQLコミッタ レプリケーション(非同期 / 同期 / カスケード / クォーラムコミット) WAL圧縮 pg_bigm(全文検索モジュール)コミッタ 自己紹介
  3. 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. 4. © 2019 NTT DATA Corporation 4 本講演について 講演資料は、後日、NTTデータのSlideShareアカウント上で公開予定です。 https://www.slideshare.net/nttdata-tech 特に断りのないかぎり、講演で取り上げる機能や仕様は PostgreSQL 12 のものになります。
  5. 5. © 2019 NTT DATA Corporation 5 アジェンダ レプリケーションとは ストリーミングレプリケーションの基本 ストリーミングレプリケーションの非同期・同期 スタンバイでのSQL実行 ストリーミングレプリケーションの監視 PostgreSQL12以降でストリーミングレプリケーションを使うときの注意 最後に
  6. 6. © 2019 NTT DATA Corporation 6 レプリケーションとは
  7. 7. © 2019 NTT DATA Corporation 7 レプリケーションとは? クライアントクライアント 更新更新 DBサーバ 更新 複製 DBサーバ 更新 中継サーバ 複数のサーバにデータベースを自動的に複製する機能
  8. 8. © 2019 NTT DATA Corporation 8 なぜレプリケーションが必要か? 24時間365日システムを安定運用するのに必要! 高可用性 負荷分散 1台が故障しても、別サーバが処理を引き継げる システム全体としてDBサービスが停止するのを回避できる SQL実行の負荷を複数のサーバに分散できる 負荷が一箇所に集中しないので、システム全体として性能向上できる クライアントクライアント SQL SQLSQL 高可用 負荷分散 DBサーバ DBサーバ
  9. 9. © 2019 NTT DATA Corporation 9 PostgreSQLで利用可能なレプリケーション ストリーミングレプリケーション (物理レプリケーション) 2010年リリースのPostgreSQL9.0から利用可能 ロジカルレプリケーション (論理レプリケーション) 2017年リリースのPostgreSQL10から利用可能 PostgreSQL関連製品によるレプリケーション 例えば、pgpool-II、Slonyなど その他製品によるレプリケーション 例えば、DRBDのディスク同期によるレプリケーションなど 今回は、10周年記念のストリーミングレプリケーションについて徹底紹介します!
  10. 10. © 2019 NTT DATA Corporation 10 ストリーミングレプリケーションの基本
  11. 11. © 2019 NTT DATA Corporation 11 マスタ・スタンバイ方式 クライアントクライアント DBサーバ 複製 マスタ 中継サーバ スタンバイ • マスタでのデータベースの更新結果をスタンバイにレプリケーション(複製) • マスタでは、更新SQLと参照SQLを実行可能 • スタンバイでは、参照SQLのみ実行可能 更新SQL 参照SQL 参照SQL更新SQL 参照SQL 更新SQL 参照SQL 更新SQL 参照SQL マスタ・スタンバイ方式
  12. 12. © 2019 NTT DATA Corporation 12 シングルマスタ・マルチスタンバイ構成 • マスタは1台のみ、スタンバイは複数台 • カスケードレプリケーション(スタンバイからスタンバイへのレプリケーション) • 更新SQLを実行可能なマスタは1台のみのため、更新スケールアウトには使えない • 参照SQLを実行可能なスタンバイは複数台構成できるため、参照スケールアウトには使える シングルマスタ マルチスタンバイ マルチスタンバイ 複製 複製 更新SQL 参照SQL 参照SQL 参照SQLクライアント
  13. 13. © 2019 NTT DATA Corporation 13 ログシッピング • マスタは、データベースの変更情報としてトランザクションログ(WAL)をスタンバイに転送 • スタンバイは、転送されたWALをリカバリすることでデータベースを複製 マスタとスタンバイのデータベースの内容は物理的に同じ ⑤リカバリ マスタ スタンバイ クライアント①更新SQL ②WAL書込 ③WAL転送 ④WAL書込
  14. 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. 15. © 2019 NTT DATA Corporation 15 データベースクラスタ単位のレプリケーション • すべてのデータベースオブジェクトが基本的にレプリケーション対象 • テーブル単位のレプリケーション指定は不可 • テーブル単位のレプリケーションにはロジカルレプリケーションを利用 データベースクラスタ単位 テーブル単位 マスタ スタンバイ マスタ スタンバイ
  16. 16. © 2019 NTT DATA Corporation 16 スタンバイのマスタへの昇格 • スタンバイはいつでもマスタに昇格可能 • 新しいスタンバイをいつでも構成に組み込むことが可能 マスタ スタン バイ レプリケーション構成 スタンバイ単独 停止 スタン バイ 停止 マスタ マスタ単独 マスタ故障 マスタへの昇格 スタンバイ 再組み込み マスタ レプリケーション構成 スタン バイ
  17. 17. © 2019 NTT DATA Corporation 17 フェイルオーバ PostgreSQLは自動的なフェイルオーバ機能を提供しない • 自動的なフェイルオーバにはクラスタソフトと要連携 クライアントクライアント マスタ pgpool-II スタンバイマスタ スタンバイ Pacemaker pgpool-II VIP
  18. 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. 19. © 2019 NTT DATA Corporation 19 アーキテクチャ walsender walreceiver startup データベース クライアント ②変更 ③書き込み WAL WAL ⑤読み込み ⑥WAL転送 ⑦書き込み ❾読み込み ❿リカバリ ⓬参照 ①更新Tx ⓫参照Tx backendbackendbackend backendbackendbackend マスタ スタンバイ データベース ディスク領域メモリ領域プロセス 凡例 ⑩応答 ⑨応答 ⑧応答 ④通知 ❽通知 ⓭結果
  20. 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. 21. © 2019 NTT DATA Corporation 21 ストリーミングレプリケーションの 非同期・同期
  22. 22. © 2019 NTT DATA Corporation 22 非同期・同期レプリケーションの概要 マスタ マスタ スタンバイ スタンバイ クライアント クライアント 非同期はスタンバイへのレプリケーション完了を待たない 同期はスタンバイへのレプリケーション完了を待つ ①更新 ②複製 ③成功応答 ④複製完了 ①更新 ②複製 ③複製完了 ④成功応答
  23. 23. © 2019 NTT DATA Corporation 23 同期レプリケーション • COMMIT時にレプリケーションの完了を待つ • COMMIT成功時にWALがマスタ・スタンバイ両方に書き込み済と保証 • フェイルオーバ時にCOMMIT済データを失わない! • レプリケーション完了を待つので比較的低性能 リカバリ マスタ スタンバイ クライアント①COMMIT ②WAL書込 ③WAL転送 ④WAL書込 ⑥OK ⑤応答  
  24. 24. © 2019 NTT DATA Corporation 24 非同期レプリケーション • COMMIT時にレプリケーションの完了を待たない • COMMIT成功時にWALがスタンバイに届いている保証なし フェイルオーバ時にCOMMIT済データを失う可能性あり レプリケーション完了を待たないので比較的高性能!   ⑥リカバリ マスタ スタンバイ クライアント①COMMIT ②WAL書込 ④WAL転送 ⑤WAL書込 ③OK ③と④の間で フェイルオーバが発生すると、 COMMIT済データを失う
  25. 25. © 2019 NTT DATA Corporation 25 非同期・同期レプリケーションの使い分け例 同期マスタ 高可用向けスタンバイ 負荷分散向けスタンバイ 災対向けスタンバイ 非同期 非同期 フェイルオーバ時に データを失わないように、 高可用向けには 同期レプリケーションを利用 データセンタ(ローカル) データセンタ(遠隔地) 更新SQL 参照SQL 少し古いデータを参照できれば十分であれば、 負荷分散向けには性能オーバーヘッドの小さい 非同期レプリケーションを利用 参照SQL クライアント 遠隔へのレプリケーションを待つと 性能が大幅劣化するため、 災対向けには非同期レプリケーションを利用 災対向けスタンバイ
  26. 26. © 2019 NTT DATA Corporation 26 synchronous_standby_names どのスタンバイを同期レプリケーションの対象とするかは synchronous_standby_names で設定 synchronous_standby_names = '[FIRST | ANY ] NUM (NAME1, NAME2, ...)‘ 同期スタンバイの台数 同期スタンバイの名前のリスト同期スタンバイを選ぶ方式 ※名前のないスタンバイは非同期
  27. 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. 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. 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. 30. © 2019 NTT DATA Corporation 30 synchronous_standby_namesの設定例3 • 1台のスタンバイ S1 に対して同期レプリケーションを設定 synchronous_standby_names = 'FIRST 1 (S1)' または 'ANY 1 (S1)' マスタ スタンバイ 同期 S1
  31. 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. 32. © 2019 NTT DATA Corporation 32 スタンバイでのSQL実行
  33. 33. © 2019 NTT DATA Corporation 33 マスタ・スタンバイ方式(再掲) クライアントクライアント DBサーバ 複製 マスタ 中継サーバ スタンバイ • マスタでのデータベースの更新結果をスタンバイにレプリケーション(複製) • マスタでは、更新SQLと参照SQLを実行可能 • スタンバイでは、参照SQLのみ実行可能 更新SQL 参照SQL 参照SQL更新SQL 参照SQL 更新SQL 参照SQL 更新SQL 参照SQL マスタ・スタンバイ方式
  34. 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. 35. © 2019 NTT DATA Corporation 35 スタンバイで参照できるデータ • スタンバイで参照できるデータが古い(COMMIT済の最新データは見えない)可能性がある • COMMIT済の最新データをすぐにスタンバイで参照するには、 synchronous_commit = remote_apply の同期レプリケーションを利用する ⑦リカバリ マスタ スタンバイ クライアント①COMMIT ③WAL転送 ⑤OK ④応答 ⑥参照SQL ⑤でCOMMIT完了とクライアントが認識した データについて、⑦のリカバリが未実施のため、 ⑥の参照SQLでは参照できない
  36. 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. 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. 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. 39. © 2019 NTT DATA Corporation 39 ストリーミングレプリケーションの 監視
  40. 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. 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. 42. © 2019 NTT DATA Corporation 42 PostgreSQL12以降で ストリーミングレプリケーションを 使うときの注意
  43. 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. 44. © 2019 NTT DATA Corporation 44 最後に
  45. 45. © 2019 NTT DATA Corporation 45 最後に ストリーミングレプリケーションは10周年記念 10年間で、機能がノウハウなど揃いつつある しかし、まだ機能不足や使いづらい点もあり、、、 次の10年間の開発に向けて、レプリケーションに関する要望などについてぜひ会話させてください!
  46. 46. © 2019 NTT DATA Corporation本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。
  47. 47. © 2019 NTT DATA Corporation 47 その他機能
  48. 48. © 2019 NTT DATA Corporation 48 旧マスタの再組み込み 9.4以前では、旧マスタの再組み込みにはフルバックアップの転送が必須 レプリケー ション マスタ スタン バイ 停止 マスタ マスタスタン バイ レプリケー ション 停止 マスタ 両系稼働 マスタ単独稼働 両系稼働 フルバックアップ転送 マスタ故障により フェイルオーバ 旧マスタの再組込み フル バック アップ
  49. 49. © 2019 NTT DATA Corporation 49 旧マスタの再組み込み(pg_rewind) 9.5以降では、pg_rewindにより、旧マスタの再組み込み時にDBデータを差分バックアップ転送できる レプリケー ション マスタ スタン バイ 停止 マスタ マスタスタン バイ レプリケー ション 停止 マスタ 差分 バック アップ 両系稼働 マスタ単独稼働 両系稼働 差分バックアップ転送 マスタ故障により フェイルオーバ pg_rewind 旧マスタの再組込み
  50. 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. 51. © 2019 NTT DATA Corporation 51 リカバリの一時停止・再開 • pg_wal_replay_pause() - 関数実行により、即座にリカバリを一時停止する 一時停止するのはリカバリのみで、WALの受信や書き込みは停止しない synchronous_commit=remote_applyとの相性が悪い。。 • pg_wal_replay_resume() - 関数実行により、一時停止しているリカバリを再開する • 例えば、スタンバイのデータベースを特定の状態のまま固定化して、その上で処理を行いたい場合に有用
  52. 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. 53. © 2019 NTT DATA Corporation 53 pg_receivewal • マスタに接続して、WALの受信と書き込みを繰り返すクライアントツール • スタンバイから walreceiver だけをツール化したイメージ • 例えば、リアルタイムなWALのアーカイブに利用できる walsender pg_receivewal データベース クライアント 変更 書き込み WAL 読み込み WAL転送 書き込み 更新Tx backendbackendbackend サーバ 応答 通知 アーカイブ
  54. 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カラムで発生回数を 確認できる

×