MySQL sigue fallando: InnoDB: no se puede bloquear ./ibdata1, error: 11

Tengo un servidor web simple (Debian 6.0 x86, DirectAdmin con 1 GB de memoria y todavía 10 GB de espacio libre, mySQl versión 5.5.9), sin embargo, el servidor mySQL sigue fallando y necesito eliminar todos los procesos mySQL para poder reiniciarlo otra vez.

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

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.

He encontrado un tema en el sitio web mySQL aquí, sin embargo, no hay solución para ello.

¿Alguna idea de alguien?

Otro enfoque de un comentario en el mismo blog:

esto me ayudó:

lsof -i: 3306

Luego mátalo (el número de proceso)

kill -9 PROCESS

por ejemplo, matar -9 13498

Luego intente reiniciar MySQL nuevamente.

a través de http://www.webhostingtalk.com/archive/index.php/t-1070293.html

con ubuntu 14.04. Estoy experimentando este problema cuando intento reiniciar a través de

/etc/init.d/mysql restart

En su lugar, intente

service mysql restart 

La causa más común de este problema es intentar iniciar MySQL cuando ya se está ejecutando.

Para resolverlo, elimine las instancias en ejecución de MySQL y luego reinícielo usando sus scripts de inicio normales, por ejemplo service mysql start.

No intente iniciar MySQL manualmente cuando use versiones empaquetadas de distribución a menos que esté preparado para un mundo de dolor.

Solución

haga una copia de los archivos originales (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

Esto me ayudó a resolverlo:

Elimine todos los archivos ibdata y deje que mysql los cree.

deja de mysql:

service mysql stop

ir a la biblioteca mysql:

cd /var/lib/mysql/

mueva archivos innodb a algún lugar en caso de que lo necesite:

mv ib* /root/

iniciar mysql:

service mysql start

Vine aquí buscando en Google el mismo error repetido pero con el código de error 13 ( InnoDB: Unable to lock ./ibdata1, error: 13). Después de probar muchas soluciones en Internet, inventé una que me ayudó (¡Aparición!)

Agregue estas líneas a la configuración /etc/apparmor.d/usr.sbin.mysqld(y vuelva a cargar apparmor y mysql, por supuesto):

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

Las principales diferencias entre las soluciones a menudo: dos reglas (para el propio directorio y para todos los archivos dentro, tenga en cuenta el doble **) y la kopción para permitir que mysql bloquee los archivos.

Espero que esto ayude a alguien.

Verifique el espacio para asegurarse de que sea 100%

df -h

Como si estuviera lleno, no creará un archivo .sock.

Verifique que tenga un pid-fileparámetro en la [mysql]sección del my.cnfarchivo. Si no está presente, unable to lock ...ibdata1.. error:1ocurrirá.

Simple, pero más rápido que "cp -a". Y ayudó cuando "cp -a" y todo lo demás no pudo.

1. service mysql stop && pkill -f mysql

Deshágase de todos los procesos mysql

2. vi /etc/mysql/my.cnf

Cambie el parámetro datadir = / var / lib / mysql a datadir = / var / lib / mysql2 (o simplemente agregue si no tiene)

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

Cambiar el nombre de datadir a un nuevo nombre

4. service mysql start

Prepara tu pandereta

Si ninguna de las otras soluciones funciona, el problema probablemente se deba a la configuración incorrecta de AppArmor.

Entonces solo hazlo:

$ apt install apparmor-profiles

y luego reinicie MySQL (observe qué tan rápido se reiniciará).

Noté que faltaba un archivo relacionado con AppArmor al hacer:

$ systemctl status mysql.service

Por eso pensé que algo andaba mal con la configuración de AppArmor.