Aviso
Despejo de dados e restauração de conflitos com prefixo $ em campos
A partir do MongoDB 5.0, os nomes dos campo do documento podem ser prefixados com um caractere de dólar ($). No entanto, mongodump e mongorestore não funcionarão com nomes de campo prefixados com um caractere de dólar nas opções de uma coleção.
O JSON estendido2 (v) do MongoDB não consegue diferenciar entre os wrappers de tipo e os campos que têm o mesmo nome dos wrappers de tipo. Não use formatos JSON estendidos se a representação BSON correspondente puder incluir $ chaves prefixadas. O mecanismo DBRefs é uma exceção a esta regra geral.
Comportamento
Restaurar para a versão do servidor correspondente
Ao usar mongorestore para carregar arquivos de dados criados por mongodump, as versões do MongoDB das implantações de origem e destino devem ser:
A mesma versão principal.
A mesma versão de compatibilidade do recurso.
Por exemplo, se o seu dump foi criado a partir de uma implantação do MongoDB executando a versão 4.4, a implantação do MongoDB para a qual você restaurou também deve executar a versão 4.4 ou ter seu FCV definido como 4.4.
Para alterar sua versão de compatibilidade do recurso,setFeatureCompatibilityVersion consulte.
Observação
É possível restaurar os arquivos BSON gerados no mongodump para implantações do MongoDB que estejam executando a mesma versão ou a versão mais recente da implantação de origem. No entanto, restaurar arquivos para uma implantação rodando numa versão mais recente não é a maneira recomendada de atualizar sua implantação. Para aprender a fazer upgrade de sua implantação, consulte a documentação sobre fazer upgrade.
Essa garantia não se aplica a arquivos de metadados, arquivamento ou reprodução de oplog. Se você tentar restaurar estes arquivos utilizando diferentes versões de implantação de origem e destino, o processo mongorestore poderá resultar em falha, falha silenciosa ou metadados corrompidos.
Além disso, certifique-se que você está utilizando a mesma versão do mongorestore para carregar os arquivos de dados como a versão do mongodump usada para criá-los. Na prática, o uso de uma versão diferente de mongorestore geralmente funciona, mas se o formato de despejo for alterado entre as versões, a restauração pode falhar ou restaurar os dados incorretamente. Por exemplo, se você usar mongodump versão 100.19.0 para criar o dump, use mongorestore versão 100.19.0 para restaurá-la.
Observação
Como uma exceção a esta regra, você pode restaurar os dados despejados de um MongoDB 9.0 em um cluster do Atlas Infinite Database. Você também pode restaurar dados despejados de um cluster de banco de dados Atlas Infinite em um sistema do MongoDB 9.0.
Inserir apenas
mongorestore pode criar um novo banco de dados de dados ou adicionar dados a um banco de banco de dados existente. No entanto, mongorestore executa apenas inserções e não executa atualizações. Se você restaurar documentos em um banco de banco de dados e coleção existentes e documentos existentes tiverem o mesmo campo de valor _id que os documentos a serem restaurados, mongorestore não substituirá esses documentos.
Ordem do documento
Por padrão, mongorestore pode inserir documentos em uma ordem aleatória. Para preservar a ordem do documento durante o processo de restauração, use --maintainInsertionOrder.
Reconstrua os índices
mongorestore recria índices registrados pelo mongodump após restaurar os dados.
Observação
Para instalações MongoDB com featureCompatibilityVersion (FCV) definidas como "4.0" ou anterior, a criação de índices ocorrerá um erro se uma chave de índice em um documento existente exceder o limite.
Para evitar esse problema, considere usar índices com hash ou indexar um valor calculado. Para resolver o problema de índice após restaurar os dados, você pode desabilitar a validação de comprimento da chave de índice padrão no banco de dados de destino configurando mongod o failIndexKeyTooLong parâmetro da instância do para falso.
Excluir Coleção system.profile
mongorestore não restaura os system.profile dados de coleta.
DICAS
mongorestore cria automaticamente conexões compatíveis com FIPS para um mongod/mongos configurado para usar o modo FIPS .
Escreva preocupação
Se você especificar a preocupação de gravação na opção --writeConcern e também na string de conexão --uri, o valor --writeConcern substituirá a preocupação de gravação especificada no URI da string.
Coleções de Time Series
A partir do MongoDB 5.0, você pode usar mongorestore para restaurar coleções de séries temporais. Para obter detalhes, consulte Restaurar uma Coleção de Séries Temporais.
Oplog Replay Across a série temporal formato Conversion
MongoDB 8.x e MongoDB 9.0 armazenam coleções de séries temporais em formatos diferentes:
No MongoDB 8.x, uma coleção de séries temporais consiste em uma visualização e uma coleção
system.buckets.<collection>separada.A partir do MongoDB 9.0, uma coleção de séries temporais é uma única coleção.
Quando você usa para alterar a versão de compatibilidade do setFeatureCompatibilityVersion recurso (FCV) além desse limite, o servidor converte cada coleção de séries temporais para o formato que corresponde ao novo FCV. O servidor registra cada conversão no oplog.
Cada conversão também altera o namespace que o bucket grava como destino, de system.buckets.<collection> para <collection>. As entradas do oplog registradas antes de uma conversão não correspondem ao formato da coleção que a segue.
Como resultado, mongorestore não pode reproduzir uma faixa de oplog que abrange uma conversão. Restaure as entradas em cada lado da conversão como faixas separadas e altere a versão de compatibilidade do recurso na implantação de destino entre as duas restaurações:
Repita as entradas do oplog que precedem a conversão.
Use --oplogLimit para interromper a reprodução antes da conversão.
Altere a versão de compatibilidade do recurso na implantação de destino.
Execute no alvo para fazer a mesma alteração de FCV, na mesma direção, que produziu a setFeatureCompatibilityVersion conversão.
A alteração da versão de compatibilidade do recurso no destino é necessária. mongorestore nunca altera a versão de compatibilidade do recurso e não reescreve namespaces durante a conversão. Se o destino permanecer em uma versão de compatibilidade do recurso para ambas as restaurações, as entradas na segunda faixa nomeiam um namespace que não corresponde ao formato da coleção no destino. A restauração falha.
A partir do Database Tools 100.18.0, mongorestore falha com uma mensagem que nomeia a conversão quando a encontra durante --oplogReplay. Versões anteriores do Database Tools relatam um comando oplog desconhecido.
Para evitar a produção de um dump que não pode ser restaurado, não altere a versão de compatibilidade do recurso enquanto mongodump --oplog estiver em execução. Se você capturar o oplog por conta própria com mongodump --db=local --collection=oplog.rs e reproduzi-lo com --oplogFile, mongodump não poderá detectar a alteração da versão de compatibilidade do recurso, portanto, verifique se a faixa que você restaura não abrange uma conversão.
Usando mongorestore nos clusters Atlas Free e Flex
Em clusters gratuitos (M0) e Flex, as seguintes limitações se aplicam:
Não é possível executar
mongorestoreno banco de dadosadmin. Por padrão,mongorestoreignora esse banco de dados. Se você usar a opção--dbpara configurar o banco de dados de destino paraadmin, o programa retornará um erro.Você não pode usar as seguintes opções com o programa
mongorestore:
Uso do mongorestore nos clusters do banco de dados infinito do Atlas
Ao restaurar para um cluster de banco de dados Infinito do Atlas , não é possível usar as seguintes opções com o programa mongorestore:
Essa restrição se aplica se o despejo vem de um MongoDB 9.0 (banco de dados infinito não Atlas) ou de um cluster do Atlas Infinite Database.
Importante
mongorestore não é possível detectar se o cluster de destino é um cluster de banco de dados Infinito do Atlas antes de iniciar a restauração. Se você usar --oplogReplay ou --preserveUUID em um Atlas Infinite Database cluster, mongorestore retornará um erro ao tentar aplicar o oplog. Como mongorestore restaura os dados não oplog antes de aplicar o oplog, a repetição do oplog com falha pode deixar a restauração apenas parcialmente concluída.
Comportamento de falha
Se mongorestore falhar, o sistema poderá ficar em um estado inconsistente em que apenas alguns dos dados foram restaurados, mas não todos. Após uma falha, exclua todos os dados restaurados e execute novamente o processo desde o início.
Observação
Rollbacks de cluster de destino
Se o cluster sofrer uma reversão durante o processo de restauração, exclua todos os dados restaurados ou importados e refaça o processo desde o início. Consulte a documentação de reversão para obter mais detalhes.
Acesso necessário
Para restaurar dados para uma implementação do MongoDB que tenha o controle de acesso ativado, a função fornece os privilégios restore necessários para restaurar dados de backups se os dados não incluírem dados de coleção e você system.profile executar mongorestore sem a opção --oplogReplay .
Observação
Se o cluster de destino for um cluster MongoDB Atlas , a Atlas admin função será necessária. O MongoDB Atlas não oferece um restore role individual, um privilégio ou uma ação de privilégio . Para saber mais, consulte Configurar usuários do banco de dados.
Se os dados da cópia de segurança incluírem system.profile dados de coleta do ou você executar o mongorestore com a opção, você precisará de privilégios --oplogReplay adicionais:
| Se os dados de backup incluírem As roles integradas |
| Para executar com, Conceda somente aos usuários que devem executar |
Uso na estratégia de backup
Standalones/Conjunto de Réplicas
Para uma visão geral do uso do mongorestore como parte de uma estratégia de backup e recuperação, consulte Fazer Backup e Restaurar com o MongoDB Tools.
Clusters fragmentados
Para usar mongodump e mongorestore como uma estratégia de backup para clusters fragmentados, consulte Fazer backup de um cluster fragmentado autogerenciado com um descarte de banco de dados.
Os clusters fragmentados também podem usar um dos seguintes processos coordenados de backup e restauração, que garantem a atomicidade entre fragmentos e, ao mesmo tempo, aceitam gravações: