合 PG高可用集群之Patroni + etcd + HAProxy + keepalived + Prometheus + Grafana监控 部署

发布日期 2022年1月22日 · 已更新 2022年12月25日  

1    2923    14

Tags： PG高可用GrafanaPrometheuskeepalivedPatroniHAProxyetcd

👉 本文共约11541个字，系统预计阅读时间或需44分钟。

显示/隐藏全文目录

目录

• 高可用测试
• 1. 高可用测试 Keepalived
• 2. 高可用测试 HAProxy
• 3. 高可用测试 Patroni
• 4. 高可用测试 etcd
• 5. 高可用测试 PostgreSQL
• 6. 高可用测试 操作系统
• 7. 读写分离+负载均衡测试
• 8. switchover和failover切换
• switchover操作
• failover操作

高可用测试

1. 高可用测试 Keepalived

注意：可以将2个节点的state都配置为backup，将priority都配置为100来避免自动来回切换，而影响客户体验。

测试类型	测试方式	测试命令	测试结果
进程故障	1. 主端killall进程	killall keepalived	VIP从主端自动转移到备端，5000端口和5001端口连接正常
-	-	systemctl start keepalived	VIP从备端自动转移到主端，5000端口和5001端口连接正常。
-	2. 备端killall进程	systemctl stop keepalived	VIP在主端正常运行，5000端口和5001端口连接正常
-	-	systemctl start keepalived	VIP在主端正常运行，5000端口和5001端口连接正常
-	3. 主端同时kill所有进程	-	主端VIP未卸掉，备端也启动VIP，此时主备端均存在VIP（异常现象），5000端口和5001端口连接正常
-	-	systemctl start keepalived	VIP转移到主端正常运行，备端无VIP，5000端口和5001端口连接正常
-	4. 主端只kill主进程	kill -9	VIP从主端自动转移到备端，VIP只在备端启动，5000端口和5001端口连接正常
-	-	systemctl start keepalived	VIP转移到主端正常运行，备端无VIP，5000端口和5001端口连接正常
-	5. 主端只kill子进程	-	VIP从主端自动转移到备端，等待主进程自动生成子进程后，VIP从备端自动转移到主端，5000端口和5001端口连接正常
-	6. 备端kill 进程	-	IP在主端正常运行，5000端口和5001端口连接正常
网卡故障	1. 主端down网卡	ifdown eth0	VIP从主端自动转移到备端，PostgreSQL发生故障转移到其中一个备库，5000端口和5001端口连接正常，patroni和etcd均不显示故障节点
-	2. 主端up网卡	ifup eth0	VIP从备端自动转移到主端，故障节点以备库角色添加到集群，patroni和etcd节点状态显示正常，5000端口和5001端口连接正常
-	3. 备端down网卡	ifdown eth0	VIP在主端正常运行，5000端口和5001端口连接正常，patroni和etcd均不显示故障节点，故障节点上的各个进程还在运行
-	4. 备端up网卡	ifup eth0	patroni和etcd节点状态显示正常

2. 高可用测试 HAProxy

测试类型	测试方式	测试命令	测试结果
进程故障	1. 主端killall进程	killall haproxy	keepalived 未检测 haproxy 进程，自动将VIP从主端转移到备端，5000端口和5001端口连接正常
-	-	systemctl start haproxy	keepalived 检测到 haproxy 进程，自动将VIP从备端转移到主端，5000端口和5001端口连接正常
-	2. 备端killall进程	killall haproxy	VIP在主端正常运行，5000端口和5001端口连接正常
-	-	systemctl start haproxy	VIP在主端正常运行，5000端口和5001端口连接正常
-	3. 主端同时kill所有进程	-	keepalived 未检测 haproxy 进程，自动将VIP从主端转移到备端，5000端口和5001端口连接正常
-	-	systemctl start haproxy	keepalived 检测到 haproxy 进程，自动将VIP从备端转移到主端，5000端口和5001端口连接正常
-	4. 主端只kill主进程	-	keepalived 未检测 haproxy 进程，自动将VIP从主端转移到备端，5000端口和5001端口连接正常
-	-	systemctl start haproxy	keepalived 检测到 haproxy 进程，自动将VIP从备端转移到主端，5000端口和5001端口连接正常
-	5. 主端只kill子进程	-	haproxy 的所有进程都死了，keepalived 未检测 haproxy 进程，自动将VIP从主端转移到备端，5000端口和5001端口连接正常
-	-	systemctl start haproxy	keepalived 检测到 haproxy 进程，自动将VIP从备端转移到主端，5000端口和5001端口连接正常

3. 高可用测试 Patroni

以下是在Patroni开启了auto failover的情况下进行测试

[root@pgtest3 ~]# patronictl resume

1	[root@pgtest3 ~]# patronictl resume

测试类型	测试方式	测试命令	测试结果
进程故障	1. 主端killall进程	killall patroni	1. 触发故障切换到备库其中一个节点，备库另一个节点同步新主库，切换时间在30秒内 2. 原主库(pgtest1)的 PostgreSQL 被关闭 3. etcd haproxy keepalived 在原主库正常运行，VIP 运行在原主库 4. VIP + 5000端口连接切换后的新主库，VIP + 5001端口连接另一个备库
-	-	systemctl start patroni	原主库(pgtest1)变成新主库(pgtest2)的备库
-	2. 主库kill patroni 进程	kill -9	1. 触发故障切换到备库其中一个节点，备库另一个节点同步新主库，切换时间在30秒内 2. 原主库(pgtest1)的 PostgreSQL 还在运行，并且是读写模式 3. etcd haproxy keepalived 在原主库正常运行，VIP 运行在原主库 4. VIP + 5000端口连接切换后的新主库，VIP + 5001端口连接另一个备库
-	-	systemctl start patroni	原主库(pgtest1)被 pg_rewind 成新主库(pgtest2)的备库
-	3. 一个备库kill patroni 进程	-	1. 使用killall，将会同时关闭备库，使用kill，此备库的 PostgreSQL 还在以只读模式运行，且与主库正常同步数据 2. VIP + 5000端口正常连接主库，VIP+5001端口不能连接此备库，可以连接另一个备库 3. 主库与另一个备库不受影响 4. 此备库上的 etcd haproxy keepalived 正常运行
-	-	systemctl start patroni	自动恢复正常状态，与主库保持同步
-	4. 两个备库kill patroni 进程	-	1. 使用killall，将会同时关闭备库，使用kill，两个备库的 PostgreSQL 还在以只读模式运行，且与主库正常同步数据 2. VIP + 5000端口只连接主库，VIP + 5001端口连接失败 3. 主库不受影响 4. 备库上的 etcd haproxy keepalived 正常运行
-	-	systemctl start patroni	自动恢复正常状态，与主库保持同步

4. 高可用测试 etcd

测试类型	测试方式	测试命令	测试结果
进程故障	1. 主库kill etcd 进程	-	不影响主库和备库, patroni 会连接其它节点上的etcd，VIP+5000/5001端口连接正常
-	2. 一个备库停止 etcd 进程	-	不影响主库和备库, patroni 会连接其它节点上的etcd，VIP+5000/5001端口连接正常
-	3. 两个备库停止 etcd 进程	-	此时超过了etcd的最大允许故障节点数，主备库3个节点均以只读模式运行，VIP + 5000端口连接失败，VIP + 5001端口轮询连接主备库3个节点
-	-	先启动第一个备库的 etcd 进程	主库从只读模式切换成读写模式，主从数据同步恢复正常，VIP + 5000/5001端口连接正常
-	-	再启动第二个备库的 etcd 进程	自动恢复正常状态，与主库保持同步

5. 高可用测试 PostgreSQL

测试类型	测试方式	测试命令	测试结果
-	停主库PostgreSQL实例	-	主库被Patroni自动拉起，VIP + 5000/5001端口连接正常
-	停备库PostgreSQL实例	-	备库被Patroni自动拉起，VIP + 5000/5001端口连接正常

6. 高可用测试 操作系统

测试类型	测试方式	测试命令	测试结果
-	停PostgreSQL主库主机(同时是haproxy + keepalived 的主机)	reboot	1. 触发故障切换到备库其中一个节点，备库另一个节点同步新主库，切换时间在30秒内 2. VIP漂移到备库 3. VIP + 5000端口连接切换后的新主库，VIP + 5001端口连接另一个备库
-	-	启动	原主库(pgtest1)变成新主库(pgtest2)的备库，VIP从keepalived的备端自动转移到主端，5000端口和5001端口连接正常
-	停备库的主机就不测试了	-	-

7. 读写分离+负载均衡测试

通过 5000 端口提供读写服务，通过 5001 端口提供只读服务。

[root@lhrpgpatroni71 /]# patronictl list +----------------+-------------+---------+---------+----+-----------+ | Member | Host | Role | State | TL | Lag in MB | + Cluster: pg_cluster (6981731393302868828) -------+----+-----------+ | lhrpgpatroni71 | 172.72.6.71 | Leader | running | 7 | | | lhrpgpatroni72 | 172.72.6.72 | Replica | running | 7 | 0 | | lhrpgpatroni73 | 172.72.6.73 | Replica | running | 7 | 0 | +----------------+-------------+---------+---------+----+-----------+ psql -U postgres -h 172.72.6.77 -p5000 psql -U postgres -h 172.72.6.78 -p5000 psql -U postgres -h 172.72.6.77 -p5001 psql -U postgres -h 172.72.6.78 -p5001 for i in $(seq 1 10); do psql 'host=172.72.6.70 port=5000 user=postgres dbname=postgres password=lhr' -c 'select inet_server_addr(),pg_is_in_recovery()'; done | egrep '172' [root@db-rac ~]# for i in $(seq 1 10); do psql 'host=172.72.6.70 port=5000 user=postgres dbname=postgres password=lhr' -c 'select inet_server_addr(),pg_is_in_recovery()'; done | egrep '172' 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f 172.72.6.71 | f [root@db-rac ~]# for i in $(seq 1 10); do psql 'host=172.72.6.70 port=5001 user=postgres dbname=postgres password=lhr' -c 'select inet_server_addr(),pg_is_in_recovery()'; done | egrep '172' 172.72.6.72 | t 172.72.6.73 | t 172.72.6.72 | t 172.72.6.72 | t 172.72.6.73 | t 172.72.6.73 | t 172.72.6.72 | t 172.72.6.72 | t 172.72.6.73 | t 172.72.6.72 | t

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

[root@lhrpgpatroni71 /]# patronictl list +----------------+-------------+---------+---------+----+-----------+ | Member         | Host        | Role    | State   | TL | Lag in MB | + Cluster: pg_cluster (6981731393302868828) -------+----+-----------+ | lhrpgpatroni71 | 172.72.6.71 | Leader  | running |  7 |           | | lhrpgpatroni72 | 172.72.6.72 | Replica | running |  7 |         0 | | lhrpgpatroni73 | 172.72.6.73 | Replica | running |  7 |         0 | +----------------+-------------+---------+---------+----+-----------+   psql -U postgres -h 172.72.6.77 -p5000 psql -U postgres -h 172.72.6.78 -p5000   psql -U postgres -h 172.72.6.77 -p5001 psql -U postgres -h 172.72.6.78 -p5001   for i in $(seq 1 10); do psql 'host=172.72.6.70 port=5000 user=postgres dbname=postgres password=lhr' -c 'select inet_server_addr(),pg_is_in_recovery()'; done | egrep '172'   [root@db-rac ~]# for i in $(seq 1 10); do psql 'host=172.72.6.70 port=5000 user=postgres dbname=postgres password=lhr' -c 'select inet_server_addr(),pg_is_in_recovery()'; done | egrep '172' 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f 172.72.6.71      | f [root@db-rac ~]# for i in $(seq 1 10); do psql 'host=172.72.6.70 port=5001 user=postgres dbname=postgres password=lhr' -c 'select inet_server_addr(),pg_is_in_recovery()'; done | egrep '172' 172.72.6.72      | t 172.72.6.73      | t 172.72.6.72      | t 172.72.6.72      | t 172.72.6.73      | t 172.72.6.73      | t 172.72.6.72      | t 172.72.6.72      | t 172.72.6.73      | t 172.72.6.72      | t

可以看出，5000是读写，而5001是只读+负载均衡。

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信dbaup66，谢谢！

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。

相关文章

• PG常见高可用方案
• PostgreSQL 11版本基于Pacemaker+Corosync+pcs的高可用搭建
• PG 14 + Pgpool-II + Watchdog 实现高可用（自动故障转移+读写分离+负载均衡）
• PG 14 + Pgpool-II + Watchdog 实现高可用
• PG高可用之Citus分布式集群搭建及使用
• PG高可用之主从流复制+keepalived 的高可用
• PG高可用工具之repmgr安装
• PG中的逻辑复制（Logical Replication）
• 【DB宝72】pgpool-II和pgpoolAdmin的使用
• pgpool-II 3.2.5手册
• pgpool-II-3.2.5入门教程
• PostgreSQL高可用之repmgr（1主2从+1witness）+Pgpool-II实现主从切换+读写分离+负载均衡
• 【DB宝61】PostgreSQL使用Pgpool-II实现读写分离+负载均衡
• 【DB宝60】PG12高可用之1主2从流复制环境搭建及切换测试
• 【DB宝36】使用Docker分分钟搭建漂亮的prometheus+grafana监控
• PG中的file_fdw、postgres_fdw和dblink
• PG通过tds_fdw访问SQL Server数据库
• PG系数据库（PG、人大金仓KES）如何配置只允许某个用户u1只能访问某单个数据库db1，而不能访问其它库
• PG中的LOCALE介绍
• 在Windows系统中定时pg_dump逻辑导出备份PG或GreenPlum数据库（异机备份、动态生成导出命令）

打赏赞(14)分享

标签： PG高可用GrafanaPrometheuskeepalivedPatroniHAProxyetcd

小麦苗

学习或考证，均可联系麦老师，请加微信db_bao或QQ646634621

• 下一篇 PCTP练习题
• 上一篇 PG连接池工具之pgbouncer

您可能还喜欢...

• 0

  Nginx高可用搭建

  2023年1月28日

   由 小麦苗 · Published 2023年1月28日 · Last modified 2023年2月8日

  · 已更新 2023年2月8日  

  0    115    3
• 0

  PG中的include索引

  2023年10月9日

   由 小麦苗 · Published 2023年10月9日 · Last modified 2024年6月3日

  · 已更新 2024年6月3日  

  0    170    2
• 0

  MySQL主从复制之增强半同步（无损复制）、延迟和并行复制

  2022年5月25日

   由 小麦苗 · Published 2022年5月25日 · Last modified 2022年8月18日

  · 已更新 2022年8月18日  

  0    921    4