Ich bräuchte mal etwas Hilfe bei der Rekonstruktion einer SQL-Datenbank. Eines vorneweg. Habe eine alte Datenbank, die ich gerne wieder verwenden möchte. Das Ganze ist privat und nicht lebenswichtig, wäre aber schon, wenn ich es wieder zum Laufen bekomme. Habe damals das Verzeichnis mit der Datenbank kopiert. Nicht explizit exportiert oder das Stamm-Verzeichnis, sondern nur einfach stumpf kopiert. Zu diesem Zeitpunkt wusste ich noch nicht, dass einfach nur das Verzeichnis kopieren nicht ausreichend war. Also die ib_logfiles und ibdata sind nicht mehr vorhanden. Was ich noch habe sind die frm und ibd Dateien. Nach ein bisschen Recherche habe ich herausgefunden, dass es doch nicht so ganz aussichtslos ist und man durchaus noch zumindest Teile davon wiederherstellen kann. Die Datensätze selbst sind ja noch vorhanden (kann ich in einem Texteditor sehen, nur eben ohne jegliche Zuordnung). Verwende openSuse 15.5, MySQL 5.7. Unter phpMyAdmin wird mir angezeigt, dass keine Tabellen für die Datenbank existieren. Habe auch schon versucht eine neue Datenbank zu erstellen und das ineinander zu kopieren. Entweder wird der Vorgang gar nicht erst zugelassen oder bringt keine Änderung. Beitrag "MySQL: Datenbank-Files "unterschieben"?" habe ich auch versucht, kann aber nichts exportieren. PS: Es handelt sich um eine EleLa Datenbank, wenn das zur Struktur hilfreich sein sollte. Habe die MySQL Utilities installiert und nach Anleitung soll ich folgenden Befehl ausführen: mysql.FRM --diagnostic path filename.frm path „mysql.FRM“ gibt es nicht und was mich ebenso verwirrt und nicht weiß, was ich damit machen soll, ist „path“. Vermutlich der Pfad zur Datei nur warum zweimal? Kann mir das jemand erklären und evtl. etwas unter die Arme greifen?
Michael D. schrieb: > Ich bräuchte mal etwas Hilfe bei der Rekonstruktion einer SQL-Datenbank. Einer MySQL Datenbank. SQL ist eine Abfragesprache die die meisten Datenbanken verstehen. > Habe damals das Verzeichnis mit der Datenbank kopiert. > Also die ib_logfiles und ibdata sind nicht mehr vorhanden. > Was ich noch habe sind die frm und ibd Dateien. Dann sieht es schlecht aus. War der Server womöglich auch noch am Laufen, als du die Daten kopiert hast? Mal eine Aufzählung der Probleme, die dich erwarten: 1. ibdata enthält das data dictionary, also die Information, welche Tabellen es gibt und was die für Spalten haben. Hast du nicht. 2. ib_logfile* enthält das Redo-Log. Da stehen alle Transaktionen drin, die die Datenbank gemacht hat. Wie jede ernstzunehmende Datenbank schreibt MySQL Änderungen nicht direkt auf Platte, sondern ändert die Daten erstmal nur im RAM und schreibt ins Redo-Log alles, was es wissen muß um die Änderung nochmal zu machen (z.B. wenn der Server abstürzt). Erst beim Checkpoint werden die Daten auf die Platte geschrieben. Dein Redo-Log ist weg. Alle Schreibvorgänge seit dem letzten Checkpoint können damit weg sein. Zu 1. gibt es Hoffnung. Die Daten stehen nämlich noch einmal im FRM File. Allerdings nicht in einer Form, die InnoDB direkt verwenden kann. Das Problem 2. ist schwerwiegender. Da gibt es prinzipiell keine Hilfe. Weg ist weg. Du kannst den Datenbestand im IBD File recovern und hoffen, daß die Daten aktuell (genug) und konsistent sind. Die prinzipielle Vorgehensweise haben Leute schon dokumentiert. LMGTFY https://www.google.com/search?q=recover+from+FRM+and+IBD+file Das Thema ist zu komplex für dieses Forum. Wenn du mit den Anleitungen nicht klar kommst, frage besser in einen MySQL Forum.
Axel S. schrieb: > Dann sieht es schlecht aus. War der Server womöglich auch noch am > Laufen, als du die Daten kopiert hast? Kann sein, kann ich aber nicht mehr genau sagen, da schon zu lange her. Axel S. schrieb: > 1. ibdata enthält das data dictionary, also die Information, welche > Tabellen es gibt und was die für Spalten haben. Hast du nicht. Richtig Axel S. schrieb: > Zu 1. gibt es Hoffnung. Die Daten stehen nämlich noch einmal im FRM > File. Allerdings nicht in einer Form, die InnoDB direkt verwenden kann. Das hoert sich schon mal gut an. Axel S. schrieb: > Das Problem 2. ist schwerwiegender. Da gibt es prinzipiell keine Hilfe. > Weg ist weg. Du kannst den Datenbestand im IBD File recovern und hoffen, > daß die Daten aktuell (genug) und konsistent sind. Damit kann ich im Zweifel leben. Es ist nur eine kleine Datenbank mit relativ wenig Zugriffen. Also nicht so relevant falls wirklich was fehlen sollte. Axel S. schrieb: > Die prinzipielle Vorgehensweise haben Leute schon dokumentiert. LMGTFY > > https://www.google.com/search?q=recover+from+FRM+and+IBD+file Das habe ich bereits versucht, aber nichts Passendes gefunden. Jedenfalls nichts, das mir weiterhelfen würde. Axel S. schrieb: > Das Thema ist zu komplex für dieses Forum. Wenn du mit den Anleitungen > nicht klar kommst, frage besser in einen MySQL Forum. Ich dachte, ich versuche es hier auch mal, da hier auch oft kompetente Hilfe angeboten wird und es dieses Problem schon mal gab. Aber zumindest schon mal Danke für deine aufschlussreichen Erklärungen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.