Tabelas MySQL ausentes/corrompidas após recreação

Question

Ontem despejei meus bancos de dados MySQL em um arquivo SQL e renomeei o arquivo ibdata1. Em seguida, recriei-o e importei o arquivo SQL e movi o novo arquivo ibdata1 para meu diretório de dados MySQL, excluindo o antigo.

Já fiz isso antes sem problemas, mas desta vez algo não está certo. Quando examino os bancos de dados (pessoais, não a configuração do MySQL), eles estão todos lá, mas estão vazios... mais ou menos. O diretório de dados ainda contém os arquivos .ibd com o conteúdo correto e posso visualizar a tabelalistanos bancos de dados, mas não nas próprias tabelas. (Tenho o arquivo por tabela habilitado e estou usando o InnoDB como padrão para tudo.)

Por exemplo com ourlsbanco de dados e seusurlstabela, posso abrir mysql.exe ou phpMyAdmin e use urls;. Consigo até show tables;ver a tabela esperada, mas aí quando tento o describe urls;or select * from urls;, ele reclama que a tabela não existe (mesmo queapenaslistou). (O Administrador MySQL lista os bancos de dados, mas nem lista as tabelas, indica que os bancos de dados estão completamente vazios.)

O problema agora é que já excluí o arquivo SQL (e não consigo recuperá-lo mesmo depois de vasculhar 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 de tabela porque ela reclama que a tabela não existe, e não posso descartá-las porque, novamente, ela 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 (posso encontrar os nomes das colunas das tabelas em questão no arquivo ibdata1 usando um editor hexadecimal).

Alguma ideia de como posso reparar esse tipo de corrupção? Não me importo de arregaçar as mangas, cavar e tomar várias medidas para consertar.

Muito obrigado.

Answer 1

Bem, eu tentei um monte de coisas e pesquisei um monte de comandos, opções e estruturas (não surpreendentemente, os documentos do MySQL foram muito úteis, embora extensos - agulha/palheiro). Eventualmente, alguns dos meus truques funcionaram (acontece que 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 só lugar, então estou postando-as juntas aqui).

O que tive que fazer foi recriar o arquivo IBDATA1. Infelizmente, durante a execução, o daemon detecta os bancos de dados (os diretórios), ele não coleta as tabelas internas do Innodb (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 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 fictício e uma tabela com o mesmo nome
5. Copie o arquivo FRM original
6. Use um DESCRIBEou melhor, SHOW TABLE CREATEpara extrair a estrutura da tabela
7. Em seguida, usei DISCARD TABLESPACEna mesa
8. Copiado sobre o arquivo IBD original
9. Então eu useiIMPORT TABLESPACE
10. Finalmente, executei novamente o daemon cominnodb-force-recovery=6
11. E corri mysqldumppara extrair as estruturas e dados

É claro que nem sempre foi tranquilo. Algumas tabelas funcionavam bem, mas outras exigiam eliminar a tabela e o banco de dados após o SHOW TABLE CREATEe usá-los para recriar a tabela antes de tentar importar os dados. Outros nem funcionaram tão longe, e eu tive que obter manualmente 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. fosse uma porcaria). atirar). Além disso, houve muitas reinicializações de daemons e clientes.

(Ainda estou procurando uma ferramenta que analise diretamente arquivos FRM/IBD (ou pelo menos exiba a estrutura da tabela de um arquivo FRM), mas parece que ninguém se preocupou em fazer “engenharia reversa” deles, mesmo que seja de código aberto e os formatos de arquivo estão disponíveis publicamente. Parece que todos são complacentes com o uso das 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, embora isso significasse que as coisas seriam simplificadas e mais fáceis de trabalhar, também significava recuperar uma mesa de cada vez – o que não era grande coisa para mim, mas para algumas pessoas poderia ser.

De qualquer forma, das muitas páginas de recuperação do MySQL na Internet que vi nos últimos dias, algumas foram bastante úteis e irei adicioná-las assim que vasculhar meu histórico para desenterrá-las.


Espero que isso possa ajudar outras pessoas em uma situação semelhante.

Answer 2

Ser capaz de listar todas as tabelas e bancos de dados geralmente significa que os arquivos *.frm estão lá. Eles não significam que haja dados para eles. Você já tentou iniciar seu processo mysqldforçando a recuperação do innodb? Se não, experimente, sim, o que diz o log do mysql ao iniciar?

Depois de fazer isso: nunca mais tente usar backups como esse novamente.