Publicado el

MongoDB: Recuperar un config server

mongodbHoy me he encontrado, que tras una caída de un servidor que alojaba un config server de mi cluster MongoDB 2.2.0 (sobre un entorno Red Hat), el config server no era capaz de arrancar. Concretamente, al intentar iniciar el config server, podría ver los siguientes logs en el fichero de error:

Thu Sep 12 11:47:37 [initandlisten] dbexception during recovery: 15874 couldn’t uncompress journal section
Thu Sep 12 11:47:37 [initandlisten] exception in initAndListen: 15874 couldn’t uncompress journal section, terminating
Thu Sep 12 11:47:37 dbexit:
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close listening sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to flush diaglog…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: waiting for fs preallocator…
Thu Sep 12 11:47:37 [initandlisten] shutdown: lock for final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: closing all files…
Thu Sep 12 11:47:37 [initandlisten] closeAllFiles() finished
Thu Sep 12 11:47:37 [initandlisten] shutdown: removing fs lock…
Thu Sep 12 11:47:37 dbexit: really exiting now

Al parecer, el fichero de journal se ha corrompido con la caída del server y ni si quiera es capaz de solucionarse con un «–repair». Aprovechando que mi cluster tiene 3 config servers, he pasado a parar uno de los dos config servers que aun funcionaban, para copiar los datos del dbpath al config server corrompido, con tal de recuperarlo.

El proceso ha sido el siguiente, descrito en la documentación oficial de MongoDB (v2.2): Continuar leyendo «MongoDB: Recuperar un config server»

Publicado el

Actualizar mongoDB de 2.0.1 a 2.0.4

MongoDB
Vuelvo a usar por enésima vez la misma imagen para un post sobre MongoDB. Esta vez, veremos cómo actualizar todo un clúster mongo de la versión 2.0.1 a la 2.0.4.

En primer lugar revisaremos qué posibilidades tenemos para actualizar mongo con

yum search mongo

A continuación, miraremos la versión de mongo que nos ofrece yum, para confirmar que coincide con la deseada:

yum info mongo-10gen
Paquetes disponibles
Name : mongo-10gen
Arch : x86_64
Version : 2.0.4

Una vez estemos seguros, seguiremos el proceso descrito en este otro post, que básicamente sigue estos pasos cuando se tiene un entorno con ReplicaSets y Sharding:

Continuar leyendo «Actualizar mongoDB de 2.0.1 a 2.0.4»

Publicado el

MongoDB: Añadir miembros al shard

MongoDB
Si partimos de un entorno con sharding y replica sets, es posible que tengamos un entorno con un único mongos y un único config_server, cuando idealmente deberíamos tener 3 config_servers y tantos mongos como servidores de aplicaciones que conectan con mongo (idealmente, cada servidor de aplicaciones tendrá su propio mongos local). Ésta no es una situación extraña, puesto que se recoge en la documentación oficial de mongo, «Upgrading from one config server to three«.

Si ya se dispone de un entorno en producción como el anterior, se deberá seguir el siguiente proceso para añadir los config_servers y mongos extras:

Continuar leyendo «MongoDB: Añadir miembros al shard»

Publicado el

MongoDB – Reconfigurar replica set

MongoDBSi se quiere cambiar alguno de los parámetros de cualquier nodo del réplica set, bastará con conectar con el nodo primario de ese conjunto, y seguir los pasos descritos a continuación.

En primer lugar, se deberá copiar la configuración actual del replica set a una variable auxiliar:

PRIMARY> cfg = rs.conf()
{
«_id» : «replica1»,
«version» : 6,
«members» : [
{
«_id» : 0,
«host» : «192.0.1.2:27001»
},
{
«_id» : 1,
«host» : «192.0.1.3:27001»
},
{
«_id» : 4,
«host» : «192.0.1.4:38001»,
«arbiterOnly» : true
}
]
}

Continuar leyendo «MongoDB – Reconfigurar replica set»

Publicado el

Actualizar MongoDB 1.8 a 2.0

MongoDBEsta semana hemos realizado una actualización de nuestro clúster MongoDB de la versión 1.8 a la 2.0.

En nuestro caso, tenemos varias máquinas que forman parte del clúster, donde cada máquina contiene un seguido de mongods corriendo, cada uno de ellos correspondiente a un shard, que a su vez contiene un nodo de un determinado replica-set. Un poco complicado de entender, si no se ha tocado mucho MongoDB. En cualquier caso, con este escenario hemos relizado la actualización.

La idea ha sido aprovechar la funcionalidad de clúster, para poder actualizar las máquinas secundarias mientras las primarias continuaban dando servicio, con tal de minimizar el downtime que requiere un proceso de estas características.

Continuar leyendo «Actualizar MongoDB 1.8 a 2.0»