ApsaraDB for MongoDB:Visão geral das soluções de restauração de dados

O intervalo de tempo para o qual você pode restaurar os dados da instância depende do período de retenção dos seus backups. Para restaurar dados de um ponto mais antigo no tempo, consulte Long-term retention backup.

O tempo necessário para restaurar dados em uma nova instância varia conforme o tipo de armazenamento, o volume de dados do backup, o volume de oplog a ser reproduzido e as especificações da nova instância. Geralmente, o processo dura de alguns minutos a várias horas.

Uma restauração completa consiste nas três etapas abaixo. O tempo total é a soma dessas três fases:

Etapa	Descrição	Relacionado ao volume de dados
Crie uma nova instância	Cria e configura a instância de destino com as especificações selecionadas.	Não
Restaurar um backup completo	Restaura os dados do backup completo na nova instância.	Depende fortemente do tipo de armazenamento. Consulte as seções a seguir.
Restaurar um backup incremental (replay do oplog)	Reproduz os dados incrementais gerados entre o ponto do backup completo e o ponto alvo no tempo na nova instância.	Sim

Instâncias baseadas em cloud disks

A restauração completa de uma instância baseada em cloud disks utiliza snapshots de cloud disks. Os dados são restaurados mediante a montagem de um snapshot, tornando essa etapa praticamente independente do volume de dados.

As estimativas abaixo usam como referência uma instância replica set com 4 núcleos e 8 GB:

Etapa	Duração estimada
Crie uma nova instância	10 a 15 minutos
Restaurar um backup completo (montagem de snapshot)	Geralmente de 5 a 10 minutos, sendo praticamente independente do volume de dados.
Iniciar e inicializar a instância	2 a 5 minutos
Restaurar um backup incremental (replay do oplog)	Depende do volume de dados incrementais e da complexidade do conteúdo. Consulte Fatores que afetam o tempo de restauração.

Exemplo: Para uma instância replica set baseada em cloud disks com 4 núcleos e 8 GB, crie uma instância a partir de um ponto de backup geralmente leva de 20 a 30 minutos, independentemente de o volume de dados ser de 20 GB ou 1 TB. Usar a recuperação point-in-time para criar uma instância requer tempo adicional de replay proporcional ao volume de oplog gerado entre o ponto de backup e o ponto alvo no tempo.

Instâncias baseadas em discos locais

A restauração completa de uma instância baseada em discos locais baixa primeiro o conjunto de backup do armazenamento de backups e, em seguida, descompacta o conjunto no nó de destino. A duração depende do tamanho do conjunto de backup e da quantidade de arquivos de dados.

As estimativas abaixo usam como referência uma instância replica set com 4 núcleos e 8 GB:

Etapa	Duração estimada
Crie uma nova instância	10 a 15 minutos
Baixe o conjunto de backup completo	A taxa de referência é de 50 a 200 GB por hora, dependendo das especificações da instância e das condições de rede.
Descompactar o conjunto de backup completo	Depende da quantidade de arquivos de dados. Consulte a nota a seguir.
Baixe o oplog	A taxa de referência é de 50 a 200 GB por hora.
Reproduzir o oplog	Depende do volume de dados incrementais e da complexidade do conteúdo. Consulte Fatores que afetam o tempo de restauração.

Nota

O tempo de descompactação é determinado principalmente pela quantidade de arquivos de dados no conjunto de backup, e não apenas pelo seu tamanho. Mais coleções e índices resultam em mais arquivos de dados e maior tempo de descompactação. Para uma instância típica, a descompactação geralmente leva alguns minutos. No entanto, para uma instância com centenas de milhares de coleções e índices, a descompactação pode levar várias horas ou mais. Esse comportamento é esperado. Para mais informações, consulte Performance issues from excessive databases and collections. Se sua instância possui muitas coleções e exige restauração rápida, utilize uma instância baseada em cloud disks.

Exemplo: Considere uma instância replica set baseada em discos locais com 4 núcleos, 8 GB e 200 GB de dados. Para criar uma instância a partir de um ponto de backup, assumindo uma taxa de download de 100 GB por hora e aproximadamente 30 minutos para descompactação, a restauração ponta a ponta leva cerca de 3 horas. Usar a recuperação point-in-time para criar uma instância também requer tempo para baixar e reproduzir o oplog.

Fatores que afetam o tempo de restauração

• Tipo de armazenamento: A restauração completa em instâncias baseadas em cloud disks monta um snapshot, processo significativamente mais rápido do que baixar e descompactar dados em instâncias com discos locais.

• Tamanho do conjunto de backup: Backups maiores demandam mais tempo de download em instâncias com discos locais. Esse fator não afeta instâncias baseadas em cloud disks.

• Quantidade de arquivos de dados: Um número maior de coleções e índices aumenta o tempo de descompactação em instâncias com discos locais.

• Especificações da nova instância: Mais núcleos de CPU, memória e IOPS de disco aceleram downloads, descompactação e replay do oplog. Restaurar um grande volume de dados em uma instância com especificações baixas leva consideravelmente mais tempo.

• Volume do oplog: Na recuperação point-in-time, quanto mais distante o ponto alvo estiver do ponto do backup completo, maior será o volume de oplog a ser reproduzido, aumentando o tempo de restauração.

• Complexidade do conteúdo do oplog: Transações multidocumento no oplog devem ser reproduzidas serialmente e não podem ser aceleradas via paralelismo. Documentos grandes e atualizações em hotspots causam amplificação de escrita adicional. Em cargas de trabalho de escrita complexas, especificações de instância mais altas podem não melhorar visivelmente a velocidade de replay.

• Taxa de escrita da instância de source: Na recuperação point-in-time, uma taxa de escrita mais alta na source gera mais dados de oplog no mesmo período, aumentando o tempo de replay.

• Instâncias sharded cluster: O Config Server, os shards e os nós mongos de uma instância sharded cluster são restaurados em paralelo. O tempo de conclusão depende do componente mais lento e normalmente não é menor do que o de uma instância replica set com o mesmo volume de dados.

Recomendações para reduzir o tempo de restauração

• Prefira instâncias baseadas em cloud disks. A restauração completa leva minutos e não é afetada pelo volume de dados ou pela quantidade de coleções.

• Selecione especificações para a nova instância que sejam iguais ou superiores às da instância de source, evitando gargalos de especificação durante a restauração.

• Prefira criar uma instância a partir de um ponto de backup. Se seu negócio permitir, use o ponto de backup mais próximo do ponto alvo no tempo para reduzir ou eliminar o tempo de replay do oplog.

• Limite a quantidade de coleções e índices. Remova prontamente coleções e índices não utilizados para reduzir significativamente o tempo de descompactação em instâncias com discos locais.

• Ative o High-frequency backup. Isso encurta o intervalo entre o ponto de backup e o ponto alvo no tempo, reduzindo o volume de oplog a ser reproduzido.

Para instâncias sharded cluster com cloud disks, utilize o recurso de restauração de banco de dados e tabelas para restaurar dados na instância de source. Para mais informações, consulte Restore one or more databases of an ApsaraDB for MongoDB instance.

Caso sua instância não ofereça suporte à restauração de dados na instância de 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 de source e nova, ou use o Data Transmission Service (DTS) para migrar os dados da nova instância para a instância de source.

• Para modifique o endpoint e a porta de uma instância, consulte Modify the endpoint and port.

• Para mais informações sobre migração de dados usando o DTS, consulte Migration solutions for self-managed MongoDB databases or ApsaraDB for MongoDB instances.

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 usando o DTS, consulte Migration solutions for self-managed MongoDB databases or ApsaraDB for MongoDB instances.

• Use o DTS para migrar os dados da instância para um banco de dados autogerenciado. Para mais informações, consulte Migration solutions for self-managed MongoDB databases or ApsaraDB for MongoDB instances.

• Utilize as ferramentas nativas de backup e restauração do MongoDB, Mongodump e Mongorestore, para fazer backup e restaurar a instância.

O Config Server de uma instância sharded cluster armazena metadados de roteamento para todas as coleções fragmentadas, incluindo as coleções config.collections e config.chunks. Os documentos nessas coleções contêm campos como shard: 'shard01' que identificam o shard ao qual os dados pertencem. A restauração por clonagem exige os dados completos de roteamento da instância de source; portanto, os shard IDs originais (nomes dos shards) devem ser mantidos. Como resultado, os shard IDs da instância clonada diferem dos nomes de shard exibidos na saída do comando sh.status().

É possível mapeá-los comparando o campo 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.