本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
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_slots。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 开发人员指南中的调整工作内存以进行逻辑解码。