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

43

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?

mysql debian Devator
fuente
¿Y qué versión de MySQL es esta?
Michael Hampton
No entiendo: esta parte del archivo de registro informa sobre el problema con el inicio de MySQL, no sobre la causa del error. Lo mejor es eliminar la fuente del problema.
Krzysztof Księżyk
@MichaelHampton La publicación ha sido editada (mySQL versión 5.5.9 y aumentó el registro).
Devator
1
¿Comprobaste que no se estaba ejecutando mysqld antes de iniciarlo? ¿Cómo?
symcbean

Respuestas:

32

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

Brigo
fuente
1
service mysql restartya no mostraba ningún proceso en ejecución, pero lo lsofencontró. Lo mató service mysql start, y ahora la avalancha de correos electrónicos fallidos del proceso puede detenerse. Muchas gracias.
Doyle Lewis
28

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
Jens
fuente
1
Gracias, me ayudó. ¿Pero por qué?
también
1
@too askubuntu.com/questions/2075/…
mloskot
@too, si tiene un script init.d de estilo antiguo y una configuración inicial para un trabajo, debe usarlo service job start; de lo contrario, si lo inicia con el script init.d, Upstart no lo sabrá y podría intentarlo para arrancar otra instancia. (Al menos ese es el caso con el defecto de MySQL init scripts.)
wireman
@wireman: eso explica por qué otros paquetes, incluido el nudo (servidor DNS), tienen problemas similares. ¿Cuándo decidieron hacerla cumplir? Creo que /etc/init.d es superior, ya que permite completar el shell y, por lo tanto, alivia al usuario del tipeo excesivo. Progreso al poder de -1 :)
también el
La finalización de la pestaña @too Bash es personalizable. No tengo nada Ubuntu a mano, pero parece extraño que nadie hubiera pensado en completar servicenombres de tabulación . ¿Tal vez enviar una solicitud de función a Canonical a través de su rastreador de errores?
un CVn
18

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.

Michael Hampton
fuente
however the mySQL server keeps crashing- No reinicio mySQL. Simplemente se bloquea, luego de lo cual necesito reiniciarlo obviamente. ;-)
Devator
@MichaelHampton, ¿puede darnos un poco más de información sobre 'world of hurt' e 'iniciar MySQL manualmente'? Gracias)
Serge Kvashnin
11

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

Brigo
fuente
mágicamente me ayudó.
nils petersohn
¿Cuál es el punto de cp -a?, ya he leído la página de manual
Ilja
2
Muchas gracias, me ayudó. ¿Pero por qué?
DaviAragao
Tuve este problema después de un reinicio fallido en una base de datos que se ejecuta en un contenedor docker. Estoy haciendo una suposición educada de por qué esto funciona y es que algunos metadatos se almacenan en el archivo. moverlo y copiarlo en su ubicación original elimina los metadatos que determinan que está bloqueado. la operación -a mantiene los atributos del archivo, incluidos los atributos relacionados con SELinux, pero no los metadatos, durante la copia.
JDL
2

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
Ali Caner Öner
fuente
Desplazándome por respuestas útiles, pensé que seguramente esto funcionaría, ya que el error se queja de no poder bloquear ese archivo. Después de mudarse, mysql los recreó pero aún se queja ... ¡loco!
Kyle Burkett
1

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.

hlomzik
fuente
También puedes agregarlo a /etc/apparmor.d/local/usr.sbin.mysqld. Cree el archivo si no existe. Para obtener más detalles, consulte/etc/apparmor.d/local/README
knb
1

Verifique el espacio para asegurarse de que sea 100%

df -h

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

RicardasSorryxas
fuente
La respuesta es sobre un sorprendente efecto secundario, estoy totalmente en desacuerdo con que sería LQ.
Peter dice reinstalar a Mónica
0

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á.

Sachin
fuente
0

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

  1. vi /etc/mysql/my.cnf

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

  1. mv /var/lib/mysql /var/lib/mysql2

Cambiar el nombre de datadir a un nuevo nombre

  1. service mysql start

Prepara tu pandereta

WSR
fuente
0

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.

fevangelou
fuente