Restore von MySQL-InnoDB-Datenbanken
Gestern habe ich ja nach einem völlig unverständlichen Datenverlust (möglicherweise ist SuperDuper schuld) ein Time-Machine-Backup zurückkopieren müssen. Das Restore funktionierte gut — bis auf die MySQL-Datenbank. Diese war nach dem Wiederherstellen auf einem veralteten Stand. Allerdings konnte ich die aktuellen MySQL-Datendateien (die in /usr/local/mysql/data liegen) aus dem SuperDuper-Klon extrahieren. Meine Hoffnung war, dass der aktuellste Zustand der Datenbank wenigstens in diesen Datendateien enthalten war.
Ich musste also meine MySQL-Datenbank mit den Datendateien aus dem Klon starten. Es war mir aber zu riskant, die aktuellen Datendateien mit den Dateien aus dem Klon zu überschreiben. Stattdessen wollte ich in einer Kopie arbeiten. Ich kann mich erinnern, folgende Schritte durchlaufen zu haben (alle Befehle habe ich im Mac OS X Terminal eingegeben, da es sich um die Datenbank handelte, die ich lokal zum Entwickeln nutze). Die verwendete Datenbank ist MySQL 5.1.22-rc, die ich damals mit dem Package-Installer von mysql.org installiert hatte. Die Datenbank liegt in diesem Fall üblicherweise in /usr/local/mysql. Meine Backup-Festplatte war unter /Volumes/Backup eingehängt. Zuerst musste ich mit
sudo tar cv /Volumes/Backup/usr/local/mysql/ | tar x -C /Users/dh/Desktop/mysql
eine 1:1-Kopie der gesamten Datenbankinstallation aus dem Backup ziehen und auf meinem Desktop ablegen. Das tar-Kommando hat im Gegensatz zu cp den Vorteil, dass alle Berechtigungen beim Kopieren erhalten bleiben. Um Probleme mit Zugriffsrechten zu umgehen habe ich mit
sudo chown -R dh /Users/dh/Desktop/mysql
erst einmal alle Dateien in der Kopie meinem Benutzer (dh) übereignet. Nun musste ich dem MySQL-Server mitteilen, dass er die Datendateien aus /Users/dh/Desktop/mysql/data und nicht aus /usr/local/mysql/data verwenden sollte. Dazu muss man bei meiner Installation die Datei /private/etc/my.cnf editieren (Quelle):
[mysqld]
#altes tmpdir:
#tmpdir=/usr/local/mysql/tmp
#neues tmpdir
tmpdir=/Users/dh/Desktop/mysql/tmp
#neues datadir
datadir=/Users/dh/Desktop/mysql/data
Den MySQL-Server kann man dann aus dem Terminal mit dem Aufruf mysqld starten. Aus den Log-Meldungen auf der Konsole sollte man entnehmen können, dass er das richtige Data-Directory verwendet. Das hat bei mir jedoch noch nicht gereicht. Der Server hat die Tabelle (system_settings), die ich restaurieren wollte, nicht gefunden. Dann bin ich auf einen Hinweis gestoßen, wie MySQL zwingen kann, die InnoDB-Datendateien (ibdata und ib_logfile0, ib_logfile1) direkt auszulesen, um an die verlorenen Daten zu kommen:Man muss die Größe der Log-Dateien ermitteln und dann im folgenden Kommando angeben:
mysqld –innodb_log_file_size=5242880 –innodb_force_recovery=6
Mit dieser Methode konnte ich den Server starten und dann mit mysqldump in Ruhe alle fehlenden Records aus der Datenbank extrahieren. Cool!
Am Ende hat sich der SuperDuper-Klon also doch noch einmal bewährt! Meine redundante Sicherungsstrategie werde ich auch in Zukunft beibehalten. Die gesamte Ausfallzeit betrug dadurch nur etwa 2,5 Stunden. Wenn der SuperDuper-Klon nun auch noch bootfähig gewesen wäre, hätte ich sogar komplett ohne Ausfallzeit weiterarbeiten können.