MySQL Fehler seit Dienstabsturz

[M. Zink]

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]

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]

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
myisamchk: warning: Found 7131 parts Should be: 6713 parts
MyISAM-table '/var/lib/mysql/db2_metalforce/wbb1_1_post.MYI' is corrupted
Fix it using switch "-r" or "-o"
myisamchk: warning: 1 client is using or hasn't closed the table properly
MyISAM-table '/var/lib/mysql/db2_metalforce/wcf1_captcha.MYI' is usable but should be fixed
myisamchk: warning: 1 client is using or hasn't closed the table properly
MyISAM-table '/var/lib/mysql/db2_metalforce/wcf1_counter.MYI' is usable but should be fixed
myisamchk: warning: 1 client is using or hasn't closed the table properly
MyISAM-table '/var/lib/mysql/db2_metalforce/wcf1_session_data.MYI' is usable but should be fixed

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
- Fixing index 3
- Fixing index 4
- Fixing index 5
- Fixing index 6
- Fixing index 7
- Fixing index 8
- Fixing index 9
myisamchk: Disk is full writing '/tmp/STOIqCPk' (Errcode: 28). Waiting for someone to free space... Retry in 60 secs

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]

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]

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
tmpfs 5.9G 0 5.9G 0% /dev/shm
/dev/md1 2.0G 79M 1.9G 5% /boot
overflow 1.0M 180K 844K 18% /tmp

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]

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]

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]

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

[M. Zink]

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]

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

umount overflow

Siehe hier:

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