spinner

¿Os acordáis de AWS DMS? Un caso de uso

Un poco de memoria…¿Os acordáis de AWS DMS?

Después del artículo que publicamos en el blog de BBVA Next Technologies en el que nuestro compañero Alberto Cantalejo explicaba (y muy bien!) qué era AWS Database Migration Service (AWS DMS) y algunas de sus características, en este post me gustaría hablar de las opciones de configuración avanzada que nos ofrece este servicio, AWS DMS. Además,también quisiera dar algunos consejos para optimizar su funcionamiento, por lo que, para ello, voy a centrarme en un caso de uso de migración entre una base de datos Oracle y Redshift. Así que…¿Preparados para introduciros en el mundo de AWS DMS de nuevo?

Arquitectura de AWS DMS. Fuente: elaboración propia

Endpoint – Orígenes y destinos

Antes de empezar explicando el caso de uso concreto, debemos tener en cuenta que los endpoints (un elemento básico del proceso de DMS) tienen características distintas según la BBDD. Es por ello que los atributos extra varían según el origen y el destino.

Para empezar, y creo que puede resultar útil, vamos a enumerar los posibles tipos de base de datos que pueden actuar como source (origen) y como target (destino), cada motor de base de datos tiene un link a la documentación oficial de AWS en la cual se detallan todos los posibles atributos que se pueden configurar.

Ahora sí: un caso de uso, migrando de Oracle a Amazon Redshift

Supongamos que nos encontramos en la situación de tener que replicar una base de datos Oracle 12 en un cluster de Redshift (wow!). Tras la carga inicial queremos que el origen y el destino queden sincronizados en casi “tiempo real” (siempre habrá un lag) y vamos a ver cómo se configuraría un proceso DMS que realice esta tarea.

La pregunta es “¿cómo?” Para ello haremos una migración “full load + ongoing replication” desde una base de datos Oracle a nuestro cluster de Amazon Redshift.

La migración: paso a paso

1. Necesitaremos crear en nuestro destino el esquema que queremos replicar. Para ellos, AWS recomienda el uso de la herramienta AWS Schema Conversion Tool, muy útil para la conversión de esquemas de un motor de base de datos a otro. También nos ayudará a identificar problemas, limitaciones y acciones necesarias para realizar la conversión con éxito. También es posible crear el esquema destino manualmente o dejar que el propio DMS lo genere automáticamente. Puedes encontrar más información en la web de AWS.

2. Creación en la base de datos origen Oracle un un usuario para DMS y concederle los privilegios necesarios, que pueden verse en la sección “Privilegios de cuenta de usuario necesarios en un origen de Oracle autoadministrado para AWS DMS” de la documentación de AWS.

3. Levantar la instancia de replicación: se configura como una instancia EC2 y es la que utilizará DMS para ejecutar los procesos de replicación. Cuanto más potente y más espacio la asignemos, mayor volumen y tareas en paralelo será capaz de ejecutar.

4. Creación de Endpoints. Una vez creados los endpoint para el source y el target, y configurados sus parámetros básicos, vamos a profundizar en la configuración avanzada. Podemos elegir una clave KMS que nos permite cifrar los datos que se migren.
Además podemos añadir parámetros extra a la conexión en el campo “Extra connection attributes”.

Fuente: AWS DMS

El objetivo es configurar algunos atributos para que el desempeño en el target, en este caso Amazon Redshift sea más óptimo. En el anterior apartado se pueden encontrar los enlaces a la documentación de AWS donde se encuentran todos los atributos configurables para las distintas BBDD.

En base a nuestra experiencia, se muestran los siguientes atributos, con los cuales hemos comprobado una mejora del rendimiento al configurarlos correctamente (Esta configuración en concreto se aplica en el endpoint Source).

atributos endpoints AWS DMS

5. Tarea de Réplica. Al terminar de definir la configuración básica, se puede seleccionar “advanced settings” para especificar parámetros avanzados que mejoren la velocidad o el desempeño de la tarea. Las configuraciones que se pueden hacer son las siguientes:

  • «Control table settings»: Se definen las tablas de control que se crearán, así como la localización y el tiempo de vida.
  • «Tuning settings»: Se definen algunas configuraciones a aplicar durante la carga completa, que pueden tener bastante impacto en el desempeño de la misma.
  • «Maximum number of tables to load in parallel»: Este es uno de los parámetros más influyentes, bastante ligado con el tipo de instancia definida. Define la cantidad de tablas en paralelo que se cargarán, por defecto tiene marcado 8 tablas, en nuestra experiencia hemos llegado a 20 tablas en paralelo con un buen rendimiento.
  • «Transaction consistency timeout (seconds)»: El número de segundos que se espera el cierre de la transacción en caso de que esta esté abierta antes de empezar la carga completa. Esto se debe a que para mantener la consistencia en las transacciones y evitar que el Full Load + CDC capture solo parte de un una transacción, se realiza un chequeo de las transacciones abiertas en el momento de inicio de la tarea y se las espera un número determinado de segundos (el valor de «Transaction consistency timeout») a que terminen.¡OJO!: Estas transacciones no cerradas se perderán, requeriría hacer un “Drop table data and reload” tras su commit para poder recuperar los datos.
  • Commit rate during full load: El valor máximo de filas que se transferirán juntas.

Para finalizar: a tener en cuenta en una migración

Log de Oracle

Al leer el CDC del log de Oracle, es imprescindible que éste se almacene durante un período de tiempo razonable que permita al sistema reconectar en caso de incidencia o desconexión. De no ser así habría que reiniciar la tarea y volver a realizar la carga completa.

Primary keys

La existencia de primary keys en el esquema en Redshift ralentiza en la carga inicial el proceso, sin embargo, es vital para la ejecución del CDC, ya que de no tenerlas las operaciones de update se ralentizan hasta el punto de no llegar nunca a sincronizarse con origen si el volumen de transacciones no es muy bajo. Existe una opción que permite levantar las primary keys tras la carga inicial, “CreatePkAfterFullLoad” y se configuría en la Task. Tienes más información en AWS Database Migration Service.

Validaciones

En la creación de la Task, si activamos el check de “Enable Validation” se realizarán comprobaciones del número de filas en origen y destino. También en CDC comprueba el número de transacciones y hay que tener en cuenta que esta funcionalidad extra consume recursos en origen y destino. Tienes más info enAWS Database Migration Service.

Roles

Tanto DMS como Redshift es necesario que tengan permisos de escritura/lectura en S3, ya que DMS utiliza S3 para almacenar los ficheros de réplica.

¡Listo! Con estos pasos estás prácticamente preparado para usar AWS DMS. Espero que contarte mi experiencia con este caso de uso te haya sido útil y te ayude en tu trabajo. Desde luego y por mi parte, sólo me queda animarte a utilizar esta herramienta para que descubras las ventajas que tiene.

Imagen: Shutterstock

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?