PostgreSQL 17 / PatroniによるマルチAZ自動フェイルオーバークラスタ構築――etcd分散合意とDCS監視実務
要旨：ミッションクリティカルなデータベース運用において、RPO=0（データ損失ゼロ）とRTO<10秒（超高速切り替え）を両立するオープンソース標準が「Patroni＋etcd」によるHA構成である。本稿では、最新PostgreSQL 17環境におけるストリーミングレプリケーション、etcd分散合意（DCS）を用いたスプリットブレイン完全防止、およびクライアント接続用HAProxy連携の実装手順をまとめる。
1. 従来のVIP/レプリケーションの弱点とPatroniの強み
従来のCorosync/Pacemakerや独自スクリプトによるフェイルオーバーでは、ネットワーク分断（スプリットブレイン）発生時に旧プライマリが書き込みを受け付け続け、データ整合性が破綻する重大事故が絶えなかった。Patroniは、分散キーバリューストア（etcdまたはConsul）のTTL（Time to Live）リース機能を主権合意（Leader Election）に利用するため、過半数（Quorum）の合意が得られないノードは自律的にリードオンリーへ降格（Demote）し、データの二重書き込みを数学的に防ぐ。
2. etcdクラスタとPatroni設定実務
最低3ノードのetcdクラスタを構成し、各PostgreSQLノードにPatroniエージェントを配置する。
# /etc/patroni/pg17-ha.yml
scope: sidc-pg-cluster
namespace: /service
name: pg-node01
etcd3:
hosts:
- 192.168.10.11:2379
- 192.168.10.12:2379
- 192.168.10.13:2379
restapi:
listen: 0.0.0.0:8008
connect_address: 192.168.10.21:8008
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
parameters:
max_connections: 500
shared_buffers: 16GB
synchronous_commit: 'on'
3. HAProxyとのREST API連動による接続ルーティング
クライアントからの書き込み通信を常に現役プライマリへ誘導するため、HAProxyのHTTPヘルスチェック機能を用いてPatroniのREST API（GET http://<node>:8008/primary）を監視する。PrimaryノードのみがHTTP 200を返し、StandbyノードはHTTP 503を返すため、VIPを用いずにDNS/L4レベルでシームレスなゼロダウンタイム切り替えが成立する。