PostgreSQL 流复制搭建主从环境,同步和异步的解释,压力测试,主从角色切换|学习笔记

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介: 快速学习PostgreSQL 流复制搭建主从环境,同步和异步的解释,压力测试,主从角色切换

开发者学堂课程【PostgreSQL快速入门PostgreSQL 流复制搭建主从环境,同步和异步的解释,压力测试,主从角色切换 】学习笔记与课程紧密联系,让用户快速学习知识

课程地址https://developer.aliyun.com/learning/course/16/detail/94


PostgreSQL 流复制搭建主从环境,同步和异步的解释,压力测试,主从角色切换

 

内容介绍

一、 8 PostgreSQL 流复制协议搭建主从环境

二、 同步和异步的解释

三、 流复制 hot _ standby 演示

 

本节课讲解 Postgre 数据库的流复制。上节课讲解了数据库物理备份时用到了一个工具,此工具是通过数据库的流复制协议来备份数据库的物理文件,以此达到数据库备份物理文件的目的。

 

一、8 PostgreSQL 流复制协议搭建主从环境

首先,在 PostgreSQL 文档当中, 有一专门讲解协议的是Frontend / Backend  Protocol ,流复制协议存在一些要求,比如备份 START_REPLICATION ,

image.png

通过流复制协议向数据库发送一个指令,就会将数据文件拷贝出来,通过流复制的连接将其传输到流出段的一个节点; BASE BACKUP 工具用来做基础备份。

数据库流复制

9.0开始支持1+ n 的异步流复制,异步流复制指的是事务在主节点提交时是异步的,1+ n 是指1个主节点, n 个流复制的内容。

9.1开始支持1+1+ n 的同步和异步流复制,异步是指在主节点提交事务时,异步的节点接受到的地方与其没有关系,而同步是有关系的,比如说此事务是同步事务,事务所产生的 xlog 要已经在同步节点中复制完成,这样说明事务允许提交成功,此事务在提交时会处于等待的状态,直到等到同步 Standby 节点收到这笔 xlog 的信息之后,反馈到主节点,主节点返回给程序,说明事务已经提交成功。1+1+ n 指一个主节点,一个同步 Standby 节点, n 指 n 个异步节点, 当此主节点同步的 Standby 节点挂掉之后, n 里就会选举出一个,它就变成了同步节点,相当于最终是1+1+ n 的状态,所有的节点还是通过一个主节点复制 xlog 。

9.2开始支持级联流复制,级联复制指可以一个主节点,后面还可以挂 Standby 节点,9.1和9.0相当于所有的 Standby 节点都是通过单一主节点去同步 xlog 数据。9.2的级联复制指比如 A 是主节点, B 是 Standby 节点,C 也是 Standby 节点,但是B是直接连 A 的主节点, C 是通过 B 取数据,也就是说 B 既从 A 里接收 xlog ,也向 C 发送 xlog 。

9.3开始支持跨平台的流复制协议(目前可用于接收 xlog ),不同的平台都是可以使用此协议来拷贝数据。

9.3开始流复制协议增加了时间线文件传输的协议,支持自动切换时间线。

 

二、同步和异步的解释

image.png

如图是异步流复制的原理,虚线的左上是 Standby ,虚线的右下是 Primary 。

Standby 中存在一个 wal  receiver 进程, Standby 是一个一直处于恢复状态的数据库, Primary 是一个运行的数据库,是生产数据库,要进行恢复或运行是通过 pg _ controdate 这条命令决定的,指定的一个 DATA 目录。

比如此时是 in production 状态,表示一个生产库,此台是 Standby ,模式为 in  archive  recovery ,表示一个 Standby 数据库,或是正在恢复的状态,当前状态为恢复 0 的,是一个流复制,此时有一个 receiver 的进程一直在接收。

有一个主节点是 sender 键,一直向172.16.3.39发送 xlog 信息,只要有 xlog 产生,就会持续不断地发送给172.16.3.39,当其接收后,会进行 recover 。如果没有流复制的连接,数据恢复会到 archlog 里,是前面所讲解的配置 restore _ command , 这是第一个是在归档里,若归档里取不到数据时,就会到本地 xlog 中( pg _ xlog ),第一步是在归档里取,通过归档命令 / ssd4 / pg 93/arch /20131299/% f  % p 取需要的 xlog ,若是取完或是取不到,就在 pg _ xlog 中取,如果此处还不存在更新的数据,查找 restore _ conninfo 文件中是否配备有 primary _ conninfo = ”命令,如配备则会主动生成一个 wal  receiver 进程,向 Primary 节点发起一个请求,在此处实时数据,要进行流复制协议, wal  receiver 与 wal  sender 两者需要进行一个沟通, postmaster 是一个监听进程,向它发起一个请求,会 fork 一个 wal  sender 进程,此进程( replica 172.16.3.39<56652>)就会不断向 wal  receiver 进程中发送 xlog 信息,是一个数据流的过程。

在主节点这里,应用程序做了一些操作后,会产生一些 WAL  buffer ,专门有一个 wal  writer 将 buffer 写进 XLOG 中, sender 进程 从 XLOG 文件中读而非 WAL  buffer 中,因为只有写在文件中的数据才确保安全,切记 sender 进程是从 xlog 文件中读,读完发送到 Standby 节点。 startup  process 取到 xlog 后,会一直做 recover,比如对数据做了变更,接收到 xlog 后,会将其恢复到对应文件中。

对应参数:

Primary

max _ wal _senders 做流复制时,主节点需要配备,一定要配备的有 wal _ level 、 hot  standby ,这样才能建立起 hot _ standby 节点,其次要配备的是归档模式,当 standby 节点因为网络中断等原因导致长时间没有与主节点发生交互时, xlog 文件会轮巡,不会保留。存在一个 keep _ segment,是指最多保留256个文件,当达到256个文件之后,旧文件可能会被覆盖掉。

image.png

如果没有归档的情况,只能凭借 in  legfile  segments ,16 MB each ;0  disables 里的 xlog 文件取,当文件被覆盖掉,则永远追不到主节点,会一直处于等待状态,

image.png

所需要的 xlog 在主节点中已找不到,只能在归档中取,如果配备归档,则直接在归档中取。

image.png

配置归档命令, bin / date 命令是一个伪命令,没有任何用处,真正的归档是将 xlog 文件拷贝到一个地方。

还要配备的是 wal _senders ,表示允许多少个流复制协议连接,如配置 hot _ standby ,至少配置成1,自然允许一个连接,32表示同时有32个流复制节点。

image.png

wal _ keep _ segment _256已经讲解过,因为文件在 pg _ xlog 目录中是轮巡的,所以需配置稍微大的数量,不能超出目录的大小,会导致主节点目录删除。

Master 节点也需要配置,比如做同步流复制时,需要指定同步 standby 节点名称,如名称为 all ,则全部都可以放到 standby 节点中;如 standby 节点有三个,但其中两个是在另外的 IDC ,所以同步流复制点放在本地 IDC 中,此处可以配备 application _ name ,如其被指定为 A ,就配备 A ,另外两个 IDC 的 standby 节点称为 B 和 C ,则 B 和 C 不用配备。

hot _ standby 节点需要打开才能做线上查询,若不打开则一直处于恢复状态,不允许查询。

image.png

max _ standby _archive _delay , max _ standby _ streaming  _delay 时间调整的长,在查询时,如正在查询 A 表,主节点可能已经将此表删除, standby 节点已经接收到,如做申请,则 A 表会被删除,正在查询的 A 表与申请就发生冲突,冲突的时长就是等待的时长,最多等待300秒,如超过300秒冲突仍然存在,就将正在查询的 A 表 sql 语句删除掉,这就是解决冲突的一个时长,允许有300秒解决冲突,如果仍然不断开,就将其删除,因为还要进行恢复,否则会与主节点延迟300秒。

wal _ receiver _ status _ interval ,每个一秒钟向主节点发送统计状态信息,已经接收到哪里或申请到哪里,此一秒钟是指在没有接收到任何数据情况下时也会发送,当接收到一笔数据时,也会向其发送,也就是说这是一个最长的时间,最短的时间与接收到的频率有关系,比如每0.1毫秒发送数据,间隔会变成0.1毫秒,因为每接收到一笔数据后都会反馈给主节点。 hot _ standby _ feedback _ on 是指已经发送冲突后,将冲突反馈给主节点,打开就会反馈,不打开则不会反馈。

image.png

同步流复制原理,与异步流复制的进程是完全相同的,

image.png

但在主节点处多一个队列,队列记录了从 standby 节点反馈到的东西,如接收到何处、申请到何处、 xlog 的虚拟地址、恢复到何处;队列中存储了事务状态信息,比如某事务的事务号为1000, 接收反馈给主节点, xlog 已经接收到1001,则表示1000的事务可以提交。

在主节点里,有一个队列记录了事务,事务在排队等待同步流复制是否接收到了部分事务信息,如接收到,则在队列中的事务信息只要小于事务号的信息都可以反馈给事务应用程序,也将被提交。

对应参数:

Primary

同步流复制需要多配备的是 synchronous _ standby _ names 。

 

三、流复制 hot _ standby 演示

首先,此节点是主节点,先有主节点后有备节点,端口是5432,监听的是0.0.0.0。第一步进行规划,由于没有表空间所以没有其他的目录。

image.png

如何建立备节点?

首先安装一个软件,主节点编译的参数是pg _ config —— configu,在讲解数据库安装时涉及到,配置要求与图中完全相同,在编译时一定与主节点一致;如主节点是使用 gmake  word 安装,那么也须使用 gmake  word ,能确保在节点中创建的文件在 iso 文件中已经创建完成。

更为方便的是直接将图中安装的目录进行打包,拷贝到 standby 节点中,此处是进行直接编译,与其完全相同。

编译完成后,其次是配置主库, postgresql . conf

, wal _ level 配置成hot _ standby ,还需要配置的是 archive _ command ,如下图前两个是可选的,在生产环境中将它打开。

image.png

max _ wal _ senders 配置成32, wal _ keep _ segnents 确保有256个文件存在,演示配置的为同步流复制节点,将其配置成 * ,所有节点都成为候选同步流复制节点,将 hot _ standby 打开,如图是 standby 配置,在切换时两个都将打开,互不影响。

image.png

接下里需要新建一个角色,角色用于流复制,此处使用了 replica 角色,允许从3.33、3.39连接,replication 协议通过用户连接,将角色的密码换成 drop  role ,create  role  replica允许其登录 ,如下图所示是其的角色,密码叫做 replica 。

image.png

配置密码文件,将密码改成 replica ,同时将密码文件改成400,在主节点处也可以对密码进行修改,优点是做角色切换时两个密码都存在, ip 地址来源于172.16.3.38(主节点的 ip 地址),此 ip 地址可以做漂移。

下一步骤使用 pg _ basebackup 创建备库基础备份,由于建立 standby 节点,所以使用 plain 模式,将其备份到 $ PGDATE 中,确保结构一致,下图是备份的结果。

image.png

将 recovery 文件重新命名为 conf ,此文件已经写完成,未写完成可进行拷贝,说明这是一个 standby 节点,还可以继续进行恢复。需要将时间线配置成 latest ,无论是否做过角色切换,都将跟从;还需要配置 primary _ conninfo ,主节点的 ip 为172.16.3.38,端口为5432,用户名为 replica ,由此便可做恢复,相当于备节点已经配置完成。

如果将下图数据库停止,要运行事务就不会被允许,

image.png

synchronous _ commit 关闭,则不需要同步提交,这笔事务与同步流复制没有关系,当前是同步流复制节点,接收到这笔信息之后才会被打开,事务才算结束,同步流复制的数据已经被复制过;对于重要事务,可以将 synchronous _ commit 打开。

同步流复制的状态, ip 为172.16.3.39, sync _ priority 为1,当前只有一个流复制节点,所以只能看到一条记录;如有多个流复制节点,则只有一个这一个为流复制节点,其余的节点都为异步流复制节点。如果此处不打开同步流复制,将其停止或改掉再进行重新加载和查看,查看的结果为异步流复制节点,也就是说,将数据库关闭后向里边写数据也没有影响,也查看不到 replication 的状态;将其再次打开查看状态,其状态立马呈现。

状态信息,一个函数是 xlog 已经发送到何处,另一个函数是用来查看当前数据库,例如当前插入到何处,流复制节点也已经复制到此处,表示流复制节点和主节点是完全同步的, xlog 数据完全接收到;write表示写入 buffer, flush 表示将 wal 中的 buffer 已经写入日志文件中, replay 表示这部分数据已经恢复。

下一步使用 pgbench 进行压力测试,查看流复制统计信息表 pg _ stat _ replication

使用优化的测试模型,模型中包含用户表、用户会话表,用户跟踪记录、用户退出记录,向里边插入两百万条测试数据,会话表中也插入两百万条测试数据,随后创建两个主键;此模型是模拟用户登陆,登陆时根据用户 ID 查询用户信息,同时插入登陆记录到 user _ login _ rec 日志表;如是退出,则缺少了查询用户信息,而是插入退出记录到 user _ logout _ rec 日志表,再更新 user _ session 表最后一次退出时间和在线时长字段,通过调用函数达到压力测试,函数就是指定范围调研用户登陆,上方是两百万条数据,下方是 pgbench- M  prepared - n - r - f ,/ test .sql - h 127.0.0.1 - p 5432 - U postgre  postgres ,指定16个连接,压30秒,查询状态时,主节点一直在插入,备节点在接收,接收和插入有一点差别但是影响甚小,如是同步节点则没有任何差别,30秒时间结束,完全达到同步,延迟时间非常短,测试出的压力结果为30000 tps ,包含一个选择、插入和更新,再有异步节点的情况下,事务会达到此数据;

改成同步流复制, 使用 remote _ write 后,打开后进行重新加载进行压力测试,如图是反馈的数据,会与主节点当前的插入有一定的延迟,反馈的速度没有插入的速度快,但是事务会存在一个等待的状态。

image.png

性能会下降很多是因为开启了了同步 remote _ write,如将其关闭,测试结果还是与之前相同,原因是相当于在主节点发生了完全的改变。即使是异步流复制节点,压力测试结果还是与之相同,原因是瓶颈不是在同步流复制,结果差别不大,只是千的基础;只有将 synchronous _ commit 关闭,性能提升才会非常明显。

角色切换测试,33是主库,39是备库,将主节点数据库关闭,将同步流复制节点改为异步流复制节点,在其他案例中不需要,关闭之后将 ip 删除,激活数据库,

image.png

时间线已经切换,将38的 ip 漂移,再将原来主节点 recovery 文件改成 conf 之前被称为 done ,表示已经恢复结束,激活完成,成为可读可写的数据库,现在处于一种生产运行模式中,原来的主节点变为一个备节点,从39 处接收数据,处于 recovery 模式。

image.png

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
7月前
|
存储 NoSQL 关系型数据库
PostgreSQL列存扩展hydra简单测试
Hydra是一款PostgreSQL的扩展,为PostgreSQL增加了列存引擎,使得PostgreSQL的olap性能大幅提升,本文介绍Hydra基本的使用方法。
857 0
|
3天前
|
测试技术 持续交付
自动化测试在软件开发中的关键角色
【5月更文挑战第11天】自动化测试在软件开发中扮演关键角色,提高测试效率、确保质量、降低成本。它通过脚本或工具实现测试自动化,支持持续集成和复杂场景测试。选择合适工具、编写高质量用例及持续优化流程是实施关键。在快速发展的软件行业中,自动化测试已成为不可或缺的组成部分。
|
3天前
|
敏捷开发 监控 jenkins
探索自动化测试在持续集成中的关键角色
【4月更文挑战第29天】 随着敏捷开发和持续集成(CI)实践的不断演进,自动化测试已成为确保软件质量和加快交付速度的核心要素。本文深入探讨了自动化测试在持续集成流程中的作用,分析了其提升效率、降低风险及促进团队协作的多重价值,并提出了有效整合自动化测试与CI的策略。通过案例分析,我们进一步验证了自动化测试在现代软件开发生态中不可替代的地位,同时指出了实施过程中可能遇到的挑战以及相应的解决方案。
|
3天前
|
敏捷开发 监控 数据管理
探索自动化测试在持续集成环境中的关键角色
【2月更文挑战第24天】 在当今软件开发的快节奏环境中,自动化测试不再是一个选择,而是确保产品质量和加速市场交付的必要条件。本文将深入探讨自动化测试在持续集成(CI)环境中的重要性,分析其如何提高测试效率、降低错误率,并最终促进开发流程的持续改进。我们将通过具体的案例研究和最佳实践,揭示自动化测试策略的关键要素,以及如何在CI流程中有效集成自动化测试。
|
3天前
|
SQL 关系型数据库 OLAP
PostgreSQL从小白到高手教程 - 第46讲:poc-tpch测试
PostgreSQL从小白到高手教程 - 第46讲:poc-tpch测试
95 3
|
3天前
|
存储 关系型数据库 分布式数据库
PolarDB-X最佳实践系列(五):使用通义千问和存储过程快速生成测试数据
我们在测试数据库性能的过程中,通常需要生成一批测试数据。 以前,一般要写一段程序或者脚本来完成这项工作,但现在是2024年啦!时代变了!
PolarDB-X最佳实践系列(五):使用通义千问和存储过程快速生成测试数据
|
3天前
|
敏捷开发 测试技术 持续交付
探索自动化测试在敏捷开发中的角色与挑战
【2月更文挑战第16天】 在快速迭代的软件开发领域,敏捷方法论已成为众多团队的首选。随之而来的是对自动化测试需求的显著增长。本文旨在探讨自动化测试在敏捷开发环境中扮演的关键角色,以及实施过程中可能遇到的挑战。通过分析敏捷框架下自动化测试的优势和面临的实际问题,我们提出一系列策略来优化测试流程,并确保软件产品质量与发布速度的平衡。
15 0
|
3天前
|
关系型数据库 OLAP OLTP
PostgreSQL从小白到高手教程 - 第45讲:poc-tpcc测试
CUUG PostgreSQL技术大讲堂系列公开课第45讲-POC-TPCC测试的内容,往期视频及文档,请联系CUUG。
58 1
|
3天前
|
Java 测试技术 编译器
JMM测试利器-JCStress学习笔记
JMM测试利器-JCStress学习笔记
|
3天前
|
SQL 关系型数据库 PostgreSQL
PostgreSQL【部署 01】离线安装PostgreSQL+PostGIS踩坑及问题解决经验分享(含安装文件PostgreSQL+PostGIS及多个依赖+测试SQL)
PostgreSQL【部署 01】离线安装PostgreSQL+PostGIS踩坑及问题解决经验分享(含安装文件PostgreSQL+PostGIS及多个依赖+测试SQL)
156 0

热门文章

最新文章