AWS DMS 数据验证 - AWS Database Migration Service

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

AWS DMS 数据验证

AWS DMS 为数据验证提供支持,以确保您的数据从源准确迁移到目标。如果启用,则在对表执行完全加载后立即开始验证。对于启用 CDC 的任务,验证会在发生更改时比较增量更改。

在数据验证期间, AWS DMS 将源中的每行与目标位置的相应行进行比较,验证这些行是否包含相同的数据,并报告任何不匹配的情况。为此 AWS DMS ,需要通过适当的查询来检索数据。请注意,这些查询将占用源和目标中的额外资源以及额外的网络资源。

对于启用了验证的仅 CDC 任务,在开始验证新数据之前,将对表中所有已存在的数据进行验证。

数据验证适用于以下源数据库,只要这些源数据库 AWS DMS 支持它们作为源端点:

  • Oracle

  • 兼容 PostgreSQL 的数据库(PostgreSQL、Aurora PostgreSQL 或 Aurora Serverless for PostgreSQL)

  • 兼容 MySQL 的数据库(MySQL、MariaDB、Aurora MySQL 或 Aurora Serverless for MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

数据验证适用于以下目标数据库,只要这些数据库 AWS DMS 支持它们作为目标端点:

  • Oracle

  • 兼容 PostgreSQL 的数据库(PostgreSQL、Aurora PostgreSQL 或 Aurora Serverless for PostgreSQL)

  • 兼容 MySQL 的数据库(MySQL、MariaDB、Aurora MySQL 或 Aurora Serverless for MySQL)

  • Microsoft SQL Server

  • IBM Db2 LUW

  • Amazon Redshift

  • Amazon S3。有关验证 Amazon S3 目标数据的信息,请参阅 Amazon S3 目标数据验证

有关支持的终端节点的更多信息,请参阅使用 AWS DMS 端点

除了迁移本身所需的时间以外,数据验证还需要占用额外的时间。所需的额外时间取决于迁移的数据量。

有关这些设置的更多信息,请参阅 数据验证任务设置

有关 JSON 文件中的 ValidationSettings 任务设置的示例,请参阅任务设置示例

复制任务统计数据

启用数据验证后,将在表级别 AWS DMS 提供以下统计信息:

  • ValidationState— 表的验证状态。参数可能具有以下值:

    • Not enabled – 没有在迁移任务中为表启用验证。

    • Pending records – 表中的某些记录正在等待验证。

    • 不匹配的记录 – 表中的某些记录在源和目标之间不匹配。可能会因多种原因而发生不匹配;有关更多信息,请参阅目标终端节点上的 awsdms_control.awsdms_validation_failures_v1 表。

    • Suspended records – 无法验证表中的某些记录。

    • No primary key – 无法验证表,因为该表没有主键。

    • Table error – 未验证表,因为该表处于错误状态并且未迁移某些数据。

    • 已验证 – 表中的所有行已验证。如果更新表,则可能会变为非 Validated 状态。

    • Error – 无法验证表,因为出现意外错误。

    • 等待验证 – 表正在等待验证。

    • 准备表 – 准备迁移任务中启用的表以进行验证。

    • 等待重新验证 – 表更新后,表中的所有行在等待验证。

  • ValidationPending— 已迁移到目标但尚未经过验证的记录数量。

  • ValidationSuspended— AWS DMS 无法比较的记录数。例如,如果源记录不断更新,则 AWS DMS 无法比较来源和目标。

  • ValidationFailed— 未通过数据验证阶段的记录数。

有关 JSON 文件中的 ValidationSettings 任务设置的示例,请参阅任务设置示例

您可以使用控制台 AWS CLI、或 AWS DMS API 查看数据验证信息。

  • 在控制台中,您可以选择在创建或修改任务时验证该任务。要使用控制台查看数据验证报告,请在任务页中选择任务,然后在详细信息部分中选择表统计数据选项卡。

  • 在创建或修改任务以开始数据验证时,使用 CLI 将 EnableValidation 参数设置为 true。以下示例创建一个任务并启用数据验证。

    create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}'

    可以使用 describe-table-statistics 命令接收 JSON 格式的数据验证报告。以下命令显示数据验证报告。

    aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q

    该报告类似于以下内容。

    { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } }
  • 使用 AWS DMS API,使用CreateReplicationTask操作创建任务并将EnableValidation参数设置为 true 以验证任务迁移的数据。使用DescribeTableStatistics操作接收 JSON 格式的数据验证报告。

使用 Amazon 进行复制任务的统计数据 CloudWatch

启 CloudWatch 用 Amazon 后,将 AWS DMS 提供以下复制任务统计信息:

  • ValidationSucceededRecordCount-每分钟 AWS DMS 经过验证的行数。

  • ValidationAttemptedRecordCount— 每分钟尝试验证的行数。

  • ValidationFailedOverallCount— 验证失败的行数。

  • ValidationSuspendedOverallCount-暂停验证的行数。

  • ValidationPendingOverallCount— 验证仍处于待处理状态的行数。

  • ValidationBulkQuerySourceLatency— AWS DMS 可以批量进行数据验证,尤其是在满载或持续复制期间存在许多更改的某些情况下。此指标指示从源终端节点读取批量数据所需的延迟。

  • ValidationBulkQueryTargetLatency— AWS DMS 可以批量进行数据验证,尤其是在满载或持续复制期间存在许多更改的某些情况下。此指标指示从目标终端节点读取批量数据所需的延迟。

  • ValidationItemQuerySourceLatency— 在持续的复制过程中,数据验证可以识别正在进行的更改并验证这些更改。此指标指示从源中读取这些更改时的延迟。验证可根据更改数运行比所需数量更多的查询,前提是验证期间出错。

  • ValidationItemQueryTargetLatency— 在正在进行的复制过程中,数据验证可以识别正在进行的更改并逐行验证更改。此指标向我们提供从目标读取这些更改时的延迟。验证可根据更改数运行比所需数量更多的查询,前提是验证期间出错。

要从 CloudWatch 启用的统计数据中收集数据验证信息,请在使用控制台创建或修改任务时选择启用 CloudWatch 日志。然后,要查看数据验证信息并确保您的数据已准确地从源迁移到目标,请执行以下操作。

  1. 数据库迁移任务页面选择任务。

  2. 选择 “CloudWatch 指标” 选项卡。

  3. 从下拉菜单中选择验证

在任务期间重新验证表

在任务运行时,您可以请求 AWS DMS 执行数据验证。

AWS Management Console

  1. 登录 AWS Management Console 并打开 AWS DMS 控制台,网址为 https://console.aws.amazon.com/dms/v2/

    如果您以 AWS Identity and Access Management (IAM) 用户身份登录,请确保您拥有相应的访问权限 AWS DMS。所需权限,请参阅IAM使用所需的权限 AWS DMS

  2. 从导航窗格中选择任务

  3. 选择具有要重新验证的表的正在运行的任务。

  4. 选择表统计数据选项卡。

  5. 选择您要重新验证的表(一次最多可选择 10 个表)。如果任务不再运行,则您无法重新验证该表。

  6. 选择 Revalidate (重新验证)

使用 JSON 编辑器修改验证规则

要使用 AWS DMS 控制台中的 JSON 编辑器向任务添加验证规则,请执行以下操作:

  1. 选择数据库迁移任务

  2. 从迁移任务列表中选择您的任务。

  3. 如果您的任务正在运行,请从操作下拉菜单中选择停止

  4. 任务停止后,要修改您的任务,请从操作下拉菜单中选择修改

  5. 表映射部分,选择 JSON 编辑器,然后将您的验证规则添加到表映射中。

例如,您可以添加以下验证规则以在源上运行替换函数。在这种情况下,如果验证规则遇到 null 字节,则会将其验证为空格。

{ "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" }

仅验证任务

您可以创建仅验证的任务来预览和验证数据,而无需执行任何迁移或数据复制。要创建仅验证的任务,请将 EnableValidationValidationOnly 设置设为 true。启用 ValidationOnly 后,还需要满足其他要求。有关更多信息,请参阅 数据验证任务设置

在报告许多故障时,对于仅完全加载的迁移类型,仅验证任务的完成速度要比其 CDC 的等同验证任务快得多。但是,对源端点或目标端点的更改会被报告为完全加载模式失败,这可能是一个缺点。

CDC 仅验证任务会根据平均延迟来延迟验证,并在报告失败之前多次重试失败的验证。如果大多数数据比较都导致失败,那么 CDC 模式的仅验证任务会非常缓慢,这可能是一个不利之处。

仅验证的任务必须与复制任务的方向设置相同,尤其是对于 CDC。这是因为 CDC 仅验证任务会根据源上的更改日志,检测哪些行已更改并需要重新验证。如果目标被指定为源,则它只知道 DMS 发送给目标的更改,不能保证捕获复制错误。

完全加载仅验证

从 3.4.6 及更高 AWS DMS 版本开始,仅限满载验证的任务一次性快速比较源表和目标表中的所有行,立即报告任何故障,然后关闭。在此模式下针对速度进行了优化,验证永远不会因为失败而暂停。但是,对源端点或目标端点的更改会被报告为失败。

注意

从 3.4.6 及更高 AWS DMS 版本开始,此验证行为也适用于启用验证的满负荷迁移任务。

仅 CDC 验证

仅 CDC 验证的任务会在全新开始时,在源表和目标表之间验证所有现有行。此外,仅 CDC 验证的任务会持续运行,重新验证正在进行的复制更改,限制每次验证报告的失败次数,并在失败之前重试不匹配的行。它经过优化,可以防止误报。

如果超过 FailureMaxCountTableFailureMaxCount 的阈值,则会暂停对表(或整个任务)的验证。这也适用于启用了验证的 CDC 或完全加载+CDC 迁移任务。而且,启用了验证的 CDC 任务会根据平均源和目标延迟,来延迟对每行更改的重新验证。

但是,CDC 仅验证任务不会迁移数据,也没有延迟。默认情况下,它将 ValidationQueryCdcDelaySeconds 设置为 180。而且,您可以增加容量以应对高延迟环境,并帮助防止误报。

仅验证的使用案例

在迁移或复制任务中,将数据验证部分拆分为单独的仅验证任务的使用案例包括但不限于以下内容:

  • 精确控制何时进行验证 – 验证查询会给源端点和目标端点增加额外的负载。因此,先在一项任务中迁移或复制数据,然后在另一项任务中验证结果会有所帮助。

  • 减少复制实例的负载 – 将数据验证拆分为在自己的实例上运行可能很有好处。

  • 快速获取在给定时刻有多少行不匹配 – 例如在维护时段,进行生产切换到目标端点之前或期间,您可以创建一个完全加载仅验证任务来获取问题的答案。

  • 当使用 CDC 组件的迁移任务预计会出现验证失败时 – 例如,如果将 Oracle varchar2 迁移到 PostgreSQL jsonb,CDC 验证会不断重试这些失败的行,并限制每次报告的失败数量。但是,您可以创建完全加载仅验证任务,并更快地获得答案。

  • 您已经开发了一个数据修复脚本/实用程序,可以读取验证失败表 –(另请参阅故障排除)。完全加载仅验证任务可以快速报告故障,以便数据修复脚本处理。

有关 JSON 文件中的 ValidationSettings 任务设置的示例,请参阅任务设置示例

故障排除

验证期间,在目标端点 AWS DMS 创建一个新表:awsdms_control.awsdms_validation_failures_v1。如果有任何记录进入ValidationSuspendedValidationFailed状态,则 AWS DMS 会将诊断信息写入awsdms_control.awsdms_validation_failures_v1。您可以查询该表以帮助纠正验证错误。

有关在目标上更改所创建表的默认架构的信息,请参阅控制表任务设置

以下是 awsdms_control.awsdms_validation_failures_v1 表描述:

列名称 数据类型 描述

TASK_NAME

VARCHAR(128) NOT NULL

AWS DMS 任务标识符。

TABLE_OWNER VARCHAR(128) NOT NULL

表的架构 (所有者)。

TABLE_NAME

VARCHAR(128) NOT NULL

表名称。

FAILURE_TIME DATETIME(3) NOT NULL

发生失败的时间。

KEY_TYPE VARCHAR(128) NOT NULL

保留供将来使用(值始终为“Row”)

KEY TEXT NOT NULL

这是行记录类型的主键。

FAILURE_TYPE VARCHAR(128) NOT NULL

验证错误的严重性。可以是 RECORD_DIFFMISSING_SOURCEMISSING_TARGET

DETAILS VARCHAR(8000) NOT NULL

与给定键不匹配的所有源/目标列值的 JSON 格式的字符串。

以下是 MySQL 目标的示例查询,它将通过查询awsdms_control.awsdms_validation_failures_v1表向您显示任务的所有失败。请注意,架构名称和查询语法因目标引擎版本而异。任务名称应该是任务的外部资源 ID。任务的外部资源 ID 是任务 ARN 中的最后一个值。例如,对于 ARN 值为 arn:aws:dms:us-west-2:5599:task: VFPFKH4FJR3FTYKK2RYSI 的任务,任务的外部资源 ID 为 VFPFKH4FJR3FTYKK2RYSI。

select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],]

您可以查看 DETAILS 字段以确定哪些列不匹配。由于您已知失败记录的主键,您可以查询源和目标终端节点以查看记录的哪个部分不匹配。

Redshift 验证性能

Amazon Redshift 在多个方面与关系数据库不同,包括列式存储、MPP、数据压缩和其他因素。这些差异使 Redshift 具有与关系数据库不同的性能特征。

在完全加载复制阶段,验证使用范围查询,数据大小由 PartitionSize 设置控制。这些基于范围的查询会选择源表中的所有记录。

对于正在进行的复制,查询会在基于范围的提取和单个记录提取之间切换。查询类型是根据多个因素动态确定的,例如:

  • 查询量

  • 源表上的 DML 查询类型

  • 任务延迟

  • 记录总数

  • 验证设置,例如 PartitionSize

由于验证查询,您可能会在 Amazon Redshift 集群上看到额外的负载。由于上述因素因用例而异,因此您必须检查验证查询性能,并相应地调整集群和表。一些缓解性能问题的方案包括:

  • 减小 PartitionSizeThreadCount 设置以帮助减少完全加载验证期间的工作量。请注意,这将减慢数据验证的速度。

  • 虽然 Redshift 不强制使用主键,但 AWS DMS 它依靠主键来唯一标识目标上的记录以进行数据验证。如果可能,请将主键设置为镜像排序键,以便更快地执行完全加载验证查询。

限制

  • 数据验证要求表具有主键或唯一索引。

    • 主键列不能是 CLOBBLOBBYTE 类型。

    • 对于 VARCHARCHAR 类型的主键列,长度必须小于 1024。您必须在数据类型中指定长度。您不能使用无界数据类型作为数据验证的主键。

    • 使用 NOVALIDATE 子句创建的 Oracle 键不被视为主键或唯一索引。

    • 对于没有主键且只有唯一键的 Oracle 表,具有唯一约束条件的列也必须具有 NOT NULL 约束条件。

  • 不支持验证 NULL PK/UK 值。

  • 如果目标 PostgreSQL 实例中的主键列的排序规则未设置为“C”,则与 Oracle 中的排序顺序相比,PostgreSQL 的主键的排序顺序将不同。如果 PostgreSQL 和 Oracle 的排序顺序不同,数据验证将无法验证记录。

  • 数据验证将针对源和目标数据库生成额外的查询。您必须确保两个数据库具有足够的资源以处理该额外负载。对于 Redshift 目标而言尤其如此。有关更多信息,请参阅下面的Redshift 验证性能

  • 将几个数据库合并为一个数据库时,不支持数据验证。

  • 对于源或目标 Oracle 端点, AWS DMS 使用 DBMS_CRYPTO 来验证 LOB。如果 Oracle 终端节点使用 LOB,则必须为用于访问 Oracle 终端节点的用户账户授予 dbms_crypto 执行权限。您可以运行以下语句以执行该操作:

    grant execute on sys.dbms_crypto to dms_endpoint_user;
  • 如果在校验 AWS DMS 期间之外修改了目标数据库,则可能无法准确报告差异。如果您的一个应用程序向目标表写入数据,同时对同一个表执行验证, AWS DMS 则会出现此结果。

  • 如果在验证期间不断修改一行或多行,则 AWS DMS 无法验证这些行。

  • 如果 AWS DMS 检测到超过 10,000 条失败或暂停的记录,则会停止验证。在继续之前,先解决数据的任何根本问题。

  • AWS DMS 不支持视图的数据验证。

  • AWS DMS 使用字符替换任务设置时不支持数据验证。

  • AWS DMS 不支持验证 Oracle LONG 类型。

  • AWS DMS 不支持在异构迁移期间验证 Oracle Spatial 类型。

有关使用 S3 目标验证的限制,请参阅使用 S3 目标验证的限制