Cómo trabajar con soporte nativo de CDC en AWS DMS

Por Ganesh Raja, Arquitecto de Soluciones en AWS

AWS Database Migration Service (AWS DMS) lanza hoy soporte nativo de CDC y la capacidad de iniciar y detener la replicación de AWS DMS desde un punto de control (checkpoint) específico. Cuando usted trabaja con esta función, puede utilizar puntos de control como un número de secuencia de registro (LSN, log sequence number) en Microsoft SQL Server, un número de cambio de sistema (SCN, system change number) en Oracle y un punto de control de recuperación específico de AWS DMS. Como parte de esta versión, también estamos lanzando la capacidad de detener la replicación de datos y volver a iniciarla utilizando la característica de punto de control de AWS DMS.

Con este lanzamiento, AWS DMS permite a los clientes utilizar el mismo mecanismo que utiliza la base de datos para la secuenciación de commit, que es el número de secuencia de registro (LSN, log sequence number). El lanzamiento también abre más casos de uso de integración. Por ejemplo, ahora puede usar Oracle Data Pump o SQL Server BCP para realizar la carga inicial de datos en una base de datos de destino y luego usar los números de secuencia de registro DMS para iniciar la captura de cambio de datos (CDC, change data capture). Con la característica de punto de control lanzada junto con el soporte nativo de punto de inicio, puede hibernar entornos y procesar cambios desde la última vez que se realizó la replicación. Por ejemplo, puede replicar los cambios una vez al día desde el último punto de control.

En el lanzamiento, apoyamos las bases de datos Oracle, SQL Server y MySQL, y también Amazon Aurora con compatibilidad MySQL. Se planea seguir el apoyo a otras bases de datos.

AWS DMS: Lo elemental

AWS Database Migration Service le ayuda a migrar bases de datos a AWS de forma fácil y segura. La base de datos origen permanece completamente operativa durante la migración, minimizando el tiempo de inactividad de las aplicaciones que dependen de la base de datos. AWS Database Migration Service puede migrar sus datos hacia y desde las bases de datos comerciales y de código abierto más utilizadas.

El servicio soporta migraciones homogéneas como Oracle a Oracle, y también migraciones heterogéneas entre diferentes plataformas de bases de datos, como Oracle a Amazon Aurora o Microsoft SQL Server a MySQL. También puede utilizar AWS DMS para transmitir datos a Amazon Redshift, Amazon DynamoDB y Amazon S3 desde cualquiera de los orígenes soportados, como Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SAP ASE, SQL Server y MongoDB. Además, usted puede utilizar AWS DMS para la replicación continua de datos con alta disponibilidad.

AWS DMS realiza replicación continua de datos mediante la captura de cambio de datos (CDC, change data capture). Al usar CDC, usted puede determinar y realizar un seguimiento de los datos que han cambiado y proporcionarlos como un flujo de cambios que una aplicación puede consumir más adelante. La mayoría de los sistemas de gestión de bases de datos administran una bitácora de transacciones (transaction log) que registra los cambios realizados en el contenido de la base de datos. Al utilizar las operaciones y funciones de la API específicas del motor, AWS DMS lee la bitácora de transacciones. AWS DMS captura los cambios realizados en la base de datos de manera no intrusiva.

Presentamos Ejemplo Corp.

Nuestro cliente ficticio Ejemplo Corp. tiene un conjunto típico de consideraciones para abordar el uso de AWS DMS. Ejemplo Corp. tiene una base de datos Oracle de 10 TB y quiere crear una copia de solo lectura de la base de datos en Aurora con compatibilidad con PostgreSQL para la elaboración de reportes. También quieren posiblemente migrar esta aplicación a AWS. Están considerando usar Aurora con compatibilidad con PostgreSQL en lugar de una base de datos Oracle. También quieren probar la aplicación en AWS con datos de producción reales.

En esta publicación, veamos cómo Ejemplo Corp. puede cumplir con sus requisitos utilizando las nuevas características de AWS DMS.

Registros de transacciones en bases de datos

Los registros de transacciones (transaction logs) capturan cada cambio realizado en el sistema de base de datos. El registro (log) contiene suficiente información sobre cada transacción ejecutada que el servidor de base de datos debe poder recuperar el clúster de base de datos. Lo hace así en caso de una caída del servidor al volver a reproducir los cambios y acciones en el registro de transacciones. El registro de transacciones también registra un número de incremento llamado número de secuencia de registro o LSN.

Oracle utiliza el término redo logs para los registros de transacciones y el término número de cambio de sistema (SCN) para el número de secuencia de registro (LSN). Archivos de redo log de Oracle, similares a los registros de transacciones, rastrean los registros de redo. Un registro redo es un conjunto de vectores de cambio que describen los cambios realizados a un solo bloque en la base de datos. Un bloque de datos es la unidad de datos más pequeña utilizada por una base de datos.

Durante una transacción, se notifica a un proceso de usuario la finalización exitosa de la transacción solo después de que los registros de redo necesarios sean escritos en disco. Cada vez que ocurre un commit, la base de datos asigna un SCN, similar a un LSN, para identificar los registros de redo para cada transacción completada.

Requisitos de presentación de informes de Ejemplo Corp.

Ejemplo Corp. quiere que su aplicación de reportes se ejecute en una base de datos de Aurora con compatibilidad con PostgreSQL, y migrar su base de datos Oracle local a Aurora con compatibilidad con PostgreSQL.

Para convertir el esquema mediante AWS SCT y migrar los datos mediante AWS DMS, Ejemplo Corp. siguió las instrucciones de la publicación Una introducción rápida a la migración de una base de datos Oracle a una base de datos de Amazon Aurora con base de datos con compatibilidad con PostgreSQL en el blog de base de datos de AWS.

Ejemplo Corp. no migró datos existentes de su base de datos de producción sino que creó una copia de la base de datos en un punto en el tiempo y configuraron los endpoints origen a esa base de datos para migrar los cambios existentes. Este enfoque garantiza que la base de datos de producción no tuviera una carga adicional de AWS DMS durante la migración completa.

Si bien Ejemplo Corp. quería iniciar CDC en la base de datos Oracle utilizada por la aplicación, se dieron cuenta de que usar un tiempo específico para iniciar CDC no era ideal, debido al alto número de transacciones por segundo (TPS, transactions per second). El alto TPS hizo imposible encontrar un tiempo que asegurara que las transacciones no se duplicaran ni se perdieran.

Ambiente de reportes de Ejemplo Corp.

Ejemplo Corp. también siguió las instrucciones en la entrada de blog mencionada anteriormente para convertir su esquema y migrar los datos a Aurora con compatibilidad con PostgreSQL. Después de migrar los datos existentes, Ejemplo Corp. tuvo que cambiar el endpoint de origen para reflejar la base de datos de producción a partir de la cual hacer CDC y migrar los datos. Tomaron los siguientes pasos para crear un ambiente de reportes en AWS en Aurora con compatibilidad con PostgreSQL.

Creación de una tarea DMS para CDC

En la consola de administración de AWS, primero cree una nueva tarea con el nuevo endpoint de origen que refleja la base de datos de producción y los endpoints de destino a Aurora con compatibilidad con PostgreSQL. Seleccione la opción para replicar sólo los cambios de los datos. Debido a que ya hemos migrado todos los datos usando DMS previamente, seleccione Do nothing for Target table preparation mode (No hacer nada para el modo de preparación de tabla Destino).

Obtención de un SCN en Oracle

La siguiente consulta le da el último SCN desde cual iniciar la replicación de bases de datos. DMS puede usar este SCN para iniciar el CDC en un punto en el tiempo.

SELECT
      SCN,
      scn_to_timestamp(scn) SCN_TimeStamp
    FROM (
          SELECT dbms_flashback.get_system_change_number() as SCN
          FROM dual
        )

Ajustes de tareas para CDC

A continuación, necesitamos configurar CDC para iniciar desde el SCN obtenido en el paso anterior.

En la sección de Log Sequence Number (Número de secuencia de registro), se introduce el SCN obtenido en el paso anterior de la base de datos Oracle. Después de crear la tarea, podemos iniciar la tarea y monitorearla desde la consola de DMS.

Empezar desde un número de secuencia de registro ayuda a garantizar que no perdamos ninguna transacción y que el punto de inicio para los CDC esté bien definido.

Ambiente de migración de Ejemplo Corp.

Como parte de la migración a Aurora con compatibilidad con PostgreSQL desde una base de datos Oracle, Ejemplo Corp. quiere detener e iniciar el proceso de los CDC. Quieren esto para que puedan probar su aplicación sin la carga del servicio CDC. La característica de punto de control en DMS permite detener e iniciar la replicación sin depender de la base de datos de origen LSN o SCN.

Para ello, Ejemplo Corp. siguió el procedimiento descrito anteriormente en la creación de un entorno de grabación para crear una segunda réplica de la base de datos. No obstante, esta vez utilizaron la función de punto de control para detener e iniciar la replicación.

Utilizando este enfoque, Ejemplo Corp. puede detener la replicación a una determinada hora del día o en una determinada hora de compromiso (commit time).

DMS asegura que los CDC se detienen en el momento particular del servidor o en el tiempo de commit descrito en la configuración de tareas. DMS también escribe contínuamente información de metadatos en una tabla de la base de datos de destino. Con estos datos de punto de control almacenados, Ejemplo Corp. puede cerrar la instancia de replicación y las tareas para ahorrar en costo.

Reiniciando CDC

Ejemplo Corp. quiere replicar datos solo durante la noche y replicar solo datos que cambiaron desde la última replicación.

Para que esto sucediera, Ejemplo Corp. primero ejecutó una consulta contra la tabla de metadatos en la instancia de destino—awsdms_txn_state—para obtener los datos del punto de control. Luego iniciaron una nueva instancia de replicación y crearon una tarea para iniciar la replicación desde el punto de control obtenido en el paso anterior, como se muestra en la siguiente captura de pantalla.

Hacer esto aseguró que solo pagaran por la instancia de replicación cuando se realizaba la replicación y que hibernaran el entorno en todos los demás momentos.

También puede obtener información de puntos de control como parte de los resultados de una llamada a la acción API describe-replication-tasks . Entonces simplemente filtra por tareas y busca el punto de control para obtener esta información. Puede recuperar el último punto de control cuando la tarea de replicación se encuentra en un estado detenido o fallido.

En la siguiente entrada del blog, podemos ver cómo Ejemplo Corp. automatizó este proceso utilizando funciones de AWS Lambda y plantillas de AWS CloudFormation .

Conclusión

Aunque los requisitos de Ejemplo Corp. eran migrar una base de datos Oracle, AWS DMS puede trabajar con bases de datos comerciales y de código abierto. DMS proporciona la misma funcionalidad para los puntos de inicio nativos y los puntos de control para ambos.

En esta publicación, aprendimos cómo Example Corp. creó un ambiente de reportes utilizando soporte nativo de SCN. También vimos cómo Ejemplo Corp., utilizando la nueva función de punto de control, ahorró en costos al ejecutar las instancias de replicación solo cuando querían y replicaban solo datos que se cambiaron con respecto al punto en el tiempo anterior.

Este artículo fue traducido automáticamente del  Blog de AWS en Inglés.

Sobre el autor

Ganesh Raja es arquitecto de soluciones en Amazon Web Services. Gansh trabaja con nuestros clientes para brindar orientación y asistencia técnica en proyectos de bases de datos, ayudándoles a mejorar el valor de sus soluciones al utilizar AWS.

Sobre el traductor

José Peñúñuri es Arquitecto de Soluciones de Amazon Web Services enfocado en el tema de migración y que trabaja con clientes de diferentes sectores. José se ha enfocado en apoyar a sus clientes  en la adopción de herramientas que los ayudan a acelerar su migración a AWS.