Um mit einer Datenbank keinen Schiffbruch zu erleiden, treffen wir im Betrieb Vorsorgemaßnahmen. Insbsondere entwickeln wir ein Backup-Konzept, welches uns im Notfall als Retungsboot nützlich sein soll. Ein gutes Backup-Konzept wird maßgeblich hinsichtlich zweier Parameter gemessen:

• RTO (Recovery time objective): Wie lange dauert es, bis die Datenbank wieder läuft?
• RPO (Recovery point objective): Unter welchem Datenverlust muss ich schlimmsten Fall erleiden?
  

Mast und Shotbruch

Der schlimmste Fall, der bei einem Crash-Szenario eintreten kann, ist, dass das gerade aktive Transaktionsprotokoll (bei MySQL Binary-Log) nicht mehr verfügbar ist (z.B. durch Datei-Korruption oder Totalverlust des Servers). Denn gerade diese Daten sind noch nicht Bestandteil des letzten Backups, bzw. konnten auch noch nicht über einen nachgelagerten Kopiermechanismus (sichere alle abgeschlossenen (!) Binary-Logs alle fünf Minuten) gesichert werden.

Kein Flottenkommando

Natürlich kann man die Anforderungen nach keinem oder einem sehr geringen Datenverlust (PRO) einer Replikation und/oder einem Cluster lösen. Solche Ansätze benötigen aber einen intensiveren Hardware-Einsatz und verhalten sich komplexer (komplizierter?) in der Administration.

Rette sich, wer kann

Es gibt jedoch auch Möglichkeiten jenseits der "Ozeanriesen". Mit dem aus dem Backup-Umfeld bekannten Tool "mysqlbinlog" können die Transaktionsprotokolle auch "remote" gelesen und kopiert werden. Dazu loggt man sich mit dem Client von einem entfernten System (Backupserver) auf die Ziel-Datenbank ein und liest die Binary-Logs der zu sichernden Datenbank mit

Neben den üblichen Client-Informationen (User, Host, ...) geben wir "mysqlbinlog" eine Pfadangabe (--result-file) zur Ablage der kopierten Binary-Logs und den Startpunkt an. Dieser Startpunkt benennt das Binary-Log des DB-Servers, ab dem alle weiteren Logs gelesen und kopiert werden sollen. Mit dem Parameter "--stop-never" weisen wir dem Client an, auf weitere Logs zu warten, sobald er das aktuellste Log des DB-Servers gelesen hat.

Wache schieben 

Da das Übertragen der Transaktionsprotokolle damit ein wesentlicher Bestandteil des Backup-&-Recovery-Prozesses ist, muss der Datentransfer überwacht werden. Ein Durchstarten des Datenbankservers führt zum Verbindungsabruch der Übertragung und ist Anlass dafür, diesen Prozess erneut zu starten. Beim Neustart des Clients "mysqlbinlog" muss dann aber der neue Startzeitpunkt definiert werden, da ja in den meisten Fällen nicht alle noch vorhanden Binary Logs des DB-Servers erneut übertragen werden sollen. Im einfachsten Fall schaut man einfach nach, welches Log als letztes (und ggfs. noch nicht vollständig) übertragen wurde und setzt den Prozess dort wieder auf.

In unserem Fall wurde der Server runtergefahren, während das Log mit der #9 übertragen wurde. Der neue Transfer startet exakt an dieser Stelle.  

Eine Hand breit Wasser unterm Kiel

Es ist wichtig zu verstehen, dass es auch bei diesem Verfahren zu einem Datenverlust kommen kann, da die Transaktion des DB-Servers nicht auf die Übertragung des Binary-Logs auf dem Backup-Server wartet. Dennoch werden hier Daten sehr zeitnah auf einen zusätzlichen Server übertragen, ohne dass eine Replikation oder gar ein Cluster betrieben werden muss.

Sie haben Fragen zum Thema Backup & Restore in Sachen MySQL oder sind auf der Suche nach eine Verfügbarkeitslösung für Ihre Systeme? Sprechen Sie mit uns – wir beraten Sie gern!