Tabelas do MySQL em falta / corrompidas após a recreação

Question

Ontem eu despejei meus bancos de dados MySQL em um arquivo SQL e renomei o arquivo ibdata1. Em seguida, recriou-o, importou o arquivo SQL e moveu o novo arquivo ibdata1 para meu diretório de dados do MySQL, excluindo o antigo.

Eu fiz isso antes sem problema, mas desta vez algo não está certo. Quando eu examino os bancos de dados (pessoal, não MySQL), eles estão todos lá, mas estão vazios ... mais ou menos. O diretório de dados ainda tem os arquivos .ibd com o conteúdo correto neles e eu posso ver a tabela list nos bancos de dados, mas não as próprias tabelas. (Eu tenho o arquivo por tabela ativado e estou usando o InnoDB como padrão para tudo).

Por exemplo, com o banco de dados urls e sua tabela urls , posso abrir com sucesso o mysql.exe ou phpMyAdmin e use urls; . Eu posso até show tables; para ver a tabela esperada, mas quando eu tento describe urls; ou select * from urls; , ela reclama que a tabela não existe (mesmo que apenas a liste). (O MySQL Administrator lista os bancos de dados, mas nem lista as tabelas, isso indica que os dbs estão completamente vazios.)

O problema agora é que eu já deletei o arquivo SQL (e não posso recuperá-lo mesmo depois de limpar meu disco rígido). Então, estou tentando descobrir uma maneira de reparar esses bancos de dados / tabelas. Não posso usar a função de reparo da tabela, pois ela reclama que a tabela não existe e não posso descartá-la porque, novamente, reclama que as tabelas não existem.

Como eu disse, os dados em si ainda estão presentes nos arquivos .ibd e os nomes das tabelas estão presentes. Eu só preciso de uma maneira de fazer com que o MySQL reconheça que as tabelas existem nos bancos de dados (eu posso encontrar os nomes de coluna das tabelas em questão no arquivo ibdata1 usando um editor hexadecimal).

Alguma ideia de como posso reparar este tipo de corrupção? Eu não me importo de arregaçar as mangas, cavar e dar um monte de passos para consertar isso.

Muito obrigado.

    

Answer 1

Bem, eu tentei um monte de coisas e pesquisei um monte de comandos, comutadores e estruturas (não surpreendentemente, os documentos do MySQL foram muito úteis, se extensos - agulha / palheiro). Eventualmente, alguns dos meus truques funcionaram (acontece que os outros pensaram nos mesmos truques, embora eu não tenha visto as duas partes principais - recuperar a estrutura da tabela e recuperar os dados - em um lugar, então estou postando juntos aqui).

O que eu tive que fazer foi recriar o arquivo IBDATA1. Infelizmente, durante a execução do daemon detecta os bancos de dados (os diretórios), ele não pega as tabelas Innodb dentro (os arquivos IBD / FRM). Então o que eu fiz foi:

1. Esvazie o diretório de dados (ou mova o original e crie um diretório vazio)
2. Execute o daemon, deixe-o criar um novo arquivo IBDATA1 vazio
3. Importe as tabelas do sistema usando os scripts SQL em …\MySQL\share
4. Crie um banco de dados e uma tabela fictícios com o mesmo nome
5. Copiar sobre o arquivo FRM original
6. Use DESCRIBE ou melhor, SHOW TABLE CREATE para extrair a estrutura da tabela
7. Em seguida, usei DISCARD TABLESPACE na tabela
8. copiado sobre o arquivo IBD original
9. Então eu usei IMPORT TABLESPACE
10. Finalmente, eu corri o daemon com innodb-force-recovery=6
11. E eu corri mysqldump para extrair as estruturas e dados

Claro que nem sempre foi bom. Algumas tabelas estavam bem, mas algumas exigiam eliminar a tabela e o banco de dados após o SHOW TABLE CREATE e usar isso para recriar a tabela antes de tentar importar os dados. Outros nem sequer funcionaram tão longe, e eu tive que manualmente obter os comentários e nomes das colunas do arquivo FRM usando um editor hexadecimal (embora descobrir quais eram os tipos de dados e atributos, chaves, etc., era uma porcaria. tiro). Além disso, houve muitos - muitos - daemon e reinicializações de clientes.

(Eu ainda estou procurando por uma ferramenta que analise diretamente os arquivos FRM / IBD (ou pelo menos exiba a estrutura da tabela a partir de um arquivo FRM), mas parece que ninguém se incomodou em “fazer engenharia reversa” deles mesmo que seja O código-fonte aberto e os formatos de arquivos estão disponíveis publicamente.Parece que todos são complacentes usando as ferramentas oficiais do MySQL - criando assim uma grande oportunidade para empresas de recuperação de dados e ferramentas proprietárias / comerciais.)

A chave era sempre trabalhar com o mínimo absoluto (por exemplo, apenas o diretório MYSQL - ou seja, tabelas do sistema). Infelizmente, enquanto isso significava que as coisas seriam simplificadas e mais fáceis de trabalhar, isso também significava recuperar uma tabela de cada vez - o que não era grande coisa para mim, mas para algumas pessoas poderia ser.

De qualquer forma, dentre as muitas páginas de recuperação do MySQL na Internet que vi nos últimos dias, um pequeno punhado foi bastante útil, e vou adicioná-las assim que eu vasculhar meu histórico para desenterrá-las.


Espero que isso possa ajudar os outros em uma situação semelhante.

    

Answer 2

Ser capaz de listar todas as tabelas & banco de dados geralmente significa que os arquivos * .frm estão lá. Eles não significam que há dados para eles. Você já tentou iniciar o processo do mysqld forçando a recuperação de innodb ? Se não, tente, de sim, o que o log mysql diz ao iniciar?

Depois disso, nunca tente usar backups desse tipo novamente.