Patroni 管理的 PostgreSQL 高可用集群中的心跳机制-优快云博客

在 Patroni 管理的 PostgreSQL 高可用集群中，“心跳”机制是通过以下三个途径协同完成的：

Leader 锁续租（DCS 心跳）：Primary 节点上的 Patroni Agent 定期向分布式配置存储（DCS，如 etcd 或 Kubernetes API Server）写入和续租“leader key”，以表明自己仍然在线且健康；
Replica 状态上报（DCS 心跳）：每个 Replica 节点定期向 DCS 更新自身状态，包括同步进度、延迟等信息；
Patroni REST API 心跳：各节点启动一个 HTTP 服务，暴露 /health、/liveness、/readiness 等端点，外部代理或监控通过调用这些接口判断节点实时健康与角色。

当 Primary 或 Replica 未在超时时间内完成心跳续租或状态更新，或 /liveness 接口返回失败时，Patroni 会触发故障切换（failover）或禁用疑似故障节点，保证集群始终只有一个 Primary 并保持可用性。

Leader Key 写入：初次选举时，获胜的节点在 DCS 中创建一个带有 TTL（默认 30 s）的 key（/service/<cluster>/leader），并存储自己的节点信息。
心跳续租：Primary 的 Patroni Agent 每隔 loop_wait（默认 10 s）向 DCS 发送写请求，续租该 key，保持 TTL 始终有效。
超时检测：若 Primary 在 TTL（> loop_wait）内未续租，DCS 会自动删除该 key；其他 Replica Agent 会在下一次轮询中检测到 key 不存在，发起新一轮 Leader 选举。

patroni:
  loop_wait: 10              # 心跳间隔，秒  
  ttl: 30                    # 领导者锁 TTL，秒  
  retry_timeout: 10          # 续租失败重试间隔，秒

cluster.last_leader_operation：DCS 中保存 Primary 最后一次成功写入的 WAL 位置，供 Replica 计算复制延迟。
Replica Agent 每隔 loop_wait 向 DCS 写入自身状态，包括 role: replica、xlog 位置等信息。
延迟阈值：通过 GET /replica?lag=<max-lag> 接口，可让外部检查延迟是否低于阈值，否则视作故障。

/health：PostgreSQL 进程可用性检查；
/liveness：检测上一次心跳是否在 ttl 或 2*ttl（Replica）内执行，适合作为 Kubernetes livenessProbe；
/readiness：确保节点已就绪（Primary 或 PostgreSQL 正常运行），适合作为 readinessProbe。

这些端点可供外部代理（如 MetalLB、HAProxy）或监控系统实时获取节点角色和健康状态，以做流量路由或报警。

Primary 心跳丢失：若 Primary 在 ttl 内未续租 Leader Key，Replica Agent 会检测到 key 消失，且 /leader 返回 404，触发新一轮 Leader 选举。
Replica 心跳丢失：如果某 Replica 无法更新状态或 /liveness 超时，Patroni 会将该节点标记为下线，不再将其列为同步候选；若同步数量不足，可触发“降级”至异步或报错。
选举过程：Replica Agent 在 DCS 中创建选举 proposal，并尝试获取 Leader Key，获胜者调用 pg_promote 将自身升为 Primary，其余节点执行 pg_rewind 或 pg_basebackup 恢复成 Replica。

Percona Documentation: “High Availability in PostgreSQL with Patroni” (docs.percona.com)
Stormatics: “Understanding Patroni Failovers” (Stormatics)
Patroni REST API: Health Check Endpoints (patroni.readthedocs.io)
Patroni Replication Modes Documentation (patroni.readthedocs.io)
Crunchy Data Blog: “Patroni & etcd in High Availability Environments” (Crunchy Data)
Redrock Postgres: “PostgreSQL HA Clustering with Patroni” (红岩 PostgreSQL)
Nutanix Dev: “PostgreSQL High Availability … Under the Hood” (Nutanix)
Percona Blog: “PostgreSQL HA with Patroni: Test Failure Scenarios” (Percona)
Rockdata: “PostgreSQL High Availability with Patroni Intro” (红岩 PostgreSQL)
Patroni GitHub: Patroni Configuration Reference (rest_api & retry_timeout) (patroni.readthedocs.io)