PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : MySQL geschrottet



~Gh05t~
14.02.07, 11:32
Hi all,
ich habe ein Problem mit meinem MySQL-Server (läuft auf Debian testing). Nach einem Update (auf mysql 5.0.32) war ein Table gecrashed und ich wollte ihn wieder reparieren. Da ich keine Ahnung davon habe habe ich zunächst mal das ganze Daten-Verzeichnis der Datenbank in der die Tabelle war kopiert.
Dann habe ich mit myisamck versucht die Tabellen wieder herzustellen. Leider ist da wieder irgend etwas schief gelaufen, also wollte ich das vorher gesicherte Verzeichnis einfach wieder zurückspielen.
Danach war meine Datenbank laut phpmyadmin leer.
Was man ich nu?

marce
14.02.07, 12:15
Infos posten. Vor allem so Dinge wie Verzeichnis und Dateirecht, Gruppen, User, was Du _genau_ getan hast, evtl. Fehlermeldungen, an der Konsole probieren, ...

MiGo
14.02.07, 12:44
Da ich keine Ahnung davon habe habe ich zunächst mal das ganze Daten-Verzeichnis der Datenbank in der die Tabelle war kopiert.
Und das war welches Verzeichnis?

Leider ist da wieder irgend etwas schief gelaufen
Eine Aussage, die an Präzision schier nicht zu überbieten ist :)
Das nächste mal: Lieber hier die Fehlermeldung posten, irgend ein MySql-Kundiger wird schon was dazu wissen.

Danach war meine Datenbank laut phpmyadmin leer.
Was man ich nu?
Hast du das gemacht, während Mysql noch lief? Hast du danach Mysql mal neu gestartet?

~Gh05t~
14.02.07, 15:35
Ok, sorry. Etwas detailierter:

Mein MySQL-Datenverzeichnis ist /daten/srv/mysql. Darin sind die Standart-Datenbanken mysql, test und diverse Dateien. Alle gehören mysql:mysql .
Außerdem ist hier noch ein Verzeichnis "wikidb", das ist die Datenbank von der ich rede. Diesen Ordner habe ich kopiert, und zwar mit "cp -a wikidb ~/".
Dann habe ich die Tabelle mit "myisamchk -o <dateiname>" versucht zu reparieren, dann hatte ich ein paar Fehler wegen doppelter Keys. Da ich ja ein Backup habe, dachte ich ich könnte einfach mal rumprobieren, also hab ich einfach ma manuell rumgebastelt. Das half aber nichts, das meinte ich mit schief gelaufen ;)
Also habe ich das modifizierte Verzeichnis mit "mv wikidb ~/wikidb_defekt" verschoben und mein Backup mit "cp -a ~/wikidb ." wieder zurück kopiert. Den MySQL server habe ich dafür nicht angehalten, als die Tabelle jedoch leer war habe ich ihn mal neu gestartet.

Jinto
14.02.07, 23:05
- Ausgangsversion von MySQL war (vor dem Upgrade)?
- upgrade lief problemlos durch?
- welche Angaben hast du während des upgrade gemacht?
- Verwendeter Datenbanktyp war?
- Du lässt die DB laufen, während du die geöffneten Daten unterm Hintern wegziehst? => Wie wäre es mit anhalten von MySQL bevor du ihm neue Tabellen unterschiebst?

rudi_m
15.02.07, 00:28
habe Dein posting nicht komplett gelesen, aber

Fehler wegen doppelter Keys
Soetwas kann an in der neuen Version veraenderten Datentypen liegen. Bei den (VAR)CHARs hat sich glaube zum Beispiel etwas bei der Handhabung der Gross/Klein-Schreibung geandert, was u.U. zu duplicate keys fuehren kann.

Besser uebrigens vor dem update einen richtigen mysqldump machen (so wie es auch die mysql Doku empfiehlt).

Am einfachste ist es vielleicht die alte mysql Version + alte tables wieder einzuspielen, tables checken, mysqldumpen, ubdaten, dump einspielen.

~Gh05t~
15.02.07, 01:45
hmmm... also. Die alte Version weiß ich nicht, kann aber nicht so alt gewesen sein. Update-Nachrichten kenne ich auch keine, da update mit "apt-get update && apt-get upgrade" mache und nur bei Fehlern nachsehe. Die gabs nicht (update lief ohne probleme durch).
Ich hatte es durchaus schon öffter, das bei einem MySQL-Update ein Table als "crashed" markiert wurde oder sonst was kaputt gegangen ist. Außer der einen Tabelle in der einen DB ging ja auch alles noch.
Welcher DB-Typ das ist weis ich nicht, ist ne DB von nem MediaWiki.

Tjo, bzgl. Anhalten: Wie gesagt, mit Datenbanken kenne ich mich nicht sonderlich aus. Und man kommt ja auch nicht auf die Idee den Apache anzuhalten wenn man die index.html im doc-root ändert ;)
Jetzt bin ich schlauer :D

Ich habe noch ein Backup der gesamten DB in SQL-Format, das habe ich vor 2 Wochen gemacht. Da ich das Wiki nur privat zu Dokumentationszwecken nutze und da nicht allzuviel passiert ist in den letzten 2 Wochen werde ich glaube einfach darauf aufbauen, was hilft es mir wenn ich mehr Zeit in das widerherstellen der DB investiere als das Nachtragen der Daten dauern würde. :rolleyes:

rudi_m
15.02.07, 02:42
hmmm... also. Die alte Version weiß ich nicht, kann aber nicht so alt gewesen sein. Update-Nachrichten kenne ich auch keine, da update mit "apt-get update && apt-get upgrade" mache und nur bei Fehlern nachsehe.
Da gibts sicher irgendwo log wo drinsteht wann was installiert wurde.

Tjo, bzgl. Anhalten: Wie gesagt, mit Datenbanken kenne ich mich nicht sonderlich aus.
Warum upgradest Du dann ueberhaupt?
Ich mache das nur wenn ich lese, dass is interessante neue features gibt.


Und man kommt ja auch nicht auf die Idee den Apache anzuhalten wenn man die index.html im doc-root ändert ;)
Jetzt bin ich schlauer :D

Ich habe noch ein Backup der gesamten DB in SQL-Format, das habe ich vor 2 Wochen gemacht. Da ich das Wiki nur privat zu Dokumentationszwecken nutze und da nicht allzuviel passiert ist in den letzten 2 Wochen werde ich glaube einfach darauf aufbauen, was hilft es mir wenn ich mehr Zeit in das widerherstellen der DB investiere als das Nachtragen der Daten dauern würde. :rolleyes:

rudi_m
15.02.07, 02:54
hmmm... also. Die alte Version weiß ich nicht, kann aber nicht so alt gewesen sein. Update-Nachrichten kenne ich auch keine, da update mit "apt-get update && apt-get upgrade" mache und nur bei Fehlern nachsehe.
Da gibts sicher irgendwo logfiles wo drinsteht wann was installiert wurde.


Wie gesagt, mit Datenbanken kenne ich mich nicht sonderlich aus.
Warum upgradest Du dann ueberhaupt?
Ich mache das nur wenn ich lese, dass interessante neue features gibt die ich gebrauchen kann.
Hier steht wie man mysql upgraded
http://dev.mysql.com/doc/refman/5.0/en/upgrade.html

~Gh05t~
15.02.07, 11:00
*räusper*
Dieser Server ist ein Home-Server. Wenn ich da für jedes popelige Paket einen riesen Aufstand probe wenn es um Update geht (d.h. Buchführen, Recherchieren, System so modifizieren, dass nur bestimmte Updates autimatisch laufen) dann ist das für meine Begriffe ein wenig übertrieben.

Ich habe mich für Debian entschieden weil es zu der Zeit als ich es installiert habe noch keine server-fähige Ubuntu-Version gab und mich u.a. das einfache Update-System überzeugt hat. Also vertraue ich meinem Distributor, dass der die Updates so macht, dass ich einfach nur "update" sagen muss und das auch funktioniert. Egal mit welchen Paketen.

Sonst hätte ich auch mein LFS drauflassen können :ugly:

Außerdem ging es hier nicht von version 2 nach 7 sondern eher von 5.031 -> 5.032

Tomek
15.02.07, 11:08
Ich habe momentan ähnliche Probleme mit dem MySQL-Server in Debian Testing. Nach jedem Neustart von MySQL meldet das Initskript kaputte Tabellen, die man reparieren muss. Dieses Problem ist mit dem libc6-Update vor einigen Tagen behoben worden, allerdings nur auf einem 32-Bit-System. Auf 64-Bit-Systemen besteht das Problem weiterhin. Zudem gibt es noch ein Problem, wiederrum nur auf 64-Bit-Systemen, so dass beim Klick auf den Kategorie-Manager im Joomla! CMS 1.0.12 der MySQL-Server direkt abstürzt. Mit der MySQL-Version 5.0.30-3 lief alles einwandfrei.

Siehe dazu folgende Reports im Debian-BTS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403721
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410606
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404929
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410821

Tomek
16.02.07, 11:44
Die Versionen 5.0.32-4 und 5.0.32-5 beheben die Probleme und sind in Unstable verfügbar:
http://packages.qa.debian.org/m/mysql-dfsg-5.0.html