PG的高可用几种实现方案

Pgpool-II

位于 应用与pg数据库之前这层,Pgpool-II提供连接池,基于VIP切换
在这里插入图片描述
基于同步复制的话,可实现故障发现后秒切 缺点基于VIP, 性能欠佳,读写分离 性能折损30%,比较传统的方案

Patroni 现在外面用的比较火

在pg社区里找的学习材料

简单介绍

  • 基于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

双机主备切换 配置失败次数
架构图
在这里插入图片描述

  • 2
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Patroni是一种开源的工具,用于管理PostgreSQL集群的高可用性。它是一个容器化的解决方案,可以实现自动化的集群管理和故障转移。以下是使用Patroni实现PG数据库高可用的步骤: 1. 安装Patroni 可以使用pip命令安装Patroni: ``` pip install patroni ``` 2. 配置Patroni Patroni的配置文件是YAML格式的,可以根据需要进行修改。以下是一个简单的示例: ``` scope: postgres namespace: /db/ name: pg-cluster restapi: listen: 0.0.0.0:8008 connect_address: $NODE1_IP:8008 etcd: host: $ETCD_IP:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 retry_timeout: 10 maximum_lag_on_failover: 1048576 postgresql: use_pg_rewind: true parameters: max_wal_senders: 10 wal_keep_segments: 10 pg_hba: - host replication replicator 0.0.0.0/0 md5 - host all all 0.0.0.0/0 md5 synchronous_mode: off synchronous_commit: off archive_mode: off archive_command: false recovery_conf: restore_command: cp /var/lib/postgresql/backup/%f %p recovery_target_timeline: latest pgpass: /tmp/pgpass pgpassfile_mode: 600 bin_dir: /usr/lib/postgresql/9.6/bin pg_ctl: /usr/lib/postgresql/9.6/bin/pg_ctl use_slots: true create_replica_methods: - basebackup - pg_rewind ``` 在这个示例中,我们使用etcd作为DCS(分布式协调服务)来管理集群状态。我们还配置了一些PostgreSQL参数,如max_wal_senders和wal_keep_segments。这些参数都可以根据需要进行修改。 3. 启动Patroni 可以使用以下命令启动Patroni: ``` patroni postgres.yml ``` 这将启动一个PostgreSQL集群,并将其注册到etcd中。您可以使用以下命令检查集群状态: ``` curl http://$NODE1_IP:8008/patroni ``` 这将返回一个JSON格式的响应,其中包含有关集群状态的信息。 4. 测试故障转移 为了测试故障转移,您可以杀死主节点上的PostgreSQL进程。Patroni将检测到主节点已经下线,并自动将一个从节点提升为新的主节点。 您可以使用以下命令检查新主节点的状态: ``` curl http://$NODE2_IP:8008/patroni ``` 这将返回有关新主节点的信息。 总的来说,使用Patroni实现PostgreSQL集群的高可用性相对简单。它可以自动管理故障转移,并提供一些其他有用的功能,如DCS和可插拔的备份存储后端。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值