PostgreSQL WAL replay 加速(datapage preload) - 恢复加速, 备库延迟优化

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS SQL Server,基础系列 2核4GB
简介:

标签

PostgreSQL , replace , standby , recovery , preload , 预加载


背景

PostgreSQL 数据库恢复时,读取wal,如果当前wal page不是full page,则从这笔wal record对应的data file中拿到datapage,与wal record合并,覆盖对应data page。持续读取wal 实现恢复的目的。

需要注意wal是顺序读写,而data file可能是离散读写(大部分oltp业务都是如此),WAL的目的就是要将离散的DATA FILE写变成顺序的IO。

那么问题来了,恢复时,data file就变成了离散的读操作。

在主库WAL产生量非常巨大时,standby recovery(replay)将会导致与主库的延迟,通常wal write不会有大的延迟(因为WAL是顺序写),replay的延迟主要是recovery时data file的离散读导致。

如何降低离散读呢?

DBAs struggling with replication lag is nothing new. A large volume of data or write IO comes into the system and the followers struggle to keep up. pg_prefaulter was written to eliminate replication lag on followers and also improves database startup times.

If your database is under 24/7 write workload, has periodic replication lag that is unacceptable, or want to reduce the startup time of PostgreSQL, pg_prefaulter will help all three of these scenarios.

At Joyent we use PostgreSQL as the metadata tier for our object storage system, Manta. This talk chronicles how we identified our source of replication lag and why we found it necessary to write pgprefaulter. pgprefaulter is a sidecar process for PostgreSQL written in Go that pre-fetches pages from disk and loads them into the operating system's filesystem cache before PostgreSQL requests them during the startup and application of WAL records.

Additionally, this talk also discusses:

the design considerations that went into writing pg_prefaulter
the various forms of "replication lag" in PostgreSQL (WAL receive lag, WAL apply lag, and checkpoint lag)
pathologies that came from deploying pg_prefaulter
why we now consider pg_prefaulter mission critical software for our production databases
tips for deploying pg_prefaulter

优化方法

在备库接收到WAL后,解析WAL,并提前将需要用到的DATA FILE PAGE加载到OS PAGE CACHE中,在postgresql startup process replay wal时,读取需要的data page时,从os cache读取,从而降低replay时因为读取data page带来的IO等待。

patch:

http://www.postgresql-archive.org/WAL-prefetch-td6024900.html

参考

pg_prefaulter: Scaling WAL Performance (application/pdf - 2.6 MB)

http://www.postgresql-archive.org/WAL-prefetch-td6024900.html

http://www.pgcon.org/2018/schedule/events/1204.en.html

https://github.com/joyent/pg_prefaulter

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
SQL 关系型数据库 数据库
|
存储 关系型数据库 测试技术
PG14新特性--恢复和VACUUM的加速
PG14新特性--恢复和VACUUM的加速
247 0
|
弹性计算 网络协议 容灾
PostgreSQL 时间点恢复(PITR)在异步流复制主从模式下,如何避免主备切换后PITR恢复(备库、容灾节点、只读节点)走错时间线(timeline , history , partial , restore_command , recovery.conf)
标签 PostgreSQL , 恢复 , 时间点恢复 , PITR , restore_command , recovery.conf , partial , history , 任意时间点恢复 , timeline , 时间线 背景 政治正确非常重要,对于数据库来说亦如此,一个基于流复制的HA架构的集群,如果还有一堆只读节点,当HA集群发生了主备切换后,这些只读节点能否与新的主节点保持
1860 0
|
SQL Oracle 关系型数据库
【DB吐槽大会】第39期 - PG 物化视图不支持基于log的增量刷新
大家好,这里是DB吐槽大会,第39期 - PG 物化视图不支持基于log的增量刷新
|
关系型数据库 测试技术 调度
PostgreSQL 9.6 检查点柔性优化(SYNC_FILE_RANGE) - 在单机多实例下的IO Hang问题浅析与优化
背景 PostgreSQL检查点是将shared buffer中的脏页打标记,并集中将其刷到磁盘的动作(fsync)。(期间可能有刷盘的调度,降低当脏页很多时带来的IO影响) 在检查点之外,平时bgwriter进程则会使用bufferio的方式(write)将脏页写到OS的dirty page。
3581 0
|
关系型数据库 调度 数据库

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版