A cópia dos arquivos / var / lib / mysql resultou em corrupção do InnoDB

Question

Meu servidor teve que ser reinstalado ontem, então eles substituíram o disco rígido e conectaram o antigo via USB. Eu peguei os arquivos de banco de dados (/ var / lib / mysql) e os baixei e então eu apaguei todos os arquivos db do meu servidor de teste local e os substituímos pelo meu servidor ao vivo.

Tudo funcionou bem no início e depois notei que algumas tabelas estavam aparecendo como "em uso". Descobri que o InnoDB não estava funcionando corretamente e acabei descobrindo que uma correção era remover os arquivos ib_logfile0 e ib_logfile2. Agora meu servidor MySQL não inicia e recebo estes erros:

110716 10:19:04  mysqld started
110716 10:19:04 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
110716 10:19:04 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110716 10:19:04  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
110716 10:19:04  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000000cd12deee693d9fd84ee8bdf2000000070000000000000000000000006935b4760000000000000000000000000000000000000000180000000000000013ee000000000000034f000000000000000d0a00000008000000090000000d0a0000000b0000000c0000$
110716 10:19:05  InnoDB: Page checksum 3392292161, prior-to-4.0.14-form checksum 3716350408
InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
InnoDB: Page lsn 1323875826 7, low 4 bytes of lsn at page end 0
InnoDB: Page number (if stored to page already) 0,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26933
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
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 InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
110716 10:19:05  mysqld ended

Eu realmente preciso desses arquivos para trabalhar, então qualquer conselho é muito apreciado.

    

Answer 1

Uau, você realmente fez um número no seu banco de dados. Você pode restaurar copiando arquivos de dados do MySQL, mas parece que você usou um pouco de mallet demais. A maneira correta de fazer isso:

• Verifique se o MySQL NÃO ESTÁ FUNCIONANDO na máquina na qual você está tentando restaurar. Verifique quádruplo com ps para garantir que nada de natureza semelhante ao MySQL esteja à espreita. Inicialize no modo de usuário único se for necessário. Se o MySQL estiver rodando, você irá manipular todo tipo de coisas.
• Copie o conteúdo de /var/lib/mysql (ou onde quer que seus dados do MySQL estejam), bem como o my.cnf que seu servidor estava usando. É importante garantir que a configuração seja a mesma quando executando o InnoDB, porque (como você observou), caso contrário o InnoDB não funciona. (Os parâmetros cruciais são o tamanho do seu log do InnoDB / count / etc, e o arquivo por tabela - se eles forem diferentes, você realmente não vai a lugar nenhum).

Quando você inicia as coisas, especialmente se estiver restaurando uma máquina que morreu de forma violenta e prematura, espere que o servidor demore um pouco para se colocar em funcionamento, já que ele precisa fazer todos os tipos de verificação de consistência interna. (o equivalente a um fsck ) antes de estar pronto para o serviço.

    

Answer 2

Como disse @womble, mas com um pequeno adendo:

É realmente útil criar o backup com innobackupex e movê-lo para o novo servidor:

primeira execução:

innobackupex /path/to/backupfiles

e depois disso ser bem-sucedido:

innobackupex --apply-log /path/to/backupfiles

Isso criaria um backup utilizável baseado em arquivo (o que só precisava ser copiado) mesmo de um servidor em execução.