MySQL-Referenzhandbuch :: A.4.1 Was zu tun ist, wenn MySQL andauernd abstürzt

Jemand oder etwas killte mysqld oder die Maschine mitten während einer Aktualisierung.

Sie haben einen Bug in mysqld gefunden, der dazu führte, dass er mitten während einer Aktualisierung starb.

Jemand manipuliert die Daten- / Index-Dateien ausserhalb von mysqld, ohne die Tabelle korrekt zu sperren.

Wenn Sie viele mysqld-Server auf denselben Daten auf einem System laufen lassen, das Dateisystem-Sperren nicht gut unterstützt (das wird normalerweise vom lockd-Daemon gehandhabt) oder wenn Sie mehrere Server mit --skip-locking fahren.

Wenn Sie eine beschädigte Index- / Daten-Datei haben, die sehr falsche Daten enthält, die mysqld durcheinander brachten.

Sie haben einen Bug im Datenspeicher-Code gefunden. Das ist nicht sehr wahrscheinlich, aber zumindest möglich. In diesem Fall können Sie versuchen, den Dateityp auf einen anderen Datenbank-Handler umzustellen, indem Sie ALTER TABLE auf eine reparierte Kopie der Tabelle anwenden!

Fahren Sie den mysqld-Daemon mit mysqladmin shutdown herunter und führen Sie myisamchk --silent --force */*.MYI auf alle Tabellen aus. Starten Sie den mysqld-Daemon erneut. Das stellt sicher, dass Sie von einem sauberen Ausgangszustand aus fahren. See Kapitel 5, MySQL-Datenbankadministration.

Benutzen Sie mysqld --log und versuchen Sie den Informationen im Log zu entnehmen, ob eine bestimmte Anfrage den Server killt oder nicht. Etwa 95% aller Bugs beziehen sich auf eine bestimmte Anfrage! Normalerweise ist das eine der letzten Anfragen in der Log-Datei, direkt bevor MySQL neu startete. See Abschnitt 5.9.2, „Die allgemeine Anfragen-Log-Datei“. Wenn Sie MySQL wiederholt mit einer der Anfragen killen, selbst wenn Sie alle Tabellen direkt vor der Ausführung der Anfrage überprüft haben, haben Sie den Bug eingegrenzt und sollten dafür einen Bug-Bericht schreiben! See Abschnitt 2.6.2.3, „Wie man Bugs oder Probleme berichtet“.

Versuchen Sie, einen Testfall herzustellen, den wir zur Reproduzierung des Problems verwenden können. See Abschnitt D.1.6, „Einen Testfall herstellen, wenn Sie Tabellenbeschädigung feststellen“.

Versuchen Sie, die beigefügten mysql-test test und MySQL-Benchmarks laufen zu lassen. See Abschnitt 10.3.2, „MySQL-Test-Suite“. Sie können MySQL recht gut prüfen. Sie können den Benchmarks auch selbst Code hinzufügen, der Ihre Applikation simuliert! Die Benchmarks finden sich im bench-Verzeichnis in der Quelldistribution oder bei einer Binärdistribution im sql-bench-Verzeichnis unter Ihrem MySQL-Installationsverzeichnis.

Probieren Sie fork_test.pl und fork2_test.pl.

Wenn Sie MySQL zum Debuggen konfigurieren, ist es wesentlich einfacher, Informationen über mögliche Fehler zu erhalten, wenn etwas schief geht. Konfigurieren Sie MySQL mit der --with-debug-Option oder mit der --with-debug=full-Option für configure neu und kompilieren Sie neu. See Abschnitt D.1, „Einen MySQL-Server debuggen“.

Wenn MySQL zum Debuggen konfiguriert wird, wird ein sicherer Speicher-Zuweiser (Memory Allocator) hinzugefügt, der einige Fehler finden kann. Ausserdem erfolgen etliche Ausgaben über das, was gerade geschieht.

Haben Sie die neuesten Patches für Ihr Betriebssystem installiert?

Benutzen Sie die --skip-locking-Option für mysqld. Auf manchen Systemen arbeitet der lockd-Sperrmanager nicht korrekt. Die --skip-locking-Option weist mysqld an, keine externen Sperren zu benutzen. (Das heißt, dass Sie nicht zwei mysqld-Server auf denselben Daten laufen lassen können und dass Sie vorsichtig sein müssen, wenn Sie myisamchk benutzen, aber es kann aufschlussreich sein, die Option testweise zu benutzen.)

Haben Sie mysqladmin -u root processlist ausprobiert, wenn mysqld zu laufen scheint, aber nicht antwortet? Manchmal ist mysqld nicht komatös, obwohl es so aussieht. Das Problem kann darin bestehen, dass alle Verbindungen in Benutzung sind, oder es kann ein internes Sperrproblem vorliegen. mysqladmin processlist ist üblicherweise in der Lage, in solchen Fällen eine Verbindung aufzubauen und kann nützliche Informationen über die momentane Anzahl von Verbindungen und ihren Status liefern.

Lassen Sie den Befehl mysqladmin -i 5 status oder mysqladmin -i 5 -r status in einem separaten Fenster laufen, um statistische Informationen auszugeben, während Sie Ihre anderen Anfragen laufen lassen.

Versuchen Sie folgendes:

Versuchen Sie, Ihre Applikation mit einem Perl-Skript zu simulieren, um MySQL zu zwingen, abzustürzen oder fehlerhaftes Verhalten an den Tag zu legen.

Senden Sie einen normalen Bug-Bericht. See Abschnitt 2.6.2.3, „Wie man Bugs oder Probleme berichtet“. Geben Sie mehr Details an als üblich. Weil MySQL bei vielen Leuten funktioniert, kann es sein, dass der Absturz das Ergebnis von etwas ist, das nur auf Ihrem Computer existiert (beispielsweise ein Fehler, der aus Ihren besonderen Systembibliotheken resultiert).

Wenn Sie ein Problem mit Tabellen haben, die Zeilen dynamischer Länge enthalten, und Sie nicht BLOB/TEXT-Spalten benutzen (sondern nur VARCHAR-Spalten), können Sie versuchen, alle VARCHAR- in CHAR-Spalten umzuwandeln, indem Sie ALTER TABLE verwenden. Das erzwingt, dass MySQL Zeilen fester Länge verwendet. Zeilen fester Länge benötigen etwas mehr Platz, sind aber fehlertoleranter gegenüber Beschädigungen!

Der aktuelle Code mit dynamischen Zeilen ist bei MySQL AB seit mindestens drei Jahren ohne jedes Problem in Benutzung, aber naturgemäß sind Zeilen dynamischer Länge fehleranfälliger. Daher kann es eine gute Idee sein, das oben Gesagte auszuprobieren.