Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 速習！論理レプリケーション ～基礎から最新動向まで～（PostgreSQL Conference Japan 2022 発表資料）
Similar to 速習！論理レプリケーション ～基礎から最新動向まで～（PostgreSQL Conference Japan 2022 発表資料） (20)
More from NTT DATA Technology & Innovation
More from NTT DATA Technology & Innovation (20)
Recently uploaded
Recently uploaded (9)
速習！論理レプリケーション ～基礎から最新動向まで～（PostgreSQL Conference Japan 2022 発表資料）
- 1. © 2022 NTT DATA Corporation 【B1】 速習！論理レプリケーション ～基礎から最新動向まで～ 2022年11月11日 PostgreSQL Conference Japan 2022 株式会社NTTデータ 技術開発本部先進コンピューティング技術センタ 鳥越 淳 @atorik_shi
- 2. © 2022 NTT DATA Corporation 2 自己紹介 • 鳥越 淳(とりこし あつし) @atorik_shi • 2008年頃からオープンソースソフトウェア、近年はPostgreSQLを扱っています • 『PostgreSQL徹底入門 第4版』(翔泳社)8～13章執筆 • 『LPI-JAPAN OSS-DB道場 PostgreSQLの新機能 バージョン10以降』執筆/監修 https://oss-db.jp/dojo • Kubernetesはじめました • 『@IT Kubernetesでもデータベースを本格運用 ―― 「PostgreSQL Operator PGO」を使い倒す』 執筆 https://atmarkit.itmedia.co.jp/ait/articles/2208/10/news007.html
- 3. © 2022 NTT DATA Corporation 3 目次 v.10で導入された論理レプリケーションの基本、仕組み、v.15までの進化、 今後についてご紹介します • 論理レプリケーションの概要 • 論理レプリケーションの仕組み • 論理レプリケーションのこれから 新機能は 随時ご紹介
- 4. © 2022 NTT DATA Corporation 4 © 2022 NTT DATA Corporation 4 論理レプリケーションの概要
- 5. © 2022 NTT DATA Corporation 5 論理レプリケーションの前に.. 物理レプリケーションの復習 • 概要: 全DBのレプリケーション • 仕組み: WAL転送・リカバリ • DBクラスタの一部レプリケーションは不可 例.×特定のテーブルのみレプリケーション • PostgreSQLのメジャーバージョンは同じである必要 • 下流側は参照のみ可能 • ユースケース: HA, 参照分散 上流 DB1 DB2 下流 上流のWAL を転送 レプリケーション対象 DB2 〇参照, ×更新 DB1
- 6. © 2022 NTT DATA Corporation 6 論理レプリケーション • 概要: DB単位以下の粒度でレプリケーションの対象を指定できるレプリケーション • 仕組み: WALをデコードして送信 • 対象や操作を絞ったレプリケーションが可能 例. テーブルAのINSERTだけレプリケーション • 異なるメジャーバージョン間でのレプリケーションも可能 • 下流側でも更新が可能 上流 DB1 DB2 table2 下流 DB2 table1 2.下流側へ送信 table1 table3 table2 1.WALを デコード レプリケーション対象 〇参照, 〇更新
- 7. © 2022 NTT DATA Corporation 7 論理レプリケーションでできること・ユースケース • 様々な構成がとれるが、後述のコンフリクトなどに注意が必要 • DBの一部のみレプリケーション • 複数のDBのデータを単一DBに集約 A B A B PG15 PG14 • DBの一部の共有 • 異なるメジャーバージョン・プラットフォーム間での レプリケーション
- 8. © 2022 NTT DATA Corporation 8 論理レプリケーションの例 ～上流の設定 t1, t2テーブルを作成、t1のみレプリケーションする。 • 設定 • 上流側のwal_levelをlogicalに変更 • テーブル作成 (pub)=# CREATE TABLE t1 (i INT PRIMARY KEY, t TEXT); (pub)=# CREATE TABLE t2 (i INT PRIMARY KEY, t TEXT); • 初期データ投入 (pub)=# INSERT INTO t1 VALUES (0, 'initial’); • PUBLICATIONの作成 (pub)=# CREATE PUBLICATION pub1 FOR TABLE t1; t1 t2 t1 UPDATE、DELETEをレプリケーションするには、 更新対象行を特定するためにREPLICA IDENTITYの定義が必要。 デフォルトでは主キーがREPLICA IDENTITY
- 9. © 2022 NTT DATA Corporation 9 論理レプリケーションの例 ～上流の設定確認 • PUBLICATIONの確認 (pub)=# ¥dRp+ Publication pub1 -[ RECORD 1 ]-------- Owner | atorik All tables | f Inserts | t Updates | t Deletes | t Truncates | t Via root | f Tables: "public.t1" INSERT、UPDATE、DELETE、 TRUNCATEのうちどれを レプリケーションするか指定可能。 デフォルトは全てが対象 PUBLICATIONの対象テーブルはt1
- 10. © 2022 NTT DATA Corporation 10 論理レプリケーションの例 ～上流の確認から見る機能追加 • PUBLICATIONの確認 (pub)=# ¥dRp+ Publication pub1 -[ RECORD 1 ]-------- Owner | atorik All tables | f Inserts | t Updates | t Deletes | t Truncates | t Via root | f Tables: "public.t1" v.11 v.13 TRUNCATEをレプリケーション対象に指定可能 パーティションテーブルも指定可能(後述)
- 11. © 2022 NTT DATA Corporation 11 論理レプリケーションの例 ～下流の設定 • テーブル作成 (sub)=# CREATE TABLE t1 (i INT PRIMARY KEY, t TEXT); (sub)=# CREATE TABLE t2 (i INT PRIMARY KEY, t TEXT); • SUBSCRIPTIONの作成 (sub)=# CREATE SUBSCRIPTION sub1 -# CONNECTION 'host=192.168.1.10 dbname=postgres' PUBLICATION pub1;
- 12. © 2022 NTT DATA Corporation 12 論理レプリケーションの例 ～下流の確認 • SUBSCRIPTIONの確認 (sub)=# ¥dRs+ List of subscriptions -[ RECORD 1 ]------+-------------------------------- Name | sub1 Owner | atorik Enabled | t Publication | {pub1} Binary | f Streaming | f Two-phase commit | d Disable on error | f Synchronous commit | off Conninfo | host=192.168.1.10 dbname=postgres Skip LSN | 0/0 PUBLICATION”pub1”を利用 SUBSCRIPTIONが有効化
- 13. © 2022 NTT DATA Corporation 13 論理レプリケーションの例 ～下流の確認から見る機能追加 • SUBSCRIPTIONの確認 (sub)=# ¥dRs+ List of subscriptions -[ RECORD 1 ]------+-------------------------------------- Name | sub1 Owner | atorik Enabled | t Publication | {pub1} Binary | f Streaming | f Two-phase commit | d Disable on error | f Synchronous commit | off Conninfo | host=192.168.1.10 dbname=atorik Skip LSN | 0/0 v.15 v.15 v.14 v.14 バイナリ転送モード。 データ型にバイナリ型への変換関数が定義され ている場合、それを利用してレプリケーション ストリーミング転送。後述 ２PCの有効化 エラー発生時にレプリケーションを無効化。後述
- 14. © 2022 NTT DATA Corporation 14 論理レプリケーションの例 ～レプリケーションの確認 • 上流側に最初からあったデータは初期同期される (sub)=# SELECT * FROM t1; i | t ---+--------- 0 | initial (1 row) • SUBSCRIPTIONのオプションcopy_dataをfalseにすることで、同期させないことも可能 • PUBLICATIONの対象テーブルだけレプリケーションされる (pub)=# INSERT INTO t1 VALUES (1, ‘aaa’); (pub)=# INSERT INTO t2 VALUES (1, 'aaa’); (sub)=# SELECT * FROM t1; i | t ---+--------- 0 | initial 1 | aaa (2 rows) (sub)=# SELECT * FROM t2; i | t ---+--- (0 rows)
- 15. © 2022 NTT DATA Corporation 15 柔軟なレプリケーション対象の指定 • 行フィルタ • PUBLICATION定義にWHERE句を指定し、レプリケーション対象行を選択可能 (pub)=# CREATE PUBLICATION pub1 FOR TABLE t1 WHERE (i > 3); • UPDATE、DELETEをレプリケーションする場合、WHERE句はREPLICA IDENTITYのみ指定可 (pub)=# CREATE PUBLICATION pub1 FOR TABLE t1 WHERE (i > 3 AND t = 'aaa'); (pub)=# UPDATE t1 SET i = 6 WHERE i = 5; ERROR: cannot update table "t1" DETAIL: Column used in the publication WHERE expression is not part of the replica identity. • WHERE句内では単純な式のみ利用可。ユーザ定義関数などは利用不可 v.15
- 16. © 2022 NTT DATA Corporation 16 柔軟なレプリケーション対象の指定 • カラムリスト • PUBLICATION定義にレプリケーション対象列を指定可能 (pub)=# CREATE PUBLICATION pub1 FOR TABLE t1(i); • UPDATE、DELETEをレプリケーションする場合、対象のカラムはREPLICA IDENTITYを含める必要 (pub)=# CREATE PUBLICATION pub1 FOR TABLE t1 (t); (pub)=# UPDATE t1 SET i = 6 WHERE i = 5; ERROR: cannot update table "t1" DETAIL: Column list used by the publication does not cover the replica identity. v.15
- 17. © 2022 NTT DATA Corporation 17 柔軟なレプリケーション対象の指定 • パーティションテーブル • PUBLICATION定義にパーティションテーブルを指定可能 • v.12まではパーティションの親テーブルをPUBLICATION対象に指定するとERRORになっていた (pub_v10)=# CREATE PUBLICATION "pub1" FOR TABLE “parent"; ERROR: “parent" is a partitioned table DETAIL: Adding partitioned tables to publications is not supported. v.13
- 18. © 2022 NTT DATA Corporation 18 柔軟なレプリケーション対象の指定 • パーティションテーブル(続き) • デフォルトでは、子テーブル側の情報を使って変更をWALに記録するため、上流と同様の定義の 子テーブルが下流側にも必要。存在しない場合SUBSCRIPTION作成に失敗 • 例えば、下流側のparentテーブルが通常のテーブルの場合、SUBSCRIPTIONの作成に失敗 (sub)=# CREATE SUBSCRIPTION sub1 -# CONNECTION 'host=192.168.1.10 dbname=postgres' PUBLICATION pub1; ERROR: relation “public.child1” does not exist. 子 子 子 親 子 子 子 親 子テーブルの情報を WALに記録するので.. 同様の定義の 子テーブルが必要
- 19. © 2022 NTT DATA Corporation 19 柔軟なレプリケーション対象の指定 • パーティションテーブル(続き) • publish_via_partition_rootオプションをonにすることで、親テーブル側の情報を使うよう変更可能。 この場合、下流側に親テーブルと同様の定義のテーブルがあればレプリケーションが可能 (pub)=# CREATE PUBLICATION "pub1" FOR TABLE “parent“ -# WITH (publish_via_partition_root = true); 子 子 子 親 通常のテーブル 親テーブルの情報を WALに記録するので.. 同様の定義の子 テーブルがなくても レプリケーション可能 子 子 親
- 20. © 2022 NTT DATA Corporation 20 コンフリクト • 論理レプリケーションでは下流側も更新可能 • 上流が送ったデータが下流でエラーを起こすと、コンフリクトが発生し、レプリケーションが失敗 • 例) 一意性制約違反 上流 下流 i(主キー) t 1 ‘aaa’ 2 ‘bbb’ i(主キー) t 1 ‘aaa’ 1. (2, ‘bbb’)を 挿入 client client
- 21. © 2022 NTT DATA Corporation 21 コンフリクト • 論理レプリケーションでは下流側も更新可能 • 上流が送ったデータが下流でエラーを起こすと、コンフリクトが発生し、レプリケーションが失敗 • 例) 一意性制約違反 上流 下流 i(主キー) t 1 ‘aaa’ 2 ‘bbb’ i(主キー) t 1 ‘aaa’ 2 ‘xxx’ client 2. (2, ‘xxx’) を挿入 client
- 22. © 2022 NTT DATA Corporation 22 コンフリクト • 論理レプリケーションでは下流側も更新可能 • 上流が送ったデータが下流でエラーを起こすと、コンフリクトが発生し、レプリケーションが失敗 • 例) 一意性制約違反 上流 下流 i(主キー) t 1 ‘aaa’ 2 ‘bbb’ i(主キー) t 1 ‘aaa’ 2 ‘xxx’ client client 3. (2, ‘xxx’)を レプリケーション
- 23. © 2022 NTT DATA Corporation 23 コンフリクト • 論理レプリケーションでは下流側も更新可能 • 上流が送ったデータが下流でエラーを起こすと、コンフリクトが発生し、レプリケーションが失敗 • 例) 一意性制約違反 上流 下流 i(主キー) t 1 ‘aaa’ 2 ‘bbb’ i(主キー) t 1 ‘aaa’ 2 ‘xxx’ client client 4. 一意性制約違反によりレプリ ケーション停止。 デフォルトではリトライを繰り返し、 エラー出力が継続
- 24. © 2022 NTT DATA Corporation 24 コンフリクト • 論理レプリケーションでは下流側も更新可能 • 上流が送ったデータが下流でエラーを起こすと、コンフリクトが発生し、レプリケーションが失敗 • 例) 一意性制約違反 上流 下流 i(主キー) t 1 ‘aaa’ 2 ‘bbb’ i(主キー) t 1 ‘aaa’ 2 ‘xxx’ client client =# SELECT ＊ FROM pg_stat_subscription_stats; -[ RECORD 1 ]-----+------- subid | 16651 subname | sub1 apply_error_count | 12 sync_error_count | 0 stats_reset | [NULL] pg_stat_subscription_statsビュー からエラーの発生回数が確認可能 v.15 初期同期時のエラー回数 初期同期後のエラー回数
- 25. © 2022 NTT DATA Corporation 25 コンフリクト • 論理レプリケーションでは下流側も更新可能 • 上流が送ったデータが下流でエラーを起こすと、コンフリクトが発生し、レプリケーションが失敗 • 例) 一意性制約違反 上流 下流 i(主キー) t 1 ‘aaa’ 2 ‘bbb’ i(主キー) t 1 ‘aaa’ 2 ‘xxx’ client client SUBSCRIPTIONのオプション DISABLE_ON_ERRORを有効 にすると、自動で SUBSCRIPTIONを無効化可能 v.15
- 26. © 2022 NTT DATA Corporation 26 コンフリクト • コンフリクトを自動で解決する仕組みは提供されていない • コンフリクト解決方法 • ①下流側でコンフリクトしているデータを変更する (sub)=# DELETE FROM t1 WHERE i = 2; • ②レプリケーションをスキップ • ALTER SUBSCRIPTION SKIPが扱いやすい。LSNは、エラーメッセージに出力されているものを指定 すればOK CONTEXT: processing remote data for replication origin "pg_16605" during message type "INSERT" for replication target relation "public.t1" in transaction 888, finished at 0/7CE99D58 (sub)=# ALTER SUBSCRIPTION sub1 SKIP ( LSN = '0/7CE99D58’); • コンフリクトするデータだけでなく、トランザクション単位でスキップする点に注意 v.15
- 27. © 2022 NTT DATA Corporation 27 © 2022 NTT DATA Corporation 27 論理レプリケーションのしくみ
- 28. © 2022 NTT DATA Corporation 28 アーキテクチャの概要 • 上流 • walsender: WALの読み取り・デコード、データを送信 • 下流 • logical replication worker: データを受信、適用 上流 walsender WAL 1. WAL読込 下流 logical replication worker 2. デコード 3. データ送信 4. データ受信 5. データ適用
- 29. © 2022 NTT DATA Corporation 29 初期同期 • レプリケーション開始時に上流側にあったデータをCOPYする • 初期同期用のwalsender, logical replication workerが起動 • SUBSCRIPTION1つあたり同時に実行できるワーカー数:max_sync_workers_per_subscription 上流 walsender WAL 下流 logical replication worker 初期データを COPY walsender logical replication worker sync logical replication worker sync walsender max_sync_workers_per_subscription max_logical_replication_workers
- 30. © 2022 NTT DATA Corporation 30 上流 walsender 初期同期後のレプリケーション • 上流側でWALを読み込み、デコードした内容をトランザクション単位で変更を管理 WAL 1. WAL読込 下流 logical replication worker begin_cb change_cb … commit_cb outputプラグイン。論理レプリケーションでは pgoutput ReorderBuffer INSERT.. DELETE.. INSERT.. UPDATE.. INSERT..
- 31. © 2022 NTT DATA Corporation 31 上流 walsender 初期同期後のレプリケーション • 上流側でWALを読み込み、デコードした内容をトランザクション単位で変更を管理 WAL 下流 logical replication worker begin_cb change_cb … commit_cb outputプラグイン。論理レプリケーションでは pgoutput ReorderBuffer INSERT.. UPDATE.. DELETE.. INSERT.. UPDATE.. INSERT.. 2. デコードし、トランザ クション単位で管理
- 32. © 2022 NTT DATA Corporation 32 上流 walsender 初期同期後のレプリケーション • COMMITをデコードすると、下流側に送信 WAL 下流 logical replication worker begin_cb change_cb … commit_cb 3. COMMITされると、各 種コールバック関数が実 行され、下流への送信 outputプラグイン。論理レプリケーションでは pgoutput ReorderBuffer INSERT.. UPDATE.. COMMIT DELETE.. INSERT.. UPDATE.. INSERT..
- 33. © 2022 NTT DATA Corporation 33 変更量の大きいトランザクションの扱い(SUBSCRIPTIONのオプションstreaming=offの場合) • １レプリケーションが使用するメモリ量がlogical_decoding_work_memを超過した場合、 ファイルに変更を出力し、メモリ逼迫を予防 • 書き出すのは、最もメモリ使用量が大きいトランザクション 上流 walsender WAL 下流 logical replication worker outputプラグイン。論理レプリケーションでは pgoutput ReorderBuffer INSERT.. UPDATE.. DELETE.. INSERT.. .spill 2. PGDATA/pg_replslot 以下に出力 begin_cb change_cb … commit_cb DELETE.. INSERT.. DELETE.. INSERT.. 1.メモリ使用量が増加し、 Logical_decoding_work_mem を超過 v.13
- 34. © 2022 NTT DATA Corporation 34 変更量の大きいトランザクションの扱い(SUBSCRIPTIONのオプションstreaming=onの場合) • １レプリケーションが使用するメモリ量がlogical_decoding_work_memを超過した場合、 下流側に送信 • streaming = offの場合に比べ、変更量の大きいトランザクションの下流側への反映が遅延しにくい • ただし、ABORTされた場合は下流側へ送信されたデータは利用されない 上流 walsender WAL 下流 logical replication worker outputプラグイン。論理レプリケーションでは pgoutput ReorderBuffer INSERT.. UPDATE.. DELETE.. INSERT.. Stream用のコールバック 関数が呼び出され、下 流側へ送信 DELETE.. INSERT.. DELETE.. INSERT.. 1.メモリ使用量が増加し、 logical_decoding_work _memを超過 stream_start_cb stream_stop_cb … stream_commit_cb v.14
- 35. © 2022 NTT DATA Corporation 35 レプリケーションスロット • レプリケーションスロットでレプリケーションの進捗状況などを管理 • 物理レプリケーションではスロットの利用は任意だが、論理レプリケーションでは必須 • 下流側へのレプリケーションが行われないと、上流側のWALが蓄積され続け、ディスクフル・PANIC終了 となるため注意 =# SELECT ＊ FROM pg_replication_slots; -[ RECORD 1 ]-------+----------- slot_name | sub1 plugin | pgoutput slot_type | logical datoid | 5 database | postgres temporary | f active | t active_pid | 4477 xmin | [NULL] catalog_xmin | 849 restart_lsn | 0/4816C1E8 confirmed_flush_lsn | 0/4816C220 wal_status | reserved safe_wal_size | [NULL] two_phase | f 上流 walsender WAL walsender walsender replication slot replication slot replication slot レプリケースロットでレプリケーションの 進捗状況などを管理
- 36. © 2022 NTT DATA Corporation 36 pg_stat_replication_slotビュー • ファイルへの書き出し・ストリーム処理の回数、量などが確認可能 =# SELECT * FROM pg_stat_replication_slots; -[ RECORD 1 ]+-------- slot_name | sub1 spill_txns | 0 spill_count | 0 spill_bytes | 0 stream_txns | 1 stream_count | 22 stream_bytes | 1444410 total_txns | 12 total_bytes | 1444410 stats_reset | [NULL] ファイルへ書き出した トランザクション数、 回数、 バイト数 ストリーム処理された トランザクション数、 回数、 バイト数 v.14
- 37. © 2022 NTT DATA Corporation 37 © 2022 NTT DATA Corporation 37 論理レプリケーションのこれから
- 38. © 2022 NTT DATA Corporation 38 レプリケーション対象の追加 • v.15時点ではCREATE TABLEなどDDLはレプリケーション対象外 • 初期同期は、 pg_dump --schema-onlyなどで対応可能 • 運用中にテーブルのスキーマを変更する場合、同じDDLを上流・下流両方で実行するなど対応が必要 • DDLもレプリケーション対象にするパッチ提案あり • v.15時点ではシーケンスオブジェクトはレプリケーション対象外 • シーケンスオブジェクトから生成されるデータはレプリケーション対象だが、シーケンス自体は レプリケーションされない • シーケンスオブジェクトもレプリケーション対象にするパッチ提案あり
- 39. © 2022 NTT DATA Corporation 39 物理レプリケーションとの連携 • 想定構成: 物理レプリケーションを利用してHA構成をとったDBを上流として、下流に論理レ プリケーション • レプリケーションスロットはレプリケーションされないため、物理レプリケーションのスタンバイが昇格 した場合、論理レプリケーションは継続できない 上流(プライマリ) 上流(スタンバイ) 物理レプリケーション 下流 論理レプリケーション 上流(旧プライマリ) 上流(新プライマリ) 下流 論理レプリケーション スロット × スロット ×
- 40. © 2022 NTT DATA Corporation 40 物理レプリケーションとの連携(続き) • 対応はコミュニティで議論中 • PostgreSQL周辺の製品では、独自に対応を実装しているものもあり
- 41. © 2022 NTT DATA Corporation 41 © 2022 NTT DATA Corporation 41 まとめ
- 42. © 2022 NTT DATA Corporation 42 まとめ • 論理レプリケーションでは、柔軟なレプリケーションが可能 • 近年の機能開発で、レプリケーション対象・方式などについて、より柔軟になった • コンフリクトなど設計・運用に注意が必要な内容もあり • DDLレプリケーションなどニーズが多い機能もコミュニティで開発中
- 43. © 2022 NTT DATA Corporation 43 その他、記載されている会社名、商品名、又はサービス名は、 各社の登録商標又は商標です。