前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >PostgreSQL 逻辑复制大事务处理的演进

PostgreSQL 逻辑复制大事务处理的演进

原创
作者头像
用户10663322
发布2023-07-31 09:49:31
3370
发布2023-07-31 09:49:31
举报
文章被收录于专栏:PostgreSQL 记录

1前言

接上篇《进击的逻辑复制》未完话题——大事务。众所周知,逻辑复制处理大事务一直比较头疼,不仅会导致性能下降,还会导致延迟。从 13 版本以来,每个大版本在对大事务的处理方面都有显著的提升。闲话少叙,让我们看看每个版本的演进。

2演进

首先是 12 的版本,在之前的文章我也提及过

在 13 以前,数据库只会为内存中的每个事务至多保留 4096 个更改 (max_changes_in_memory)。如果有一个非常冗长的大事务,其余的更改会作为溢出文件溢出到磁盘,也就是我们看到的那一些 spill 文件。

图片
图片

当发布端的事务提交,会从磁盘上将 spill 文件读出来,解析后再发送给订阅端,不难想象,这会涉及到一定的 IO。不过这块我倒是没有看到类似的等待事件,要是有类似的等待事件的话,也可以作为分析逻辑复制的一个手段。并且此处还提及了 12 版本不能很好控制 walsender 的内存使用,因此假如各位发现内存使用率很高的话,这个也是一个排查点。

图片
图片

在 13 版本以后,引入了一个新的 GUC 参数:logical_decoding_work_mem

Specifies the maximum amount of memory to be used by logical decoding, before some of the decoded changes are written to local disk. This limits the amount of memory used by logical streaming replication connections. It defaults to 64 megabytes (64MB). Since each replication connection only uses a single buffer of this size, and an installation normally doesn't have many such connections concurrently (as limited by max_wal_senders), it's safe to set this value significantly higher than work_mem, reducing the amount of decoded changes written to disk. 指定在将已解码的更改写入本地磁盘之前,逻辑解码使用的最大内存量。这限制了逻辑流复制连接使用的内存量。默认为 64 MB。由于每个复制连接只使用一个这样大小的缓冲区,并且一个实例通常不会同时有多个这样的连接(受 max_wal_senders 的限制) ,因此将这个值设置为比 work_mem 大得多的值是安全的,从而减少了写入磁盘的解码更改的数量。

针对每一个连接的限制,并且只有消耗最多内存的最大事务才会成为溢出到磁盘的受害者。没错,选择受害者,溢出到磁盘这个操作变得更加聪明,会选择消耗内存最大的那个事务,我们可以查询 pg_stat_replication_slots 的 spill_txns 相关字段。

但是 13 只是解决了内存使用相关的问题,并没有解决延迟方面的问题,因为所有累积的变更仅在事务提交的时候才一股脑发送给订阅端

large transactions may trigger the network congestion

然后在 14 正式引入了"流式"传输,即未提交的事务也会流式传输到订阅端

If the memory limit has been exceeded, spilled changes to BufFile or send to subsriber

图片
图片

同理,可以根据 pg_replication_slots 的 stream 相关字段分析。

而在 15 版本里,主要是对逻辑复制功能方面进行了增强,比如 row filter

另外还有一个很方便的特性,便是 skip lsn,直接在订阅端指定要跳过的位点,这就要方便多了。

但是 13、14、15 三个大版本还是没有解决延迟的问题,只有在事务提交的时候,订阅端才可以进行回放,依旧会导致延迟。天空中最乌黑的那朵乌云依旧飘着,所以在 16 的版本里,又引入了并行回放——顾名思义,多个进程同时回放(要是 startup 也能多进程就好了)

大幅提升回放速度,无需等待发布端的 COMMIT

图片
图片

并行回放同样依赖于 DSM

不过目前并行回放依旧还有很多工作要做,比如死锁的处理,让我们拭目以待,希望这个功能不要跳票了。

3小结

可以看到,社区一直在不断优化着逻辑复制的功能,相信在今年发布的 16 中,逻辑复制的能力会有一个质的飞跃。另外分享一个逻辑复制演进合订本 👇🏻 请叫我雷锋

图片
图片

4参考

编号

说明

1

2

CREATE PUBLICATION — 定义一个新的发布

3

CREATE SUBSCRIPTION — 定义一个新的订阅

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1前言
  • 2演进
  • 3小结
  • 4参考
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档