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のレプリケーション

14,992 views

Published on

OSSコンソーシアム DB比較セミナー(2018/1/26)での講演資料です。

Published in: Technology
  • Be the first to comment

アーキテクチャから理解するPostgreSQLのレプリケーション

  1. 1. Copyright©2018 NTT Corp. All Rights Reserved. アーキテクチャから理解する PostgreSQLのレプリケーション NTT OSSセンタ 澤田 雅彦
  2. 2. 2Copyright©2018 NTT Corp. All Rights Reserved. 自己紹介 澤田 雅彦 @sawada_masahiko NTT OSSセンタ PostgreSQLの技術サポート PostgreSQLの本体開発 PostgreSQLの周辺ツール開発  pg_repack – オンラインメンテナンスツール  pg_bigm – 2-gram全文検索モジュール
  3. 3. 3Copyright©2018 NTT Corp. All Rights Reserved. • PostgreSQLのアーキテクチャについて簡単におさらい • Replicationについて • Streaming Replicationを理解する • 設定、構築、運用など • Logical Replicationを理解する • 設定、構築、運用など Index
  4. 4. 4Copyright©2018 NTT Corp. All Rights Reserved. PostgreSQLのアーキテクチャ
  5. 5. 5Copyright©2018 NTT Corp. All Rights Reserved. • プロセスモデル • Postmasterプロセス:接続の受付、Backendプロセスのforkなどを行う • Backendプロセス : SQLを処理するプロセス • Background Worker (bg worker)プロセス : 任意の処理を定義できるプロセス PostgreSQLのアーキテクチャ DBデータ (テーブル、インデックスなど) 共有バッファ WALバッファ WAL (トランザクションログ) backendbackendbackend (postgres) postmaster wal writer bg writer auto vacuum stat collector logger archiver wal receiver wal sender wal sender wal sender wal sender wal senderbg worker その他 制御情報 startup
  6. 6. 6Copyright©2018 NTT Corp. All Rights Reserved. Replicationについて
  7. 7. 7Copyright©2018 NTT Corp. All Rights Reserved. • データを複数のマシンにコピーすること • 一つに障害が起きても動き続けられる • データのコピーを各ユーザに近い場所に配置することも可能 • データのコピーに対して読み込みクエリを発行することも可能 • マスタとスタンバイ • プライマリとスレーブ、リーダーとフォロワーなど呼び方は色々 • レプリケーショントポロジー データベース・レプリケーションとは?
  8. 8. 8Copyright©2018 NTT Corp. All Rights Reserved. 何を複製(Replication)するか? UPDATE tbl SET price = 100 WHERE id = ‘ABC000’; Log shipping 97d0 0700 1800 ef12 0300 55b1 0300 54b1 0300 0000 0000 0000 ... Statement-based “UPDATE tbl SET price = 100 WHERE id = ‘ABC000’;” Row-based Table : tbl Row : id = ‘ABC000’, price = 100 Master Standby Client Logical Replication はこれ↓ Streaming Replication はこれ↓
  9. 9. 9Copyright©2018 NTT Corp. All Rights Reserved. Streaming Replicationを理解する
  10. 10. 10Copyright©2018 NTT Corp. All Rights Reserved. Streaming Replicationの基本的なアーキテクチャ WAL WAL Write WAL Send WAL COMMIT Write WAL OK Apply WAL • マスタはWALを送り続ける • スタンバイはリカバリをし続ける • 物理的に同じデータベースを複製する 一台のときの 処理 レプリケーショ ン構成での処理
  11. 11. 11Copyright©2018 NTT Corp. All Rights Reserved. backend より詳細に WAL WAL backend wal sender wal receiver startup Table Table 1. Write 1. Modify 3. Read 4. Send OK (LSNs) 6. Notify 5. Write 7. Read 8. Apply • 処理の順番 1. backendプロセスがWALを書き、wal senderプロセスに通知 2. wal senderプロセスはwal receiverプロセスにWALを送る 3. wal receiverプロセスはWALを受信後、startupプロセスに通知 • スタンバイではリカバリをし続けている状態(startupプロセス) • スタンバイはマスタにLSN(どこまでWALを受信したか)を返す 2. Notify
  12. 12. 12Copyright©2018 NTT Corp. All Rights Reserved. • WALを複製+スタンバイでリカバリすることでDBを複製する • 物理的に全く同じDBが出来上がる • スタンバイではDBを変更するような操作はできない(Read-Only) • メジャーバージョンを跨いだレプリケーションはできない • 1:Nのレプリケーションのみ可能 • トランザクションの途中でも、生成されたWALは随時複製される (”Streaming” Replication) • ロールバックされた変更情報も複製される • スタンバイはマスタに昇格(Promote)可能 • プロセス間のデータ連携は共有メモリやWALファイルで行う Streaming Replication - 特徴まとめ
  13. 13. 13Copyright©2018 NTT Corp. All Rights Reserved. 使い方(設定、設計編)
  14. 14. 14Copyright©2018 NTT Corp. All Rights Reserved. • 最低限必要なパラメータ(マスタ側) • wal_level = replica(デフォルト) or logical • max_wal_senders > 0 • レプリケーション接続を許可(pg_hba.conf) • その他関連するパラメータ • max_replication_slots • wal_keep_segments • hot_standby • hot_standby_feedback • synchronous_standby_names • wal_sender_timeout • wal_receiver_timeout • wal_log_hints など(たくさんある) 使い方(設定編)
  15. 15. 15Copyright©2018 NTT Corp. All Rights Reserved. • 非同期レプリケーション • スタンバイでのWAL書き込みを待たない • 同期レプリケーション • スタンバイでのWAL書き込みを待つ 同期、非同期の選択 性 能 信 頼 性
  16. 16. 16Copyright©2018 NTT Corp. All Rights Reserved. 非同期レプリケーション • スタンバイにWALを非同期的に送る • COMMITはスタンバイでのWAL書き込みを待たない • マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない data change OK Time Client Master Standby OKdata change
  17. 17. 17Copyright©2018 NTT Corp. All Rights Reserved. 非同期レプリケーション OK Time Client Master Standby old value data change read data Become a new master • スタンバイにWALを非同期的に送る • COMMITはスタンバイでのWAL書き込みを待たない • マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない
  18. 18. 18Copyright©2018 NTT Corp. All Rights Reserved. 同期レプリケーション • COMMITはスタンバイでのWAL書き込みを待つ • マスタでCOMMIT済み(COMMIT OKとなったデータ)は、マスタ、スタンバ イの両方に存在することを保証する data change OK OK Time Client Master Standby waiting for standby flush data change
  19. 19. 19Copyright©2018 NTT Corp. All Rights Reserved. synchronous_commit = [ off | local | remote_write | on | remote_apply ] • remote_writeは、WALのメモリ書き込みまで待つ • 「MySQLでの準同期」=「PostgreSQLの同期(synchronous_commit = on)」 トランザクション単位での設定 data change OK OK Time Client Master Standby waiting for standby... write applyflush OK OK
  20. 20. 20Copyright©2018 NTT Corp. All Rights Reserved. • スタンバイがスタンバイを持てる • カスケード・スタンバイは非同期レプリケーションのみ使用可能 カスケード構成 Master Standby (sync) Standbys (async) Cascading Standbys (async) Cascading Standbys (async)
  21. 21. 21Copyright©2018 NTT Corp. All Rights Reserved. • synchronous_standby_namesパラメータをマスタ側で設定 • 複数のスタンバイに対して同期レプリケーションを利用できる • 2つの方法を用意 • Priority-based (9.6~) • Quorum-based (10~) 複数の同期スタンバイ構成 Master Standby (sync) Master Standbys (quorum) Priority-based Quorum-based 予め指定した2つの 同期スタンバイ からのOKを待つよ 5つの内どれか 2つからのOKを 待つよ Standby (async)
  22. 22. 22Copyright©2018 NTT Corp. All Rights Reserved. • スタンバイでのリカバリを”あえて”遅らせる • オペミス起因のデータ損失等に対応できる • recovery_min_apply_delayで遅延時間を指定可能 • 「WALは受け取っているがリカバリはしてない」という状態になる • synchronous_commit = remote_applyを使用しているときは要注意 • 遅らせた分がそのままトランザクション処理の遅延に影響する 遅延レプリケーション
  23. 23. 23Copyright©2018 NTT Corp. All Rights Reserved. 使い方(構築編)
  24. 24. 24Copyright©2018 NTT Corp. All Rights Reserved. 必要なのは以下の3ステップ 1. マスタサーバから物理バックアップを取得 • DB停止 → 物理コピー → DB起動 • pg_start_backup関数 → 物理コピー → pg_stop_backup関数 • pg_basebackup • ※論理バックアップは利用できない 2. スタンバイサーバの設定 3. スタンバイサーバを起動 使い方(構築編)
  25. 25. 25Copyright©2018 NTT Corp. All Rights Reserved. • 設定必須なパラメータ • standby_mode = on • primary_conninfo = ‘マスタサーバへの接続情報’ • primary_conninfo = ‘host=xxx port=yyy dbname=zzz user=xxx’ • 必要に応じて • primary_sloname • recovery_target_timeline • trigger_file スタンバイサーバの設定
  26. 26. 26Copyright©2018 NTT Corp. All Rights Reserved. 使い方(監視編)
  27. 27. 27Copyright©2018 NTT Corp. All Rights Reserved. =# SELECT application_name, sent_lsn, write_lsn, flush_lsn, replay_lsn, write_lag, flush_lag, replay_lag, sync_state, state FROM pg_stat_replication ; -[ RECORD 1 ]----+---------------- application_name | node1 sent_lsn | 0/46349B8 write_lsn | 0/46349B8 flush_lsn | 0/46349B8 replay_lsn | 0/46349B8 write_lag | 00:00:00.010832 flush_lag | 00:00:00.017551 replay_lag | 00:00:00.21462 sync_state | sync state | streaming -[ RECORD 2 ]----+---------------- application_name | node2 sent_lsn | 0/46349B8 write_lsn | 0/46349B8 flush_lsn | 0/46349B8 replay_lsn | 0/46349B8 : マスタ側からの監視 LSNで送信状況、受信状況を 確認(バイト数でラグが確認でき る) レプリケーション遅延を時間で表 示(v10~)
  28. 28. 28Copyright©2018 NTT Corp. All Rights Reserved. =# SELECT received_lsn, last_msg_send_time, last_msg_receipt_time, latest_end_time FROM pg_stat_wal_receiver; -[ RECORD 1 ]---------+------------------------------ received_lsn | 0/46381F8 last_msg_send_time | 2018-01-18 10:39:30.151872+09 last_msg_receipt_time | 2018-01-18 10:39:30.15193+09 latest_end_time | 2018-01-18 10:39:30.151872+09 スタンバイ側からの監視
  29. 29. 29Copyright©2018 NTT Corp. All Rights Reserved. 使い方(参照負荷分散)
  30. 30. 30Copyright©2018 NTT Corp. All Rights Reserved. • Streaming Replicationで参照負荷分散は可能 • pgpool-IIやPgBouncerを利用して振り分ける事が多い • ホットスタンバイで使用する際に注意すべき点は、以下の3つ • 参照結果の整合性 • レプリケーション競合 • マスタでのデータ肥大化 ホットスタンバイ(参照負荷分散)
  31. 31. 31Copyright©2018 NTT Corp. All Rights Reserved. • synchronous_commit = ‘remote_apply’ • COMMITは、スタンバイでWALが書き込み+リカバリされる (=ユーザに変更結果が見えるようになるまで)まで待つ Reading Your Own Writes OK Time Client Master Standby write & flush apply OK INSERT INTO tbl ... Read previous writes No result! data change
  32. 32. 32Copyright©2018 NTT Corp. All Rights Reserved. Reading Your Own Writes OK Time Client Master Standby write & flush apply OK INSERT INTO tbl ... Read Found! data change wait for data to be applied • synchronous_commit = ‘remote_apply’ • COMMITは、スタンバイでWALが書き込み+リカバリされる (=ユーザに変更結果が見えるようになるまで)まで待つ
  33. 33. 33Copyright©2018 NTT Corp. All Rights Reserved. • 何が競合するか? • クエリ処理とリカバリ • スタンバイでの参照 vs その参照しているデータの物理削除 (をするWALのリカバリ) • スタンバイでの参照 vs その参照しているテーブルへの排他ロック (を取得するWALのリカバリ) • スタンバイでの参照 vs その参照しているデータベースの削除 (をするWALのリカバリ) レプリケーション競合
  34. 34. 34Copyright©2018 NTT Corp. All Rights Reserved. • マスタでパラメータを設定することで、物理削除起因のレプリケーション競合を防ぐ ことができる • マスタ側で設定 • vacuum_defer_cleanup_age • 物理削除のタイミングを遅らせる • スタンバイ側で設定 • hot_standby_feedback • スタンバイの活動状況をマスタに通知する • スタンバイが参照してる可能性のあるデータの物理削除をしないようにする • スタンバイでのロングトランザクションに注意 レプリケーション競合を防ぐ
  35. 35. 35Copyright©2018 NTT Corp. All Rights Reserved. • リカバリを優先したい! • レプリケーション遅延をなるべく起こしたくない • スタンバイのWAL領域溢れを防ぎたい • クエリ処理を優先したい! • スタンバイで分析系SQLを実行したい • スタンバイで論理バックアップを取得したい • max_standby_streaming_delayで設定する • -1 : クエリが完了するまで待つ(クエリ優先) • >= 0 : 設定値以上たったらクエリをキャンセル(リカバリ優先) クエリ処理を優先する?リカバリを優先する?
  36. 36. 36Copyright©2018 NTT Corp. All Rights Reserved. • 遅延するとスタンバイで見えるデータが古い • かつ、レプリケーションが継続できなくなる レプリケーション遅延 -- WAL受信自体が遅れている sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag -----------+-----------+-----------+------------+-----------------+-----------------+----------------- 0/A060000 | 0/A000000 | 0/A000000 | 0/9F90968 | 00:00:21.729059 | 00:00:21.729059 | 00:00:23.218801 (1 row) -- 受信はできているがリカバリが遅れている sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag -----------+-----------+-----------+------------+-----------------+-----------------+---------------- 0/799CCC0 | 0/799CCC0 | 0/799CCC0 | 0/78F76C8 | 00:00:00.000149 | 00:00:00.000475 | 00:00:21.75451 (1 row)
  37. 37. 37Copyright©2018 NTT Corp. All Rights Reserved. • 必要なWALがマスタ上でリサイクル(アーカイブ)されてしまう • “FATAL: could not receive data from WAL stream ERROR: requested WAL segment 000000010000000000000007 has already been removed” • スタンバイを一時的に停止していた場合にもよく発生する • 解決策 • restore_command = ‘scp hostname:/path/to/%f %p’ • アーカイブWALから必要なWALを持ってくる • ただし、アーカイブされたWALも削除された場合はどうする? • wal_keep_segments • マスタ側で余分にWALを持っておく • ただし、想定以上のWALが生成されたらどうする? レプリケーション遅延の影響
  38. 38. 38Copyright©2018 NTT Corp. All Rights Reserved. • スタンバイが必要としてるWALを”絶対に”削除しない • 設定方法 • マスタ側でレプリケーションスロット作成 • pg_physical_replication_slot関数 • スタンバイ側でレプリケーションスロットを使うように設定 • primary_slot_name(recovery.conf内) • スタンバイが受信するまでWALを持ち続けるので、ディスクフルに 注意 • うっかり消し忘れる事が多い レプリケーションスロット
  39. 39. 39Copyright©2018 NTT Corp. All Rights Reserved. • コミュニティ提供の自動昇格機能がない! • PG-REX、pgpool-II、repmgr、PAF等を使う事が多い • マスタサーバを復旧し、起動。または、スタンバイサーバを昇格 • 昇格(Promote)方法は2つ • pg_ctl promote • trigger_file マスタサーバがダウン・・・どうする?
  40. 40. 40Copyright©2018 NTT Corp. All Rights Reserved. • マスタサーバ回復後、新しいスタンバイとして利用したい • 更にその後、マスタとスタンバイを元の関係に戻したい(スイッチバック)と きもある • 旧マスタはそのままは使えない事に注意 • 同期レプリケーションの場合でも使えないことに注意 旧マスタサーバの再利用 マスタ スタンバイ 最初の マスタサーバ 最初の スタンバイサーバ ここからは 新しいマスタサーバ サーバ間で物理的に異 なる可能性がある部分
  41. 41. 41Copyright©2018 NTT Corp. All Rights Reserved. • 旧マスタサーバ再利用のための方法は2つ 1. 新しいマスタサーバのバックアップを取り直して、スタンバ イを再構築 2. pg_rewindを使う ではどうするか?
  42. 42. 42Copyright©2018 NTT Corp. All Rights Reserved. • 新しいマスタから物理バックアップを再取得する • 再取得したバックアップを使ってスタンバイとして起動 • スイッチバック(マスタ正常終了の後に切り替え)する時は、バックアップは必要ない • データベースが大きいと時間が掛かる 1. バックアップを取り直す Master Standby New Master Replication Replication full backup Master MasterStandby
  43. 43. 43Copyright©2018 NTT Corp. All Rights Reserved. • 旧マスタの状態を巻き戻して(rewind)して、再利用する • サーバ間の差分を転送するだけで良いので短い時間で済む • wal_log_hintsもしくはchecksumの設定が必要 2. pg_rewindを使う(v9.5 ~) Master Standby New Master Replication Replication send only deltas Master MasterStandby pg_rewind
  44. 44. 44Copyright©2018 NTT Corp. All Rights Reserved. • 同期レプリケーションの場合、マスタサーバでの更新系トランザ クションは止まる • タイムアウト等は用意されていない • クエリのキャンセルは可能 • 同期待ちで止まっているプロセスは、ps コマンドでプロセスを見ると「XXX waiint for XXX/XXX」となっている • 外部ツールで検知して、非同期レプリケーションに変更する必要がある • synchronous_standby_namesを空にして、設定ファイルの再読込 スタンバイサーバがダウンしたらどうなる?
  45. 45. 45Copyright©2018 NTT Corp. All Rights Reserved. Logical Replicationを理解する
  46. 46. 46Copyright©2018 NTT Corp. All Rights Reserved. • データベースの一部を複製する • 複数ソースからの受信 • メジャーバージョンが異なるPostgreSQL間でのレプリケ ーション • Row-based • 初期データコピー • Publication / Subscription Logical Replication
  47. 47. 47Copyright©2018 NTT Corp. All Rights Reserved. • Partial replication (sending a subset of a database) • Consolidating multiple database into a single one • On-line major version updating • Sharing a subset of the database • Multi-master replication ユースケース
  48. 48. 48Copyright©2018 NTT Corp. All Rights Reserved. • Logical Replicationのインフラとなる機能 • WALを任意の形式にデコードする Logical Decoding BEGIN; CREATE TABLE tbl (c int primary key); INSERT INTO tbl VALUES (1), (2), (3); COMMIT; SELECT lsn, data FROM pg_logical_slot_get_changes('slot', pg_current_wal_lsn(), 10); lsn | data ------------+---------------------------------------- 1/331723E8 | BEGIN 242422 1/3317A778 | table public.tbl: INSERT: c[integer]:1 1/3317A848 | table public.tbl: INSERT: c[integer]:2 1/3317A8C8 | table public.tbl: INSERT: c[integer]:3 1/3317ABC0 | COMMIT 242422 (5 rows)
  49. 49. 49Copyright©2018 NTT Corp. All Rights Reserved. Logical Replicationの基本的なアーキテクチャ backend WAL WAL backend wal sender apply worker Table Table 1. Write 1. Modify 3. Read 4. Decode and Send OK (LSNs) 5. Write 5. Apply 2. Notify • Streaming Replicationと似ている • 違うところは、 • wal senderがWALをデコード、デコードしたデータを送信する • apply workerがデータを受信して、テーブルに反映
  50. 50. 50Copyright©2018 NTT Corp. All Rights Reserved. より詳細に WAL INSERT Write Read Decode COMMIT UPDATE UPDATE DELETE INSERTDELETE INSERT INSERT Reorder Buffer COMMIT Decode change_cb begin_cb commit_cb origin_cb pgoutput backendbackendbackend wal sender apply worker Logical Decoding Replication Slot slot_name = ‘slot’ plugin = ‘pgoutput’ restart_lsn = X/ABC000 :
  51. 51. 51Copyright©2018 NTT Corp. All Rights Reserved. • Logical Decoding(WALをデコードする機能)がベース • プラグインの書き方次第では、PostgreSQL→他DBMSというレプリケーションも可能 • Logical Replicationもプラグインの一つ • 論理的な変更情報(行単位)を送信している • RAND()とかCURRENT_TIMESTAMPとかも上流、下流で結果が異なる心配はない • 1:N、N:1、カスケードの構成が可能 • 双方向レプリケーションはテーブルが異なれば可能 • COMMITレコードをデコードした時に変更情報を送信する • COMMITされたトランザクション情報しか複製されない • テーブルのフィルタリングは上流で行う • 上流、下流で必ずしも同じテーブル定義である必要はない • 列数が異なっていてもOK • 下流のテーブルの列が足りないのはNG • 列のデータ型が異なっていてもOK • 変更データの転送はテキスト形式 アーキテクチャ特徴まとめ
  52. 52. 52Copyright©2018 NTT Corp. All Rights Reserved. 使い方(設定、設計編)
  53. 53. 53Copyright©2018 NTT Corp. All Rights Reserved. • 設定必須パラメータ • wal_level = logical • max_wal_senders > 0 • max_replication_slots > 0 • max_worker_processes > 0 • max_logical_replication_workers > 0 • 設定推奨パラメータ • max_sync_workers_per_subscriptions > 0 使い方(設定編)
  54. 54. 54Copyright©2018 NTT Corp. All Rights Reserved. • 基本的にはStreaming Replicationと同じ様に設定できる • Publisherのsynchronous_standby_namesにSubscriberのSubscription名 を入れる • synchronous_commitも同じように利用可能 • 同期レプリケーションを使うときの注意 • 同期、非同期の選択はサーバ単位 • テーブルの変更情報を受け取らないSubscriberからのACKも待つ • Publisherの同期COMMIT設定はONにしておく • クエリのレイテンシが大きくなりやすい • PostgreSQL 11で改善するかも 同期、非同期の選択
  55. 55. 55Copyright©2018 NTT Corp. All Rights Reserved. 使い方(構築編)
  56. 56. 56Copyright©2018 NTT Corp. All Rights Reserved. • Publicationに複数テーブルを設定する • Subscriber(受信側)は受信するPublicationを選択する Publication / Subscription Table A Table B Table C Table D Subscriber Subscriber pubA pubBPublisher
  57. 57. 57Copyright©2018 NTT Corp. All Rights Reserved. -- On publisher -- テーブル作成 CREATE TABLE tbl (k int primary key, v int); -- PUBLICATION作成し、tblを登録 CREATE PUBLICATION tbl_pub FOR TABLE tbl; -- データを入れる INSERT INTO tbl VALUES (1), (2), (3); 使い方(構築) -- On subscriber -- テーブルを作成(Subscriber側でも) CREATE TABLE tbl (k int primary key, v int); -- SUBSCRIPTIONを作成し、レプリケーション開始。 CREATE SUBSCRIPTION tbl_sub CONNECTION ‘...’ PUBLICATION tbl_pub; -- デフォルトで初期データコピーが有効なのでデータが非同期的にコピーされる SELECT * FROM tbl; c --- 1 2 3 (3 rows)
  58. 58. 58Copyright©2018 NTT Corp. All Rights Reserved. -- On publisher -- 対象テーブルを追加 ALTER PUBLICATION tbl_pub ADD TABLE tbl2; -- INSERTとUPDATEだけ複製するように変更 ALTER PUBLICATION tbl_pub SET (publish = ‘insert, update’); 使い方(対象テーブルを変更する) -- On subscriber -- テーブルを作成 CREATE TABLE tbl2 (id int primary key, name text); -- SUBSCRIPTIONを更新し、PUBLICATIONの変更を反映 ALTER SUBSCRIPTION tbl_sub REFRESH PUBLICATION tbl_pub WITH (copy_data = false);
  59. 59. 59Copyright©2018 NTT Corp. All Rights Reserved. • Streaming Replicationと同じ!! マスタ側からの監視方法
  60. 60. 60Copyright©2018 NTT Corp. All Rights Reserved. 使い方(監視編)
  61. 61. 61Copyright©2018 NTT Corp. All Rights Reserved. # SELECT * FROM pg_stat_subscription ; -[ RECORD 1 ]---------+------------------------------ subid | 16387 subname | hoge_sub pid | 57387 relid | received_lsn | 0/164A120 last_msg_send_time | 2018-01-23 10:40:56.95926+09 last_msg_receipt_time | 2018-01-23 10:40:56.959331+09 latest_end_lsn | 0/164A120 latest_end_time | 2018-01-23 10:40:56.95926+09 スタンバイ側からの監視方法
  62. 62. 62Copyright©2018 NTT Corp. All Rights Reserved. • 同一データに対する変更は「後勝ち方式」 • エラーが発生した場合は、成功するまでずっと繰り返す • 手動で解決する方法はある(pg_replication_origin_advance関数) • 競合をモニタリングする方法がない… レプリケーション競合
  63. 63. 63Copyright©2018 NTT Corp. All Rights Reserved. • INSERT/DELETE/UPDATEのみ対応 • DDL、シーケンス等は未対応 • レプリケーション・ラグが発生しやすい • 大きな変更を1トランザクションで実行する時は注意 • 同期レプリケーションの場合は特に注意 • 同期レプリケーションは使えるがDBインスタンス単位 • テーブル、Subscription、Publication単位での指定はできない • ハングするケースがいくつかある • 同時にCREATE SUBSCRIPTION ... WITH (create_slot = true) • 同時にALTER SUBSCRIPTION REFRESH PUBLICATION WITH (copy_data = ture) • など 現在(v10)の制約のまとめ
  64. 64. 64Copyright©2018 NTT Corp. All Rights Reserved. まとめ
  65. 65. 65Copyright©2018 NTT Corp. All Rights Reserved. • Streaming Replicationは10歳 • 利用事例多数 • 機能、周辺ツールが揃っている • Logical Replicationは0歳 • ポテンシャルは非常に高い • まだいくつか制約、使いづらい点がある • Streaming Replicationで使っている機能を利用することで、ユー ザにも使いやすい+コードを再利用できる まとめ
  66. 66. 66Copyright©2018 NTT Corp. All Rights Reserved. THANK YOU !!
  67. 67. 67Copyright©2018 NTT Corp. All Rights Reserved. 参考資料
  68. 68. 68Copyright©2018 NTT Corp. All Rights Reserved. Logical Replication開発の歴史 https://blog.2ndquadrant.com/bdr-history-and-future/
  69. 69. 69Copyright©2018 NTT Corp. All Rights Reserved. • データベースのベースバックアップ+WALを使って、任意の時点(~障害 直前の状態)にデータを復旧することが可能 PITR (Point In Time Recovery) WAL ② サーバダウンDB バッ クア ップ WAL ① CHECKPOINT ② WAL ① ①まで復旧:バックアップ+WAL① ②まで復旧:現在のDB+WAL② または、 バックアップ+WAL①、②

×