Technic Blog

Technik BlogDisaster Recovery-Strategien für MySQL Datenbanksysteme

13. November 2017 Max Fruth

Entscheidungsgrößen bei der Strategiewahl

Backup- und Wiederherstellungsprozesse sind ein kritischer Teil jeder IT-Anwendung und somit ein wichtiger Baustein der Business Continuity Planung. Ein gut durchdachtes und erprobtes Backup- und Recovery-System kann den Unterschied zwischen einem kleinen Ausfall und einer ernsten Bedrohung für ein Unternehmen ausmachen.

Bei der Planung Ihrer Backup und Disaster Recovery Strategie müssen drei Punkte berücksichtigt werden: Wiederherstellungszeit (RTO), Wiederherstellungpunkt (RPO) und die Risikominderung.

Recovery Time Objective (RTO)

Die RTO beschreibt die Zeitvorgabe für Dauer der Wiederherstellung eines Datenbanksystems nach einem Störfall. Wie hoch ist der potentielle Umsatzverlust durch einen Ausfall ? Was wurde in den SLA's mit Kunden vereinbart ? Die Antworten aus diesen Fragen haben entscheidenden Einfluss bei der Bestimmung der RTO.

Recovery Point Objective (RPO)

Die RPO ist der Zeitpunkt, zu dem Sie wiederherstellen möchten. Die Wiederherstellung einer Datenbank aus einen Backup hat einen Datenverlust zur Folge. Wenn ein RPO von mehr als einem Tag vereinbart wurde, können tägliche Backup-Routinen dies abdecken. Wenn jedoch strengere RPOs definiert wurden, sind zusätzliche Maßnahmen wie Binär-Streaming oder inkrementelles Backup erforderlich.

Risikominderung

Bei der Definition einer Strategie ist zudem wichtig, welche Art von Risiken gemindert werden sollen. Sind es Fehler in der Programmierung oder Mängel in der Administration von Datenbanken? Besteht ein erhöhtes Risiko der Datenintegrität durch Hackerangriffe oder Benutzerfehler ? Wie kann das Risiko des Ausfalls eines Servers oder sogar des Rechenzentrums gemindert werden ?

Backup Strategien für MySQL Datenbanken

Generell unterscheidet man zwischen logischen und physischen Backups. Logische Backups schützen vor dem Verlust einzelner Datenpunkte, während physische Backups vor einem kompletten Datenverlust, z.B nach dem Ausfall des DB-Serverhardware, schützen.

Die Komplexität bei der Erstellung sog. Hot-Backups mit aktiven Datenbanksystemen liegt darin, daß der Datenbankservice bezüglich Verfügbarkeit und Performanz nicht beeinträchtigt werden soll. Der Service darf weder gestoppt noch schreibgeschützt werden. Ein einfaches Kopieren der Datendateien einer aktiven Datenbank führt in der Regel zu einer inkonsistenten Kopie der Datenbank, d.h. diese ist nicht verwendbar oder es fehlen Transaktionen, die während des Vorgangs durchgeführt wurden. Andererseits führt das Stoppen der Datenbank für geplante Backups dazu, dass datenbankabhängige Teile Ihrer Anwendung nicht mehr verfügbar sind.

Welche Software-Tools stehen zur Verfügung, um MySQL-Backups zu erstellen?

mysqldump erzeugt logische Backups der Daten und wird vor allem bei kleineren Datenbanksystemen und in der Entwicklung verwendet. Bei großen und hochverfügbaren Datenbanksystemen kommt mysqldump kaum zur Anwendung, da die Nachteile dieses Verfahrens bzgl. Skalierbarkeit (Dauer des Backups und Restores) und die Interaktionen mit aktiven Anwendungen (Performanzeinbussen) nicht vertretbar sind.

XtraBackup erstellt physische Backups der Datenbankdateien, also Kopien der Datendateien. Anschließend wendet es das Transaktionsprotokoll (auch als Redo-Log bekannt) auf die physischen Sicherungen an, um alle aktiven Transaktionen, die während der Erstellung der Sicherungen nicht beendet wurden, zu sichern, um die Datenkonsistenz zu einer laufenden Datenbank zu gewährleisten.

Entscheidungsdiagramm zur Backup Strategie

Decision Flow Chart

Wiederherstellung von Datenbanksystemen

Die Wiederherstellungszeit kann mit Hilfe einer DB Staging Area erheblich reduziert werden. Das Rückkopieren der Daten aus einer Sicherung mittels zentraler Backup Software (z.B. VEEAM) erfordert einen erheblich größeren Zeitaufwand, da die Daten zunächst aus einem großen, meist langsamen Speichermedium für den Restore bereitgestellt werden müssen. Aktive Backup-Prozesse können zudem den Zugriff auf das Backup-Medium massiv verzögern.

Das Vorhalten eines kompletten Backup-Zyklus inkl. Full, Incremental und Binlog Backups in einer sog. Staging Area ist deshalb bei einer größeren IT-Infrastruktur wichtig, um die in den RTOs definierten Ziele zu erreichen. Die DB Staging Area sollte folgende Bedingungen erfüllen:

  • Das Speichermedium sollte auch bei einem Ausfall der DB Serverhardware verfügbar sein.
  • Die Systemprozesse der Wiederherstellungssoftware sollten einen direkten Zugriff auf das Speichermedium haben.
  • Die Zugriffslatenz (Disk I/O, Network I/O) auf gesicherte Daten der Staging Area sollte möglichst kurz sein.

GlusterFS ein hochverfügbares, verteiltes Dateisystem würde z.B die genannten Vorgaben an eine Staging Area gut erfüllen. Wir bei netplace haben mit GlusterFS sehr gute Erfahrungen gemacht.

Aus dem Entscheidungsdiagramm zur Backup Strategie wird ersichtlich, daß die RPO einen entscheidenden Einfluß auf die Definition des Backup Schemas hat. Insbesondere wenn der Wiederherstellungszeitpunkt kurz ist, also nur ein geringer Datenverlust toleriert werden kann, sind Datensicherungen in kürzeren Zeitabständen erforderlich. Da diese Zusatzsicherungen in die Zeiträume hoher Produktivität fallen, dürfen die DB-System dadurch nicht beeinträchtigt werden. Sicherungsverfahren mit Locks auf Read oder Write Operationen würde die Verfügbarkeit oder Performanz von Applikationen beeinträchtigen und scheiden somit aus.

Mit der Sicherung des MySQL Binärprotokolls (kurz BINLOG genannt), besteht die Möglichkeit das Backup Schema für hoch produktive Systeme zu erweitern. Üblicherweise ist die Aufzeichnung von Write Operationen in Binärlogs bei asynchronen Replikationen (Master/Slave, Master/Master) bereits aktiv, so daß die Sicherung dieser Dateien keinen negativen Einfluß auf die Performanz des DB Systems hat.

Galera Cluster Systeme benutzen hingegen ein synchrones Replikationsprotokoll, so daß das Schreiben des BINLOG auf einem Node im Cluster explizit aktiviert werden muß. Da die Performanz des Clustersystems vom langsamsten Node bestimmt wird, hat die Aktivierung von BINLOG einen negativen Einfluß bei allen Write Operationen. Dies muß bei den Überlegungen zur Risikominderung berücksichtigt werden.

In weiterführenden Blog Artikel werde ich detailliert auf die bekanntesten MySQL Backup Tools xtrabackup und mysqldump eingehen. Zudem werde ich Scripts zum Download bereitstellen, die ein umfassendes Backup Schema für MySQL Datenbanken abbilden und umsetzen.