AWS DMS 数据恢复与弹性场景

关键要点

在这篇文章中，我们将探讨 AWS 数据库迁移服务DMS的数据验证与目标数据库故障的相关场景。我们将重点介绍常见的验证场景，包括源与目标之间的数据漂移，并分享应对策略以及对错误处理设置的建议。 通过这些内容，您可以更好地理解如何确保数据迁移的完整性和可靠性。

在系列文章的第一部分中，我们讨论了在从 Oracle 迁移到亚马逊关系数据库服务Amazon RDS for PostgreSQL 时，与源、网络、任务和复制实例相关的故障。在本篇文章中，我们将讨论与验证和目标数据库故障相关的场景，并分享相应的缓解策略和错误处理设置。

AWS DMS 数据验证

AWS DMS 支持 数据验证，确保您的数据已正确从源迁移到目标。如果启用，验证将在完整加载阶段完成后不久开始。验证还会比较变更数据捕获CDC任务所发生的增量变更。AWS DMS 会将源中的每一行与目标中的匹配行进行比较，并报告任何不匹配情况。如果在数据验证过程中遇到错误，您需要检查复制任务日志或查看目标数据库中的 awsdmsvalidationfailuresv1 表。

AWS DMS 数据验证可能出现的错误类型

以下是 AWS DMS 日志中出现的错误示例：

[VALIDATOR ]I Validation Failed key Table 1 Partition 101 iLastUpdateTime 1689790621443407 iFailedTimeThreshold 1689790622015420 iFailedTime 1689790621443407 iFailedCount 6 (partitionupdatetrackerc653)

错误日志对于缺少源、缺少目标和记录差异是相同的，但 awsdmsvalidationfailuresv1 中的错误细节是不同的，我们将在下面的示例中探讨。

如果目标数据库中有额外记录而源中缺少相应行，则该错误在控制表 awsdmsvalidationfailuresv1 中会显示为 MISSINGSOURCE。以下是相关代码示例：

TASKNAME 7ADUZYCTMASWYXSOTDDV43B2Q7BRMKAG5DNKUGATABLEOWNER crtdmsTABLENAME ppt10FAILURETIME 20230719 185958780287KEYTYPE RowKEY { key [2] }FAILURETYPE MISSINGSOURCEDETAILS

在重新验证时，如果源中缺少记录，可能是因为： 源中的分区被删除而目标中仍然存在。 目标中在 AWS DMS 或您的应用以外的位置插入了额外数据。

如果任何记录未迁移到目标数据库，您将在控制表 awsdmsvalidationfailuresv1 中看到此错误，显示为 MISSINGTARGET：

TASKNAME 7ADUZYCTMASWYXSOTDDV43B2Q7BRMKAG5DNKUGATABLEOWNER crtdmsTABLENAME ppt10FAILURETIME 20230719 184444375939KEYTYPE RowKEY { key [1102511] }FAILURETYPE MISSINGTARGETDETAILS

当任务的复制选项开启时，数据将从源到目标以及反向进行验证。

如果源与目标数据库中基于主键或唯一键的记录不匹配，您将在控制表 awsdmsvalidationfailuresv1 中看到以下错误，显示为 RECORDDIFF：

TASKNAME 7ADUZYCTMASWYXSOTDDV43B2Q7BRMKAG5DNKUGATABLEOWNER crtdmsTABLENAME ppt10FAILURETIME 20230719 182207977138KEYTYPE RowKEY { key [1102511] }FAILURETYPE RECORDDIFFDETAILS [[{COUNTRY INDIA} {country AUS}]]

此问题可能由以下原因引起： 目标的延迟 源上的批量加载可能对目标数据库造成潜在影响。当 AWS DMS 任务延迟时，可能会导致数据验证错误，并报告由于目标上缺失记录而导致的失败。 源的频繁更新 在源上进行大量并发更新时，您可能会注意到 AWS DMS 数据验证未能准确验证目标中的数据。

建议的缓解策略

在本节中，我们将讨论缓解数据验证问题的可能策略。

您可以部署自定义的 AWS Lambda 函数来解析 Amazon CloudWatch 日志，并根据错误匹配向相关团队发送通知。您还可以参考目标数据库中由 DMS 创建的控制表 awsdmsvalidationfailuresv1 来及时通知相关团队进行纠正措施。您可以使用 AWS DMS 描述任务 API 来获取验证失败统计数据。

在数据库中查询该表的命令如下：

select from awsdmsvalidationfailuresv1 where TASKNAME = task name and TABLENAME=table name order by FAILURETIME desc

您可以为源和目标延迟设置 CloudWatch 警报。当延迟达到某一值时，CloudWatch 会通过 Amazon 简单通知服务Amazon SNS触发警报，并向相关团队发送通知。

考虑使用以下建议的验证配置来调整 AWS DMS 任务：

jsonValidationPartialLobSize 0PartitionSize 20000RecordFailureDelayLimitInMinutes 0SkipLobColumns falseFailureMaxCount 9999999HandleCollationDiff trueValidationQueryCdcDelaySeconds 0ValidationMode ROWLEVELTableFailureMaxCount 9999999RecordFailureDelayInMinutes 5MaxKeyColumnSize 8096EnableValidation trueThreadCount 10RecordSuspendDelayInMinutes 3ValidationOnly false

此外，您在数据验证过程中可能会遇到以下问题： 源与目标间的数据类型不匹配 如果遇到数据类型问题，您可以在验证或数据复制任务中使用 AWS DMS 转换规则来修复。 LOB 截断 在某些情况下，可能会观察到 LOB 列不匹配。为此，您可以手动检查源与目标数据库之间的主键或唯一键值是否匹配。 因目标数据库故障/连接超时造成表错误 如果验证失败计数达到验证阈值，则该表将被暂停验证。

以下表格展示了 AWS DMS 任务控制台上的表统计示例。

以下是目标数据库重新启动时的 AWS DMS 日志示例：

[VALIDATORTARGE ]E Fetching validation result from endpoint PTVJNY57F7ZKPQRQFOVAQXNNVOQO76UKHWVFN7I (2) failed ErrorMessage SSL SYSCALL error EOF detected No query has been executed with that handle Retryable 0 [1022502] (validationresultc358)

在验证期间发生连接超时或数据库重启时，请考虑以下措施： 如果是仅验证任务，重新启动验证任务。 如果任务类型是完整数据加载及 CDC，尝试在任务中使用重新验证选项。 如果任务类型仅为 CDC 且验证已启用，则需要为失败表创建单独的验证任务。 排序差异 由于 PostgreSQL 和 Microsoft SQL Server 数据库之间的排序差异，验证可能返回假阴性。为缓解此类问题，请在验证设置中将 HandleCollationDiff 设置为 true。

有关数据验证限制的更多信息，请参考 限制。

目标数据库故障

Amazon Aurora 是一种支持 MySQL 和 PostgreSQL 的托管服务。在本篇文章中，我们将使用 Amazon Aurora PostgreSQL 兼容版 数据库作为目标数据库。如果由于争用、重启、网络、通信或其他原因导致目标数据库不可用，将会导致源与目标数据库间的复制任务失败。

以下图示展示了目标数据库故障场景。

AWS DMS 与目标数据库之间断开连接

如果由于硬件或网络问题导致目标数据库不可用，AWS DMS 任务将无法连接到目标，从而导致目标延迟增加。

以下是 AWS DMS 在完整加载时向目标加载数据时出现的错误代码示例：

20230718T100804 [TASKMANAGER ]E RetCode SQLERROR SqlState 08S01 NativeError 35 Message The connection has been lost Failed to get table crtdmsppt3 Handling new table crtdmsppt3 failed Connection error Endpoint is disconnected Error executing data handler Stream component failed at subtask 2 component st2PTVJNY57F7ZKPQRQFOVAQXNNVOQO76UKHWVFN7I Stream component st2PTVJNY57F7ZKPQRQFOVAQXNNVOQO76UKHWVFN7I terminated [1020414] (replicationtaskc3239)

以下是 AWS DMS 在 CDC 时向目标加载数据时出现的错误代码示例：

20230718T102306 [TARGETLOAD ]E RetCode SQLERROR SqlState 08001 NativeError 101 Message [unixODBC]could not connect to server Connection refused Is the server running on host ukpgclustercl7uqmhlcmfieuwest2rdsamazonawscom (1723245133) and accepting TCP/IP connections on port 5432 [1022502] (arodbcconnc579)

此连接丢失可能是由于您在 AWS DMS 中配置目标端点时使用了实例端点。偶尔也可能因为安全组的更改导致连接丢失。

为减少此问题的影响，请考虑以下策略： 检查 AWS DMS 任务日志以了解更多错误信息。 检查 CloudWatch 指标、事件订阅和数据库日志，以了解目标数据库故障或故障转移的原因。 为了实现高可用性，我们建议使用多可用区配置，将读实例放置在不同的可用区。可用的读实例将被 提升为写实例 并继承集群写入端点，AWS DMS 将尝试重新连接。 配置目标端点以使用 RDS 集群端点，这可以帮助缓解网络连接事件。

目标数据库中的资源争用

目标数据库的资源争用可能由以下原因造成： 目标数据库实例的错误配置 其他服务导致的高资源使用CPU、内存或 I/O 表中缺少适当的索引主索引、唯一索引或二级索引，导致全表扫描 源数据库的高 OLTP 工作负载

如果除 AWS DMS 外没有其他内容连接到目标数据库，则需要首先使用 增强监控、CloudWatch 或 Amazon RDS 性能洞察 来了解争用发生的位置。如果错误是由于实例配置问题造成的，请考虑以下措施： 将主数据库的实例类型更改为更高等级以增加计算或内存容量，并重新运行 AWS DMS 任务。 修改只读副本的实例类型并增加其大小。当您对当前写实例发起故障转移时，AWS DMS 将自动连接至新的写实例。

在持续的复制阶段，您可能会观察到 AWS DMS 在目标数据库上使用了更多资源，原因可能是索引不合理或全表扫描。在这种情况下，您需要生成基础查询的执行计划并修复根本原因，可以通过在目标表上添加二级索引来解决。

如果目标数据库为 PostgreSQL，则高峰业务时间的大型 DML 操作可能会使自动清理守护进程运行，导致 AWS DMS 应用阶段变慢。为此，请调整您的 autovacuum 参数 并考虑我们讨论的实例配置策略。

错误处理设置与监控

在本节中，我们讨论默认行为和可能的解决方案，以避免任何数据错误，例如 SUSPENDTABLE 和 STOPTASK。有关更多信息，请参考 错误处理任务设置。

任务在发生错误时的默认行为是记录问题并继续复制。为了避免由于数据损坏、数据缺失或部分数据复制而导致的关键业务损失，建议使用 STOPTASK 选项。

大多数错误处理基于以下设置： LOGERROR 任务继续执行，并将错误写入任务日志 SUSPENDTABLE 任务继续执行，但包含错误记录的表的数据进入错误状态且该数据不会被复制 STOPTASK 任务停止，需要手动干预

如果您使用有限 LOB 模式并且在 CDC 中的任何新 LOB 值超出任务设置的有限大小，则仅会部分复制数据。为此，您可以使用参数 DataTruncationErrorPolicy，决定 AWS DMS 对截断数据采取的操作。默认设置为 LOGERROR，意味着将消息记录在任务日志中并继续。然而，我们建议使用 STOPTASK 停止任务，修复错误后再恢复任务。

在 DML 的情况下，如果任何操作失败，则目标表中的数据会出现问题。为了解决此问题，请检查 awsdmsapplyexceptions 中的异常，然后调整错误处理设置。您可以根据需要设置 ApplyErrorDeletePolicy、ApplyErrorInsertPolicy 和 ApplyErrorUpdatePolicy。

有关其他任务控制和行为的信息，请参考 错误处理任务设置。这可以帮助您采取必要行动，而不会遭遇表暂停或任务取消的情况。如需了解更多信息，请参考 我如何修改 AWS DMS 任务的错误处理任务设置？。

有关迁移任务故障排除的更多信息，请参阅 AWS 数据库迁移服务中的迁移任务故障排除。

结论

在这篇文章中，我们讨论了各种故障场景及其缓解步骤，这些场景与数据复制设置中的每个组件相关。确保在开始数据迁移之前，针对每个测试用例进行了充分的测试，并有可行的解决方案，能够同时满足客户、业务和技术利益相关者的需求。

感谢您的反馈。如有任何问题或建议，欢迎在评论区留言。

作者介绍

Vivekananda Mohapatra 是 AWS 专业服务团队的首席顾问。他对 Amazon RDS for Oracle、Amazon RDS for PostgreSQL、Amazon Aurora PostgreSQL 和 Amazon Red