Restaurar dados completos de uma instância ApsaraDB RDS for MySQL - ApsaraDB RDS: Central de Documentação do Alibaba Cloud

Pré-requisitos

Antes de começar, verifique se:

A instância RDS original está no estado Running e não está bloqueada
Não há tarefas de migração em andamento na instância RDS original
Pelo menos um backup de dados foi concluído (o ApsaraDB RDS realiza backups automáticos por padrão — consulte Visão geral dos métodos de backup)
(Obrigatório para restauração point-in-time) O backup de logs está ativado — consulte Usar o recurso de backup de logs para uma instância ApsaraDB RDS for MySQL
(Obrigatório para restauração a partir de conjunto de backup) Pelo menos um backup físico foi concluído — consulte Backup automático

Como funciona

A restauração completa de dados cria uma nova instância RDS a partir dos dados de backup. A instância original permanece inalterada durante todo o processo.

Item	Descrição
Restoration range	Toda a instância RDS é restaurada.
Specifications of the new RDS instance	Herda as configurações de lista de permissões, de backup e de parâmetros da instância original.
Account information	Inclui as informações da conta no momento da restauração e as informações do arquivo de backup selecionado.
Data	Corresponde aos dados do arquivo de backup especificado da instância RDS original.
Restore point	Depende dos recursos de backup ativados: backup de logs desativado — restauração apenas para o horário de criação do backup; backup de logs ativado — restauração para qualquer ponto dentro do período de retenção do backup de logs; recuperação point-in-time (PITR) ativada — restauração para qualquer ponto com base no parâmetro Time Range of Specific Points in Time for Restoration. Para diferenças entre PITR e backup de logs, consulte Diferenças entre os recursos PITR e backup de logs.

Limitações

Não é possível restaurar arquivos de backup baixados diretamente em uma instância RDS for MySQL existente. Restaure primeiro para uma nova instância, verifique os dados e então migre os dados para a instância existente.
A restauração pode falhar se a nova instância RDS executar uma versão do mecanismo de banco de dados anterior à da instância original.
A restauração pode falhar se nomes de tabelas ou colunas contiverem caracteres chineses ou especiais.
A restauração pode falhar caso os binary logs da instância RDS original tenham sido excluídos.
Tabelas sem chaves primárias não podem ser restauradas se implicit_primary_key estiver definido como off na instância RDS original.

Faturamento

As cobranças pela nova instância RDS começam assim que ela é criada. Revise o preço durante a configuração da instância antes de confirmar o pedido.

Para uso temporário, crie uma instância RDS com pagamento conforme o uso ou serverless. Após verificar e migrar os dados de volta para a instância original, libere a nova instância para interromper as cobranças. Consulte Migrar dados entre instâncias ApsaraDB RDS e Liberar ou cancelar assinatura de uma instância ApsaraDB RDS for MySQL.

Restaurar uma instância completa

A restauração completa de dados está habilitada por padrão. O ApsaraDB RDS realiza backups periódicos automaticamente, permitindo usar os arquivos de backup e logs gerados para restaurar dados a qualquer momento.

Acesse a página Instances. Na barra de navegação superior, selecione a região onde a instância RDS reside. Localize a instância e clique em seu ID.
No painel de navegação à esquerda, clique em Backup and Restoration.
Clique em Restore Database.

Nota
Alternativamente, clique em Restore Instance na seção Instance Distribution da página Basic Information.

Na página Restore Instance, selecione um ponto de restauração ou conjunto de backup e configure os parâmetros da instância.

Parâmetro	Descrição
Billing Method	Subscription: Pagamento antecipado para uso de longo prazo com menor custo por unidade. Pay-as-you-go: Faturamento por hora com base no uso real; libere a instância quando não for mais necessária.
Restoration Mode	By Backup Set: Restaura a partir de um backup físico específico. Arquivos de backup lógico não são suportados. By Point in Time: Restaura para qualquer ponto dentro do período de retenção do backup de logs. Disponível apenas quando o backup de logs está ativado.
Product Type	Não exibido para a Basic Edition. Para a High-availability Edition: armazenamento ESSD ou Premium ESSD suporta os tipos de produto Standard e YiTian; armazenamento Premium Local SSD suporta apenas Standard. Para a Cluster Edition: os tipos de produto Standard e YiTian estão disponíveis. Consulte Tipos de produto.
Zone of primary node e Zone of secondary node	Single-zone deployment: Os nós primário e secundário ficam na mesma zona. Multi-zone deployment: Os nós primário e secundário ficam em zonas diferentes para recuperação de desastres entre zonas. Recomenda-se a implantação multizona. Após a criação, visualize os detalhes da zona na página Service Availability. A Basic Edition suporta apenas implantação em zona única.
Instance Type	General-purpose instance types: Memória e I/O dedicados; CPU e armazenamento compartilhados com outras instâncias no mesmo host. Dedicated instance types: Recursos de CPU, memória, armazenamento e I/O dedicados exclusivamente à sua instância. Para núcleos, memória, conexões e IOPS suportados por tipo de instância, consulte Tipos de instância primária do ApsaraDB RDS. Nota Cada tipo de instância suporta um número específico de núcleos, capacidade de memória, conexões máximas e IOPS máximo. Para mais informações, consulte Tipos de instância primária do ApsaraDB RDS.
Storage Capacity	Armazenamento máximo para arquivos de dados, arquivos de sistema, arquivos de binary log e arquivos de transação. Ajustável em incrementos de 5 GB.

Clique em Next: Instance Configuration e configure as definições de rede.

Parâmetro	Descrição
Network Type	Classic network: Tipo de rede tradicional. VPC: Recomendado. Uma virtual private cloud (VPC) oferece maior segurança e desempenho. Ao selecionar VPC, configure os parâmetros VPC e vSwitch of Primary Node. Para implantação multizona, configure também vSwitch of Secondary Node. A nova instância RDS e sua instância Elastic Compute Service (ECS) devem estar no mesmo tipo de rede — e na mesma VPC, se ambas usarem VPC — para se comunicarem por uma rede interna.
Resource Group	Atribua a instância a um grupo de recursos para simplificar o gerenciamento de recursos e permissões. Selecione um grupo existente ou crie um novo. Se o agrupamento não for necessário, selecione Default Resource Group.

Clique em Next: Confirm Order.
Revise a seção Parameter Configuration, defina Quantity e Subscription Duration (apenas para faturamento por assinatura), clique em Confirm Order e conclua o pagamento.

Nota
Para instâncias por assinatura, ative Auto-renew para evitar renovações manuais e interrupções de serviço por pagamentos atrasados.
(Opcional) Faça login na nova instância RDS e verifique os dados.

Migrar dados restaurados de volta para a instância original

Após verificar os dados na nova instância RDS, use o Data Transmission Service (DTS) para migrar alguns ou todos os bancos de dados e tabelas de volta para a instância original.

Defina a nova instância RDS como banco de dados de source e a instância RDS original como banco de dados de destino. Defina Access Method como Alibaba Cloud Instance para ambos. Consulte Migrar dados entre instâncias ApsaraDB RDS for MySQL.

Dependendo do objetivo, escolha a abordagem adequada após a restauração:

Substituir os dados da instância original: Migre todos os dados da nova instância para a instância original.
Recuperar dados específicos: Crie e execute uma tarefa de migração que extraia apenas os bancos de dados ou tabelas afetados e aplique-os na instância original.

Métodos de restauração por destino

Destino	Métodos disponíveis
Instância RDS original	Método 1: Restaure para uma nova instância, verifique e então migre os dados selecionados de volta para a instância original. Método 2: Use o recurso de restauração de banco de dados e tabelas para restaurar diretamente. Método 3: Use o Database Backup (DBS) para criar um backup lógico e restaure usando o arquivo de backup lógico — consulte Restaurar um banco de dados MySQL a partir de um backup lógico.
Outra instância RDS existente	Método 1: Restaure para uma nova instância, verifique e então migre os dados para a instância de destino. Método 2: Use o DBS para criar um backup lógico e restaurar — consulte Restaurar um banco de dados MySQL a partir de um backup lógico.
Banco de dados autogerenciado	Método 1: Restaure para uma nova instância, verifique e então migre os dados. Método 2: Use o DBS para criar um backup lógico e restaurar — consulte Restaurar um banco de dados MySQL a partir de um backup lógico. Método 3: Baixe um arquivo de backup e restaure a partir dele — consulte Restaurar a partir de um backup físico, Restaurar a partir de um backup lógico ou Restaurar usando arquivos de backup snapshot.

Para orientações de restauração de outros mecanismos de banco de dados, consulte Restaurar dados do SQL Server, Restaurar dados de uma instância ApsaraDB RDS for PostgreSQL e Restaurar dados de uma instância ApsaraDB RDS for MariaDB.

Perguntas frequentes

Como restauro bancos de dados individuais que foram excluídos?

Use o recurso de restauração de banco de dados e tabelas para restaurar bancos de dados e tabelas específicos. Se sua instância não suportar esse recurso, restaure os bancos de dados excluídos para uma nova instância RDS, verifique os dados e migre-os de volta para a instância original.

Posso restaurar dados para um ponto específico no tempo?

Sim, se o backup de logs estiver ativado. É possível restaurar para qualquer ponto dentro do período de retenção do backup de logs. Se o backup de logs estiver desativado, a restauração só é possível para o momento em que o backup de dados foi criado. Para verificar o período de retenção do backup de logs, consulte Usar o recurso de backup de logs.

Posso restaurar para um ponto no tempo se não existirem arquivos de backup de dados?

Não. A recuperação point-in-time exige um backup completo de dados concluído antes do horário alvo, além dos binary logs desse backup até o horário alvo. Sem um backup completo, nenhum dos dois pode ser aplicado.

Se o período de retenção de backup for de sete dias, posso restaurar dados de sete dias atrás?

Não. Quando o período de retenção expira, os backups são excluídos automaticamente e não podem ser recuperados.

Posso usar o recurso de rastreamento de dados do Data Management (DMS) para recuperar backups excluídos?

Não. O rastreamento de dados usa binary logs, que também estão sujeitos ao período de retenção de backup. Binary logs anteriores ao período de retenção ficam indisponíveis. Para estender o histórico de recuperação, aumente o período de retenção de backup — consulte Backup automático.

Por que sou cobrado pela restauração de dados?

As cobranças referem-se à nova instância RDS criada durante a restauração, não à operação de restauração em si. A instância é faturada desde o momento de sua criação. Consulte a seção Faturamento acima para opções de minimização de custos.

Quanto tempo leva para restaurar dados para uma nova instância RDS?

O tempo de restauração depende do volume de dados e das condições da rede. Na maioria dos casos, o processo leva de vários minutos a várias horas.

O tempo necessário varia conforme o volume de dados, as especificações da instância, o tipo de armazenamento e a complexidade dos binary logs. Como referência, restaurar 200 GB de dados em uma instância High-availability Edition de 2 núcleos e 4 GB de memória com Premium Local SSDs leva aproximadamente 3 horas (com tempo de aplicação de binary log de 30 minutos).

Exemplo do tempo necessário para restauração de dados

A tabela a seguir mostra estimativas de tempo de restauração para uma instância de 2 núcleos e 4 GB de memória executando RDS High-availability Edition com Premium Local SSDs.

Operação	Tempo necessário
Criar uma instância RDS	5 minutos
Configurar uma instância RDS	15 minutos
Baixar um arquivo de backup	200 GB-hora
Iniciar uma instância RDS	5 minutos
Baixar um arquivo de binary log	200 GB-hora
Aplicar um arquivo de binary log	Baseado no conteúdo

Nota

Por exemplo, restaurar 200 GB de dados com 30 minutos de aplicação de binary log leva aproximadamente 3 horas quando os dados de backup e os binary logs são baixados serialmente.
Para uma restauração mais rápida, ative uma instância sandbox. O sistema sincroniza automaticamente os dados para a instância sandbox para recuperação rápida. Para mais informações, consulte Usar o recurso de recuperação de emergência.

Fatores

A velocidade de restauração depende de vários fatores, e falhas podem ocorrer em alguns casos, exigindo solução de problemas manual. Os seguintes fatores afetam a velocidade de restauração:

Volume de dados: Backups maiores tornam a restauração mais lenta.
Transações grandes: Binary logs contendo transações volumosas reduzem a velocidade.
Atualizações de dados quentes: Binary logs com atualizações de alta frequência reduzem a velocidade.
Restrições de chave estrangeira: A sobrecarga de verificação reduz a velocidade.
Volume de binary logs: Mais registros de binary log para recuperação point-in-time reduzem a velocidade.
Storage type: Discos em nuvem restauram mais rápido que Premium Local SSDs.
Especificações da instância: Especificações superiores melhoram a velocidade.
Versão do mecanismo de banco de dados: Versões que suportam replicação paralela restauram mais rápido.

Importante

Os seguintes fatores podem causar falhas na restauração:

Por que não consigo selecionar um vSwitch na lista suspensa vSwitch of Primary Node?

Não existem vSwitches na zona selecionada na etapa anterior. Clique no link na lista suspensa para acessar o console VPC, crie um vSwitch na zona necessária e retorne para selecioná-lo.

Próximos passos

Para restaurar bancos de dados ou tabelas individuais em vez de toda a instância, consulte Restaurar bancos de dados e tabelas individuais de uma instância ApsaraDB RDS for MySQL.
Para uma visão geral de todas as opções de restauração, consulte Visão geral dos métodos de restauração de dados.