Dois Bancos de Dados, um Oracle e um MySQL, estavam passeando tranquilamente, quando Itaipu foi desligada. Quando a energia voltou, o Oracle pergunta ao MySQL: – Caramba MySQL, viu que susto passamos? Ainda bem que somos RDBMS, e conseguimos nos recuperar de uma falha destas. MySQL? Você tá me ouvindo?
Piada a parte, um colega de trabalho entrou em contato comigo, pois dois bancos MySQL (após o apagão de 10/11/2009 (aliás, conheço o cara que instalou o SAP de Itaipu e colocou a tal regra lá…) não subiam mais.
Essa era a mensagem que os logs (mysqld.log) apresentavam:
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: Doing recovery: scanned up to log sequence number 468 3362699776 InnoDB: Doing recovery: scanned up to log sequence number 468 3367942656 InnoDB: Doing recovery: scanned up to log sequence number 468 3373185536 InnoDB: Doing recovery: scanned up to log sequence number 468 3377730086 091111 10:25:44 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 091111 10:25:45 - mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=0 read_buffer_size=8388608 max_used_connections=0 max_connections=1000 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 16384000 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=(nil) Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... frame pointer is NULL, did you compile with -fomit-frame-pointer? Aborting backtrace! The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 091111 10:25:45 mysqld ended A solução foi executar o comando myisamchk, em todos os bancos e tabelas, e em seguida o banco subiu normalmente. [root@sgfmon01 mysql]# myisamchk --silent --force */*.MYI myisamchk: MyISAM file cacti/host.MYI myisamchk: warning: 7 clients are using or haven't closed the table properly myisamchk: MyISAM file cacti/host_snmp_cache.MYI myisamchk: warning: 2 clients are using or haven't closed the table properly myisamchk: MyISAM file cacti/poller_command.MYI myisamchk: warning: 2 clients are using or haven't closed the table properly myisamchk: MyISAM file cacti/poller_item.MYI myisamchk: warning: 7 clients are using or haven't closed the table properly myisamchk: MyISAM file cacti/poller_output.MYI myisamchk: warning: 5 clients are using or haven't closed the table properly myisamchk: MyISAM file cacti/poller_reindex.MYI myisamchk: warning: 6 clients are using or haven't closed the table properly myisamchk: MyISAM file cacti/poller_time.MYI myisamchk: warning: 1 client is using or hasn't closed the table properly myisamchk: MyISAM file cacti/settings.MYI myisamchk: warning: 8 clients are using or haven't closed the table properly myisamchk: MyISAM file cacti/user_log.MYI myisamchk: warning: 1 client is using or hasn't closed the table properly myisamchk: MyISAM file mysql/db.MYI myisamchk: warning: 1 client is using or hasn't closed the table properly myisamchk: MyISAM file mysql/user.MYI myisamchk: warning: 1 client is using or hasn't closed the table properly [root@sgfmon01 mysql]# /etc/init.d/mysqld start Starting MySQL: [ OK ]
Com 20 anos de experiência profissional, Oracle ACE Member – eleito pela Oracle Corporation um dos maiores especialistas do mundo em Oracle Database- Trabalhou em grande parte dos maiores bancos de dados Oracle do Brasil. Certificado em Oracle, SQL Server, DB2, MySQL, Sybase e Websphere.
Conselheiro do GPO e do GUOB, palestrante do ENPO, GUOB Tech Day e Oracle Open World, escritor da Revista SQL Magazine e Instrutor na Nerv.
É Mr. Portilho, nessas horas eu penso nos que apostam no MySQL como solução Free… nada contra, mas nessas horas…ai ai ai ai
A primeira vez que vi um “recover” do Oracle por problemas de energia foi em 1997 e fiquei impressionado em recuperar tudo em 3 minutos e meio…
[]s Ishii
Bom dia, Portilho.. Só não consegui entender porque myisamchk se o problema se deu na engine InnoDB. Estou extamente com o mesmo problema, mas não possuo tabelas .MYI a não ser do banco default “mysql”.
Att,
Oi Leonardo.
Embora tenha ocorrido um RECOVER do InnoDB devido à queda, não ficou claro se o erro final após o RECOVER é devido a uma tabela do InnoDB ou do MyISAM, pois neste banco eu utilizada os dois, por isso tinha arquivos MYI.
Abraço !
Alguém pode me ajudar?
Entrei no error.log do mysql e esta apresentando a mensagem
Starting crash recovery
e lista varias tabelas com a msg ( is marked as crashed and should be repaired )
e Apos reinicia o mysql.
Como resolver isso /?? se o mysql reinicia da pau no sistema, pois tenhos arquivos que ficam rodando fazendo consultas no banco.
Uso o ubuntu 11.10
Oi.
Tente isto: http://nervinformatica.com.br/blog/2012/01/05/mysql-innodb-corrompido/
Tem backup?
Acho q isso não ajuda, pois o proprio mysql checa as tabelas e repara, o problema é ele reinciar apos essa reparação.
Se eu criar uma função no mysql para fazer essa verificação de hora em hora evita essa crash recovery
Cara, seu banco está corrompido.
O MySQL diz que consegue reparar, mas não consegue e cai.
Tente subir com as opções de recovery, para conseguir exportar os dados e recriar o banco.
Certo, outra dúvida, quando o mysql dispara esse evento para reparar e onde esta configurado isso?
O MySQL tentou acessar os dados corrompidos e aí dispara este Alarme. Esta verificação não é opcional.