PostgreSQL Patroni集群组件作用介绍：Patroni、etcd、HAProxy、Keepalived、Watchdog

1. Watchdog 简介

1.1 核心作用

• 主节点故障检测

Watchdog 会定时检测数据库主节点（或 Pgpool 主节点）的运行状态。

一旦主节点宕机，它会发起故障切换请求。
• 协调主备切换

多个 Pgpool 节点时，Watchdog 保证只有一个 Pgpool 处于“主”状态，避免混乱。

使用仲裁机制或投票（通常通过 VIP、网络心跳或 quorum 判定）决定新的主节点。
• 避免脑裂

防止两个节点误判对方故障后“各自称王”导致的数据不一致。

Watchdog 通过心跳机制（heartbeat）+ 仲裁机制（arbitrator）+ VIP 管理，确保集群有单一主节点。
• 管理 VIP

Watchdog 控制一个浮动 IP（VIP），将其绑定到当前 Pgpool 主节点上。

客户端连接 VIP，无感知主备切换。

1.2 工作方式

节点通过心跳机制与仲裁机制协调主备身份并自动迁移 VIP。

心跳探测：每个 Pgpool Watchdog 互相通过 ping/TCP 检测存活状态。

仲裁：可以通过“仲裁者主机”或“第三方 etcd/Zookeeper”做一致性投票。

自动切换 VIP：主 Pgpool 宕机后，VIP 自动迁移到新的主节点。

1.3 应用场景

场景	是否需要 Watchdog
单节点 Pgpool	不需要
多节点 Pgpool + 自动主备切换	必须使用
提供高可用虚拟 IP（VIP）	必须使用
防止脑裂或双主场景	必须使用

2. etcd 简介

etcd 是一个开源的、分布式的键值存储系统，广泛用于服务发现、配置管理和主备协调等场景。

2.1 核心作用

• 存储 PostgreSQL 集群状态

etcd 存储整个 PostgreSQL 集群的元信息和状态信息，例如：

当前的主节点是谁（Leader）

各节点的健康状态

Patroni 实例的注册信息（IP、端口、角色等）

Failover 请求等

这样，所有节点都可基于 etcd 的一致性视图做决策，避免分歧。
• 分布式一致性协调器

etcd 基于 Raft 协议，提供分布式系统中一致性的基础，作用类似：

Zookeeper

Consul

etcd 保证任意节点都能看到相同的集群状态，从而在故障转移或主从切换时作出正确判断。
• 提供锁机制

Patroni 使用 etcd 的分布式锁（Leader Key）来决定主节点。

借助 etcd 的 TTL 租约机制，主节点需定期续约，否则失去主控权。

保证只有一个主节点存在（Single Leader），防止脑裂。

2.2 架构示意图

所有 Patroni 节点向 etcd 注册自身状态。

Patroni 主节点持有一个 etcd 的“Leader 锁”键（带 TTL）。

主节点宕机后 TTL 过期，锁自动释放，其他节点竞争新主。

2.3 典型用途

用途	示例系统
服务发现	Kubernetes
配置中心	Istio、Traefik
主备协调	Patroni、TiDB
分布式锁	主选举场景

2.4 特性总结

特性	说明
数据一致性	使用 Raft 实现强一致性
高可用部署	支持奇数节点，允许少数节点宕机
分布式锁	用于主节点选举
监控 & 续租	主节点失联自动释放锁
易部署	单一二进制与配置文件即可

3. Patroni 简介

Patroni 是一个开源的 PostgreSQL 高可用（HA）管理工具，专为构建自动化主备切换、健康检查、集群协调的 PostgreSQL 集群而设计。

它不是数据库本身，而是一个控制器，负责维护 PostgreSQL 的主从架构，并在主节点宕机时自动选择一个新主节点，保证服务连续性。

3.1 核心作用

• 自动主从切换

当 Patroni 监测到主库不可用时，会自动发起主从切换流程。

通过协调系统（如 etcd、Consul、ZooKeeper）选出新的主节点。
• 分布式选主

依赖后端协调服务（如 etcd）的分布式锁（leader key）机制，确保只有一个主节点存在。

有效防止脑裂（Split-Brain）现象。
• 集群状态管理

所有 Patroni 节点将自己的状态（角色、健康、PostgreSQL 配置等）注册到共享存储（如 etcd）。

客户端如 HAProxy、pgbouncer 可以通过 Patroni API 查询集群健康信息。
• 自动配置 PostgreSQL 复制

Patroni 自动配置 streaming replication（流复制），支持同步或异步模式。

自动处理 pg_hba.conf、主备配置差异、recovery.conf（或 standby.signal）等。
• 提供 REST API 接口

每个节点运行一个 HTTP REST API，可用于：

查询节点状态

手动发起 failover/switchover

管理维护模式（pause/resume）

3.2 架构示意图

+----------------------+          +----------------------+
|   PostgreSQL 主节点 |          |   PostgreSQL 从节点 |
|      Patroni         | <-----> |      Patroni         |
+----------------------+          +----------------------+
          |                                 |
          +-------------+   +---------------+
                          |   |
                     +---------+
                     | etcd   | <- 协调主选举
                     +---------+
所有节点通过 etcd 协调主节点身份。

Patroni 定期健康检查本地 PostgreSQL，并与集群中其他节点同步状态。

3.3 配套工具

工具/组件	作用
etcd / Consul	分布式一致性协调
HAProxy / pgbouncer	客户端连接负载均衡
WAL-G / Barman	备份与恢复

3.4 Patroni vs 其它 HA 方案

特性	Patroni	Pgpool-II	repmgr
主从切换	自动	半自动（需配置）	自动或手动
状态协调	etcd/Consul 支持	无状态或 Watchdog	无（自己维护）
配置自动化	高	中	中
架构复杂度	中	高（需 watchdog）	低（轻量）

4. HAProxy 简介

在 PostgreSQL 高可用集群中，HAProxy 充当的是客户端访问的统一入口，起到流量转发、负载均衡、故障切换引导的作用。

4.1 核心作用

• 客户端统一访问入口

无论 PostgreSQL 的主节点如何切换，客户端始终通过 HAProxy 的 IP 和端口连接。

客户端无需知道谁是当前主节点，避免频繁改配置。
• 主从识别自动转发

HAProxy 可结合 Patroni 的 REST API 判断当前主库。

根据主备角色，将写请求转发到主库，将读请求转发到从库（可实现读写分离）。
• 负载均衡

在读请求场景中（例如只读查询、BI分析），HAProxy 可将请求负载均衡到多个只读从库。
• 健康检查

自动探测数据库节点是否在线。

可通过 TCP 检查 PostgreSQL 端口、或调用 Patroni 的 /health HTTP API 返回状态。
• 支持 VIP 高可用

多个 HAProxy 节点 + VIP 浮动可实现自身的高可用，不再是单点。

4.2 架构示意图

HAProxy 架构图（结合 Patroni）

+-------------+        +------------------+
|   客户端     | -----> |   HAProxy 节点    |
+-------------+        +--------+---------+
                               |
         +---------------------+---------------------+
         |                     |                     |
+-------------+   +-------------------+   +-------------------+
| Patroni 主库 |   | Patroni 从库 1    |   | Patroni 从库 2    |
+-------------+   +-------------------+   +-------------------+

4.3 示例场景

功能需求	HAProxy 配置方式
主库写请求	frontend → backend 主节点（只选 leader）
从库读请求	frontend → backend 所有 follower 节点
健康检查	每隔几秒请求 Patroni API
故障自动切换	新主上线后自动切换到新主
多个 HAProxy 节点	使用 Keepalived + VIP

4.4 示例配置片段

主库健康检查：
frontend pgsql_front
    bind *:5432
    default_backend pgsql_primary

backend pgsql_primary
    option httpchk GET /master
    server node1 192.168.1.101:5432 check port 8008
    server node2 192.168.1.102:5432 check port 8008
    server node3 192.168.1.103:5432 check port 8008
说明：

port 8008 是 Patroni 默认的 HTTP API 端口。

GET /master 是自定义脚本或 HTTP 返回判断是否为主库。

4.5 特性总结

功能	说明
写请求引导	只连接主库，防止写入从库
读写分离	可配置多个 frontend/backend
故障自动绕行	通过健康检查绕过不可用节点
无感主备切换	客户端无需关心实际主节点地址

5. Keepalived 简介

在 PostgreSQL 高可用架构中，Keepalived 的主要作用是：通过 VRRP 协议提供高可用的虚拟IP（VIP）漂移机制，确保即使服务节点发生故障，客户端仍然能通过一个固定 IP 无缝访问数据库或中间件（如 HAProxy），实现 PostgreSQL 集群访问地址的高可用。

5.1 核心作用

• 虚拟 IP (VIP) 漂移

Keepalived 运行在多个节点上，多个节点共享一个 VIP（Virtual IP）。

其中一个节点是 MASTER，持有该 VIP，其他为 BACKUP。

MASTER 节点宕机时，VIP 自动漂移到 BACKUP 节点，实现 IP 的高可用。

• 服务可用性监控

Keepalived 可配置脚本或进程监控（如 HAProxy、PostgreSQL）。

若检测到服务失败，可主动释放 VIP 并由其它节点接管。

• 实现无单点的访问入口

通常结合 HAProxy 或 Pgpool-II 使用，确保即使一个代理节点宕机，客户端依然可用。

5.2 架构示意图

+------------+   VIP   +------------+   +-----------------+
| HAProxy A | <------> | HAProxy B |---| Patroni/Postgres|
| Keepalived|         |Keepalived |   +------------------+
+------------+         +------------+

客户端通过 VIP（如 192.168.1.100:5432）访问，无感切换。

工作机制简述：

• Keepalived 使用 VRRP 协议，维持节点优先级（priority）来决定谁持有 VIP。

• 定期心跳检测：

如果 MASTER 掉线，BACKUP 自动提升为 MASTER，接管 VIP。

当原 MASTER 恢复，可以自动重新接管（可配置）。

5.3 示例配置

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.1.100
    }
    track_script {
        chk_haproxy
    }
}

vrrp_script chk_haproxy {
    script "/etc/keepalived/check_haproxy.sh"
    interval 2
    weight -10
}
说明：

priority 决定主备优先级。

track_script 可用于检测 HAProxy 是否存活。

若脚本返回非 0，则降低优先级，触发 VIP 漂移。

5.4 特性总结

功能	说明
VIP 漂移	提供固定访问 IP，屏蔽后端节点变化
节点高可用	后备节点自动接管服务
主备监控	可结合 HAProxy/Pgpool 状态做切换
零停机切换	客户端连接不中断，无感知漂移