Preservar antes de mexer

Um reparo pode descartar linhas, e uma correção pode atingir os dados errados. Uma cópia do estado anterior permite investigar o que mudou e recuperar o que se perdeu. Essa cópia precisa ser consistente e adequada ao engine, e um arquivo ou uma tabela com a palavra backup no nome não garante, sozinho, uma restauração.

A exportação lógica

O mysqldump é a ferramenta do MySQL que lê o banco e gera um arquivo de comandos SQL com a estrutura e os dados das tabelas. Ele funciona com o InnoDB e com o MyISAM e roda no Prompt de Comando, com o servidor indicado na própria linha:

• mysqldump --host=192.168.1.10 --user=backup --password --single-transaction loja vendas itens_venda --result-file=vendas_20261008.sql: exporta as tabelas vendas e itens_venda do banco loja, no servidor da loja.

As partes do comando têm funções próprias:

• --host: indica o servidor. Sem essa opção, a ferramenta procura o MySQL no próprio computador, e a cópia pode sair do banco errado.
• --password: faz a ferramenta pedir a senha, sem deixá-la escrita na linha de comando.
• --single-transaction: lê as tabelas InnoDB em uma visão consistente, sem bloquear as gravações.
• --result-file: grava o arquivo pela própria ferramenta, sem depender do redirecionamento do terminal.

As tabelas relacionadas entram no mesmo comando, para que todas reflitam o mesmo momento. Sem a opção --single-transaction, o mysqldump bloqueia as tabelas exportadas até o fim da cópia, e as gravações das estações nessas tabelas podem esperar durante esse tempo. A opção --single-transaction desliga esse bloqueio e garante a consistência só nas tabelas InnoDB. Em tabelas MyISAM, a exportação acontece com o sistema parado ou sem essa opção, como neste comando:

• mysqldump --host=192.168.1.10 --user=backup --password loja vendas itens_venda --result-file=vendas_20261008.sql: exporta as mesmas tabelas com o bloqueio padrão da ferramenta.

Conferir a exportação

A existência do arquivo não prova que a exportação terminou. O arquivo de uma exportação completa termina com uma linha de comentário com as palavras Dump completed e a data, e um arquivo sem essa linha foi interrompido. As mensagens de erro da ferramenta, o servidor e o banco de origem também entram no registro da cópia, e a prova final é uma restauração em um destino de teste.

A cópia dentro do mesmo banco

• CREATE TABLE vendas_antes_20261008 AS SELECT * FROM vendas;: cria uma tabela com as linhas da tabela vendas.

Essa cópia guarda as linhas legíveis, mas não reproduz a tabela inteira. A tabela nova nasce sem a chave primária, sem os índices e sem a numeração automática, e usa o engine padrão do servidor, que pode ser diferente do engine da tabela original. Além disso, ela fica no mesmo servidor e não protege contra a perda do disco. Por isso, essa cópia serve como fonte de dados e vem acompanhada da definição original, guardada com o SHOW CREATE TABLE.

A volta dos dados a partir dessa cópia usa um INSERT com a lista de colunas, incluindo a chave primária, para preservar as identidades. O procedimento define antes se a tabela de destino está vazia, quais linhas serão recuperadas e como evitar as duplicidades.

A cópia dos arquivos

Em uma tabela MyISAM, a cópia física reúne os arquivos de dados e de índices e, até o MySQL 5.7, o arquivo de definição. A cópia exige o serviço parado ou a tabela bloqueada, com o conteúdo da memória gravado no disco:

• FLUSH TABLES vendas WITH READ LOCK;: grava no disco o que estava em memória e bloqueia as gravações na tabela;
• UNLOCK TABLES;: libera o bloqueio, depois da cópia dos arquivos.

Os dois comandos usam a mesma conexão, que fica aberta durante toda a cópia, porque o encerramento dessa conexão libera o bloqueio antes da hora. Essa forma do FLUSH TABLES existe a partir do MySQL 5.5, e, no 5.1, a cópia dos arquivos se faz com o serviço parado. Em uma tabela InnoDB, a cópia isolada do arquivo da tabela não é uma cópia de segurança, e a preservação usa a exportação lógica ou uma ferramenta própria de cópia física.

As evidências

Antes da intervenção, convém guardar também:

• o registro de erros do sistema e o log de erros do MySQL, cujo caminho aparece com o comando SELECT @@log_error;;
• a saída do SHOW CREATE TABLE, do SHOW TABLE STATUS e das medidas de referência da tabela;
• a tabela de controle das ordens da aplicação, quando a intervenção pode afetar os índices.

Os dados e os metadados da aplicação precisam vir do mesmo momento. Uma tabela restaurada de um momento e uma tabela de controle de outro deixam as ordens em desacordo.

O que a preservação precisa cobrir

A cópia de uma única tabela guarda as linhas dela, mas uma restauração útil para a aplicação pode exigir também as tabelas relacionadas, a tabela de controle, as definições e um momento comum entre elas. Restaurar só uma parte pode trocar um defeito físico por registros órfãos. Por isso, o escopo da preservação é definido antes do reparo, com o registro da versão da ferramenta, do servidor de origem, do banco, do horário, das opções usadas e do local da cópia.