MongoDB: Recuperar un config server

12 Septiembre 2013 at 16:03 by Adrián Pérez

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):

Actualizar mongoDB de 2.0.1 a 2.0.4

1 Junio 2012 at 16:04 by Adrián Pérez

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:

MongoDB: Añadir miembros al shard

23 Mayo 2012 at 15:19 by Adrián Pérez

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:

MongoDB - Reconfigurar replica set

23 Octubre 2011 at 19:36 by Adrián Pérez

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
}
]
}

Actualizar MongoDB 1.8 a 2.0

11 Octubre 2011 at 21:36 by Adrián Pérez

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.