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:
Starten Sie mysqld von gdb (oder einem anderen Debugger) aus. Siehe auch Abschnitt E.1.3, „mysqld unter gdb debuggen“.
Lassen Sie Ihre Testskripten laufen.
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
auf einen
bestimmten Thread umschalten, wobei
N
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.