HA 集群 on pgcli

Patroni 高可用

Mon, 01 Jan 0001 00:00:00 +0000

Patroni 是 PostgreSQL 高可用的事实标准：它管理每个 postmaster 的生命周期、在成员间流式复制，并在 leader 失联时执行 自动故障切换。pgcli 将 Patroni 作为独立的模式暴露 —— pg ha —— 而不是把它揉进普通的 pg 实例管理路径。

Patroni 动态配置

Mon, 01 Jan 0001 00:00:00 +0000

这些参数存储在 DCS（etcd）的 /service/<scope>/config 下，应用于集群的所有成员。使用 pg ha edit-config 修改：

pg ha edit-config app -- -s loop_wait=5
pg ha edit-config app -- -s 'postgresql.parameters.max_connections=200'
pg ha edit-config app --show          # 查看当前配置

参考：Patroni 官方文档、 Pigsty 动态配置。

Patroni REST API

Mon, 01 Jan 0001 00:00:00 +0000

Patroni 在每个成员上暴露一个 HTTP REST API，提供健康检查端点（供负载均衡器和 Kubernetes 探针使用）、监控数据（含 Prometheus 指标）以及集群管理操作。

参考：Patroni 官方文档、 Pigsty REST API。

查找 REST API

每个成员的 REST API 端口由 pgcli 自动分配，存储在 pg.yaml 的 addons.patroni.<scope>.members.<name>.restapi_port 下。端口也写入渲染后的 patroni.yml 的 restapi.connect_address。

HA 集群扩展安装

Mon, 01 Jan 0001 00:00:00 +0000

在 Patroni 管理的 HA 集群中安装 PostgreSQL 扩展，与单节点实例有本质区别。本页解释原因，并介绍 pg ha extension 命令子树。

为什么不能用 `pg extension install`？

单节点流程（pg extension install <instance> <ext>）的工作方式是：

Patroni 集群备份

Mon, 01 Jan 0001 00:00:00 +0000

本页给出 Patroni HA 集群备份的完整操作流程：从 pg backup setup 打通备份基础设施，到 pg ha snapshot 做全量/增量/差异备份，再到一个运行态坑——副本 Replay LSN 卡住导致 pg ha status 显示成员 LSN 不一致时，如何用 patronictl reinit 拉回。命令与前置机制的参考细节见 Patroni HA 与备份；本页把它们串成一条能照着跑完的路径。

Patroni 集群恢复

Mon, 01 Jan 0001 00:00:00 +0000

本页是 Patroni 集群备份 的恢复侧姊妹页。集群一旦有了带 WAL 归档的 stanza（pg backup setup + pg ha snapshot），pg ha restore 就能把整个集群回到某个时间点——它是单实例 pg restore 的 Patroni 集群对应物。本页讲清机制（为什么集群 PITR 不是简单跑一次 pgbackrest restore）、关于 leader 所在主机的安全性预检、端到端操作流程，以及恢复之后必须做的重新基线步骤。命令 / flag 细节同时见恢复 → Patroni 集群；本页把它们串成一条可照着跑的流程。

HA Exec / psql

Mon, 01 Jan 0001 00:00:00 +0000

pg ha exec 和 pg ha psql 是对 Patroni 集群直接跑 SQL 的方式。它们是单实例 pg exec / pg psql 的集群对应物：你只给一个 scope，工具负责解析目标并连上去。不用手拼 --dsn、不用 podman exec 钻进成员容器，而且因为走的是普通 TCP，另一台主机上的 leader 或副本和本机成员一样可达。

示例：HA 集群 + 自签 CA 的 MinIO

Mon, 01 Jan 0001 00:00:00 +0000

这是一页实操示例，每一步都真实跑通并验证过：创建 Patroni HA 集群，架一台对外服务自带域名证书的 MinIO 插件（这里用我们自己造的自签 CA——与公共 CA、企业 CA 证书同一种形态，只是没去买），并把集群的 pgBackRest 备份与 WAL 归档指向它。下面每条命令都是实跑过的命令；只有主机名、端口、密码和证书材料做了泛化处理。

生成证书 —— pg cert

Mon, 01 Jan 0001 00:00:00 +0000

pg cert 签发一张自签证书——SubjectAltNames 覆盖你要求的任意域名 / IP 组合——适用于任何不想走 CA 又需要 TLS 的场合：开发或测试服务器、内部端点、客户端归你可控的服务。它写出的就是一张普通的 TLS 服务端叶证书，哪里都能用。

S3 存储高可用方案

Mon, 01 Jan 0001 00:00:00 +0000

Patroni 集群能扛住一个节点失联；它的 WAL 与备份流向的那个 S3 仓库却必须同样扛得住，否则"高可用"在备份这条路上悄无声息地就断了。store 是一个 MinIO 或 silo 插件（两者可互换——silo 是 Pigsty 的 MinIO 分支，功能面完全一致）。这里真正要紧的是两个互相正交的故障域：

HA 集群 on pgcli

Patroni 高可用

Patroni 动态配置

Patroni REST API

查找 REST API

HA 集群扩展安装

为什么不能用 pg extension install？

Patroni 集群备份

Patroni 集群恢复

HA Exec / psql

示例：HA 集群 + 自签 CA 的 MinIO

生成证书 —— pg cert

S3 存储高可用方案

为什么不能用 `pg extension install`？