Backup lógico e inventário recuperável | MySQL: desenvolvimento e operação segura

Definir um resultado verificável

O laboratório começa com contas A e B, saldos 40 e 60 e duas linhas de auditoria criadas por um trigger. Acrescenta uma view de totais, uma procedure de leitura e um evento deliberadamente desativado. Este inventário fornece resultados verificáveis para o restauro: duas linhas, total 100 e os objetos necessários ao fluxo. Um exit code zero do dump apenas confirma o comando dentro do âmbito pedido; não confirma que esse âmbito cobre todo o serviço. Regista tabelas, dados, objetos executáveis, contas e configuração que exigem tratamento próprio. Os exemplos são sintéticos e não representam dados ou procedimentos internos de qualquer banco.

Snapshot e limites da concorrência

Durante a produção dos dumps, outra ligação manteve uma atualização de A para 999 sem commit. O dump com single-transaction recuperou mais tarde o valor confirmado 40, e a escrita pendente foi desfeita. Isto demonstra exclusão dessa alteração não confirmada em tabelas InnoDB; não testa todas as combinações de concorrência. Não foi executado DDL durante a cópia. A documentação limita as garantias de consistência aos motores e operações apropriados, pelo que não se deve alargar o resultado a MyISAM ou a alterações de schema concorrentes. Define a coordenação entre backup e mudanças antes da janela, incluindo o que fazer se uma operação incompatível estiver em curso.

O âmbito inclui mais do que tabelas

A primeira restauração usou um dump sem as opções routines e events. Recuperou duas tabelas, uma view e um trigger, mas nenhuma procedure nem evento. O dump seguinte incluiu explicitamente esses objetos e o inventário no destino confirmou ambos. Não avalies completude apenas pela contagem de tabelas ou pelo tamanho do ficheiro. Uma aplicação pode iniciar e só falhar quando chamar uma rotina ausente ou quando esperar uma tarefa agendada. O evento do ensaio permaneceu desativado e o scheduler foi mantido OFF para impedir execução de trabalho agendado. A presença de um evento não demonstra que deva ser ativado automaticamente durante recuperação.

Estrutura sem dados e dados sem estrutura

A opção no-data produziu estrutura e objetos, mas deixou accounts e audit vazias no destino. Um ficheiro apenas com os dados de accounts falhou com 1146 quando a tabela ainda não existia. Depois de carregar a estrutura correspondente, o mesmo ficheiro inseriu as duas contas. O trigger já existente criou então duas linhas de auditoria. Este efeito ajuda a perceber por que a ordem e o âmbito da recuperação importam: carregar dados em objetos já ativos pode executar lógica adicional. O teste deve observar o resultado de negócio e os efeitos associados, não apenas confirmar que os INSERT terminaram sem erro.

A origem pode avançar depois do backup

Depois de terminar os dumps, a origem confirmou A=999 e acrescentou LATE=5, passando a três contas e total 1064. O restauro completo continuou a apresentar A=40, B=60 e total 100. O ficheiro reproduz o estado capturado; não incorpora automaticamente alterações posteriores. A diferença não prova corrupção, mas exige explicar o ponto de recuperação ao negócio. O laboratório não reproduziu binary logs nem recuperou até um instante escolhido. Se o requisito for mais recente do que o backup, é necessário um plano apropriado de recuperação incremental e evidência de execução. A existência de logs por si só não comprova que essa cadeia foi aplicada corretamente.

Identificar artefacto e configuração

O guião registou SHA256 do dump e confirmou que os bytes permaneceram iguais durante os restauros. Isso identifica o artefacto usado e ajuda a detetar alterações, mas não prova autenticidade da origem nem completude funcional. Os dois servidores executaram MySQL 9.7.2 e apresentaram GTID mode ON. O dump usou set-gtid-purged=OFF neste ensaio de recuperação lógica isolada; não demonstrou preservação do histórico GTID para montar uma réplica. As opções de configuração e login foram explicitamente limitadas aos sockets privados do laboratório. Num serviço real, credenciais, proteção dos artefactos, transporte e escolha da política GTID exigem validação apropriada ao ambiente.

mysqldump --no-defaults --no-login-paths --protocol=SOCKET \
  --socket=/owned/source/mysql.sock --user=root \
  --single-transaction --quick --no-tablespaces --set-gtid-purged=OFF \
  --routines --events --databases lab > full.sql
# Lab-only empty-password account on a private socket. Review options for a real service.
mysql --no-defaults --no-login-paths --protocol=SOCKET \
  --socket=/owned/target/mysql.sock --user=root --batch < full.sql

NA PRÁTICA

O dump normal recuperou tabelas, view e trigger, mas só a versão com opções explícitas incluiu a procedure e o evento desativado.

Armadilhas comuns

Ficheiro existente como recuperação; dump de uma base como backup de contas; single-transaction como proteção de qualquer motor ou DDL.

Tópicos relacionados: Backup lógico e inventário de objetos · Permissões e aceitação da recuperação

Leva esta ideia contigo

A evidência começa no âmbito escolhido e termina no estado observado do destino, incluindo os objetos de que a aplicação depende.

Criar conta

Referência: Logical backup scope and options · MySQL 9.7 LTS with InnoDB reference semantics