Skip navigation links
A.4.3 Wie MySQL mit vollen Festplatten umgeht »
Section Navigation      [Toggle]

A.4.2. Was zu tun ist, wenn MySQL andauernd abstürzt

Jede MySQL-Version wird vor dem Release auf vielen Plattformen getestet. Dennoch kann es immer noch Bugs in MySQL geben, allerdings ziemlich wenige, die darüber hinaus schwer zu finden sind. Wenn Sie ein Problem haben, ist es immer gut, ganz genau festzustellen, was Ihr System zum Absturz brachte. Dann sind Ihre Chancen auf schnelle Abhilfe viel besser.

Als Erstes müssen Sie herausfinden, ob Ihr mysqld-Server oder Ihr Client an dem Absturz schuld ist. Der Befehl mysqladmin version verrät Ihnen, wie lange Ihr mysqld-Server bereits läuft. Wenn mysqld herunter- und wieder hochgefahren ist, finden Sie die Wurzel des Problems vielleicht im Fehlerlog des Servers. Siehe Abschnitt 5.12.1, „Die Fehler-Logdatei“.

Auf manchen Systemen enthält das Fehlerlog einen Stack-Trace mit der Information, wo mysqld abgestürzt ist. Diesen Trace können Sie mit dem Programm resolve_stack_dump auswerten. Siehe Abschnitt E.1.4, „Einen Stack-Trace benutzen“. Beachten Sie, dass die Variablenwerte im Fehlerlog nicht immer hundertprozentig korrekt sind.

Viele Serverabstürze werden durch beschädigte Daten- oder Indexdateien verursacht. MySQL aktualisiert nach jeder SQL-Anweisung und vor der Benachrichtigung des Clients über das Ergebnis die Dateien auf der Festplatte mit dem Systemaufruf write(). (Das gilt allerdings nicht, wenn Sie mit der Option --delay-key-write arbeiten: Hier werden zwar die Datendateien zeitnah geschrieben, aber nicht die Indexdateien.) Das bedeutet, dass der Inhalt der Datendateien selbst bei einem mysqld-Absturz sicher ist, weil das Betriebssystem dafür sorgt, dass die Arbeitsspeicherdaten auf die Platte zurückgeschrieben werden. Sie können MySQL zwingen, nach jeder SQL-Anweisung gleich alles auf die Platte zurückzuschreiben, indem Sie mysqld mit der Option --flush starten.

Das bedeutet, dass Sie normalerweise nur in folgenden Fällen mit beschädigten Tabellen zu tun haben:

  • Wenn der MySQL Server oder der Serverhost mitten in einem Update abgestürzt ist.

  • Wenn Sie einen Bug in mysqld gefunden haben, der den Prozess mitten in einem Update anhielt.

  • Wenn ein externes Programm Daten- oder Indexdateien zur gleichen Zeit wie mysqld ändert, ohne die Tabelle ordentlich zu sperren.

  • Wenn Sie viele mysqld-Server zugleich mit demselben Data Directory auf einem System betreiben, das keine vernünftigen Dateisystemsperren kennt (diese werden normalerweise von dem Sperrenmanager lockd verwaltet), oder wenn Sie mehrere Server bei ausgeschaltetem externem Locking laufen lassen.

  • Wenn Sie eine abgestürzte Daten- oder Indexdatei mit völlig kaputten Daten haben, die mysqld in Verwirrung stürzt.

  • Wenn Sie einen Fehler im Code der Datenspeicherung gefunden haben. Das ist zwar unwahrscheinlich, aber nicht unmöglich. In diesem Fall können Sie versuchen, die Speicher-Engine auf eine andere Engine umzustellen, indem Sie ALTER TABLE auf einer reparierten Kopie der Tabelle ausführen.

Da der Grund für einen Absturz so schwer festzustellen ist, sollten Sie zuerst versuchen, herauszufinden, ob Dinge, die bei anderen funktionieren, bei Ihnen abstürzen. Hierzu sollten Sie Folgendes ausprobieren:

  • Halten Sie den mysqld-Server mit mysqladmin shutdown an, führen Sie im Data Directory myisamchk --silent --force */*.MYI aus, um alle MyISAM-Tabellen zu prüfen, und starten Sie mysqld erneut. Dann ist gewährleistet, dass der Server in einem sauberen Zustand läuft. Siehe Kapitel 5, Datenbankverwaltung.

  • Starten Sie mysqld mit der Option --log und versuchen Sie, an den Logdaten zu erkennen, ob eine spezifische Anfrage den Server abstürzen lässt. Rund 95 % aller Fehler hängen mit einer konkreten Anfrage zusammen. Normalerweise ist dies eine der letzten Anfragen, die in der Logdatei kurz vor dem Neustart des Servers protokolliert sind. Siehe auch Abschnitt 5.12.2, „Die allgemeine Anfragen-Logdatei“. Wenn Sie MySQL mit einer bestimmten Anfrage wiederholt zum Absturz bringen können, obwohl Sie alle Tabellen kurz vorher überprüft haben, dann haben Sie den Fehler gefunden und sollten einen Bugreport übermitteln. Siehe hierzu Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

  • Versuchen Sie, einen Testfall einzurichten, den wir verwenden können, um den Fehler zu reproduzieren. Siehe Abschnitt E.1.6, „Erzeugen eines Testfalls, wenn Sie Tabellenbeschädigung feststellen“.

  • Versuchen Sie, die Tests im Verzeichnis mysql-test und die MySQL-Benchmarks auszuführen. Siehe Abschnitt 26.1.2, „MySQL-Testsystem“. Damit sollte MySQL ziemlich gut getestet sein. Sie können den Benchmarks auch Code hinzufügen, der Ihre Anwendung simuliert. Die Benchmarks finden Sie im Verzeichnis sql-bench einer Quelldistribution oder im Verzeichnis sql-bench unterhalb des MySQL-Installationsverzeichnisses in einer Binärdistribution.

  • Probieren Sie es mit dem Skript fork_big.pl. (Dieses finden Sie im Verzeichnis tests der Quelldistributionen.)

  • Wenn Sie MySQL für das Debugging konfigurieren, lassen sich Informationen über mögliche Fehler viel leichter beschaffen. In der Debuggingkonfiguration ist eine Arbeitsspeicherzuweisung enthalten, die so manchem Fehler auf die Spur kommt. Außerdem liefert diese Konfiguration viele Ausgabedaten über alles, was vor sich geht. Rekonfigurieren Sie also MySQL mit der Option --with-debug oder --with-debug=full für configure und kompilieren Sie dann neu. Siehe auch Abschnitt E.1, „Einen MySQL-Server debuggen“.

  • Installieren Sie immer die neuesten Patches für Ihr Betriebssystem.

  • Stellen Sie die Option --skip-external-locking für mysqld ein. Auf manchen Systemen funktioniert der Sperrenmanager lockd nicht richtig. Die Option --skip-external-locking hält mysqld davon ab, externes Locking zu benutzen. (Das bedeutet, dass Sie nicht zwei mysqld-Server mit demselben Data Directory betreiben können und dass Sie mit myisamchk aufpassen müssen. Aber immerhin kann es sehr aufschlussreich sein, die Option einmal auszuprobieren.)

  • Haben Sie es schon mit mysqladmin -u root processlist versucht, wenn mysqld scheinbar läuft, aber nicht antwortet? Manchmal ist mysqld gar nicht ins Koma gefallen, auch wenn es den Anschein hat. Vielleicht sind alle Verbindungen belegt oder es gibt ein Problem mit internen Sperren. Normalerweise kann mysqladmin -u root processlist selbst in solchen Fällen eine Verbindung einrichten und Aufschluss über die Anzahl und den Status der laufenden Verbindungen geben.

  • Führen Sie in einem separaten Fenster den Befehl mysqladmin -i 5 status oder mysqladmin -i 5 -r status aus, um Statistiken zu erstellen, während sie andere Anfragen ausführen.

  • Versuchen Sie Folgendes:

    1. Starten Sie mysqld von gdb (oder einem anderen Debugger) aus. Siehe auch Abschnitt E.1.3, „mysqld unter gdb debuggen“.

    2. Lassen Sie Ihre Testskripten laufen.

    3. Geben Sie den Backtrace und die lokalen Variablen auf den drei untersten Ebenen aus. In gdb tun Sie dies mit den folgenden Befehlen, wenn mysqld innerhalb von gdb abgestürzt ist: 

      backtrace
info local
up
info local
up
info local

      In gdb können Sie auch mit info threads herausfinden, welche Threads vorhanden sind, und mit thread N auf einen bestimmten Thread umschalten, wobei N die Thread-ID ist.

  • Versuchen Sie, Ihre Anwendung mit einem Perl-Skript zu simulieren, um MySQL zu einem Absturz oder Fehlverhalten zu veranlassen.

  • Senden Sie einen normalen Bugreport. Siehe Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“. Machen Sie noch detailliertere Angaben als üblich. Da MySQL bei den meisten Nutzern funktioniert, kann es sein, dass der Crash durch Umstände verursacht wird, die nur auf Ihrem Compter existieren (zum Beispiel im Zusammenhang mit Ihren Systembibliotheken).

  • Wenn Sie Schwierigkeiten mit Tabellen haben, die Datenzeilen mit variabler Länge speichern und nur VARCHAR-, aber keine BLOB- oder TEXT-Spalten benutzen, können Sie mit ALTER TABLE ausprobieren, alle VARCHAR- in CHAR-Spalten zu ändern. Damit zwingen Sie MySQL, Zeilen mit fester Länge zu verwenden, die zwar ein bisschen mehr Platz belegen, aber weniger anfällig für Beschädigungen sind.

    Der jetzige Code für dynamische Zeilen, den MySQL AB schon seit Jahren verwendet, macht nur minimale Probleme, aber Zeilen dynamischer Länge sind von Natur aus fehleranfälliger. Daher sollten Sie bei Problemen folgende Strategie versuchen:

  • Beziehen Sie auch Ihre Serverhardware als mögliche Fehlerursache ein. Auch Hardwaredefekte können Datenkorruption verursachen. Achten Sie bei der Hardware besonders auf RAMs und Festplattenlaufwerke.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.