MySQL não inicia!

lucas-appr2
(usa Ubuntu)

Enviado em 24/05/2016 - 10:39h

Bom dia!!

Hoje cheguei aqui no meu trabalho, e o mysql não iniciava de jeito nenhum pós queda de energia.
Quando rodo
service mysql start

[FAIL] Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed! 

Então deixei um tail -f /var/log/syslog e obtive o resultado seguinte:

May 24 10:36:27 cdede /etc/init.d/mysql[6290]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in

May 24 10:36:27 cdede /etc/init.d/mysql[6290]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed

May 24 10:36:27 cdede /etc/init.d/mysql[6290]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'

May 24 10:36:27 cdede /etc/init.d/mysql[6290]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

May 24 10:36:27 cdede /etc/init.d/mysql[6290]:

May 24 10:36:45 cdede mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql

May 24 10:36:45 cdede mysqld: 160524 10:36:45 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.

May 24 10:36:45 cdede mysqld: 160524 10:36:45 [Note] /usr/sbin/mysqld (mysqld 5.5.46-0+deb7u1) starting as process 6711 ...

May 24 10:36:45 cdede mysqld: 160524 10:36:45 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.

May 24 10:36:45 cdede mysqld: 160524 10:36:45 [Note] Plugin 'FEDERATED' is disabled.

May 24 10:36:45 cdede mysqld: 160524 10:36:45 InnoDB: The InnoDB memory heap is disabled

May 24 10:36:45 cdede mysqld: 160524 10:36:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins

May 24 10:36:45 cdede mysqld: 160524 10:36:45 InnoDB: Compressed tables use zlib 1.2.7

May 24 10:36:45 cdede mysqld: 160524 10:36:45 InnoDB: Using Linux native AIO

May 24 10:36:45 cdede mysqld: 160524 10:36:45 InnoDB: Initializing buffer pool, size = 128.0M

May 24 10:36:45 cdede mysqld: 160524 10:36:45 InnoDB: Completed initialization of buffer pool

May 24 10:36:46 cdede mysqld: 160524 10:36:46 InnoDB: highest supported file format is Barracuda.

May 24 10:36:46 cdede mysqld: InnoDB: The log sequence number in ibdata files does not match

May 24 10:36:46 cdede mysqld: InnoDB: the log sequence number in the ib_logfiles!

May 24 10:36:46 cdede mysqld: 160524 10:36:46  InnoDB: Database was not shut down normally!

May 24 10:36:46 cdede mysqld: InnoDB: Starting crash recovery.

May 24 10:36:46 cdede mysqld: InnoDB: Reading tablespace information from the .ibd files...

May 24 10:36:46 cdede mysqld: InnoDB: Restoring possible half-written data pages from the doublewrite

May 24 10:36:46 cdede mysqld: InnoDB: buffer...

May 24 10:36:46 cdede mysqld: 160524 10:36:46  InnoDB: ERROR: We were only able to scan the log up to

May 24 10:36:46 cdede mysqld: InnoDB: 209718784, but a checkpoint was at 209719066.

May 24 10:36:46 cdede mysqld: InnoDB: It is possible that the database is now corrupt!

May 24 10:36:46 cdede mysqld: 160524 10:36:46  InnoDB: Assertion failure in thread 3064367328 in file fut0lst.ic line 83

May 24 10:36:46 cdede mysqld: InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA

May 24 10:36:46 cdede mysqld: InnoDB: We intentionally generate a memory trap.

May 24 10:36:46 cdede mysqld: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.

May 24 10:36:46 cdede mysqld: InnoDB: If you get repeated assertion failures or crashes, even

May 24 10:36:46 cdede mysqld: InnoDB: immediately after the mysqld startup, there may be

May 24 10:36:46 cdede mysqld: InnoDB: corruption in the InnoDB tablespace. Please refer to

May 24 10:36:46 cdede mysqld: InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

May 24 10:36:46 cdede mysqld: InnoDB: about forcing recovery.

May 24 10:36:46 cdede mysqld: 13:36:46 UTC - mysqld got signal 6 ;

May 24 10:36:46 cdede mysqld: This could be because you hit a bug. It is also possible that this binary

May 24 10:36:46 cdede mysqld: or one of the libraries it was linked against is corrupt, improperly built,

May 24 10:36:46 cdede mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.

May 24 10:36:46 cdede mysqld: We will try our best to scrape up some info that will hopefully help

May 24 10:36:46 cdede mysqld: diagnose the problem, but since we have already crashed,

May 24 10:36:46 cdede mysqld: something is definitely wrong and this may fail.

May 24 10:36:46 cdede mysqld:

May 24 10:36:46 cdede mysqld: key_buffer_size=16777216

May 24 10:36:46 cdede mysqld: read_buffer_size=131072

May 24 10:36:46 cdede mysqld: max_used_connections=0

May 24 10:36:46 cdede mysqld: max_threads=151

May 24 10:36:46 cdede mysqld: thread_count=0

May 24 10:36:46 cdede mysqld: connection_count=0

May 24 10:36:46 cdede mysqld: It is possible that mysqld could use up to

May 24 10:36:46 cdede mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346076 K  bytes of memory

May 24 10:36:46 cdede mysqld: Hope that's ok; if not, decrease some variables in the equation.

May 24 10:36:46 cdede mysqld:

May 24 10:36:46 cdede mysqld: Thread pointer: 0x0

May 24 10:36:46 cdede mysqld: Attempting backtrace. You can use the following information to find out

May 24 10:36:46 cdede mysqld: where mysqld died. If you see no messages after this, something went

May 24 10:36:46 cdede mysqld: terribly wrong...

May 24 10:36:46 cdede mysqld: stack_bottom = 0 thread_stack 0x30000

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb724ac23]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0xb70eb2d4]

May 24 10:36:46 cdede mysqld: [0xb6d9d400]

May 24 10:36:46 cdede mysqld: /lib/i386-linux-gnu/i686/cmov/libc.so.6(abort+0x182)[0xb6aaea92]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x4f5f89)[0xb72b1f89]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x4e98da)[0xb72a58da]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x4e9cd2)[0xb72a5cd2]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x4ecf5b)[0xb72a8f5b]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x4d8625)[0xb7294625]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x49c4cc)[0xb72584cc]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4e)[0xb70eddee]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x20e3e2)[0xb6fca3e2]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(_Z11plugin_initPiPPci+0xbc3)[0xb6fcedb3]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x174aa4)[0xb6f30aa4]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x6b1)[0xb6f34841]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(main+0x27)[0xb6f28967]

May 24 10:36:46 cdede mysqld: /lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb6a97e46]

May 24 10:36:46 cdede mysqld: /usr/sbin/mysqld(+0x16c871)[0xb6f28871]

May 24 10:36:46 cdede mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains

May 24 10:36:46 cdede mysqld: information that should help you find out what is causing the crash.

May 24 10:36:46 cdede mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended

May 24 10:36:59 cdede /etc/init.d/mysql[6881]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in

May 24 10:36:59 cdede /etc/init.d/mysql[6881]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed

May 24 10:36:59 cdede /etc/init.d/mysql[6881]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'

May 24 10:36:59 cdede /etc/init.d/mysql[6881]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!

May 24 10:36:59 cdede /etc/init.d/mysql[6881]:

 

Alguém pode me ajudar???
Obrigado!

textmode
(usa Slackware)

Enviado em 24/05/2016 - 11:08h

Banco corrompido. Volte o backup mais recente.

[]'s
--
"Não manejo bem as palavras
Mas manipulo bem as strings."
------------------------------
https://perspicazsite.wordpress.com

lucas-appr2
(usa Ubuntu)

Enviado em 24/05/2016 - 11:40h

Não consigo fazer algum repair? Meu servidor de backup não efetuou o backup desde o mês 2, e só percebemos agora que precisei disso.

lucas-appr2
(usa Ubuntu)

Enviado em 24/05/2016 - 12:05h

Resolvido:
http://www.itexto.net/devkico/?p=380

Copiando caso o site acima saida do ar:
Pois bem: vejam o que aconteceu comigo na semana passada. Esperando o final do dia, no qual o número de conexões ao MySQL é normalmente quase zero, resolvi criar um índice para uma tabela gigantesca de logs (14 Gb). Enquanto o índice era criado, alguns usuários reclamaram ao administrador de rede que o acesso às aplicações estava lento. Solução encontrada pelo administrador? Desligar o servidor do MySQL físicamente! (detalhe: quando ele desligou o servidor, a criação do índice ainda estava em execução!)

Obviamente, a tabela em questão foi perdida e, pior ainda: o servidor do MySQL simplesmente não pode mais ser iniciado. Por que? Por que as tabelas presentes no banco de dados, assim como os logs de transação e diversas outras informações fundamentais para a execução do banco de dados foram corrompidos. Acabei adotando o problema (sei que é loucura, mas era a solução) e, após algumas horas de pesquisa (e a empresa de 600 funcionários parada), encontrei uma solução tosca, mas que pode salvar uma base de dados MySQL corrompida.

No caso, a tabela na qual eu estava criando o índice era do tipo MyISAM, porém, como houve um desligamento incorreto do servidor, diversos outros arquivos foram corrompidos para o processo, incluindo as tabelas no formato InnoDB.

A solução adotada neste procedimento resolve o problema para arquivos no formato MyISAM e InnoDB apenas. Convém mencionar também que a versão usada do MySQL foi a 5.0. O procedimento de recuperação é composto por três passos:

1. Execute o programa myisamchk dentro do diretório que contém a estrutura de bancos de dados do MySQL. Se não souber aonde este diretório se encontra, abra o seu arquivo my.ini (Windows) oy my.cnf (Linux e Unix em geral) e localize a instrução datadir.

Dentro deste diretório, execute o comando

1
myisamchk --force --verbose */*.MYI
O atributo –force obriga o aplicativo a reparar qualquer tipo de erros encontrados na estrutura da tabela, enquanto o –verbose simplesmente irá expor na tela o status da execução do aplicativo.

Só para lembrar, este aplicativo serve para reparar as suas tabelas do tipo MyISAM.

2. Inicie o servidor do mysql com o atributo –innodb_force_recovery=[algum valor]

Você deverá iniciar o seu servidor MySQL com o atributo –innodb_force_recovery com um valor de 1 a 6, sendo que quanto maior o valor, maior o nível de corrupção da sua base de dados. Se o valor estiver entre 1 e 4, o MySQL irá reparar todos os erros das suas tabelas e em seguida você poderá trabalhar na base de dados normalmente. Caso contrário, todas as bases de dados estarão disponíveis apenas para leitura. Execute o servidor passando este parâmetro até que este volte a ser inicializado.

(aviso aos orelhas: se o seu servidor voltou a executar com o valor 2 ou 3, não é preciso executar o servidor com valores maiores)

Exemplo de execução:

1
mysqld --innodb_force_recovery=4
Se quiser, pode também incluir este atributo no arquivo de configuração do MySQL (my.ini no Windows, my.cnf no Linux/Unix/etc). Para tal, basta incluir a instrução innodb_force_recovery=valor logo após a seção mysqld deste arquivo, tal como no exemplo abaixo:

1
2
[mysqld]
innodb_force_recovery=4
3. Faça backup da sua base de dados e, em seguida, faça o restore da mesma em uma nova instalação do MySQL.

Este terceiro passo pode parecer exagerado se você executou o comando innodb_force_recovery com valores menores ou iguais a 4, porém, como seguro morreu de velho, esta alternativa garante que na nova base de dados não haja informações corrompidas.

alastori
(usa Outra)

Enviado em 24/05/2016 - 14:01h

Parece que seu banco de dados foi corrompido.

Se você não tiver backups recentes, pode tentar recuperar...

1. Faça uma cópia do seu datadir (por padrão /var/lib/mysql)
2. Tente subir o banco alterando o valor de innodb_force_recovery. Comece com valores mais baixos e vá aumentando. http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
3. Se não der certo, pode tentar alguma ferramenta de recuperação como, por exemplo, https://launchpad.net/percona-data-recovery-tool-for-innodb