Saber isso é útil para podermos testar nossos aplicativos em situações de risco.
Em um típico servidor Debian, você encontrará os bancos de dados em /var/lib/mysql. Cada banco tem seu próprio diretório, composto de 3 arquivos por tabela. Uma tabela MyISAM vai estar então armazenada em:
– [tabela].frm – dados de criação da tabela (campos, etc);
– [tabela].MYI – índice (um ‘cache’ onde parte dos dados é duplicada pra que o acesso seja mais rápido);
– [tabela].MYD – onde os dados são efetivamente guardados.
Não parece ser muito comum arquivos .frm ou MYI serem corrompidos. Pelo menos até o momento não tive a felicidade de encontrar problemas com eles. O que acontece com freqüência em alguns servidores mais populares é corromper o MYD.
O arquivo MYD é um bando de dados. Como googlar pela estrutura do MYD não retornou nada de cara, vamos apelar pra engenharia reversa. Os dados parecem estar gravados da seguinte maneira:
– 6 bytes pra demarcar o começo de uma linha;
– 0-2 bytes pra demarcar o campo (depende do tipo de campo);
– Dados (o que estamos efetivamente guardando).
Ficamos com um arquivo assim:
Começo de linha – Campo – Dados – Campo – Dados – Começo de Linha – Campo – Dados ….
Inserir um dado com os mesmos bytes dos marcadores não vai corromper a tabela. MySQL não é tão burro assim. Corromper o dado em si, mesmo que seja feito diretamente no arquivo, também não vai corromper a tabela – só vai prejudicar o dado.
Para matar a tabela, mate os marcadores. Substitua-os por qualquer outra coisa usando um editor hexa como beav (apt-get install beav). Quanto mais marcadores você matar, mais problemas vai dar para o REPAIR TABLE.
O REPAIR TABLE parece usar o arquivo de índice para ajudar a recuperar dados. Se a sua estrutura usa indexação, em geral menos dados são perdidos.