Blog Intermol

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.