RootForum Community

Hallo Forum!

Sorry, wenn ich im falschen Unterform gelandet sein sollte, aber ich wußte nicht welches ich wählen sollte...

Ich wende mich Hilfe suchend an Euch:

Auf meinem 1&1-Managed Server ist eine Datenbank/Tabelle defekt. Nun stellt sich mir die Frage, wie das passieren konnte, und ob man so eine Tabelle noch retten kann. Falls ja wie?

Nachdem ich meine Datenbank optimieren wollte, hang sich der Server quasi auf und nach einem Server-Neustart kam bei einem weiteren Analyze folgende Meldung:

warning : Table is marked as crashed and last repair failed
warning : Size of indexfile is: 545614848 Should be: 17893376
warning : Size of datafile is: 286795552 Should be: 286789472
error : Found 626323 keys of 195711
error : Corrupt


Nun habe ich natürlich als erstes versucht, den üblichen Repair-Befehl zu nutzen: mysqlcheck --auto-repair

Damit hatte ich wieder das Problem, dass sich das System quasi aufhängt (natürlich ohne das die Repartur zu Ende stattgefunden hätte). Es ist zwar noch erreichbar, aber der Speicher ist voll - und Dienste wie der Webserver - können nicht mehr, oder nur noch schlecht bedient werden, d. h. meine Website kann nicht mehr geladen werden: "Interner Server Error".

Was kann ich in diesem Fall tun? Wenn ich mir über top die Prozesse anzeigen lasse erscheinen ca. 100 Stück, wovon 99 schlafend sind. Nur der Prozess top ist aktiv... Wenn ich per "kill" irgendwelche Prozesse lösche, ändert das gar nichts an der Situation. Kann ich den Server also nur noch über einen Restart (den ich bei meinem Managed Server ja leider nicht selbst vornehmen kann) wieder zum Laufen bringen?

Nun habe ich ein DB-Backup eingespielt - und die defekte Tabelle ist auch im Backup bereits nicht ganz in Ordnung. Es kommt die Fehlermeldung "Incorrect key file for table x Try to repair it". Nur reparieren kann ich ja nicht, siehe oben! Dann hängt sich das System wieder auf! Also was tun?

Hatte schon mal jemand ein ähnliches Problem? Was kann ich jetzt tun? Mein Provider wird sich zwar "irgendwann" drum kümmern, aber gerne würde ich zukünftig selbst wissen, wie man da vorgehen kann.

Danke für jeden Hinweis!
Gruß,
Chriss

Noch als Ergänzung. Wenn ich mir über top die Prozesse anzeigen lasse, kommt eine lange Liste nichts aussagender Prozesse, die alle je 0% CPU und 0% MEM benötigen, den Time-Status 0:00 haben, Command = PHP4, und schlafend sind. Size, RSS und Share sind allerings ungleich 0.

Trotzdem ist der Hauptspeicher voll:

05:35:19 up 48 min, 3 users, load average: 0.04, 0.07, 0.17
101 processes: 100 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.4% user, 0.2% system, 0.2% nice, 99.2% idle
Mem: 2040572K total, 1979416K used, 61156K free, 18204K buffers
Swap: 257032K total, 0K used, 257032K free, 1106652K cached

Wie kann das sein? Wie leere ich den Speicher wieder? Wo kommen die "toten" Prozesse her?

Gruß,
Chriss

Von Deinem Speicher sind nur ca. 800MB tatsächlich "belegt" (SuFu verrät Dir, was "cached" bedeutet und wie die Ausgabe zu interpretieren ist).

Sleeping != tot (Zombie). Schlafende Prozesse haben eben gerade nichts zu tun und beanspruchen deshalb keine CPU-Zeit. Wahrscheinlich handelt es sich dabei um einen Haufen Apache- und PHP-Prozesse, die auf "Vorrat" erzeugt wurden - das kann man aber über die Apache-Konfiguration einstellen.

jfreund wrote:Von Deinem Speicher sind nur ca. 800MB tatsächlich "belegt" (SuFu verrät Dir, was "cached" bedeutet und wie die Ausgabe zu interpretieren ist).

Sleeping != tot (Zombie). Schlafende Prozesse haben eben gerade nichts zu tun und beanspruchen deshalb keine CPU-Zeit. Wahrscheinlich handelt es sich dabei um einen Haufen Apache- und PHP-Prozesse, die auf "Vorrat" erzeugt wurden - das kann man aber über die Apache-Konfiguration einstellen.

Ok, aber warum läuft das System dann nicht, obwohl "top" bis auf sich selbst nur schlafende Prozesse anzeigt? Wie gesagt, einfache statische Seiten kann der Server in diesem Zustand nicht mehr anzeigen. Oder gibt es noch versteckte Prozesse o. ä., die ich über "top" nicht sehen kann?

Gruß,
Chriss

Welche Prozesse top anzeigt hängt von der Systemkonfiguration insbesondere dem Kernel ab. Sobald Du Prozesse von root sehen kannst, siehst Du alle Prozesse (abgesehen von durch RootKits verborgene). Repariere die Tabelle auf Deinem Testsystem @home, wenn der Server es nicht verkraftet...

Joe User wrote:Welche Prozesse top anzeigt hängt von der Systemkonfiguration insbesondere dem Kernel ab. Sobald Du Prozesse von root sehen kannst, siehst Du alle Prozesse (abgesehen von durch RootKits verborgene). Repariere die Tabelle auf Deinem Testsystem @home, wenn der Server es nicht verkraftet...

Danke zunächst für die Antworten.

Da ich keine Root-Rechte habe, sehe ich also nicht was da abläuft...

Mein Rechner zuhause wird's dann wohl erst recht nicht schaffen, denn der ist bei weitem nicht so gut ausgestattet wie der Server. Leider habe ich nur einen Dump von der gesamten Datenbank. Kann man da irgendwie die eine defekte Tabelle herausextrahieren? Denn 5 Gig Dump-File herunterladen würde ja Tage dauern - und das spätere Hochladen (immerhin ca. 600 MB-Tabelle) dauert ja noch länger...

Gibt es denn keine Möglichkeit, eine Tabelle mit der Fehlermeldung:Incorrect key file for table x Try to repair it

anders zu reparieren? Vielleicht den key file erst löschen und neu anlegen?

Gruß,
Chriss

Zur Info: Mein Provider konnte die Tabelle nun reparieren. Wie sie es gemacht haben, werde ich noch erfragen. Aber wahrscheinlich genügte einfach ein Rechner mit mehr Ressourcen (obwohl mein Server immerhin 2 GB Speicher hat).

Trotzdem ist mein Vertrauen in die MySQL-Datenbank etwas erschüttert. Wie konnte sie nur kaputt gehen? Im Zweifel nutzt einem ja nicht mal mehr ein Backup etwas, denn dort könnte der Fehler auch schon mit drin sein (so wie in meinem Fall).

Gruß,
Chriss

Chriss74 wrote:Im Zweifel nutzt einem ja nicht mal mehr ein Backup etwas, denn dort könnte der Fehler auch schon mit drin sein (so wie in meinem Fall).

Genau aus diesem Grund hebt man mehrere Backup-Generationen auf und rotiert diese dann bei jedem neuen Backup - mit 14 Generationen bei täglichem Backup sollte man eigentlich in der Lage sein, noch ein heiles Backup zu finden. Wenn nicht, hat man volle 2 Wochen gepennt und nicht gemerkt, dass irgendwo was in die Grütze fährt...