Recuperação e retorno à operação

Fazer o MySQL iniciar ou terminar uma importação é só uma parte da recuperação. Antes de devolver o sistema aos usuários, é preciso demonstrar que os dados chegaram ao ponto esperado e que a aplicação consegue operar sem repetir o defeito nem gravar sobre um estado incoerente.

Recuperar, validar e retornar

• Recuperar: restabelecer o acesso e o conteúdo, conforme um objetivo definido.
• Validar: comparar o resultado com critérios e evidências.
• Retornar à operação: liberar o uso normal do ambiente aprovado, com acompanhamento.

Definir o resultado esperado

Antes da intervenção, ficam registrados o servidor, o banco, a versão, o engine, os sintomas e o período afetado. Duas perguntas definem o objetivo: até qual momento os dados precisam ser recuperados e por quanto tempo a loja pode ficar parada.

Uma cópia de segurança devolve os dados ao momento em que foi feita. As alterações posteriores dependem do log binário, que vem desligado nas versões antigas, como a 5.1. Sem ele, as vendas feitas entre a cópia e o problema ficam fora da restauração, e esse intervalo precisa ser tratado de forma explícita, por exemplo com os dados já enviados à matriz.

Escolher o caminho pelo estado dos dados

• Serviço acessível e dados legíveis: a investigação confere as consultas, os bloqueios, as definições e os metadados da aplicação, sem restauração.
• Dano físico com os dados legíveis: a reconstrução, o reparo ou a exportação adequados ao engine, com a cópia preservada.
• InnoDB que não inicia: o log de erros, a preservação com o serviço parado e a recuperação forçada com a equipe responsável.
• Dados ilegíveis ou exportação incompleta: a restauração de uma cópia testada e o registro do que não foi recuperado.

Restaurar com o destino e o momento controlados

A primeira restauração acontece em um ambiente isolado, sem ligação com a sincronização da matriz nem com integrações reais. O conteúdo do arquivo de exportação é examinado antes, e o resultado é conferido antes de qualquer estação apontar para ele.

A aplicação do log binário depois da cópia exige a posição de início, os arquivos na ordem certa e um ponto final definido. Um evento aplicado duas vezes, ou além do limite, altera os dados de novo.

Os dados das tabelas e a tabela de controle das ordens precisam vir do mesmo momento. Uma cópia dos dados de ontem com a tabela de controle de hoje forma um conjunto incoerente, e a decisão sobre esse caso fica registrada.

Conferir a estrutura e o conteúdo

• o engine, as colunas, os índices e as definições;
• as contagens exatas, com a mesma condição da marca de exclusão;
• o maior identificador e o próximo valor do contador;
• a tabela de controle, os nomes dos índices e as colunas derivadas;
• as ligações entre as tabelas, com as consultas de registros órfãos;
• os erros do serviço e o resultado das consultas da aplicação.

Uma contagem igual não prova que as linhas são as mesmas, e o mesmo maior identificador não prova que os números continuam ligados às mesmas vendas. O resultado OK do CHECK TABLE não valida as regras da aplicação.

Testar a aplicação sem efeitos indevidos

Na cópia isolada, os testes cobrem as buscas, a navegação e os relatórios ligados ao problema. Uma operação que gera venda, comunicação com a matriz, pagamento ou envio a uma integração exige um modo de teste. Antes da liberação, o arquivo de configuração de cada estação precisa apontar para o servidor e o banco certos, e as tabelas precisam ser reabertas na aplicação, para que as definições atuais sejam carregadas.

Liberar e acompanhar

A liberação registra quem validou, o ponto recuperado, o que foi conferido e as limitações que ficaram. Depois do retorno, o acompanhamento observa os erros, a busca afetada, as gravações e os bloqueios durante um período combinado. Se a causa do problema, como um disco com defeito ou uma transação esquecida, ainda não foi esclarecida, a investigação continua.

Se a validação falhar depois que os usuários voltaram a gravar, as vendas novas também precisam ser preservadas. A volta para a cópia anterior, nessa situação, não é uma simples troca de arquivos.

Critérios de liberação

• O ponto recuperado e o intervalo sem cobertura estão conhecidos?
• A recuperação terminou sem erros pendentes?
• A estrutura, os dados e as identidades foram conferidos com a referência certa?
• A tabela de controle, os índices e as colunas derivadas correspondem à aplicação?
• O servidor funciona com a configuração normal, sem a recuperação forçada?
• As estações apontam para o servidor e o banco certos?
• As buscas e as operações afetadas foram testadas de forma controlada?
• As limitações, o responsável pela liberação e o acompanhamento estão registrados?