# MySQL Fehler seit Dienstabsturz



## M. Zink (16. März 2011)

Hallo,
seit der MySQL Dienst abgeschossen wurde aufgrund von voller Festplatte hab ich wie es aussieht mit dem ein Problem. Folgende Meldung erhalte ich beim restart.


> Checking for corrupt, not cleanly closed and upgrade needing tables..
> server1:~# ERROR 126 (HY000) at line 1: Incorrect key file for table '/tmp/#sql_6ede_0.MYI'; try to repair it


Als erstes wollte ich mit myisamchk -c einfach die Tabelle mal prüfen lassen. Diese Tabelle im Temp Ordner gibts aber offenbar gar nicht. Nach ein wenig fummelei bin ich drauf gekommen, dass auf jeden Fall eine Tabelle schon mal ein Problem hat (Laut PHPMyAdmin). Wenn ich nun in PHPMyAdmin mittels "Repair" versuche die Tabelle zu reparieren läuft das ganze endlos und es passiert nichts außer das der MySQL Server den ganzen Server auslastet bis zum geht nicht mehr.
Ich weiß nicht wie bzw. welche Datei ich bei myisamchk nun angeben muss damit der mal prüft. Ich weiß auch schon genau welche Tabelle in der DB corrupt ist nur weiß ich nicht wie die Lösung hier aussehen muss.


----------



## Till (16. März 2011)

> Wenn ich nun in PHPMyAdmin mittels "Repair" versuche die Tabelle zu reparieren läuft das ganze endlos und es passiert nichts außer das der MySQL Server den ganzen Server auslastet bis zum geht nicht mehr.


wie groß ist die Tabelle und wie lange hast Du gewartet? Das kann bei großen Tabellen und etwas Serverauslastung auch über eine Stunde dauern.



> Ich weiß nicht wie bzw. welche Datei ich bei myisamchk nun angeben muss damit der mal prüft.


Die Datei heißt wie die Defekte Tabelle in phpmyadmin und liegt im Verzeichnis mit dem Namen der Datenbank.


----------



## M. Zink (16. März 2011)

So, ich bin jetzt schon mal ein Stück weiter. Allerdings noch weit weg von OK.
Wenn ich den MySQL Service neu starte kommt die Meldung nicht mehr. Allerdings ist der Fehler nicht weg. Wohl ehr noch schlimmer vermute ich 

Wenn ich mit myisamchk /var/lib/mysql/db2_metalforce/*.MYI >> /tmp/myisamchk_log.txt die defekte Tabelle prüfen lasse erhalte ich folgende Meldung


> myisamchk: warning: Table is marked as crashed and last repair failed
> myisamchk: warning: Size of indexfile is: 2367488       Should be: 600064
> myisamchk: error: Found 7113 keys of 6712
> myisamchk: error: Record-count is not ok; is 7113         Should be: 6712
> ...


Und wenn ich nun versuche die Tabelle zu fixen mittels
myisamchk -r /var/lib/mysql/db2_metalforce/wbb1_1_post.MYI
Erhalte ich folgende Meldung


> - recovering (with sort) MyISAM-table '/var/lib/mysql/db2_metalforce/wbb1_1_post.MYI'
> Data records: 6712
> - Fixing index 1
> - Fixing index 2
> ...


Und dabei bleibt es schon. Ich hab schon in der my.cnf laut irgendwas was ich in Google gefunden habe den Ordner für temporäre Dateien verschoben an einen anderen Ort weil die Rede davon war der Mountpoint für tmp sei möglicherweise zu klein. Kann ja eigentlich nicht sein weil wieder ca. 800 GB frei sind auf der Festplatte.
Kann es sein, dass irgendwas auf dem Server noch nicht gemerkt hat das wieder mehr Platz da ist und deshalb jetzt so dermaßen Zicken macht? Weil der Ordner tmp ist ja ein Ordner im Mountpoint md2 wo laut df -h nur noch 42% belegt sind. Somit sollte auch die größte Tabelle rein passen für die Reparatur.

Lange Rede kurzer Sinn, welches Vorgehen führt hier nun am einfachsten zum Ziel? Ich hab das Gefühl wenn ich jetzt weiter einfach versuche was zu erreichen mache ich ggf. alles noch schlimmer.


----------



## Till (16. März 2011)

Poste bitte mal die Ausgabe von:

df -h

sowie die Ausgabe von:

ls -la /var/lib/mysql/db2_metalforce/wbb1_1_post.MYI


----------



## M. Zink (16. März 2011)

df -h


> Filesystem            Size  Used Avail Use% Mounted on
> /dev/md2              1.4T  515G  797G  40% /
> tmpfs                 5.9G     0  5.9G   0% /lib/init/rw
> udev                   10M  764K  9.3M   8% /dev
> ...


ls -la /var/lib/mysql/db2_metalforce/wbb1_1_post.MYI


> -rw-rw---- 1 mysql mysql 2.3M 2011-03-16 11:58 /var/lib/mysql/db2_metalforce/wbb1_1_post.MYI


Und ich glaube mir geht da grade ein Licht auf wieso das nicht klappt. Der Mountpoint von /tmp is nur 1.0M groß und die Tabelle hat 2.3M und laut meinem Wissen benötigt myisamchk beim Reparieren gerne schon mal die 3 fachte Größe der zu reparierenden Tabelle.
Also muss ich /tmp mehr Speicher geben (der ja auch zur Verfügung steht).


----------



## Till (16. März 2011)

> Und ich glaube mir geht da grade ein Licht auf wieso das nicht klappt. Der Mountpoint von /tmp is nur 1.0M groß und die Tabelle hat 2.3M und laut meinem Wissen benötigt myisamchk beim Reparieren gerne schon mal die 3 fachte Größe der zu reparierenden Tabelle.
> Also muss ich /tmp mehr Speicher geben (der ja auch zur Verfügung steht).


Ich denke auch, das dort das Problem liegt.

Ansonsten kannst Du die defekte Tabelle auch auf einen anderen Linux Server (falls vorhanden) kopieren und dort reparieren.


----------



## M. Zink (16. März 2011)

HA ich hab das Problem mit dem /tmp umgangen! Und siehe da, es hat direkt geklappt.

bei myisamchk gibts die option --tmpdir=<path> womit man den Pfad für /tmp irgendwo anders hin legt für diese eine Aktion. Ich konnte wo nun die Tabelle reparieren und jetzt ist alles wieder absolut sauber!

Wobei ich dennoch meine /tmp könnte ruhig etwas größer sein. Kann man irgendwie nachträglich da an der Größe schrauben ohne dadurch Probleme zu bekommen?


----------



## Till (16. März 2011)

wie ist /tmp denn in /etc/fstab definiert?


----------



## M. Zink (16. März 2011)

Garnicht? 



> proc /proc proc defaults 0 0
> none /dev/pts devpts gid=5,mode=620 0 0
> /dev/md0 none swap sw 0 0
> /dev/md1 /boot ext3 defaults 0 0
> /dev/md2 / ext3 defaults 0 0


----------



## Till (16. März 2011)

Ich glaube Du musst einfach mal neu booten oder versuch ein:

umount overflow

Siehe hier:

https://answers.launchpad.net/ubuntu/+question/34535


----------



## M. Zink (16. März 2011)

Mich würde echt mal interessieren was da so stellenweise auf so nem Server los ist.
Ich hab jetzt einen Neustart vom Server gemacht da ich unter anderem trotz aktiven Diensten keine Emails empfangen hab. Nun zeigt mir df -h folgendes an.


> Filesystem            Size  Used Avail Use% Mounted on
> /dev/md2              1.4T  515G  797G  40% /
> tmpfs                 5.9G     0  5.9G   0% /lib/init/rw
> udev                   10M  764K  9.3M   8% /dev
> ...


Wo ist /tmp hin? Bzw. was hat vor dem Neustart den scheinbar falschen Mountpoint bewirkt der in der fstab nicht mal zu finden war?


----------



## Till (16. März 2011)

Das sieht doch schon mal viel besser aus.



> Wo ist /tmp hin?


/tmp ist ein Unterverzeichnis von /, daher nicht gesondert als mountpoint gelistet.



> zw. was hat vor dem Neustart den scheinbar falschen Mountpoint bewirkt der in der fstab nicht mal zu finden war?


Wahrscheinlich ein kernel Update, so wie im launchpad Thread beschrieben.


----------

