Migrando hacia Amazon DocumentDB Offline con AWS DMS | DocDB Series parte 3
📢 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.
☢ Rompiendo se aprende
⭐ Visita mi web principal,
Breaking the Cloud y Al día con AWS en
https://aldiaconaws.cortez.cloud
https://aiformortals.cortez.cloud
⭐Suscríbete a mi canal de Youtube :
https://youtube.com/c/carloseduardocortezbazan
encontrarás: videos, noticias de AWS, análisis, demos, workshops
🔥🔥 Sígueme en mis redes 🔥🔥
follow <- me()
🦜 Mi Twitter: https://twitter.com/ccortezb
📺 Youtube Channel: http://bit.ly/aldiaconaws
📺 AWSUGPerú: https://www.youtube.com/awsusergroupperuoficial
📟 Mi Facebook: https://www.facebook.com/ccortezb/
🤳 Mi Instagram: ccortezbazan
📜 Mis cursos de AWS: https://cennticloud.thinkific.com
🕮 Mi blog — cortez.cloud
Muchas gracias, espero nos volvamos a ver
🔥🔥 Acerca de mí 🔥🔥
Les presento mi pequeña web personal https://www.Cortez.Cloud llamado “Breaking the Cloud”.
Seguiré creando contenido cada semana de AWS sobre Al/ML, Serverless, Security y como romper las reglas!
También mis próximas iniciativas, talleres, cursos, videos gratuitos, awsugperu y más.