Innodump stellt rows aus Offline-Dateien relationaler Datenbanken wieder her
Innodump kann rows und Table-Definitionen direkt aus Offline-Datendateien quelloffener relationaler Datenbanksysteme extrahieren, die von vielen Webanwendungen genutzt werden, ohne einen Database Server zu starten. Das experimentelle Open-Source-Tool wurde in einem Percona-Artikel vom 28. Oktober 2026 vorgestellt, unterstützt InnoDB, MyISAM und MyRocks, auch bekannt als RocksDB, und ist für Recovery, Untersuchungen und selektive Extraktionen gedacht, nicht als Ersatz für ordnungsgemäße Backups.
Das Tool kann ein vollständiges data directory, einen Datenbankordner, eine einzelne Datei oder tables verarbeiten, die in gemeinsam genutzten, allgemeinen oder tabellenspezifischen tablespace gespeichert sind. Ein tablespace ist eine Datei oder ein Speicherbereich, in dem eine Database Engine tables und indexes speichert. Innodump liest das gespeicherte Table-Schema und die rows und exportiert sie anschließend als SQL oder als tabulatorgetrennte Werte, bezeichnet als TSV. Die TSV-Ausgabe ist mit den Dump-Utilities der Database Shell kompatibel, sodass die extrahierten Daten effizient in eine andere instance geladen werden können.
Mögliche Einsatzzwecke sind die Rettung unbeschädigter rows nach einer Beschädigung, die Prüfung, welche Daten in einem Backup noch lesbar sind, die Extraktion ausgewählter tables aus einem vollständigen Backup, die Vorbereitung von Staging- oder Qualitätssicherungssystemen, die Wiederherstellung kürzlich gelöschter rows, die Suche in alten Backups für forensische Untersuchungen und die Migration von Daten aus älteren Datenbankversionen. Das Tool kann gewöhnliche data directories ebenso untersuchen wie binäre Backups, darunter Snapshots von Storage Volumes und XtraBackup-Kopien.
Dies ist keine weitere Backup-Methode. Moderne Engines verwenden ACID-Regeln, die die Zuverlässigkeit von Transactions schützen, sowie MVCC, also multiversion concurrency control, wodurch Transactions geeignete Versionen veränderlicher Daten sehen können. Das direkte Lesen von Dateien bildet nicht alle Arbeitsschritte nach, die erforderlich sind, um einen konsistenten Datenbankzustand herzustellen. Spezialisierte Backup-Software kann dem redo log folgen, also der Aufzeichnung der Änderungen, die während der Recovery benötigt werden, und backup locks verwenden, um das Kopieren von Dateien zu koordinieren. Eine rohe Extraktion kann daher Daten enthalten, die zu keinem Zeitpunkt einen konsistenten Gesamtzustand dargestellt haben. Point-in-time recovery, kurz PITR, bleibt wichtig, da damit eine Datenbank anhand von Backups und aufgezeichneten Änderungen auf einen ausgewählten Zeitpunkt zurückgesetzt werden kann.
Die Offline-Extraktion wird besonders relevant, wenn eine Beschädigung verhindert, dass der Database Server online bleibt. Ein Server kann sich nach dem Erkennen schwerwiegender Schäden absichtlich herunterfahren, um eine Verschlimmerung zu vermeiden. Eine Beschädigung in einem secondary index lässt sich manchmal durch den Neuaufbau dieses index beheben. Schäden am clustered index, der Table-rows in der Reihenfolge des Primary Key enthält, können die Engine jedoch jedes Mal zum Absturz bringen, wenn sie die betroffene page erreicht. Eine herkömmliche Recovery wird dann langsam, weil jeder Versuch, eine beschädigte page zu lesen, einen weiteren Serverneustart erzwingen kann.
Die Option skip-corrupted von Innodump meldet eine beschädigte data page und fährt mit der nächsten fort. Im Beispiel von Percona mit innodump 0.8.1 enthielt eine 130.023.424 Byte große InnoDB-Datei 7.936 pages mit jeweils 16.384 Byte sowie Metadaten, die von der quelloffenen Datenbank in Version 8.0.33 geschrieben worden waren. Das Tool erkannte auf page 100 des primary index eine Abweichung in den Bytes der log sequence number. Es übersprang diese page und schrieb 100.680 rows. Dies zeigt, wie ein Offline-Durchlauf lesbare records wiederherstellen kann, ohne einen laufenden Server wiederholt zum Absturz zu bringen.
Der examine mode liest und decodiert rows, ohne einen Export zu erstellen. Er meldet die gefundenen tables und rows sowie Beschädigungen, die verhindern, dass records decodiert werden. Ein demonstrierter Scan umfasste sechs InnoDB-tables mit 29 rows und eine MyRocks-table mit 1.000.000 rows, insgesamt also 1.000.029 rows. Außerdem wurden 129 ältere Table-Definition-Dateien ohne passende tabellenspezifische Dateien oder Einträge im gemeinsam genutzten InnoDB-Dictionary gefunden. Diese könnten Nicht-InnoDB-tables, views oder tables in einem allgemeinen tablespace dargestellt haben und wurden deshalb nicht untersucht. Der Modus liest nur den clustered index und kann Beschädigungen nicht erkennen, die ausschließlich secondary indexes betreffen. Percona empfiehlt, einen Scan auf InnoDB-Beschädigungen mit dem offiziellen checksum utility zu beginnen. Der engere Zweck von innodump besteht darin, festzustellen, was tatsächlich gelesen und wiederhergestellt werden kann.
Durch selektive Extraktion lässt sich die Wiederherstellung eines vollständigen Backups vermeiden, wenn nur wenige Datenbanken benötigt werden. In einem Beispiel exportierte innodump aus einem einzigen Datenbankverzeichnis fünf tables mit insgesamt 1.359.877 rows. Die Ausgabe umfasste komprimierte TSV-Dateien und unterstützende Dateien, die mit der Dump-Ladefunktion der Database Shell kompatibel waren. Dies kann den Aufwand für die Erstellung einer Nicht-Produktionskopie verringern, wenn keine exakte Konsistenz zu einem bestimmten Zeitpunkt erforderlich ist.
Das Lesen eines aktiven data directory birgt erhebliche Konsistenzrisiken. Dirty pages, also Änderungen, die sich noch im Arbeitsspeicher befinden, sind möglicherweise noch nicht auf den Datenträger geschrieben worden; eine page kann während eines Schreibvorgangs erfasst werden; rows können fehlen, veraltet oder falsch markiert sein; und kürzlich in einem gemeinsam genutzten Bereich erstellte tables können fehlen. Diese Einschränkungen können für eine vorübergehende Staging-Kopie akzeptabel sein, nicht jedoch für eine maßgebliche Recovery oder eine Produktionsmigration.
Um die Auswirkungen auf ein Live-System zu reduzieren, bietet innodump ein input and output limit zur Begrenzung des Datenträgerdurchsatzes sowie die Option direct input and output, mit der der page cache des Betriebssystems umgangen wird. Dadurch wird vermieden, dass der Cache mit nur einmal gelesenen Daten gefüllt wird, und das Risiko sinkt, dass das Betriebssystem länger nicht verwendeten Anwendungsspeicher in den swap verschiebt. Der Artikel empfiehlt außerdem, die CPU-Priorität mit nice zu senken. In einem Test, bei dem 1.500.000 rows aus einer 228 MB großen table mit zstd-Komprimierung exportiert wurden, dauerte ein uneingeschränkter Durchlauf 1,726 Sekunden und hinterließ 192,1 MB im page cache. Ein auf 30 MB pro Sekunde begrenzter Durchlauf mit direct input and output dauerte 9,241 Sekunden, hinterließ jedoch keine Dateidaten im Cache.
InnoDB kann gelöschte records ebenfalls für kurze Zeit wiederherstellbar lassen. Beim Löschen wird eine row zunächst markiert, statt ihr Speicherplatz sofort überschrieben zu werden. Wenn nachfolgende Schreibvorgänge diesen Speicherplatz noch nicht wiederverwendet haben, kann der record möglicherweise weiterhin decodiert werden. Die Option deleted-only exportierte 2.100 als gelöscht markierte rows aus der Beispiel-table. Eine Recovery ist nicht garantiert, und die Möglichkeit kann verschwinden, sobald normale Schreibvorgänge den Speicherplatz wiederverwenden.
Innodump bleibt ein experimentelles persönliches Projekt und ist keine offiziell unterstützte Percona-Software. Seine größte Stärke liegt in der Verwendung als letztes Hilfsmittel oder als Untersuchungs-Utility zusammen mit getesteten Backups, nicht als Nachweis dafür, dass Backups intakt oder konsistent sind. Für Organisationen, die prüfen, wo geschützte Datendienste betrieben werden können, stellt AEU Data europäische Cloud- und Dateninfrastruktur bereit. Die Recovery-Bereitschaft hängt jedoch weiterhin davon ab, dass ein angemessener Backup-Prozess gepflegt und getestet wird.