PostgreSQLで高可用性を実現するにはどうしますか？

Question

Accepted Answer

**高可用性（HA）**とは、障害が発生した場合でも**レプリケーション**（スタンバイレプリカ）、**自動フェイルオーバー**（プライマリが失敗したときのレプリカの昇格）、および適切なアーキテクチャを通じてデータベースを利用可能に保つことを意味します。目標は、データベース障害がアプリケーション全体を停止させるため、ダウンタイムとデータ損失を最小化することです。

## レプリケーション + 自動フェイルオーバーの基礎

```text
Primary ──(streaming replication)──▶ Standby replica(s)

If the PRIMARY fails:
  → a STANDBY is automatically PROMOTED to become the new primary (FAILOVER)
  → the application reconnects to the new primary → minimal downtime
→ Without HA, a primary failure = total database outage = application down.
```

レプリケーションはスタンバイレプリカを同期状態に保ちます。**自動フェイルオーバー**はプライマリの障害を検出し、レプリカを昇格させます。これにより、完全な停止が短い中断に変わります。

## HA ツール（フェイルオーバーの自動化）

```text
Patroni → the popular HA solution: manages failover, uses a consensus store (etcd/
  Consul/ZooKeeper) to coordinate, prevents split-brain
repmgr → replication and failover management
Managed Postgres (AWS RDS/Aurora, Cloud SQL, etc.) → built-in HA with automatic failover
→ These automate detection + promotion, which is hard to do safely by hand.
```

手動フェイルオーバーは遅く、エラーが起きやすいため、HA ツール（またはマネージドサービス）がそれを安全に自動化します。これには**スプリットブレイン**（2つのプライマリが書き込みを受け入れてデータが破損する状態）の防止も含まれます。

## 接続ルーティング

```text
Applications need to find the CURRENT primary after a failover:
  → a load balancer / proxy (HAProxy, PgBouncer) or service discovery routes
    WRITES to the current primary and READS to replicas
  → after failover, routing updates to point to the new primary
```

## 重要な HA 考慮事項

```text
✓ Synchronous replication → no data loss on failover (vs async's small loss window)
✓ Multiple replicas / multiple availability zones → survive zone failures
✓ Avoid SPLIT-BRAIN (two primaries) — consensus/fencing prevents it (critical for safety)
✓ Monitoring + health checks to detect failures quickly
✓ Test failover regularly (like backups, untested failover may not work)
→ Many teams use MANAGED Postgres for built-in, battle-tested HA.
```

## なぜ重要なのか

高可用性は、**本番環境で重要**な PostgreSQL システムを運用するための重要な知識です。データベース障害はアプリケーション全体を停止させるため（データベースはしばしば最も重要な単一の依存関係）、障害に対して PostgreSQL を利用可能に保つ方法を理解することは、信頼性の高いシステムのための価値のある上級レベルの知識です。

基礎となるもの — **レプリケーションと自動フェイルオーバー** — は、プライマリデータベースの障害（そうでなければアプリケーション全体の停止となる）を短い復旧可能な中断に変えます。スタンバイレプリカは同期を保ち、プライマリが失敗すると、レプリカが自動的に昇格して引き継ぎます。

**HA ツール**（フェイルオーバーをコンセンサスストアで調整する一般的なソリューション Patroni、repmgr、またはビルトイン HA を備えたマネージドクラウド Postgres）の理解は重要です。フェイルオーバーを安全に自動化することは手作業では難しいからです。

**重要な考慮事項**を知ることは重要です：フェイルオーバー時のデータ損失がない**同期レプリケーション**、ゾーン障害に耐える**複数のアベイラビリティゾーンのレプリカ**、特に**スプリットブレインの防止**（2つのプライマリが同時に書き込みを受け入れることを防止して、データ破損を防ぐ — コンセンサス/フェンシングが防ぐ深刻なリスク）。

**接続ルーティング**（フェイルオーバー後に、ロードバランサー/プロキシを介してアプリケーションを現在のプライマリに向ける）の理解と、フェイルオーバー（バックアップと同じく）を**テスト**すべきことで、実用的な知識が完成します。

多くのチームがバトルテスト済みの HA を備えた**マネージド Postgres** を使用していることも関連があります。

データベース可用性は本番システムにとって重要（障害は全体を停止させる）であり、それを実現するにはレプリケーション、自動フェイルオーバー、スプリットブレイン防止、接続ルーティングの理解（またはマネージド HA の使用）が必要であるため、PostgreSQL 高可用性の理解は、信頼できる弾力的なシステムを構築するための重要な上級レベルの知識です。これは本番データベースにとって頻繁に重要な懸念事項であり、障害に対して生き残ることができるデータベースインフラストラクチャを構築する方法の理解を示すトピックであり、上級データベース/インフラストラクチャロール向けに予想されます。