MySQL Fehler seit Dienstabsturz

M

M. Zink

New Member
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
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
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.
 
T

Till

Administrator
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.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

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.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

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

M. Zink

New Member
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 :confused:

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
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
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
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
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.
 
T

Till

Administrator
Poste bitte mal die Ausgabe von:

df -h

sowie die Ausgabe von:

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

M. Zink

New Member
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
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
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
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
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).
 
T

Till

Administrator
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).
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.

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

M. Zink

New Member
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?
 
M

M. Zink

New Member
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
tmpfs 5.9G 0 5.9G 0% /dev/shm
/dev/md1 2.0G 79M 1.9G 5% /boot
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Wo ist /tmp hin? Bzw. was hat vor dem Neustart den scheinbar falschen Mountpoint bewirkt der in der fstab nicht mal zu finden war?
 
T

Till

Administrator
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top