PostgreSQL 端点故障排除 - AWS 数据库迁移服务
源上长时间运行的事务源端工作负载过高高网络吞吐量Aurora PostgreSQL 中的溢出文件

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

PostgreSQL 端点故障排除

本节包含特定于 PostgreSQL 的复制场景。

源上长时间运行的事务

当源数据库中有长时间运行的事务（例如单个事务中有几千次插入）时，在事务完成之前，DMS CDC 事件和事务计数器不会增加。这种延迟可能会导致延迟问题，您可以使用 CDCLatencyTarget 指标来衡量。

要查看长期运行的事务，请执行以下操作之一：

  • 使用 pg_replication_slots 视图。如果 restart_lsn 值未更新，PostgreSQL 很可能因为长时间运行的活动事务而无法发布预写日志（WAL）。有关 pg_replication_slots 视图的信息，请参阅 PostgreSQL 15.4 文档中的 pg_replication_slots。

  • 使用以下查询返回数据库中所有活动查询的列表以及相关信息：

    SELECT pid, age(clock_timestamp(), query_start), usename, query 
FROM pg_stat_activity WHERE query != '<IDLE>' 
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;

    在查询结果中，age 字段显示每个查询的活动时长，您可以使用该时长来确定长时间运行的查询。

源端工作负载过高

如果您的源 PostgreSQL 的工作负载很高，请检查以下事项以减少延迟：

  • 使用 test_decoding 插件，从具有高每秒事务数（TPS）值的源数据库迁移表的子集时，您可能会遇到高延迟。这是因为 test_decoding 插件会将所有数据库更改发送到复制实例，然后 DMS 会根据任务的表映射对这些更改进行筛选。不属于任务表映射的表中的事件可能会增加源延迟。

  • 使用以下方法之一检查 TPS 吞吐量。

    • 对于 Aurora PostgreSQL 源，请使用 CommitThroughput CloudWatch 指标。

    • 对于在 Amazon RDS 或本地运行的 PostgreSQL，请通过 PSQL 客户端版本 11 或更高版本使用以下查询（在查询期间按 enter 可显示结果进度）：

      SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";

  • 为了减少使用 test_decoding 插件时的延迟，请考虑改为使用 pglogical 插件。与 test_decoding 插件不同，pglogical 插件会筛选源端的预写日志（WAL）更改，并且仅将相关更改发送到复制实例。有关将 pglogical 插件与 AWS DMS 结合使用的信息，请参阅配置 pglogical 插件。

高网络吞吐量

使用 test_decoding 插件时，您的复制可能会占用大量的网络带宽，尤其是在有大量事务期间。这是因为 test_decoding 插件会处理更改，并将它们转换为人类可读格式，这比原始二进制格式更大。

为了提高性能，请考虑改用 pglogical 插件，它是一个二进制插件。与 test_decoding 插件不同，pglogical 插件生成二进制格式的输出，从而导致压缩的预写日志（WAL）流更改。

Aurora PostgreSQL 中的溢出文件

在 PostgreSQL 版本 13 及更高版本中，logical_decoding_work_mem 参数决定了用于解码和流式传输的内存分配。有关 logical_decoding_work_mem 参数的更多信息，请参阅 PostgreSQL 13.13 文档中的 PostgreSQL 中的资源消耗量。

逻辑复制会累积内存中所有事务的更改，直到这些事务提交为止。如果所有事务中存储的数据量超过数据库参数 logical_decoding_work_mem 指定的量，则 DMS 会将事务数据溢出到磁盘，以便为新的解码数据腾出内存空间。

长时间运行的事务或许多子事务可能会导致 DMS 占用更多的逻辑解码内存。内存使用量的增加会导致 DMS 在磁盘上创建溢出文件，从而导致复制期间源延迟很高。

要减少源工作负载增加所带来的影响，请执行以下操作：

  • 减少长时间运行的事务。

  • 减少子事务数。

  • 避免执行会生成大量日志记录的操作，例如在单个事务中删除或更新整个表。改为以较小的批量执行操作。

您可以使用以下 CloudWatch 指标来监控源端的工作负载：

  • TransactionLogsDiskUsage：逻辑 WAL 当前占用的字节数。如果逻辑复制槽无法跟上新写入数据的步伐，或者如果任何长时间运行的事务阻碍对旧文件进行垃圾回收，则此值会单调增加。

  • ReplicationSlotDiskUsage：逻辑复制插槽当前使用的磁盘空间量。

您可以通过调整 logical_decoding_work_mem 参数来减少源延迟。此参数的默认值为 64 MB。此参数限制每个逻辑流复制连接使用的内存量。建议将 logical_decoding_work_mem 值设置为显著高于 work_mem 值，以减少 DMS 写入磁盘的解码更改量。

建议定期检查溢出文件，尤其是在迁移活动繁忙或延迟期间。如果 DMS 正在创建大量溢出文件，则意味着逻辑解码的运行效率低下，可能会增加延迟。要缓解这种情况，请增加 logical_decoding_work_mem 参数值。

您可以使用 aurora_stat_file 函数检查当前事务溢出量。有关更多信息，请参阅《Amazon Relational Database Service 开发人员指南》中的调整工作内存以进行逻辑解码。