pgactive - Postgresのアクティブ-アクティブ複製拡張

 (github.com/aws)
9 ポイント 投稿者 GN⁺ 2025-07-18 | 1件のコメント | WhatsAppで共有
  • AWSが開発して公開した、PostgreSQL向けのアクティブ-アクティブ複製拡張
  • 複数のPostgreSQLインスタンスでデータの書き込み・更新が必要なとき、特定のインスタンスだけが変更を受け付ける従来のアクティブ-スタンバイモデルではなく、複数インスタンスで同時変更と複製が可能な構成を構築できる
  • 複数リージョンでの高可用性データベース構成や、書き込み遅延の最小化、アプリケーションのブルー/グリーンアップデート、双方向データマイグレーションのようなシナリオに適している
  • 論理複製を活用し、競合検出、書き込み競合の解決、ターゲットデータベースのフォーマット変換などをサポート

アクティブ-アクティブ複製の概念

  • 複製(Replication) は、データベース間で変更内容を同期する技術
  • 従来のPostgreSQLのアクティブ-スタンバイ構成は、1つのインスタンスだけが変更を受け付け、他は読み取り専用となるため、1か所が単一のデータソースとして機能する
  • pgactiveはアクティブ-アクティブ複製トポロジーを提供することで、複数インスタンスで同時にデータ書き込みを許可する
  • この方式は、複数の書き込み地点が必要な環境、たとえばマルチリージョン展開や双方向マイグレーションなどに適している
  • アクティブ-アクティブモデルでは、競合、遅延、一部機能の制約に対する別途の管理が必要

中核技術: 論理複製

  • 論理複製(Logical Replication) は、データを外部システムが解釈可能な形式で転送する
  • 論理複製により、対象データベースで競合検出、書き込み競合の解決、クエリ変換など、さまざまな付加機能を実装できる
  • PostgreSQLは2017年のバージョン10で基本的な論理複製を導入したが、アクティブ-アクティブ複製には追加機能が求められる
  • PostgreSQLの設計特性により、これらの機能は拡張(extension)形式として開発・適用できる
  • PostgreSQL開発コミュニティも、徐々にこの機能を基本プロジェクトへ追加している

関連記事

1件のコメント

 
GN⁺ 2025-07-18
Hacker Newsの意見
  • 2nd QuadrantやEDBのチームメンバーから聞いた、BDRとpglogical、pgactive、そしてPostgres Distributed(PGD)の発展史を整理してみる。
    最初に登場し、今もオープンソースなのがBDR1（リンク）で、pgactiveはこれをベースにしている。
    BDR2はBDR1をクローズドソースで書き直したものだったが、最終的に廃止された。
    pglogical v1とv2（どちらもオープンソース、リンク）が公開され、このうちv1が大幅に修正されてPostgres 10にマージされた。
    Postgres 10の論理レプリケーション機能の経験をもとに、2nd Quadrantはpglogical v2の開発を始め、ここからpgEdgeも生まれた。
    その後2nd Quadrantはクローズドソース版のpglogical v3とBDR v3を作り、両者を統合してBDR v4になった。
    さらにBDRという製品名はPostgres Distributed(PGD, リンク)に変更された。
    2ndQuadrantがEDBに買収され、EDBからPGD v6がリリースされた。
    • PostgresProにも別のmulti-masterレプリケーションシステムがある ドキュメントリンク
    • PGDv6は今でもクローズドソースなのかと質問している
  • このシステムはPostgresのLogical replicationを使って、あるインスタンスの変更を別のインスタンスへ伝える。
    競合が発生した場合はtimestamp基準で最後に書き込まれた値が最終的に適用される方式である。
    競合の発生履歴はpgactive_conflict_historyという特別なテーブルに残るため、履歴の確認や手動解決などが可能である。
    詳細およびドキュメントはこちらを参照。
    • これがmulti-master replicationに当たるのか気になる
      もしその機能を公式にPostgresへ取り込めるなら面白そうだ
    • ユーザーとしては、自分の書き込みが即時に確定するのか、それとも最終的に収束するだけなのかを知りたい
  • 最近Bloombergのデータベース（comdb2）を実際に使ってみた人がいるのか気になる
  • 関連はあるが少し脇道の話として、「ローカルで書き込み可能な（read replicaベースの）レプリケーション」を実現する方法があるのか気になる。
    たとえば本番やステージングのデータを読みつつ、ローカルでだけ変更でき、その結果はupstreamに反映されない二次データベースを使いたい。
    現在は定期的にスクリプト（cronなど）でデータダンプやクエリを実行してスナップショットを作り、それをS3に保存してからローカルで取得し、データを復元する方式が一般的である。
    この方法はたいてい有効だが、インデックス構築に時間がかかりすぎることがある。
    • ちなみに、個人情報などの機微情報の問題があるため、このようにstagingやdev環境へデータをそのまま入れるのは危険である。
      法的・倫理的な問題が大きいため、多くの企業ではこうしたやり方は推奨していない
    • Postgresのlogical replicationをフィルタ付きで使えば一方向レプリケーションが可能で、レプリケーションスロットを解除すればローカルで自由に変更できる。
      こうすればprimaryに影響を与えず、ローカルテーブルだけを更新できる
    • 「素の」状態のローカルデータベースをバックアップ用に置いておき、必要なときにこれを複製して開発用データベースとして使えば、インデックス構築なしでコピーが非常に速い。
      createdb --template コマンドがおすすめ
    • ローカル書き込みとリモート更新が衝突したらどう処理するのか気になる
      どんな状況にも当てはまるマージ戦略は思いつかない
    • 私の知る限り、Postgresの論理レプリケーション設定ではこれが標準的な動作である。
      replicaで書き込みを禁止するのではなく、単にその結果が他へ広がらないだけである
  • 「Conflict resolution」という用語は、結局のところ「すでにコミットされ承認されたデータを捨てることで耐久性を壊す」という意味だという点を常に意識すべきである。
    すべてのactiveインスタンスにまたがって、書き込み対象データ領域が重ならないようにアーキテクチャを設計するのが最善である。
    こういう場合にはpgactiveのようなツールは有用である。
    そうでなければ、最初から分散データベース（Yugabyteなど）を使うべきである
    • 公式ドキュメントでも、競合回避の方法としてmasterごとにschemaを分け、「各masterは各schemaの唯一のwriter」になるよう推奨している。
      すべてのmasterがすべてのschemaを読むことはできるが、書き込みはそれぞれ自分の担当だけにする方式を提案している。
      schemaだけでなく、partitionなども責務分散に使えるのか気になる
  • AWSがなぜこれを作ったのか考えてしまう。
    自社製品でこの機能を直接使う場面が思い浮かばない。
    RDSはblock replication、Auroraは独自のSAN replicationを使っている。
    DMSあたりで活用する意図なのではと推測している
    • おそらく最近リリースされた Aurora DSQL のためかもしれない
    • 正直なところ、大きな有用性がよく分からない。
      強いACIDを持つリレーショナルデータベースで、なぜわざわざこれをやる必要があるのか疑問である
    • AuroraのSAN replicationはcross region replicationには使われていないと理解している
    • そのリポジトリのreadmeにも「Multi-Region高可用性データベースクラスターの構築が主用途」と明記されている
    • 実際、RDS Postgresでは2年前から提供されていた機能だったという（関連リンク）。
      ただし1か月前にコミュニティへオープンソースとして正式公開したという知らせがあった（公式ニュース)
  • repmgrやpatroniを使って完全無停止環境で複数クラスタを運用したことがあるが、このプラグインは本当に最後の手段としてしか入れたくない。
    夜ぐっすり眠るためにも、できるだけ避けたい
  • 偶然にも最近、「自動フェイルオーバー、ノード復旧、ポイントインタイムリカバリ」が可能な高可用性Postgresクラスタを簡単に作る方法を探していた。
    patroni+etcd+haproxyの組み合わせがよく勧められているが、実際に使った人たちが熱量高く勧めているのを見ると、それだけの理由があるのだろう。
    ただ、docker composeで例のファイルを見たときは少し重たく感じた。
    pgpoolは各postgresの前に置くだけでよさそうなので簡単に見える。
    実際の現場でPostgresが好きな人たちのおすすめや経験が知りたい。
    docker composeベースで、できるだけ簡単に、高可用性と（最小限の）無損失、ポイントインタイムリカバリまで可能なクラスタ構築を目標にしている
    • Barmanのようなツールを探しているのかと質問している
    • cloudnativepgを使っているが、これだけで必要な機能の大半がそのまま動く
  • pgactiveや関連事例など、ほかに資料がないか共有している。
    <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
    Hacker Newsの投稿（2023年10月の投稿、コメント1件）
  • 非同期方式のようで、トランザクション分離性には大きな問題がありそうだ
    • 結局はトレードオフだという立場である
      つまり、それぞれの状況に応じて長所と短所を受け入れる必要がある