PostgreSQL 端点故障排除 - Amazon 数据库迁移服务
源上长时间运行的事务源端工作负载过高高网络吞吐量在 Aurora PostgreSQL 中泄露文件
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

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 插件与 Amazon 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 开发人员指南中的调整工作内存以进行逻辑解码。