ハクソク

世界を動かす技術を、日本語で。

Pgactive: PostgreSQL アクティブ-アクティブレプリケーション拡張モジュール

313日前原文(github.com)

概要

pgactive は、PostgreSQL用の アクティブ-アクティブレプリケーション拡張機能。 従来の アクティブ-スタンバイ構成 との違いと、利用ケースを整理。 論理レプリケーション 技術の役割とPostgreSQLの対応状況を解説。 アクティブ-アクティブ構成で発生する 課題 と設計上の注意点。 ライセンス やセキュリティ関連情報への参照も記載。

pgactive：PostgreSQLのアクティブ-アクティブレプリケーション拡張

  • pgactive は、PostgreSQL向け アクティブ-アクティブ型データベース 構築用レプリケーション拡張
  • データベース間で 変更内容を相互複製 する仕組み
  • 主な用途
    • 高可用性 の実現
    • アプリケーションとデータソース間の レイテンシ削減
    • 本番-テスト環境間 や インフラ移行 時のデータ移動
  • PostgreSQL標準の アクティブ-スタンバイ型 レプリケーションとの違い
    • アクティブ-スタンバイ： 単一インスタンスのみ書き込み可、他は参照専用
    • アクティブ-アクティブ： 複数インスタンスで同時書き込み可能

アクティブ-アクティブ構成の特徴と課題

  • アクティブ-アクティブ構成 では、クラスタ内の複数DBが同時に 書き込み受付 可能
  • 単一の真実のソース が存在しないため、アプリケーション設計に 工夫が必要
  • 主なユースケース
    • マルチリージョン高可用性クラスタ
    • アプリ-DB間の 書き込みレイテンシ低減
    • Blue/Greenデプロイ 運用
    • 双方書き込み可能なシステム間移行
  • 設計時に考慮すべき課題
    • 変更競合 の発生
    • レプリケーション遅延
    • 連番（シーケンス） など一部DB機能の制限

論理レプリケーションの役割

  • 論理レプリケーション は、変更内容を 外部システムが解釈可能なデータ形式 で転送
  • 受信側DBでの 競合検知・解決 や SQL変換 など柔軟な処理が可能
  • PostgreSQL 10（2017年リリース）より ネイティブサポート
  • アクティブ-アクティブ構成 実現には、追加機能が必要
  • PostgreSQLの 拡張機構 により、pgactiveのような機能追加が可能

セキュリティおよびライセンス情報

  • セキュリティ詳細 は、CONTRIBUTINGドキュメント参照
  • ライセンス は、プロジェクト付属のLicenseファイル参照

Hackerたちの意見

どうやら、Postgresの論理レプリケーションを使って、あるPostgresインスタンスでの変更を別のインスタンスに共有してるみたい。競合解決はタイムスタンプに基づく「最後の書き込みが勝ち」方式だね。競合するトランザクションは特別なテーブル（pgactive_conflict_history）に記録されるから、履歴を見たり解決したりできるよ。 https://github.com/aws/pgactive/tree/main/docs

└

面白そうだね。じゃあ、自分の書き込みが受け入れられたか拒否されたかは、どのくらいでわかるの？すぐにわかるの、それとも後で？

└

これはマルチマスターレプリケーションなの？もしPostgres本体に取り入れられたら面白いね。

なんでAWSがこれに取り組んだのか、頭をひねって考えてるんだけど…彼らの製品で使われてるのが思いつかない。RDSはブロックレプリケーションを使ってるし、Auroraは独自のSANレプリケーション層を使ってる。DMSかな？

└

おそらく、数週間前にリリースされたAurora DSQLだね。

└

うん、でもこれはあまり役に立たない気がする。少なくとも、強いACIDリレーショナルデータベースでこれをやる理由がよくわからないな。

└

どうやら、RDS Postgresの機能として数年前から提供されてたみたいだよ。 https://aws.amazon.com/about-aws/whats-new/2023/10/pgactive-... でも、先月になってやっとオープンソースとしてコミュニティに正式にリリースしたんだって。 https://aws-news.com/article/2025-06-09-announcing-open-sour...

└

Auroraは独自のSANレプリケーションレイヤーを使ってるけど、クロスリージョンレプリケーションには使われてないと思う。

└

リポジトリのREADMEから: 「これのユースケースには、マルチリージョンの高可用性データベースクラスターの運用が含まれます。」

└

AWSはpgactiveを使って「Aurora Postgres Global」を売ってると思う。https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

自分が何をしてるか正確にわかってない限り、これを使わない方がいいよ。一般的に、パフォーマンスやスケーラビリティを向上させる方法ではないから。

非同期みたいだね？それってトランザクションの隔離にとって大きな問題だよ。

└

自分の好みを選んで。

ちょっと脱線するけど、関連してる。プライマリから読み込むけど、ローカルの変更も保持できる「ローカル書き込み可能」なリードレプリカって作れないかな？要するに、プロダクションやステージングからデータを取得できる開発用DBが欲しいんだけど、ローカルの変更をプライマリに戻さないやつね。私が普段やってるのは、定期的にスクリプトやcron、ワーカーを動かしてデータを取得すること。ダンプかクエリを実行してスナップショットを作成し、それをS3に保存して、ローカルの開発コードでそのスナップショットを取得してデータをローカルDBに挿入・復元するって感じ。これで多くのケースに対応できるけど、データによってはインデックス作成が面倒（時間がかかる）なんだよね。

└

ちなみに、ほとんどの人は法的な理由からこれをやらない方がいいって言うよ。PII情報とかは、いろんな理由でステージングや開発環境に置くことは通常許可されてないからね。これをやったり許可したりするのは、大きなリスクになるよ。

└

これについて気になるんだけど、ローカルの書き込みがリモートの更新と衝突した場合、どう対処するの？全てのシナリオ（あるいはほとんどの場合）で機能するマージ戦略は思いつかないな。

└

スナップショットを一切変更しない「ピュア」なローカルデータベースにロードして。開発データベースを「リセット」したいときは、データベースを削除してから、createdb --templateを使ってピュアなデータベースをコピーすればいい。これで事前に作成されたインデックスをコピーするから、再構築するよりずっと早いよ。

└

私の知る限り、それがPostgresの論理レプリケーション設定での標準的な動作だよ。レプリカで書き込みをすることを妨げるものはないけど、他の場所に送信されることはないよ。

2nd Quadrant/EDBの人たちから聞いた歴史を少し。BDR1 [0] が最初に登場して、オープンソースだった。pgactiveはBDR1をベースにしてる。BDR2はBDR1のクローズドソースの書き直しで、後に放棄された。pglogical v1とv2（PGL1、PGL2）はオープンソースで、今もそう。pglogical v1は大幅に改造された後、最終的にPostgres 10に統合された。このPostgres 10の論理レプリケーションからの学びを基に、2nd Quadrantはpglogical v2を始めた。pgEdgeはpglogical v2をベースにしてる。その後、2nd Quadrantはpglogical v3（クローズドソース）とBDR v3（クローズドソース）を始めた。これらはBDR v4に統合された。ある時点でBDR製品はPostgres Distributed（PGD）に名前が変更された [2]。2nd QuadrantはEDBに買収された。私たち（EDB）はPGD v6をリリースしたばかりだよ。[0] https://github.com/2ndQuadrant/bdr/tree/bdr-plugin/REL1_0_ST... [1] https://github.com/2ndquadrant/pglogical [2] https://www.enterprisedb.com/docs/pgd/latest/

└

PGDv6はまだクローズドソースだよね？

└

それから、https://postgrespro.com/docs/enterprise/current/multimaster もあるよ。歴史があるやつ。

関連情報。他にある？ Pgactive: Amazon RDS上のPostgreSQL用アクティブ-アクティブレプリケーション拡張 - https://news.ycombinator.com/item?id=37838223 - 2023年10月（コメント1件）

数多くのクラスターをrepmgrやpatroniでセットアップして、ゼロダウンタイムの本番環境で運用してきたけど… これが最後にインストールするプラグインだわ。夜はぐっすり眠りたいからね。

「コンフリクト解決」ってのは、実際には「すでにコミットされて承認されたデータを捨てることで耐久性を壊す」っていう婉曲表現に過ぎないってことをみんなに言い続けるのは全然飽きてない。全ての「アクティブ」で書き込みのデータ重複がないように設計するか（その場合、pgactiveみたいなソフトウェアはいいかもね）、純粋に分散型データベースを使うべき（Yugabyteみたいな）。