您如何在 PostgreSQL 中实现高可用性？

Question

Accepted Answer

**高可用性 (HA)** 意味着即使在发生故障时也要保持数据库可用 — 通过 **replication**（standby 副本）、**automatic failover**（当主库故障时提升副本），以及适当的架构。目标：最小化停机时间和数据丢失，因为数据库故障会导致整个应用程序瘫痪。

## 基础：replication + automatic failover

```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.
```

Replication 保持 standby 副本同步；**automatic failover** 检测主库故障并提升副本 — 将完全中断转变为短暂的服务中断。

## HA 工具（自动化 failover）

```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.
```

手动 failover 速度慢且容易出错，因此 HA 工具（或托管服务）将其安全地自动化 — 包括防止 **split-brain**（两个主库同时接受写入，这会破坏数据）。

## 连接路由

```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.
```

## 为什么这很重要

高可用性对于操作 **production-critical** PostgreSQL 系统来说是重要知识，因为数据库故障会导致整个应用程序宕机（数据库通常是最关键的依赖项），所以理解如何在出现故障时保持 Postgres 可用是构建可靠系统的宝贵高级知识。

基础 — **replication 加 automatic failover** — 将主数据库故障（否则会导致完全的应用程序宕机）转变为短暂的、可恢复的中断：standby 副本保持同步，当主库故障时，副本会自动提升接管。

理解 **HA 工具**（Patroni — 通过共识存储协调 failover 的流行解决方案；repmgr；或具有内置 HA 的托管云 Postgres）很重要，因为自动化安全的 failover 很难手动完成。

了解 **关键考虑因素**至关重要：**synchronous replication** 确保 failover 时不丢失数据，**跨可用区的多个副本**以在区域故障中存活，尤其是 **避免 split-brain**（防止两个主库同时接受写入，这会破坏数据 — 共识/防护机制防止的严重风险）。

理解 **连接路由**（通过负载均衡器/代理在 failover 后将应用程序指向当前主库）以及 failover（如备份）应该被 **测试**完整了实际知识。

了解许多团队为了经过战斗考验的 HA 而使用 **托管 Postgres** 也是相关的。

由于数据库可用性对于生产系统至关重要（故障会导致一切停止），并且实现它需要理解 replication、automatic failover、split-brain 防护和连接路由（或使用托管 HA），理解 PostgreSQL 高可用性是构建可靠、有弹性系统的重要高级知识 — 对于生产数据库来说是经常性的关键问题，也是展示如何构建能够经受故障的数据库基础设施的主题，预期出现在高级数据库/基础设施职位。