PostgreSQL10 徹底解説 澤田 雅彦 日本 PostgreSQL ユーザ会 北海道支部 2017/07/15 @ オープンソースカンファレンス Hokkaido 2017
自己紹介 • 澤田 雅彦 • @sawada_masahiko • NTT OSS センタ勤務 • PostgreSQL Contributor • pg_repack Maintainer • pg_bigm Maintainer
目次 • 約7年ぶりの大型アップデート • 新機能紹介 • 大規模データ • レプリケーション • 非互換に注意! • まとめ • PostgreSQL の未来
• 機能の概要、使い所を紹介します • • まだ Beta 版なので、正式リリースまでに動作が変わっている可能 性があります はじめに
約7年ぶりの大型アップデート! • 約 200 個の改善点 • 大きい機能を多く導入 • バージョン番号が2桁に変更 (9.6.0 → 10.0) • わかりやすさ・使いやすさ向上のために、一部後方互換性をなくして 改善 9.09.0 9.19.1 9.29.2 9.39.3 9.49.4 9.59.5 9.69.6 10.010.0 2010 年リリース 2017 年リリース
PostgreSQL のバージョンリリース • 約1年かけて新バージョンを開発 • 毎年9月頃に新メジャーバージョンをリリース • 2 、 3 ヵ月毎にマイナーバージョンをリリース • 大きな機能は、複数バージョンを跨いで少しずつ開発される ことが多い • 新機能を使う時はその制約も把握することが大切
新機能紹介 • 大規模データ処理 • ネイティブ・パーティショニング • パラレルクエリ強化 • FDW を使った並列分散 DB 化 • レプリケーション • ロジカルレプリケーション • Quorum 同期レプリケーション
ネイティブ・ パーティショニング (Amit Langote)
ネイティブ・パーティショニング • ” ネイティブ”・パーティショニング • これまでもパーティショニング機能はあった • しかし、複数機能 (CHECK 制約、テーブル継承、トリガ ) を組み合わせ た「なんちゃってパーティショニング」 • 性能面、運用面で多くの課題があった • なにが良くなった? • パーティショニング専用の DDL が追加 • 性能向上 • プランナがパーティショニング情報を考慮して • 動くようになった 親 子 子子
パーティショニングの DDL -- 親テーブルの作成 =# CREATE TABLE parent (c1 int, c2 int) PARTITION BY RANGE; -- 子テーブルの作成 =# CREATE TABLE child1 PARTITION OF parent FOR VALUES FROM (0) TO (100); =# CREATE TABLE child2 PARTITION OF parent FOR VALUES FROM (100) TO (200); -- 子テーブルの取り外し =# ALTER TABLE parent DETACH PARTITION child2; -- 子テーブルの取り付け =# ALTER TABLE parent ATTACH PARTITION child2 FOR VALUES (100) TO (500);
INSERT 性能が向上 INSERT 時間 0 10 20 30 40 50 60 70 80 90 83 7 従来のトリガ方式 PostgreSQL 10 単純な INSERT 性能を従来のトリガ方式、 PostgreSQL10 方式で比較 日付をキーに分割し た複数の子テーブル にデータを 864,000 件 INSERT
ネイティブ・パーティショニング できること • レンジ、リスト・パーティショニン グ • パーティションテーブルの追加、 削除、取り付け (Attach) 、取り 外し (Detach) • 複数階層のパーティショニング • マルチカラム・パーティショニン グ できないこと • グローバルインデックス • パーティションを跨いだ UPDATE • ハッシュ・パーティショニング • パーティションテーブルのリバラ ンシング
パラレルクエリ改善 (Robert Haas, Amit Kapila, Rahila Syed, Rafia Sabih, Dilip Mumar)
パラレルクエリとは? • 1つの SQL を複数の CPU を活用して並列に処理する機能 • 特に大きなデータを処理するような分析系クエリで大活躍 • PostgreSQL 9.6 から導入された機能 テーブルテーブルプロセスプロセス プロセスプロセス プロセスプロセス テーブルテーブル 1プロセスでの処理 複数プロセスでのパラレル処理
パラレルクエリが更に強化 • Scan • Sequential Scan • Bitmap Heap Scan • Index Scan • Index Only Scan • Join • Nested Loop Join • Hash Join • Merge Join • PostgreSQL 10 でさらにパラレルクエリが使える場面が増えた • ただし、 UPDATE/DELETE, DDL は未対応 QUERY PLAN ---------------------------------------------------------------- Finalize Aggregate -> Gather Workers Planned: 2 -> Partial Aggregate -> Parallel Index Only Scan using a_idx on a Index Cond: ((c >= 100) AND (c <= 300000)) (6 rows) QUERY PLAN ---------------------------------------------------------------- Finalize Aggregate -> Gather Workers Planned: 2 -> Partial Aggregate -> Parallel Index Only Scan using a_idx on a Index Cond: ((c >= 100) AND (c <= 300000)) (6 rows)
https://www.pgcon.org/2017/schedule/attachments/445_Next-Generation%20Parallel%20Query%20-%20PGCon.pdf
https://www.pgcon.org/2017/schedule/attachments/445_Next-Generation%20Parallel%20Query%20-%20PGCon.pdf
https://www.pgcon.org/2017/schedule/attachments/445_Next-Generation%20Parallel%20Query%20-%20PGCon.pdf
FDW 改善・並列分散 DB 化 (Etsuro Fujita, Jeevan Chalke, Ashutosh Bapat)
Foreign Data Wrapper(FDW) とは? OracleOracle PostgreSQLPostgreSQL CSV ファイルCSV ファイル SELECT * FROM oracle_tbl WHERE amount < 100; PostgreSQL を”ハブ”のようにして、外部データ ( 他の DBMS 、 NoSQL 、ファイ ル、 Web サービス等 ) と連携できる機能 oracle_tbl pg_tbl file_tbl oracle_fdw postgres_fdwpostgres_fdw fle_fdw fle_fdw
FDW 、 postgres_fdw の機能が強化された • Join 、 Sort に加え Aggregation (集約)が push down 対応した • より外部サーバのリソースを使って処理できるようになった QUERY PLAN ------------------------------------------------------------ Aggregate Output: sum(col) -> Foreign Scan on public.s1 Output: col Remote SQL: SELECT col FROM public.s1 QUERY PLAN ------------------------------------------------------------ Aggregate Output: sum(col) -> Foreign Scan on public.s1 Output: col Remote SQL: SELECT col FROM public.s1 QUERY PLAN ---------------------------------------------------------------- Foreign Scan Output: (sum(col)) Relations: Aggregate on (public.s1) Remote SQL: SELECT sum(col) FROM public.s1 QUERY PLAN ---------------------------------------------------------------- Foreign Scan Output: (sum(col)) Relations: Aggregate on (public.s1) Remote SQL: SELECT sum(col) FROM public.s1 ■ 9.6 以前 ■ 10 以降 ② ローカルでスキャン結果を 集計 ① リモートのデータをスキャン ① リモートでスキャン・集計 を両方実行 SELECT sum(col) FROM s1; ?
FDW を使って並列分散処理 • “PostgreSQL と PostgreSQL と連携させる”というアイディア • さらに、パーティショニングを組み合わせて分散処理させる User ID 100 ~ 200 User ID 200 ~ 300 User ID 300 ~ 400 postgres_fdw postgres_fdw postgres_fdwpostgres_fdw postgres_fdw postgres_fdw user_tbl child_1 child_2 child_3 SELECT count(*) FROM user_tbl WHERE user_id = 300;
ここまでのまとめ • パーティショニング →専用 DDL が用意されたことにより運用が楽になった →INSERT 性能が大幅に向上 • パラレルクエリ強化 →IndexScan 、 IndexOnlyScan 、 BitmapHeapScan 、 Parallel Merge に 対応した →UPDATE/DELETE, DDL の対応はまだ • FDW を使った並列分散 DB 化 →集約関数が PushDown されたことにより、並列分散 DB 化がより現実的に →ただし注意点はまだまだあるので、使うときは気をつける
ロジカル・ レプリケーション (Petr Jelinek)
レプリケーション • フィジカル ( 物理 ) レプリケーション • バイナリ情報 ( トランザクションログなど ) をスタンバイへ送信する • DB まるごと複製 ( バックアップなど ) するときに良く利用される • PostgreSQL では 9.0(2008 年 ) から導入された • ロジカル ( 論理 ) レプリケーション • 論理的な変更情報 (SQL など ) をスタンバイへ送信する • テーブル単位、 DB 単位等の細かい粒度が指定可能 • PostgreSQL では 10.0(2017 年 ) から導入
PostgreSQL のロジカルレプリケーションは Pub/Sub モデル • Publication( 上流 ) と Subscription( 下流 ) を設定 • Publication は複数テーブルを指定可能 • Subscription は複数 Publication を指定可能 • UPDATE/DELETE を複製するためにはプライマリキーまたは、 NOT NULL UNIQUE キーが必要 TABLE A TABLE B TABLE C TABLE D sub_hoge sub_bar TABLE A TABLE B TABLE C TABLE D TABLE C TABLE D Publisher 側 Subscriber 側
設定例( Publication の作成) -- Publication 作成 =# CREATE PUBLICATION test_pub FOR TABLE t1, t2 WITH (publish = ‘insert, delete’); -- Publication 確認 =# dRp+ Publication hoge_pub All tables | Inserts | Updates | Deletes -------------+----------+-------------+--------- f | t | f | t Tables: "public.t1“ "public.t2" • 複数テーブル、または DB 全体を複製対象として設定可能 • Subscription 毎に複製する操作を指定可能 •
設定例( Subscription の作成) -- Subscription 作成 =# CREATE SUBSCRIPTION hoge_sub CONNECTION ‘port= ... ‘ PUBLICATION hoge_pub; -- Subscription 確認 =# dRs+ List of subscriptions Name | Owner | Enabled | Publication | Synchronous commit | Conninfo ---------- --+--------------+------------+----------------+----------------------------+--------------------------------------- hoge_sub | masahiko | t | {hoge_pub} | off | dbname=postgres port=5550 (1 row) • Subscription を作成した時点からレプリケーションが開始される • レプリケーション開始時に初期データのコピーを実行される
モニタリング -- Publisher 側 =# SELECT application_name, state, write_lag, flush_lag, replay_lag, sync_state FROM pg_stat_replication ; -[ RECORD 1 ]-----+---------------- application_name | hoge_sub state | streaming write_lag | 00:00:00.003926 flush_lag | 00:00:00.003926 replay_lag | 00:00:00.003926 sync_state | sync -- Subscriber 側 =# SELECT * FROM pg_stat_subscription ; -[ RECORD 1 ]------------+------------------------------ subid | 16388 subname | hoge_sub pid | 15796 relid | received_lsn | 0/1693EC8 last_msg_send_time | 2017-07-10 12:30:17.383905-07 last_msg_receipt_time | 2017-07-10 12:30:17.383994-07 latest_end_lsn | 0/1693EC8 latest_end_time | 2017-07-10 12:30:17.383905-07 -- Subscriber 側 =# SELECT * FROM pg_stat_subscription ; -[ RECORD 1 ]------------+------------------------------ subid | 16388 subname | hoge_sub pid | 15796 relid | received_lsn | 0/1693EC8 last_msg_send_time | 2017-07-10 12:30:17.383905-07 last_msg_receipt_time | 2017-07-10 12:30:17.383994-07 latest_end_lsn | 0/1693EC8 latest_end_time | 2017-07-10 12:30:17.383905-07
仕組み • PostgreSQL のロジカルレプリケーションで送信しているのは SQL” ではない” • MySQL の Row-based Replication 相当 TABLE WAL wal sender wal sender apply worker apply worker TABLE WAL backendbackend ① Write ② Read ③ Decode ④ Send ⑤ Write ⑤ Write ① Write
ロジカルレプリケーション できること • テーブル、 DB 単位でのレプリケ ーション • 初期データの転送 • コンフリクトの解消(手動) できないこと • DDL レプリケーション • テーブル、 • Publication 、 Subscription 単 位での同期レプリケーション • 双方向レプリケーション(マルチマ スター) • テーブル以外のレプリケーション (シーケンスなど)
Quorum-based 同期レプリケーション (Masahiko Sawada)
Quorum ベース同期レプリケーション • Quorum( 定足数 ) ベースとは ? • “quorum とは分散システムにおいて、分散トランザクションが処理を実行するため に必要な最低限の票の数である。” (Wikipedia より ) • 5 台の内、 3 台から応答が返ってきたら COMMIT とする、と言った感じ • 9.6 までは応答を待つスタンバイは”固定”だった マスタ スタンバイ A スタンバイ B スタンバイ C マスタ スタンバイ A スタンバイ B スタンバイ C スタンバイ A,B から応答 が返ってくるまで待つよ 3 台の内どれか 2 台 から応答が返ってくれ ばいいよ 応答 停止中・・・ 9.6 までの方式 Quorum ベース
設定方法 • FIRST 、 ANY で同期方法を選択 • N で台数を指定 • 例 • FIRST 2 (node1, node2, node3) • node1, node2 の 2 台からの返答を待つ • ANY 2 (node1, node2, node3) • node1, node2, node3 の内 2 台からの返答を待つ synchronous_standby_names = [ ANY | FIRST ] N (node1, node2, ... )synchronous_standby_names = [ ANY | FIRST ] N (node1, node2, ... )
使い所・注意点 • N 台の中から K 台に同期的にデータを複製するという所は 同じ • 選び方の違いがあるだけ • 性能面では ANY の方が優位 • 遅いスタンバイに性能が引っ張られないため • ANY では今どれが同期スタンバイかは状況によって異なる • レプリケーション状況は pg_stat_replication で確認
ここまでのまとめ • ロジカルレプリケーション →テーブル単位でのレプリケーションが可能に →Pub/Sub モデル →ただし、 DDL はレプリケートされないので注意 • • • Quorum 同期レプリケーション →“5 個の中からどれでもいいので 2 個同期にする”みたいな使い方 →性能が遅いスタンバイに引きずられないので、性能的に優位になるケ ースが多い
全 22 個の非互換箇所 • Hash インデックスは再作成する必要がある (pg_upgrade を使用し た場合 ) • “xlog” が” wal” に変更 • pg_xlog ディレクトリ、 XXX_xlog() 関数など、全ての xlog が wal に名称変 更 • pg_clog ディレクトリが pg_xact ディレクトリに名称変更 • “lsn” が” location” に変更 • 主に XXX_location() 関数が XXX_lsn() に称変更 • デフォルトで localhost からのレプリケーション接続が有効になった • pg_ctl がデフォルトで”待つ”動作になった :
ここまでのまとめ • PostgreSQL 10 では非互換箇所が多い! • 運用ツールに影響があるもの、セキュリティ的に影響があるものなの で、バージョンアップの際は必ず確認することを推奨します • 一覧はリリースノートでチェック
まとめ • PostgreSQL 10 は現在 Beta2  日本人開発者も多く参画している • リリースは 9 月頃を予定 • 正式リリースを待ってもよし • リリース前に使ってみるのもよし • 不具合を見つけたらバグレポください! • 英語が・・・というかたは日本 PostgreSQL ユーザ会の slack でも OK • もしくは、 @sawada_masahiko に連絡ください
PostgreSQL の進化が止まらない! •さらなる機能拡充  並列分散 DB 化  パラレル DDL  JIT コンパイル  セキュリティ機能の拡充 • •PostgreSQL の適用領域拡大へ
PostgreSQL Conference Japan 2017
PGConf.ASIA 2017
参考資料 • Next-Generation Parallel Query • https://www.pgcon.org/2017/schedule/attachments/445_Next- Generation%20Parallel%20Query%20-%20PGCon.pdf • 次期バージョン PostgreSQL 10 の新機能とその後の方向性 • https://www.sraoss.co.jp/event_seminar/2017/db_tech_show_cas e_oss_2017.pdf • PostgreSQL 10 がやってくる! • https://www.slideshare.net/toshiharada/jpug-studypostgre- sql10pub
Thank you!! twitter : @sawada_masahiko mail : sawada_masahiko_f7@lab.ntt.co.jp
その他たくさん新機能があります • HASH インデックスの WAL 対応 • 拡張統計情報( Multi Column Correlation) • JSON 型の全文検索サポート • ICU サポート • SCRAM 認証

PostgreSQL10徹底解説

  • 1.
    PostgreSQL10 徹底解説 澤田 雅彦 日本 PostgreSQLユーザ会 北海道支部 2017/07/15 @ オープンソースカンファレンス Hokkaido 2017
  • 2.
    自己紹介 • 澤田 雅彦 • @sawada_masahiko •NTT OSS センタ勤務 • PostgreSQL Contributor • pg_repack Maintainer • pg_bigm Maintainer
  • 3.
    目次 • 約7年ぶりの大型アップデート • 新機能紹介 •大規模データ • レプリケーション • 非互換に注意! • まとめ • PostgreSQL の未来
  • 4.
    • 機能の概要、使い所を紹介します • • まだBeta 版なので、正式リリースまでに動作が変わっている可能 性があります はじめに
  • 5.
    約7年ぶりの大型アップデート! • 約 200個の改善点 • 大きい機能を多く導入 • バージョン番号が2桁に変更 (9.6.0 → 10.0) • わかりやすさ・使いやすさ向上のために、一部後方互換性をなくして 改善 9.09.0 9.19.1 9.29.2 9.39.3 9.49.4 9.59.5 9.69.6 10.010.0 2010 年リリース 2017 年リリース
  • 6.
    PostgreSQL のバージョンリリース • 約1年かけて新バージョンを開発 •毎年9月頃に新メジャーバージョンをリリース • 2 、 3 ヵ月毎にマイナーバージョンをリリース • 大きな機能は、複数バージョンを跨いで少しずつ開発される ことが多い • 新機能を使う時はその制約も把握することが大切
  • 7.
    新機能紹介 • 大規模データ処理 • ネイティブ・パーティショニング •パラレルクエリ強化 • FDW を使った並列分散 DB 化 • レプリケーション • ロジカルレプリケーション • Quorum 同期レプリケーション
  • 8.
  • 9.
    ネイティブ・パーティショニング • ” ネイティブ”・パーティショニング •これまでもパーティショニング機能はあった • しかし、複数機能 (CHECK 制約、テーブル継承、トリガ ) を組み合わせ た「なんちゃってパーティショニング」 • 性能面、運用面で多くの課題があった • なにが良くなった? • パーティショニング専用の DDL が追加 • 性能向上 • プランナがパーティショニング情報を考慮して • 動くようになった 親 子 子子
  • 10.
    パーティショニングの DDL -- 親テーブルの作成 =#CREATE TABLE parent (c1 int, c2 int) PARTITION BY RANGE; -- 子テーブルの作成 =# CREATE TABLE child1 PARTITION OF parent FOR VALUES FROM (0) TO (100); =# CREATE TABLE child2 PARTITION OF parent FOR VALUES FROM (100) TO (200); -- 子テーブルの取り外し =# ALTER TABLE parent DETACH PARTITION child2; -- 子テーブルの取り付け =# ALTER TABLE parent ATTACH PARTITION child2 FOR VALUES (100) TO (500);
  • 11.
    INSERT 性能が向上 INSERT 時間 0 10 20 30 40 50 60 70 80 90 83 7 従来のトリガ方式PostgreSQL 10 単純な INSERT 性能を従来のトリガ方式、 PostgreSQL10 方式で比較 日付をキーに分割し た複数の子テーブル にデータを 864,000 件 INSERT
  • 12.
    ネイティブ・パーティショニング できること • レンジ、リスト・パーティショニン グ • パーティションテーブルの追加、 削除、取り付け(Attach) 、取り 外し (Detach) • 複数階層のパーティショニング • マルチカラム・パーティショニン グ できないこと • グローバルインデックス • パーティションを跨いだ UPDATE • ハッシュ・パーティショニング • パーティションテーブルのリバラ ンシング
  • 13.
    パラレルクエリ改善 (Robert Haas, AmitKapila, Rahila Syed, Rafia Sabih, Dilip Mumar)
  • 14.
    パラレルクエリとは? • 1つの SQLを複数の CPU を活用して並列に処理する機能 • 特に大きなデータを処理するような分析系クエリで大活躍 • PostgreSQL 9.6 から導入された機能 テーブルテーブルプロセスプロセス プロセスプロセス プロセスプロセス テーブルテーブル 1プロセスでの処理 複数プロセスでのパラレル処理
  • 15.
    パラレルクエリが更に強化 • Scan • SequentialScan • Bitmap Heap Scan • Index Scan • Index Only Scan • Join • Nested Loop Join • Hash Join • Merge Join • PostgreSQL 10 でさらにパラレルクエリが使える場面が増えた • ただし、 UPDATE/DELETE, DDL は未対応 QUERY PLAN ---------------------------------------------------------------- Finalize Aggregate -> Gather Workers Planned: 2 -> Partial Aggregate -> Parallel Index Only Scan using a_idx on a Index Cond: ((c >= 100) AND (c <= 300000)) (6 rows) QUERY PLAN ---------------------------------------------------------------- Finalize Aggregate -> Gather Workers Planned: 2 -> Partial Aggregate -> Parallel Index Only Scan using a_idx on a Index Cond: ((c >= 100) AND (c <= 300000)) (6 rows)
  • 16.
  • 17.
  • 18.
  • 19.
    FDW 改善・並列分散 DB化 (Etsuro Fujita, Jeevan Chalke, Ashutosh Bapat)
  • 20.
    Foreign Data Wrapper(FDW)とは? OracleOracle PostgreSQLPostgreSQL CSV ファイルCSV ファイル SELECT * FROM oracle_tbl WHERE amount < 100; PostgreSQL を”ハブ”のようにして、外部データ ( 他の DBMS 、 NoSQL 、ファイ ル、 Web サービス等 ) と連携できる機能 oracle_tbl pg_tbl file_tbl oracle_fdw postgres_fdwpostgres_fdw fle_fdw fle_fdw
  • 21.
    FDW 、 postgres_fdwの機能が強化された • Join 、 Sort に加え Aggregation (集約)が push down 対応した • より外部サーバのリソースを使って処理できるようになった QUERY PLAN ------------------------------------------------------------ Aggregate Output: sum(col) -> Foreign Scan on public.s1 Output: col Remote SQL: SELECT col FROM public.s1 QUERY PLAN ------------------------------------------------------------ Aggregate Output: sum(col) -> Foreign Scan on public.s1 Output: col Remote SQL: SELECT col FROM public.s1 QUERY PLAN ---------------------------------------------------------------- Foreign Scan Output: (sum(col)) Relations: Aggregate on (public.s1) Remote SQL: SELECT sum(col) FROM public.s1 QUERY PLAN ---------------------------------------------------------------- Foreign Scan Output: (sum(col)) Relations: Aggregate on (public.s1) Remote SQL: SELECT sum(col) FROM public.s1 ■ 9.6 以前 ■ 10 以降 ② ローカルでスキャン結果を 集計 ① リモートのデータをスキャン ① リモートでスキャン・集計 を両方実行 SELECT sum(col) FROM s1; ?
  • 22.
    FDW を使って並列分散処理 • “PostgreSQLと PostgreSQL と連携させる”というアイディア • さらに、パーティショニングを組み合わせて分散処理させる User ID 100 ~ 200 User ID 200 ~ 300 User ID 300 ~ 400 postgres_fdw postgres_fdw postgres_fdwpostgres_fdw postgres_fdw postgres_fdw user_tbl child_1 child_2 child_3 SELECT count(*) FROM user_tbl WHERE user_id = 300;
  • 23.
    ここまでのまとめ • パーティショニング →専用 DDLが用意されたことにより運用が楽になった →INSERT 性能が大幅に向上 • パラレルクエリ強化 →IndexScan 、 IndexOnlyScan 、 BitmapHeapScan 、 Parallel Merge に 対応した →UPDATE/DELETE, DDL の対応はまだ • FDW を使った並列分散 DB 化 →集約関数が PushDown されたことにより、並列分散 DB 化がより現実的に →ただし注意点はまだまだあるので、使うときは気をつける
  • 24.
  • 25.
    レプリケーション • フィジカル (物理 ) レプリケーション • バイナリ情報 ( トランザクションログなど ) をスタンバイへ送信する • DB まるごと複製 ( バックアップなど ) するときに良く利用される • PostgreSQL では 9.0(2008 年 ) から導入された • ロジカル ( 論理 ) レプリケーション • 論理的な変更情報 (SQL など ) をスタンバイへ送信する • テーブル単位、 DB 単位等の細かい粒度が指定可能 • PostgreSQL では 10.0(2017 年 ) から導入
  • 26.
    PostgreSQL のロジカルレプリケーションは Pub/Subモデル • Publication( 上流 ) と Subscription( 下流 ) を設定 • Publication は複数テーブルを指定可能 • Subscription は複数 Publication を指定可能 • UPDATE/DELETE を複製するためにはプライマリキーまたは、 NOT NULL UNIQUE キーが必要 TABLE A TABLE B TABLE C TABLE D sub_hoge sub_bar TABLE A TABLE B TABLE C TABLE D TABLE C TABLE D Publisher 側 Subscriber 側
  • 27.
    設定例( Publication の作成) --Publication 作成 =# CREATE PUBLICATION test_pub FOR TABLE t1, t2 WITH (publish = ‘insert, delete’); -- Publication 確認 =# dRp+ Publication hoge_pub All tables | Inserts | Updates | Deletes -------------+----------+-------------+--------- f | t | f | t Tables: "public.t1“ "public.t2" • 複数テーブル、または DB 全体を複製対象として設定可能 • Subscription 毎に複製する操作を指定可能 •
  • 28.
    設定例( Subscription の作成) --Subscription 作成 =# CREATE SUBSCRIPTION hoge_sub CONNECTION ‘port= ... ‘ PUBLICATION hoge_pub; -- Subscription 確認 =# dRs+ List of subscriptions Name | Owner | Enabled | Publication | Synchronous commit | Conninfo ---------- --+--------------+------------+----------------+----------------------------+--------------------------------------- hoge_sub | masahiko | t | {hoge_pub} | off | dbname=postgres port=5550 (1 row) • Subscription を作成した時点からレプリケーションが開始される • レプリケーション開始時に初期データのコピーを実行される
  • 29.
    モニタリング -- Publisher 側 =#SELECT application_name, state, write_lag, flush_lag, replay_lag, sync_state FROM pg_stat_replication ; -[ RECORD 1 ]-----+---------------- application_name | hoge_sub state | streaming write_lag | 00:00:00.003926 flush_lag | 00:00:00.003926 replay_lag | 00:00:00.003926 sync_state | sync -- Subscriber 側 =# SELECT * FROM pg_stat_subscription ; -[ RECORD 1 ]------------+------------------------------ subid | 16388 subname | hoge_sub pid | 15796 relid | received_lsn | 0/1693EC8 last_msg_send_time | 2017-07-10 12:30:17.383905-07 last_msg_receipt_time | 2017-07-10 12:30:17.383994-07 latest_end_lsn | 0/1693EC8 latest_end_time | 2017-07-10 12:30:17.383905-07 -- Subscriber 側 =# SELECT * FROM pg_stat_subscription ; -[ RECORD 1 ]------------+------------------------------ subid | 16388 subname | hoge_sub pid | 15796 relid | received_lsn | 0/1693EC8 last_msg_send_time | 2017-07-10 12:30:17.383905-07 last_msg_receipt_time | 2017-07-10 12:30:17.383994-07 latest_end_lsn | 0/1693EC8 latest_end_time | 2017-07-10 12:30:17.383905-07
  • 30.
    仕組み • PostgreSQL のロジカルレプリケーションで送信しているのは SQL”ではない” • MySQL の Row-based Replication 相当 TABLE WAL wal sender wal sender apply worker apply worker TABLE WAL backendbackend ① Write ② Read ③ Decode ④ Send ⑤ Write ⑤ Write ① Write
  • 31.
    ロジカルレプリケーション できること • テーブル、 DB単位でのレプリケ ーション • 初期データの転送 • コンフリクトの解消(手動) できないこと • DDL レプリケーション • テーブル、 • Publication 、 Subscription 単 位での同期レプリケーション • 双方向レプリケーション(マルチマ スター) • テーブル以外のレプリケーション (シーケンスなど)
  • 32.
  • 33.
    Quorum ベース同期レプリケーション • Quorum(定足数 ) ベースとは ? • “quorum とは分散システムにおいて、分散トランザクションが処理を実行するため に必要な最低限の票の数である。” (Wikipedia より ) • 5 台の内、 3 台から応答が返ってきたら COMMIT とする、と言った感じ • 9.6 までは応答を待つスタンバイは”固定”だった マスタ スタンバイ A スタンバイ B スタンバイ C マスタ スタンバイ A スタンバイ B スタンバイ C スタンバイ A,B から応答 が返ってくるまで待つよ 3 台の内どれか 2 台 から応答が返ってくれ ばいいよ 応答 停止中・・・ 9.6 までの方式 Quorum ベース
  • 34.
    設定方法 • FIRST 、ANY で同期方法を選択 • N で台数を指定 • 例 • FIRST 2 (node1, node2, node3) • node1, node2 の 2 台からの返答を待つ • ANY 2 (node1, node2, node3) • node1, node2, node3 の内 2 台からの返答を待つ synchronous_standby_names = [ ANY | FIRST ] N (node1, node2, ... )synchronous_standby_names = [ ANY | FIRST ] N (node1, node2, ... )
  • 35.
    使い所・注意点 • N 台の中からK 台に同期的にデータを複製するという所は 同じ • 選び方の違いがあるだけ • 性能面では ANY の方が優位 • 遅いスタンバイに性能が引っ張られないため • ANY では今どれが同期スタンバイかは状況によって異なる • レプリケーション状況は pg_stat_replication で確認
  • 36.
    ここまでのまとめ • ロジカルレプリケーション →テーブル単位でのレプリケーションが可能に →Pub/Sub モデル →ただし、DDL はレプリケートされないので注意 • • • Quorum 同期レプリケーション →“5 個の中からどれでもいいので 2 個同期にする”みたいな使い方 →性能が遅いスタンバイに引きずられないので、性能的に優位になるケ ースが多い
  • 37.
    全 22 個の非互換箇所 •Hash インデックスは再作成する必要がある (pg_upgrade を使用し た場合 ) • “xlog” が” wal” に変更 • pg_xlog ディレクトリ、 XXX_xlog() 関数など、全ての xlog が wal に名称変 更 • pg_clog ディレクトリが pg_xact ディレクトリに名称変更 • “lsn” が” location” に変更 • 主に XXX_location() 関数が XXX_lsn() に称変更 • デフォルトで localhost からのレプリケーション接続が有効になった • pg_ctl がデフォルトで”待つ”動作になった :
  • 38.
    ここまでのまとめ • PostgreSQL 10では非互換箇所が多い! • 運用ツールに影響があるもの、セキュリティ的に影響があるものなの で、バージョンアップの際は必ず確認することを推奨します • 一覧はリリースノートでチェック
  • 39.
    まとめ • PostgreSQL 10は現在 Beta2  日本人開発者も多く参画している • リリースは 9 月頃を予定 • 正式リリースを待ってもよし • リリース前に使ってみるのもよし • 不具合を見つけたらバグレポください! • 英語が・・・というかたは日本 PostgreSQL ユーザ会の slack でも OK • もしくは、 @sawada_masahiko に連絡ください
  • 40.
    PostgreSQL の進化が止まらない! •さらなる機能拡充  並列分散 DB化  パラレル DDL  JIT コンパイル  セキュリティ機能の拡充 • •PostgreSQL の適用領域拡大へ
  • 41.
  • 42.
  • 43.
    参考資料 • Next-Generation ParallelQuery • https://www.pgcon.org/2017/schedule/attachments/445_Next- Generation%20Parallel%20Query%20-%20PGCon.pdf • 次期バージョン PostgreSQL 10 の新機能とその後の方向性 • https://www.sraoss.co.jp/event_seminar/2017/db_tech_show_cas e_oss_2017.pdf • PostgreSQL 10 がやってくる! • https://www.slideshare.net/toshiharada/jpug-studypostgre- sql10pub
  • 44.
    Thank you!! twitter :@sawada_masahiko mail : sawada_masahiko_f7@lab.ntt.co.jp
  • 45.
    その他たくさん新機能があります • HASH インデックスのWAL 対応 • 拡張統計情報( Multi Column Correlation) • JSON 型の全文検索サポート • ICU サポート • SCRAM 認証