Visão geral das soluções de restauração de dados do ApsaraDB for MongoDB - ApsaraDB for MongoDB: Central de Documentação do Alibaba Cloud

O ApsaraDB for MongoDB oferece diversas soluções de restauração de dados para diferentes cenários.

Restaurar dados em uma instância do ApsaraDB for MongoDB

Importante

Antes de restaurar dados em uma nova instância, observe os seguintes requisitos:

A nova instância deve ter a mesma versão principal do banco de dados da instância source. Selecione uma zona compatível com essa versão, pois as zonas disponíveis variam conforme a versão (Notas de uso).
A nova instância deve ter capacidade de armazenamento igual ou superior à da instância source.
Não é possível restaurar backups criados antes de uma atualização de versão principal na nova versão.
Por padrão, uma nova instância criada para restauração de dados executa a versão secundária mais recente do kernel.
Se sua instância contiver coleções de séries temporais (MongoDB 5.0 ou posterior), a recuperação point-in-time poderá apresentar problemas durante a fase de replay do oplog.

Solução	Arquitetura da instância	Destino da restauração	Escopo da restauração	Cenário
Restaurar um ou mais bancos de dados de uma instância do ApsaraDB for MongoDB	Instância replica set com discos em nuvem Instância sharded cluster com discos em nuvem	Instância original	Todos os bancos de dados Bancos de dados específicos	Recupera coleções ou documentos excluídos acidentalmente.
	Instância replica set com discos locais executando MongoDB 4.0 ou 4.2 Nota As regiões suportadas e outros limites estão listados nas Notas de uso.	Nova instância	Todos os bancos de dados Bancos de dados específicos	Recupera coleções ou documentos excluídos acidentalmente.
Criar uma nova instância a partir de um conjunto de backup	Instância standalone Instância replica set	Nova instância	Todos os bancos de dados Bancos de dados específicos Nota A restauração parcial é suportada apenas em instâncias com discos locais.	Indicado quando a atualidade dos dados não é crítica.
Criar uma nova instância usando recuperação point-in-time	Instância replica set	Nova instância	Todos os bancos de dados Bancos de dados específicos Nota A restauração parcial é suportada apenas em instâncias com discos locais.	Restaura os dados da instância para um ponto específico no tempo.
Criar uma nova instância usando recuperação point-in-time	Instância sharded cluster	Nova instância	Todos os bancos de dados
Restauração de dados entre regiões	Instância replica set com discos em nuvem Instância sharded cluster com discos em nuvem	Nova instância	Todos os bancos de dados	Restaura um backup entre regiões em uma nova instância na região onde o backup está armazenado, para fins de conformidade ou recuperação de desastres.

Restaurar dados em um banco de dados autogerenciado

Para restaurar dados em um banco de dados autogerenciado, primeiro baixe o backup da sua instância do ApsaraDB for MongoDB (Baixar um arquivo de backup).

Solução

Arquitetura da instância

Notas de uso

Restaurar um backup lógico em um banco de dados autogerenciado

Instância replica set executando MongoDB 4.2 ou anterior com SSDs locais.
Instância sharded cluster executando MongoDB 4.2 ou anterior com SSDs locais.

Sempre utilize uma versão do mongorestore compatível com sua versão do MongoDB, pois versões mais antigas podem não suportar bancos de dados mais recentes (mongorestore).

Restaurar dados a partir de um backup de disco local

Instância replica set que atenda às seguintes condições:

A criptografia transparente de dados (TDE) está desativada para a instância (Ativar TDE).
O mecanismo de armazenamento da instância é WiredTiger ou RocksDB.

Nenhuma.

Perguntas frequentes

Como restauro dados de um ponto anterior no tempo?

O intervalo de tempo disponível para restauração depende do período de retenção dos seus dados de backup. Para restaurar dados de um ponto mais antigo, consulte Backup de retenção de longo prazo.

Como restauro dados de backup na instância source?

Para instâncias sharded cluster com discos em nuvem, utilize o recurso de restauração de bancos de dados e tabelas para restaurar dados na instância source. Para mais informações, consulte Restaurar um ou mais bancos de dados de uma instância do ApsaraDB for MongoDB.

Caso sua instância não suporte a restauração direta na instância source por meio desse recurso, restaure os dados de backup em uma nova instância. Em seguida, alterne os endpoints e números de porta entre as instâncias source e nova, ou utilize o Data Transmission Service (DTS) para migrar os dados da nova instância para a instância source.

Para modifique o endpoint e a porta de uma instância, consulte Modificar o endpoint e a porta.
Para mais informações sobre migração de dados com o DTS, consulte Soluções de migração para bancos de dados MongoDB autogerenciados ou instâncias do ApsaraDB for MongoDB.

Como restauro um arquivo de backup baixado em uma instância do ApsaraDB for MongoDB?

Não é possível restaurar diretamente um arquivo de backup baixado em uma instância do ApsaraDB for MongoDB. Primeiro, restaure os dados em um banco de dados autogerenciado e, em seguida, use o DTS para migrar os dados para a instância do ApsaraDB for MongoDB. Para mais informações sobre migração de dados com o DTS, consulte Soluções de migração para bancos de dados MongoDB autogerenciados ou instâncias do ApsaraDB for MongoDB.

Se meu tipo de instância não suportar o download de arquivos de backup, como posso restaurar dados em um banco de dados autogerenciado?

Utilize o DTS para migrar os dados da instância para um banco de dados autogerenciado. Para mais informações, consulte Soluções de migração para bancos de dados MongoDB autogerenciados ou instâncias do ApsaraDB for MongoDB.
Use as ferramentas nativas de backup e restauração do MongoDB, Mongodump e Mongorestore, para fazer backup e restaurar a instância.

Por que o ID do shard de uma instância sharded cluster clonada difere da saída do comando sh.status()?

Uma instância clonada herda todos os dados de roteamento da instância source, incluindo seus IDs de shard (nomes dos shards). Os documentos nessas coleções contêm um campo semelhante a shard: 'shard01' que identifica a qual shard os dados pertencem. Isso causa uma discrepância entre o ID do shard retido e o nome do shard exibido na saída do comando sh.status() da instância clonada.

É possível mapeá-los comparando o Shard ID (replicaSetName) na página de detalhes da instância no console com a saída do comando sh.status(). Esse mapeamento permanece inalterado após a restauração.