Início / dba / Perguntas / 167152
Accepted
WAF
Asked: 2017-03-15 07:28:12 +0800 CST

Encontrando ou confirmando a ausência de dados corrompidos no MongoDB

  • 772

Fundo

Eu tenho um diretório cheio de .gzarquivos que foram produzidos por mongodumpum mongod executando o MongoDB 3.4.x, que estou escrevendo em uma instância diferente executando o MongoDB 3.4.2 usando mongorestore ... --numInsertionWorkersPerCollection 8 --drop --nsFrom ... --nsTo .... Todos, exceto um, estão sendo carregados corretamente. Todos eles levam entre 1 e 3 horas para carregar os dados e, em seguida, mais 2 a 4 horas para reconstruir os índices. O arquivo problemático trava antes da etapa abaixo e costumo matar o processo externamente após cerca de um dia. Reproduzi o cenário 4 ou 5 vezes.

finished restoring database.collection (N documents)

Durante esse tempo, o mongorestoreprocesso ainda está visível no shell, mas não possui uma entrada correspondente em db.currentOp(), e o tamanho do banco de dados não está aumentando.

Esses erros foram retornados logo antes da linha de log "restaurando índices para coleção database.collection from metadata":

2017-03-13T09:30:04.218-0400    demux namespaceHeader: {database collection true 726142452659775357}
2017-03-13T09:30:04.218-0400    demux checksum for namespace database.collection is correct (726142452659775357), 54599167880 bytes
2017-03-13T09:30:04.218-0400    demux finishing (err:corruption found in archive; I/O error reading length or terminator ( gzip: invalid header ))

Eu encontrei alguns relatórios de travamento do mongorestore ( por exemplo ) e alguma documentação de problemas com /s em namespaces em versões mais antigas ( por exemplo ), mas não encontrei uma descrição da minha situação.

Pergunta

Agora me encontro com alguma indicação de que um arquivo que carreguei pode estar corrompido ou pelo menos ter um cabeçalho corrompido. A emissão de consultas realistas para a coleção em questão e seus índices retorna resultados que parecem razoáveis. Como posso detectar ou descartar definitivamente "corrupção" desse tipo? O que realmente significa "corrupto" neste contexto? Posso esperar encontrá-lo no banco de dados ou apenas no arquivo zip?

Atualização : por sugestão de @mustaccio, executei gzip -to arquivo problemático e ele relatou "lixo à direita". Isso é suficiente para fixar o problema relatado pelo MongoDB em uma entrada incorreta e parar de procurar por corrupção no banco de dados?

mongodb restore

1 respostas

  1. Best Answer

    finalização demux (err:corruption found in archive; erro de E/S lendo comprimento ou terminador ( gzip: cabeçalho inválido ))

    Esta mensagem de erro refere-se ao processamento do arquivo gzip em vez dos dados BSON contidos. Seu teste com gzip -timplica que o conteúdo provavelmente está OK e o erro pode ser devido ao preenchimento ignorável no final do arquivo (consulte: gzip reclama com lixo à direita ignorado ).

    Todos, exceto um, estão sendo carregados corretamente. Aquele reprodutivelmente trava (indefinidamente)

    Se o problema for facilmente reproduzível, eu levantaria um relatório de bug no projeto MongoDB Jira TOOLS, incluindo mais detalhes, como as versões específicas de mongodumpe mongorestoreparâmetros de linha de comando usados, bem como quanto tempo você esperou. Parece razoável mongorestoreter algum tipo de tempo limite ou tratamento de erros para este caso em vez de travar indefinidamente; Eu também não esperaria mongodumpcriar arquivos que a mesma versão mongorestorenão possa manipular.

    Agora me encontro com alguma indicação de que um arquivo que carreguei pode estar corrompido ou pelo menos ter um cabeçalho corrompido. A emissão de consultas realistas para a coleção em questão e seus índices retorna resultados que parecem razoáveis. Como posso detectar ou descartar definitivamente "corrupção" desse tipo? O que realmente significa "corrupto" neste contexto? Posso esperar encontrá-lo no banco de dados ou apenas no arquivo zip?

    É improvável que você consiga restaurar documentos BSON corrompidos no MongoDB, mas pode haver algumas nuances dependendo de como/onde os dados estão corrompidos. Na maioria dos casos, dados inválidos acionarão uma exceção/asserção quando o servidor tentar ler o BSON, mas um BSON válido não significa necessariamente que o conteúdo do campo seja o esperado.

    Para ter certeza absoluta, você teria que comparar as contagens de documentos ou somas de verificação dos dados restaurados com os dados originais (supondo que você ainda tenha uma cópia diferente do arquivo gzip).

    • 2

relate perguntas