部署高可用PostgreSQL14集群

目录

基础依赖包安装

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 firewalld

 setenforce配置

sudo setenforce 0

hostname配置

[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 node3

consul配置

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: patroni123superuser:# 数据库超级用户的用户名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+0815135 |    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 1000link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::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 1000link/ether 0c:da:41:1d:fc:bf brd ff:ff:ff:ff:ff:ffinet 100.3.254.211/16 brd 100.3.255.255 scope global eth0valid_lft forever preferred_lft foreverinet 100.3.254.200/16 scope global secondary eth0valid_lft forever preferred_lft foreverinet6 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 lock

pgbouncer配置

以上其实已经完成了三节点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,postgres

userlist.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 版本的配置文档链接，方便用户查阅详细配置说明
#=====================================================================
globaldaemon           # 以守护进程模式运行 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_USERSgroup admin users admin  # 在 STATS_USERS 用户列表中定义一个名为 admin 的用户组，包含用户 adminuser stats  insecure-password pigsty  # 在 STATS_USERS 用户列表中定义一个名为 stats 的用户，使用明文密码 pigstyuser 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 状态码为 200default-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，服务器权重为 100server node1 100.3.254.210:6432 check port 8008 weight 100  # 定义一个名为 node1 的后端服务器，地址为 100.3.254.210:6432，对其 8008 端口进行健康检查，服务器权重为 100server node2 100.3.254.211:6432 check port 8008 weight 100  # 定义一个名为 node2 的后端服务器，地址为 100.3.254.211:6432，对其 8008 端口进行健康检查，服务器权重为 100server 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的部署方式；