1. Watchdog 简介
1.1 核心作用
• 主节点故障检测
Watchdog 会定时检测数据库主节点（或 Pgpool 主节点）的运行状态。
一旦主节点宕机，它会发起故障切换请求。
• 协调主备切换
多个 Pgpool 节点时，Watchdog 保证只有一个 Pgpool 处于"主"状态，避免混乱。
使用仲裁机制或投票（通常通过 VIP、网络心跳或 quorum 判定）决定新的主节点。
• 避免脑裂
防止两个节点误判对方故障后"各自称王"导致的数据不一致。
Watchdog 通过 心跳机制（heartbeat）+ 仲裁机制（arbitrator）+ VIP 管理，确保集群有单一主节点。
• 管理 VIP
Watchdog 控制一个浮动 IP（VIP），将其绑定到当前 Pgpool 主节点上。
客户端连接 VIP，无感知主备切换。
1.2 工作方式
（以 Pgpool-II 为例）
+-------------+ +-------------+ +-------------+
| Pgpool 1 |<--->| Pgpool 2 |<--->| Pgpool 3 |
| (主节点) | | (备用节点) | | (备用节点) |
+-------------+ +-------------+ +-------------+
| | |
+--- VIP 地址由 Watchdog 绑定在主 Pgpool 上 ---+
节点通过心跳机制与仲裁机制协调主备身份并自动迁移 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 节点 A | <-----> | etcd |
| PostgreSQL主库 | +-------------+
+----------------+ ↑
状态存储
+----------------+ +-------------+
| Patroni 节点 B | <-----> | etcd |
| PostgreSQL从库 | +-------------+
+----------------+
关键行为：
所有 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 状态做切换 |
| 零停机切换 | 客户端连接不中断，无感知漂移 |