平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“PostgreSQL四种常见部署模式对比”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

结合项目来看，repmgr 和 Patroni 都不是 PostgreSQL 数据库自带组件，而是需额外安装的第三方高可用管理软件。PostgreSQL 本身自带的是 Streaming Replication（流复制）能力，repmgr 和 Patroni 是在流复制基础上增加主备管理、自动切换和高可用能力。

PostgreSQL 常用能够理解为四种部署模式：

单实例、原生流复制、流复制 + repmgr、流复制 + Patroni

• repmgr：基本就是 Replication Manager 的缩写，中文可理解为 复制管理器落到代码里，。它是 PostgreSQL 的复制与故障切换管理工具，主要负责主备节点管理、监控、Switchover、Failover 等。
• Patroni：不是一个缩写在这个场景下，，没有类似 “P-A-T-R-O-N-I 分别代表什么单词” 的官方展开。官方把它定义为一个用来构建 PostgreSQL 高可用方案的 Python HA 框架，最早源自 Compose 的 Governor 项目分支。

需先明确一个概念：

实际处理时，repmgr 和 Patroni 不是新的数据复制技术，它们都是建立在 PostgreSQL Streaming Replication（流复制）之上的高可用管理组件。

它们之间的关系能够轻松理解为：

PostgreSQL
   │
   ├── 单实例
   │
   └── Streaming Replication
             │
             ├── + repmgr
             └── + Patroni

一、四种部署模式核心对比

二、WAL 是什么？

WAL 全称：

Write-Ahead Logging

即 预写式日志。

轻松理解：

业务修改数据
    ↓
先生成 WAL
    ↓
WAL先落盘
    ↓
数据页再写入磁盘

在主备流复制中：

Primary
   │
   │ WAL
   ↓
Standby
   │
   ↓
回放 WAL
   ↓
保持数据同步

所以 PostgreSQL 流复制的本质就是：

理解这一步时，主库不断产生 WAL，备库不断接收同时回放 WAL，从而保持主备数据同步。

三、单实例

只部署一台 PostgreSQL：

APP
 │
PG01

服务器数量

1 台

特点

• 没有主备
• 没有自动切换
• 服务器故障后数据库直接不可用
• 适合开发、测试或高可用要求较低的环境

一句话理解：

单实例 = 只有一套数据库，没有高可用。

四、原生 Streaming Replication

最基本的 PostgreSQL 主备架构：

PG01 Primary
      │
      │ WAL
      ↓
PG02 Standby

服务器数量

至少 2 台
PG01：Primary
PG02：Standby

特点

比如：

原来：
PG01 = Primary
PG02 = Standby

把 PG02 Promote 后：

PG02：Standby → Primary   ✅
PG01：Primary → Standby   ❌

在这个场景下，原来的 PG01 不会自动变成备库，需 DBA 再借助 pg_rewind、重新同步等方式加入。

一句话理解：

流复制 = 数据自动同步，但主备切换和角色管理主要依赖 DBA。

五、Streaming Replication + repmgr

repmgr 是 PostgreSQL 流复制的 主备管理工具。

主要作用包括：

• 监控 Primary / Standby
• Switchover
• Failover
• 自动 Promote
• 节点 Rejoin
• 管理复制拓扑

需几台服务器？

最低能够 2 台：

PG01：PostgreSQL + repmgr + repmgrd
PG02：PostgreSQL + repmgr + repmgrd

即：

PG01 Primary
      │
      ↓
PG02 Standby

但是生产环境通常建议 3 台。

一种常用方式：

PG01：PostgreSQL + repmgr + repmgrd
      Primary
PG02：PostgreSQL + repmgr + repmgrd
      Standby
PG03：PostgreSQL + repmgr + repmgrd
      Witness

结构：

              PG03
             Witness
                │
        ┌───────┴───────┐
        │               │
      PG01            PG02
    Primary          Standby

第三台也能够不做 Witness，而是部署成第二个 Standby：

PG01 = Primary
PG02 = Standby
PG03 = Standby

角色是否自动转换？

计划内 Switchover：

切换前：
PG01 = Primary
PG02 = Standby
        ↓
切换后：
PG01 = Standby
PG02 = Primary

因此：

repmgr 能够编排计划内主备角色互换。

主库突然故障时，repmgrd 能够自动提升 Standby，但旧 Primary 恢复后通常还需执行 Rejoin 等恢复操作。

一句话理解：

实际处理时，repmgr = 流复制 + 自动监控 + 主备切换 + Failover。

六、Streaming Replication + Patroni

Patroni 是 PostgreSQL 更完整的高可用管理框架。

主要负责：

• Primary 状态检测
• Leader 管理
• 自动选主
• 自动 Promote
• Switchover
• Failover
• 角色管理
• 防脑裂
• 故障节点重新加入管理

Patroni 通常还需：

etcd / Consul 等 DCS

用来保存集群状态和 Leader 信息。

Patroni 需几台服务器？

生产建议至少 3 台

一种最容易理解的三节点部署：

PG01：
PostgreSQL
Patroni
etcd
PG02：
PostgreSQL
Patroni
etcd
PG03：
PostgreSQL
Patroni
etcd

数据库角色比如：

PG01 = Primary
PG02 = Replica
PG03 = Replica

同时三台 etcd 组成：

3 节点 etcd 集群

结构：

              etcd Cluster
          ┌──────┼──────┐
          │      │      │
        PG01   PG02   PG03
       Patroni Patroni Patroni
       Primary Replica Replica

这里需留意：

在这个场景下，Patroni 本身能够管理两个或多个 PostgreSQL 节点，但如果要求企业级自动 HA 和可靠仲裁，DCS 通常要采用奇数节点形成多数派，所以生产上通常至少按 3 台服务器规划。

Patroni 角色是否自动转换？

计划 Switchover：

切换前：
PG01 = Primary
PG02 = Replica
PG03 = Replica

切换后能够变成：

PG01 = Replica
PG02 = Primary
PG03 = Replica

也就是：

Primary → Replica
Replica → Primary

由 Patroni 统一管理。

如果 PG01 突然故障：

PG01 Primary ×
       ↓
Patroni检测
       ↓
DCS判断Leader状态
       ↓
选择Replica
       ↓
PG02 Promote
       ↓
PG02 Primary

一句话理解：

在这个场景下，Patroni = 流复制 + 自动选主 + 自动切换 + 集群角色管理。

七、四种模式最关键区别

理解这一步时，若只想更快记住 PostgreSQL 的四种部署方式，看这一张表即可：

角色转换重点：

这里的“自动变备库”主要指 正常的计划 Switchover。

如果原 Primary 已经宕机：

Primary ×
Standby → Primary

实际处理时，旧 Primary 不可能在故障瞬间同步完成角色转换，恢复后仍需重新加入集群。

八、最后怎么理解

把这四种模式记成四句话即可：

单实例
= 1台数据库，没有HA

Streaming Replication
= 至少2台，解决数据主备同步

repmgr
= 通常3台，在流复制基础上增加自动监控和主备切换

Patroni
= 生产通常至少3台，在流复制基础上增加自动选主、自动故障切换和完整HA管理

因此，如果企业生产要求：

理解这一步时，主库故障能够自动发现、备库自动提升、计划切换后主备角色自动转换，同时尽可能减少 DBA 人工干预，

从实现思路看，就不能只部署 PostgreSQL 原生 Streaming Replication，而应进一步考虑 repmgr 或 Patroni实际处理时，；其中 Patroni 更偏向完整的 PostgreSQL 自动高可用架构。

实际处理时，总的来说，PostgreSQL四种常用部署模式适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。