Recuperar um Standalone autogerenciado após um desligamento inesperado
Aviso
O procedimento a seguir se aplica à instância autônoma mongod versão 5.0. Nas outras versões do MongoDB, consulte o manual correspondente.
Não utilize este tutorial para recuperar um membro de um conjunto de réplicas. Na verdade, você deve restaurar a partir de um backup ou sincronizar novamente a partir de outro membro do conjunto, conforme descrito em Sincronize novamente um membro de um conjunto de réplicas autogerenciadas.
Dica
Se você estiver executando com o journaling ativado, quase nunca será necessário executar o reparo, pois o servidor pode usar os arquivos de journaling para restaurar automaticamente os ficheiros de dados para um estado limpo. No entanto, talvez seja necessário executar o reparo nos casos em que você precise se recuperar de uma corrupção de dados no nível do disco.
A corrupção de dados no nível do disco ou a falta de arquivos de dados podem impedir que a instânciamongod seja iniciada, e os arquivos de diário possam ser insuficientes para serem recuperados automaticamente:
2018-10-24T18:05:18.248-04:00 W STORAGE [initandlisten] Detected unclean shutdown - mongod.lock is not empty. ... 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] Failed to get the cursor for uri: table:collection-2-6854866147293273505 2018-10-24T17:24:53.122-04:00 E STORAGE [initandlisten] This may be due to missing data files. ... ... ***aborting after fassert() failure
Nesses casos, seu dbPath contém um arquivo mongod.lock não vazio.
O procedimento a seguir usa mongod --repair para se recuperar desses casos:
Aviso
Use mongod --repair apenas se não tiver outras opções. A operação remove e não salva quaisquer dados corrompidos durante o processo de reparo.
Para o mecanismo de armazenamento WiredTiger, mongod --repair:
Reconstrói todos os índices para coleções com um ou mais índices inconsistentes.
Descarta dados corrompidos.
Cria arquivos vazios/stub para arquivos de dados/metadados ausentes.
Procedimento
Importante
Execute a operação de reparo como o mesmo usuário que normalmente executa o processo mongod para evitar alterar as permissões dos arquivos de dados do MongoDB.
Cria uma cópia de segurança dos arquivos de dados.
Crie uma cópia de segurança dos arquivos de dados no --dbpath.
Comece mongod com --repair.
Para corrigir os arquivos de dados, inicie a instância do mongod com a opção --repair.
Emita um comando semelhante ao seguinte para o seu standalone:
mongod --dbpath /data/db --repair
Ao completar, o dbpath deve conter os arquivos de dados reparados e um arquivo mongod.lock vazio. [1]
Observação
Se o reparo falhar por algum motivo, você deverá reiniciar a instância com a opção --repair para concluir o reparo.
| [1] | Geralmente, você não deve remover manualmente o arquivo mongod.lock . Em vez disso, use o procedimento acima para recuperar o banco de dados. Em situações difíceis, você pode remover o arquivo, iniciar o banco de dados usando os arquivos possivelmente corrompidos e tentar recuperar dados do banco de dados. No entanto, é impossível prever o estado do banco de dados nessas situações. |