Parece que MongoDB 3.6 no está configurado automáticamente para reiniciarse si falla. Al observar el servicio systemd que viene incluido con el último paquete .deb para Ubuntu 16.04LTS, no parece tener reinicios configurados:
$ sudo systemctl cat mongod
# /lib/systemd/system/mongod.service
[Unit]
Description=High-performance, schema-free document-oriented database
After=network.target
Documentation=https://docs.mongodb.org/manual
[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
PIDFile=/var/run/mongodb/mongod.pid
# file size
LimitFSIZE=infinity
# cpu time
LimitCPU=infinity
# virtual memory size
LimitAS=infinity
# open files
LimitNOFILE=64000
# processes/threads
LimitNPROC=64000
# locked memory
LimitMEMLOCK=infinity
# total threads (user+kernel)
TasksMax=infinity
TasksAccounting=false
# Recommended limits for for mongod as specified in
# http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
[Install]
WantedBy=multi-user.target
El envío de SIGKILL y SIGSEGV finaliza el proceso y no se reinicia. Sin embargo, no estoy seguro de si systemd los "capta" y no simplemente los reinicia.
Entonces, algunas preguntas: ¿Es esto crucial para un servicio de alta disponibilidad como una base de datos? Seguro que lo parece. ¿Hay alguna razón por la que MongoDB no tenga esto configurado de fábrica?
Respuesta1
El cierre inesperado es definitivamente un caso en el que se recomienda encarecidamente la intervención del administrador, aunque siempre puede cambiar el valor predeterminado del servicio para sus implementaciones.
Si el motivo del mongodcierre de un proceso es una invariante que no se puede solucionar sin intervención manual (por ejemplo, falta de espacio en disco o corrupción de archivos de datos), los reinicios automáticos no serán útiles y podrían empeorar la situación. En general, mongodno debería cerrarse ante errores recuperables. El MongoDBArquitectura de excepción del servidordistingue entre errores fatales por operación y aquellos que son fatales para todo el proceso. Los errores fatales en el proceso son situaciones en las que continuar puede conducir a resultados nefastos como pérdida de datos o datos corruptos en el disco. Una señal iniciada por el usuario o el O/S para finalizar el proceso (como elSin memoria, también conocido como OOM Killeren Linux) también provocará mongodel apagado.
Un error de ejemplo mencionado en los comentarios fue una compilación de índice que presentaba un error de segmentación en algunos secundarios con una versión anterior de MongoDB. Con los reinicios automáticos del servicio, este escenario podría conducir a un bucle sin fin en el que un secundario podría fallar, reiniciarse, reanudar la creación del índice, encontrar la misma condición y reiniciar... solo para reanudar una creación del índice condenada al fracaso. Mientras este ciclo de reinicio está en progreso, la disponibilidad intermitente del secundario podría afectar a los clientes que usan preferencias de lectura secundarias u otros miembros del conjunto de réplicas (por ejemplo, buscar repetidamente en un registro de operaciones ascendente para reanudar la sincronización).
Como administrador del sistema, preferiría revisar los registros de MongoDB e intentar comprender por qué se cerró el proceso para poder abordar la causa raíz. Idealmente, una implementación tendrá suficienteTolerancia a fallospara poder hacer frente a la falta de disponibilidad de los miembros para que haya tiempo para investigar y remediar la situación.
Dependiendo de la naturaleza del problema y la implementación (independiente, conjunto de réplicas o clúster fragmentado), es posible que también desee realizar una copia de seguridad de los archivos de datos antes de intentar cualquier recuperación automática o manual. Por ejemplo, cuando se reinicia después de un apagado incorrecto, mongodtiene una etapa de recuperación inicial que aplicará las entradas de diario pendientes y ejecutará comprobaciones del motor de almacenamiento, como la integridad de los archivos de datos en el archivo dbPath. Para un servidor independiente, sería prudente tomar una copia de los archivos de datos no modificados antes de cualquier intento de recuperación/reparación. Con una implementación de conjunto de réplicas, los datos ya están duplicados en otro miembro del conjunto de réplicas, por lo que si la recuperación estándar no tiene éxito, lo haríavolver a sincronizar este miembroen lugar de intentar cualquier reparación.
Respuesta2
Si está utilizando systemd, Restart=alwaysen la [Service]sección debería permitir que el servicio se reinicie después de un bloqueo.
Respuesta3
Si realmente le preocupa la alta disponibilidad, estaría ejecutando un conjunto de réplicas y podría lidiar con 1 o más nodos que fallan.
Después de haber administrado personalmente una implementación grande y fragmentada de mongodb en producción durante 5 años, preferiría que las instancias NO se reiniciaran automáticamente, ya que me gustaría investigar cualquier problema antes de que volviera a rotar en el conjunto de réplicas.
https://docs.mongodb.com/manual/core/replica-set-high-availability/