PGSQL Replica 从库部署
本文介绍如何为PostgreSQL集群添加只读从库副本,配置L2 VIP接入,以及流量分发。
只读从库
复制可以极大高数据库系统可靠性,是应对硬件故障的最佳手段,在生产环境中强烈建议至少使用一主一从的配置。
Pigsty原生支持设置主从复制,例如,声明典型的一主一从高可用数据库集群,可以使用:
pg-test:
hosts:
10.10.10.11: { pg_seq: 1, pg_role: primary }
10.10.10.12: { pg_seq: 2, pg_role: replica } # 在集群中定义一个新从库
vars:
pg_cluster: pg-test
pg_users: [ { name: test , password: test , pgbouncer: true , roles: [ dbrole_admin ] } ]
pg_databases: [ { name: test } ]
使用 bin/createpg pg-test
可一次性创建出该集群来。
如果集群的主库已经存在,则可以执行 集群扩容。
集群扩容
扩容现有集群分为两步:初始化新的集群实例,将流量均匀分发至新实例。
bin/createpg 10.10.10.12 # 初始化 pg-test 集群的新从库 10.10.10.12
集群扩容后,现有流量并不会自动切换至新实例上, 需要参考 集群角色调整 的操作重新调整流量:
bin/reloadha pg-test # 重新配置集群流量,让新实例接入流量
集群扩容后,当主库宕机不可用时,从库会自动接管,成为新的主库。请注意,如果您的客户端使用IP地址直连数据库与连接池,则故障切换会导致连接到原来集群主库客户端应用 无法写入。 一个简单的解决方案是使用 2层VIP,绑定集群主库,通过动态绑定的VIP而非写死的主库IP,访问数据库。
2层VIP
Pigsty允许您指定一个 2层的VIP地址,以便客户端自动适应集群高可用故障切换
- 客户端可以始终通过此 VIP 地址访问集群主库,集群自动高可用故障切换后,客户端流量将自动适配。
- 您可以通过此VIP确保HAProxy负载均衡器本身的高可用。
Pigsty提供了多种不同的接入方式,L2 VIP为可选项,且只有集群所有实例位于同一个大二层网络时可用。
pg-test:
hosts:
10.10.10.11: { pg_seq: 1, pg_role: primary }
10.10.10.12: { pg_seq: 2, pg_role: replica } # 在集群中定义一个新从库
vars:
pg_cluster: pg-test
pg_users: [ { name: test , password: test , pgbouncer: true , roles: [ dbrole_admin ] } ]
pg_databases: [ { name: test } ]
# 为集群定义一个 VIP : 10.10.10.3/8 网卡为 eth1 (按实际情况修改)
vip_mode: l2 # enable/disable vip (require members in same LAN)
vip_address: 10.10.10.3 # virtual ip address for this cluster
vip_cidrmask: 8 # cidr network mask length
vip_interface: eth1 # interface to add virtual ip
如果初始化实例/集群时,PG_SERVICE 中的VIP相关配置已经定义, 那么该数据库集群将在集群初始化完毕后自动绑定该VIP,否则您需要通过以下命令手工启用VIP:
./pgsql.yml -l pg-test -t vip # 在已有集群上加装2层VIP
启用VIP后,您可以使用VIP访问集群,也可以将一个静态域名绑定在该VIP上。
make test-ri # 初始化 pgbench
pgbench -is10 postgres://test:test@pg-test:5436/test
make test-rw # 添加一些 pgbench 主库写入流量
while true; do pgbench -nv -P1 -c4 --rate=64 -T10 postgres://test:test@pg-test:5433/test; done
故障切换
如果主库出现故障,或者我们希望将从库提升为新主库,可以执行 主动切换(Switchover)或 故障切换 (Failover),两者的区别主要在于集群当前的主库是否可用。
pg switchover pg-test # 手工执行Switchover(原主库可用)
pg failover pg-test # 手工执行Failover (原主库不可用)
请注意,自动故障切换需要第三方进行仲裁,在Pigsty中,部署于管理节点上的DCS提供了此仲裁服务。(您也可以通过配置 dcs_servers 使用外部DCS服务)
原有主库在宕机重启后,会尝试自动重新加入集群中,并自动降级为从库追随新的主库。这一过程可能会因为某些原因失败。在这种情况下,建议将其仔细检查原因,并为集群补充添加一台新的从库,恢复一主一从的集群拓扑。
请注意,一主一从的数据库本身尽管只需要2个节点,但数据库的高可用依赖 DCS 服务,如果您没有使用 外部DCS 服务,而是重用数据库节点部署DCS服务,那么您的整个环境至少需要3个节点才足以部署生产级的基础高可用集群(3坏1)
三节点标准HA集群
如果您的整套环境只有两个节点,且没有使用外部DCS进行仲裁,则无法进行安全可靠的自动故障切换,当故障发生时,您需要手工介入,人工仲裁。 任何真正有意义的高可用方案,在没有特殊硬件(如心跳线等Fencing硬件)支持下,至少需要整个环境中有三个节点。因为高可用所依赖的仲裁者(DCS)本身的高可用至少需要三个节点。
因此,如果希望部署生产级自动高可用切换的集群,您的整个环境中应当至少有3个节点
如果您的整套环境中有三个节点,则可以使用 pigsty-dcs3.yml 中的样例, 构建一个3元节点 x 3实例PG集群的基础高可用单元。在此部署下, 三个管理节点上部署有 DCS Server (Consul/Etcd),任意一个节点故障,整个集群都可以继续正常工作。
在生产环境中,您可以使用此三节点集群作为整个集群的管控核心,管理更多的数据库集群。 在已有3节点DCS的仲裁者的情况下,您可以部署大量1主1从的基本高可用PGSQL集群,这些集群可以自动进行故障切换。
all:
children:
vars:
dcs_servers: # 使用一个3节点 的高可用DCS 服务器集群,来确保元数据库本身的高可用
meta-1: 10.10.10.10 # you could use existing dcs cluster
meta-2: 10.10.10.11 # host which have their IP listed here will be init as server
meta-3: 10.10.10.12 # 3 or 5 dcs nodes are recommended for production environment
您可以接入集群中任何一个实例上的Haproxy,以获取完整的集群服务。
添加更多从库
您可以为集群添加更多从库,例如为 pg-test
再扩容一台实例 pg-test-3 @ 10.10.10.13
,来分担只读流量
当您有多个从库时,可以通过 pg_weight 调整各实例承载流量的相对权重(默认:100,范围:0-255)
pg-test:
hosts:
10.10.10.11: { pg_seq: 1, pg_role: primary }
10.10.10.12: { pg_seq: 2, pg_role: replica }
10.10.10.13: { pg_seq: 3, pg_role: replica , pg_weight: 20 }
vars:
pg_cluster: pg-test
pg_users: [ { name: test , password: test , pgbouncer: true , roles: [ dbrole_admin ] } ]
pg_databases: [ { name: test } ]
# 为集群定义一个 VIP : 10.10.10.3/8 网卡为 eth1 (按实际情况修改)
vip_mode: l2 # enable/disable vip (require members in same LAN)
vip_address: 10.10.10.3 # virtual ip address for this cluster
vip_cidrmask: 8 # cidr network mask length
vip_interface: eth1 # interface to add virtual ip
新扩容一台从库实例
bin/createpg 10.10.10.13
调整集群负载均衡器配置:
bin/reloadha pg-test # 应用集群负载均衡配置
make test-ro # 生成一些只读流量,并观察流量分布
在高频访问的只读从库上运行长时间,大批量,交互式的慢查询通常并不是一个好主意,有可能会导致资源征用,出现慢查询,或复制延迟。
针对这种场景,可以为集群配置一个专用的离线从库。
最后修改 2022-06-05: add pgsql/deploy document (34a3325)