目录
基础依赖包安装
consul配置
patroni配置
vip-manager配置
pgbouncer配置
haproxy配置
验证
本文将介绍如何使用Patroni、Consul、vip-manager、Pgbouncer、HaProxy组件来部署一个3节点的高可用、高吞吐、负载均衡的PostgresSQL集群（14版本），大致的架构图如下，这种架构是业界比较认可和广泛实用的（例如Pigsty）优点是：
- 使用Patroni和Consul来接管pg，完成它的生命周期管理，包括initdb到切换，避免手动的backup操作，Consul会选举Patroni的主当做pg的主；
- 使用冗余的Pgbouncer来完成pg的连接池化，降低进程开销；
- 使用Haproxy来进行所有请求负载均衡到连接池，还可以进一步实现读写分离；
但这种架构缺陷是Consul是跟pg节点共同部署的，如果consul单独抽出来可以同时管理多套pg高可用集群。
+-------------------+
| 客户端 |
+-------------------+
↓ (连接 VIP:5436)
+-------------------+
| HAProxy | ← 监听VIP:5436负载均衡
| (VIP:100.3.254.200)|
+-------------------+
↓ (轮询转发到三节点PgBouncer的6432)
+-------------------+ +-------------------+ +-------------------+
| 节点1 | | 节点2 | | 节点3 |
| - PgBouncer (6432)| | - PgBouncer (6432)| | - PgBouncer (6432)|
+-------------------+ +-------------------+ +-------------------+
↓ (通过 VIP 连接) ↓ (通过 VIP 连接) ↓ (通过 VIP 连接)
+-----------------------------------------------------------------------+
| vip-manager 管理的PostgreSQL 主节点 (VIP:100.3.254.200:5432) |
+-----------------------------------------------------------------------+
+---------↓----------+ +---------↓-------+ +---------↓-------+
| 节点1 | | 节点2 | | 节点3 |
| - Patroni | | - Patroni | | - Patroni |
| - Consul | | - Consul | | - Consul |
| - PostgreSQL | | - PostgreSQL | | - PostgreSQL |
+-------------------+ +-------------------+ +-------------------+基础依赖包安装
因为复用3节点资源("100.3.254.210","100.3.254.211","100.3.254.212")，dstat用于监控资源情况，每个节点都安装所有的yum包，下面的步骤将分别细说为什么在每个节点都安装这些包；
yum install -y postgresql14
yum install -y consul
yum install -y patroni
yum install -y vip-manager
yum install -y dstat
yum install -y haproxy关闭防火墙
systemctl status firewalld
systemctl stop firewalld
systemctl disable firewalldsetenforce配置
sudo setenforce 0hostname配置
[root@node2 ~]# hostnamectl set-hostname node2
# 校验
[root@node2 ~]# hostname
node2
# 在每个节点上配置node（可选）
[root@node2 ~]# vi /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
100.3.254.210 node1
100.3.254.211 node2
100.3.254.212 node3consul配置
consul是Go 语言开发的用于服务发现与分布式配置管理工具，Patroni 通过 Consul 的 Session + Lock 机制实现分布式选举，使用 Consul 的 KV 存储保存集群元数据（如当前主节点、节点列表、配置参数）;
在3个节点上配置启动consul，配置consul.hc1文件中只有bind_addr有差异，如下：
vi /etc/consul.d/consul.hcl
datacenter = "dc1"
data_dir = "/opt/consul"
server = true
bootstrap_expect = 3
bind_addr = "100.3.254.210" # 当前节点 IP
client_addr = "0.0.0.0"
retry_join = ["100.3.254.210","100.3.254.211","100.3.254.212"]
ui = true
# 创建数据目录（dcs相当于分布式数据库）
chown -R consul:consul /opt/consul
# 直接启动
systemctl start consul
systemctl enable consul
# 查看consul节点说
[root@node1 ~]# consul members
Node Address Status Type Build Protocol DC Partition Segment
node1 100.3.254.210:8301 alive server 1.12.2 2 dc1 default <all>
node2 100.3.254.211:8301 alive server 1.12.2 2 dc1 default <all>
node3 100.3.254.212:8301 alive server 1.12.2 2 dc1 default <all>
[root@node1 ~]# 配置文件中ui = true能够打开web页面查看信息，包括后续patroni在consul中注册的k/v信息；
patroni配置
Patroni 是Python 编写的用于管理 PostgreSQL 高可用性的工具，实现 PostgreSQL 集群的自动化高可用，处理主节点故障转移、从节点同步等任务，确保数据库服务的连续性，厅提供
- 注册：Patroni 节点在启动时，会将自己的服务信息（如节点名称、角色、IP 地址、端口等）注册到 Consul 的 KV 存储中。例如，每个节点会在 Consul 的
/service/postgresql路径下创建一个子目录，用于存储自己的详细信息。 - 发现：其他组件（如 HAProxy、Pgbouncer 等）可以通过 Consul 的 API 或 DNS 接口来查询可用的 PostgreSQL 节点信息。这样，当主节点发生切换时，这些组件可以及时获取到新的主节点信息，从而实现负载均衡和连接管理。
Patroni管理Postgresql的用户、配置、初始化、启停生命周期、主备切换与故障恢复的配置都非常简单，
patronictl工具使用方法：
# 基础状态查询
patronictl -c /path/to/patroni.yml list my-cluster # 查看集群成员状态
patronictl -c /path/to/patroni.yml show-config my-cluster # 查看动态配置
patronictl -c /path/to/patroni.yml history my-cluster # 查看故障转移历史
patronictl -c /path/to/patroni.yml dsn my-cluster node1 # 获取节点连接字符串
patronictl -c /path/to/patroni.yml version # 查看版本信息
# 主备切换（Switchover）
patronictl -c /path/to/patroni.yml switchover my-cluster --to node2 # 手动切换主节点到 node2
patronictl -c /path/to/patroni.yml switchover my-cluster --scheduled "2025-03-22T08:00:00Z" # 定时切换
patronictl -c /path/to/patroni.yml switchover my-cluster --force # 强制切换
patronictl -c /path/to/patroni.yml switchover my-cluster --group 0 # 指定组别切换
# 故障转移（Failover）
patronictl -c /path/to/patroni.yml failover my-cluster --force # 强制故障转移
patronictl -c /path/to/patroni.yml failover my-cluster --node node3 # 指定新主节点
# 配置管理
patronictl -c /path/to/patroni.yml edit-config my-cluster # 修改动态配置（如 loop_wait、ttl）
patronictl configure > /path/to/new-patroni.yml # 生成默认配置模板
# 维护操作
patronictl -c /path/to/patroni.yml restart my-cluster node1 --force # 重启指定节点
patronictl -c /path/to/patroni.yml reinit my-cluster node2 # 重新初始化节点
patronictl -c /path/to/patroni.yml pause my-cluster # 暂停自动故障转移
patronictl -c /path/to/patroni.yml resume my-cluster # 恢复自动故障转移patroni配置文件如下：
cat /etc/patroni.yml
# 集群名称，所有节点的该配置项需保持一致，用于标识属于同一个 PostgreSQL 集群
scope: pg_cluster
# 节点的唯一名称，不同节点应使用不同的名称，例如 pg-node1、pg-node2、pg-node3
name: pg-node1
# REST API 相关配置，用于外部程序与 Patroni 进行交互
restapi:
# REST API 监听的地址和端口，0.0.0.0 表示监听所有可用的网络接口
listen: 0.0.0.0:8008
# 当前节点用于外部连接 REST API 的 IP 地址和端口
connect_address: 100.3.254.210:8008
# Consul 相关配置，Consul 作为分布式协调系统，用于存储集群状态信息
consul:
# Consul 服务的地址和端口，这里使用本地默认端口
host: 127.0.0.1:8500
# 集群启动时的初始化配置
bootstrap:
# 分布式协调系统（DCS）相关配置
dcs:
# Leader 锁的生存时间（Time To Live），单位为秒，超过该时间 Leader 锁将失效
ttl: 30
# 状态检查的时间间隔，单位为秒，Patroni 会按照该间隔检查集群状态
loop_wait: 10
# 操作重试的超时时间，单位为秒，如果操作在该时间内未完成则进行重试
retry_timeout: 10
postgresql:
# 允许节点在重新加入集群时自动使用 pg_rewind 工具修复数据差异
use_pg_rewind: true
# 使用复制槽来确保流复制的可靠性，避免数据丢失
use_slots: true
# PostgreSQL 数据库的参数配置
parameters:
# 数据库允许的最大连接数
max_connections: 100
# WAL（Write-Ahead Logging）日志级别，replica 表示支持流复制
wal_level: replica
# 启用热备模式，允许在备库上进行只读查询
hot_standby: "on"
# 初始化数据库时的配置参数
initdb:
# 数据库的字符编码设置为 UTF8
- encoding: UTF8
# 数据库的区域设置为 en_US.UTF-8
- locale: en_US.UTF-8
# PostgreSQL 的客户端访问控制规则，用于限制哪些客户端可以连接到数据库
pg_hba:
# 允许所有子网内的客户端使用 replicator 用户进行复制连接，使用 md5 加密认证
- host replication replicator all md5
# 允许所有客户端使用任何用户连接到数据库，使用 md5 加密认证
- host all all 0.0.0.0/0 md5
# PostgreSQL 数据库本身的配置
postgresql:
# PostgreSQL 数据库监听的地址和端口，0.0.0.0 表示监听所有可用的网络接口
listen: 0.0.0.0:5432
# 当前节点用于外部连接 PostgreSQL 数据库的 IP 地址和端口
connect_address: 100.3.254.210:5432
# PostgreSQL 数据库的数据文件存储目录
data_dir: /opt/pgsql/14/data
# PostgreSQL 二进制可执行文件所在的目录
bin_dir: /usr/local/tos/pgsql/bin
# 数据库的认证配置，包括复制用户和超级用户的信息
authentication:
replication:
# 用于流复制的用户名
username: replicator
# 用于流复制的用户密码
password: patroni123
superuser:
# 数据库超级用户的用户名
username: postgres
# 数据库超级用户的密码
password: patroni123增加patroni服务：
[root@node1 ~]# vi /etc/systemd/system/patroni.service
[Unit]
Description=Patroni - HA PostgreSQL
After=network.target
[Service]
Type=simple
User=postgres
Group=postgres
ExecStart=/usr/bin/patroni /etc/patroni.yml
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
# 启动
systemctl start patroni.service
systemctl status patroni.service patroni启动后会自动完成postgreSQL集群的启动和初始化，并选主节点；
[root@node1 ~]# patronictl -c /etc/patroni.yml list
+----------+---------------+---------+---------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+ Cluster: pg_cluster (7482703141283838846) ---+----+-----------+
| pg-node1 | 100.3.254.210 | Replica | running | 3 | 0 |
| pg-node2 | 100.3.254.211 | Leader | running | 3 | |
| pg-node3 | 100.3.254.212 | Replica | running | 3 | 0 |
+----------+---------------+---------+---------+----+-----------+
# psql查看复制状态
postgres=# select * from pg_stat_replication;
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backen
d_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state |
reply_time
-------+----------+------------+------------------+---------------+-----------------+-------------+-------------------------------+-------
-------+-----------+-----------+-----------+-----------+------------+-----------+-----------+------------+---------------+------------+---
----------------------------
15132 | 16384 | replicator | pg-node1 | 100.3.254.210 | | 36202 | 2025-03-17 18:44:55.147136+08 |
| streaming | 0/44C8E98 | 0/44C8E98 | 0/44C8E98 | 0/44C8E98 | | | | 0 | async | 20
25-03-24 09:38:42.598134+08
15135 | 16384 | replicator | pg-node3 | 100.3.254.212 | | 59486 | 2025-03-17 18:44:57.936311+08 |
| streaming | 0/44C8E98 | 0/44C8E98 | 0/44C8E98 | 0/44C8E98 | | | | 0 | async | 20
25-03-24 09:38:43.652995+08
(2 rows)以上，完成了patroni基于DCS的接管pg状态的配置；
vip-manager配置
patroni实现了集群的管理，并把leader信息保存在DSC/Consul中，那么就可以基于这个值来实现vip的管理，也就是consul中存的patroni的leader变动那么vip就跟着漂移，因此配置文件如下：
[root@node1 ~]# more /etc/default/vip-manager.yml
ip: 100.3.254.200 # 虚拟 IP 地址
netmask: 16 # 子网掩码
interface: eth0 # 绑定的网络接口
trigger-key: /service/pg_cluster/leader
dcs-type: consul # 与 Patroni 使用的 DCS 类型一致
trigger-value: pg-node1 # node1配置pg-node1,node2配置pg-node2,跟patronictl list一致
dcs-endpoints: http://100.3.254.210:8500,http://100.3.254.211:8500,http://100.3.254.212:8500 # Consul 的访问地址
# 直接启动
systemctl restart vip-manager
systemctl status vip-manager
# 验证网络端口的绑定
[root@node2 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 0c:da:41:1d:fc:bf brd ff:ff:ff:ff:ff:ff
inet 100.3.254.211/16 brd 100.3.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet 100.3.254.200/16 scope global secondary eth0
valid_lft forever preferred_lft forever
inet6 fe80::eda:41ff:fe1d:fcbf/64 scope link
valid_lft forever preferred_lft forever以上完成了vip的配置，100.254.3.200将跟着DCS中leader的value而变动，因为vip-manager中配置文件没有写log日志地址，所以默认是/var/log/messages；
[root@node2 ~]# tail -90f /var/log/messages
Mar 24 09:41:44 node2 vip-manager: 2025/03/24 09:41:44 IP address 100.3.254.200/16 state is true, desired true
Mar 24 09:41:53 node2 patroni: 2025-03-24 09:41:53,950 INFO: no action. I am (pg-node2), the leader with the lock
Mar 24 09:41:54 node2 vip-manager: 2025/03/24 09:41:54 IP address 100.3.254.200/16 state is true, desired true
Mar 24 09:42:03 node2 patroni: 2025-03-24 09:42:03,950 INFO: no action. I am (pg-node2), the leader with the lockpgbouncer配置
以上其实已经完成了三节点PostgreSQL的高可用，如果在此基础上还想做些高并发/负载均衡的优化以应对复杂场景，就需要在每个节点再补充部署pgbouncer和haproxy；
前者进行pg的连接池化（pg是基于多进程的，每个connection消耗1个进程，进程的创建和销毁开销很大），后者在pgbouncer的基础上实现负载均衡（也就是将请求负载到每个主机的连接池上），haproxy还可以将读请求分发到从节点，写请求分发到主节点来实现读写分离（端口级别）；
pgbouncer的配置如下：
[root@node2 ~]# cat /etc/pgbouncer/pgbouncer.ini
# [databases] 部分用于定义 Pgbouncer 可以连接的数据库及其连接信息
[databases]
# 使用通配符 * 表示匹配所有数据库连接请求
# host 指定 PostgreSQL 数据库服务器的 IP 地址
# port 指定 PostgreSQL 数据库服务器监听的端口号
# dbname 指定要连接的数据库名称
# user 指定连接数据库使用的用户名
* = host=100.3.254.200 port=5432 dbname=postgres user=postgres
# [pgbouncer] 部分用于配置 Pgbouncer 本身的行为和参数
[pgbouncer]
# 忽略客户端在启动时发送的 extra_float_digits 参数，避免该参数对连接池的影响
ignore_startup_parameters = extra_float_digits
# 指定 Pgbouncer 监听的地址，0.0.0.0 表示监听所有可用的网络接口
listen_addr = 0.0.0.0
# 指定 Pgbouncer 监听的端口号，应用程序将通过该端口连接到 Pgbouncer
listen_port = 6432
# 指定 Pgbouncer 的日志文件路径，用于记录运行过程中的日志信息
logfile = /var/log/pgbouncer/pgbouncer.log
# 指定 Pgbouncer 的进程 ID 文件路径，用于管理 Pgbouncer 进程
pidfile = /var/run/pgbouncer/pgbouncer.pid
# 指定认证类型为 md5，即使用 MD5 加密的密码进行认证
auth_type = md5
# 指定存储用户认证信息的文件路径，该文件包含用户名和对应的加密密码
auth_file = /etc/pgbouncer/userlist.txt
# 指定连接池模式为 transaction，即事务级连接池模式
# 在该模式下，一个连接在一个事务结束后会被释放回连接池供其他事务使用
pool_mode = transaction
# 指定 Pgbouncer 允许的最大客户端连接数
max_client_conn = 1000
# 指定每个数据库的默认连接池大小，即每个数据库可以同时使用的连接数量
default_pool_size = 100
# 指定具有管理员权限的用户列表，这些用户可以执行 Pgbouncer 的管理命令
admin_users = pgbouncer,postgres
# 指定具有统计信息查看权限的用户列表，这些用户可以查看 Pgbouncer 的统计信息
stats_users = pgbouncer,postgresuserlist.txt存储用户名和密码：（加密与否待确认）
[root@node2 ~]# more /etc/pgbouncer/userlist.txt
"postgres" "patroni123"
"pgbouncer" "patroni123"验证pgbouncer用户和库的使用：
[root@node1 ~]# su - postgres
Last login: Mon Mar 24 09:38:21 CST 2025 on pts/0
-bash-4.2$ psql -h 127.0.0.1 -p 6432 -U pgbouncer -d pgbouncer
Password for user pgbouncer:
psql (14.5, server 1.17.0/bouncer)
Type "help" for help.
-- 查看所有可用的 show 命令
show help;
-- 查看当前配置参数
show config;
-- 查看所有已配置的数据库
show databases;
-- 查看当前连接池状态（每个数据库的连接池信息）
show pools;
-- 查看所有客户端连接
show clients;
-- 查看所有服务器连接
show servers;
-- 查看版本信息
show version;
-- 查看内存使用情况
show mem;
-- 查看总连接数和执行状态
show totals;
-- 查看当前客户端连接详情（IP、状态、空闲时间等）
show clients;
-- 查看与后端 PostgreSQL 的服务器连接状态
show servers;
-- 查看当前连接池中每个数据库的活跃连接数
show pools;
-- 查看当前连接池的模式（session/transaction/statement）
show pool_mode;
-- 包含连接数、事务数、查询数等各项统计数据
SHOW STATS;
-- 列出所有配置的用户及其相关信息
SHOW USERS;以上，在三个节点上不属于了pgbouncer就实现了连接池化，并且是3个池，每个池的配置文件中配置的服务端口都是能提供读写服务的+vip所在的主的5432端口，所以3个pgbouncer的6432服务端口都可以提供给业务侧使用，如果想让这三个池都均衡的使用起来就可以使用下面的haproxy负载实现；
同时这里的pgbouncer是监听6432转发到vip的5432上，还可以配置成是三个节点上的pgbouncer只监听当前主机的5432，结合haproxy的转发配置策略，比如haproxy监听5436转发到vip上pgbouncer服务的6432就实现了读+写请求转发，haproxy监听5437端口转发到非vip上pgbouncer服务的6432服务端口就实现了只读请求转发，这样给读写业务提供5436端口连接，给只读业务提供5437连接就可以实现读写分离控制；（三个节点均部署haproxy，对业务提供的是vip上haproxy的地址）
haproxy配置
三个节点上都要部署haproxy以保持冗余，对业务侧仅提供vip上的haproxy地址（如vip:5436），haproxy的crash与拉起机制是操作系统来保证的，确保vip漂移后每个haproxy可连接，虽然这里可能是一个出问题的点，总不能再把haproxy的健康状态注册到DCS来再绑定一个vip吧。
按照上面描述每个pgbouncer都是vip上的5432端口的池化，因此haproxy可以均匀的将请求转发到每个节点的pgbouncer上，配置如下：
[root@node1 ~]# cat /etc/haproxy/haproxy.cfg
#=====================================================================
# Document: https://www.haproxy.org/download/2.5/doc/configuration.txt
# 此注释指向 HAProxy 2.5 版本的配置文档链接，方便用户查阅详细配置说明
#=====================================================================
global
daemon # 以守护进程模式运行 HAProxy，使其在后台持续运行
user haproxy # 指定 HAProxy 运行时使用的用户
group haproxy # 指定 HAProxy 运行时使用的用户组
node haproxy # 为当前 HAProxy 节点设置一个名称，用于标识
#pidfile /var/run/haproxy.pid # 注释掉的配置项，指定 HAProxy 进程 ID 文件的路径
# chroot /var/lib/haproxy # if chrooted, change stats socket above # 注释掉的配置项，将 HAProxy 进程限制在指定的根目录下运行，若启用需修改统计信息套接字配置
# stats socket /var/run/haproxy.socket user haproxy group haproxy mode 600 level admin # 注释掉的配置项，定义统计信息套接字的路径、所属用户、用户组、权限和管理级别
# spread-checks 3 # add randomness in check interval # 注释掉的配置项，在健康检查间隔中添加随机性
# quiet # Do not display any message during startup # 注释掉的配置项，启动时不显示任何消息
maxconn 65535 # maximum per-process number of concurrent connections # 每个进程允许的最大并发连接数
#---------------------------------------------------------------------
# default settings
# 以下是 HAProxy 的默认配置部分
#---------------------------------------------------------------------
defaults
# log global # 注释掉的配置项，使用全局日志配置
mode tcp # 设置默认的工作模式为 TCP 模式，适用于处理 TCP 流量
retries 3 # max retry connect to upstream # 连接到上游服务器的最大重试次数
timeout queue 3s # maximum time to wait in the queue for a connection slot to be free # 客户端在队列中等待连接槽空闲的最大时间
timeout connect 3s # maximum time to wait for a connection attempt to a server to succeed # 连接到服务器的最大等待时间
timeout client 24h # client connection timeout # 客户端连接的超时时间
timeout server 24h # server connection timeout # 服务器连接的超时时间
timeout check 3s # health check timeout # 健康检查的超时时间
#---------------------------------------------------------------------
# default admin users
# 以下是默认的管理员用户配置部分
#---------------------------------------------------------------------
userlist STATS_USERS # 定义一个用户列表，名为 STATS_USERS
group admin users admin # 在 STATS_USERS 用户列表中定义一个名为 admin 的用户组，包含用户 admin
user stats insecure-password pigsty # 在 STATS_USERS 用户列表中定义一个名为 stats 的用户，使用明文密码 pigsty
user admin insecure-password pigsty # 在 STATS_USERS 用户列表中定义一个名为 admin 的用户，使用明文密码 pigsty
#=====================================================================
# Service Definition
# 以下是服务定义部分
#=====================================================================
listen default # 定义一个名为 default 的监听部分
bind *:5436 # 绑定到所有可用的网络接口，并监听 5436 端口
mode tcp # 设置该监听部分的工作模式为 TCP 模式
maxconn 3000 # 该监听部分允许的最大并发连接数
balance roundrobin # 设置负载均衡算法为轮询，即依次将请求分发给后端服务器
option httpchk # 启用 HTTP 健康检查
option http-keep-alive # 启用 HTTP 长连接，保持客户端和服务器之间的连接
http-check expect status 200 # 期望健康检查返回的 HTTP 状态码为 200
default-server inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100 # 后端服务器的默认配置：健康检查间隔为 3 秒，快速检查间隔为 1 秒，服务器标记为故障后的检查间隔为 5 秒，连续 3 次检查成功则认为服务器恢复正常，连续 3 次检查失败则认为服务器故障，服务器被标记为故障时关闭现有会话，服务器启动时的慢速启动时间为 30 秒，每个服务器允许的最大并发连接数为 3000，最大队列长度为 128，服务器权重为 100
server node1 100.3.254.210:6432 check port 8008 weight 100 # 定义一个名为 node1 的后端服务器，地址为 100.3.254.210:6432，对其 8008 端口进行健康检查，服务器权重为 100
server node2 100.3.254.211:6432 check port 8008 weight 100 # 定义一个名为 node2 的后端服务器，地址为 100.3.254.211:6432，对其 8008 端口进行健康检查，服务器权重为 100
server node3 100.3.254.212:6432 check port 8008 weight 100 # 定义一个名为 node3 的后端服务器，地址为 100.3.254.212:6432，对其 8008 端口进行健康检查，服务器权重为 100
#启动
[root@node1 ~]# systemctl start haproxy.service
[root@node1 ~]# systemctl status haproxy.service 验证
以上不仅完成3节点的PostgreSQL高可用集群，还进行了连接池化与负载均衡，保证了PG高可用同时，确保业务侧使用时候的精细化管理，确实是pg使用的最佳实践，也是Pigsty的部署方式；
