Recuperação de emergência do InnoDB

Quando o MySQL não inicia depois de uma queda de energia ou de um problema no disco, o primeiro objetivo é descobrir a causa e preservar os arquivos existentes. A queda, sozinha, não prova um dano. O InnoDB tem uma recuperação automática depois de falhas, e o serviço também pode deixar de iniciar por falta de espaço, por permissões ou por um erro na configuração.

O log de erros primeiro

O log de erros do MySQL registra o motivo de uma falha na inicialização. No Windows, ele costuma ficar na pasta de dados, com o nome do computador e a extensão err. As mensagens desse arquivo separam os casos mais comuns:

• a falta de espaço no disco;
• a falta de permissão na pasta de dados;
• uma opção inválida no arquivo de configuração;
• a porta 3306 ocupada por outro programa;
• páginas danificadas ou falhas repetidas durante a recuperação do InnoDB.

Nas versões anteriores ao MySQL 5.6, uma mudança no tamanho dos arquivos de registro do InnoDB, feita só no arquivo de configuração, também impede a inicialização, e o log mostra a diferença de tamanho entre a configuração e os arquivos existentes.

O modo de recuperação forçada

A opção innodb_force_recovery faz o InnoDB ignorar partes da recuperação normal. Com ela, dados ilegíveis podem ficar legíveis o bastante para uma exportação, mas os arquivos continuam danificados, e as linhas extraídas podem não estar consistentes. A opção fica na seção do servidor, no arquivo de configuração:

• [mysqld]
• innodb_force_recovery = 1

Os valores vão de 1 a 6, e cada valor inclui os efeitos dos anteriores:

• 1: mantém o servidor funcionando mesmo com páginas danificadas e pula os registros danificados na leitura.
• 2: impede as tarefas de limpeza que rodam em segundo plano.
• 3: não desfaz as transações incompletas depois da recuperação.
• 4: impede a aplicação das alterações acumuladas para os índices secundários e o cálculo das estatísticas.
• 5: ignora os registros de desfazer e trata as transações incompletas como confirmadas.
• 6: ignora os registros de alterações usados na recuperação normal.

Com qualquer valor acima de zero, o InnoDB recusa INSERT, UPDATE e DELETE, e, nas versões atuais, os valores a partir de 4 deixam o InnoDB somente leitura. Os valores a partir de 4 podem causar um dano permanente aos arquivos, e a documentação do MySQL orienta testar esses valores antes em uma cópia física separada. O uso começa pelo valor 1 e só sobe um valor por vez, quando o valor anterior não permite a exportação.

Preservar, extrair e reconstruir

A recuperação segue uma sequência:

1. a parada do serviço e uma cópia completa da pasta de dados, guardada em outro lugar;
2. a inicialização com o menor valor que permita ler os dados;
3. a exportação com o mysqldump, tabela por tabela quando uma tabela danificada interrompe a exportação do banco inteiro;
4. a criação de uma instalação nova, sem a opção, e a importação dos dados exportados;
5. a conferência das contagens, dos identificadores, das definições e dos dados importantes antes da volta da operação.

Nas instalações com o arquivo compartilhado ibdata1, todas as tabelas InnoDB ficam no mesmo arquivo, e a cópia da pasta de dados inteira é a única forma de preservar o estado. Uma exportação que parou em uma página danificada não recuperou a tabela inteira, e os trechos que faltaram ficam registrados. A ferramenta innochecksum, executada com o serviço parado, confere as somas de verificação das páginas de um arquivo do InnoDB e ajuda a localizar o dano.

Ao final, a opção sai da configuração. Um servidor que continua funcionando com a recuperação forçada não aceita alterações de dados e não tem as proteções normais do InnoDB.