Parece que o MongoDB 3.6 não está configurado automaticamente para reiniciar se travar. Olhando para o serviço systemd que acompanha o pacote .deb mais recente para Ubuntu 16.04LTS, não parece ter reinicializações configuradas:
$ 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
O envio de SIGKILL e SIGSEGV interrompe o processo e ele não é reiniciado. Não tenho certeza se eles foram "capturados" pelo systemd e não apenas reiniciados.
Então, algumas perguntas: isso é crucial para um serviço de alta disponibilidade como um banco de dados? Com certeza parece que sim. Existe alguma razão para o MongoDB não ter isso configurado imediatamente?
Responder1
O desligamento inesperado é definitivamente um caso em que a intervenção do administrador seria fortemente recomendada, embora você sempre possa alterar o serviço padrã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 poderão piorar a situação. Em geral, mongodnão deve desligar devido a erros recuperáveis. O MongoDBArquitetura de exceção de servidordistingue 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 continuar pode levar a resultados terríveis, como perda de dados ou dados corrompidos no disco. Um sinal iniciado pelo usuário ou sistema operacional para encerrar o processo (como oFalta de memória, também conhecido como OOM Killerno Linux) também causará mongodo desligamento.
Um exemplo de erro mencionado nos comentários foi uma construçã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 infinito em que um secundário pode travar, reiniciar, retomar a construção do índice, encontrar a mesma condição e reiniciar... apenas para retomar uma construção de índice condenada. Enquanto esse loop de reinicialização estiver em andamento, a disponibilidade intermitente do secundário poderá afetar os clientes que usam preferências de leitura secundária ou outros membros do conjunto de réplicas (por exemplo, buscar repetidamente em um oplog upstream para retomar a sincronização).
Como administrador de 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á suficientetolerância ao erroser capaz de lidar com a indisponibilidade de membros para que haja tempo para investigar e remediar a situação.
Dependendo da natureza do problema e da implantação (autônomo, conjunto de réplicas ou cluster fragmentado), 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 autorizado, mongodhá um estágio inicial de recuperação 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 independente, 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 fariasincronizar novamente este membroem vez de tentar qualquer reparo.
Responder2
Se você estiver usando o systemd, Restart=alwaysna [Service]seção deverá permitir que o serviço seja reiniciado após uma falha.
Responder3
Se você estiver realmente preocupado com a alta disponibilidade, estará executando um conjunto de réplicas e poderá lidar com a falha de um 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 voltarem à rotação no conjunto de réplicas.
https://docs.mongodb.com/manual/core/replica-set-high-availability/