使用 Aurora PostgreSQL 的新直写缓存将复制延迟降低多达 17 倍

兼容 Amazon Aurora PostgreSQL 的版本最近添加了逻辑复制直写缓存。逻辑复制直写缓存通过减少逻辑解码期间发生的 Aurora 存储 I/O 量来帮助提高性能。使用直写缓存时，逻辑解码器首先在缓存中查找数据以满足查询；如果找到数据，则直接从缓存中返回。通过减少存储 I/O 量，默认的直写缓存可在 pgbench 工作负载下将复制延迟减少多达 17 倍，而不会降低每秒事务数 (TPS)。在这篇文章中，我们将向您展示如何监控和调整直写缓存，以便您的集群充分发挥缓存的优势。

逻辑复制概述

逻辑复制是一种发布/订阅功能，可为 Aurora PostgreSQL 集群的复制提供精细控制。Aurora PostgreSQL 集群可以使用逻辑复制来执行数据的逻辑导出，以利用亚马逊云科技数据库迁移服务 (亚马逊云科技 DMS) 、A mazon Kinesis 等托管服务。在 Aurora PostgreSQL 版本 11.17、12.12、13.8 和 14.5 中，提供了一项新功能，可以提高依赖于 Aurora PostgreSQL 逻辑复制的工作负载的性能。这种性能改进是通过专为改善逻辑复制到客户端的数据的延迟而设计的直写缓存实现的。缓存的目标是减少延迟并降低 PostgreSQL 逻辑复制的 CPU 开销。

PostgreSQL 中的逻辑复制通过将预写日志 (WAL) 解码为可供订阅者使用的记录流来工作。配置逻辑复制时，需要指定每个 复制槽的复制槽 名称和解码插件类型。解码插件类型决定了向逻辑复制订阅者传输记录时使用的编码。如果没有缓存，则必须从 Aurora 存储中提取数据更改，即使这些更改是最近才写入的，这会消耗 I/O 并加剧写入器实例上的资源争用。

如果您的连续同步工作负载（例如 CDC 流或异步读取器）与 Aurora PostgreSQL 逻辑复制配对，则使用直写缓存可以从中受益。在连续同步工作负载中，复制使用者不断地从数据库中流出，需要低延迟地访问最近提交的数据。 这种新近偏差允许 Aurora 从直写缓存中提取数据而不会出现明显的复制延迟；可供缓存使用的内存量由 rds.logical_wal_cache 参数控制。

在以下部分中，我们将向您展示如何监控和调整直写缓存以提高逻辑复制性能。

提高了性能

以下示例显示了直写缓存可以为不同类型的工作负载和缓存配置提供的性能改进类型。为了保持一致性和准确性，使用自定义编写的工具收集了数据，以直接测量复制延迟。

减少了复制延迟

如果复制流的生成速度过快以至于无法跟上实例，则副本会落后；这就是复制延迟。与上一版本的 Aurora PostgreSQL 相比，默认的直写缓存将复制延迟提高了 44%。将直写缓存大小增加到 2 GB 进一步改善了复制延迟，达到 59%。

在下图中，最左边的栏显示了未使用直写缓存的集群中的复制延迟。中间的栏表示使用默认缓存大小 (16 MB) 的集群中延迟的改进；最右边的栏表示同一集群使用自定义调整的缓存大小 (2 GB) 时看到的改进。

缩短了交易处理时间

下图显示了处理混合工作负载（由大型和小型事务组成的工作负载）时的性能改进。在具有默认缓存设置 (16 MB) 的实例中，每秒复制的行数（以复制使用者为单位测量）提高了 161%；当缓存增加到 2 GB 时，复制吞吐量提高了多达 185%。

缩短了交易追赶时间

在新事务停止且复制时段需要追赶的情况下，复制追赶时间会缩短。关闭缓存后，剩余的写入事务需要超过 695 秒（11 分半钟）才能复制。当缓存开启并设置为默认设置时，同一组剩余的写入事务需要 43 秒才赶上（提高了 93.7%）。缓存大小越大，改善幅度更大，写入需要 14 秒（提高 97%），如下图所示。

减少了读取 I/O

选择缓存大小时，应记住，通常处理的事务组合可能会影响读取 I/O 的减少程度。在下图中，蓝条表示主要由大型数据事务组成的工作负载。对于大型数据事务，增加直写缓存大小 (2 GB) 可以显著减少读取 I/O。

图表中的橙色条形表示组合工作负载（由大型数据和 pgbench 事务混合组成）。在组合工作负载下，与禁用缓存的实例相比，默认配置的读取 I/O 提高了 47%。如果将缓存大小增加到 2GB，则读取 I/O 会进一步减少，运行速度加快 71%。

如果您在读取 I/O 时遇到问题，或者如果您的缓存统计数据显示失误次数很多，则可能需要评估工作负载并相应地增加缓存大小。

直写缓存管理

在本节中，我们将讨论管理直写缓存行为和监控。

行为

当写入事务在 Aurora PostgreSQL 集群中提交时，相应的 WAL 记录将同时写入 Aurora 存储空间和 Aurora PostgreSQL WAL 缓存。如果缓存已满（大小由 rds.logical_wal_cach e 参数定义），则将删除缓存中最旧的记录，并将新记录附加到缓存的末尾（通常称为先入、先出或 FIFO 队列）。

如果写入工作负载生成新记录的速度快于从复制槽消耗这些记录的速度，则复制过程将开始从 Aurora 存储中读取 WAL 记录，直到这些记录赶上逻辑复制直写缓存中可用的数据。

在监控和优化缓存性能时，需要记住以下几点：

如果只有一个（或多个）复制槽落后，则可能是由于从复制槽读取的工具的可用性或性能出现问题。
如果所有复制槽都持续落后，则缓存可能太小。考虑增加 rds.log ical_wal_cache 的值。
如果所有复制槽在短时间内都落后然后赶上，则可能是由于需要扩展处理的大量写入事务（大量行和大量保存点）所致。考虑监控复制延迟（如下所述），调整事务以对较小的行进行操作，或者禁用该事务的 SAVEPOINT 使用率。

监控

对于使用逻辑复制的集群，Aurora PostgreSQL 版本 11.17、12.12、13.8 和 14.5 中会自动启用直写缓存。要关闭直写缓存，请修改您的参数组，将 rds.log ical_w al_cache 参数设置为 0。

Aurora PostgreSQL 有三个函数可用于评估和管理直写缓存。你可以使用 a urora_stat_logical_wal_cache () 函数来返回有关每个插槽的缓存使用情况的信息。该函数评估直写缓存的使用情况，以确定其是否具有性能优势。

该命令返回包含以下内容 的 SET OF 记录：

名称 -复制槽名称。
active_pid — wals ender 进程。
cache_hit — 自上次重置以来的 WAL 缓存命中总数。
cache_miss — 自上次重置以来失去 WAL 缓存的总次数。
blks_read — WAL 缓存读取 请求的总数。
hit_rate — WAL 缓存命中率 （ cache_hit/blks_read ）。
last_reset_timestamp — Aurora 最后一次重置计数器的时间。

以下结果集显示了两个复制槽，其中一个处于活动状态。它显示了对直写缓存的良好利用，缓存缓冲区的 命中率为 100%：

postgres=# SELECT * FROM aurora_stat_logical_wal_cache();
    name    | active_pid | cache_hit | cache_miss | blks_read | hit_rate |     last_reset_timestamp
------------+------------+-----------+------------+-----------+----------+-------------------------------
 test_slot1 |      79183 |        24 |          0 |        24 | 100.00%  | 2022-08-05 17:39:56.830635+00
 test_slot2 |            |         1 |          0 |         1 | 100.00%  | 2022-08-05 17:34:04.036795+00
(2 rows)

如果您的缓存大小不足以处理缓存使用量，请编辑参数文件以增加 wal_buffer 的大小。

还有两个函数可以用来帮助管理逻辑复制直写缓存：

使用 a urora_stat_reset_wal_cache () 函数重置 aurora_stat_logical_wal_cache () 函数的计数器。 此函数仅适用于复制场景的 writer 实例。有关更多详细信息，请参阅 a urora_stat_reset_wal_cache ()。
使用 get_oldest_wal_cache_ptr () 函数返回逻辑 WAL 缓存中最旧的页面。

摘要

在这篇文章中，我们讨论了亚马逊 Aurora PostgreSQL 的逻辑复制直写缓存。逻辑复制可能会在数据库上造成不必要的复制延迟；如果工作负载允许，逻辑复制直写缓存可以帮助减少这种延迟。即使您的配置可以充分处理复制而不会导致速度变慢，您也可以使用直写缓存来提高集群的读取性能。

要开始使用，请创建或升级到运行 Aurora PostgreSQL 版本 11.17、12.12、13.8 和 14.5 的实例。

作者简介

苏珊·道格拉斯 担任亚马逊 Aurora 开发者倡导者已有近两年了。在加入亚马逊云科技之前，她花了20多年的时间撰写有关PostgreSQL和Linux的文章，并为PostgreSQL用户提供咨询。她与丈夫、马、狗、猫以及任何其他需要家园的动物在弗吉尼亚中部共享一个农场。

斯科特·米德 是亚马逊云科技的数据库工程师。