PG数据库实现高可用方案(包括通用型方案Corosync+pacemaker协作)

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介: PG数据库实现高可用方案(包括通用型方案Corosync+pacemaker协作)

首先了解一下高可用集群


在传统Linux集群种类,主要分了三类,

一类是LB集群,这类集群主要作用是对用户的流量做负载均衡,让其后端每个server都能均衡的处理一部分请求;这类集群有一个特点就是前端调度器通常是单点,后端server有很多台,即便某一台后端server挂掉,也不影响用户的请求;

其次就是HA集群,所谓ha集群就是高可用集群,这类集群的主要作用是对集群中的单点做高可用,所谓高可用就是在发生故障时,能够及时的将故障转移,从而使故障修复时间最小;这类集群的特点是在多台节点上,各空闲节点会一直盯着工作节点,工作节点也会基于多播或广播的方式把自己的心跳信息发送给其他空闲节点,一旦工作节点的心跳信息在一定时间内空闲节点没有收到,那么此时就会触发资源抢占,先抢到资源的成为新的工作节点,而其他节点又会一直盯着新的工作节点,直到它挂掉,然后再次触发资源抢占;这类集群的特点就是一个节点工作,其他节点看着它工作,一旦工作节点挂了,立刻会有其他节点上来顶替它的工作;

最后就是HP集群,HP集群主要用于在复杂计算中场景中,把多台server的算力综合一起,对复杂计算要求比较高的环境中使用;

在生产环境中常见的LB和HA集群较多。


高可用:透明切换,故障切换,连接管理器/集群管理器


connect manager/cluster manager


pgpool-Ⅱ:连接池、复制、负载均衡功能


位于数据库服务器与客户端的中间层(中间件)


连接池:pgpool 提供连接池功能,降低建立连接带来的开销,同时增加系统的吞吐量


负载均衡:它的负载均衡适用于只读场景。

当数据库运行在复制模式或主备模式下,SELECT语句运行在集群中任何一个节点都能返回一致的结果,pgpool能将查询语句分发到集群的各个数据库中,从而提升系统的吞吐量。


高可用:当集群中的主库不可用时,pgpool 能够探测到并且激活备库,实现故障转移。


限制超过限度的连接:PostgreSQL支持限制当前最大的连接数,拒绝新连接。pgpool-Ⅱ也支持限制最大连接数,它将超过限制的连接放入队列而不是立即返回一个错误。


客户端连接到pgpool-Ⅱ上,就于连接到数据库上完全一样。pgpool-Ⅱ的复制是同步的,即如果客户端发送一个DML语句,将并发地在后端所有数据库上执行,保证所有数据库的一致性。

4.png


pgpool-Ⅱ包括对于pg数据库的健康检查功能。整个架构属于多进程架构。

2.png

pcp进程:pcp是一个管理工具,向pgpool-Ⅱ发送管理命令

pgpool-Ⅱ父进程:负责检查各个底层数据库的健康状态

pgpool-Ⅱ子进程:负责接收用户发送过来的SQL请求,然后根据规则发送到底层数据库上,实现的是负载均衡作用

worker进程:负责检查底层数据库之间的复制延迟


pgpool-Ⅱ存在多种工作模式。


1.原始模式:只有faliober功能。对于后端多个数据库进行故障切换。此时的数据库同步功能由用户负责。

2.连接池模式:实现连接池的功能和原始模式的故障切换功能。

3.内置复制模式:这种模式下pgpool负责后端数据库数据同步,pgpool节点上的写操作需等待所有后端数据库将数据写入后才向客户端返回成功,是强同步复制方式,实现负载均衡功能。

5.主备模式:中间件层使用pgpool-Ⅱ,pgpool提供高可用和连接池的功能。

配合流复制的主备模式:使用PostgreSQL流复制方式,PostgreSQL流复制负责pgpool后端数据库数据同步,对应的配置文件为$prefix/etc/pgpool.conf.sample-stream,这种模式支持负载均衡。pgpool+pg复制实现高可用解决方案

6.并行模式:实现查询的并行执行。并行模式不能与主备模式同时使用。


对于pgpool这个中间件,要考虑它坏掉之后对于客户端连接数据库的影响,可以引入多个pgpool,基于vip进行切换。

3.png

上面提到的这个方案是传统的方案,读写分离时性能会折损30%。


Patroni


基于vip切换时,是将vip主切换成vip从,域名为客户端 有缓存 切换后不能立即生效。

整体架构如下:

5.png

基于前面博客中提到的keepalived+haproxy架构,可以解决当前架构中跨网段和域名缓存的问题。又加入一层。

6.png


引入consul注册中心 每台机器上部署patroni-agent

patroni特性:


每一个patroni都会管理pg的信息拉起集群并将注册到consul中。 (起到的是集群管理作用)

patroni与pg捆绑强依赖,两个属于一台服务器,且信息配置在pg上,宕机时两个服务一起宕机。

patroni通过心跳与consul保持连接以达到掉线后故障发现,(节点间通信)

leader定时到期后重新选主,如果你已经是主始终在线下次选主优先


主从切换过程:(集群管理部分)

patroni确定它连接的库故障时,避免产生脑裂,会通过kill命令杀死pg进程。


如果杀不掉,通过linux,watch dog直接重启,干掉主(这里不理解)

然后通过查看资料,看到:这里面将主干掉,就是避免出现脑裂的情况。对于ABC三台机器,发生了网络分区,a挂了(有可能仅是网络故障),bc当前认为a挂了,会将vip抢过来,而a认为自己没有挂,会来回争抢,造成集群的不稳定性。所以当bc都投票觉得a挂的时候,会将a干掉,即使a是存活状态,避免产生脑裂。

选出回放最快的从库 通过对比lsn的坐标谁最大谁就是新的主库。


Corosync+pacemaker高可用解决方案


Corosync


实现HA心跳信息传输的功能就是Corosync。

Coreosync在传递信息的时候可以通过一个简单的配置文件来定义信息传递的方式和协议等。


pacemaker


pacemaker是一个开源的高可用资源管理器(CRM),位于HA集群架构中资源管理、资源代理(RA)这个层次,它不能提供底层心跳信息传递的功能,要想与对方节点通信需要借助底层的心跳传递服务。


corosync+pacemaker架构协作


7.png

corosync的主要作用是提供messaging Layer,这个消息传递层的主要作用是,把个主机间的各状态信息,空闲信息等等一系列信息通过消息传递层互相传递,使得托管在corosync上的服务能够根据底层各主机传递的消息来决定,该服务该运行到那台主机上,一旦运行服务的主机发生故障时,它们又能够根据消息传递层的消息,来判断该把服务迁移到那台主机上运行;这样一来托管在corosync上的服务,就实现了高可用;

简单点讲,托管在corosync之上的服务对底层主机是不可见的,这也意味着托管在corosync上的服务是能够调用和理解Messaging Layer中的消息;这样一来托管在上面的服务就必须得提供接口来调用messaging Layer对外提供的接口,然后实现服务的迁移;

而对于大多数程序来讲,它根本就没有这样的接口,这样一来我们要使用corosync实现服务高可用就变得困难;为了解决托管在corosync的服务能够调用corosync提供的接口,我们需要开发一个中间件,让这个中间件能够向下理解和调用coroysnc提供的接口,向上能够托管服务;

这个中间层就是pacemaker;它的主要作用是通过调用corosync提供的接口,来判断把集群资源该怎么分配,服务该怎么迁移和运行;同时pacemaker还提供一个管理界面,能够让管理员来管理这些集群资源;

而对于pacemaker来讲,它主要有3个层次,其中CRM(cluster resource manager)的主要作用是通过调用messaging Layer提供的接口和各节点的状态信息来决策集群资源的管理;然后通过接口把决策信息传递给LRM(local resource manager);LRM的主要作用是对本地的资源做各种管理;而对于LRM来讲,它要怎么管理本地资源呢?它通常不会自己去管理本地资源,而是通过委派RA去管理,所谓RA(resource agent)就是资源代理;它会根据LRM发送的信息来对本地资源进行管理,而这种管理通常是基于各种服务提供的起停脚本来实现的;


资源分配:设置资源倾向性(实现负载均衡功能)


什么叫资源倾向性呢?我们知道一个资源托管在corosync+pacemaker上,最终都会把资源落在某一个节点上运行,而我们怎么来限制这些资源在那个或那些各节点上运行呢?这个就需要我们配置资源对节点的倾向性了;所谓倾向性就是该资源更加倾向在那个节点运行或更加讨厌在那个节点上运行;在corosync+pacemaker集群上运行资源的方式有3中,N-1、N-M、N-N,其中N表示节点数量,M表示资源数量;N-1表示N个节点上运行1个资源;这也意味有N减1个节点是处于空闲待命状态,这对于服务器的资源利用率有点浪费;

所以对于corosync+pacemaker集群和keepalived来讲,keepalived更加轻量化;

这句话不是很理解,轻量化是什么意思?可能是更易于配置,按照,对其他的工具没有什么影响?但是与资源的关系是什么?

N-M表示N个节点上运行M个资源,通常M小于N;这意味着有N减M个节点冗余;N-N表示N个节点上运行N个资源,没有冗余节点,这意味着一旦一个资源挂掉,那么对应就会迁移至其他节点,对于其他节点只要提供的ip地址,进程,端口不冲突就不会有很大的问题,只不过相对压力要大一点;对于不同运行方式,冗余的节点数量也是不同的;而对于资源该运行到那个节点我们可以通过定义资源对节点的倾向性来决定;默认情况每个资源都能够在任意节点上运行;也就说默认情况当A资源挂掉以后,它的故障转移范围是其他任何一个集群节点,为了不让A服务运行到B节点,我们可以定义A资源对B节点的倾向性为负无穷,所谓负无穷就是只要有其他节点可运行就绝不在B节点上运行;通过定义资源对节点的倾向性,从而来限制资源在那些节点上进行转移;这种限制资源对节点的倾向性我们叫做定义资源的故障转移域;除了能够定义资源对节点的倾向性,我们还可以定义资源与资源的倾向性,其逻辑都是相似的;对于资源倾向性通常我们会用分数来表示,其取值范围是正无穷到负无穷;正无穷表示无限喜欢到某个节点或资源,只要对应节点正常存在就一定在该节点上,负无穷相反。


相关实践学习
通过ACR快速部署网站应用
本次实验任务是在云上基于ECS部署Docker环境,制作网站镜像并上传至ACR镜像仓库,通过容器镜像运行网站应用,网站运行在Docker容器中、网站业务数据存储在Mariadb数据库中、网站文件数据存储在服务器ECS云盘中,通过公网地址进行访问。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
2月前
|
中间件 关系型数据库 Java
MySQL数据库分库分表方案
MySQL数据库分库分表方案
190 0
MySQL数据库分库分表方案
|
28天前
|
关系型数据库 数据库连接 数据库
Python执行PG数据库查询语句:以Markdown格式打印查询结果
使用Python的`psycopg2`和`pandas`库与PostgreSQL交互,执行查询并以Markdown格式打印结果。首先确保安装所需库:`pip install psycopg2 pandas`。接着建立数据库连接,执行查询,将查询结果转换为DataFrame,再用`tabulate`库将DataFrame格式化为Markdown。代码示例包括连接函数、查询函数、转换和打印函数。最后限制列宽以适应输出。
|
2月前
|
存储 负载均衡 监控
关系型数据库搭建高可用存储集群
【5月更文挑战第4天】关系型数据库搭建高可用存储集群
44 4
关系型数据库搭建高可用存储集群
|
2月前
|
DataWorks Oracle 关系型数据库
DataWorks操作报错合集之尝试从Oracle数据库同步数据到TDSQL的PG版本,并遇到了与RAW字段相关的语法错误,该怎么处理
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
49 0
|
1月前
|
NoSQL 关系型数据库 MySQL
高可用数据库架构:互备(Multi-Master)技术详解
本文介绍了分布式系统中的互备(Multi-Master)机制,特别是在高可用数据库系统中的应用。互备机制超越了传统的主从复制,允许每个Master节点同时进行读写操作并互相同步数据,以提高可用性和负载均衡。文章探讨了主从复制与互备模式的区别,以及互备模式的数据同步和冲突解决策略。还以MySQL的双主复制和MongoDB的副本集为例,展示了MM模式在数据库高可用性中的实践。最后,强调了互备在未来分布式系统中的重要性。
52 7
|
9天前
|
存储 分布式数据库 数据库
深入OceanBase内部机制:分区构建高可用、高性能的分布式数据库基石
深入OceanBase内部机制:分区构建高可用、高性能的分布式数据库基石
|
1月前
|
canal 缓存 关系型数据库
高并发场景下,6种方案,保证缓存和数据库的最终一致性!
在解决缓存一致性的过程中,有多种途径可以保证缓存的最终一致性,应该根据场景来设计合适的方案,读多写少的场景下,可以选择采用“Cache-Aside结合消费数据库日志做补偿”的方案,写多的场景下,可以选择采用“Write-Through结合分布式锁”的方案,写多的极端场景下,可以选择采用“Write-Behind”的方案。
141 0
|
2月前
|
算法 Go 分布式数据库
构建高可用的分布式数据库集群:使用Go语言与Raft共识算法
随着数据量的爆炸式增长,单一数据库服务器已难以满足高可用性和可扩展性的需求。在本文中,我们将探讨如何使用Go语言结合Raft共识算法来构建一个高可用的分布式数据库集群。我们不仅会介绍Raft算法的基本原理,还会详细阐述如何利用Go语言的并发特性和网络编程能力来实现这一目标。此外,我们还将分析构建过程中可能遇到的挑战和解决方案,为读者提供一个完整的实践指南。
|
2月前
|
SQL 监控 关系型数据库
PG数据库释放闲置连接
PG数据库释放闲置连接
88 0
|
2月前
|
存储 SQL NoSQL
关系数据库与非关系数据库:选择适当的数据存储方案
关系数据库与非关系数据库:选择适当的数据存储方案