Eu derrubei acidentalmente todas as tabelas. Posso restaurar de volta? Eu não tenho a cópia de backup.
Se você não tem, literalmente, nenhum backup, então tenho 99% de certeza de que você está sem sorte.
Se você tem alguma forma de backup, por mais antigo que seja, você tem o log binário ligado via a opção log-bin no arquivo de configuração do MySQL (my.ini)? Se assim for, você poderá recuperar desde o último backup.
Mau jeito de começar uma semana, desculpe.
A pergunta é bem antiga, mas não há uma única resposta positiva, então adicionarei uma.
Depois que o MySQL descarta uma tabela, os dados ainda estão na mídia por um tempo. Então você pode buscar registros e reconstruir uma tabela. Mais tarde, vou blogar sobre isso, mas por enquanto rápido esboço.
Você precisaria ter a estrutura da sua tabela (instrução CREATE TABLE).
Se innodb_file_per_table estiver ON, a tabela eliminada estará na partição do disco. Pare o MySQL e monte-o novamente como somente leitura o mais rápido possível. Se o MySQL estava em uma partição raiz (o que não é uma boa idéia), então pegue uma imagem ou retire o disco e conecte em outro servidor. Pare todas as gravações em outras palavras.
Se innodb_file_per_table OFF, simplesmente pare o MySQL.
Em seguida, baixe e compile a ferramenta un-drop para o InnoDB do link . Marque a seção " Compilando o kit de ferramentas de recuperação do TwinDB " para obter detalhes.
Em seguida, analise a partição de disco ou ibdata1 (dependendo da configuração innodb_file_per_table) com stream_parser:
./stream_parser -f /path/to/diskimage_or_ibdata1
Em seguida, recupere o dicionário InnoDB para saber em qual index_id a tabela descartada estava.
Em seguida, pegue a estrutura da tabela e busque os registros
./c_parser -f pages-diskimage_or_ibdata1/FIL_PAGE_INDEX/00000<index_id>.page
Ele irá gerar registros para stdout e o comando LOAD DATA para stderr.
Há muito pouco que você pode fazer, infelizmente, além de tirar muito menos da necessidade de um bom plano de backup.
Dependendo do tipo de tabela, você pode encontrar um especialista que possa reunir os dados do que foi deixado no disco, mas essa análise forense seria muito, muito cara (já que requereria habilidades relativamente incomuns) e não a todos garantido para ser verdadeiramente útil.
Aqui está o que eu fiz. No diretório mysql (para o Ubuntu isso é / var / lib / mysql, para Mac usando o Homebrew isso é / usr / local / var / mysql), eu encontrei alguns arquivos. Primeiro eu copiei o diretório myapp_development / contendo o esquema em particular para o meu diretório mysql local. Então eu fiz o backup do meu ibdata1 local e copiei o ibdata1 do servidor para o diretório mysql. Matou o mysqld. ( ps aux para encontrar o PID e, em seguida, kill PID ). Reiniciado mysql, ele começou no modo de recuperação de falhas. Em seguida, liguei o meu cliente mysql local e gerou um despejo completo das tabelas que eu precisava.
E, 15.000 linhas representando semanas de trabalho inserindo metadados que pensamos que foram perdidas para sempre, são salvas !!
Espero que isso ajude alguém.
Se esta foi a tabela MyISAM, você precisa apenas recuperar arquivos da tabela em / var / log / mysql ou qualquer que seja seu diretório de dados. Você pode usar o utilitário ext3grep para isso, por exemplo.
Você não pode "desfazer" um DROP TABLE .
Você pode ver se o MySQL tinha registro binário ativado, talvez você possa extrair alguns dados de lá.
Além disso, você pode esquecer o MySQL e está na mesma classe de problemas de "eu acidentalmente apaguei alguns arquivos do meu sistema de arquivos". Existem algumas ferramentas que tentam recuperar arquivos, e também há empresas que fazem isso de forma profissional.
Se você tiver o log binário ativado, poderá recriar uma tabela primeiro se tiver um esquema. Certifique-se de criar um esquema enquanto estiver com binlogs desativados. Ou você pode simplesmente pular para a sessão. Então você pode reproduzir os binlogs até a última declaração que foi drop table em si.
Se não, você pode restaurar usando um dump de backup se tiver algum. Se você tiver arquivos csv, poderá carregar o método infile de dados para recuperar os dados. Se você está se recuperando do mysqldump, então você pode considerar restaurar uma única tabela do arquivo de despejo em vez de restaurar o banco de dados completo. Se o tamanho dos dados for muito grande, você pode considerar a possibilidade de desabilitar as chaves antes de carregá-las, o que aumentará significativamente o processo de restauração.
Para o futuro, você pode gostar de ter um escravo com atraso de 10 a 24 horas. Você pode criar escravos atrasados usando o toolkit percona (pt-slave-delay)