Recuperação do InnoDB

Question

Meu servidor MySQL é executado para travar devido a (erro de gravação do arquivo de paginação). Eu fiz um diagnóstico de disco, mas nenhum erro foi encontrado. Eu reiniciei o servidor MySQL. Ele digitalizou o log do compartimento como por 1-2 horas e gravou o log como abaixo:

InnoDB: Doing recovery: scanned up to log sequence number 51 2341175808
InnoDB: Doing recovery: scanned up to log sequence number 51 2346418688
InnoDB: Doing recovery: scanned up to log sequence number 51 2351661568
InnoDB: Doing recovery: scanned up to log sequence number 51 2356904448
InnoDB: Doing recovery: scanned up to log sequence number 51 2362147328

Depois disso, vejo muitos erros, conforme abaixo:

InnoDB: Number of pending reads 128, pending pread calls 0
InnoDB: Error: InnoDB has waited for 50 seconds for pending
InnoDB: reads to the buffer pool to be finished.
InnoDB: Number of pending reads 128, pending pread calls 0
InnoDB: Error: InnoDB has waited for 50 seconds for pending
InnoDB: reads to the buffer pool to be finished.
InnoDB: Number of pending reads 128, pending pread calls 0
InnoDB: Error: InnoDB has waited for 50 seconds for pending
InnoDB: reads to the buffer pool to be finished.

Espero algumas horas, mas ele adiciona essas linhas ao log de erros repetidamente sem sinal para parar.

O que significa mensagens de log acima? Como posso fazer meu servidor MySQL rodar novamente? Eu tenho um banco de dados de 80GB InnoDB em execução neste servidor. Existe uma maneira de forçar a recuperá-lo sem desfazer quaisquer transações não confirmadas ou tentar recuperar os dados do arquivo de paginação que causou a falha? Não tenho nenhum problema em largar esses dados.

Eu tentei "sudo -u mysql / usr / sbin / mysqld -innodb_force_recovery = 6" para reiniciar o servidor MySQL, mas recebi novos erros repetidos conforme abaixo:

InnoDB: stored checksum 2440779633, prior-to-4.0.14-form stored checksum 3425185587
InnoDB: Page lsn 51 2450779673, low 4 bytes of lsn at page end 2450779673
InnoDB: Page number (if stored to page already) 10824,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 4294967295 0
InnoDB: (index "CLUST_IND" of table "SYS_IBUF_TABLE_0")
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 10824.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.

O que devo fazer agora?

    

Answer 1

Sem o erro que causou o travamento, a versão do MySQL e seu my.cnf, é difícil determinar qual é exatamente o problema ... Dito isto, aqui estão alguns conselhos genéricos ....

Você pode encontrar a tabela que possui a página corrompida de várias maneiras. A maneira mais fácil de desligar o servidor e executar innochecksum em todas as tabelas seu banco de dados. Se encontrar algum problema, você pode iniciar o banco de dados no modo de recuperação definindo innodb_force_recovery e tentar executar um SELECT INTO OUTFILE da tabela para descarregar o conteúdo, então LOAD DATA FROM INFILE para carregá-lo em uma nova tabela. Inicie innodb_force_recovery em 1 e, se ocorrer uma falha ao despejar a (s) tabela (s), continue a incrementar o valor innodb_force_recovery até que você possa despejar os dados sem que ele falhe. Certifique-se de que nenhum cliente esteja se conectando enquanto você faz isso.

Percona também tem o Percona Data Recovery Tool para InnoDB que podem minimizar o tempo de inatividade, mas eles exigem algum conhecimento para usar e tem potencial para atrapalhar as coisas ainda mais. Além disso, na realidade, você pode executar o innochecksum em um banco de dados ativo, mas é provável que você obtenha falsos positivos para páginas corrompidas. Nesse caso, você pode, em seguida, desligar o servidor e apenas incluir as tabelas que retornaram erros de página enquanto estava ativo. Em um servidor ativo, um innochecksum bem-sucedido significará que a tabela está bem, enquanto um innochecksum falho pode não ser preciso.

Quando você se posicionar, recomendo criar um escravo deste banco de dados para que, se isso acontecer novamente, você possa facilmente começar a usar o escravo e não se preocupar com procedimentos complexos de recuperação.

    

Answer 2

Eu estava recebendo um erro semelhante e, depois de ler o link , decidi testar minha RAM. E estava com defeito ...

Eu descobri que rodar o memtester, sem precisar reiniciar a máquina, e tenho muito:

FAILURE: 0x657423ee6593084d != 0x84e423ee6593084d at offset 0x16f17b1a0.
FAILURE: 0x58c620a5a8e4984f != 0x783620a5a8e4984f at offset 0x16f3571a0.
FAILURE: 0x73eba2598aaaa228 != 0x935ba2598aaaa228 at offset 0x16f3db1a0.

Portanto, se você tiver este erro em uma versão estável do mysql e a reinicialização resolver seu problema, é muito provável que seja um problema de RAM. Se você prestar atenção na mensagem de erro, ela diz que:

InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.

Mas talvez você, como eu, se recuse a acreditar que possa ser um problema de hardware.