Desligamento inesperado é definitivamente um caso em que a intervenção do administrador seria altamente recomendável, embora você sempre possa alterar o padrão de serviço para suas implantações.
Se o motivo de um processo mongod desligar é uma invariante que não pode ser corrigida sem intervenção manual (por exemplo, falta de espaço em disco ou corrupção de arquivos de dados), reinicializações automáticas não serão úteis e podem potencialmente tornar a situação pior. Em geral, mongod não deve desligar os erros recuperáveis. O Server Exception Architecture do MongoDB distingue entre erros fatais por operação e aqueles que são fatais para o todo processo. Erros fatais de processo são situações em que a continuação pode levar a resultados terríveis, como perda de dados ou dados corrompidos no disco. Um usuário ou O / S iniciou o sinal para finalizar o processo (como o Out-of-Memory aka OOM Killer no Linux) também fará com que mongod seja desligado.
Um erro de exemplo mencionado nos comentários foi uma construção de índice que segmentou alguns secundários com uma versão mais antiga do MongoDB. Com a reinicialização do serviço automático, esse cenário poderia levar a um loop infinito em que um secundário pode travar, reiniciar, continuar a compilação do índice, encontrar a mesma condição e reiniciar .. apenas para retomar uma construção de índice doado. Enquanto esse loop de reinicialização estiver em andamento, a disponibilidade intermitente do secundário poderá impactar os clientes usando preferências de leitura secundárias ou outros membros do conjunto de réplicas (por exemplo, procurando repetidamente em um oplog upstream para retomar a sincronização).
Como administrador do sistema, eu preferiria revisar os logs do MongoDB e tentar entender por que o processo foi encerrado para que a causa raiz possa ser resolvida. Idealmente, uma implantação terá suficiente tolerância a falhas para poder lidar com com membros indisponíveis, então há tempo para investigar e remediar a situação.
Dependendo da natureza do problema e da implantação (independente, conjunto de réplicas ou cluster particionado), também posso querer fazer um backup dos arquivos de dados antes de tentar qualquer recuperação automática ou manual. Por exemplo, quando reiniciado após um desligamento não limpo, mongod tem um estágio inicial de recuperação que aplicará as entradas de diário pendentes e executará verificações do mecanismo de armazenamento, como integridade do arquivo de dados, no dbPath . Para um servidor autônomo, seria prudente fazer uma cópia dos arquivos de dados não modificados antes de qualquer tentativa de recuperação / reparo. Com uma implantação do conjunto de réplicas, os dados já estão duplicados em outro membro do conjunto de réplicas, portanto, se a recuperação padrão não for bem-sucedida, eu