O MySQL continua travando: InnoDB: Não foi possível bloquear ./ibdata1, erro: 11

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), no entanto, o servidor mySQL continua travando e preciso interromper todos os processos mySQL para poder reiniciá-lo novamente.

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

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 mySQL aqui, mas não há solução para isso.

Alguma idéia para alguém?

outra abordagem de um comentário no mesmo blog:

isso me ajudou:

lsof -i: 3306

Então mate (o número do processo)

kill -9 PROCESS

por exemplo, matar -9 13498

Em seguida, tente reiniciar o MySQL novamente.

via http://www.webhostingtalk.com/archive/index.php/t-1070293.html

com o ubuntu 14.04. Estou com esse problema ao tentar reiniciar via

/etc/init.d/mysql restart

Em vez disso, tente

service mysql restart 

A causa mais comum desse problema é tentar iniciar o MySQL quando ele já estiver 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 em pacotes de distribuição, a menos que esteja preparado para um mundo de mágoas.

Solução

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

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

http://cglreport.zhenhua.info/2008/08/mysql-error-unable-to-lock-ibdata1.html

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 mysql:

cd /var/lib/mysql/

mova os arquivos innodb para algum lugar, caso você precise:

mv ib* /root/

inicie o mysql:

service mysql start

Veio aqui pesquisando o mesmo erro de repetição, 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 as soluções frequentemente: duas regras (para o próprio diretório e para todos os arquivos dentro, observe o dobro **) e a kopção para permitir que o mysql bloqueie arquivos.

Espero que isso ajude alguém.

Verifique o espaço para garantir que seja 100%

df -h

Como se estivesse cheio, ele não criará um arquivo .sock.

Por favor, verifique se você possui pid-fileparâmetro na [mysql]seção do my.cnfarquivo. Se não estiver presente, unable to lock ...ibdata1.. error:1ocorrerá.

Simples, mas mais rápido do que o caminho 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 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 o datadir para um novo nome

4. service mysql start

Prepare seu pandeiro

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

Então faça:

$ apt install apparmor-profiles

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

Percebi um arquivo ausente relacionado ao AppArmor ao fazer:

$ systemctl status mysql.service

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