Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # AWS Validación de datos DMS **Topics** + [Estadísticas de la tarea de replicación](#CHAP_Validating.TaskStatistics) + [Estadísticas de tareas de replicación con Amazon CloudWatch](#CHAP_Validating.TaskStatistics.CloudWatch) + [Volver a validar tablas durante una tarea](#CHAP_Validating.Revalidating) + [Uso del editor JSON para modificar las reglas de validación](#CHAP_Validating.JSONEditor) + [Tareas exclusivas de validación](#CHAP_Validating.ValidationOnly) + [Resolución de problemas](#CHAP_Validating.Troubleshooting) + [Rendimiento de validación de Redshift](#CHAP_Validating.Redshift) + [Validación de datos mejorada para AWS Database Migration Service](#CHAP_Validating_Enhanced) + [Limitaciones](#CHAP_Validating.Limitations) + [Validación de datos de destino de Amazon S3](CHAP_Validating_S3.md) + [AWS DMS resincronización de datos](CHAP_Validating.DataResync.md) AWS DMS proporciona soporte para la validación de datos para garantizar que los datos se hayan migrado con precisión del origen al destino. Si está habilitada, la validación comienza inmediatamente después de que se haya realizado la carga completa de una tabla. La validación compara los cambios incrementales de una tarea habilitada para CDC a medida que se producen. Durante la validación de los datos, AWS DMS compara cada fila del origen con la fila correspondiente del destino, comprueba que las filas contienen los mismos datos e informa de cualquier discrepancia. Para ello, realiza AWS DMS las consultas adecuadas para recuperar los datos. Tenga en cuenta que estas consultas consumirán recursos adicionales en el origen y el destino, así como recursos de red adicionales. Para una tarea exclusiva de CDC con la validación habilitada, todos los datos preexistentes de una tabla se validan antes de iniciar la validación de los nuevos datos. La validación de datos funciona con las siguientes bases de datos de origen siempre que las AWS DMS admita como puntos finales de origen: + Oracle + Base de datos compatible con PostgreSQL (PostgreSQL, Aurora PostgreSQL o Aurora sin servidor para PostgreSQL) + Base de datos compatible con MySQL (MySQL, MariaDB, Aurora MySQL o Aurora sin servidor para MySQL) + Microsoft SQL Server + IBM Db2 LUW La validación de datos funciona con las siguientes bases de datos de destino siempre que las AWS DMS respalde como puntos finales de destino: + Oracle + Base de datos compatible con PostgreSQL (PostgreSQL, Aurora PostgreSQL o Aurora sin servidor para PostgreSQL) + Base de datos compatible con MySQL (MySQL, MariaDB, Aurora MySQL o Aurora sin servidor para MySQL) + Microsoft SQL Server + IBM Db2 LUW + Amazon Redshift + Amazon S3. Para obtener información sobre la validación de los datos de destino de Amazon S3, consulte [Validación de datos de destino de Amazon S3](CHAP_Validating_S3.md). Para obtener más información acerca de los puntos de enlace admitidos, consulte [Trabajar con puntos finales AWS de DMS](CHAP_Endpoints.md). La validación de datos requiere más tiempo, más allá de la cantidad necesaria para la migración en sí. El tiempo extra necesario depende de la cantidad de datos que se ha migrado. Para obtener más información sobre estas opciones, consulte [Configuración de tareas de validación de datos](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). Para ver un ejemplo de la configuración de tareas de `ValidationSettings` en un archivo JSON, consulte [Ejemplo de configuración de tarea](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). ## Estadísticas de la tarea de replicación Cuando la validación de datos está habilitada, AWS DMS proporciona las siguientes estadísticas a nivel de tabla: + **ValidationState**—El estado de validación de la tabla. El parámetro puede tener los siguientes valores: + **Not enabled**: la validación no está habilitada para la tabla en la tarea de migración. + **Pending records**: algunos registros en la tabla están a la espera de validación. + **Discrepancia en los registros**: algunos registros de la tabla no coinciden entre origen y destino. Se puede producir una discrepancia por varios motivos. Para obtener más información, consulte la tabla `awsdms_control.awsdms_validation_failures_v1` en el punto de enlace de destino. + **Suspended records** (Registros suspendidos): no se han podido validar algunos registros de la tabla. + **No primary key** (No hay clave principal): no se ha podido validar la tabla porque no tenía clave principal. + **Table error** (Error de tabla): la tabla no se ha validado porque estaba en un estado de error y no se han migrado algunos datos. + **Validada**: se han validado todas las filas de la tabla. Si se actualiza la tabla, el estado puede cambiar de Validated. + **Error**: no se ha podido validar la tabla debido a un error inesperado. + **Validación pendiente**: la tabla está pendiente de validación. + **Preparación de la tabla**: preparación de la tabla habilitada en la tarea de migración para su validación. + **Revalidación pendiente**: todas las filas de la tabla están pendientes de validación tras la actualización de la tabla. + **ValidationPending**—El número de registros que se han migrado al destino, pero que aún no se han validado. + **ValidationSuspended**—La cantidad de registros que no AWS DMS se pueden comparar. Por ejemplo, si un registro del origen se actualiza constantemente, no AWS DMS se puede comparar el origen y el destino. + **ValidationFailed**—El número de registros que no pasaron la fase de validación de datos. Para ver un ejemplo de la configuración de tareas de `ValidationSettings` en un archivo JSON, consulte [Ejemplo de configuración de tarea](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). Puede ver la información de validación de datos mediante la consola AWS CLI, la AWS DMS API o la consola. + En la consola, puede elegir validar una tarea cuando crea o modifica la tarea. Para ver el informe de validación de datos mediante la consola, elija la tarea en la página **Tasks** y seleccione la pestaña **Table statistics** en la sección de detalles. + Con la CLI, establezca el parámetro `EnableValidation` en `true` al crear o modificar una tarea para iniciar la validación de datos. En el siguiente ejemplo se crea una tarea y permite la validación de datos. ``` 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"}]}' ``` Utilice el comando `describe-table-statistics` para recibir el informe de validación de datos en formato JSON. El siguiente comando muestra el informe de validación de datos. ``` aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q ``` El informe debería ser similar al siguiente. ``` { "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 } } ``` + Con la AWS DMS API, cree una tarea mediante la **CreateReplicationTask**acción y establezca el `EnableValidation` parámetro en **true** para validar los datos migrados por la tarea. Usa la **DescribeTableStatistics**acción para recibir el informe de validación de datos en formato JSON. ## Estadísticas de tareas de replicación con Amazon CloudWatch Cuando Amazon CloudWatch está activado, AWS DMS proporciona las siguientes estadísticas de tareas de replicación: + **ValidationSucceededRecordCount**— Número de filas que se AWS DMS validaron, por minuto. + **ValidationAttemptedRecordCount**— Número de filas en las que se intentó la validación, por minuto. + **ValidationFailedOverallCount**— Número de filas en las que la validación falló. + **ValidationSuspendedOverallCount**— Número de filas en las que se suspendió la validación. + **ValidationPendingOverallCount**— Número de filas en las que la validación sigue pendiente. + **ValidationBulkQuerySourceLatency**— AWS DMS puede realizar la validación de datos de forma masiva, especialmente en determinadas situaciones durante una replicación a plena carga o en curso, cuando hay muchos cambios. Esta métrica indica la latencia necesaria para leer un conjunto masivo de datos desde el punto de enlace de origen. + **ValidationBulkQueryTargetLatency**— AWS DMS puede realizar la validación de datos de forma masiva, especialmente en algunos escenarios durante una replicación a plena carga o en curso, cuando hay muchos cambios. Esta métrica indica la latencia necesaria para leer un conjunto masivo de datos en el punto de enlace de destino. + **ValidationItemQuerySourceLatency**— Durante la replicación en curso, la validación de datos puede identificar los cambios en curso y validarlos. Esta métrica indica la latencia para leer esos cambios desde el origen. La validación puede ejecutar más consultas de las necesarias en función del número de cambios, si hay errores durante la validación. + **ValidationItemQueryTargetLatency**— Durante la replicación continua, la validación de datos puede identificar los cambios en curso y validarlos fila por fila. Esta métrica nos indica la latencia para leer esos cambios desde el destino. La validación puede ejecutar más consultas de las necesarias en función del número de cambios, si hay errores durante la validación. Para recopilar información de validación de datos a partir de las estadísticas CloudWatch habilitadas, seleccione **Habilitar CloudWatch registros** al crear o modificar una tarea mediante la consola. A continuación, para ver la información de la validación de datos y garantizar que los datos se han migrado de forma precisa del origen al destino, haga lo siguiente. 1. Elija la tarea en la página **Tareas de migración de base de datos**. 1. Selecciona la pestaña de **CloudWatch métricas**. 1. Seleccione **Validación** en el menú desplegable. ## Volver a validar tablas durante una tarea Mientras se ejecuta una tarea, puede solicitar la validación AWS DMS de datos. ### Consola de administración de AWS 1. Inicie sesión en la AWS DMS consola Consola de administración de AWS y ábrala en la versión [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). Si ha iniciado sesión como usuario AWS Identity and Access Management (IAM), asegúrese de tener los permisos de acceso adecuados AWS DMS. Consulte los permisos necesarios. [Se necesitan permisos de IAM para utilizarlos AWS DMS](security-iam.md#CHAP_Security.IAMPermissions) 1. Elija **Tasks** en el panel de navegación. 1. Elija la tarea en ejecución que tiene la tabla que desea volver a validar. 1. Elija la pestaña **Table Statistics** (Estadísticas de la tabla). 1. Elija la tabla que desea revalidar (puede elegir hasta 10 tablas a la vez). Si la tarea ya no está en ejecución, no podrá volver a validar la tabla. 1. Elija **Revalidate (Volver a validar)**. ## Uso del editor JSON para modificar las reglas de validación Para añadir una regla de validación a una tarea mediante el editor JSON de la AWS DMS consola, haga lo siguiente: 1. Seleccione las **tareas de migración de bases de datos**. 1. Seleccione la tarea de la lista de tareas de migración. 1. Si la tarea está en ejecución, seleccione **Detener** en el menú desplegable **Acciones**. 1. Una vez detenida la tarea, para modificarla, seleccione **Modificar** en el menú desplegable **Acciones**. 1. En la sección **Asignaciones de tablas**, seleccione el **editor JSON** y agregue la regla de validación a las asignaciones de tablas. Por ejemplo, puede agregar la siguiente regla de validación al origen para ejecutar una función de sustitución. En este caso, si la regla de validación encuentra un byte nulo, lo valida como un espacio. ``` { "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}" } ``` **nota** `override-validation-function` no surte efecto si la columna forma parte de la clave principal. ## Tareas exclusivas de validación Puede crear tareas exclusivas de validación para obtener una vista previa y validar los datos sin realizar ninguna migración o replicación de datos. Para crear una tarea exclusiva de validación, establezca la configuración de `EnableValidation` y `ValidationOnly` en `true`. Cuando se habilita `ValidationOnly`, se aplican requisitos adicionales. Para obtener más información, consulte [Configuración de tareas de validación de datos](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md). Para un tipo de migración exclusivo de carga completa, una tarea exclusiva de validación se completa mucho más rápido que su equivalente de CDC cuando se informa de muchos errores. Sin embargo, se informa de los cambios en el punto de conexión de origen o destino como errores en el modo de carga completa, lo que podría ser una desventaja. Una tarea exclusiva de validación de CDC retrasa la validación en función de la latencia media y vuelve a intentar los errores varias veces antes de informar de ellos. Si la mayoría de las comparaciones de datos dan como resultado errores, una tarea exclusiva de validación para el modo de CDC es muy lenta, lo que podría suponer un inconveniente. Una tarea exclusiva de validación se debe configurar en la misma dirección que la tarea de replicación, especialmente para la CDC. Esto se debe a que una tarea exclusiva de validación de CDC detecta qué filas han cambiado y deben revalidarse en función del registro de cambios del origen. Si el destino se especifica como origen, solo conoce los cambios enviados al destino por el DMS y no se garantiza que detecte errores de replicación. ### Validación solo de carga completa A partir de la AWS DMS versión 3.4.6 y versiones posteriores, una tarea que solo sea de validación a carga completa compara rápidamente todas las filas de las tablas de origen y destino en una sola pasada, informa inmediatamente de cualquier error y, a continuación, se cierra. La validación nunca se suspende debido a errores en este modo, sino que está optimizada para velocidad. Sin embargo, se informa de los cambios en el punto de conexión de origen o destino como errores. **nota** A partir de AWS DMS la versión 3.4.6 y versiones posteriores, este comportamiento de validación también se aplica a las tareas de migración a carga completa con la validación habilitada. ### Validación solo de CDC Una tarea exclusiva de validación de CDC valida todas las filas existentes entre las tablas de origen y destino desde cero. Además, una tarea exclusiva de validación de CDC se ejecuta de forma continua, vuelve a validar los cambios de replicación en curso, limita el número de errores notificados en cada pase y reintenta las filas que no coinciden antes de que produzcan un error. Está optimizada para evitar los falsos positivos. La validación de una tabla (o de toda la tarea) se suspende si se superan los umbrales ` FailureMaxCount` o `TableFailureMaxCount`. Esto también se aplica a una tarea de migración de CDC o Full carga completa\$1CDC con la validación habilitada. Además, una tarea de CDC con la validación habilitada retrasa la revalidación de cada fila modificada en función de la latencia media de origen y destino. Sin embargo, una *tarea exclusiva de validación* de CDC no migra los datos y no tiene latencia. De forma predeterminada, `ValidationQueryCdcDelaySeconds` se establece en 180. Además, puede aumentar la cantidad para tener en cuenta los entornos de alta latencia y ayudar a evitar los falsos positivos. ### Casos de uso solo de validación Los casos de uso para dividir la parte de validación de datos de una tarea de migración o replicación en una *tarea exclusiva de validación* incluyen, entre otros, los siguientes: + *Controlar exactamente cuándo se produce la validación*: las consultas de validación agregan una carga adicional a los puntos de conexión de origen y destino. Por lo tanto, migrar o replicar primero los datos de una tarea y, después, validar los resultados en otra tarea puede resultar beneficioso. + *Reducir la carga en la instancia de replicación*: dividir la validación de datos para que se ejecute en su propia instancia puede resultar ventajoso. + *Obtener rápidamente cuántas filas no coinciden en un momento dado en el tiempo*: por ejemplo, justo antes o durante una transición de producción de periodo de mantenimiento a un punto de conexión de destino, puede crear una tarea exclusiva de validación de carga completa para obtener una respuesta a la pregunta. + *Cuando se esperan errores de validación para una tarea de migración con un componente de CDC*: por ejemplo, si se migra Oracle `varchar2` a PostgreSQL `jsonb`, la validación de CDC sigue reintentando estas filas erróneas y limita el número de errores notificados cada vez. Sin embargo, puede crear una tarea exclusiva de validación de carga completa y obtener una respuesta más rápida. + *Ha desarrollado una reparación de datos script/utility que lee la tabla de errores de validación* (consulte también,[Resolución de problemas](#CHAP_Validating.Troubleshooting)). Una tarea exclusiva de validación de carga completa informa rápidamente de los errores para que el script de reparación de datos actúe en consecuencia. Para ver un ejemplo de la configuración de tareas de `ValidationSettings` en un archivo JSON, consulte [Ejemplo de configuración de tarea](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example). ## Resolución de problemas Durante la validación, AWS DMS crea una nueva tabla en el punto final de destino:`awsdms_control.awsdms_validation_failures_v1`. Si algún registro entra en el *ValidationSuspended*o el *ValidationFailed*estado, AWS DMS escribe la información de diagnóstico en`awsdms_control.awsdms_validation_failures_v1`. Puede consultar esta tabla para ayudar a solucionar errores de validación. Para obtener información sobre cómo cambiar el esquema predeterminado en el que se crea la tabla en el destino, consulte la [configuración de las tareas de la tabla de control](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md). A continuación se muestra una descripción de la tabla `awsdms_control.awsdms_validation_failures_v1`: | Nombre de la columna | Tipo de datos: | Description (Descripción) | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS identificador de tareas. | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | Esquema (propietario) de la tabla. | | `TABLE_NAME` | VARCHAR(128) NOT NULL | Nombre de la tabla. | | FAILURE\$1TIME | DATETIME(3) NOT NULL | Hora cuando se produjo el error. | | KEY\$1TYPE | VARCHAR(128) NOT NULL | Reservado para uso futuro (el valor siempre es “Fila”) | | KEY | TEXT NOT NULL | Esta es la clave principal para el tipo de registro de fila. | | FAILURE\$1TYPE | VARCHAR(128) NOT NULL | Gravedad de error de validación. Puede ser `RECORD_DIFF`, `MISSING_SOURCE`, `MISSING_TARGET` o `TABLE_WARNING`. | | DETAILS | VARCHAR(8000) NOT NULL | Cadena con formato JSON de todos los valores de source/target columna que no coinciden con la clave dada. | A continuación se incluye una consulta de ejemplo de un destino MySQL que le mostrará todos los errores para una tarea mediante la consulta de la tabla `awsdms_control.awsdms_validation_failures_v1`. Tenga en cuenta que el nombre del esquema y la sintaxis de la consulta variarán en las distintas versiones del motor de destino. El nombre de la tarea debe ser el ID del recurso externo de la tarea. El ID del recurso externo de la tarea es el último valor en el ARN de la tarea. Por ejemplo, para una tarea con un valor de ARN de arn:aws:dms:us-west- 2:5599:task: RYSI, el ID de recurso externo de la tarea sería 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'}],] ``` Puede mirar el campo `DETAILS` para determinar qué columnas no coinciden. Dado que tiene la clave principal del registro con error, puede consultar los puntos de conexión de origen y destino para ver qué parte del registro no coincide. ### Tabla de control `awsdms_validation_failures_v2` Durante la validación, en la AWS DMS versión 3.6.1 y versiones posteriores, DMS crea una nueva tabla en el punto final de destino de PostgreSQL:. `awsdms_validation_failures_v2` Esta tabla engloba los errores de todas las tareas de DMS que tienen activada la validación de datos. Cuando se cree la tabla `awsdms_validation_failures_v2`, no debe descartarla ni truncarla, ya que puede provocar errores en cualquier tarea que tenga activada la validación y la resincronización. La tabla `awsdms_validation_failures_v2` tiene una característica de clave principal de incremento automático. Esta tabla contiene columnas nuevas para admitir la característica de resincronización de datos. Son los siguientes: `RESYNC_RESULT` **Valores**: `SUCCESS` o `FAILURE` **`RESYNC_TIME`** Marca temporal con precisión de milisegundos. El valor predeterminado es `NULL` si no se intenta resincronizar los datos de este error. **`RESYNC_ACTION`** **Valores**: `UPSERT` o `DELETE` `RESYNC_ID` Columna de clave principal con el incremento automático activado. En la tabla `awsdms_validation_failures_v2`, se añade un índice a las columnas `TASK_NAME`, `TABLE_OWNER`, `TABLE_NAME`, `FAILURE_TYPE` y `FAILURE_TIME` para leer de manera eficiente los errores de cualquier tabla de la base de datos de destino. A continuación se muestra un ejemplo de instrucción de creación de una tabla `awsdms_validation_failures_v2`: ``` 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") ); ``` ## Rendimiento de validación de Redshift Amazon Redshift se diferencia de las bases de datos relacionales en varios aspectos, como el almacenamiento en columnas, el MPP, la compresión de datos y otros factores. Estas diferencias dan a Redshift un perfil de rendimiento diferente al de las bases de datos relacionales. Durante la fase de replicación de carga completa, la validación utiliza consultas de intervalo, y el tamaño de los datos depende de la configuración `PartitionSize`. Estas consultas basadas en intervalos seleccionan todos los registros de la tabla de origen. Para una replicación continua, las consultas cambian entre recuperaciones basadas en intervalos y de registros individuales. El tipo de consulta se determina de forma dinámica en función de varios factores, como los siguientes: + Volumen de consultas + Tipos de consultas DML en la tabla de origen + Latencia de la tarea + Número total de registros + Configuración de la validación, como `PartitionSize` Es posible que observe una carga adicional en su clúster de Amazon Redshift debido a las consultas de validación. Como los factores anteriores varían según los casos de uso, debe revisar el rendimiento de las consultas de validación y ajustar el clúster y la tabla en consecuencia. Algunas opciones para mitigar los problemas de rendimiento son las siguientes: + Reduzca la configuración `PartitionSize` y `ThreadCount` para ayudar a reducir la carga de trabajo durante la validación de carga completa. Tenga en cuenta que esto ralentizará la validación de los datos. + Si bien Redshift no aplica las claves principales, AWS DMS se basa en ellas para identificar de forma exclusiva los registros del destino para la validación de los datos. Si es posible, configure la clave principal para que refleje la clave de clasificación, de modo que las consultas de validación de carga completa se ejecuten más rápido. ## Validación de datos mejorada para AWS Database Migration Service AWS Database Migration Service ha mejorado el rendimiento de validación de datos para las migraciones de bases de datos, lo que permite a los clientes validar grandes conjuntos de datos con tiempos de procesamiento significativamente más rápidos. Esta validación de datos mejorada ya está disponible en la versión 3.5.4 del motor de replicación, tanto para tareas de migración de carga completa como de carga completa con CDC. Actualmente, esta mejora admite las rutas de migración de Oracle a PostgreSQL, de SQL Server a PostgreSQL, de Oracle a Oracle y de SQL Server a SQL Server. También hay previstas rutas de migración adicionales para versiones futuras. ### Requisitos previos + *Oracle:* conceda el permiso `EXECUTE` en `SYS.DBMS_CRYPTO` a la cuenta de usuario que accede al punto de conexión de Oracle: ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + Instale la extensión `pgcrypto` en la base de datos de PostgreSQL de destino: Para las instancias de PostgreSQL autoadministradas, debe instalar las bibliotecas de módulos `contrib` y crear la extensión: + Instale las bibliotecas de módulos `contrib`. Por ejemplo, en una instancia de Amazon EC2 con Amazon Linux y PostgreSQL 15, haga lo siguiente: ``` sudo dnf install postgresql15-contrib ``` + Cree la extensión `pgcrypto`: ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + En el caso de las instancias de Amazon RDS for PostgreSQL, configure el modo SSL para el punto de conexión: AWS DMS + De forma predeterminada, Amazon RDS fuerza una conexión SSL. Al crear un AWS DMS punto de conexión para una instancia de Amazon RDS for PostgreSQL, utilice la opción «modo SSL» = «obligatorio». + Si desea utilizar la opción “Modo SSL” = “obligatorio”, defina el parámetro `rds.force_ssl` en 0 en el grupo de parámetros de RDS. + Para PostgreSQL 12 y 13, cree el agregado `BIT_XOR`: ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### Limitaciones de la validación de datos mejorada Esta característica de validación de datos mejorada tiene las siguientes limitaciones: + Requisitos de los puntos de conexión de base de datos: esta mejora solo está activada para puntos de conexión de base de datos que cumplan los siguientes criterios: + Se utiliza para almacenar AWS Secrets Manager las credenciales. + Para Microsoft SQL Server, también se admite la autenticación de Kerberos. + Compatibilidad con las versiones de bases de datos: + PostgreSQL 12 y versiones posteriores + Oracle 12.1 y versiones posteriores + Para las versiones de Microsoft SQL Server anteriores a 2019, no se admite la validación de los tipos de datos NCHAR y NVARCHAR. ## Limitaciones + La validación de datos requiere que la tabla tenga una clave principal o índice único. + Las columnas de clave principal no pueden ser del tipo `CLOB`, `BLOB`, `BINARY` o `BYTE`. + Para las columnas de clave principal de tipo `VARCHAR` o `CHAR`, la longitud debe ser inferior a 1024. Debe especificar la longitud del tipo de datos. No puede usar tipos de datos ilimitados como clave principal para la validación de datos. + Una clave de Oracle creada con la cláusula `NOVALIDATE` *no* se considera una clave principal ni un índice único. + Para una tabla de Oracle sin clave principal y solo con una clave única, las columnas con la restricción única también deben tener una restricción `NOT NULL`. + No se admite la validación de PK/UK valores NULL. + Si la intercalación de la columna de clave principal en la instancia de PostgreSQL de destino no se ha establecido en "C", el orden de clasificación de la clave principal será diferente en comparación con el de Oracle. La validación de datos producirá un error al validar los registros si el orden de clasificación es diferente entre PostgreSQL y Oracle. + La validación de datos genera consultas adicionales en las bases de datos de origen y de destino. Debe asegurarse de que ambas bases de datos tengan suficientes recursos para gestionar esta carga adicional. Esto es especialmente importante en el caso de los destinos de Redshift. Para obtener más información, consulte [Rendimiento de validación de Redshift](#CHAP_Validating.Redshift) a continuación. + La validación de datos no se admite si se consolidan varias bases de datos en una. + Para un punto final de Oracle de origen o destino, AWS DMS utiliza`DBMS_CRYPTO`. Si usa la validación de datos en el punto de conexión de Oracle, debe conceder el permiso de ejecución en `dbms_crypto` a la cuenta de usuario que se utiliza para acceder al punto de conexión de Oracle. Puede hacerlo ejecutando la siguiente instrucción: ``` grant execute on sys.dbms_crypto to dms_endpoint_user; ``` + Si la base de datos de destino se modifica fuera o AWS DMS durante la validación, es posible que las discrepancias no se notifiquen con precisión. Este resultado puede producirse si una de sus aplicaciones escribe datos en la tabla de destino mientras AWS DMS realiza la validación en esa misma tabla. + Si una o más filas se modifican continuamente durante la validación, no AWS DMS podrá validarlas. + Si AWS DMS detecta más de 10 000 registros fallidos o suspendidos, detiene la validación. Antes de continuar, deberá resolver los problemas subyacentes con los datos. + AWS DMS no admite la validación de datos de las vistas. + AWS DMS no admite la validación de datos cuando se utilizan los ajustes de las tareas de sustitución de caracteres. + AWS DMS no admite la validación del tipo Oracle LONG. + AWS DMS no admite la validación del tipo Oracle Spatial durante una migración heterogénea. + La validación de datos ignora las columnas de las tablas para las que existen transformaciones de enmascaramiento de datos en las asignaciones de tablas. + La validación de datos omite una tabla completa si existe una regla de transformación de enmascaramiento de datos para su columna. PK/UK El estado de validación se mostrará como Sin clave principal para dichas tablas. + La validación de datos no funciona con Amazon Aurora PostgreSQL sin límite. Al intentar validar tablas en una base de datos ilimitada, el estado de validación muestra Sin clave principal para dichas tablas. Para conocer las limitaciones al utilizar la validación de destino de S3, consulte [Limitaciones para utilizar la validación de destinos de S3](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations). # Validación de datos de destino de Amazon S3 AWS DMS admite la validación de datos replicados en los destinos de Amazon S3. Dado que AWS DMS almacena los datos replicados como archivos planos en Amazon S3, utilizamos las consultas de [Amazon](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) `CREATE TABLE AS SELECT` Athena (CTAS) para validar los datos. Las consultas de los datos almacenados en Amazon S3 son intensas desde el punto de vista computacional. Por lo tanto, AWS DMS ejecuta la validación de los datos de Amazon S3 durante la captura de datos de cambios (CDC) solo una vez al día, a medianoche (00:00) UTC. Cada validación diaria que AWS DMS se ejecuta se denomina *validación por intervalos*. Durante una validación por intervalos, AWS DMS valida todos los registros de cambios que se migraron al bucket de Amazon S3 de destino durante las últimas 24 horas. Para obtener más información sobre las limitaciones de la validación de intervalo, consulte [Limitaciones para utilizar la validación de destinos de S3](#CHAP_Validating_S3_limitations). La validación de destinos de Amazon S3 utiliza Amazon Athena, por lo que se aplican costos adicionales. Para obtener más información, consulte [Precios de Amazon Athena](https://aws.amazon.com/athena/pricing/). **nota** La validación del destino de S3 requiere AWS DMS la versión 3.5.0 o posterior. **Topics** + [Requisitos previos](#CHAP_Validating_S3_prerequisites) + [Permisos](#CHAP_Validating_S3_permissions) + [Limitaciones](#CHAP_Validating_S3_limitations) + [Tareas exclusivas de validación](#CHAP_Validating_S3_only) ## Requisitos previos de validación de destino de S3 Antes de usar la validación de destino de S3, compruebe la siguiente configuración y permisos: + Establezca el valor `DataFormat` para [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) en `parquet`. Para obtener más información, consulte [Configuración de Parquet para S3](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet). + Asegúrese de que el rol asignado a la cuenta de usuario utilizada para crear la tarea de migración tenga el conjunto de permisos correcto. Consulte [Permisos](#CHAP_Validating_S3_permissions) a continuación. Para las tareas que utilizan la replicación continua (CDC), compruebe la siguiente configuración: + Active el registro complementario para tener registros completos de los datos de CDC. Para obtener información sobre cómo activar el registro complementario, consulte [Soporte de diagnóstico y solución de problemasSolución de problemas de latencia](CHAP_Troubleshooting.md) en la sección [Agregar automáticamente registros suplementarios a un punto de conexión de origen de Oracle](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging) de esta guía. + Establezca el parámetro `TimestampColumnName` para el punto de conexión de destino. No hay limitaciones en cuanto al nombre de la columna de marca temporal. Para obtener más información, consulte [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html). + Configure la partición de carpetas basada en fechas para el destino. Para obtener más información, consulte [Uso de la partición de carpetas basada en fechas](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning). ## Permisos para usar la validación de destinos de S3 Para configurar el acceso para usar la validación de destino de S3, asegúrese de que el rol asignado a la cuenta de usuario que se usó para crear la tarea de migración tenga el siguiente conjunto de permisos. Sustituya los valores de ejemplo por sus valores. ------ #### [ 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": "*" } ] } ``` ------ ## Limitaciones para utilizar la validación de destinos de S3 Consulte las siguientes limitaciones adicionales que se aplican al utilizar la validación de destinos de S3. Para conocer las limitaciones que se aplican a todas las validaciones, consulte [Limitaciones](CHAP_Validating.md#CHAP_Validating.Limitations). + El valor `DatePartitionSequence` necesita un componente de día. La validación de destinos de S3 no admite el formato `YYYYMM`. + Cuando la validación de intervalo se ejecuta durante CDC, es posible que vea errores de validación falsos en la tabla `awsdms_validation_failures_v1`. Estos errores se producen porque se AWS DMS migran los cambios que llegaron durante la validación del intervalo a la carpeta de particiones del día siguiente. Normalmente, estos cambios se escriben en la carpeta de particiones del día actual. Estos errores falsos son una limitación a la hora de validar la replicación desde una base de datos de origen dinámica a un destino estático, como Amazon S3. Para investigar estos errores falsos, compruebe si hay registros cerca del final del periodo de validación (00:00 UTC), que es cuando suelen aparecer estos errores. Para minimizar el número de errores falsos, asegúrese de que `CDCLatencySource` para la tarea sea bajo. Para obtener información sobre el monitoreo de latencia, consulte [Métricas de tareas de replicación](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task). + Las tareas en el estado `failed` o `stopped` no validan los cambios del día anterior. Para minimizar los errores de validación debidos a errores inesperados, cree tareas exclusivas de validación independientes con las mismas asignaciones de tablas y los mismos puntos de conexión de origen y destino. Para obtener más información sobre las tareas exclusivas de validación, consulte [Uso de tareas exclusivas de validación con validación de destino de S3](#CHAP_Validating_S3_only). + La columna **Estado de validación** de las estadísticas de la tabla refleja el estado de la validación de intervalo más reciente. Como resultado, una tabla que tenga discrepancias podría aparecer como validada tras la validación de intervalo del día siguiente. Compruebe `s3_validation_failures folder` en el bucket de Amazon S3 de destino por si hay discrepancias que se hayan producido hace más de un día. + La validación de S3 utiliza la característica de tabla en buckets de Amazon Athena. Esto permite que la validación de S3 haga una copia en buckets de los datos de la tabla de destino. Esto significa que la copia de los datos de la tabla se divide en subconjuntos que coinciden con el particionamiento interno de la validación de DMS. Las tablas en buckets de Athena tienen un límite de 100 000 buckets. Cualquier tabla que S3 intente validar y que supere este límite no se validará. El número de buckets que la validación de S3 intenta crear es igual a lo siguiente: ``` (#records in the table) / (validation partition size setting) ``` Para evitar esta limitación, aumente el valor del tamaño de partición de la validación de forma que el número de buckets creados por la validación de S3 sea inferior a 100 000. Para obtener más información sobre la agrupación en buckets, consulte [Uso de particiones y asignación de buckets](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html) en Athena en la *Guía del usuario de Amazon Athena*. + El nombre de la tabla no puede contener caracteres especiales, excepto el guion bajo. La validación de S3 utiliza Amazon Athena, que no admite caracteres especiales (excepto el guion bajo) en los nombres de las tablas. Para obtener más información, consulte el tema [CREATE TABLE](https://docs.aws.amazon.com/athena/latest/ug/create-table.html) en la *Guía del usuario de Amazon Athena*. + Cuando se utiliza la función de validación de AWS DMS datos con un destino de Amazon S3 gestionado por AWS Lake Formation, el proceso de validación falla. Esto puede generar problemas de coherencia de datos. ## Uso de tareas exclusivas de validación con validación de destino de S3 Una *tarea exclusiva de validación* ejecuta la validación de los datos que se van a migrar sin ejecutar la migración. Las tareas exclusivas de validación siguen ejecutándose, incluso si la tarea de migración se detiene, lo que garantiza que AWS DMS no se pierda el intervalo de validación a las 00:00 UTC. El uso de tareas exclusivas de validación con puntos de conexión de destino de Amazon S3 tiene las siguientes limitaciones: + Se admite la validación de Amazon S3 para tareas de carga completa con la configuración exclusiva de validación habilitada, pero funciona de manera diferente a las tareas de carga completa y exclusivas de validación para otros puntos de conexión. En el caso de S3 como destino, una tarea de este tipo se valida solo con los datos de carga completa del destino de S3 y no se valida con ningún dato migrado como parte de una migración de CDC. Utilice esta característica solo para validar los datos creados por una tarea exclusiva de carga completa. El uso de este modo para validar los datos de un destino en el que se esté ejecutando una tarea de CDC no producirá una validación eficaz. + Las tareas exclusivas de validación solo validan los cambios realizados desde la última validación de intervalo (00:00 UTC). Las tareas exclusivas de validación no validan los datos de carga completa ni los datos de CDC de días anteriores. # AWS DMS resincronización de datos AWS Database Migration Service (AWS DMS) La resincronización de datos corrige automáticamente las inconsistencias de datos identificadas mediante la validación de datos entre las bases de datos de origen y destino. Esta característica funciona como parte de sus tareas de migración de DMS actuales, lo que garantiza que se realicen las actualizaciones adecuadas en función de las configuraciones de las tareas, los ajustes de conexión, las asignaciones de tablas y las transformaciones. La característica de resincronización de datos funciona mediante la lectura de los errores de validación de una tabla de control en la base de datos de destino y la ejecución de las operaciones de reparación adecuadas. Cuando se detecta una discrepancia, los datos actuales se obtienen del origen usando la clave principal almacenada en el registro de errores y se aplican al destino respetando las transformaciones configuradas. Para obtener más información, consulte [Tabla de control `awsdms_validation_failures_v2`](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table). El comportamiento varía en función del tipo de migración. En el caso de full-load-only las tareas, la resincronización de datos se ejecuta una vez finalizada la carga inicial y la validación. En el caso de las tareas que requieren la captura de datos de cambios (CDC), la resincronización de datos funciona según una programación configurada que detiene temporalmente la replicación y la validación mientras se aplican las correcciones. Durante las operaciones de resincronización de CDC: + La replicación y la validación se detienen temporalmente. + La resincronización de datos procesa los errores de validación existentes. + Se reanudan la replicación y la validación normales. + El proceso se repite según la programación configurada. La resincronización de datos rastrea automáticamente el estado de cada operación de reparación y proporciona métricas detalladas mediante estadísticas de tablas. **Requisitos previos**: La característica de resincronización de datos necesita los siguientes requisitos previos: + Debe tener la versión AWS DMS del motor 3.6.1 o posterior. + Debe configurar los ajustes de programación y duración para las tareas que tienen una replicación continua. Las tareas que solo son de carga completa no requieren estos ajustes. ## Limitaciones La característica de resincronización de datos tiene las siguientes limitaciones: + La resincronización de datos solo admite Oracle y SQL Server como base de datos de origen. + La resincronización de datos admite el motor compatible con PostgreSQL y Amazon Aurora PostgreSQL como base de datos de destino. + Todas las tablas de la base de datos de origen y destino deben tener claves principales. La validación no admite tablas sin una clave principal o una clave única. Las tablas que no tengan una clave principal o única válida no se validan y no se informa de ningún error de validación. + Al ejecutar Full-load-only tareas, la validación de datos debe estar habilitada. + La resincronización de datos no se puede habilitar para las tareas exclusivas de validación, ya que no replican ningún dato. Puede habilitar la resincronización en la tarea de replicación principal proporcionando el `taskID` exclusivo de validación. Para obtener más información, consulte [Tareas exclusivas de validación](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly). + Si la tarea exclusiva de validación tiene configurado un parámetro `ControlSchema` en la configuración de la tarea, la tarea de replicación también debe tener la misma configuración de parámetros para que la resincronización de datos detecte los errores de validación correctos. + Debe configurar los ajustes de programación y duración de las tareas de CDC. + Durante el período de resincronización, la resincronización de datos puede afectar a la latencia de replicación en DMS. [Para obtener más información sobre la solución de problemas de las validaciones AWS DMS durante la resincronización de datos, consulta la sección [Solución](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) de problemas de la validación de datos.AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) ## Programación y duración Para las tareas con CDC, debe configurar cuándo y durante cuánto tiempo funcionará la resincronización de datos. Esto ayuda a evitar que sus operaciones de replicación habituales se vean afectadas. Debe especificar: + un programa que utiliza el formato cron para definir cuándo se pueden producir las operaciones de resincronización, + una duración máxima para garantizar que las operaciones de resincronización no se prolonguen hasta los períodos de mayor consumo. Se recomienda programar las operaciones de resincronización durante las horas de menor actividad o en un período en el que los cambios en la base de datos de origen sean mínimos o nulos. **nota** El tiempo programado incluye esperar a que el flujo de aplicación de destino esté vacío, ya que la resincronización de datos y la replicación normal no pueden ejecutarse simultáneamente. ## Casos de uso La característica de resincronización de datos permite a los usuarios reconciliar las incoherencias de datos entre los sistemas de origen y destino. Además, identifica los registros que no coinciden y los sincroniza para mantener la coherencia de los datos en los entornos distribuidos. Los siguientes casos de uso muestran situaciones comunes en las que la característica de resincronización de datos resuelve los problemas de coherencia de datos: **Escenario 1 - Tarea de carga completa: ejecute la resincronización con la misma tarea de DMS** En la tarea de migración de carga completa de DMS existente, puede realizar lo siguiente: + Activar la validación: `Validation with data migration = true` + Activar la resincronización: `Data resync = true` **Escenario 2 - Tarea de carga completa y CDC, tarea exclusiva de CDC: ejecute la resincronización con la misma tarea de DMS** En la tarea de migración de CDC de DMS existente, puede realizar lo siguiente: + Activar la validación: `Validation with data migration = true` + Activar la resincronización: `Data resync = true` + Especificar el programa de resincronización: `"ResyncSchedule": "0 0,2,4,6 * * *"` + Especificar la hora de resincronización: `MaxResyncTime": 60` **Escenario 3 - Tarea de carga completa y CDC o tarea exclusiva de CDC para la replicación y resincronización, en combinación con una tarea exclusiva de validación** Para realizar una operación exclusiva de validación en otra tarea de DMS al utilizar la resincronización, puede hacer lo siguiente: + Crear una tarea de CDC de DMS exclusiva de validación **nota** Debe tomar nota y especificar el ID de esta tarea durante la resincronización de datos. + En su tarea de CDC principal, desactive la validación: `Data validation = false` + Activar la resincronización: `Data resync = true` + Especificar el programa de resincronización: `"ResyncSchedule": "0 0,2,4,6 * * *"` + Especificar la hora de resincronización: `MaxResyncTime": 60` + Especificar el ID de la tarea de CDC de DMS exclusiva de validación. El ID de la tarea exclusiva de validación se añade al final del ARN. Ejemplo de ARN: `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` y ejemplo de ID de tarea exclusiva de validación: `6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` ## Prácticas recomendadas Puede aprovechar la función de resincronización de datos AWS Database Migration Service para mejorar la durabilidad de sus tareas de replicación y lograr la coherencia. Algunas prácticas recomendadas para utilizar la característica de resincronización de datos son: + Como parte de la resincronización de datos, los registros que no coinciden se corrigen extrayéndolos del origen y aplicándolos a la base de datos de destino. Si la base de datos de origen se actualiza durante el período de resincronización, la resincronización lee el último valor del registro y lo aplica al destino. Esto puede provocar que los eventos de aplicación de CDC fallen e introduzcan inconsistencias temporales en la base de datos de destino. Para evitarlo, debe programar el período de resincronización fuera del horario laboral o en períodos en los que los cambios en la base de datos de origen sean nulos o mínimos. + Establezca el período de resincronización durante los períodos de actividad mínima de la base de datos de origen y dentro del umbral de latencia de destino aceptable. Los intervalos de resincronización pequeños pueden provocar la acumulación de discrepancias de validación no procesadas, mientras que los períodos más extendidos pueden aumentar la latencia de replicación cuando se producen muchos errores de validación. Supervise los errores de validación y las tasas de resincronización para determinar los intervalos de resincronización óptimos durante los períodos de inactividad del origen. A continuación mostramos algunos ejemplos de configuración de los intervalos de resincronización: + Configuración de múltiples intervalos cortos: ``` "ResyncSchedule": "0 0,2,4,6 * * *", "MaxResyncTime": 60 ``` + Configuración de un intervalo diario único: ``` "ResyncSchedule": "0 0 * * *", "MaxResyncTime": 360 ``` + Supervise la latencia de replicación en DMS durante los intervalos de resincronización y ajuste la programación en consecuencia para mitigar los grandes picos. + Puede revisar los resultados de la resincronización en las estadísticas de tabla o consultando la tabla `awsdms_validation_failures_v2` en la base de datos de destino. Para obtener más información, consulte [Supervisión de las tareas de replicación mediante Amazon CloudWatch](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch). + Cuando la tarea se encuentre en una fase de replicación continua, evite iniciar una recarga de tablas individuales durante el período de resincronización. + Prácticas recomendadas para una tarea de replicación de CDC: + Todas las tablas de su base de datos completan el proceso de carga. + Las discrepancias se identifican en el proceso de validación en curso. + Según el período de resincronización programado, la tarea de replicación se detiene durante un breve período. + La resincronización de datos soluciona los problemas identificados durante el proceso de validación. + El proceso de replicación se reanuda y se repite según la programación. ## Configuración y ejemplos de resincronización de datos **Configuración de los ajustes de resincronización de datos**: Puede configurar la resincronización para su tarea de replicación en DMS. A continuación, se muestra un ejemplo de la configuración de los ajustes de resincronización de datos en su tarea: ``` "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 } ``` **Ejemplos de patrones comunes de programación de la resincronización**: + `0 0 * * *`: se ejecuta una vez al día a medianoche + `0 0,12 * * *`: se ejecuta dos veces al día a medianoche y al mediodía + `0 0,2,4,6, * * *`: se ejecuta cada dos horas entre la medianoche y las 6 de la mañana + `0 1 * * 1`: se ejecuta todas las semanas los lunes a la 1 de la madrugada **nota** Debe especificar un número del 0 al 6 para cada día. Para obtener más información, consulte [Reglas de expresiones cron](#CHAP_DataResync.cron). **Supervisión de las operaciones de resincronización**: Puede supervisar la operación de resincronización mediante las estadísticas de tabla. A continuación, se muestra un ejemplo del resultado: ``` { "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" } } ``` Para configurar la función de resincronización de datos AWS DMS, puede revisar varios parámetros de resincronización y sus respectivos ajustes de configuración. Para obtener más información, consulte [Configuración de la resincronización de datos](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md). Para obtener más información sobre la configuración del registro de resincronización de datos, consulte [Configuración de las tareas de los registros](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md). ## Validación y solución de problemas **Validación**: Cuando la validación de datos está habilitada, AWS DMS crea una tabla de errores de validación en la base de datos de destino con la siguiente estructura: ``` 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 ); ``` Puede escribir una consulta en esta tabla para comprender las discrepancias de datos que se encuentran y cómo se resuelven. Cuando la validación está habilitada, AWS DMS crea una tabla de errores de validación en la base de datos de destino. Si tiene problemas, puede escribir una consulta en la tabla `awsdms_control.awsdms_validation_failures_v2` para comprender las discrepancias de datos que se encuentran y cómo se resuelven. Para obtener más información, consulte la sección [Solución de problemas](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) en [Validación de datos de AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html). **Flujo de trabajo común**: Durante la validación en la resincronización de datos, el flujo de trabajo estándar es el siguiente: **Tareas que solo son de carga completa**: 1. Todas las tablas de su base de datos completan el proceso de carga. 1. Las discrepancias se identifican en el proceso de validación en curso. 1. La resincronización de datos soluciona los problemas identificados durante el proceso de validación. 1. El proceso de validación valida la rectificación. 1. La tarea de migración se ha completado correctamente. **Tareas de CDC**: 1. Todas las tablas de su base de datos completan el proceso de carga. 1. Las discrepancias se identifican en el proceso de validación en curso. 1. Según el período de resincronización programado, la tarea de replicación se detiene durante un breve período. 1. La resincronización de datos soluciona los problemas identificados durante el proceso de validación. 1. El proceso de replicación se reanuda y se repite según la programación. Cualquier modificación que se realice en la tarea, como detener la tarea de replicación durante la operación de resincronización o volver a cargar y revalidar las tablas, puede afectar al comportamiento y al resultado de la tarea. Algunos de los cambios de comportamiento conocidos son los siguientes: **Al detener la tarea de replicación mientras la operación de resincronización está en curso**: + La operación de resincronización no se reanuda automáticamente. Deberá reiniciarla de nuevo. + Las operaciones de resincronización futuras se ejecutan según la programación configurada. + Las correcciones incompletas se intentarán en el siguiente período de programación de la resincronización. **Al volver a cargar una tabla en la base de datos**: + La operación de resincronización omite cualquier tabla que se esté cargando de nuevo. + Se ignoran los errores de validación anteriores de una tabla que se ha vuelto a cargar. + La nueva validación comienza una vez finalizada la acción de recarga. **Al volver a validar una tabla en la base de datos**: + Se restablecen todas las estadísticas de la operación de resincronización. + Se ignoran los errores de validación anteriores de una tabla que se ha vuelto a validar. **nota** Al actualizar o mover una tarea a la versión 3.6.1 o superior de DMS, los errores de la tabla `awsdms_control.awsdms_validation_failures_v1` no se vuelven a sincronizar. Solo se vuelven a sincronizar los errores de la tabla `awsdms_validation_failures_v2`. Para volver a sincronizar los errores de la tabla `awsdms_control.awsdms_validation_failures_v2`, debe volver a cargar la tarea, volver a cargar una o más tablas en la tarea o volver a validar una o más tablas. Para obtener más información, consulte los enlaces siguientes: Para volver a cargar una tarea, consulte [Referencia de la API `StartReplicationTask`](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html). Para volver a cargar una o más tablas en una tarea, consulte [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html) en la documentación de la *Referencia de comandos de la CLI de AWS *. Para volver a validar una o más tablas, consulte la opción `validate-only` en la sección [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html) de la documentación de la *Referencia de comandos de la CLI de AWS *. . ## Reglas de expresiones cron Para configurar las operaciones de resincronización de datos durante una tarea de replicación, AWS DMS puede utilizar las reglas de expresiones cron. Estas reglas le permiten personalizar los intervalos de tiempo de resincronización y programarlos según las necesidades de su empresa. Puede utilizar varios parámetros, como minutos, horas, días, meses y días de la semana. Las reglas de expresión cron para cada parámetro son: **Minutos:** + Rango de minutos entre 0 y 59. + Puede usar (`-`), `or`/`and` para especificar el rango. Máximo de 10 elementos separados por una coma (`,`). + **Ejemplos**: + `2-5` es igual a `2,3,5,5`. + `1-2,3-4,5,7-10` es un rango válido. + `1,2,3,4,5,6,7,8,9,10` es un rango válido. + `1,2,3,4,5,6,7,8,9,10,11` no es un rango válido. La operación de resincronización se omite después del décimo elemento del rango. + Puede usar (`*`). Ejemplo: `*` es igual a `0-59`. + Solo puede usar (`/`) en combinación con (`-`) o (`*`). **Ejemplos**: + `2-7/2` es igual a `2,4,6`. + `*/15` es igual a `0,15,30,45`. **Horas**: Igual que **Minutos** pero el intervalo válido va de `0` a `23`. **Días**: + Igual que **Minutos** pero el intervalo válido va de `1` a `31`. + Se admite el uso de `L` en la configuración de resincronización. Se interpreta como el último día del mes. No debe usarlo en combinación con otra sintaxis. **Meses**: Igual que **Minutos** pero el intervalo válido va de `1` a `12`. **Días de la semana**: + Igual que **Minutos** pero el intervalo válido va de `0` a `6`. + No se puede añadir un valor de cadena para el nombre de la semana.