Migrando hacia Amazon DocumentDB Offline con AWS DMS | DocDB Series parte 3

5 min readApr 7, 2021

📢 Un Milagro a la vez:

Queridos Mongo Lovers, ¿Existe el milagro de hacer una migración de base de datos sin muertos y sin bloqueos, sin amanecidas y sin dudas, sin zapatos y a manos libres? Bueno, empecemos primero conociendo el proceso de migración desde una instancia fuera de AWS hacia DocumentDB y luego iremos recorriendo los caminos de la automatización y homologación en tiempo real.

En este viaje hacia el perfeccionamiento y entendimiento de mejorar y optimizar cargas de trabajo de MongoDB en AWS, revisaremos muchos casos de uso y arquitecturas distintas. Como vemos aquí, nos encontramos en el paso 1: llamado Migración fuera de línea autogestionada.

🧩 Pre requisitos:

Instalar la versión de 3.6

https://docs.mongodb.com/v3.6/tutorial/install-mongodb-on-windows/

Direct Link Mongodb 3.6 for Windows MSI: https://fastdl.mongodb.org/win32/mongodb-win32-x86_64-2008plus-ssl-3.6.19-signed.msi

Crear Bastion Host: Levantar un EC2 con este AMI en Oregon:

ami-067f5c3d5a99edc80

Cambiar los bindings de mongodb en EC2 en mi bastion para que se conecte a nuestro DMS

sudo vim /etc/mongod.conf bindIp: 127.0.0.1 →0.0.0.0

Hacemos un restart para aplicar los cambios al servidor:

sudo service mongod status
mongod (pid 2612) is running…sudo service mongod restart
Stopping mongod: [ OK ]
Starting mongod:

🧩 Migrar con una tarea automática, desde Mongodb EC2 hacia DocumentDB

donde:

EC2: docdb-bastion (sin SSL ni password)
DocumentDB: docdb-001 (con SSL)
IP: 52.89.199.68

Nos conectamos a nuestro mongodb de prueba simulando que está fuera de AWS.

➜ ~ mongo 52.89.199.68 — port 27017

Para la base de datos de Destino, Creamos un cluster de documentDB con SSL/TLS activado. Esto lo hicimos en los 2 posts anteriores, puedes revisarlo aquí: (https://medium.com/aws-user-group-peru-oficial/primeros-pasos-con-amazon-documentdb-y-aws-cli-21430eb19168)

Cluster name: docdb-001username: ccortezPassword: admin,,123Cluster parameter group: defaultSubnet Group: default VPCSecurity Group: default, Inbound Rule: 27017→ 0.0.0.0/0

Bajar el CA: Certificate Authority:

wget https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem

Comprobar el funcionamiento del cluster creado:

mongo — ssl — host docdb-001.cluster-cgyttffk8nhp.us-west-2.docdb.amazonaws.com:27017 — sslCAFile rds-combined-ca-bundle.pem — username ccortez — password admin,,123

🧩 Crear Subnet Group para replicación en DMS:

🧩 Crear instancia de replicación en DMS:

Creemos con las siguientes configuraciones:

Name: mongotodocDescription: mongodb to documentdbInstance Class: dms.t3.medium (dms.t2.medium es la versión anterior)Engine Version: 3.4.3Allocated Storage: 50 GB

🧩 Crear endpoints: (source y target):

Los endpoints, o puntos de acceso, son las definiciones de nuestro origen y destino de nuestro proceso de migración. Sin importar si está en AWS o está fuera.

Para la Fuente de datos vamos a crear un “source endpoint” con los siguientes datos:

Source Endpoint

name: mongodb-zips-ec2source engine: mongodbserver name: 52.89.199.68auth: ningunouser/pass: -database: zips-db

Target Endpoint:

Para nuestro cluster de documentDB, vamos a necesitar los siguientes datos, en este caso estamos usando un clúster con SSL,

name: docdb-001source engine: mongodbserver name: docdb-001.cluster-cgyttffk8nhp.us-west-2.docdb.amazonaws.comssl mode: verify-fullCA Certificate: rds-combined-ca-bundleauth: ningunousername: ccortezpassword: admin,,123database: zips-db

Es importante agregar el Certificado .pem que podemos descargar desde la consola de documentDB:

Debemos habilitar el modo SSL, Secure Socket Layer,

Finalmente, podemos refrescar los esquemas en source y target endpoint hacia el replication instance.

🧩 Crear y correr una tarea de migración

Nos vamos a crear y ejecutar la tarea de migración auto gestionada por AWS DMS, para ello, necesitaremos los siguientes datos:

name: migration-task-001Replication instanceSource endpointTarget endpointschema: zips-db

La selección de esquemas es sumamente importante, y también sencilla, pero no hacerlo puede terminar en muchos errores de ejecución de tarea de migración. Migremos todos los esquemas colocando ‘%’ o especificando el nombre de la base de datos que queremos apuntar.

El tipo de migración será “Full Load”, y ya podemos crear la tarea. Seamos pacientes porque tomará unos minutos iniciarlo.

Y apenas terminemos de configurar, empezará a correr la tarea:

🧩 Conclusión

Esta es la manera más efectiva y rápida de migrar, y aún es importante conocer el método tradicional, así como actualizaciones posteriores a la migración para entender más sobre DMS y su característica de Change data Capture.

🧩 ¿Con qué continuamos?

En el próxima episodio veremos y recordaremos cómo migrar con solo comandos puros de MongoDB y ver el funcionamiento de DocumentDB,. subirlo a s3 y automatizar la tarea.

Siguiente post: (Al Aire el 06 de Abril)

Si te gustó este post, dale un like, comparte y comenta.