AWS dms documentation change
Summary
Added documentation for the 'awsdms_validation_failures_v2' control table in PostgreSQL targets, including schema details and usage notes for data resync functionality
Security assessment
The change introduces documentation for a new validation failure tracking table and data resync features, but there is no evidence of addressing a security vulnerability or describing security-specific capabilities. The changes focus on data validation mechanics and operational guidance.
Diff
diff --git a/dms/latest/userguide/CHAP_Validating.md b/dms/latest/userguide/CHAP_Validating.md index 94f38dd6f..978938805 100644 --- a//dms/latest/userguide/CHAP_Validating.md +++ b//dms/latest/userguide/CHAP_Validating.md @@ -30,0 +31,2 @@ Replication task statisticsReplication task statistics with Amazon CloudWatchRev + * [AWS DMS data resync](./CHAP_Validating.DataResync.html) + @@ -282 +284 @@ A CDC validation only task delays validation based on average latency, and retri -A validation-only task must be set up in the same direction as the replication task, especially for CDC. This is because a CDC Validation Only task detects which rows have changed and need to be revalidated based on the change log on the source. If the target is specified as the source, then it only knows about changes sent to the target by DMS and is not guaranteed to catch replication errors. +A validation only task must be set up in the same direction as the replication task, especially for CDC. This is because a CDC Validation Only task detects which rows have changed and need to be revalidated based on the change log on the source. If the target is specified as the source, then it only knows about changes sent to the target by DMS and is not guaranteed to catch replication errors. @@ -355,0 +358,43 @@ You can look at the `DETAILS` field to determine which columns don’t match. Si +### `awsdms_validation_failures_v2` control table + +During validation, in AWS DMS version 3.6.1 and above, DMS creates a new table at the PostgreSQL target endpoint: `awsdms_validation_failures_v2`. This tables consists of failures for all the DMS tasks that have data validation enabled. When the `awsdms_validation_failures_v2` table is created, you should not drop or truncate the table as it can cause errors for any tasks with validation and resync enabled. `awsdms_validation_failures_v2` table has an auto-increment primary key feature. This table consists of new columns to support the Data resync feature. They are: + +`**RESYNC_RESULT**` + + +**Values** : `SUCCESS` or `FAILURE`. + +**`RESYNC_TIME`** + + +Timestamp with millisecond precision. Default value is `NULL` if Data resync is not attempted for this failure. + +**`RESYNC_ACTION`** + + +**Values** : `UPSERT` or `DELETE`. + +`**RESYNC_ID**` + + +Primary key column with auto-increment enabled. + +In the `awsdms_validation_failures_v2` table, an index is added to the `TASK_NAME`, `TABLE_OWNER`, `TABLE_NAME`, `FAILURE_TYPE`, and `FAILURE_TIME` columns to efficiently read failures for any given table in your target database. Below is an example create statement to create an `awsdms_validation_failures_v2` table: + + + 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") + ); +