Frage MySQL stürzt ab: InnoDB: Kann nicht sperren ./ibdata1, Fehler: 11


Ich habe einen einfachen Webserver (Debian 6.0 x86, DirectAdmin mit 1 GB Speicher und immer noch 10 GB freien Speicherplatz, mySQl Version 5.5.9), aber der mySQL-Server stürzt immer ab und ich muss alle mySQL-Prozesse beenden, um sie neu starten zu können nochmal.

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

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.

Ich habe ein Thema auf der mySQL-Website gefunden Hier Aber es gibt keine Lösung dafür.

Irgendwelche Ideen irgendjemand?


38
2018-02-10 22:01


Ursprung


Und welche Version von MySQL ist das? - Michael Hampton♦
Ich verstehe nicht - dieser Teil der Protokolldatei erzählt über das Problem mit dem MySQL-Start nicht über die Ursache des Fehlers. Das Beste ist, die Ursache des Problems zu beseitigen. - Krzysztof Księżyk
@MichaelHampton Der Beitrag wurde bearbeitet (mySQL Version 5.5.9 und das Log erhöht). - Devator
Haben Sie überprüft, dass mysqld nicht ausgeführt wurde, bevor Sie es gestartet haben? Wie? - symcbean


Antworten:


ein anderer Ansatz von einem Kommentar im selben Blog:

Das hat mir geholfen:

lsof -i: 3306

Dann töte es (die Prozessnummer)

kill -9 PROZESS

z.B. Töte -9 13498

Versuchen Sie dann, MySQL erneut zu starten.

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


30
2018-02-10 23:04



service mysql restart zeigte schon keinen laufenden Prozess, aber lsof fand es. Töte es, service mysql startund jetzt die Flut von Prozess fehlgeschlagenen E-Mails kann aufhören. Danke vielmals. - Doyle Lewis


mit ubuntu 14.04. Ich habe dieses Problem, wenn ich versuche, neu zu starten

/etc/init.d/mysql restart

Stattdessen versuche es

service mysql restart 

27
2018-02-05 22:21



Danke, es hat geholfen. Aber warum? - too
@auch askubuntu.com/questions/2075/... - mloskot
@too, wenn Sie beide ein altes init.d-Skript haben und eine Upstart-Konfiguration für einen Job, den Sie verwenden müssen service job startAndernfalls würde Upstart nichts davon wissen und könnte versuchen, eine andere Instanz zu booten, wenn Sie es mit dem Skript init.d starten. (Dies ist zumindest bei den Standard-Init-Skripten von MySQL der Fall.) - wireman
@wireman: das erklärt, warum andere Pakete einschließlich Knoten (DNS-Server) ähnliche Probleme haben. Als sie beschlossen, es durchzusetzen? Ich denke, /etc/init.d ist überlegen, da es die Shell-Vervollständigung erlaubt und so den Benutzer von übermäßiger Typisierung befreit. Fortschritte auf die Macht von -1 :) - too
@too Bash tab completion ist anpassbar. Habe nichts Ubuntu zur Hand, aber es scheint merkwürdig, dass niemand daran gedacht hätte, Tabulatoren zu erstellen service Namen. Übermitteln Sie vielleicht eine Feature-Anfrage an Canonical über ihren Bug-Tracker? - α CVn


Die häufigste Ursache für dieses Problem ist der Versuch, MySQL zu starten, wenn es bereits ausgeführt wird.

Um dies zu beheben, beenden Sie alle laufenden MySQL-Instanzen und starten Sie sie dann mit Ihren normalen Startskripten, z. service mysql start.

Versuchen Sie nicht, MySQL manuell zu starten, wenn Sie verteilte Versionen verwenden, es sei denn, Sie sind auf eine Welt voller Verletzungen vorbereitet.


17
2018-02-10 22:16



however the mySQL server keeps crashing - Ich starte mySQL nicht neu. Es stürzt einfach ab, nach dem ich es offensichtlich neu starten muss. ;-) - Devator
@MichaelHampton kannst du etwas mehr über 'Welt der Verletzung' und 'MySQL manuell starten' geben? Vielen Dank) - sergekv


Lösung

Erstellen Sie eine Kopie der Originaldateien (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


10
2018-02-10 23:01



Magisch hat mir geholfen. - nils petersohn
was ist der Punkt von cp-a? Ich habe bereits Manpage gelesen - Ilja
Vielen Dank, es hat geholfen. Aber warum? - DaviAragao
Ich hatte dieses Problem nach einem fehlgeschlagenen Neustart für eine Datenbank, die in einem Andock-Container ausgeführt wird. Ich mache eine fundierte Vermutung, warum das funktioniert und es ist, dass einige Metadaten in der Datei gespeichert sind. Wenn Sie sie verschieben und an den ursprünglichen Speicherort kopieren, werden die Metadaten entfernt, wodurch festgestellt wird, dass sie gesperrt ist. Die Operation -a behält während der Kopie die Dateiattribute bei, einschließlich SELinux-bezogener Attribute, nicht jedoch die Metadaten. - JDL


Das hat mir geholfen, es zu lösen:

Löschen Sie alle ibdata-Dateien und lassen Sie sie von mysql erstellen.

stoppe mysql:

service mysql stop

Gehe zur mysql-Bibliothek:

cd /var/lib/mysql/

Verschiebe innodb-Dateien, falls du sie brauchst:

mv ib* /root/

starte mysql:

service mysql start

2
2018-01-13 11:28



Wenn ich durch hilfreiche Antworten blättere, dachte ich, dass es so aussieht, als würde es funktionieren, da sich der Fehler darüber beschwert, dass man diese Datei nicht sperren kann. Nach dem Umzug hat Mysql sie neu erstellt, aber immer noch beschwert ... verrückt! - Kyle Burkett


Kam hier vom Googeln des gleichen Wiederholungsfehlers aber mit Fehlercode 13 (InnoDB: Unable to lock ./ibdata1, error: 13). Nachdem ich viele Lösungen im Internet probiert habe, habe ich eine erfunden, die mir geholfen hat (apparmor!)

Fügen Sie diese Zeilen zur Konfiguration hinzu /etc/apparmor.d/usr.sbin.mysqld (und laden Sie natürlich apparmor und mysql neu):

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

Die Hauptunterschiede zwischen oft Lösungen: zwei Regeln (für dir selbst und für alle Dateien im Inneren, beachten Sie die doppelte **) und k Option, um es mysql zu erlauben, Dateien zu sperren.

Hoffe, dass das jemandem hilft.


1
2018-03-15 18:22



Sie können es auch hinzufügen /etc/apparmor.d/local/usr.sbin.mysqld. Erstellen Sie die Datei, wenn sie nicht existiert. Für mehr Details sehen Sie bitte /etc/apparmor.d/local/README - knb


Überprüfen Sie den Speicherplatz, um sicherzustellen, dass es 100% ist

df -h

Als ob es voll ist wird es keine .sock Datei erstellen.


1
2018-02-04 14:30



Die Antwort ist über einen überraschenden Nebeneffekt, ich stimme überhaupt nicht zu, es wäre LQ. - peterh


Bitte überprüfen Sie, dass Sie haben pid-file Parameter in der [mysql] Abschnitt von my.cnf Datei. Wenn es nicht vorhanden ist, das unable to lock ...ibdata1.. error:1 wird passieren.


0
2018-01-20 19:24





Einfach, aber schneller als mit "cp -a". Und half, wenn "cp -a" und alles andere nicht konnte.

  1. service mysql stop && pkill -f mysql

Befreie alle mysql-Prozesse

  1. vi /etc/mysql/my.cnf 

Ändern Sie den Parameter datadir = / var / lib / mysql in datadir = / var / lib / mysql2 (oder fügen Sie einfach hinzu, wenn Sie nicht haben)

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

Benennen Sie das Datenverzeichnis in einen neuen Namen um

  1. service mysql start 

Bereite dein Tamburin vor


0
2018-03-23 09:59





Wenn keine der anderen Lösungen funktioniert, liegt das Problem wahrscheinlich an der falschen Konfiguration von AppArmor.

Also mach einfach:

$ apt install apparmor-profiles

und starte MySQL neu (merke, wie schnell es neu startet).

Ich habe festgestellt, dass eine Datei in Verbindung mit AppArmor fehlt:

$ systemctl status mysql.service

Daher dachte ich, dass etwas mit AppArmors Konfiguration nicht stimmte.


0
2018-01-26 12:48