本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # AWS DMS 数据验证 **Topics** + [复制任务统计数据](#CHAP_Validating.TaskStatistics) + [使用 Amazon 进行复制任务的统计数据 CloudWatch](#CHAP_Validating.TaskStatistics.CloudWatch) + [在任务期间重新验证表](#CHAP_Validating.Revalidating) + [使用 JSON 编辑器修改验证规则](#CHAP_Validating.JSONEditor) + [仅验证任务](#CHAP_Validating.ValidationOnly) + [问题排查](#CHAP_Validating.Troubleshooting) + [Redshift 验证性能](#CHAP_Validating.Redshift) + [增强的数据验证功能 AWS Database Migration Service](#CHAP_Validating_Enhanced) + [限制](#CHAP_Validating.Limitations) + [Amazon S3 目标数据验证](CHAP_Validating_S3.md) + [AWS DMS 数据重新同步](CHAP_Validating.DataResync.md) 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 目标数据验证](CHAP_Validating_S3.md)。 有关支持的终端节点的更多信息，请参阅[使用 AWS DMS 终端节点](CHAP_Endpoints.md)。 除了迁移本身所需的时间以外，数据验证还需要占用额外的时间。所需的额外时间取决于迁移的数据量。 有关这些设置的更多信息，请参阅 [数据验证任务设置](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)。 有关 JSON 文件中的 `ValidationSettings` 任务设置的示例，请参阅[任务设置示例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)。 ## 复制任务统计数据 启用数据验证后，将在表级别 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` 任务设置的示例，请参阅[任务设置示例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)。 您可以使用控制台 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. 从**数据库迁移任务**页面选择任务。 1. 选择 “**CloudWatch 指标**” 选项卡。 1. 从下拉菜单中选择**验证**。 ## 在任务期间重新验证表 在任务运行时，您可以请求 AWS DMS 执行数据验证。 ### AWS 管理控制台 1. 登录 AWS 管理控制台 并在 [https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2/)/上打开 AWS DMS 控制台。 如果您以 AWS Identity and Access Management (IAM) 用户身份登录，请确保您拥有相应的访问权限 AWS DMS。所需权限，请参阅[使用所需的 IAM 权限 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions)。 1. 从导航窗格中选择**任务**。 1. 选择具有要重新验证的表的正在运行的任务。 1. 选择**表统计数据**选项卡。 1. 选择您要重新验证的表（一次最多可选择 10 个表）。如果任务不再运行，则您无法重新验证该表。 1. 选择 **Revalidate (重新验证)**。 ## 使用 JSON 编辑器修改验证规则 要使用 AWS DMS 控制台中的 JSON 编辑器向任务添加验证规则，请执行以下操作： 1. 选择**数据库迁移任务**。 1. 从迁移任务列表中选择您的任务。 1. 如果您的任务正在运行，请从**操作**下拉菜单中选择**停止**。 1. 任务停止后，要修改您的任务，请从**操作**下拉菜单中选择**修改**。 1. 在**表映射**部分，选择 **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}" } ``` **注意** 如果该列是主键的一部分，则 `override-validation-function` 不会生效。 ## 仅验证任务 您可以创建仅验证的任务来预览和验证数据，而无需执行任何迁移或数据复制。要创建仅验证的任务，请将 `EnableValidation` 和 `ValidationOnly` 设置设为 `true`。启用 `ValidationOnly` 后，还需要满足其他要求。有关更多信息，请参阅 [数据验证任务设置](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)。 在报告许多故障时，对于仅完全加载的迁移类型，仅验证任务的完成速度要比其 CDC 的等同验证任务快得多。但是，对源端点或目标端点的更改会被报告为完全加载模式失败，这可能是一个缺点。 CDC 仅验证任务会根据平均延迟来延迟验证，并在报告失败之前多次重试失败的验证。如果大多数数据比较都导致失败，那么 CDC 模式的仅验证任务会非常缓慢，这可能是一个不利之处。 仅验证的任务必须与复制任务的方向设置相同，尤其是对于 CDC。这是因为 CDC 仅验证任务会根据源上的更改日志，检测哪些行已更改并需要重新验证。如果目标被指定为源，则它只知道 DMS 发送给目标的更改，不能保证捕获复制错误。 ### 完全加载仅验证 从 3.4.6 及更高 AWS DMS 版本开始，仅限满载验证的任务一次性快速比较源表和目标表中的所有行，立即报告任何故障，然后关闭。在此模式下针对速度进行了优化，验证永远不会因为失败而暂停。但是，对源端点或目标端点的更改会被报告为失败。 **注意** 从 3.4.6 及更高 AWS DMS 版本开始，此验证行为也适用于启用验证的满负荷迁移任务。 ### 仅 CDC 验证 仅 CDC 验证的任务会在全新开始时，在源表和目标表之间验证所有现有行。此外，仅 CDC 验证的任务会持续运行，重新验证正在进行的复制更改，限制每次验证报告的失败次数，并在失败之前重试不匹配的行。它经过优化，可以防止误报。 如果超过 ` FailureMaxCount` 或 `TableFailureMaxCount` 的阈值，则会暂停对表（或整个任务）的验证。这也适用于启用了验证的 CDC 或完全加载\$1CDC 迁移任务。而且，启用了验证的 CDC 任务会根据平均源和目标延迟，来延迟对每行更改的重新验证。 但是，CDC *仅验证任务*不会迁移数据，也没有延迟。默认情况下，它将 `ValidationQueryCdcDelaySeconds` 设置为 180。而且，您可以增加容量以应对高延迟环境，并帮助防止误报。 ### 仅验证的使用案例 在迁移或复制任务中，将数据验证部分拆分为单独的*仅验证任务*的使用案例包括但不限于以下内容： + *精确控制何时进行验证* – 验证查询会给源端点和目标端点增加额外的负载。因此，先在一项任务中迁移或复制数据，然后在另一项任务中验证结果会有所帮助。 + *减少复制实例的负载* – 将数据验证拆分为在自己的实例上运行可能很有好处。 + *快速获取在给定时刻有多少行不匹配* – 例如在维护时段，进行生产切换到目标端点之前或期间，您可以创建一个完全加载仅验证任务来获取问题的答案。 + *当使用 CDC 组件的迁移任务预计会出现验证失败时* – 例如，如果将 Oracle `varchar2` 迁移到 PostgreSQL `jsonb`，CDC 验证会不断重试这些失败的行，并限制每次报告的失败数量。但是，您可以创建完全加载仅验证任务，并更快地获得答案。 + *您已经开发了一种 script/utility 可以读取验证失败表的数据修复工具* —（另请参阅，[问题排查](#CHAP_Validating.Troubleshooting)）。完全加载仅验证任务可以快速报告故障，以便数据修复脚本处理。 有关 JSON 文件中的 `ValidationSettings` 任务设置的示例，请参阅[任务设置示例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)。 ## 问题排查 验证期间，在目标端点 AWS DMS 创建一个新表：`awsdms_control.awsdms_validation_failures_v1`。如果有任何记录进入*ValidationSuspended*或*ValidationFailed*状态，则 AWS DMS 会将诊断信息写入`awsdms_control.awsdms_validation_failures_v1`。您可以查询该表以帮助纠正验证错误。 有关在目标上更改所创建表的默认架构的信息，请参阅[控制表任务设置](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md)。 以下是 `awsdms_control.awsdms_validation_failures_v1` 表描述： | 列名称 | 数据类型 | 说明 | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS 任务标识符。 | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | 表的架构 (所有者)。 | | `TABLE_NAME` | VARCHAR(128) NOT NULL | 表名称。 | | FAILURE\$1TIME | DATETIME(3) NOT NULL | 发生失败的时间。 | | KEY\$1TYPE | VARCHAR(128) NOT NULL | 保留供将来使用（值始终为“Row”） | | KEY | TEXT NOT NULL | 这是行记录类型的主键。 | | FAILURE\$1TYPE | VARCHAR(128) NOT NULL | 验证错误的严重性。可以是 `RECORD_DIFF`、`MISSING_SOURCE`、`MISSING_TARGET` 或 `TABLE_WARNING`。 | | DETAILS | VARCHAR(8000) NOT NULL | JSON 格式的字符串，包含与给定键不匹配的所有 source/target 列值。 | 通过查询 `awsdms_control.awsdms_validation_failures_v1` 表，以下针对 MySQL 目标的示例查询显示任务的所有失败。请注意，架构名称和查询语法因目标引擎版本而异。任务名称应该是任务的外部资源 ID。任务的外部资源 ID 是任务 ARN 中的最后一个值。例如，对于 ARN 值为 arn: aws: dms: us-west-2:5599: task: RYSI 的任务，该任务的外部资源 ID 将是 RYSI。 VFPFKH4 FJR3 FTYKK2 VFPFKH4 FJR3 FTYKK2 ``` 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` 字段以确定哪些列不匹配。由于您已知失败记录的主键，您可以查询源和目标终端节点以查看记录的哪个部分不匹配。 ### `awsdms_validation_failures_v2` 控制表 在验证期间，在 3.6.1 及更高 AWS DMS 版本中，DMS 在 PostgreSQL 目标端点创建了一个新表：。`awsdms_validation_failures_v2`此表包含所有启用了数据验证的 DMS 任务的失败情况。创建 `awsdms_validation_failures_v2` 表时，不应删除或截断该表，因为这可能会导致任何启用了验证和重新同步的任务出错。`awsdms_validation_failures_v2` 表具有自动递增主键功能。此表由支持数据重新同步功能的新列组成。它们是： `RESYNC_RESULT` **值**：`SUCCESS` 或 `FAILURE`。 **`RESYNC_TIME`** 时间戳，精确到毫秒。如果此失败未尝试重新同步数据，则默认值为 `NULL`。 **`RESYNC_ACTION`** **值**：`UPSERT` 或 `DELETE`。 `RESYNC_ID` 启用了自动递增的主键列。 在 `awsdms_validation_failures_v2` 表中，将索引添加到 `TASK_NAME`、`TABLE_OWNER`、`TABLE_NAME`、`FAILURE_TYPE` 和 `FAILURE_TIME` 列中，以便有效地读取目标数据库中任意给定表的失败情况。以下是创建 `awsdms_validation_failures_v2` 表的 create 语句示例： ``` CREATE TABLE public.awsdms_validation_failures_v2 ( "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL, CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID") ); ``` ## Redshift 验证性能 Amazon Redshift 在多个方面与关系数据库不同，包括列式存储、MPP、数据压缩和其他因素。这些差异使 Redshift 具有与关系数据库不同的性能特征。 在完全加载复制阶段，验证使用范围查询，数据大小由 `PartitionSize` 设置控制。这些基于范围的查询会选择源表中的所有记录。 对于正在进行的复制，查询会在基于范围的提取和单个记录提取之间切换。查询类型是根据多个因素动态确定的，例如： + 查询量 + 源表上的 DML 查询类型 + 任务延迟 + 记录总数 + 验证设置，例如 `PartitionSize` 由于验证查询，您可能会在 Amazon Redshift 集群上看到额外的负载。由于上述因素因用例而异，因此您必须检查验证查询性能，并相应地调整集群和表。一些缓解性能问题的方案包括： + 减小 `PartitionSize` 和 `ThreadCount` 设置以帮助减少完全加载验证期间的工作量。请注意，这将减慢数据验证的速度。 + 虽然 Redshift 不强制使用主键，但 AWS DMS 它依靠主键来唯一标识目标上的记录以进行数据验证。如果可能，请将主键设置为镜像排序键，以便更快地执行完全加载验证查询。 ## 增强的数据验证功能 AWS Database Migration Service AWS Database Migration Service 增强了数据库迁移的数据验证性能，使客户能够以更快的处理时间验证大型数据集。这种增强的数据验证功能现已在 3.5.4 版复制引擎中提供，适用于完全加载以及带 CDC 的完全加载这两种迁移任务。目前，此增强功能支持从 Oracle 到 PostgreSQL、SQL Server 到 PostgreSQL、Oracle 到 Oracle 以及 SQL Server 到 SQL Server 的迁移路径，并计划在未来的版本中增加迁移路径。 ### 先决条件 + *Oracle：*会向用于访问 Oracle 端点的用户账户授予对 `SYS.DBMS_CRYPTO` 的 `EXECUTE` 权限： ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + 在 PostgreSQL 数据库上安装 `pgcrypto` 扩展： 对于自管理 PostgreSQL 实例，您需要安装 `contrib` 模块库并创建扩展： + 安装 `contrib` 模块库。例如，在装有 Amazon Linux 和 PostgreSQL 15 的 Amazon EC2 实例上： ``` sudo dnf install postgresql15-contrib ``` + 创建 `pgcrypto` 扩展： ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + 对于 Amazon RDS for PostgreSQL 实例，请为终端节点配置 SSL 模式： AWS DMS + 默认情况下，Amazon RDS 强制建立 SSL 连接。在为亚马逊 RDS for PostgreSQL 实例创建 AWS DMS 终端节点时，请使用 “SSL 模式” 选项 = “必需”。 + 如果要使用“SSL 模式”选项 =“无”，请在 RDS 参数组中将 `rds.force_ssl` 参数设置为 0。 + 对于 PostgreSQL 12 和 13，请创建 `BIT_XOR` 聚合： ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### 增强数据验证限制 此增强数据验证功能具有以下限制： + 数据库端点要求：此改进仅适用于满足以下条件的数据库端点： + AWS Secrets Manager 用于存储凭据。 + 对于 Microsoft SQL Server，还支持 Kerberos 身份验证。 + 数据库版本支持： + PostgreSQL 12 及更高版本 + Oracle 12.1 及更高版本 + 对于 2019 年以下的 Microsoft SQL Server 版本，不支持验证 NCHAR 和 NVARCHAR 数据类型。 ## 限制 + 数据验证要求表具有主键或唯一索引。 + 主键列不能是 `CLOB`、`BLOB`、`BINARY` 或 `BYTE` 类型。 + 对于 `VARCHAR` 或 `CHAR` 类型的主键列，长度必须小于 1024。您必须在数据类型中指定长度。您不能使用无界数据类型作为数据验证的主键。 + 使用 `NOVALIDATE` 子句创建的 Oracle 键*不被*视为主键或唯一索引。 + 对于没有主键且只有唯一键的 Oracle 表，具有唯一约束条件的列也必须具有 `NOT NULL` 约束条件。 + 不支持对 NULL PK/UK 值进行验证。 + 如果目标 PostgreSQL 实例中的主键列的排序规则未设置为“C”，则与 Oracle 中的排序顺序相比，PostgreSQL 的主键的排序顺序将不同。如果 PostgreSQL 和 Oracle 的排序顺序不同，数据验证将无法验证记录。 + 数据验证将针对源和目标数据库生成额外的查询。您必须确保两个数据库具有足够的资源以处理该额外负载。对于 Redshift 目标而言尤其如此。有关更多信息，请参阅下面的[Redshift 验证性能](#CHAP_Validating.Redshift)。 + 将几个数据库合并为一个数据库时，不支持数据验证。 + 对于源或目标 Oracle 终端节点， AWS DMS 使用`DBMS_CRYPTO`。如果您在 Oracle 端点上使用数据验证，则必须为用于访问 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 类型。 + 数据验证会忽略表中那些在表映射中存在数据掩蔽转换的列。 + 如果整个表的列有数据屏蔽转换规则，则数据验证会跳过整个表。 PK/UK 此类表的验证状态将显示为无主键。 + 数据验证不适用于 Amazon Aurora PostgreSQL Limitless。尝试验证 Limitless Database 中的表时，这些表的验证状态显示为“无主键”。 有关使用 S3 目标验证的限制，请参阅[使用 S3 目标验证的限制](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations)。 # Amazon S3 目标数据验证 AWS DMS 支持验证 Amazon S3 目标中复制的数据。由于复制的数据以平面文件形式 AWS DMS 存储在 Amazon S3 中，因此我们使用 [Amazon A](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) t `CREATE TABLE AS SELECT` hena (CTAS) 查询来验证数据。 对存储在 Amazon S3 中的数据进行查询的计算量很大。因此，在更改数据捕获 (CDC) 期间，每天仅在世界标准时间午夜 (00:00) 对 Amazon S3 数据 AWS DMS 运行一次验证。 AWS DMS 运行的每项每日验证都称为间*隔验证*。在间隔验证期间， AWS DMS 验证过去 24 小时内迁移到目标 Amazon S3 存储桶的所有更改记录。有关间隔验证限制的更多信息，请参阅[使用 S3 目标验证的限制](#CHAP_Validating_S3_limitations)。 Amazon S3 目标验证使用 Amazon Athena，因此需要支付额外费用。有关更多信息，请参阅 [Amazon Athena 定价](https://aws.amazon.com/athena/pricing/)。 **注意** S3 目标验证需要 AWS DMS 版本 3.5.0 或更高版本。 **Topics** + [先决条件](#CHAP_Validating_S3_prerequisites) + [Permissions](#CHAP_Validating_S3_permissions) + [限制](#CHAP_Validating_S3_limitations) + [仅验证任务](#CHAP_Validating_S3_only) ## S3 目标验证先决条件 在使用 S3 目标验证之前，请检查以下设置和权限： + 将端点的 [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) 的 `DataFormat` 值设置为 `parquet`。有关更多信息，请参阅 [S3 的 Parquet 设置](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet)。 + 确保向用于创建迁移任务的用户账户分配的角色具有以下一系列权限。参见下文中的[Permissions](#CHAP_Validating_S3_permissions)。 对于使用持续复制（CDC）的任务，请检查以下设置： + 启用补充日志，这样您就可获得 CDC 数据的完整记录。有关启用补充日志记录的信息，请参阅本指南[故障排除和诊断支持排除延迟问题](CHAP_Troubleshooting.md)部分中的[自动将补充日志记录添加到 Oracle 源端点](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging)。 + 为目标端点设置 `TimestampColumnName` 参数。对时间戳列名没有限制。有关更多信息，请参阅 [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html)。 + 为目标设置基于日期的文件夹分区。有关更多信息，请参阅 [使用基于日期的文件夹分区](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning)。 ## 使用 S3 目标验证的权限 要设置访问权限以使用 S3 目标验证，请确保向用于创建迁移任务的用户账户分配的角色具有以下一系列权限。请将示例值替换为您的值。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:CreateWorkGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetTables", "glue:CreateTable", "glue:DeleteTable", "glue:GetTable" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] } ``` ------ ## 使用 S3 目标验证的限制 查看使用 S3 目标验证时适用的以下其他限制。有关适用于所有验证的限制，请参阅[限制](CHAP_Validating.md#CHAP_Validating.Limitations)。 + 您的 `DatePartitionSequence` 值需要一个 Day 组件。S3 目标验证不支持 `YYYYMM` 格式。 + 在 CDC 期间运行间隔验证时，您可能会在 `awsdms_validation_failures_v1` 表中看到虚假的验证错误。之所以出现这些错误，是因为会将间隔验证期间收到的更改 AWS DMS 迁移到第二天的分区文件夹中。通常，这些更改会写入当天的分区文件夹。这些虚假错误限制了对从动态源数据库复制到静态目标（例如 Amazon S3）的验证。要调查这些虚假错误，请检查验证时段（00:00 UTC）快要结束时的记录，错误通常出现在这些时候。 要尽可能减少虚假错误的数量，请确保任务的 `CDCLatencySource` 较低。有监控延迟的信息，请参阅[复制任务指标](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task)。 + 处于 `failed` 或 `stopped` 状态的任务不验证前一天的更改。要最大限度地减少由于意外失败而导致的验证错误，请使用相同的表映射以及源端点和目标端点，创建单独的仅验证任务。有关仅验证任务的更多信息，请参阅[通过 S3 目标验证使用仅验证任务](#CHAP_Validating_S3_only)。 + 表统计数据中的**验证状态**列反映了最近一次间隔验证的状态。因此，存在不匹配的表可能会在第二天的间隔验证后显示为已验证。检查目标 Amazon S3 存储桶中的 `s3_validation_failures folder` 是否存超过一天之前发生的不匹配情况。 + S3 验证使用 Amazon Athena 的分桶表特征。这允许 S3 验证创建目标表数据的分桶副本。这意味着表数据的副本分成多个子集，这些子集与 DMS 验证的内部分区相匹配。Athena 分桶表的存储桶上限为 10 万个。S3 验证尝试验证的任何超过此限制的表都将无法通过验证。S3 验证尝试创建的存储桶数等于以下值： ``` (#records in the table) / (validation partition size setting) ``` 要解决此限制，请增加验证分区大小设置，使 S3 验证创建的存储桶数小于 10 万。有关分桶的更多信息，请参阅《Amazon Athena 用户指南》**中的[在 Athena 中进行分区和分桶](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html)。 + 表名称不得包含除下划线之外的特殊字符。 S3 验证使用 Amazon Athena，它不支持在表名中使用特殊字符（下划线除外）。有关更多信息，请参阅《Amazon Athena 用户指南》中的 [CREATE TABLE](https://docs.aws.amazon.com/athena/latest/ug/create-table.html) 主题。 + 当对由 La AWS ke Formation 管理的 Amazon S3 目标使用 AWS DMS 数据验证功能时，验证过程会失败。这可能会导致数据一致性问题。 ## 通过 S3 目标验证使用仅验证任务 *仅验证任务*在不运行迁移的情况下对要迁移的数据进行验证。 即使迁移任务停止，仅限验证的任务也会继续运行，这样可以确保 AWS DMS 不会错过 00:00 UTC 间隔验证窗口。 在 Amazon S3 目标端点上使用仅验证任务有以下限制： + 启用了仅验证设置的 Amazon S3 完全加载任务验证是受支持的，但操作方式与其他端点的完全加载和仅验证任务不同。对于作为目标的 S3，此类任务仅针对 S3 目标中的完全加载数据进行验证，不会针对作为 CDC 迁移的一部分迁移的任何数据进行验证。仅使用此功能来验证由仅完全加载任务创建的数据。使用此模式，对于正在运行 CDC 任务的目标，对其中的数据进行验证不会得到有效的验证。 + 仅验证任务仅验证自上次间隔验证窗口（00:00 UTC）以来的更改。仅验证任务不会验证前一天的完全加载数据或 CDC 数据。 # AWS DMS 数据重新同步 AWS Database Migration Service (AWS DMS) 数据重新同步可自动修复通过源数据库和目标数据库之间的数据验证发现的数据不一致性。此功能可作为现有 DMS 迁移任务的一部分，确保根据您的任务配置、连接设置、表映射和转换进行适当的更新。 数据重新同步功能的工作原理是：通过从目标数据库上的控制表读取验证失败信息，并执行相应的修复操作。当检测到不匹配时，将使用存储在失败记录中的主键从源端检索当前数据，并在遵守所配置的任何转换的同时将其应用于目标。有关更多信息，请参阅 [`awsdms_validation_failures_v2` 控制表](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table)。 行为因迁移类型而异。对于 full-load-only任务，数据重新同步将在初始加载和验证完成后运行一次。对于使用更改数据捕获（CDC）的任务，数据重新同步将根据所配置的时间表运行，在应用修复程序时会暂停复制和验证。 在 CDC 重新同步操作期间： + 复制和验证暂时暂停。 + 数据重新同步会处理现有的验证失败。 + 恢复正常复制和验证。 + 该过程将根据您配置的时间表重复执行。 数据重新同步会自动跟踪每个修复操作的状态，并通过表格统计数据提供详细的指标。 **先决条件：** 数据重新同步功能需要以下先决条件： + 您的 AWS DMS 引擎版本必须为 3.6.1 或更高版本。 + 必须为正在进行复制的任务配置计划和计时持续时间设置。仅完全加载任务不需要这些设置。 ## 限制 数据重新同步功能有以下限制： + 数据重新同步仅支持 Oracle 和 SQL Server 作为源数据库。 + 数据重新同步支持兼容 PostgreSQL 和 Amazon Aurora PostgreSQL 的引擎作为目标数据库。 + 源数据库和目标数据库中的所有表都必须有主键。验证不支持没有主键或唯一键的表。任何没有有效主键或唯一键的表都将暂停验证，并且不会报告任何验证失败。 + 运行 Full-load-only任务时，必须启用数据验证。 + 无法为仅验证任务启用数据重新同步，因为它们不会复制任何数据。您只需提供仅验证 `taskID` 即可在父复制任务上启用重新同步。有关更多信息，请参阅[仅验证任务](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly)。 + 如果“仅验证”任务在任务设置中配置了 `ControlSchema` 参数，则复制任务也必须具有相同的参数配置，数据重新同步才能找到正确的验证错误。 + 您需要配置 CDC 任务的调度和时长设置。 + 在重新同步时段，数据重新同步可能会影响 DMS 中的复制延迟。 [有关在数据重新同步 AWS DMS 期间对验证进行故障排除的更多信息，请参阅数据验证下AWS DMS 的 “[疑难解答](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting)” 部分。](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) ## 调度和计时 对于执行 CDC 的任务，您必须配置数据重新同步的时间和时长。这有助于防止影响您的正常复制操作。您需要指定： + 采用 cron 格式的调度计划，用于定义重新同步操作可执行的时间。 + 最长持续时间，以确保重新同步操作不会延长至高峰使用时段。 建议将数据重新同步操作安排在非高峰时段，或者安排在源数据库变更极少或没有变更的时间段进行。 **注意** 计划时间包括等待目标应用流变为空，因为数据重新同步和正常复制无法同时运行。 ## 使用案例 数据重新同步功能使用户能够调和源系统和目标系统之间的数据不一致问题。该功能会识别不匹配的记录并进行同步，以维持分布式环境中的数据一致性。以下使用案例演示了数据重新同步功能解决数据一致性难题的常见场景： **场景 1：完全加载任务 - 使用相同的 DMS 任务运行重新同步** 在现有的 DMS 完全加载迁移任务中，可以执行以下操作： + 启用验证：`Validation with data migration = true`。 + 启用重新同步：`Data resync = true` **场景 2：完全加载和 CDC、仅 CDC 任务 - 使用相同的 DMS 任务运行重新同步** 在现有的 DMS CDC 迁移任务中，可以执行以下操作： + 启用验证：`Validation with data migration = true`。 + 启用重新同步：`Data resync = true` + 指定重新同步时间表：`"ResyncSchedule": "0 0,2,4,6 * * *"`。 + 指定重新同步时间：`MaxResyncTime": 60` **场景 3：将完全加载和 CDC 任务，或仅 CDC 任务，用于数据复制和重新同步，并结合一个仅验证任务** 要在使用重新同步时在另一个 DMS 任务中执行仅验证操作，可以执行以下操作： + 创建仅验证 DMS CDC 任务。 **注意** 在数据重新同步期间，您必须记下并指定此任务的 ID。 + 在您的主要 CDC 任务中，禁用验证：`Data validation = false`。 + 启用重新同步：`Data resync = true` + 指定重新同步时间表：`"ResyncSchedule": "0 0,2,4,6 * * *"`。 + 指定重新同步时间：`MaxResyncTime": 60`。 + 指定仅验证 DMS CDC 任务的 ID。仅验证任务 ID 会附加在 ARN 的末尾。示例 ARN：`arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` 和仅示例验证任务 ID：`6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`。 ## 最佳实践 您可以利用中的数据重新同步功能 AWS Database Migration Service 来提高复制任务的持久性并实现一致性。使用数据重新同步功能的一些最佳做法是： + 作为数据重新同步过程的一部分，存在不匹配的记录通过从源数据库获取并应用到目标数据库来进行修复。如果在重新同步时段更新了源数据库，则重新同步会读取最新的记录值并将其应用于目标数据库。这可能会导致 CDC 应用事件失败，并在目标数据库上引入暂时的不一致问题。为避免这种情况，您必须将重新同步时段安排在非工作时间或源数据库更改为零或最小的时段。 + 在源数据库活动最少的时段和可接受的目标延迟阈值内设置重新同步时段。较小的重新同步间隔可能会导致未处理的验证不匹配项累积，而当出现许多验证失败时，较大的时段可能会增加复制延迟。监控验证失败率和重新同步率，以确定源处于非活动状态期间的最佳重新同步时段。设置重新同步时段的一些示例是： + 多个短窗口配置： ``` "ResyncSchedule": "0 0,2,4,6 * * *", "MaxResyncTime": 60 ``` + 每日单窗口配置： ``` "ResyncSchedule": "0 0 * * *", "MaxResyncTime": 360 ``` + 在重新同步窗口期间监控 DMS 中的复制延迟，并根据情况调整计划，以缓解大的延迟峰值。 + 您可以通过表统计信息或在目标数据库上查询 `awsdms_validation_failures_v2` 表来查看重新同步结果。有关更多信息，请参阅[使用 Amazon 监控复制任务 CloudWatch](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch)。 + 当任务处于持续复制阶段时，请避免在重新同步窗口期间启动对个别表的重新加载。 + CDC 复制任务的最佳实践： + 数据库中的所有表都已完成加载过程。 + 在正在进行的验证过程中发现不匹配项。 + 根据重新同步计划窗口，复制任务会暂停片刻。 + 数据重新同步修复验证过程发现的问题。 + 复制过程将按计划恢复和重复。 ## 数据重新同步配置和示例 **数据重新同步设置配置**： 您可以在 DMS 中为复制任务配置重新同步。以下是任务中数据重新同步设置配置的示例： ``` "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "0 0,2,4,6 * * *", // Run at 12AM, 2AM, 4AM, and 6AM daily "MaxResyncTime": 60, // Run for maximum of 60 minutes, or 1 hour "ValidationTaskId": "TASK-ID-IF-NEEDED" //Optional, used only if validation is performed as a separate Validation only task } ``` **常见的重新同步计划模式示例**： + `0 0 * * *`：每天午夜运行一次。 + `0 0,12 * * *`：每天午夜和中午各运行一次。 + `0 0,2,4,6, * * *`：午夜至早上 6 点之间，每两小时运行一次。 + `0 1 * * 1`：每周一凌晨 1 点运行。 **注意** 您必须为每天指定一个从 0 到 6 的数字。有关更多信息，请参阅 [Cron 表达式规则](#CHAP_DataResync.cron)。 **监视重新同步操作**： 您可以通过表统计信息监控重新同步操作。下面是一个输出示例： ``` { "TableStatistics": { ... "ValidationFailedRecords": 1000, ... "ResyncRowsAttempted": 1000, "ResyncRowsSucceeded": 995, "ResyncRowsFailed": 5, "ResyncProgress": 99.5, // ratio of ResyncRowsSucceeded/ValidationFailedRecords "ResyncState": "Last resync at: 2024-03-14T06:00:00Z" } } ``` 要在中配置数据重新同步功能 AWS DMS，您可以查看各种重新同步参数及其各自的配置设置。有关更多信息，请参阅 [数据重新同步设置](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md)。有关数据重新同步日志设置的更多信息，请参阅[日志记录任务设置](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md)。 ## 验证和故障排除 **验证**： 启用数据评估后， AWS DMS 将在目标数据库中创建一个结构如下所示的验证失败表： ``` CREATE TABLE awsdms_validation_failures_v2 ( "RESYNC_ID" bigint NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL ); ``` 您可以向此表写入一个查询，以了解发现的数据不匹配项以及如何解决它们。 启用校验后， AWS DMS 将在目标数据库中创建校验失败表。如果您有任何问题，可以查询 `awsdms_control.awsdms_validation_failures_v2` 表以了解发现的数据不匹配项以及如何解决它们。有关更多信息，请参阅 [AWS DMS 数据验证](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)中的[故障排除](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting)部分。 **常见工作流程**： 在数据重新同步中进行验证期间，标准工作流程如下： **仅完全加载任务**： 1. 数据库中的所有表都已完成加载过程。 1. 在正在进行的验证过程中发现不匹配项。 1. 数据重新同步修复验证过程发现的问题。 1. 验证过程对更正进行验证。 1. 迁移任务已成功完成。 **CDC 任务**： 1. 数据库中的所有表都已完成加载过程。 1. 在正在进行的验证过程中发现不匹配项。 1. 根据重新同步计划窗口，复制任务会暂停片刻。 1. 数据重新同步修复验证过程发现的问题。 1. 复制过程将按计划恢复和重复。 对任务所做的任何修改（例如在重新同步操作期间停止复制任务，或重新加载和重新验证表）都可能影响任务的行为和结果。一些已知的行为变化如下： **当您在重新同步操作进行期间停止复制任务时**： + 重新同步操作不会自动恢复。必须重新启动它。 + 将来的重新同步操作将按照配置的时间表进行。 + 所有未完成的修复都将在下一个重新同步计划窗口中尝试。 **当您在数据库中重新加载表时**： + 重新同步操作会跳过任何正在重新加载的表。 + 对于已重新加载的表，之前的验证失败将被忽略。 + 新的验证将在重新加载操作完成后开始。 **当您重新验证数据库中的表时**： + 重新同步操作的所有统计数据都将被重置。 + 对于已重新验证的表，之前的验证失败将被忽略。 **注意** 将任务升级或移动到 DMS 版本 3.6.1 及更高版本时，`awsdms_control.awsdms_validation_failures_v1` 表中的任何失败都不会重新同步。只有 `awsdms_validation_failures_v2` 表中的故障才会被重新同步。要在 `awsdms_control.awsdms_validation_failures_v2` 表中重新同步失败，必须重新加载任务、重新加载任务中的一个或多个表，或者重新验证一个或多个表。有关更多信息，请参阅以下链接： 要重新加载任务，请参阅 [`StartReplicationTask` API 参考](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html)。 要在任务中重新加载一个或多个表，请参阅 *AWS CLI 命令参考*文档中的 [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)。 要重新验证一个或多个表，请参阅 *AWS CLI 命令参考*文档 [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html) 一节中的 `validate-only` 选项。 . ## Cron 表达式规则 要在中配置复制任务期间的数据重新同步操作， AWS DMS 可以使用 cron 表达式规则。这些规则允许您自定义重新同步的时间窗口，并根据业务需求进行安排。您可以使用各种参数，例如分钟、小时、天、月和星期几。每个参数的 cron 表达式规则为： **分钟**： + 分钟范围为 0 到 59。 + 可以使用（`-`）、`or`/`and` 来指定范围。最多 10 个项目，用逗号（`,`）分隔。 + **示例：** + `2-5` 等于 `2,3,5,5`。 + `1-2,3-4,5,7-10` 是有效范围。 + `1,2,3,4,5,6,7,8,9,10` 是有效范围。 + `1,2,3,4,5,6,7,8,9,10,11` 不是有效范围。在第 10 个范围项之后会跳过重新同步操作。 + 您可以使用（`*`）。示例：`*` 等于 `0-59`。 + 只能将（`/`）与（`-`）或（`*`）结合使用。 **示例：** + `2-7/2` 等于 `2,4,6`。 + `*/15` 等于 `0,15,30,45`。 **时间**： 与“**分钟**”相同，但有效范围是从 `0` 到 `23`。 **天**： + 与“**分钟**”相同，但有效范围是从 `1` 到 `31`。 + 在重新同步配置中支持使用 `L`。它被解释为当月的最后一天。不得将其与其他语法结合使用。 **月**: 与“**分钟**”相同，但有效范围是从 `1` 到 `12`。 **星期几**： + 与“**分钟**”相同，但有效范围是从 `0` 到 `6`。 + 您不能为周名添加字符串值。