使用 AWS DMS 仅验证任务优化数据验证 数据库博客

使用 AWS DMS 进行数据验证优化

关键要点

本文将探讨如何利用 AWS 数据库迁移服务DMS中的验证专用任务来优化数据验证过程。AWS DMS 数据验证帮助确保源数据和目标数据之间的一致性，提高迁移项目成功率。我们将讨论 AWS DMS 验证任务的使用案例、配置监控以及如何处理验证失败。

AWS 数据库迁移服务AWS DMS可以帮助您高效、安全地将数据迁移到 亚马逊云服务AWS。您可以将数据从广泛使用的商业数据库如 Oracle 和 SQL Server迁移到开源数据库如 MySQL 和 PostgreSQL。AWS DMS 提供在从多种 支持的来源 迁移到 AWS 时验证数据的能力。数据完整性和准确性是客户所期望的成功迁移项目的重要要求之一。本文将深入探讨 AWS DMS 数据验证功能，并探讨其优点、配置和用例。

AWS DMS 数据验证

AWS DMS 数据验证确保您从源迁移到目标的数据准确无误。当您选择 带数据迁移的验证 作为 AWS DMS 迁移任务的 Full Loadonly仅迁移现有数据类型时，数据验证在完整加载完成后立即开始。对于 带数据迁移的验证 和 Full Load CDC迁移现有数据并复制持续变化，验证在完整加载完成后立即开始，并在增量变化发生时持续比较变化。如果使用仅 CDC 的任务并启用了验证，所有表中的预存数据在验证新数据之前都会被验证。

在数据验证过程中，AWS DMS 将源中的每一行与目标中的相应行进行比较，验证这些行中的数据是否相同，并报告任何不匹配的情况。不同数据类型的列值会有不同的比较方式。例如，针对大型二进制对象LOB列使用校验和函数进行比较，而其他数据类型则使用实际数值进行比较。

您可以通过 AWS DMS 控制台或 AWS 命令行界面AWS CLI 启用数据验证功能。有关更多信息，请参阅 迁移验证第2部分 在 AWS 数据库迁移服务中引入数据验证。您还可以创建 仅验证任务 来预览和验证数据，而不执行任何迁移或数据复制。此验证过程会消耗源端和目标端的额外资源以及额外的网络资源，并且需要源和目标表具有主键或唯一索引。在使用 AWS DMS 验证之前，建议您查看 限制。

解决方案概述

本帖子涵盖以下主题：

AWS DMS 验证专用任务的用例关系数据库如何配置和监控 AWS DMS 仅验证任务数据验证任务：全量加载与 CDC 比对如何优化 AWS DMS 仅验证任务如何处理验证失败的情况

AWS DMS 验证专用任务的用例关系数据库

AWS DMS 验证专用任务有几个常见用例：

无需执行迁移即可验证数据：验证专用任务允许您在不复制任何数据的情况下验证源和目标之间的数据。这对于测试验证规则和设置非常有用。将验证与迁移任务隔离：通过创建单独的验证专用任务，您可以独立验证数据，而不会影响现有的迁移任务。这可以防止验证失败阻塞迁移，并提供在单独的复制实例上运行验证任务的可能性。此外，这个不同的 DMS 版本也可以包含新的功能。故障排除验证失败：如果迁移任务中的验证失败，验证专用任务可以更轻松地进行调查和故障排除，因其与正在进行的迁移处于隔离状态。计划验证：您可以安排验证专用任务定期运行，以验证数据在源和目标数据库中的变化。这与持续运行任务相比，可以减少源和目标数据库实例的负载。快速获取特定时刻的不匹配数据行：您可以在生产切换窗口之前或期间运行全量加载验证专用任务，以验证数据，然后再将应用程序指向新的目标端点。数据修复脚本：当您创建一个读取验证失败表的修复脚本时，全量加载验证专用任务可以快速报告脚本需要处理的失败情况。

如何配置和监控 AWS DMS 仅验证任务

要通过 AWS DMS 控制台创建验证任务，请在创建 AWS DMS 任务时设置以下配置：

将 TargetTablePrepMode 设置为 DONOTHING这是验证专用任务的默认值。将 Migration Type 设置为 迁移现有数据 或 仅复制数据更改。在 Data Validation 中，选择 不带数据迁移的验证。

您也可以使用 JSON 编辑器修改 Task settings：

jsonEnableValidation true ValidationOnly true

当启用数据验证后，您可以通过 AWS DMS 控制台或 Amazon CloudWatch 监控验证的状态。

在某些记录在源和目标之间不匹配的情况下，Validation state 将显示为 Mismatched records，您可以在目标数据库中的 awsdmsvalidationfailuresv1 表中查看详细信息。该表是在您定义的 ControlSchema 中创建的，或者在您的数据库引擎的 默认位置。如果有任何记录进入 ValidationSuspended 或 ValidationFailed 状态，AWS DMS 会将诊断信息写入同一表中。

全量加载和 CDC 验证专用迁移类型

如前所述，您可以使用两种类型的迁移类型创建验证专用任务：全量加载验证专用任务和 CDC 验证专用任务。以下部分解释这两种类型的数据验证过程和关键调优参数。

全量加载验证专用任务

从 AWS DMS 版本 346 及更高版本开始，全量加载验证专用任务能够快速比较源和目标表中的所有行，无延迟地报告验证失败，并在验证完成后停止任务。

AWS DMS 将数据逻辑上分为各个分区默认每个分区 10000 行，并通过多个 AWS DMS 数据验证线程默认五个线程比较这些分区的数据。任何数据验证错误都会记录在目标数据库中的控制表awsdmscontrolawsdmsvalidationfailuresv1。在下图中，由于数据 Row n 在列 coln 的值不匹配，因此报告了不匹配记录。

一元云.cn

下表显示了全量加载验证专用任务的重要任务参数。有关 AWS DMS 数据验证任务的完全支持参数，请参考 数据验证任务设置。

参数默认设置说明PartitionSize10000指定要从源和目标读取以进行比较的记录批量大小。ThreadCount5指定 AWS DMS 在验证期间使用的执行线程数量。SkipLobColumnsFALSE如果此设置为 “TRUE”，则 AWS DMS 会跳过所有 LOB 列的数据验证。ValidationPartialLobSize0默认情况下，AWS DMS 会验证所有 LOB 列数据。指定您在有限 LOB 模式中使用的截断值。如果在数据迁移任务中将最大 LOB 大小设置为 32KB，则应将 “ValidationPartialLobSize” 设置为 32。这确保 AWS DMS 仅在源和目标中验证列数据的前 32KB。

CDC 验证专用任务

当 CDC 验证专用任务启动后，首先验证预存数据，然后验证 CDC 捕获的增量更改并报告任何不匹配的情况。它会持续重新验证正在复制的更改。CDC 验证在报告失败之前会重试不匹配的行，以防止误报。它等待重试的时间取决于在任务设置中使用的参数 RecordFailureDelayLimitInMinutes 和 RecordSuspendDelayInMinutes 配置的失败重试期限。在下图所示的时间 T1，AWS DMS 验证线程发现 Row n 的数据不一致，而不立即报告失败，它会重试并预期持续的数据复制任务可能会修复该问题。

在随后的时间点 T2，仍在失败重试期间，AWS DMS 验证线程会再次比较 Row n 的数据，发现数据匹配，因此不会报告任何数据验证失败。对于 AWS DMS 验证任务发现的任何新数据，AWS DMS 会将其分成多个分区并分配数据验证线程来验证数据。

下表显示了 CDC 验证专用任务的重要任务参数，应与前述全量加载验证专用任务突出显示的参数结合考虑。有关 AWS DMS 数据验证任务的完全支持参数，请参考 数据验证任务设置。

参数默认设置说明失败重试期限RecordFailureDelayInMinutes=0 RecordFailureDelayLimitInMinutes=0指定报告任何验证失败详细信息之前的延迟时间以分钟为单位。表级失败控制TableFailureMaxCount=1000指定在验证失败之前，单个表中可以失败的最大行数。表级失败控制RecordSuspendDelayInMinutes=0指定由于在 FailureMaxCount 中设置的错误阈值，表被暂停验证之前的延迟时间以分钟为单位。任务级失败控制FailureMaxCount=10000指定在验证失败之前，可能导致任务挂起的最大记录数。

如何优化 AWS DMS 验证专用任务

本节描述了一些可以优化 AWS DMS 验证专用任务性能的验证任务设置。这些设置应在较低环境中进行测试，然后再实施到生产环境中。每个验证任务都是独特的，并且需要在任务级别上进行微调。

ThreadCount：此参数指定 AWS DMS 在执行数据验证时使用的线程数。默认值为五，每个线程处理尚未验证的数据进行比较和验证。较高的线程数可以提高验证任务的整体性能，但增加线程数会消耗源和目标端点的额外资源。PartitionSize：此设置指定每个线程从源和目标实例读取的记录数。从默认值 10000 增加可以让 AWS DMS 读取更多记录进行验证，但会增加迁移组件的额外负载。RecordFailureDelayLimitInMinutes：此参数允许您指定 AWS DMS 报告验证失败之前的延迟。通常，AWS DMS 使用任务延迟值以允许实际延迟，以防止误报。这一设置可以定义更高的值。ValidationQueryCdcDelaySeconds：这是在源和目标上验证查询首次延迟的时间。对于验证专用任务，默认值为 180 秒。如果由于源上的大量更新而导致高延迟，您可以将此值设置得更高，以减少对源实例的争用。FailureMaxCount：此设置跟踪在任务挂起之前的最大验证失败数量。默认值为 10000。在希望验证继续验证所有记录的情况下，将此值设置为高于源表记录数。相反，如果您不能容忍数据不匹配，您可以使用较低的值，这样当发生失败时任务会快速挂起，从而确保更严格的数据完整性检查。HandleCollationDiff：此选项控制如何处理列排序规则的差异。默认值为 false，这会忽略列之间的排序规则差异，从而可能导致数据验证中的误报。排序规则决定了记录的排序方式以及在比较过程中如何匹配数据，这在数据验证中是一个重要方面。例如，以下示例展示了基于字符串“abcABC”的不区分大小写与区分大小写的排序顺序。ASCII 表示不区分大小写排序区分大小写排序a = 01100001A = 01000001A = 01000001b = 01100010a = 01100001B = 01000010c = 01100011B = 01000010C = 01000011A = 01000001b = 01100010a = 01100001B = 01000010C = 01000011b = 01100010C = 01000011c = 01100011c = 01100011结果：“AaBbCc”“ABCabc”

如何处理验证失败情况

在本节中，我们将介绍 AWS DMS 验证任务报告的数据验证失败的常见场景及其解决方案。

截断 LOB

在将数据库迁移到目标实例时，AWS DMS 会根据迁移任务中的配置复制数据，包括大对象LOB。您有几个 可配置设置 用于 LOB 对象。默认情况下，AWS DMS 在有限 LOB 模式下使用最大 32 KB 的单个 LOB 大小。如果使用默认配置，任何超过最大 LOB 大小的 LOB 都会被截断。

截断的 LOB 列会导致数据验证失败，因为源和目标之间的值不同。您可以通过在 AWS DMS CloudWatch 日志中搜索截断警告来验证 LOB 截断。为避免截断，请将最大 LOB 大小设置为与源数据库中的 LOB 大小相匹配。如果不确定 LOB 大小，您可以选择 内联 LOB 模式如果端点支持以复制小型和大型 LOB。建议在验证专用任务中将 ValidationPartialLobSize 值设置为与数据迁移任务的最大 LOB 大小相同。

截断的数字和时间戳

数字和时间戳数据通常在不同的数据库引擎中具有不同的尺度和精度，如果未指定值，它们的默认值会有所不同。以下是一些常见示例，以说明数字和时间戳可能遇到的问题以及如何解决它们。

Oracle 数据库作为源

在 Oracle 数据库中，对于未明确提及尺度和精度的 NUMBER 类型数字数据，AWS DMS 会将数据截断为 10 的尺度。对现有数据，如果尺度大于 10，目标中的数字将会被截断。例如，数据 123456123456789012 会被截断为 1234561234567890。要避免数据截断，需通过在 AWS DMS 数据复制任务的端点中修改相关参数 NumberDataTypeScale 来指定合适的值。默认值为 10，在本例中应将其设置为 12 以避免数据截断。有关更多信息，请参考 AWS DMS 文档。

PostgreSQL 作为源和目标

在 PostgreSQL 到 PostgreSQL 的迁移中，当数值数据存储在未定义任何精度或尺度的数字数据类型的列中时，AWS DMS 会将数据截断为精度 28 和尺度 6。为避免截断，需在源和目标端点上使用 ECA 参数 MapUnboundedNumericAsString=true，以在迁移过程中将不受限的数字数据映射为字符串类型。

时间戳数据

Oracle 为 TIMESTAMP 数据类型支持最多九位秒的小数位即，纳秒，而 SQL Server 在 TIME 数据类型中支持最多七位小数位。将这些数据映射到 MySQL 或 PostgreSQL 等目标时，它们都支持以 TIMESTAMP 数据类型表示的最多六位小数位。因此，如果源数据库例如，Oracle的数据类型定义为 TIMESTAMP