Como você identifica a corrupção da tabela InnoDB?

Morgan dá uma dica em seu comentário de que o InnoDB está constantemente verificando páginas corrompidas fazendo checksums nas páginas que lê. Se o InnoDB encontrar uma incompatibilidade de checksum, ele irá travar o servidor.

Se você quiser acelerar esse processo (em vez de esperar que o InnoDB leia a página corrompida), você pode usar innochecksum:

Como as incompatibilidades de soma de verificação farão com que o InnoDB desligue deliberadamente um servidor em execução, pode ser preferível usar essa ferramenta em vez de esperar que um servidor em uso de produção encontre as páginas danificadas.

Uma ressalva interessante:

innochecksum não pode ser usado em arquivos de tablespace que o servidor já tenha aberto. Para esses arquivos, você deve usar CHECK TABLE para verificar as tabelas dentro do tablespace.

Então sim, para uma tabela online CHECK TABLEé provavelmente a ferramenta (ou como apontado em outra resposta mysqlcheck se você quiser fazer mais de um único banco de dados por vez).

Se você pode desligar seu banco de dados, você pode forçar as somas de verificação usandoinnochecksum

Anedótico: Em um tablespace innodb de 29 GB (com innodb_file_per_table=1), esse script levou cerca de 2 minutos

#!/bin/bash
for i in $(ls /var/lib/mysql/*/*.ibd)
do
  innochecksum -v $i
done

Como um bônus, porém, como você está executando o Percona, eles implementaram um novo método para soma de verificação innodb rápida . Nunca usei, mas pode acelerar o processo.

AVISO: antes de tentar qualquer uma dessas instruções, é altamente recomendável verificar se há um backup íntegro do seu banco de dados em mãos, apenas por precaução. (obrigado @Nick pelo aviso)

Tente usar o mysqlcheckcomando. Em um terminal:

mysqlcheck -u username -p --databases database1 database2

Este comando produzirá uma lista de todas as tabelas e um status informando se houve algum tipo de corrupção:

table1  OK
table2  OK
table3  OK
tableN  OK

Com isso em mãos você já saberá quais mesas você precisa reparar. Apenas no caso de você querer reparar tudo de uma vez:

mysqlcheck -u username -p --auto-repair --databases database1 database2 

Mais sobre mysqlcheck: ​​http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html

Nota: você marcou sua pergunta com percona . Eu não tinha idéia do que era isso, então eu pesquisei. Parece ser um fork do MySQL, mas não tenho motivos para acreditar que os comandos são incompatíveis (dedos cruzados).

Alguém me indicou este guia que tem instruções mais específicas para recuperação de banco de dados InnoDB para situações mais críticas em que todo o banco de dados não inicia: http://www.softwareprojects.com/resources/programming/t-how-to-fix-mysql -database-myisam-innodb-1634.html

De acordo com o Guia de Estudo de Certificação MySQL 5.0, Página 443.444 Seção 30.4 :

Você pode verificar as tabelas do InnoDB usando o comando CHECK TABLE ou usando um programa cliente para emitir a instrução para você. No entanto, se uma tabela InnoDB tiver problemas, você não poderá corrigi-la usando REPAIR TABLE porque essa instrução se aplica apenas ao MyISAM.

Se uma verificação de tabela indicar que uma tabela do InnoDB tem problemas, você poderá restaurar a tabela para um estado consistente despejando-a com mysqldump, descartando-a e recriando-a a partir desse despejo.

No caso de um travamento de um servidor MySQL ou no host em que ele é executado, algumas tabelas InnoDB podem precisar de reparos. Normalmente, basta reiniciar o servidor porque o mecanismo de armazenamento InnoDB executa a recuperação automática como parte de sua sequência de inicialização. Em casos raros, o servidor pode não inicializar devido à falha da recuperação automática do InnoDB. Se isso acontecer, use o seguinte procedimento:

• Reinicie o servidor com a opção --innodb_force_recovery definida para um valor de 1 a 6. Esses valores indicam níveis crescentes de cautela para evitar uma falha e níveis crescentes de tolerância para possíveis inconsistências nas tabelas recuperadas. Um bom valor para começar é 4.

• Quando você inicia o servidor com --innodb_force_recovery definido como um valor diferente de zero, o InnoDB trata o tablespace como somente leitura. Consequentemente, você deve despejar as tabelas do InnoDB com mysqldump e depois eliminá-las enquanto a opção estiver em vigor. Em seguida, reinicie o servidor sem a opção --innodb_force_recovery. Quando o servidor for ativado, recupere as tabelas InnoDB dos arquivos de despejo.

• Se as etapas anteriores falharem, é necessário restaurar as tabelas do InnoDB de um backup anterior.

Por favor, leia MySQL Docs em InnoDB Forced Recovery  

Eu me pergunto o que acontece se alguém usar dados do InnoDB criados por meio do plug-in InnoDB e depois mudar para outra versão do InnoDB. Isso poderia criar uma possível corrupção de página aos olhos do mysqld.

Observe o que a documentação do MySQL no formato de arquivo InnoDB diz sobre essa possibilidade:

Em geral, uma versão mais recente do InnoDB pode criar uma tabela ou índice que não pode ser lido ou escrito com segurança com uma versão anterior do InnoDB sem risco de travamentos, travamentos, resultados errados ou corrupções. O plug-in InnoDB apresenta um novo mecanismo para proteger contra essas condições e ajudar a preservar a compatibilidade entre arquivos de banco de dados e versões do InnoDB.

Eu descartaria os dados do escravo. Na verdade, eu apenas usaria força bruta obtendo um despejo lógico (mysqldump) dos dados:

• Solte todos os bancos de dados usando o InnoDB no escravo
• Desligue o mysql no escravo
• Excluir ibdata1, ib_logfile0 e ib_logfile1 no escravo
• Inicie o mysql no escravo, permitindo que ibdata1, ib_logfile0 e ib_logfile1 sejam recriados
• mysqldump os dados do mestre no escravo

Minha resposta original postada é considerada 'old school'. No entanto, neste caso, eu definitivamente examinaria os formatos de arquivo usados ​​por .ibd e/ou ibdata1.