Recuperação de Dados em MySQL
Resposta direta
MySQL falha por InnoDB tablespace corrompido (ibdata1, .ibd), MyISAM crashed (.MYI/.MYD), binary log perdido, atualizações mal-sucedidas e crashes durante write. A HD Doctor recupera 90% dos casos MySQL via InnoDB recovery, MyISAM repair e parser nativo de tablespaces. Em 24+ anos atendemos 320+ casos MySQL/MariaDB. Diagnóstico gratuito em 24h.
Crítico: NÃO rode innodb_force_recovery > 4 sem backup, NÃO delete ibdata1 achando que é só log, NÃO rode REPAIR TABLE em MyISAM com I/O errors. MySQL tem comandos de reparo agressivos que podem amplificar dano.
Como MySQL organiza os dados
MySQL/MariaDB usa engines de storage: InnoDB (default, transacional, ACID com .ibd por tabela + ibdata1 system tablespace + ib_logfile redo log) e MyISAM (legado, com .MYD data + .MYI index + .frm schema). Falhas comuns: InnoDB com page corruption, ibdata1 destruído após disk full, MyISAM tabela marked as crashed, binary log perdido e crashes durante COMMIT.
Sintomas comuns em MySQL
- InnoDB: "Table doesn't exist" mas .ibd existe no filesystem
- InnoDB: "Tablespace has been discarded"
- MyISAM: "Table is marked as crashed"
- Erro 1932 (table not found in engine)
- MySQL não inicia, ibdata1 corrupted
- Binary log corrompido ou ausente
- Replication broken, slave not in sync
- Database em SUSPECT após crash do OS
Causas mais frequentes em MySQL
| Causa | % | Recuperável? |
|---|---|---|
| InnoDB tablespace corrompido (.ibd ou ibdata) | 32% | ✅ Sim, parser InnoDB |
| MyISAM crashed (table is marked as crashed) | 20% | ✅ Sim, MyISAM repair |
| Storage failure sob datadir | 15% | ✅ Sim, recuperação de storage primeiro |
| Crash durante COMMIT (data inconsistente) | 12% | ✅ Sim, redo log + recovery |
| DROP TABLE/DATABASE acidental | 10% | ✅ Sim, file carving |
| Binary log perdido (replication) | 6% | ✅ Sim, reconstrução via slave |
| Outros (corruption pós-update) | 5% | ✅ Sim |
Fonte: estatísticas internas da HD Doctor sobre 320 casos de MySQL/MariaDB entre 2022 e 2025.
O que NÃO fazer em MySQL com problema
- 1.Não rode innodb_force_recovery > 4 sem backup. Modo 5+ pode destruir indexes e dados ainda recuperáveis.
- 2.Não delete ibdata1. ibdata1 contém system tablespace, undo logs e (em config legado) dados de tabelas.
- 3.Não rode REPAIR TABLE com I/O error em curso. Pode amplificar corrupção da tabela MyISAM.
- 4.Não copie .ibd entre databases sem matching ibdata. Tablespace IDs precisam coincidir com o data dictionary.
- 5.Não rode mysql_upgrade com banco em SUSPECT. Update de schema em banco corrompido pode brickar instances.
- 6.Não rode FLUSH TABLES com problema em curso. Pode forçar write de páginas em estado inconsistente.
Como a HD Doctor recupera MySQL
Trabalhamos sobre cópias do datadir. Para InnoDB usamos parser nativo; para MyISAM, reconstrução de header e index.
- 1
Recebimento do datadir
Você envia datadir/ inteiro ou os discos do servidor MySQL.
- 2
Diagnóstico em 24h
Identificação de versão MySQL, engines em uso (InnoDB/MyISAM), tipo de corrupção.
- 3
Laudo gratuito com escopo
Análise técnica antes da aprovação, listando tabelas viáveis.
- 4
InnoDB recovery
Para InnoDB, parser nativo extrai páginas dos .ibd, ignora corrompidas e reconstrói o data dictionary se necessário.
- 5
MyISAM repair técnico
Para MyISAM, reconstruímos .MYI a partir do .MYD e validamos via myisamchk.
- 6
Recovery via redo log
Quando ib_logfile está disponível, aplicamos redo controlado para chegar ao último COMMIT consistente.
- 7
Extração via parser custom
Para casos extremos, extraímos linhas individuais do filesystem InnoDB ignorando indexes corrompidos.
- 8
Validação dos dados
Comparamos contagens de linhas e integridade em instância de teste.
- 9
Entrega + laudo final
Database restaurado ou dump SQL/CSV, laudo técnico assinado.
Tempo e SLA
| Cenário | Prazo |
|---|---|
| MyISAM crashed (1 tabela) | 3–7 dias úteis |
| InnoDB tablespace corrompido | 5–12 dias úteis |
| Database completo + storage failure | 10–20 dias úteis |
| DROP acidental + file carving | 8–15 dias úteis |
- SLA emergencial 24h disponível para MySQL em produção.
- Política No Data, No Charge: se não recuperarmos as tabelas críticas que você indicou, você não paga pelo serviço. Diagnóstico gratuito em 92% dos casos.
Versões e ambientes atendidos
Atendemos MySQL 5.5, 5.6, 5.7, 8.0, 8.1, 8.2, 8.3, 8.4. MariaDB 10.x, 11.x. Percona Server 5.7, 8.0. Engines: InnoDB, MyISAM, Aria, MEMORY, ARCHIVE, CSV. Configurações: standalone, replication master-slave, Group Replication, MariaDB Galera Cluster. AWS RDS MySQL/MariaDB com snapshots.
Por que escolher a HD Doctor para MySQL
- 🏛️24+ anos dedicados exclusivamente a recuperação de dados
- 🔬Sala limpa Classe 100 + infraestrutura MySQL própria
- 🧠Parser InnoDB nativo + MyISAM repair + redo log recovery
- ⚡SLA emergencial 24h para MySQL em produção
- 🤝Único Platinum oficial Western Digital com laboratório regional
- ⚖️Laudo técnico assinado, válido para perícia e seguro
Perguntas frequentes sobre MySQL
InnoDB "Tablespace has been discarded". Recupera?
Sim, em 88% dos casos. Mensagem indica que .ibd e ibdata estão divergentes. Reattachamos via parser e extraímos dados.
MyISAM "Table marked as crashed". Tem chance?
Sim, em 95% dos casos. MyISAM crash é geralmente reparável via reconstrução do .MYI a partir do .MYD.
DROP TABLE acidental ontem. Recupera?
Sim, em 80% dos casos se o disco não foi muito gravado. Em InnoDB com file_per_table, o .ibd costuma persistir até overwrite.
Replication slave broken. Recuperam?
Sim. Reconstruímos via análise dos binary logs disponíveis ou re-sincronizamos do master.
Como funciona o orçamento?
O diagnóstico é gratuito. Após análise técnica em até 24h, enviamos por e-mail ou WhatsApp o orçamento detalhado.
Atendem AWS RDS MySQL?
Para RDS, recuperamos via snapshots disponíveis ou export do banco. Falhas catastróficas exigem suporte direto da AWS.