Cómo actualizar tu instalación de MongoDB a la versión 3.0

MongoDBShardedClusterUpgradeHa llegado el momento de actualizar nuestra instalación de MongoDB, ¿sabemos cómo hacerlo? En este artículo explicaré los pasos a seguir, tanto si tenemos un único nodo, una Replica Set o un Sharded Cluster. Nos centraremos en la actualización a la versión 3.0.

Release and Upgrade Notes

Antes de comenzar siempre hemos de leer las Release Notes y las Upgrade Notes, sobre todo entre major releases. Aquí os dejo los enlaces a la documentación oficial:

Descarga de binarios

Independiente de la configuración que tengamos, siempre vamos a necesitar los binarios de la nueva versión a instalar. Desde la siguiente url podremos descargarlos:

Downloads – MongoDB

Obtendremos un fichero comprimido que será necesario descomprimir para poder acceder a los binarios.

Como siempre, escogeremos la versión que más nos convenga, pudiendo escoger entre:

SO 64 bit 32 bit
Linux
Mac OS X
Windows
Solaris

Restricciones

Hemos de saber que para actualizar a la versión 3.0 es necesario tener instalada la versión 2.6.

Una vez que hayamos instalado la versión 3.0 no podremos volver a una inferior a la 2.6.5.

Actualización de paquetes

Si hemos instalado MongoDB desde los repositorios apt, yum o zypper, actualizaremos la versión utilizando el package manager, aquí se indica cómo hacerlo: instrucciones de instalación.

Actualización de una instalación de un único nodo

Estos son los pasos que debemos seguir:

  1. Paramos nuestra instancia de mongod.
  2. Reemplazamos los binarios actuales con los de la versión a instalar (la 3.0).
  3. Reiniciamos la instancia.

Para parar la instancia podemos utilizar alguno de los comandos siguientes:

Y para reiniciar la instancia:

Actualización de una Replica Set

Objetivos

A la hora de realizar trabajos de mantenimiento (como puede ser actualizar la versión) en los nodos de una Replica Set tendremos dos objetivos:

  1. No correr ningún tipo de riesgo.
  2. No interrumpir el servicio en ningún momento.

Requisitos

  1. La Replica Set ha de tener un mínimo de tres nodos, con dos secundarios completos para no correr ningún riesgo y tener, en todo momento, dos copias de los datos. Esto no podría darse si tuviéramos, por ejemplo, un primario, un secundario y un árbitro, porque sólo tendríamos una copia de los datos (la del primario) mientras durara la actualización.
  2. El oplog time será lo suficientemente grande como para no perder nada de lo que ocurra durante la actualización. El oplog es una capped collection y en ella se guardan todas las operaciones que se hacen en la base de datos. Este ‘registro’ nos servirá para poner al día el nodo que estamos actualizando una vez que vuelva a estar operativo. Si el tiempo que nos van a llevar nuestros trabajos de mantenimiento (actualización en este caso) es inferior al tiempo que somos capaces de guardar en ese oplog, no perderemos ninguna operación cuando se actualice el servidor al reincorporarse a la Replica Set. Podemos conocer el tamaño de nuestra ventana de oplog a través del comando

Pasos a seguir con los nodos secundarios

Lógicamente los secundarios de una misma Replica Set se han de actualizar de uno en uno para disponer siempre de dos copias de nuestros datos.

  1. Paramos la instancia mongod. La Replica Set sigue funcionando con el primario y un secundario (estos seguirán haciendo ping al nodo caído para comprobar su estado).
  2. Sustituimos los binarios por los de la nueva versión.
  3. Levantamos la instancia de nuevo con las mismas opciones que tenía.
  4. Esperamos a que el nodo actualizado se ponga al día antes de pasar a actualizar el otro secundario. Para saber cuándo ha terminado la replicación al nodo actualizado podemos utilizar el comando

    y comprobar que el valor optimeDate es igual para todos los nodos (principal y secundarios).

Pasos a seguir con el nodo primario

  1. Cerramos las conexiones existentes con los drivers y, a la vez que convertimos nuestro primario en secundario, provocamos una elección de primario. Esto lo conseguimos con el comando

    Los drivers establecerán conexión automáticamente con el nuevo primario y sin apenas penalización en tiempo. Hemos de saber que un Replica Set failover no es instantáneo y que mientras se completa no se pueden realizar escrituras.
  2. A partir de este momento los pasos a aplicar son los cuatro vistos anteriormente para los nodos secundarios.

Actualización de un Sharded Cluster

Sólo actualizaremos sharded clusters a la versión 3.0 si todos los miembros del cluster ejecutan instancias de la versión 2.6.

Un Sharded Cluster está compuesto por Replica Sets pero, además, contiene:

  • Config Servers (contienen la base de datos que relaciona el dato con el shard en el que se encuentra) y
  • mongos processes (enrutan las peticiones al shard que le indica el config server en función del dato al que se quiere acceder)

Recomendaciones

  • Es recomendable hacer una copia de seguridad de la base de datos ‘config’ antes de actualizar el cluster.

Requisitos

  1. Debemos asegurarnos de que ningún cliente realiza operaciones que modifiquen el meta-data (la base de datos config) mientras dure el proceso de actualización del cluster.
  2. Primero actualizaremos el meta data, después los mongos y, por último, los mongod.

Pasos a seguir

  1. Desactivamos el balanceador (si hay alguna operación en proceso el sistema espera a que termine)
  2. Actualizamos el metadata del cluster
    1. Actualizamos un mongos a la versión 3.0
    2. Levantamos el mongos con las mismas opciones que tuviera y añadimos –upgrade (esta ejecución terminará cuando termine la actualización). En caso de que no hubiéramos parado el balanceador nos avisaría el sistema. Mientras dure este proceso el sistema no realizará ningún split ni moverá chunk alguno. Veremos el siguiente mensaje cuando la actualización del meta data haya ido bien:
    3. Actualizamos a la versión 3.0 las dos instancias mongos restantes
    4. Levantamos los tres mongos, ya sin la opción –upgrade
    5. Actualizamos los tres config servers. Sabemos que en producción vamos a tener tres. Los actualizaremos de uno en uno y como procesos stand-alone mongod normales. Es decir, paramos el servicio, actualizamos los binarios y levantamos el servicio. Los Config Servers guardan información muy importante (en una base de datos propia) relativa a los datos que contiene cada shard, por eso, antes de actualizarlos es recomendable hacer un backup de su contenido. Los tres contienen la misma información, así que bastará con parar el servicio de uno de los tres y hacer el backup desde el servidor detenido. Esto es posible porque si uno de los tres está caído, automáticamente los otros dos se ponen en estado de sólo lectura.
    6. Actualizaremos los secundarios de todos los shards. Recordaremos que los secundarios de un mismo shard se han de tratar de uno en uno. Sin embargo, podemos actualizar en paralelo secundarios de distintos shards.
    7. Actualizamos ahora, de uno en uno, los primarios de cada shard. No es recomendable hacerlos todos a la vez porque los mongos enrutan todas las escrituras al nuevo primario y el sistema estará ocupado estableciendo las nuevas conexiones. Recordemos que cuando hacemos un stepDown a un primario se destruyen las conexiones existentes y se establecen nuevas.
    8. Activamos el balanceador

Si intentamos actualizar la base de datos ‘config’ sin haber parado el balanceador MongoDB nos avisa.

Tanto mongodbspain.com como yo mismo declinamos toda responsabilidad ante cualquier problema que pueda surgir en la actualización de vuestras instancias de MongoDB. Este artículo está escrito a título informativo y sólo con fines didácticos. Como es lógico, siempre se ha de acudir a las fuentes oficiales de MongoDB.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

10 + nueve =