repmgr 和 Patroni 都不是 PostgreSQL 数据库自带组件,而是需要额外安装的第三方高可用管理软件。PostgreSQL 本身自带的是 Streaming Replication(流复制)能力,repmgr 和 Patroni 是在流复制基础上增加主备管理、自动切换和高可用能力。
| 组件 | PostgreSQL 自带? | 是否单独安装 | 主要作用 |
|---|---|---|---|
| Streaming Replication | ✅ | ❌ | PostgreSQL 原生主备复制 |
| repmgr | ❌ | ✅ | 主备管理、Switchover、Failover、节点 Rejoin |
| Patroni | ❌ | ✅ | 自动选主、Switchover、Failover、HA 管理 |

PostgreSQL 常见可以理解为四种部署模式:
单实例、原生流复制、流复制 + repmgr、流复制 + Patroni
- repmgr :基本就是 Replication Manager 的缩写,中文可理解为 复制管理器。它是 PostgreSQL 的复制与故障切换管理工具,主要负责主备节点管理、监控、Switchover、Failover 等。
- Patroni :不是一个缩写,没有类似 "P-A-T-R-O-N-I 分别代表什么单词" 的官方展开。官方把它定义为一个用于构建 PostgreSQL 高可用方案的 Python HA 框架,最早源自 Compose 的 Governor 项目分支。
| 名称 | 是否缩写 | 含义 |
|---|---|---|
| repmgr | ✅ | Replication Manager,复制管理器 |
| Patroni | ❌ | 项目名称,PostgreSQL 高可用管理框架 |
需要先明确一个概念:
repmgr 和 Patroni 不是新的数据复制技术,它们都是建立在 PostgreSQL Streaming Replication(流复制)之上的高可用管理组件。
它们之间的关系可以简单理解为:
PostgreSQL
│
├── 单实例
│
└── Streaming Replication
│
├── + repmgr
└── + Patroni
一、四种部署模式核心对比
| 部署模式 | 服务器数量 | 数据主备 | 自动故障切换 | 计划切换角色自动转换 | 定位 |
|---|---|---|---|---|---|
| 单实例 | 1 台 | ❌ | ❌ | 不涉及 | 基础部署 |
| Streaming Replication | 至少 2 台 | ✅ | ❌ | ❌ | 原生主备 |
| Streaming + repmgr | 至少 2 台,生产常见 3 台 | ✅ | ✅ | ✅ | 轻量级 HA |
| Streaming + Patroni | 生产建议至少 3 台 | ✅ | ✅ | ✅ | 自动高可用 |
二、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
特点
| 能力 | 是否支持 |
|---|---|
| 数据实时复制 | ✅ |
| Standby 数据副本 | ✅ |
| Standby 提升为 Primary | ✅ |
| 自动检测主库故障 | ❌ |
| 自动故障切换 | ❌ |
| 主备角色自动互换 | ❌ |
例如:
原来:
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 的四种部署方式,看这一张表即可:
| 模式 | 最典型部署 | 核心理解 |
|---|---|---|
| 单实例 | 1 台 | 只有数据库,没有主备 |
| Streaming Replication | 2 台:1主1备 | 数据自动同步,切换主要靠人工 |
| repmgr | 3 台:2数据库 + 1 Witness,或1主2备 | 流复制基础上的轻量 HA 管理 |
| Patroni | 3 台:1 Primary + 2 Replica,并配 DCS | 自动选主、自动切换、完整 HA 管理 |
角色转换重点:
| 部署方式 | 备库提升主库 | 原主库自动变备库 | 计划切换角色互换 |
|---|---|---|---|
| Streaming Replication | ✅ | ❌ | ❌ |
| repmgr | ✅ | ✅ | ✅ |
| Patroni | ✅ | ✅ | ✅ |
这里的"自动变备库"主要指 正常的计划 Switchover。
如果原 Primary 已经宕机:
Primary ×
Standby → Primary
旧 Primary 不可能在故障瞬间同步完成角色转换,恢复后仍需要重新加入集群。
八、最终怎么理解
把这四种模式记成四句话即可:
单实例
= 1台数据库,没有HA
Streaming Replication
= 至少2台,解决数据主备同步
repmgr
= 通常3台,在流复制基础上增加自动监控和主备切换
Patroni
= 生产通常至少3台,在流复制基础上增加自动选主、自动故障切换和完整HA管理
因此,如果企业生产要求:
主库故障能够自动发现、备库自动提升、计划切换后主备角色自动转换,并尽可能减少 DBA 人工干预,
就不能只部署 PostgreSQL 原生 Streaming Replication,而应进一步考虑 repmgr 或 Patroni;其中 Patroni 更偏向完整的 PostgreSQL 自动高可用架构。