Recuperação de desastres do Mysql

Question

Acabamos de receber um grande desastre: alguém fez uma atualização descontrolada no banco de dados de produção e, obviamente, o processo de backup não está funcionando há muito tempo, então tivemos uma grande perda de dados. Uma tabela de 40 milhões de linhas agora está cheia de lixo.

Alguém tem uma ideia para restaurar os dados? Por exemplo, uma ferramenta usando a recuperação do sistema de arquivos?

Fatos:

• ext3 fs (no Debian)
• Mecanismo InnoDB (no Mysql 5.0)

Honestamente, não é o primeiro grande desastre em nossa empresa, mas este pode ser facilmente o último. Costumamos ter uma ideia para salvar o dia, mas desta vez estou realmente sem ideias. Clusterf * ck ...

Editar: o problema ocorreu após uma instrução de atualização sem o local. O problema é que o problema ocorreu entre a tarde de segunda-feira e a manhã de terça-feira (horário da França) e só foi descoberto hoje por vários motivos (o aplicativo oferece uma ferramenta de sincronização, portanto novos dados são inseridos com os dados ausentes), outra tabela está agora completamente quebrada). Então, na verdade, quase todas as linhas na tabela (exceto a recém inserida) contém os mesmos dados (exceto a coluna id).

Sobre ibdata * e ib_logfile *, parei o servidor replicado, assim eles permanecem como estão agora. Não consigo parar o banco de dados no servidor principal para copiar os arquivos.

    

Answer 1

2 horas e sem respostas? Eu acho que isso pode ser porque ninguém está disposto a dar a notícia para você.

Você tem uma boa cópia dos dados em qualquer lugar (mesmo um com um ou dois meses de idade)? Se não, então você está SOL eu estou com medo. Você fez algumas alusões a uma cópia sincronizada do banco de dados, portanto, se a sincronização foi cancelada antes da execução incorreta da instrução UPDATE, será necessário criar uma instrução para atualizar a Origem A com os dados da Origem B para essa tabela. p>

(Eu tive isso uma vez, com MSSQL e log shipping, e felizmente consegui parar o envio de log antes que os dados ruins fossem restaurados no Site B, e apenas fiz uma instrução UPDATE entre os servidores para desfazer meu erro).

Como Marc B mencionou, se você tiver o log binário ativado (e o log não foi truncado), poderá recuperar alguns dos dados fazendo com que esse log seja repetido (mesmo se você tiver uma cópia antiga real) do banco de dados, se seu log estiver intacto, você estará OK), mas isso pode ser um pouco problemático.