PostgreSQL 高可用架构选型与实践

dbaai

一、具体的问题

很多团队在 PostgreSQL 上跑核心业务，最怕的不是查询慢，而是"主库一挂，业务全停"。老板问"能不能做到自动切换、少停机"，DBA 往往张口就是"上高可用"，但具体选型却纠结：是裸用流复制、上 repmgr，还是直接上 Patroni？到底哪套最适合自己的规模？本文把一个常见场景一次讲透：中小团队（单机房、1 主 1 备、要能自动故障转移）该怎么选、怎么落地、怎么验证。

二、核心原理

1. 高可用的三个层次

最简单的保障是流复制（Streaming Replication）：主库把 WAL 日志实时发给备库，备库重放，数据几乎零丢失（同步模式下可做到 RPO=0）。但它只解决"数据同步"，不解决"谁来切"——主库宕机后，需要人工或额外组件把备库提升为主，业务连接也得手动改地址。

repmgr 在流复制之上加了一层管理：它能自动检测主库故障、把备库提升为主、并更新连接元数据；但它不带分布式选主，多个节点同时抢主时仍要靠人工约定。

Patroni 更进一步，依赖 etcd/Consul/ZooKeeper 做分布式一致性选主，配合 VIP 或 HAProxy 实现真正自动切换，是现在云原生环境的主流方案。代价是引入了额外组件，运维心智成本更高。

一句话：单备、能接受手动切换 → 流复制足够；要自动故障转移又不想养复杂集群 → repmgr；多节点、要强一致自动选主 → Patroni。

2. 同步还是异步？

异步复制（默认）性能好，但主库宕机可能丢最后几秒数据；同步复制（synchronous_commit=on + 备库在同步列表中）保证主备数据一致，代价是备库网络抖动会拖慢主库写入。折中做法是"1 同步 + N 异步"，既能保底又不至于被单点拖累。

3. 一个常被忽略的坑：脑裂与连接漂移

自动切换最危险的不是切不过去，而是"两个主同时存在"。如果旧主还没真正死透，网络抖动后又恢复，就可能双写导致数据分叉。所以无论用 repmgr 还是 Patroni，都必须配 fences/witness，并让应用通过统一接入层（VIP 或中间件）访问，而不是写死主库 IP。

三、实例参考（动手步骤）

下面以"1 主 1 备 + 流复制"的最小可用落地为例，给出可照做的步骤（主库 192.168.1.10，备库 192.168.1.11）。

1) 主库打开归档与复制参数（postgresql.conf）：

2. wal_level = replica
3. max_wal_senders = 10
4. wal_keep_size = 1GB
5. listen_addresses = '*'

复制代码

并配置 pg_hba.conf 允许备库以复制身份连接：

2. host replication repluser 192.168.1.11/32 md5

复制代码

2) 创建复制用户并做基础备份（在备库执行 pg_basebackup）：

2. CREATE ROLE repluser WITH REPLICATION LOGIN PASSWORD '从配置文件取，不硬编码';
3. pg_basebackup -h 192.168.1.10 -U repluser -D /var/lib/pgsql/standby -Fp -Xs -P

复制代码

3) 备库建 recovery 配置（postgresql.auto.conf 或 standby.signal + primary_conninfo）：

2. primary_conninfo = 'host=192.168.1.10 port=5432 user=repluser password=xxx'

复制代码

4) 启动备库并验证复制状态：

2. SELECT pg_is_in_recovery();                 -- 返回 t 表示备库
3. SELECT * FROM pg_stat_replication;          -- 主库侧能看到备库连接与 replay 进度
4. SELECT now() - pg_last_xact_replay_timestamp() AS lag;  -- 观察复制延迟

复制代码

5) 前后对比：配置前备库无法实时同步，主库宕机业务需手工恢复；配置后 pg_stat_replication 出现活跃行、延迟通常在秒级，pg_is_in_recovery() 持续为 t。要注意 replication lag 为 0 不代表完全同步，只有开了同步复制才是强一致。

四、实操检查清单

• 主库是否开启 wal_level=replica 并配好 max_wal_senders 与 wal_keep_size（太小会被回收导致备库断流）？
  
• 备库 pg_is_in_recovery() 是否长期为 t，且 pg_stat_replication 在主库侧实时可见？
  
• 是否设置了复制槽（replication slot）防止 WAL 被主库提前清理、备库追不上？
  
• 是否定期用 pg_last_xact_replay_timestamp() 监控复制延迟，并设告警阈值（如 > 30 秒）？
  
• 主库宕机后的提升流程（pg_ctl promote 或 repmgr standby promote）是否演练过，而非临时查文档？
  
• 业务是否通过 VIP/中间件访问，避免脑裂时写串两个主库？
  
• 是否做过一次真实故障演练：关主库、验证备库提升、业务恢复、原主重新加回为备库？
  
• 备份恢复策略是否与复制分开：复制不是备份，误删表不会在备库自动保护，仍需独立备份。
  

把这份清单逐条核对，高可用才能真正兜底，而不是"以为有备库就安全"。