Datenbank optimieren / reparieren - Prozess hängt sich auf

[fenris]

Hy,

wenn ich versuche meine Datenbank "post" zu reparieren bzw. zu optimieren, hängt diese sich auf. Die Zeit stehet nun schon seit über 1 Stunde und es tut sich nichts mehr. Gibt es da irgendwie einen Trick, wie ich die Datenbank doch noch repariert bekomme ?

Gruß

Frank

Folgender Prozess ist zu sehen :

HTML clipboard IdUserHostdbCommandTimeStateInfo43hbtfj8l_GTvUlpolocalhostmysql_server_1Query7534Repair by sortingOPTIMIZE TABLE `vb3_post`1592hbtfj8l_GTvUlpolocalhostmysql_server_1Query7525Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1593hbtfj8l_GTvUlpolocalhostmysql_server_1Query7522Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1606hbtfj8l_GTvUlpolocalhostmysql_server_1Query7497Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1615hbtfj8l_GTvUlpolocalhostmysql_server_1Query7477Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1628hbtfj8l_GTvUlpolocalhostmysql_server_1Query7456Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1630hbtfj8l_GTvUlpolocalhostmysql_server_1Query7452Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1636hbtfj8l_GTvUlpolocalhostmysql_server_1Query7444Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1645hbtfj8l_GTvUlpolocalhostmysql_server_1Query7435Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1798hbtfj8l_GTvUlpolocalhostmysql_server_1Query7387Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1813hbtfj8l_GTvUlpolocalhostmysql_server_1Query7375Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1846hbtfj8l_GTvUlpolocalhostmysql_server_1Query7366Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1875hbtfj8l_GTvUlpolocalhostmysql_server_1Query7354Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1904hbtfj8l_GTvUlpolocalhostmysql_server_1Query7345Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed1922hbtfj8l_GTvUlpolocalhostmysql_server_1Query7340Waiting for tableSELECT post.*, IF(post.visible = 2, 1, 0) AS isdeleted, editlog.userid AS edit_userid, ed

[Valério Leitner]

Hast du bei dir Mysqldumper/Phpmyadmin installiert/eingerichtet?

Wenn ja, dann kannst du auch darüber die Datenbanken reparieren/optimieren


Hast du nur Webspace oder nen VServer/RootServer?
Mit Zugriff auf die SystemShell kannst du die Befehle genauso absetzen, ich hab mir dazu ne kleine Bash-Datei angelegt, die jede Nacht per Cronjob ausgeführt wird und die ganzen Datenbanken optimiert ^^

[fenris]

Hy,

ich versuche gerade die Datenbank über den Server direkt zu reparieren. Leider ist nun ein Fehler in der Datenbank und die post Tabelle scheint beschädigt zu sein. Die Tabelle hat eine Größe von ca. 1 GB - wie bekomme ich die repariert bei dieser Größe ? Jeder Reparatur Prozess bleibt hängen ?

Gruß

Frank

[Valério Leitner]

das klingt wohl eher so, als ob deine mysql-config nicht entsprechend angepasst ist für solche aktionen

[fenris]

Hy,

das ist die Fehlermeldung :

MySQL-Fehler : Table './mysql_server_1/vb3_post' is marked as crashed and last (automatic?) repair failed

[fenris]

Hy,

und noch ein Nachtrag :

Error : File './mysql_server_1/vb3_post.MYD' not found (Errcode: 2)
Error : Can't find file: 'vb3_post' (errno: 2)
error : Corrupt

Ist die Datei ( Der Inhalt ) nun unwiederbringlich kaputt ? Wieso heißt die Dateiendung den nun "
vb3_post.MYD"

Gruß

Frank

[Jaydee]

Hallo,

auch wenn die Tabelle post fast immer die mit Abstand größte ist, sind natürlich 1 GB nur dafür schon eine Hausnummer.
Es klingt danach, als ob es bei Dir an den MySQL Limits hängt und der Server diese Form/Länge der Abfragen irgendwann ablehnt.
In dem Fall kannst Du nur den Hoster bitten, die Limits zu lockern. Auf Shared-Servern sieht's damit aber relativ schlecht aus.

Wie Du einen repair/optimze Befehl ausführst, ist relativ egal.
Ob per vB-ACP, MySQLDumper, Shell oder phpMyAdmin. Technisch geschieht im Hintergrund immer dasselbe.

Beim ACP kann man ggf. darauf reinfallen, dass die Seite im Browser nicht zuende lädt bzw. abbricht, weil es zu lange dauert. Das Script und der Prozess laufen dann normalerweise trotzdem bis zum Ende durch. Aber bei 1 GB ist das schon recht fraglich.

Prüfen kannst Du das, indem Du erneut auf Wartung gehst und den Vorgang (nur für _post) immer wieder neu anwirfst. Hat der vorige Durchlauf geklappt, geschieht ab da der Aufruf jedesmal schneller und Du müsstest auch dann die Erfolgsmeldung bekommen (Table post checked = Status ok, table is already optimized/up to date - irgendwas in der Art).

[fenris]

Hy,

die Datenbank scheint völlig zerschossen - ich spiele gerade ein Backup ein, was zwar 3 Monate alt ist aber ohne Fehler war. Ich weiß nur noch nicht, wie sich das im Forum verhält, wenn ich nun eine alte Post Tabelle in eine sonst aktuelle VB Datenbank einspiele....
Die Frage die sich mir eigentlich für die Zukunft stellt - mache ich lieber kurze Backup Intervalle und riskiere einen evtl. Fehler mit zu sichern oder mache ich lieber längere Backup Intervalle ( wie aktuell ) und mir gehen halt immer so 3 Monate verloren. Mein Forum besitzt eine Gesamtkapazität von etwas über 120 GB - da kann man natürlich nicht unendlich Sicherungen machen.

Gruß

Frank

[The Coon]

Hy,
Mein Forum besitzt eine Gesamtkapazität von etwas über 120 GB

Und das ist jetzt wirklich kein Schreibfehler???? Sorry, will Dir wirklich nicht zu nahe treten oder Dich beleidigen. Frage ernsthaft! Und schließt das Attachments mit ein?

[Jaydee]

Darüber war ich auch gestolpert. Dazu müssten sich 1. die Anhänge fälschlicherweise in der Datenbank befinden (sofern sich die 120 GB auf die DB-Größe beziehen) und 2. das Forum älter als das gesamte öffentliche Internet sein, um solche gigantischen Größen zu erreichen.
Die Software besteht aus wenigen MB (entpackt) und der Content eines mittelgroßen Forums beläuft sich auf max. 1-2 GB, wenn es hoch kommt.

Selbst in einem Forum mit etwa 30.000 Usern und ca. 500.000 Beiträgen (Bestand seit 2002) erreiche ich diese _post Größe noch nicht.

Eventuell mal regelmäßig die Tabellen optimieren lassen, um sie von unnötigen Überhängen zu befreien und Probleme zu vermeiden.
Für Größen um die 120 GB und häufige Schreibzugriffe wäre eine MySQL Datenbank überhaupt nicht ausgelegt von der Verwaltungs-Struktur her.
Ist bestimmt einTipp - oder Interpretationsfehler.

[The Coon]

Um aber auf die Ausgangsfrage zurück zu kommen. Ich sichere meine DB täglich: ~ 200.000 Einträge = ~ 60 MB (exkl. Attachments). Gehe davon aus, dass ich das auch machen werde, wenn die Größe mal 120 MB erreichen sollte.

Allein schon bei vielen Zu- und Abgängen von Usern (bei mir zum Glück nicht so ...) kommt man doch sonst völlig ins schleudern.

[fenris]

Hy,

nein - nicht die Post Tabelle ist 120 GB
Das gesamte Forum hat eine Kapazität von um die 120 GB - dazu zählen natürlich auch die Anhänge die natürlich nicht in der Datenbak sind. Die Post Tabelle hat eine Größe von ca. 1 GB - das gesamte Forum hat eine Größe von über 120 GB.

Gruß

Frank

[Hoffi]

Also bei meiner 750MB Tabelle dauert eine intensive Reparatur inkl. Reindizierung auch mal locker zwei bis drei Stunden. Reparieren mittels phpMyAdmin kann man ab einer gewissen Größe direkt vergessen weil die PHP Laufzeit zu lange ist.

Bei der Meldung oben ist vermutlich die Tabelle post gelockt. Das heisst defitiv den mySQL Deamon zu stoppen und dann eine Intensive Reparatur ansetzen mittels myisamchk.

Gerade bei Reparaturen sollte man den Dienst stoppen, um keine neuen Fehler zu riskieren, denn wenn Schreibvorgänge reinkommen, während die Tabelle repariert wird, kann es noch schlimmer werden. Oder es wird gelockt, und dann stauen sich die ganzen Abfragen auf bis der Apache immer in ein Timeout rennt.