Migración MongoDb 2.4 -> 2.6 -> 3.0 (con replicas)

Migración MongoDB 2.4 -> 2.6 -> 3.2 (con replicas)

Este post pretende mostrar los pasos a seguir para la migración del mongoDB 2.4 a 3.2.

¿Por qué debemos migrar a 2.6 primero?

En la versión 2.6 se cambia el modelo de datos para las credenciales de los usuarios, como así también se agregan nuevas herramientas de auditoria. En el proceso de migración a esta versión se realizan los cambios de modelos necesario y la verificación del buen funcionamiento de las nuevas herramientas. Estas verificaciones y cambios en versiones posteriores no se realiza.

Migración de 2.4 a 2.6

Fuente de información para la migración: https://docs.mongodb.org/manual/release-notes/2.6-upgrade/

Lo primero que debemos hacer es descargarnos el mongoDb 2.6, esto es para usar su cliente y realizar por medio de este la migración.

64: https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.6.11.tgz

32: https://fastdl.mongodb.org/linux/mongodb-linux-i686-2.6.11.tgz

Para descargar los binarios para otras versiones u otros Sistemas Operativos ir a la siguiente url : https://www.mongodb.org/downloads#previous

La migración debe de comenzar por las réplicas secundarias siguiendo los siguientes pasos:

1- Conectarse a la réplica con el mongo 2.6:

1. ./mongo host:puerto -> Cambien el host según la réplica que estén actualizando y el puerto.

2- En la Shell de mongo ejecutar:

1. rs.stepDown() -> Este solo hay que ejecutarlo si el nodo es el primario, hace que otro nodo sea el primario.
2. rs.slaveOk() -> Ese comando es la forma corta de ejecutar el siguiente comando: db.getMongo().setSlaveOk(), lo que hace es habilitar en la conexión actual las operaciones de lectura en el miembro secundario (En la réplica).
3. use admin -> selecciona la base de datos “admin”.
4. db.upgradeCheckAllDBs() -> Realiza una comprobación de compatibilidad de todos los datos almacenados.

3- Actualizamos los binarios del mongoDb en el nodo(servidor):

1. Ingresamos al nodo.
2. Nos conectamos al MongoDb.
3. use admin -> cambiamos a admin.
4. db.shutdownServer() -> paramos el server. 
5. mv carpetaMongoBinarios carpetaMongoBinarios-2.4 -> renombramos la carpeta del mongo para instalar la nueva versión.
6. Descargamos la versión del MongoDB según nuestro Sistema Operativo (recordar que estamos migrando primero a la 2.6)
7. Levantamos el mongod nuevamente. Recuerden que tenemos que levantar el nodo con la misma configuración que tenia antes de migrar el binario. Este post supone que se tiene en una carpeta separada el archivo de configuración del mongod y el storage del mongo.
8. Esperamos que se ponga funcional.

Migración de 2.6 a 3.0

Los pasos para la migración de la versión 2.6 a la 3.0 son los mismos ya descritos para la migración de la 2.4 a la 2.6, solo hay que cambiar las referencias a las versiones 3.0 en donde corresponda.

¿Qué nos ofrece MongoDB 3.0?:

Nueva API de motor de almacenamiento de MongoDB que permite optimizar la base de datos para diferentes arquitecturas de hardware y cargas de trabajo de aplicaciones.
MongoDB 3.0 multiplica el rendimiento entre siete y diez veces, ofrece escalabilidad vertical para las cargas de trabajo de escritura intensiva mediante la recopilación y el bloqueo a nivel de documento. La compresión nativa reduce considerablemente los costes de almacenamiento hasta en un 80%. Ahora los conjuntos de réplicas pueden incluir hasta 50 miembros, lo que reduce la latencia al distribuir geográficamente los datos cerca de los usuarios.
Ampliación del marco de auditoría introducido en MongoDB 2.6 para incluir todas las operaciones de sistema y datos (DDL y DML) en la base de datos. Gracias a estas extensiones, ahora los administradores pueden crear y filtrar las trazas de auditoría de cualquier operación en MongoDB sin tener que recurrir a herramientas de terceros.

Definir el Engine WiredTiger

Para realizar correctamente el proceso hay que verificar los valores de los tamaños de los objetos almacenados y el tamaño de la base de datos antes de la migración al nuevo engine. Luego de la migración hay que volver a tomar los valores y comparar con los valores viejos, si los valores se redujeron la migración fue exitosa. Más grande sea la base más notorio va a ser la diferencia en el tamaño después de la migración.

Manos a la obra y a seguir los siguientes pasos:

1- Conectarse a la réplica que vamos a migrar (Comenzar por las secundarias y luego la primaria):

1. ./mongo host:puerto -> Solo es un ejemplo, cambien el host según la réplica que estén actualizando y el puerto.

2- En la Shell de mongo ejecutar:

1. rs.stepDown() -> Este solo hay que ejecutarlo si el nodo es el primario, hace que otro nodo sea el primario.
2. rs.slaveOk() -> Ese comando es la forma corta de ejecutar el siguiente comando: db.getMongo().setSlaveOk(), lo que hace es habilitar en la conexión actual las operaciones de lectura en el miembro secundario (En la réplica).
3. use Database -> La base de datos que se va a usar para realizar la comparación con el antes y el despues de la migración.
4. db.stats(1024*1024) -> Json con el estado de la base de datos, entre esos datos tenemos el tamaño total de la base y el tamaño por objeto entre otros. Tener en cuenta que si ponemos la escala 1024 lo tenemos en KB y si ponemos 1024*1024 lo tenemos en MB.

3- Bajar el servidor, para hacer esto hay dos alternativas:

1. db.shutdownServer() -> Esta es una de las opciones, no es la más recomendada.

4- Eliminar el contenido de la carpeta que contiene los datos con el viejo formato, al eliminarlo forzará una re sincronización y al realizar el mismo comprimirá los datos con el nuevo engine. (Revisar que no haya una carpeta montada dentro - “df -h”)

1. rm -r carpetaMongoConData/*

5- Agregar al archivo de configuración el uso del nuevo engine:

1. “storageEngine=wiredTiger” -> agregar al archivo mongodb.conf
2. mongod --storageEngine wiredTiger -> De esta forma se puede especificar en el comando para levantar el mongo. Sí se esta usando el archivo de configuración esta linea no es necesaria

6- Levantar el servidor de mongo:

1. mongod --storageEngine wiredTiger -> comando alternativo pero poco recomendado. Recordar que si se esta usando un archivo de configuración no es necesario agregar el parámetro

7- Mientras se levanta se va a sincronizar los datos y mientras dure la sincronización el nodo va a estar desactivado en la réplica.

8- Cuando termine la sincronización hay que repetir el paso 1 y 2 para verificar los nuevos valores y comprarlos con los viejos.

9- Repetir los pasos anteriores con los demás nodos.

Los pasos descritos anteriormente es una alternativa de migrar el engine, la otra es hacer un dump de la base de datos y luego un restore, para más información de este proceso revisar el siguiente link.

https://docs.mongodb.org/v3.0/release-notes/3.0-upgrade/

Para más información de las características del mongo 3.0 ir al siguiente link.

http://es.slideshare.net/JonRangel/let-the-tiger-roar-mongodb-30-wiredtiger

Happy Hacking } ; ) by Tahuri