Creación de tareas para la replicación continua con AWS DMS

Puede crear una tarea de AWS DMS que capture los cambios en curso desde el almacén de datos de origen. Para ello, puede capturar al mismo tiempo que migra los datos. También puede crear una tarea que capture los cambios continuos después de completar la migración (carga completa) inicial a un almacén de datos de destino compatible. Este proceso se denomina «replicación continua» o «captura de datos de cambios (CDC)». AWS DMS utiliza este proceso para replicar los cambios continuos desde un almacén de datos de origen. Este proceso funciona recopilando los cambios en logs de la base de datos con la API nativa del motor de base de datos.

nota

Puede migrar vistas solo con tareas de carga completa. Si la tarea es una tarea de solo CDC o una tarea de carga completa que inicia CDC después de completarse, la migración incluye solo tablas del origen. Con una tarea de solo carga completa, puede migrar vistas o una combinación de tablas y vistas. Para obtener más información, consulte Especificación de reglas de selección de tablas y transformaciones mediante JSON.

Cada motor origen tiene requisitos de configuración específicos para exponer el flujo de cambios a una determinada cuenta de usuario. La mayoría de los motores necesitan algún tipo de configuración adicional para que el proceso de captura pueda consumir los datos de forma provechosa, sin perder información. Por ejemplo, con Oracle es necesario añadir un modo de registro complementario y, con MySQL, un sistema de registro binario en el nivel de fila.

Para leer los cambios continuos de la base de datos de origen, AWS DMS utiliza acciones de la API específicas del motor que le permiten ver cambios en los registros de transacciones del motor de origen. A continuación, se incluyen algunos ejemplos de cómo AWS DMS realiza esta operación:

• En Oracle: AWS DMS utiliza la API de Oracle LogMiner o de Binary Reader (API bfile) para leer los cambios continuos. AWS DMS lee los cambios continuos de los registros REDO archivados o en línea en función del número de cambio del sistema (SCN).

• En Microsoft SQL Server, AWS DMS utiliza MS-Replication o MS-CDC para escribir información en el registro de transacciones de SQL Server. A continuación, utiliza la función fn_dblog() o fn_dump_dblog() de SQL Server para leer los cambios del registro de transacciones basándose en el número de secuencia del registro (LSN).

• En MySQL, AWS DMS lee los cambios de los registros binarios (binlogs) basados en filas y migra dichos cambios al destino.

• En PostgreSQL, AWS DMS configura ranuras de replicación lógica, utiliza el complemento test_decoding para leer los cambios del origen y migra dichos cambios al destino.

• Cuando use Amazon RDS como origen, le recomendamos que se asegure de que las copias de seguridad están habilitadas para configurar CDC. También le recomendamos que se asegure de que la base de datos de origen esté configurada para retener los registros de cambios durante un tiempo suficiente, 24 horas suele ser suficiente. Para configuración específica de cada punto de conexión, consulte lo siguiente:

  • Amazon RDS para Oracle: Configuración de una fuente de Oracle AWS gestionada por Oracle para AWS DMS.

  • Amazon RDS para MySQL y Aurora MySQL: Uso de una base AWS de datos compatible con MySQL gestionada como fuente para AWS DMS.

  • Amazon RDS para SQL Server: Configuración de la replicación continua en una instancia de base de datos de SQL Server de la nube.

  • Amazon RDS para PostgreSQL y Aurora PostgreSQL: PostgreSQL conserva automáticamente el WAL requerido.

Hay dos tipos de tareas de replicación continua:

• Carga completa más CDC: la tarea migra los datos existentes y, a continuación, actualiza la base de datos de destino en función de los cambios realizados en la base de datos de origen.

• Solo CDC: la tarea migra los cambios continuos una vez que los datos están en la base de datos de destino.

Realizar la replicación comenzando desde un punto de inicio de CDC

Puede iniciar una tarea de replicación continua de AWS DMS (cambiar solo la captura de datos) desde varios puntos. Esto incluye lo siguiente:

• A partir de una hora de inicio CDC personalizada: puede usar AWS Management Console o AWS CLI para proporcionar a AWS DMS la fecha y hora en la que desea que comience la replicación. AWS DMS, a continuación, inicia una tarea de replicación continua a partir de esta hora de inicio personalizada de CDC. AWS DMS convierte la marca temporal dada (en UTC) en un punto de inicio nativo, como un LSN para SQL Server o un SCN para Oracle. AWS DMS utiliza métodos específicos del motor para determinar dónde iniciar la tarea de migración en función del flujo de cambios del motor de origen.

  nota

  Solo si se establece el atributo de conexión StartFromContext en la marca temporal requerida, Db2 como origen ofrece una hora de inicio de CDC personalizada.

  PostgreSQL como origen no admite una hora de inicio CDC personalizada. Esto se debe a que el motor de base de datos de PostgreSQL no tiene forma de asignar una marca temporal a un LSN o SCN como Oracle y SQL Server.

• A partir de un punto de inicio nativo de CDC: también puede iniciar desde un punto nativo en el registro de transacciones del motor de origen. En algunos casos, es posible que prefiera este enfoque, ya que una marca temporal puede indicar varios puntos nativos en el registro de transacciones. AWS DMS admite esta característica en los siguientes puntos de enlace de origen:

  • SQL Server

  • PostgreSQL

  • Oracle

  • MySQL

  • MariaDB

Cuando se crea la tarea, AWS DMS marca el punto de inicio de CDC y no se puede cambiar. Para usar un punto de inicio de CDC diferente, cree una tarea nueva.

Determinar un punto de inicio de CDC nativo

Un punto de inicio nativo de CDC es un punto en el registro del motor de base de datos que define una hora a la que se puede iniciar la captura de datos de cambios (CDC). Por ejemplo, suponga que un volcado de datos masivos ya se ha aplicado al destino. Puede buscar el punto de partida nativo para la tarea en curso exclusiva de replicación. Para evitar cualquier incoherencia en los datos, elija cuidadosamente el punto de inicio para la tarea de solo replicación. El DMS captura las transacciones que se iniciaron después del punto de inicio de CDC elegido.

Los siguientes ejemplos muestran cómo puede encontrar el punto de inicio de CDC nativo de motores de origen admitidos:

SQL Server

El SQL Server, un número de secuencia de registro (LSN) tiene tres partes:

• Número de secuencia del archivo registro virtual (VLF)

• Desplazamiento inicial de un bloque del registro

• Número de ranura

Un LSN de ejemplo es: 00000014:00000061:0001

Para obtener el punto de inicio de una tarea de migración de SQL Server en función de la configuración de copias de seguridad de registros de transacciones, use la función fn_dblog() o fn_dump_dblog() de SQL Server.

Para utilizar el punto de inicio nativo de CDC con SQL Server, cree una publicación en cualquier tabla que participe en la replicación continua. AWS DMS crea la publicación automáticamente cuando utiliza CDC sin utilizar un punto de inicio nativo de CDC.

PostgreSQL

Puede utilizar un punto de control de recuperación de CDC en la base de datos de origen de PostgreSQL. Este valor de control se genera en varios puntos a medida que se ejecuta una tarea de replicación continua en la base de datos de origen (la tarea principal). Para obtener más información sobre los puntos de comprobación en general, consulte Uso de un punto de comprobación como punto de inicio de CDC.

Para identificar el punto de control que se va a utilizar como punto de inicio nativo, utilice la vista pg_replication_slots de la base de datos o los detalles generales de la tarea principal de AWS Management Console

Para buscar los detalles generales de la tarea principal en la consola

1. Inicie sesión en la AWS Management Console y abra la consola de AWS DMS en https://console.aws.amazon.com/dms/v2/.

   Si ha iniciado sesión como usuario de IAM, asegúrese de que dispone de los permisos adecuados para acceder a AWS DMS. Para obtener más información sobre los permisos que se necesitan, consulte Permisos de IAM necesarios para utilizar AWS DMS.

2. En el panel de navegación, elija Database migration tasks (Tareas de migración de base de datos).

3. Elija la tarea principal de la lista de la página Database migration tasks (Tareas de migración de base de datos). De este modo, se abrirá la página de tareas principal, que contiene los detalles generales.

4. Localice el valor del punto de control en Change data capture (CDC) [Captura de datos de cambio (CDC)], Change data capture (CDC) start position [Posición inicial de la captura de datos de cambio (CDC)] y Change data capture (CDC) recovery checkpoint [Punto de control de recuperación de la captura de datos de cambio (CDC)].

   El valor tiene un aspecto similar al siguiente.

   checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

   Aquí, el componente 4AF/B00000D0 es lo que necesita para especificar este punto de inicio de CDC nativo. Establezca el parámetro CdcStartPosition de la API de DMS en este valor cuando cree la de tarea CDC para comenzar la replicación en este punto de inicio del origen de PostgreSQL. Si necesita más información acerca de cómo utilizar AWS CLI de para crear esta tarea de CDC, consulte Habilitar CDC con una instancia de base AWS de datos PostgreSQL administrada con AWS DMS.

Oracle

Un número de cambio del sistema (SCN) es una marca temporal interna lógica que utilizan las bases de datos de Oracle. Se usa para ordenar los eventos que se producen dentro de la base de datos, lo cual es necesario para satisfacer las propiedades de atomicidad, uniformidad, aislamiento y durabilidad (ACID) de una transacción. Las bases de datos de Oracle utilizan los SCN para marcar la ubicación donde todos los cambios se han escrito en el disco, de modo que una acción de recuperación no aplique los cambios que ya se han escrito. Oracle también utiliza los SCN para marcar el punto en el que no hay nada que rehacer en un conjunto de datos, de modo que la recuperación pueda detenerse.

Para obtener el SCN actual de una base de datos de Oracle, ejecute el siguiente comando.

SELECT CURRENT_SCN FROM V$DATABASE

Si utiliza el SCN o la marca temporal para iniciar una tarea de CDC, no verá los resultados de las transacciones abiertas y no podrá migrarlos. Las transacciones abiertas se iniciaron antes de la posición de inicio de la tarea y se confirmaron después de la posición de inicio de la tarea. Puede identificar el SCN y la marca temporal para iniciar una tarea de CDC en un punto que incluya todas las transacciones abiertas. Para obtener más información, consulte Transacciones en la documentación en línea de Oracle. Con la versión 3.5.1 y versiones superiores, AWS DMS admite transacciones abiertas para tareas exclusivas de CDC con la configuración de punto de conexión openTransactionWindow si se utiliza el SCN o la marca temporal para iniciar la tarea.

Al utilizar esta configuración openTransactionWindow, debe proporcionar el intervalo, en número de minutos, para gestionar las transacciones abiertas. AWS DMS cambia la posición de captura y busca la nueva posición para iniciar la captura de datos. AWS DMS utiliza la nueva posición de inicio para escanear cualquier transacción abierta de los registros REDO archivados o REDO de Oracle necesarios.

MySQL

Antes del lanzamiento de MySQL versión 5.6.3, el número de secuencia de registro (LSN) de MySQL era un número entero sin firmar de 4 bytes. En MySQL versión 5.6.3, en la que el límite de tamaño de archivos de registro redo aumentó de 4 GB a 512 GB, el LSN pasó a ser un número entero sin firmar de 8 bytes. El aumento refleja que se requerían bytes adicionales para almacenar información de tamaño adicional. Las aplicaciones creadas en MySQL 5.6.3 o versiones superiores que utilizan valores LSN deben usar variables de 64 bits, en lugar de 32 bits, para almacenar y comparar los valores LSN. Para obtener más información acerca de los LSN de MySQL, consulte la documentación de MySQL.

Para obtener el LSN actual de una base de datos de MySQL, ejecute el siguiente comando.

mysql> show master status;

La consulta devuelve un nombre de archivo binlog, la posición y otros valores. El punto de inicio nativo de CDC es una combinación del nombre y la posición del archivo binlogs, como mysql-bin-changelog.000024:373. En este ejemplo, mysql-bin-changelog.000024 es el nombre de archivo de binlogs y 373 es la posición en la que AWS DMS debe comenzar a capturar los cambios.

Uso de un punto de comprobación como punto de inicio de CDC

Una tarea de replicación continua migra los cambios y AWS DMS almacena en caché información sobre los puntos de comprobación que es específica de AWS DMS de vez en cuando. El punto de control que AWS DMS crea contiene información para que el motor de replicación conozca el punto de recuperación del flujo de cambios. Puede utilizar el punto de comprobación para retroceder en la escala de tiempo de los cambios y recuperar una tarea de migración que haya producido un error. También puede utilizar un punto de comprobación para iniciar otra tarea de replicación continua para otro destino en cualquier punto en el tiempo.

Puede obtener la información del punto de comprobación de una de las siguientes tres formas:

• Ejecute la operación de la API DescribeReplicationTasks y consulte los resultados. Puede filtrar la información por tarea y buscar el punto de comprobación. Puede recuperar el último punto de comprobación cuando la tarea está detenida o tenga el estado de error. Esta información se pierde si se elimina la tarea.

• Consulte la tabla de metadatos denominada awsdms_txn_state en la instancia de destino. Puede consultar la tabla para obtener información del punto de comprobación. Para crear la tabla de metadatos, establezca el parámetro TaskRecoveryTableEnabled en Yes cuando cree una tarea. Este valor hace que AWS DMS escriba la información del punto de control en la tabla de metadatos de destino de forma continua. Esta información se pierde si se elimina la tarea.

  Por ejemplo, el siguiente es un ejemplo de punto de comprobación en la tabla de metadatos: checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121

• En el panel de navegación, elija Tareas de migración de bases de datos y elija la tarea principal de la lista que aparece en la página de tareas de migración de bases de datos. Se abre la página de tareas principal, que contiene los detalles generales. Localice el valor del punto de control en Change data capture (CDC) [Captura de datos de cambio (CDC)], Change data capture (CDC) start position [Posición inicial de la captura de datos de cambio (CDC)] y Change data capture (CDC) recovery checkpoint [Punto de control de recuperación de la captura de datos de cambio (CDC)]. El valor del punto de comprobación tiene un aspecto similar al siguiente:

  checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

Parar una tarea en un punto en el tiempo de confirmación o del servidor

Con la introducción de los puntos de inicio nativos de CDC, AWS DMS también puede detener una tarea en los puntos siguientes:

• Un punto en el tiempo de confirmación en el origen

• Un punto en el tiempo de servidor en la instancia de replicación

Puede modificar una tarea y establecer una hora en UTC para detener una tarea, según sea necesario. La tarea se detiene automáticamente en función de la hora de confirmación o de servidor que haya establecido. Además, si al crear la tarea sabe que hay un punto adecuado para detener la tarea de migración, puede establecer la hora de detención durante la creación.

nota

La primera vez que inicie una nueva replicación sin servidor de AWS DMS pueden tardar hasta 40 minutos en inicializarse todos los recursos. Tenga en cuenta que la opción server_time solo se aplica una vez que se haya completado la inicialización del recurso.

Realizar la replicación bidireccional

Puede utilizar tareas de AWS DMS para ejecuta la replicación bidireccional entre dos sistemas. En la replicación bidireccional, se replican datos de la misma tabla (o un conjunto de tablas) entre dos sistemas en ambas direcciones.

Por ejemplo, puede copiar la tabla EMPLOYEE de la base de datos A en la base de datos B y replicar los cambios de la tabla de la base de datos A en la base de datos B. También puede replicar los cambios de la tabla EMPLOYEE de la base de datos B de nuevo en la base de datos A. En ese caso, estará realizando una replicación bidireccional.

nota

La replicación bidireccional de AWS DMS no se ha diseñado como una solución multimaestra completa que incluya un nodo principal, la resolución de conflictos, etc.

Utilice la replicación bidireccional en aquellos casos en los que haya datos de diferentes nodos segregados operacionalmente. En otras palabras, supongamos que tiene un elemento de datos que ha sido modificado por una aplicación que opera en el nodo A y que el nodo A realiza una replicación bidireccional con el nodo B. Ese elemento de datos del nodo A nunca podrá ser modificado por una aplicación que opere en el nodo B.

AWS DMS admite la replicación bidireccional en estos motores de bases de datos:

• Oracle

• SQL Server

• MySQL

• PostgreSQL

• Amazon Aurora MySQL-Compatible Edition

• Aurora PostgreSQL-Compatible Edition

Creación de tareas de replicación bidireccional

Para habilitar la replicación bidireccional de AWS DMS, configure los puntos de enlace de origen y destino en las dos bases de datos (A y B). Por ejemplo, configure un punto de enlace de origen en la base de datos A, un punto de enlace de origen en la base de datos B, un punto de enlace de destino en la base de datos A y un punto de enlace de destino en la base de datos B.

A continuación, cree dos tareas: una tarea que mueva los datos del origen A al destino B y otra tarea que mueva los datos del origen B al destino A. Además, asegúrese de que cada tarea esté configurada con la prevención de bucle invertido. De este modo, evitará que se repliquen cambios idénticos en los destinos de ambas tareas, lo que dañaría los datos de uno de ellos, por lo menos. Para obtener más información, consulte Prevención de bucle invertido.

Para simplificar el enfoque, comience con los conjuntos de datos idénticos tanto de la base de datos A como de la base de datos B. A continuación, cree dos tareas solo de CDC: una tarea para replicar datos de A en B y otra tarea para replicar datos de B en A.

Si desea usar AWS DMS para crear instancias de un nuevo conjunto de datos (base de datos) en el nodo B desde el nodo A, haga lo siguiente:

1. Utilice una carga completa y una tarea de CDC para mover los datos de la base de datos A a B. Asegúrese de que ninguna aplicación modifique los datos de la base de datos B durante este tiempo.

2. Cuando se haya completado la carga completa y antes de que se permita a las aplicaciones modificar los datos de la base de datos B, anote la hora o la posición de inicio del CDC de la base de datos B. Para obtener instrucciones, consulte Realizar la replicación comenzando desde un punto de inicio de CDC.

3. Cree una tarea solo de CDC que mueva de nuevo los datos de la base de datos B a A utilizando esta hora de inicio o esta posición de inicio de CDC.

nota

Solo una tarea del par bidireccional puede cargarse completamente y someterse a CDC.

Prevención de bucle invertido

Para ilustrar la prevención del bucle invertido, supongamos que, en una tarea T1, AWS DMS lee los registros de cambios de la base de datos de origen A y aplica los cambios a la base de datos de destino B.

A continuación, una segunda tarea, T2, lee los registros de cambios de la base de datos de origen B y los aplica de nuevo a la base de datos de destino A. Antes de que T2 lo haga, DMS debe asegurarse de que los mismos cambios realizados en la base de datos de origen B procedentes de la base de datos de origen A no se realicen en la base de datos de origen A. En otras palabras, DMS debe asegurarse de que estos cambios no se replican (en bucle) de nuevo en la base de datos de destino A. De lo contrario, los datos de la base de datos A podrían dañarse.

Para evitar el bucle invertido de los cambios, agregue la siguiente configuración a cada tarea de replicación bidireccional. De este modo, tendrá la seguridad de que la corrupción de datos que provoca el bucle invertido no se produzca en ninguna dirección.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": Boolean,
    "SourceSchema": String,
    "TargetSchema": String
  },

. . .
}

La opción LoopbackPreventionSettings de una tarea determina si una transacción es nueva o si es un eco de la tarea de replicación opuesta. Cuando AWS DMS aplica una transacción a una base de datos de destino, actualiza una tabla de DMS (awsdms_loopback_prevention) con una indicación del cambio. Antes de aplicar cada transacción a un destino, DMS omite todas las transacciones que incluyan una referencia a esta tabla awsdms_loopback_prevention. Por lo tanto, no aplica el cambio.

Incluya esta configuración con cada tarea de replicación en pares bidireccionales. Esta configuración habilita la prevención de bucle invertido. También especifica el esquema de cada base de datos de origen y de destino en la tarea que incluye la tabla awsdms_loopback_prevention para cada punto de enlace.

Para permitir que cada tarea identifique este tipo de ecos y los descarte, establezca EnableLoopbackPrevention en true. Para especificar un esquema en el origen que incluya awsdms_loopback_prevention, establezca SourceSchema en el nombre de ese esquema en la base de datos de origen. Para especificar un esquema en el destino que incluya la misma tabla, establezca TargetSchema en el nombre de ese esquema en la base de datos de destino.

En el ejemplo siguiente, las opciones TargetSchema y SourceSchema de una tarea de replicación  T1 y la tarea de replicación opuesta T2 se especifican con valores opuestos.

La configuración de la tarea T1 es la siguiente.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "LOOP-DATA",
    "TargetSchema": "loop-data"
  },

. . .
}

La configuración de la tarea opuesta T2 son los siguientes.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "loop-data",
    "TargetSchema": "LOOP-DATA"
  },

. . .
}

nota

Si usa AWS CLI, utilice solo el comando modify-replication-task o create-replication-task para configurar LoopbackPreventionSettings en las tareas de replicación bidireccional.

Restricciones de la replicación bidireccional

La replicación bidireccional de AWS DMS tiene las siguientes limitaciones:

• La prevención de bucle invertido solo realiza un seguimiento de las instrucciones del lenguaje de manipulación de datos (DML). AWS DMS no permite la prevención de bucle invertido en el lenguaje de definición de datos (DDL). Si desea habilitarla en este lenguaje, configure una de las tareas de un par bidireccional para que filtre las instrucciones de DDL.

• Las tareas que utilizan la prevención de bucle invertido no permiten confirmar cambios en lotes. Para configurar una tarea con la prevención de bucle invertido, asegúrese de establecer BatchApplyEnabled en false.

• La replicación bidireccional de DMS no incluye la detección o resolución de conflictos. Para detectar incoherencias en los datos, utilice la validación de datos en ambas tareas.