MySQL-Tabellen fehlen/sind nach der Neuerstellung beschädigt

Question

Gestern habe ich meine MySQL-Datenbanken in eine SQL-Datei kopiert und die Datei ibdata1 umbenannt. Anschließend habe ich sie neu erstellt, die SQL-Datei importiert und die neue ibdata1-Datei in mein MySQL-Datenverzeichnis verschoben und die alte gelöscht.

Ich habe es schon einmal ohne Probleme gemacht, aber diesmal stimmt etwas nicht. Wenn ich die (persönlichen, nicht MySQL-Konfigurations-)Datenbanken untersuche, sind sie alle da, aber sie sind leer … irgendwie. Das Datenverzeichnis enthält immer noch die .ibd-Dateien mit dem richtigen Inhalt und ich kann die Tabelle anzeigenListein den Datenbanken, aber nicht in den Tabellen selbst. (Ich habe „Datei pro Tabelle“ aktiviert und verwende InnoDB als Standard für alles.)

Zum Beispiel mit demURLsDatenbank und ihreURLsTabelle, kann ich erfolgreich mysql.exe oder phpMyAdmin öffnen und use urls;. Ich kann sogar show tables;die erwartete Tabelle sehen, aber wenn ich dann versuche, describe urls;oder select * from urls;, beschwert es sich, dass die Tabelle nicht existiert (obwohl sieNurhat es aufgelistet). (Der MySQL-Administrator listet die Datenbanken auf, listet aber nicht einmal die Tabellen auf, das zeigt an, dass die Datenbanken völlig leer sind.)

Das Problem ist jetzt, dass ich die SQL-Datei bereits gelöscht habe (und sie auch nach Durchforsten meiner Festplatte nicht wiederherstellen kann). Ich versuche also, einen Weg zu finden, diese Datenbanken/Tabellen zu reparieren. Ich kann die Tabellenreparaturfunktion nicht verwenden, da sie beschwert, dass die Tabelle nicht existiert, und ich kann sie nicht sichern, da sie erneut beschwert, dass die Tabellen nicht existieren.

Wie gesagt, die Daten selbst sind noch in den .ibd-Dateien vorhanden und die Tabellennamen sind vorhanden. Ich brauche nur eine Möglichkeit, MySQL dazu zu bringen, zu erkennen, dass die Tabellen in den Datenbanken vorhanden sind (ich kann die Spaltennamen der betreffenden Tabellen mithilfe eines Hex-Editors in der ibdata1-Datei finden).

Irgendeine Idee, wie ich diese Art von Beschädigung reparieren kann? Es macht mir nichts aus, die Ärmel hochzukrempeln, mich ins Zeug zu legen und eine Reihe von Schritten zu unternehmen, um das Problem zu beheben.

Vielen Dank.

Answer 1

Nun, ich habe eine Menge Sachen ausprobiert und eine Menge Befehle, Schalter und Strukturen untersucht (nicht überraschend waren die MySQL-Dokumente am hilfreichsten, wenn auch umfangreich – wie eine Nadel im Heuhaufen). Schließlich funktionierten einige meiner Tricks (es stellte sich heraus, dass andere auf dieselben Tricks gekommen waren, obwohl ich die beiden Hauptteile – Wiederherstellen der Tabellenstruktur und Wiederherstellen der Daten – nicht an einem Ort gesehen hatte, also poste ich sie hier zusammen).

Ich musste die IBDATA1-Datei neu erstellen. Leider erkennt der Daemon beim Ausführen die Datenbanken (die Verzeichnisse), erkennt aber nicht die Innodb-Tabellen darin (die IBD/FRM-Dateien). Also habe ich Folgendes getan:

1. Leeren Sie das Datenverzeichnis (oder verschieben Sie das Original und erstellen Sie ein leeres)
2. Führen Sie den Daemon aus und lassen Sie ihn eine neue, leere IBDATA1-Datei erstellen
3. Importieren Sie die Systemtabellen mit den SQL-Skripten in…\MySQL\share
4. Erstellen Sie eine Dummy-Datenbank und eine Tabelle mit demselben Namen
5. Kopieren Sie die ursprüngliche FRM-Datei
6. Verwenden Sie entweder DESCRIBEoder besser, SHOW TABLE CREATEum die Tabellenstruktur zu extrahieren
7. Als nächstes habe ich DISCARD TABLESPACEauf dem Tisch
8. Über die ursprüngliche IBD-Datei kopiert
9. Dann benutzte ichIMPORT TABLESPACE
10. Schließlich habe ich den Daemon erneut ausgeführt mitinnodb-force-recovery=6
11. Und ich rannte los mysqldump, um die Strukturen und Daten zu extrahieren

Natürlich lief es nicht immer reibungslos. Einige Tabellen funktionierten einwandfrei, aber bei manchen musste ich die Tabelle und die Datenbank nach dem löschen SHOW TABLE CREATEund die Tabelle damit neu erstellen, bevor ich versuchte, die Daten zu importieren. Andere funktionierten nicht einmal so weit, und ich musste die Kommentare und Namen der Spalten manuell mit einem Hex-Editor aus der FRM-Datei abrufen (obwohl es ein Glücksspiel war, die Datentypen und Attribute, Schlüssel usw. herauszufinden). Außerdem gab es viele – zu viele – Neustarts von Daemon und Client.

(Ich suche immer noch nach einem Tool, das FRM/IBD-Dateien direkt analysiert (oder zumindest die Tabellenstruktur einer FRM-Datei anzeigt), aber es sieht so aus, als ob sich niemand die Mühe gemacht hat, sie „zurückzuentwickeln“, obwohl es Open Source ist und die Dateiformate öffentlich verfügbar sind. Es scheint, als ob alle mit den offiziellen MySQL-Tools zufrieden sind – was eine großartige Gelegenheit für Datenrettungsfirmen und proprietäre/kommerzielle Tools darstellt.)

Der Schlüssel war, immer mit dem absoluten Minimum zu arbeiten (z. B. nur mit dem MySQL-Verzeichnis, also mit den Systemtabellen). Das bedeutete zwar, dass die Dinge dadurch einfacher und leichter zu handhaben waren, aber leider bedeutete es auch, dass jeweils nur eine Tabelle wiederhergestellt werden musste – was für mich kein großes Problem war, für manche Leute aber schon.

Wie dem auch sei, von den vielen MySQL-Wiederherstellungsseiten im Internet, die ich in den letzten Tagen gesehen habe, waren einige recht nützlich, und ich werde sie hinzufügen, sobald ich meinen Verlauf durchforstet habe, um sie auszugraben.


Ich hoffe, dies kann anderen in einer ähnlichen Situation helfen.

Answer 2

Wenn alle Tabellen und Datenbanken aufgelistet werden können, bedeutet das normalerweise, dass die *.frm-Dateien vorhanden sind. Das bedeutet nicht, dass Daten für sie vorhanden sind. Haben Sie versucht, Ihren mysqld-Prozess zu starten?InnoDB-Wiederherstellung erzwingen? Wenn nicht, versuchen Sie es. Oder ja, was sagt das MySQL-Protokoll beim Start?

Versuchen Sie danach nie wieder, derartige Backups zu verwenden.