MySQL stürzt weiterhin ab: InnoDB: Sperren von ./ibdata1 nicht möglich, Fehler: 11

43

Ich habe einen einfachen Webserver (Debian 6.0 x86, DirectAdmin mit 1 GB Arbeitsspeicher und noch 10 GB freiem Speicherplatz, mySQl Version 5.5.9), aber der mySQL-Server stürzt immer wieder ab und ich muss alle mySQL-Prozesse beenden, um ihn 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 hier ein Thema auf der mySQL-Website gefunden, aber es gibt keine Lösung dafür.

Irgendwelche Ideen?

mysql debian

— Devator
quelle

Und welche Version von MySQL ist das?

— Michael Hampton

Ich verstehe nicht - dieser Teil der Logdatei beschreibt ein Problem mit MySQL und nicht die Fehlerursache. Am besten entfernen Sie die Ursache des Problems.

— Krzysztof Księżyk

@MichaelHampton Der Beitrag wurde bearbeitet (mySQL Version 5.5.9 und das Protokoll erweitert).

— Devator

1

Haben Sie vor dem Start überprüft, ob mysqld nicht ausgeführt wird? Wie?

— Symcbean

32

Ein anderer Ansatz aus einem Kommentar im selben Blog:

das hat mir geholfen:

Isof -i: 3306

Dann töte es (die Prozessnummer)

kill -9 PROCESS

zB töte -9 13498

Versuchen Sie dann erneut, MySQL neu zu starten.

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

— Brigo
quelle

1

service mysql restartzeigte bereits keinen laufenden Prozess, lsoffand ihn aber. Killed it, service mysql startund jetzt kann die Flut von Prozess fehlgeschlagenen E-Mails aufhören. Danke vielmals.

— Doyle Lewis

28

mit Ubuntu 14.04. Ich habe dieses Problem, wenn ich versuche, über neu zu starten

/etc/init.d/mysql restart

Versuchen Sie es stattdessen

service mysql restart

— Jens
quelle

1

Danke, es hat geholfen. Aber wieso?

— Auch

1

@too askubuntu.com/questions/2075/…

— mloskot

@too, wenn Sie sowohl ein altes init.d-Skript als auch eine Upstart-Konfiguration für einen Job haben, müssen Sie diese verwenden service job start. Wenn Sie es mit dem init.d-Skript starten, weiß Upstart nichts darüber und es könnte versuchen um eine andere Instanz zu booten. (Zumindest ist dies bei den Standard-Init-Skripten von MySQL der Fall.)

— wireman

@wireman: Das erklärt, warum andere Pakete, einschließlich knot (DNS-Server), ähnliche Probleme haben. Wann haben sie beschlossen, es durchzusetzen? Ich denke, /etc/init.d ist überlegen, da es die Vervollständigung der Shell ermöglicht und den Benutzer von übermäßigem Tippen befreit. Fortschritt auf die Potenz von -1 :)

— auch

Die Vervollständigung der Registerkarte "@too Bash" kann angepasst werden. Sie haben noch nichts von Ubuntu zur Hand, aber es scheint seltsam, dass niemand daran gedacht hätte, Namen mit Tabulatoren zu ergänzen service. Senden Sie Canonical möglicherweise eine Feature-Anfrage über deren Bug-Tracker?

— ein

18

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

Um es zu beheben, beenden Sie alle laufenden Instanzen von MySQL und starten Sie es dann mit Ihren normalen Startskripten neu, z service mysql start.

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

— Michael Hampton
quelle

however the mySQL server keeps crashing- Ich starte mySQL nicht neu. Es stürzt einfach von selbst ab, danach muss ich es offensichtlich neu starten. ;-)

— Devator

@MichaelHampton kannst du etwas mehr über 'world of hurt' und 'MySQL manuell starten' erzählen? Danke)

— Serge Kvashnin

11

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

— Brigo
quelle

hat mir magisch geholfen.

— nils petersohn

Was ist der Sinn von cp -a? Ich habe bereits die Manpage gelesen

— Ilja

2

Vielen Dank, es hat geholfen. Aber wieso?

— DaviAragao

Ich hatte dieses Problem nach einem fehlgeschlagenen Neustart auf einer Datenbank, die in einem Docker-Container ausgeführt wird. Ich mache eine fundierte Vermutung, warum dies funktioniert und es ist, dass einige Metadaten in der Datei gespeichert sind. Durch Verschieben und Kopieren an den ursprünglichen Speicherort werden die Metadaten entfernt, die bestimmen, dass sie gesperrt sind. Die Operation -a behält die Dateiattribute bei, einschließlich der SELinux-bezogenen Attribute, jedoch nicht die Metadaten, während des Kopiervorgangs.

— JDL

2

Dies hat mir geholfen, es zu lösen:

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

Stoppen Sie MySQL:

service mysql stop

Gehe zur MySQL-Bibliothek:

cd /var/lib/mysql/

Verschieben Sie innodb-Dateien an einen beliebigen Ort, falls Sie sie benötigen:

mv ib* /root/

starte mysql:

service mysql start

— Ali Caner Öner
quelle

Durch hilfreiche Antworten scrollen Ich dachte, das wird sicher funktionieren, da sich der Fehler darüber beschwert, dass diese Datei nicht gesperrt werden kann. Nach dem Umzug hat mysql sie neu erstellt, beschwert sich aber immer noch ... verrückt!

— Kyle Burkett

1

Kam hier vom googeln des gleichen sich wiederholenden Fehlers aber mit Fehlercode 13 ( InnoDB: Unable to lock ./ibdata1, error: 13). Nachdem ich viele Lösungen im Internet ausprobiert hatte, erfand ich eine, die mir half (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 wichtigsten Unterschiede zwischen oft Lösungen: zwei Regeln (für dir selbst und für alle Dateien innerhalb, beachten Sie die Doppel **) und kOption mysql Lock - Dateien zu ermöglichen.

Hoffe das hilft jemandem.

— hlomzik
quelle

Sie können es auch hinzufügen /etc/apparmor.d/local/usr.sbin.mysqld. Erstellen Sie die Datei, wenn sie nicht vorhanden ist. Weitere Informationen finden Sie unter/etc/apparmor.d/local/README

— knb

1

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

df -h

Als ob es voll wäre, würde es keine .sock-Datei erstellen.

— RicardasSorryxas
quelle

Die Antwort ist über einen überraschenden Nebeneffekt, ich bin absolut anderer Meinung, es wäre LQ.

— user259412

0

Bitte überprüfen Sie, ob Sie pid-fileParameter im [mysql]Abschnitt der my.cnfDatei haben. Wenn es nicht vorhanden ist, unable to lock ...ibdata1.. error:1wird das auftreten.

— Sachin
quelle

0

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

service mysql stop && pkill -f mysql

Beseitigen Sie alle MySQL-Prozesse

vi /etc/mysql/my.cnf

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

mv /var/lib/mysql /var/lib/mysql2

Benennen Sie datadir in einen neuen Namen um

service mysql start

Bereiten Sie Ihr Tamburin vor

— WSR
quelle

0

Wenn keine der anderen Lösungen funktioniert, ist das Problem wahrscheinlich auf eine falsche AppArmor-Konfiguration zurückzuführen.

Also mach einfach:

$ apt install apparmor-profiles

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

Ich habe festgestellt, dass im Zusammenhang mit AppArmor eine Datei fehlt:

$ systemctl status mysql.service

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

— Fevangelou
quelle