Hace unas semanas el equipo de Sistemas de Paradigma tuvimos la suerte de asistir a un Workshop organizado por AWS sobre su servicio AWS Database Migration Service (DMS) y Schema Conversion Tool (SCT) y conocer de primera mano cuáles son las ventajas de trabajar con este tipo de herramientas.

AWS Database Migration Service

En la primera parte del workshop se describieron las funcionalidades del servicio AWS Database Migration Service (DMS). Se trata de un servicio ideado para ayudar en las tareas de migración de datos entre bases de datos del mismo, o diferente tipo, a la nube.

Permite dividir o unificar bases de datos, enviar flujos de datos a Amazon Redshift desde multitud de fuentes (Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SAP ASE and SQL Server) e incluso mantener una réplica de la base de datos con alta disponibilidad. Es un servicio ideado para facilitar la migración de grandes bases de datos (del orden de Petabytes) sin pérdida de servicio.

Como el procedimiento que sigue para la migración empieza realizando una copia y modificación de los datos y, una vez copiados, sincroniza continuamente los elementos que se hayan podido modificar. Esto permite que este servicio pueda usarse para mantener sincronizadas y en alta disponibilidad dos bases de datos de distinto (o mismo) tipo remotas (puede incluir instancias que no se encuentren en la nube). Esto es muy útil para tener un Backup actualizado de BBDD o posibles escenarios de Disaster Recovery.

La versatilidad de este servicio hace que sea una pieza fundamental a la hora de gestionar desde proyectos de migración de grandes BBDD, hasta pequeños proyectos de gestión de un backup de BBDD en la nube para situaciones de Disaster Recovery o unificación de múltiples BBDD en una única BBDD común en la nube.

AWS Schema Conversion Tool

Así mismo, AWS facilita una herramienta para la gestión de las migraciones: AWS Schema Conversion Tool. Se trata de una programa que cualquiera puede descargar e instalar en su equipo (tiene una versión para los sistemas operativos Microsoft Windows, Apple Mac, Fedora Linux y Ubuntu Linux), que permite gestionar de forma más amigable la automatización de los cambios a realizar. Las posibles relaciones entre tipos de bases de dato origen y destino son las siguientes:

Como se trata de una herramienta para adaptar funciones y bases de datos del tipo Oracle o SQL Server al servicio AWS requerido, el destino debe ser estar siempre en AWS (bien Redshift, RDS o EC2). Algunas de las tareas sobre las que aporta mayor utilidad esta herramienta son por ejemplo:

• En caso de que al migrar un dato de una BBDD a otra no exista ese tipo de dato concreto. En este caso, el procedimiento que se seguiría por defecto (sin usar SCT) consistiría en realizar un mapeo al tipo de dato más parecido, pero gracias a esta herramienta, se podría modificar esta política por defecto y asignar al tipo que mejor nos venga.
• Para migración de grandes bases de datos tipo Oracle y Teradata a Redshift de forma ordenada.

Consejos antes de afrontar un proyecto de migración de bases de datos a la nube

Uno de los puntos fuertes del workshop fueron los consejos y pautas que nos facilitaron a la hora de gestionar este tipo de proyectos de migración de BBDD:

1. Cómo estimar correctamente este tipo de proyectos: No debería realizarse esta estimación antes de conocer por ejemplo cómo se gestionará la conectividad con la base de datos, los tiempos que la gestión de esos accesos conllevan, que persona o personas por parte del cliente gestionará este proyecto (así como sus conocimientos), obviamente el tamaño, tipo y tipo de los datos de la base de datos, requisitos de disponibilidad del cliente (si es posible tener algún tiempo mínimo de caída o indisponibilidad de la base de datos...), si la BBDD original se seguirá utilizando, usuarios, roles y permisos de acceso (por si hubiera que realizar algún tipo de integración de los sistemas de identificación tipo LDAP o AD del cliente)...
2. Todos esos puntos pueden hacer que varíe la estimación desde una semana a varios meses, e incluso el tiempo mismo de la migración. Por ejemplo, hay un tipo de datos cuya migración es muy costosa usando DMS (objetos de tipo BLOLS o CLOBs). En caso de que nuestra BBDD tenga muchos objetos de este tipo no es muy recomendado utilizar esta herramienta. Así mismo es posible que en caso de haber tipo de datos específicos, no estén soportados por DMS.Una buena recomendación es la de hacer uso de servicios tipo AWS Snowball para bases de datos muy grandes, de forma que se acorten los tiempos de transferencia de los datos.
3. La importancia de activar los logs del proceso en modo debug antes de iniciar el proceso de migración**:** Es importante porque en ocasiones, en caso de algún error en la migración, es posible que no se muestre ningún aviso del error en la consola de aws y sí en los logs.Por último, es importante recordar que hay momentos en los que el uso de esta herramienta no aporta mucho y es preferible utilizar herramientas nativas de cada BBDD. Por ejemplo si el destino soporta replicación y migrado de forma nativa, en caso de no tener que realizar ningún tipo de transformación de BBDD (o de los mismos datos durante el proceso), cuando hay muchos objetos de tipo BLOLS o CLOBs, o si se trata simplemente de mover toda la base de datos.

Conclusión

En definitiva, tanto AWS DMS como la aplicación SCT son herramientas con las que AWS da en el blanco a la hora de resolver los problemas con los que se encuentra un administrador de bases de datos tanto para el caso de migración de base de datos como para mantener una réplica sincronizada en otro emplazamiento, o para entornos de disaster recovery.

hbspt.cta.load(2189055, '3733f91c-e3fa-4e62-b6ce-12833fc684f5', {});