ApsaraDB RDS:Restaurar um backup lógico do RDS MySQL para um banco de dados auto-gerenciado

Como funciona

1. Baixe o arquivo de backup lógico no console do RDS.

2. Descompacte o arquivo .tar e, em seguida, os arquivos .sql.gz de cada banco de dados.

3. Crie um banco de dados de destino vazio e importe os arquivos de esquema e de dados com o comando mysql.

Pré-requisitos

Antes de começar, verifique se você tem:

• Uma instância ApsaraDB RDS for MySQL com todas as características abaixo (verifique na página Basic Information):

  • Versão principal: 8,0, 5,7, 5,6 ou 5,5

  • Edição: High-availability Edition

  • Tipo de armazenamento: Local SSD

• Um arquivo de backup lógico já criado. Backups lógicos exigem criação manual, pois o sistema gera backups físicos por padrão. Consulte Backup manual.

• Um host Linux que execute a mesma versão principal do MySQL da instância RDS, com espaço livre em disco suficiente para armazenar os arquivos de backup descompactados.

Baixar o arquivo de backup

1. Acesse a página Instances. Na barra de navegação superior, selecione a região onde sua instância RDS está localizada e clique em ID da instância.

2. No painel de navegação à esquerda, clique em Backup and Restoration.

3. Na aba Base Backups > Data Backup, localize o arquivo de backup lógico desejado e clique em Download Instance Backup File na coluna Actions.

   Nota

   Se a opção Download Instance Backup File estiver indisponível, verifique se a edição da sua instância suporta download de backups.

4. Na caixa de diálogo Download Instance Backup File, copie a URL de download:

   • Se sua instância ECS e a instância RDS estiverem na mesma VPC (recomendado): copie a URL de rede interna. Essa opção é mais rápida e estável, especialmente para arquivos de backup grandes.

   • Caso contrário: copie a URL de download externa. Há uma cota gratuita para downloads de backup via internet; o tráfego excedente é cobrado. Consulte Faturamento.

5. No host Linux, execute o comando abaixo para baixar o arquivo de backup. Substitua <download_url> pela URL copiada e <custom_file_name> pelo nome de sua preferência.

   Flag	Descrição
   -c	Habilita downloads retomáveis; o processo continua de onde parou caso seja interrompido
   -O	Salva o arquivo com o nome especificado

   wget -c '<download_url>' -O <custom_file_name>.tar

Descompactar o arquivo de backup

1. Extraia o arquivo .tar:

   Nota

   Se aparecer a mensagem This does not look like a tar archive, confirme se você baixou um arquivo de backup lógico do RDS, e não um backup físico. Caso veja Wrote only 512 of 10240 bytes, seu disco está cheio. Altere a configuração da instância para aumentar o espaço em disco e tente novamente.

   tar xvf <custom_file_name>.tar -C /tmp

2. Verifique a estrutura de diretórios após a extração. O arquivo contém um subdiretório por banco de dados, cada um com um arquivo de esquema e outro de dados:

   tree /tmp/backup_root/   # Replace with the actual root directory created by tar.

   Saída esperada:

   /tmp/backup_root/
   ├── database1/   # Directory of target database 1
   │ ├── schema.sql # Database schema file
   │ └── data.sql   # Data file
   ├── database2/   # Directory of target database 2
   │ ├── schema.sql
   │ └── data.sql
   └── config.txt    # Backup metadata (optional)

3. Acesse o diretório do banco de dados que deseja restaurar:

   cd /tmp/backup_root/<database_name>

4. Descompacte os arquivos .sql.gz:

   gzip -d schema.sql.gz
   gzip -d data.sql.gz

   Esse procedimento gera os arquivos schema.sql e data.sql, que serão importados na próxima etapa.

Importar os dados

1. Faça login no MySQL e crie um banco de dados de destino vazio. O usuário precisa ter permissão para executar todas as instruções SQL nos arquivos .sql.

   Placeholder	Descrição	Exemplo
   <user>	Nome de usuário do MySQL	root
   <password>	Senha do MySQL (sem espaço após -p)	mypassword
   <target_database_name>	Nome do banco de dados vazio a ser criado	restored_db

    mysql -u <user> -p<password>

    CREATE DATABASE <target_database_name>;
    EXIT;

   Substitua os placeholders conforme indicado:

2. Importe o esquema e, depois, os dados:

   Nota

   Se aparecer a mensagem Can't find master key from keyring, sua instância pode não atender aos pré-requisitos listados neste guia. Verifique a edição e o tipo de armazenamento da instância RDS.

    # Import the table schema
    mysql -u <user> -p <target_database_name> < schema.sql
   
    # Import the data
    mysql -u <user> -p <target_database_name> < data.sql

   Insira sua senha quando solicitado após cada comando.

Verificar a restauração

1. Faça login no MySQL e confirme se as tabelas e os dados estão presentes:

    mysql -u <user> -p

    USE <target_database_name>;
    SHOW TABLES;                            -- Check that tables exist
    SELECT COUNT(*) FROM <table_name>;      -- Verify the row count

   Se as tabelas e os dados aparecerem, a restauração foi concluída.

Perguntas frequentes

Por que minha instância não possui backups lógicos?

O RDS cria backups físicos por padrão. Para obter um backup lógico, crie-o manualmente. Consulte Backup manual.

Por que o valor de Restore Point in Time é 0 para backups lógicos?

A restauração point-in-time exige um backup físico combinado com um backup de log. Backups lógicos não suportam restauração point-in-time; portanto, o campo Restore Point in Time exibe 0.

Como corrigir ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty?

Esse erro indica que o banco de dados de destino já contém histórico de identificadores globais de transação (GTID). Use uma das abordagens abaixo:

• Ative o GTID no banco de dados de destino e execute a importação novamente.

• Comente todas as linhas GTID_PURGED no arquivo .sql e execute a importação novamente.

• Se a replicação primária/secundária não estiver em uso, execute RESET MASTER no banco de dados de destino para limpar o histórico de GTID e execute a importação novamente.

Como corrigir ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED?

O arquivo .sql contém informações de GTID que entram em conflito com o histórico existente no banco de dados de destino. Execute RESET MASTER para limpar o histórico de GTID e execute a importação novamente.

Por que os dados restaurados estão apenas no banco de dados primário e não foram sincronizados com o secundário?

O arquivo .sql contém SESSION.SQL_LOG_BIN= 0, que desativa o log binário durante a importação e impede a replicação das alterações para o banco de dados secundário. Verifique essa configuração no arquivo de importação.

Próximos passos

• Fazer backup de uma instância ApsaraDB RDS — configure backups automáticos para facilitar futuras restaurações.

• Usar mysqldump para migrar dados do MySQL — migre dados de um banco de dados auto-gerenciado para uma instância RDS.

• Opções do mysqldump para RDS MySQL — referência para todas as flags do mysqldump suportadas pelo ApsaraDB RDS for MySQL.