Por que o MongoDB não reinicia automaticamente?

O desligamento inesperado é definitivamente um caso em que a intervenção do administrador seria fortemente recomendada, embora você sempre possa alterar o padrão do serviço para suas implantações.

Se o motivo do mongodencerramento de um processo for 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), as reinicializações automáticas não serão úteis e podem piorar a situação. Em geral, mongodnão deve desligar em erros recuperáveis. A Arquitetura de Exceções do MongoDB Server distingue entre erros fatais por operação e aqueles que são fatais para todo o 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 sinal iniciado pelo usuário ou O/S para encerrar o processo (como o Out-of-Memory, também conhecido como OOM Killer no Linux) também causará mongodo desligamento.

Um exemplo de erro mencionado nos comentários foi uma compilação de índice que falhou em alguns secundários com uma versão mais antiga do MongoDB. Com reinicializações automáticas de serviço, esse cenário pode levar a um loop sem fim em que um secundário pode travar, reiniciar, retomar a compilação de índice, encontrar a mesma condição e reiniciar... apenas para retomar uma compilação de índice condenada. Enquanto esse loop de reinicialização está em andamento, a disponibilidade intermitente do secundário pode afetar os clientes que usam as preferências de leitura secundária ou outros membros do conjunto de réplicas (por exemplo, procurar repetidamente em um oplog upstream para retomar a sincronização).

Como administrador do sistema, prefiro 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á tolerância a falhas suficiente para poder lidar com membros indisponíveis para que haja tempo para investigar e remediar a situação.

Dependendo da natureza do problema e da implantação (independente, conjunto de réplicas ou cluster fragmentado), talvez eu também queira 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 de recuperação inicial que aplicará entradas de diário pendentes e executará verificações do mecanismo de armazenamento, como integridade do arquivo de dados no arquivo 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 de 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 sincronizaria novamente esse membro em vez de tentar qualquer reparo.

Se você estiver usando o systemd, Restart=alwaysna [Service]seção deve permitir que o serviço seja reiniciado após uma falha.

Se você estiver realmente preocupado com a alta disponibilidade, estará executando um conjunto de réplicas e poderá lidar com a falha de 1 ou mais nós.

Tendo gerenciado pessoalmente uma implantação grande e fragmentada do mongodb em produção por 5 anos, prefiro que as instâncias NÃO sejam reiniciadas automaticamente, pois gostaria de investigar quaisquer problemas antes de voltar à rotação no conjunto de réplicas.

https://docs.mongodb.com/manual/core/replica-set-high-availability/