Reiniciar/Autorematar Mongodb en producción

Question

Lo que quiero lograr es tener un script /etc/init.d que inicie de manera más confiable Mongodb, incluso si fue muy difícil - debería intentar una reparación automática en caso de que el sistema está en un estado bloqueado

Sí, podría escribir esto yo mismo, pero creo que alguien ya debe haber hecho esto.

Me di cuenta de que después de que un servidor falla, Mongodb se encuentra en un estado en el que no se reinicia mediante el script /etc/init.d/mongod. Obviamente, los archivos de bloqueo deben eliminarse y debe iniciarse con la opción --repair y corregir --dbpath primero, antes de que pueda reiniciarse con éxito. En algunos casos, también es necesario cambiar la propiedad de los archivos db para el usuario que ejecuta mongodb. Un problema adicional es que la secuencia de comandos /etc/init.d/mongod estándar no informa un error en esta situación, sino que devuelve con alegría e incorrectamente el estado "OK" e informa que Mongod se inició, aunque no fue así.

$ sudo /etc/init.d/mongod start 
Starting mongod: forked process: 9220 
all output going to: /data/mongo/log/mongod.log 
                  [ OK ] 
$ sudo /etc/init.d/mongod status 
mongod dead but subsys locked 

El sistema operativo es CentOS o Fedora.

¿Alguien ha modificado scripts /etc/init.d o un puntero a tales scripts, que intentan una reparación automáticamente en esa situación? ¿O hay otra herramienta que funcione como un perro guardián para Mongod?

¿Alguna opinión sobre por qué podría ser una mala idea intentar reparar automáticamente mongodb?

$ sudo /etc/init.d/mongod status 
mongod dead but subsys locked 

$ sudo ls -l /var/lib/mongo/mongod.lock 
-rw-r--r--. 1 mongod mongod 5 Nov 19 11:52 /var/lib/mongo/mongod.lock 


$ sudo tail -50 /data/mongo/log/mongod.log 
************** 
old lock file: /data/mongo/db/mongod.lock. probably means unclean shutdown 
recommend removing file and running --repair 
see: http://dochub.mongodb.org/core/repair for more information 
************* 
Sat Nov 19 11:55:44 exception in initAndListen std::exception: old lock file, terminating 
Sat Nov 19 11:55:44 dbexit: 

Sat Nov 19 11:55:44 shutdown: going to close listening sockets... 
Sat Nov 19 11:55:44 shutdown: going to flush oplog... 
Sat Nov 19 11:55:44 shutdown: going to close sockets... 
Sat Nov 19 11:55:44 shutdown: waiting for fs preallocator... 
Sat Nov 19 11:55:44 shutdown: closing all files... 
Sat Nov 19 11:55:44  closeAllFiles() finished 

Sat Nov 19 11:55:44 dbexit: really exiting now 

Answer 1

Así que el primer bit de mencionar es diario. El diario se factura como "reparación rápida". El diario está activado por defecto en 2.0+ y realizará esa "reparación" por defecto.

Por lo tanto, si sus discos pueden manejar el rendimiento de escritura adicional del diario, esto puede resolver su problema.

¿Alguna opinión sobre por qué podría ser una mala idea intentar reparar automáticamente mongodb?

El problema # 1 con la reparación de MongoDB automáticamente es simplemente una de las veces.

Si usted tiene una base de datos de 200 GB, el sistema tendrá que hacer lo siguiente en la reparación:

1. Asignar ~ 200 GB de archivos (¿Tiene usted el espacio en el disco?)
2. Lea todo los datos de los archivos existentes en la memoria (200GB read)
3. comprobar cada documento para su validez y escribir de nuevo a los nuevos archivos (200GB write)
4. volver a crear todos los índices (200GB reads + large number of writes)
5. Flush todo en el disco

Si nos fijamos en mis notas Esa es una cantidad seria de golear unidad para realizar una reparación.

Pero la mayoría de las instalaciones de producción ejecutan conjuntos de réplicas. En este caso, en lugar de reparar, puede restaurar desde una copia de seguridad.Restaurar desde una copia de seguridad solo escribe los datos una vez y es un proceso que ya debería haber implementado.

A pesar de que la secuencia de comandos init.d devuelve OK, la supervisión del sistema debería indicarle que la base de datos no está activa.

Answer 2

Solo quiero señalar que escribir en diario funciona en la versión de 32 bits. Sin embargo, no está activado por defecto en 32 bits.