Backup lógico e restauração no MySQL (mysqldump, MySQL Shell)

Backup e restauração lógicos com mysqldump ou MySQL Shell (util.dumpInstance / dumpSchemas / dumpTables + util.loadDump): uma tabela, um schema ou a instance inteira; somente estrutura ou somente dados; migração para outro servidor; extração de uma única tabela de um dump completo; backup agendado com systemd/cron, sem senha via login-path, verificado e com retenção. Todo caminho termina com uma comparação de contagem de linhas. Use este guia para migrações, recuperação de um único objeto e mudança entre versões; para o backup diário de bancos grandes, restore rápido e recuperação para um ponto no tempo (PITR), use o guia do Percona XtraBackup.

Topologia: 1 servidor (+ um servidor de destino na migração e na restauração da instance)

Cenários

• Export / import de tabela(s) — Fazer backup de uma ou mais tabelas, copiá-las para outro schema/servidor ou restaurá-las. A origem continua no ar; não são obtidos locks em tabelas InnoDB.
• Fazer backup / restaurar um schema (banco de dados) — Fazer backup de um banco de dados (schema) inteiro ou carregá-lo em outro schema/servidor. A origem continua no ar; no destino, as tabelas com o mesmo nome são removidas e recriadas.
• Instance inteira (usuários + todos os schemas) — O backup é feito neste servidor e a restauração é feita em um servidor vazio: usuários, privilégios e todos os schemas. Para reconstruir um servidor ou mudar de versão/plataforma.
• Somente estrutura (DDL) — Definições de tabelas, views, triggers, procedures e events; sem dados. Para comparar schemas, montar um ambiente vazio ou colocar a estrutura sob controle de versão.
• Somente dados — Somente as linhas são transferidas, com a estrutura já pronta no destino (ex.: atualizar dados de teste). Triggers no destino podem disparar durante a carga; o guia verifica isso.
• Migração para outro servidor — O trabalho é feito no servidor de destino; a conexão com a origem é feita pela rede, com login-path. No momento do corte, a aplicação para de gravar; a indisponibilidade dura o tempo do dump + carga. Para trocar de servidor, sistema operacional ou versão.
• Extrair uma única tabela de um dump completo — Você tem um dump completo e precisa de apenas uma tabela (linhas apagadas, tabela removida com DROP). Ela é extraída para um schema separado sem mexer no schema original, ou a tabela removida é recolocada.
• Backup agendado (systemd timer / cron) — Backup lógico automático todos os dias em horário definido: usuário de backup separado, login-path, script, systemd timer ou cron, período de retenção e notificação de erro. A origem continua no ar.

Antes de começar

• O MySQL … está rodando; o root do sistema operacional consegue se conectar sem senha com o comando mysql (auth_socket ou ~/.mylogin.cnf). Se foi instalado com o guia Instalação do MySQL em servidor único do DBAtlas, os caminhos são os mesmos.
• O tamanho dos schemas é conhecido e o diretório de backup … tem espaço livre suficiente (um backup lógico compactado costuma ter 10–30% do tamanho dos dados; os índices entram no dump apenas como definição).
• Todas as tabelas são InnoDB. O --single-transaction (e o dump consistente do MySQL Shell) só é consistente e sem locks em tabelas InnoDB; se houver uma tabela MyISAM, gravações nela durante o dump geram inconsistência.
• O servidor em que o MySQL Shell será instalado acessa o repositório do MySQL (repo.mysql.com) ou há um mirror interno configurado.
• No servidor de destino … está instalada e rodando a mesma versão do MySQL ou uma mais nova (com o guia de instalação do DBAtlas), sem schemas de usuário. Não é suportado carregar em uma versão mais antiga, como de 8.4 para 8.0 em um rollback.
• O servidor de destino acessa a porta … da origem.
• O servidor consegue enviar e-mail: o MTA local (postfix) encaminha para o SMTP relay corporativo.
• Foi planejada uma janela de manutenção para uma restauração ou migração grande; se o destino for sobrescrito, foi feito backup do destino.
• Este servidor é uma replica saudável: as threads IO e SQL estão Yes e o atraso é baixo. A posição do binlog no dump (--source-data=2) se refere ao binlog desta própria replica; se for usada em PITR, log_replica_updates deve estar habilitado (padrão no 8.x).
• Este servidor é membro de um InnoDB Cluster e está agora SECONDARY / ONLINE.

Fases do guia

• Preparação — Criar o diretório de backup · Verificar os engines das tabelas e as transações longas · Instalar o MySQL Shell
• Restauração (import) — Criar o schema de destino · Criar a estrutura das tabelas no destino · Verificar as triggers no destino · Carregar (mysql) · Carregar (mysql, sobre o mesmo schema) · Carregar (util.loadDump) …
• Backup da instance — Exportar usuários e privilégios · Fazer backup de todos os schemas (mysqldump) · Fazer backup da instance (util.dumpInstance) · Copiar o backup para o servidor de restauração · Carregar o backup (mysql) · Carregar os usuários …
• Conta de migração no servidor de origem — Criar o usuário de migração · Liberar a porta para o destino no firewall · Parar a aplicação (momento do corte)
• Transferência no servidor de destino — Salvar a conexão com a origem como login-path · Migrar os usuários · Transferir os schemas (mysqldump | mysql) · Carregar os usuários no destino · Fazer o dump da origem (util.dumpInstance / dumpSchemas) · Carregar no destino (util.loadDump) …
• Extração de uma única tabela do dump — Verificar se a tabela está no dump · Extrair a tabela do dump · Criar o schema de destino · Carregar a tabela · Restaurar a tabela no schema original · Comparar a contagem de linhas …
• Usuário de backup e login-path — Criar o usuário de backup do sistema operacional · Criar a conta de backup do MySQL · Salvar o login-path (mysql_config_editor)
• Script de backup — Instalar a ferramenta de notificação · Gravar o script de backup · Tornar o script executável · Fazer o primeiro backup manualmente
• Agendamento (systemd timer) — Gravar o serviço systemd · Gravar o systemd timer · Habilitar o timer e disparar o serviço manualmente · Verificar se o job agendado rodou (no dia seguinte)
• Agendamento (cron) — Preparar o serviço cron · Gravar o job do cron · Ajustar a permissão do arquivo do cron e testar no ambiente do cron · Verificar se o job agendado rodou (no dia seguinte)
• Verificação e monitoramento — Restaurar o último backup em um schema de teste · Monitorar a idade do último backup
• Próximo passo: backup físico — Cobrir os limites do backup lógico