优化 AWS DMS 复制延迟：使用 Amazon S3 作为目标

关键要点

本文介绍了针对 AWS 数据库迁移服务DMS和 Amazon S3 的自定义配置，以优化数据加载并减少延迟。复制延迟的主要原因包括来源捕获、资源限制以及任务设置。对于目标性能问题的解决办法，建议调整任务和 S3 的配置参数，以降低延迟并提升性能。

本文旨在通过 Amazon S3 作为目标，帮助用户巧妙地优化 AWS DMS 任务，进而减少数据复制所产生的延迟，确保客户能够快速访问和分析数据。

构建数据源于 Amazon Simple Storage ServiceAmazon S3可以为分析管道带来显著好处，它可以让您访问多个大型数据源，优化新数据处理管道，构建人工智能AI和机器学习ML模型，为客户和消费者提供个性化的体验。

在这篇文章中，我们展示了在 AWS 数据库迁移服务AWS DMS和 Amazon S3 级别上进行的自定义配置，以优化负载并减少目标延迟。每个复制操作都是独特的，在生产系统进行任何更改之前，务必要在您的环境中测试这些修改。

如何排查延迟问题

在任何逻辑复制过程中，主要步骤包括从源收集数据、在复制层处理变更在 AWS DMS 中，这些操作发生在 复制实例 上以及准备并将数据发送到目标。由于 AWS DMS 是异步复制数据，任何突发的变更增加、长时间运行的查询或资源限制都可能在源提交变更和目标可用之间产生复制间隙，这些间隙就被称为 延迟。

您可以了解更详细的可观察性 这里，以及如何监控和解决常见的延迟原因 这里。以下是我们进行故障排除的关键步骤：

确认延迟是在源捕获还是 Amazon S3目标端。可以通过检查 CDCLatencySource 和 CDCLatencyTarget 的值来实现。确认复制实例上是否有足够的资源。检查 Amazon CloudWatch 指标如 CPUUtilization、FreeableMemory 和 SwapUsage、ReadIOPS、WriteIOPS、ReadLatency 和 WriteLatency是否出现高峰或持续高值。对于 AWS DMS 的内存，充分处理突发增加或大量 CDC 操作尤其重要。审查 Amazon S3 的一般设置和性能，如使用尽可能靠近或位于与 AWS DMS 复制相同区域的 S3 存储桶。检查 AWS DMS 任务日志以确保没有错误或警告消息，如客户端断开连接、复制问题或与延迟相关的消息。

用例概述

在这一场景中，我们在复制到 Amazon S3 的过程中面临竞争问题。初步观察如下：

我们在本地和 Amazon 关系型数据库服务Amazon RDS上有多个 Oracle 和 MySQL 源数据库，其中一些显示出较强的事务性特征。二进制日志和存档生成量在高峰期波动，最高达每小时 100GB。根据我们的初步调查，没有源延迟，我们在复制层面提供了足够的资源CDCLatencySource 接近 0，且 CDCLatencyTarget 波动在 15分钟阈值之上。AWS DMS 任务和 S3 端点使用了默认设置，高峰期 CDCLatencyTarget 指标达到数千秒，并不断增加，最终导致 AWS DMS 任务暂停从源读取变更。这些暂停是由于当前变更的流入、处理延迟和 AWS DMS 设置造成的，这使得事务在内存中停留有限时间，以免影响其他进程。

最终结果是不断出现阻塞变更的循环，这影响了整体延迟以及客户体验，使得最终用户无法在预期的 15 分钟时间窗口内获取数据。

如何解决目标性能问题

为了解决上述问题，可以执行以下步骤。请注意，以下值是基于此特定场景的示例，可能在您的复制中并不完全适用；测试这些更改于 QA/DEV 环境中并进行充分分析后，再应用到生产工作负载中非常重要。

小熊加速器下载停止与同一 S3 目标相关的当前 AWS DMS 任务。在 S3 目标 DMS 端点级别 更改以下设置以控制写入频率：cdcMaxBatchInterval 定义以秒为单位的最大间隔长度，输出文件到 Amazon S3 的条件。将默认值从 60 秒改为 20 秒。cdcMinFileSize 定义以千字节为单位的最小文件大小条件，输出文件到 Amazon S3。将默认值 32000 KB 改为 16000 KB。在 AWS DMS 任务级别 调整当前 CDC 任务的以下设置：MinTransactionSize 每个事务中包含的最小变更数量。将默认值从 1000 改为 3000。CommitTimeout AWS DMS 在宣布超时之前，收集事务批处理的最大时间以秒为单位。将默认值从 1 秒增加到 5 秒。恢复任务以应用新更改。

在这个场景中，我们通过降低触发传输事件所需的时间和大小阈值，优化了端点目标写入能力。这种配置将使任何使用相同 S3 端点的任务，每 20 秒关闭并创建 CDC 文件，如果文件大小未超过 16MB。相应参数组合是有条件的，写入文件会在较先满足的阈值下触发。

结果和额外配置

在应用上述更改后，来自两个源的复制流的目标延迟降低到 310 秒的平均值相比之前 15 分钟的窗口降低了 99。处理变更的速度加快也减少了总体内存使用，从而减轻了 CDC 停止捕获的问题。

如出现“Reading from source is paused Total storage used by swap files exceeded the limit”的消息，请考虑增加特定任务的整体内存设置。这将使事务在内存中停留的时间更长，根据以下设置：

MemoryLimitTotal 设置所有事务在写入磁盘之前可以占用的最大内存大小以 MB 为单位。默认值为 1024。增加此参数的值可以帮助有效利用实例的可用内存。MemoryKeepTime 设置每个事务可以在内存中停留的最大时间以秒为单位，计算自 AWS DMS 开始捕获事务的时间。默认值为 60 秒。增加此值可以帮助长时间保持事务在内存中。

这些更改还会增加每个单独任务的总内存分配，因此 选择合适的实例类型至关重要。由于内存是复制实例上最关键的资源之一，内存优化实例R 类通常是生产环境中关键和资源密集型迁移中的优选选择，但类型和理想大小可能会因其他因素而异。

结论

在这篇文章中，我们展示了在面对大数据变更量时，如何优化您的 AWS DMS 任务，并使用 Amazon S3 作为目标。尝试在您的用例中应用这个解决方案，并查看 最佳实践，以利用 AWS DMS 的其他功能，包括 通用日志、上下文日志、通过 CloudWatch 指标 的可观察性，以及通过 Amazon EventBridge 和 Amazon SNS 的自动化和通知。如果这里讨论的设置无法解决您的问题，也可以查看文中提供的所有链接以获取更多选项，并联系 AWS 支持，以便我们的数据库主题专家为您提供指导。

关于作者

Felipe Gregolewitsch 是亚马逊网络服务的高级数据库迁移专家，专注于 RDS 核心服务。拥有超过 14 年的数据库迁移经验，涵盖南美和亚太地区的项目，Felipe 帮助客户在多个引擎和平台如关系型数据库、数据湖和数据仓库上实现迁移和复制，同时利用从本地工具到 AWS DMS 等选项。