MySQL corrompido é um cenário que afeta sistemas web, lojas virtuais, ERPs e qualquer aplicação que use MySQL ou MariaDB como banco de dados. Por isso, quando o MySQL não consegue abrir as tabelas, reporta erros de checksum nas páginas de dados ou simplesmente recusa conexões com erros de tablespace, a aplicação para completamente. Contudo, banco de dados corrompido não significa perda definitiva dos dados — na maioria dos casos, a recuperação forense consegue extrair o conteúdo das tabelas mesmo quando o MySQL não consegue mais acessá-las. Portanto, entender a causa e o protocolo correto é o primeiro passo.

Por que o MySQL fica corrompido

Corrupção do tablespace InnoDB

O InnoDB é o mecanismo de armazenamento padrão do MySQL moderno. Ele armazena os dados em arquivos de tablespace — o arquivo ibdata1 e os arquivos .ibd individuais por tabela. Por isso, quando o servidor sofre queda de energia durante uma operação de escrita no tablespace, a página de dados pode ficar em estado parcialmente gravado. Além disso, o InnoDB usa checksum em cada página para detectar inconsistências. Portanto, ao reiniciar, o MySQL detecta o checksum incorreto e se recusa a abrir a tabela afetada.

Contudo, as páginas com checksum incorreto frequentemente são minoria dentro do arquivo de tablespace. Por isso, a Crowdertech acessa o tablespace diretamente, mapeando quais páginas têm erro e extraindo as que estão íntegras. Para recuperação de MySQL corrompido em servidor com RAID, o processo começa pela imagem forense do volume antes de qualquer tentativa de reparo.

Falha durante operação de ALTER TABLE ou OPTIMIZE TABLE

Operações de manutenção como ALTER TABLE e OPTIMIZE TABLE reescrevem completamente o arquivo de tablespace. Por isso, se a energia cai ou o servidor reinicia no meio dessas operações, o arquivo fica em estado intermediário — nem o original nem o novo. Além disso, algumas versões do MySQL não conseguem recuperar esse estado automaticamente e declaram a tabela corrompida.

Portanto, operações de ALTER TABLE em tabelas grandes em servidores de produção devem sempre acontecer com UPS ativo e fora do horário de pico. Por isso, antes de qualquer operação de manutenção, confirme que o backup está atualizado.

Corrupção do ibdata1 e undo log

O arquivo ibdata1 contém o dicionário de dados do InnoDB — o catálogo que mapeia todas as tabelas, índices e relacionamentos. Além disso, ele contém o undo log — o mecanismo de rollback de transações. Por isso, quando o ibdata1 fica corrompido, o MySQL pode não conseguir iniciar ou pode iniciar mas recusar acesso a todas as tabelas InnoDB. Contudo, os dados das tabelas ficam nos arquivos .ibd individuais — e a Crowdertech os acessa diretamente, reconstruindo o dicionário de dados por forense.

Tabelas MyISAM corrompidas

Embora menos comum em instalações novas, muitos sistemas legados ainda usam MyISAM. Por isso, o MyISAM não tem transações nem recovery automático — uma queda de energia durante escrita resulta quase sempre em corrupção. Além disso, as tabelas MyISAM têm estrutura mais simples que o InnoDB, o que torna a recuperação forense frequentemente mais direta. Por isso, a taxa de recuperação de dados de tabelas MyISAM corrompidas é alta.

O que nunca fazer quando o MySQL está corrompido

Não execute myisamchk ou mysqlcheck direto na tabela original. O mysqlcheck com a opção –repair modifica os arquivos de tabela para corrigir inconsistências. Contudo, em tabelas com corrupção extensa, o reparo pode deletar registros que considera inválidos — inclusive registros que a recuperação forense conseguiria extrair. Por isso, qualquer reparo deve acontecer sobre cópia dos arquivos, nunca nos originais. Acione a Crowdertech: (11) 99630-0675 · (11) 4863-3636.

Não ative innodb_force_recovery acima do nível 1 sem diagnóstico. O parâmetro innodb_force_recovery em níveis altos (4, 5 ou 6) instrui o InnoDB a ignorar inconsistências e montar o banco mesmo com corrupção. Contudo, níveis acima de 1 desabilitam operações que protegem os dados durante a montagem. Por isso, usar innodb_force_recovery sem entender o estado real da corrupção pode agravar os danos.

Não reinicie o MySQL repetidamente tentando forçar o recovery. Cada tentativa de inicialização com banco corrompido gera novos writes nos logs de erro e pode modificar o estado dos arquivos de tablespace. Além disso, o InnoDB em recovery automático pode tentar corrigir inconsistências de forma destrutiva. Por isso, limite os restarts ao mínimo e acione especialistas rapidamente.

Como a Crowdertech recupera MySQL corrompido

Acesso direto ao tablespace InnoDB

A Crowdertech acessa os arquivos .ibd diretamente, sem depender do MySQL estar funcional. Por isso, o processo usa ferramentas forenses que leem as páginas do InnoDB página a página, verificando os checksums individualmente. Além disso, as páginas com checksum correto são extraídas e reconstruídas em novo banco limpo. Portanto, mesmo quando o MySQL não consegue montar o banco, os dados nas páginas íntegras ficam acessíveis.

Reconstrução do dicionário de dados

Quando o ibdata1 está corrompido, a Crowdertech reconstrói o dicionário de dados analisando a estrutura dos arquivos .ibd. Por isso, mesmo sem o catálogo original, as tabelas recuperadas ficam com a estrutura de colunas correta. Além disso, para sistemas com código-fonte disponível, o schema das tabelas do código confirma a estrutura reconstituída. Para recuperação de banco de dados MySQL em servidor RAID parado, o processo inclui a recuperação do volume antes da análise do banco.

Validação antes da entrega

A Crowdertech executa mysqlcheck no banco recuperado antes da entrega — verificando a integridade de todas as tabelas e índices. Por isso, o cliente recebe um banco funcional, não apenas arquivos recuperados. Além disso, para sistemas com tabelas relacionadas, a Crowdertech verifica a integridade referencial entre as tabelas principais.

Perguntas frequentes

MySQL corrompido após atualização de versão — é diferente de corrupção por hardware? Sim. Atualizações de MySQL que mudam o formato do tablespace podem tornar arquivos de versão anterior inacessíveis na versão nova. Por isso, o diagnóstico identifica se é incompatibilidade de versão — resolvível com downgrade — ou corrupção real. Contudo, na maioria dos casos de atualização, o MySQL tem procedimentos nativos de upgrade que resolvem sem intervenção forense.

MariaDB corrompido tem o mesmo processo de recuperação? Sim. O MariaDB usa o mesmo mecanismo InnoDB do MySQL com pequenas variações. Por isso, o processo forense de recuperação é equivalente. Além disso, tabelas MyISAM no MariaDB têm recuperação idêntica ao MySQL. Contudo, algumas versões do MariaDB têm funcionalidades específicas de tablespace que exigem adaptações no processo.

Quanto tempo leva a recuperação de MySQL corrompido? O diagnóstico é entregue em horas. Para bancos com corrupção isolada em poucas páginas, a recuperação leva de 4 a 12 horas. Além disso, para bancos com ibdata1 corrompido e múltiplos .ibd afetados, o processo leva de 24 a 48 horas. Contudo, para bancos muito grandes (acima de 1 TB), o tempo pode ser maior dependendo do volume de páginas a verificar.

Conclusão

MySQL corrompido tem alta taxa de recuperação quando a ação correta começa antes das tentativas de reparo automático. Contudo, mysqlcheck direto no original, innodb_force_recovery em nível alto e restarts repetidos podem destruir dados que ainda seriam recuperáveis. Em resumo, pare o MySQL, faça cópia dos arquivos de tablespace e acione especialistas antes de qualquer outra decisão. A Crowdertech recupera MySQL corrompido com diagnóstico gratuito — (11) 99630-0675 · (11) 4863-3636.

Fontes: MySQL Documentation · NIST SP 800-34r1.