MySQL continua travando: InnoDB: Não é possível travar ./ibdata1, erro: 11

Question

Eu tenho um servidor web simples (Debian 6.0 x86, DirectAdmin com 1 GB de memória e ainda 10 GB de espaço livre, mySQl versão 5.5.9), mas o servidor mySQL continua travando e eu preciso matar todos os processos mySQL para poder para reiniciá-lo novamente.

/var/log/mysql-error.log output:

130210 21:04:26 InnoDB: Using Linux native AIO
130210 21:04:34 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:05:42 InnoDB: Completed initialization of buffer pool
130210 21:05:48 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:22 InnoDB: Initializing buffer pool, size = 128.0M
130210 21:06:27 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:06:29 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:07:22 InnoDB: Completed initialization of buffer pool
130210 21:07:51 mysqld_safe mysqld from pid file /usr/local/mysql/data/website.pid ended
130210 21:08:33 InnoDB: Completed initialization of buffer pool
130210 21:12:03 [Note] Plugin 'FEDERATED' is disabled.
130210 21:12:47 InnoDB: The InnoDB memory heap is disabled
130210 21:12:47 InnoDB: Mutexes and rw_locks use InnoDB's own implementation
130210 21:12:47 InnoDB: Compressed tables use zlib 1.2.3
130210 21:12:47 InnoDB: Using Linux native AIO
130210 21:13:11 InnoDB: highest supported file format is Barracuda.
130210 21:13:23 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
130210 21:14:05  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
130210 21:17:53  InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
130210 21:17:53  InnoDB: Operating system error number 11 in a file operation.

Encontrei um tópico no site do mySQL aqui , mas não há solução para isso.

Alguma ideia é de alguém?

    

Answer 1

outra abordagem de um comentário no mesmo blog:

this helped me:

lsof -i:3306

Then kill it (the process number)

kill -9 PROCESS

e.g. kill -9 13498

Then try to restart MySQL again.

via link

    

Answer 2

com o Ubuntu 14.04. Estou com esse problema quando tento reiniciar via

/etc/init.d/mysql restart

Em vez disso, tente

service mysql restart 

    

Answer 3

A causa mais comum desse problema é tentar iniciar o MySQL quando ele já está em execução.

Para resolvê-lo, elimine todas as instâncias em execução do MySQL e reinicie-o usando seus scripts de inicialização normais, por exemplo, service mysql start .

Não tente iniciar o MySQL manualmente ao usar versões de pacote de distribuição, a menos que esteja preparado para um mundo de problemas.

    

Answer 4

Solução

faça uma cópia dos arquivos originais (ibdata1, ib_logfile0, ib_logfile1 ...).

mv ibdata1 ibdata1.bak 
cp -a ibdata1.bak ibdata1

link

    

Answer 5

Isso me ajudou a resolvê-lo:

Exclua todos os arquivos ibdata e deixe o mysql criá-los.

pare o mysql:

service mysql stop

vá para a biblioteca do mysql:

cd /var/lib/mysql/

mova arquivos innodb em algum lugar, caso precise:

mv ib* /root/

iniciar o mysql:

service mysql start

    

Answer 6

Veio do googling do mesmo erro repetitivo, mas com o código de erro 13 ( InnoDB: Unable to lock ./ibdata1, error: 13 ). Depois de tentar muitas soluções pela internet, inventei uma que me ajudou (apparmor!)

Adicione estas linhas à configuração /etc/apparmor.d/usr.sbin.mysqld (e recarregue o apparmor e o mysql, é claro):

/path/to/mysql/data/ r,
/path/to/mysql/data/** rwk,

As principais diferenças entre soluções frequentes: duas regras (para dir propriamente dito e para todos os arquivos dentro, anote as opções double ** ) e k para permitir que o mysql bloqueie arquivos.

Espero que isso ajude alguém.

    

Answer 7

Verifique o espaço para se certificar de que é 100%

df -h

Como se estivesse cheio, não criaria arquivo .sock.

    

Answer 8

Verifique se você tem o parâmetro pid-file na seção [mysql] do arquivo my.cnf . Se não estiver presente, o unable to lock ...ibdata1.. error:1 ocorrerá.

    

Answer 9

Simples, mas mais rápido que o modo com "cp -a". E ajudou quando "cp -a" e tudo o mais não podia.

1. service mysql stop && pkill -f mysql

Livre-se de todos os processos do mysql

2. vi /etc/mysql/my.cnf

Altere o parâmetro datadir = / var / lib / mysql para datadir = / var / lib / mysql2 (ou apenas adicione se você não tiver)

3. mv /var/lib/mysql /var/lib/mysql2

Renomeie datadir para um novo nome

4. service mysql start

Prepare seu pandeiro

    

Answer 10

Se nenhuma das outras soluções funcionar, o problema provavelmente deriva da configuração incorreta do AppArmor.

Então faça:

$ apt install apparmor-profiles

e, em seguida, reinicie o MySQL (observe quão rápido ele será reiniciado).

Eu notei um arquivo faltando relacionado ao AppArmor ao fazer:

$ systemctl status mysql.service

Por isso pensei que havia algo errado com a configuração do AppArmor.