PGConf.dev 2024参加レポート - PostgreSQL 17での論理レプリケーションの新機能:技術者Blog
PostgreSQLインサイド

黒田 隼人

富士通株式会社
ソフトウェアオープンイノベーション事業本部 データマネジメント事業部

はじめに

2024年5月28日から31日にかけて開催されたPostgreSQL Development Conference 2024に参加しました。この記事では、私が講演したセッションの内容を中心に紹介します。

PostgreSQL Development Conference(PGConf.dev)とは

PGConf.devとは、PostgreSQL開発者とコミュニティ運営者が一堂に会して講演・議論を行う国際カンファレンスです。一般的な技術イベントとは異なり、企業の宣伝ではなく開発者間の交流に主眼を置いているという特徴があります。昨年まではPostgreSQL Conference(PGCon)というカンファレンスが開催されていましたが、PGConf.devはその後継となります。カナダのバンクーバーにあるサイモン・フレイザー大学(Simon Fraser University, SFU)で開催されました。
私たち富士通からは3名(Amit Kapila、Zhijie Hou、黒田)が参加し、2つの講演(詳細は「関連リンク」を参照)を主催しました。

カンファレンス会場近くのバンクーバー港
図1:カンファレンス会場近くのバンクーバー港

講演内容:論理レプリケーションに追加された新機能

私の講演は、大きく言うと論理レプリケーションに関するものです。PostgreSQL 17から、論理スタンバイ(サブスクライバー)を作成するための新たなサーバーアプリケーションが追加されるほか、論理レプリケーション構成を壊さずにpg_upgradeが使用可能となる予定です。これら次期バージョンの新機能について解説を行いました。

論理レプリケーションとは、データに対して行われた変更を抽出し、別のPostgreSQLサーバーへと複製する仕組みです。PostgreSQLのよく知られたレプリケーション機能として「ストリーミングレプリケーション」というものがありますが、この機能はノード間でデータの物理的な表現まで一致している必要があるため、異種OSや異なるPostgreSQLメジャーバージョン間ではレプリケーションができません。論理レプリケーションはこれらの制限を緩和し、より柔軟なシステムの構築を可能にしています。

ストリーミングレプリケーションと論理レプリケーションの違い(講演資料より)
図2:ストリーミングレプリケーションと論理レプリケーションの違い(講演資料より)

論理レプリケーションの詳細な仕組みやその他の違いについては、以下の記事で解説しています。

大規模環境における論理レプリケーション新規セットアップの課題解決

現在も活発に開発が進められている論理レプリケーションですが、まだいくつかの問題を抱えています。そのうちの1つが、「大規模環境では、新たに論理レプリケーションをセットアップするのが難しい」というものでした。論理レプリケーションでは、最初に対象となる全テーブルに対してCOPY文を発行し、初期のデータ同期を行います。そのためテーブル数やデータ量に応じて、初期データの同期に時間がかかってしまうという問題がありました。また、論理レプリケーションでは同期中に生成されたWALを保持し続ける必要があるため、同期時間が長すぎるとWAL格納ディスクが満杯になってしまい、サーバープロセスがクラッシュするという可能性がありました。

サブスクライバーを作成するときの問題点(講演資料より)
図3:サブスクライバーを作成するときの問題点(講演資料より)

そこで私たちは、システムに存在するであろうリードレプリカ(非同期の物理スタンバイ)に着目し、物理スタンバイをサブスクライバーに変換するサーバーアプリケーションであるpg_createsubscriberを開発しました。システムに存在する大量のデータを最初からコピーすることが問題の発端なので、ある程度ストリーミングレプリケーションを行い、変更に追従しているノードをベースに論理レプリケーションを構築することで、初期同期にかかる時間を削減できます。大量のWALが残存する問題は、そもそもCOPY文による初期データ同期を行わないことで解決しています。

新しいサーバーアプリケーションであるpg_createsubscriber(講演資料より)
図4:新しいサーバーアプリケーションであるpg_createsubscriber(講演資料より)

pg_upgradeの機能追加による論理レプリケーションクラスタのアップグレード手順簡易化

PostgreSQL 17では論理レプリケーションが抱えていた別の課題も解決しています。それは「pg_upgradeに(実質的に)対応していない」というものです。

論理レプリケーション環境を構築する際、内部的には「レプリケーションスロット」や「レプリケーション起点」といったオブジェクトが生成されます。これらはWALの送信状況や適用状況といったレプリケーション状態を記録するために必要なものですが、ノード固有の情報のためpg_upgradeによるアップグレードで移行されることはありません。そのため、論理レプリケーションを構築するノードをアップグレードした後は、ユーザーが手作業でこれら内部オブジェクトを再構築する必要がありました。

そこで私たちはpg_upgradeを改良し、それら内部オブジェクトの参照・再構築を行うように変更しました。この機能により、論理レプリケーションを構築するノードをアップグレードした場合でも、レプリケーションを自動的に再開する事が可能となります。

おわりに

昨年に続き私にとって2回目の国際カンファレンスに参加し、論理レプリケーションの取り組みを紹介しました。冒頭で述べたようにPGConf.devは開発者間の交流に主眼を置いているため、参加された開発者たちと論理レプリケーションの課題解決に対する議論ができ、とても有意義な時間を過ごすことができました。改めてPostgreSQLの拡張性が無限の可能性を秘めていることを実感しました。

今後も私たち富士通のチームは、カンファレンスへの積極的な提案やディスカッションに参加し、さらにPostgreSQLの発展に貢献していきたいと考えています。

関連リンク

PGConf.dev 2024での講演内容については、以下をご覧ください。

2024年7月31日公開

富士通のソフトウェア公式チャンネル(YouTube)

本コンテンツに関するお問い合わせ

お電話でのお問い合わせ

Webでのお問い合わせ

当社はセキュリティ保護の観点からSSL技術を使用しております。

ページの先頭へ