Der Schlüssel zu einem sicheren Datenbankmanagement sind regelmäßige Backups.

InnoDB Hot Backup ist ein Online-Backup-Tool mit dem Sie eine InnoDB-Datenbank bei laufendem Betrieb sichern können. InnoDB Hot Backup verlangt nicht, dass Sie die Datenbank herunterfahren, setzt keine Sperren und stört nicht die normale Datenbankverarbeitung. InnoDB Hot Backup ist ein kostenpflichtiges (kommerzielles) Add-on, das pro Jahr und pro MySQL-Server-Computer €390 kostet. Genauere Informationen und Screenshots finden Sie unter InnoDB Hot Backup home page.

Wenn Sie in der Lage sind, Ihren MySQL-Server herunterzufahren, können Sie auch ein Binär-Backup aller Dateien erstellen, die InnoDB zur Verwaltung seiner Tabellen benötigt. Gehen Sie folgendermaßen vor:

Da die Replikation mit InnoDB-Tabellen funktioniert, können Sie die Replikationsfähigkeiten von MySQL nutzen, um in Hochverfügbarkeitsumgebungen eine Kopie Ihrer Datenbank zu halten.

Zusätzlich zu den Binär-Backups sollten Sie auch regelmäßig mit mysqldump Dump-Kopien der Tabellen anlegen, da eine Binärdatei beschädigt werden kann, ohne dass man es merkt. Dump-Dateien hingegen werde in Textdateien gespeichert, die für Menschen lesbar sind. So lassen sich Schäden leichter erkennen. Außerdem ist die Gefahr einer ernsten Datenkorruption geringer, da das Format einfacher ist. mysqldump besitzt zudem die --single-transaction-Option, mit der Sie konsistente Snapshots anlegen können, ohne andere Clients auszusperren.

Um überhaupt in der Lage zu sein, eine InnoDB-Datenbank aus dem Binär-Backup wiederherzustellen, müssen Sie den MySQL-Server mit eingeschaltetem Binär-Logging betreiben. Dann können Sie das Binärlog auf die Datenbanksicherung übertragen, um eine Point-in-Time-Recovery zu fahren:

mysqlbinlog yourhostname-bin.123 | mysql

Um den MySQL-Server nach einem Absturz wiederherzustellen, müssen Sie ihn lediglich neu starten. InnoDB schaut automatisch in die Logs und versetzt die Datenbank wieder in den aktuellen Zustand (Roll-forward). InnoDB rollt unbestätigte Transaktionen, die zum Zeitpunkt des Absturzes anhängig waren, automatisch zurück. Während der Wiederherstellung zeigt mysqld so etwas wie dieses an:

InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 13674004
InnoDB: Doing recovery: scanned up to log sequence number 0 13739520
InnoDB: Doing recovery: scanned up to log sequence number 0 13805056
InnoDB: Doing recovery: scanned up to log sequence number 0 13870592
InnoDB: Doing recovery: scanned up to log sequence number 0 13936128
...
InnoDB: Doing recovery: scanned up to log sequence number 0 20555264
InnoDB: Doing recovery: scanned up to log sequence number 0 20620800
InnoDB: Doing recovery: scanned up to log sequence number 0 20664692
InnoDB: 1 uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no 16745
InnoDB: Rolling back of trx no 16745 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections

Wenn Ihre Datenbank beschädigt wurde oder Ihre Festplatte abstürzt, müssen Sie ein Backup zur Wiederherstellung verwenden. Sind Schäden aufgetreten, müssen Sie ein Backup suchen, das unbeschädigt ist. Nach der Wiederherstellung der Sicherungsdateien aus dem Backup müssen Sie mit mysqlbinlog und mysql die Änderungen, die nach dem Backup eingetreten sind, aus den Binärlogs anwenden.

In manchen Fällen, in denen Daten beschädigt wurden, reicht es aus, die beschädigten Tabellen zu dumpen, zu löschen und neu zu erzeugen. Mit der SQL-Anweisung CHECK TABLE finden Sie die meisten Schäden heraus, allerdings nicht jede nur denkbare Art von Datenkorruption. Der innodb_tablespace_monitor prüft die Integrität des Dateiraum-Managements in den Tablespace-Dateien.

Manchmal ist ein scheinbarer Datenbankschaden in Wirklichkeit ein Schaden, den das Betriebssystem an seinem eigenen Datei-Cache verursacht hat, während die Daten auf der Festplatte nach wie vor in Ordnung sind. Am besten versuchen Sie als Erstes, den Computer neu zu starten. So können Sie Fehler eliminieren, die nur scheinbar einen Schaden an Datenbankseiten verursachten.