Postgre SQL 端点故障 - AWS 数据库迁移服务
源上长时间运行的事务源端工作负载过高高网络吞吐量在 Aurora Postgre 中泄露文件 SQL

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

Postgre SQL 端点故障

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

源上长时间运行的事务

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

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

  • 使用 pg_replication_slots 视图。如果该restart_lsn值未更新，Postgre SQL 很可能由于交易长期处于活动状态而无法发布 Write Ahead Logs (WALs)。有关该pg_replication_slots视图的信息，请参阅 Postgre 15.4 文档中的 pg_replication_slot s。SQL

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

    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 字段显示每个查询的活动时长，您可以使用该时长来确定长时间运行的查询。

源端工作负载过高

如果您的源 Postg SQL re 的工作负载很高，请检查以下内容以减少延迟：

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

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

    • 对于 Aurora Postgre SQL 来源，请使用该CommitThroughput CloudWatch 指标。

    • 对于在 Amazon RDS 或本地SQL运行的 Postgre，请使用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 Postgre 中泄露文件 SQL

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

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

长时间运行的事务或许多子事务可能会导致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 开发人员指南中的调整工作内存以进行逻辑解码。