PG的高可用几种实现方案
Pgpool-II
位于 应用与pg数据库之前这层,Pgpool-II提供连接池,基于VIP切换
基于同步复制的话,可实现故障发现后秒切 缺点基于VIP, 性能欠佳,读写分离 性能折损30%,比较传统的方案
Patroni 现在外面用的比较火
简单介绍
- 基于patroni-agent与consul的注册中心发现实现高可用
- 支持PG10–12与centos7
- 整体架构如下:
基于vip和域名
vip硬伤不能跨网段 域名为客户端有缓存切换后不能立即生效
基于haproxy
可以解决跨网段及域名缓存问题 但又架出一层
故障发现
引入consul注册中心 每台机器上部署patroni-agent
patroni有以下几个特性:
- 每一个patroni都会管理pg的信息拉起集群并将注册到consul中
- patroni与pg捆绑强依赖,pg的复制信息等都配在他这了能够做到patroni死了pg也死了
- 以及发生主从切换时调用什么脚本
- patroni通过心跳与consul保持连接以达到掉线后故障发现,(节点间通信)
- leader有租约到期后重新选主,如果你已经是主始终在线下次选主优先
分析与决策-fencing
- patroni通过 确保故障库真挂防脑裂 kill pg 线程 或如果杀不掉 通过linux watch dog直接重启,将主干掉 (如果上面部了其它应用,会有影响)
- 选出回放最快的从库 通过对比lsn的坐标谁最大谁就是新的主库
主从拓扑关系修改(自动切换)–其它从要重启生效
- 新主做checkpoint操作(其它从库发现新主存盘操作没做,从库就得等而不接收读服务,造成读不可用)
- 从库起来新主起来很容易但是网络拓扑难,
- 通过DCS选主,其他从库从DCS获取新主库信息,修改自身复制调并重启生效
修改的配置都会记录在autoconfig 重启时会覆盖pg_config 达到生效
pg也有设置主响应从同步的节点数
流量切换管控
- 域名解析
dns域名解析(7层)-consul自带的, 会存在dns缓存的问题发生了切换后,客户端缓存失效才会解析到真正的地址 - keepalive+vip(2层) 能解决切换后访问地址时效性,但必须同网段,这个网段挂了就都挂了
haproxy(4层): 架出一层代理层分别转发到 主那面 或 从那面 - 原理就是他通过访问patroni的健康检查信息来获得 集群节点谁是主,谁是从,haproxy的单点问题可以通过vip来解决
场景
场景一从库挂了
patroni会先尝试拉起来 ,如果误操作关闭从库 是不影响的
如果把从库上的patroni关了 ,那么这台从被踢出集群,haproxy也不会转发了
场景一switchover主库可用的发生切换
集群健康时,我们主动的触发切换 可以设置一个指定的时间, 将主切换从
场景一failover主库不可用挂了发生切换
比如误操作给关了,他会尝试先拉起主 并且在consul的key失效之前 会打到老主流量上 如果在并且在consul的key失效之后 会打到新主流量上
场景三人工造成脑裂修复
patroni集群里 一主二从 跑的好好的 DBA把其中一个从强制设置为主 ,partroni仍然会往老的主库上写 最后会被修复掉
场景四主库闪断掉线一段时间
由于网络的抖动主库掉线一段时间 支持配置允许一个预值内能忍受,不发生切换
比如修改主库配置之后,重启主库不发生切换
如果主库掉线时长超过consul里的key失效时间,就会发生切换
附:如果允许一个预值的话,那么将来发生切换时RTO可能会增加,即RTO=预值+切换执行时长
场景五一主一从并且物理强同步
如果从库挂了 主库就会挂起 数据库集群不可写
场景六consul挂了
1.consul挂了之后 数据库集群中的的主库就不可写了
原因是: patroni连不上consul patroni会把主库降级变为从库
解释:保障前提
你的运维或者你的基础设施团队能够给你提供这样的运维环境,就比如k8s 挂了 上面的集群都挂了 你就得保证k8s的根儿的稳定性 如果要求数据库四个9 那consul就得5个9
如果真就保证不了 那这套高可用只能用做故障发现 分析决策 做不了自动切换 只能人工切换
如果运维不小心把consul关了 怎么变通处理?
retryTimout时长设置的很长, 此时consul虽然关了,但是agent端还会缓存之前的主备关系状态 这段时间内不受影响
此时 运维打开手动切换模式 ,然后慢慢处理consul的问题
关于RPO与RTO
一主多从 也可以设置同步方式响应应答数 来保证不丢数据
多种策略供业务选择
可靠性 ,可用性 或允许丢1个G的数据后,再停服务
使用注意
关于配置都要在patroni里配置,然后修改才能生效
haproxy的关键配置
listen master
bind *:5000
mode tcp
option tcplog
balance roundrobin
option httpchk OPTIONS /master
http-check expect status 200
default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
server node1 192.168.216.130:5432 maxconn 1000 check port 8008 inter 5000 rise 2 fall 2
server node2 192.168.216.132:5432 maxconn 1000 check port 8008 inter 5000 rise 2 fall 2
listen replicas
bind *:5001
mode tcp
option tcplog
balance roundrobin
option httpchk OPTIONS /replica
http-check expect status 200
default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
server node1 192.168.216.130:5432 maxconn 1000 check port 8008 inter 5000 rise 2 fall 2
server node2 192.168.216.132:5432 maxconn 1000 check port 8008 inter 5000 rise 2 fall 2
pacemaker+corosync
双机主备切换 配置失败次数
架构图