MySQL Fehler: Incorrect key file for table ‚./[TABELLENNAME].MYI‘; try to repair it

In den vergangenen Wochen ist mir dieser Fehler mehrfach bei einer sehr großen MySQL-Installation aufgetaucht. Es hat einige Zeit gedauert, bis ich diesen Fehler ausgemerzt habe, zumal die betreffende Tabelle über 20 Mio Einträge bei einer Tabellengröße über 14 GB besitzt. Da ist jeder Befehl, jeder Versuch, die Tabelle zu reparieren, nicht in einer Kaffeepause abgetan. Ein Repair dauert mehrere Stunden …

Da es sich um eine MyISAM-Tabelle handelt, ist der erste Versuch natürlich, die Tabelle per „myisamchk“ zu reparieren. Den genauen Ablauf habe ich im Artikel „MyISAM-Datenbank-Tabelle reparieren“ bereits ausführlich beschrieben. Je nach Tabellengröße ist es an der Zeit, in eine ausgedehnte Mittagspause oder gar ins Bett zu gehen. Dieser Befehl dauert seine Zeit und in meinem Fall hat die Reparatur zwar die Tabelle wieder lesbar gemacht, das defekte Key-File jedoch nicht repariert.

Methode 1: Das Keyfile löschen

In diversen Foren bin ich über die nachfolgend beschriebene Methode gestoßen, um das Keyfile wieder erneut zu stellen. Um es vorweg zu nehmen: Die Methode hat bei meiner Tabelle nicht funktioniert. Ich kann nicht behaupten, dass die Methode nie funktioniert. Aus diesem Grund beschreibe ich sie hier auch. Nur in meinem Fall führte sie nicht zum Erfolg.
Ziel der Methode ist, dass betreffende Keyfile zu löschen und neu erstellen zu lassen:

1. Den MySQL-Server stoppen („sudo service mysql stop“)
2. Das betreffende .myi-File im Dateisystem umbenennen (beispielsweise „name.old“)
3. Den MySQL-Server wieder starten („sudo service mysql start“)
4. Nun die Tabelle reparieren lassen ( http://dev.mysql.com/doc/refman/5.1/en/repair-table.html ). Hierbei soll das Keyfile neu erstellt werden, da es ja nicht mehr vorhanden ist.

In meinem Fall brach die Reparatur mit wilden Fehlermeldungen ab. Ich habe danach wieder das Keyfile der Tabelle hinzugefügt und die Tabelle wieder neu repariert („myisamchk“). Dieser Versuch hat mich dann insgesamt über 12 Stunden beschäftigt. In dieser Zeit war die Datenbank also offline.

Methode 2: Tabelle per Dump neu aufbauen

Bei dieser Methode wird von der betreffenden Tabelle ein Dump erzeugt. Dies geht relativ schnell mittels „mysqldump –h localhost –u USER –pPASSWORD DATENBANKNAME TABELLENNAME > mydump.sql“ Wir erzeugen also einen Dump der Tabelle mit dem defekten Keyfile. In meinem Fall einfach auf der lokalen Platte (sofern natürlich ausreichend Platz vorhanden ist). Zu beachten ist ebenfalls, dass die Tabelle nicht als defekt gekennzeichnet sein darf („marked as crashed“). Wenn dies der Fall ist, muss zuvor per myisamchk die Tabelle repariert werden (siehe oben).
Nun haben wir also auf der lokalen Platte den Dump „mydump.sql“ liegen. Dann wird es spannend: Wir löschen über mysql die Tabelle mit dem defekten Keyfile. Dann spielen wir den Dump wieder zurück. Dies geschieht mit dem Befehl „mysql –h localhost -u USER –pPASSWORD ZIELDATENBANK < dump.sql“. Wenn nach einem abschließenden Return nicht sofort ein Fehler in der Konsole auftaucht, kann sich unser Puls erst einmal wieder regulieren. Im Filesystem kann gesehen werden, dass die Tabelle angelegt wurde und die Größe der Tabelle stetig wächst. Irgendwann wird die Tabelle ihre vorherige Größe haben und das Keyfile wird neu erstellt. Dann meldet sich die Konsole (hoffentlich) ohne Fehlermeldung wieder zurück.
Diese Methode hat für mich großen Charme, denn einerseits hat der eigentliche Dump und das Zurückspielen – vergleichsweise – wenig Zeit gekostet, zum Anderen habe ich mir ein „Optimize Table“ gespart. Die Tabelle wurde ja durch das Rückspielen der Daten von jeglicher Fragmentierung befreit.