Open Source
Patroni PostgreSQL HA
Patroni・etcd・PgBouncer・HAProxy をベースに、PostgreSQL 高可用性(HA)クラスタを Ansible Playbook の一回の実行で構築するオープンソースプロジェクトです。
Apache License 2.0 · オープンソースGitHub リポジトリ
SQL 接続とクラスタ制御
アプリケーション接続は VIP・HAProxy・PgBouncer を経て PostgreSQL に届き、Patroni と etcd は別の経路でリーダー状態を調整します。
- 1.接続先ポートを選択
- 同じ VIP の 5000 ポートは読み書き用、5001 ポートはレプリカ優先です。Keepalived が HAProxy ホスト上の VIP を管理します。
- 2.転送と接続プール
- HAProxy は Patroni の /primary・/replica 応答で接続先を選び、対象 DB ホストの PgBouncer 6432 ポートに転送します。
- 3.保存とレプリケーション
- PgBouncer は同じホストの PostgreSQL 5432 ポートに接続します。リーダーの WAL をレプリカへ転送し、SQL 通信は Patroni を経由しません。
- 4.リーダー状態を調整
- 各 DB ホストの Patroni が etcd のリーダーキーを管理し、ローカル PostgreSQL の昇格・降格を制御します。監視・制御は SQL 接続と別経路です。
既定は非同期レプリケーションです。正常なレプリカがない場合、読み取りポートもリーダーに接続します。etcd 3 ノードのクォーラムは 2 です。
GitHubの文書・コードを見るリーダー障害から再接続まで
リーダーのリース失効から、新リーダーの選出、ヘルスチェック、アプリケーションの再接続までを追います。
- 1.リーダー障害を検知
- 旧リーダーが etcd のリースを更新できなくなると、リースが失効します。HAProxy もヘルスチェックにより障害のある接続先を除外します。
- 2.リーダーロックを取得
- 昇格条件を満たすレプリカの Patroni が etcd リーダーキーを取得します。etcd のクォーラムとレプリケーション状態が切り替え条件になります。
- 3.昇格して経路を変更
- 新リーダーの PostgreSQL が昇格し、Patroni /primary が 200 を返すと、HAProxy が書き込み接続をそのホストの PgBouncer に転送します。
- 4.再接続して確認
- アプリケーションが同じ VIP:5000 に新しい接続を確立します。patronictl と SQL で役割・複製状態を確認し、旧リーダーの再参加は別の復旧手順で行います。
既定のリーダー TTL は 30 秒、Patroni の確認周期は 10 秒です。切り替え時間は状態と設定に依存し、DB リーダーの交代が必ず VIP の移動を伴うわけではありません。
GitHubの文書・コードを見る配置構成の選択と導入検証
etcd を分離する構成または 3 台に集約する構成を選び、クラスタを検証します。
- 1.分離型
- etcd 専用 3 台と DB 2 台以上を配置します。
- 2.集約型
- 6 つの構成要素を 3 台に同居させます。
- 3.構成要素の役割
- SQL 経路、接続プール、保存、リーダー調整を分離します。
- 4.自動化
- 設定、導入、接続経路と複製の検証を行います。
文書では PostgreSQL 14–17、標準は 16 です。切り替え時は接続が切れる場合があります。同期複製と pgBackRest は任意設定です。
GitHubの文書・コードを見る