Solución:
El cierre inesperado es definitivamente un caso en el que se recomienda encarecidamente la intervención del administrador, aunque siempre puede cambiar el servicio predeterminado para sus implementaciones.
Si el motivo de una mongod El proceso de cierre es un 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, mongod no debe apagarse por errores recuperables. La arquitectura de excepciones del servidor MongoDB distingue entre errores fatales por operación y aquellos que son fatales para todo el proceso. Los errores fatales del proceso son situaciones en las que continuar puede conducir a resultados nefastos como la 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 la memoria insuficiente, también conocida como OOM Killer en Linux) también provocará mongod para desconectar.
Un error de ejemplo mencionado en los comentarios fue una compilación de índice que falló 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 bloquearse, reiniciarse, reanudar la generación del índice, encontrar la misma condición y reiniciarse … solo para reanudar una generación de índice condenada. 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á suficiente tolerancia a fallas para poder hacer frente a los miembros que no están disponibles, por lo que hay 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 no limpio mongod tiene una etapa de recuperación inicial que aplicará entradas de diario pendientes y ejecutará comprobaciones del motor de almacenamiento como la integridad del archivo de datos en el 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, volvería a sincronizar este miembro en lugar de intentar cualquier reparación.
Si está utilizando systemd entonces Restart=always bajo la [Service] La sección debería permitir que el servicio se reinicie después de un bloqueo.
Si está realmente preocupado por la alta disponibilidad, estaría ejecutando un conjunto de réplicas y podría lidiar con uno o más nodos que fallan.
Habiendo gestionado 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 vuelva a girar en el conjunto de réplicas.
https://docs.mongodb.com/manual/core/replica-set-high-availability/