Datenbanken im Serverbetrieb: Replikation, Point-in-Time-Recovery und Major-Upgrades

Webserver lassen sich austauschen, Applikationscontainer neu starten, Konfigurationen aus einem Repository wiederherstellen. Bei der Datenbank gilt das nicht. Sie hält den Zustand, den niemand aus einem Build neu erzeugen kann. Entsprechend anders muss sie betrieben werden. Dieser Beitrag beschreibt die vier Themen, an denen Datenbankbetrieb in der Praxis am häufigsten scheitert: Replikation, Wiederherstellung auf einen Zeitpunkt, Failover und Versionswechsel.

Warum die Datenbank eine Sonderrolle hat

In einer typischen Anwendungslandschaft sind die meisten Komponenten zustandslos. Fällt eine davon aus, übernimmt eine zweite Instanz, und niemand merkt etwas. Die Datenbank ist die Ausnahme. Sie ist meist einmal vorhanden, alle Schreibvorgänge laufen über sie, und ein Datenverlust ist nicht durch Neustart zu reparieren.

Daraus folgt eine einfache Regel für die Planung: Die Verfügbarkeit Ihrer Anwendung ist nie höher als die Wiederherstellbarkeit Ihrer Datenbank. Ein Cluster mit drei Applikationsservern hilft nicht, wenn die einzige Datenbankinstanz nach einem Defekt zwölf Stunden Wiederherstellung braucht.

Replikation ist kein Backup

Eine Replikation spiegelt Schreibvorgänge auf eine zweite Instanz. Das schützt gegen Hardwareausfall, Datenträgerdefekte und den Ausfall eines Standorts. Gegen logische Fehler schützt sie nicht. Ein versehentliches DELETE ohne WHERE wird innerhalb von Millisekunden auf die Replik übertragen. Dasselbe gilt für ein fehlerhaftes Migrationsskript, das eine Spalte leert.

Replikation und Sicherung lösen also verschiedene Probleme. Wer nur repliziert, hat Ausfallsicherheit ohne Fehlertoleranz. Wer nur sichert, hat Fehlertoleranz mit langer Wiederherstellungszeit. Für produktive Systeme braucht es beides.

Asynchron oder synchron

Bei asynchroner Replikation bestätigt der Primärserver eine Transaktion, bevor die Replik sie übernommen hat. Das ist schnell, bedeutet aber: Bei einem harten Ausfall können die zuletzt bestätigten Transaktionen verloren gehen. Wie viele das sind, hängt von der Replikationsverzögerung ab, nicht von einer Annahme.

Bei synchroner Replikation wartet der Primärserver auf die Bestätigung mindestens einer Replik. Datenverlust bei Ausfall entfällt praktisch, dafür steigt die Latenz jeder Schreiboperation, und der Ausfall der Replik kann den Primärserver blockieren, wenn keine Fallback-Regel definiert ist.

Die Entscheidung gehört zum Fachbereich, nicht zur Technik. Bei Buchungs- oder Abrechnungsdaten sind verlorene Transaktionen teuer. Bei Protokolldaten oder Caches sind sie irrelevant.

Point-in-Time-Recovery aufbauen

Ein nächtlicher Dump beantwortet die Frage "Wie sah die Datenbank gestern um drei Uhr aus". Er beantwortet nicht die Frage "Wie sah sie heute um 14:42 Uhr aus, kurz bevor das Skript lief". Für diese Frage brauchen Sie Point-in-Time-Recovery, also eine Basissicherung plus die fortlaufenden Transaktionsprotokolle.

Bei PostgreSQL sind das die WAL-Segmente, bei MySQL und MariaDB die Binlogs. Beide werden fortlaufend an einen externen Speicher ausgelagert. Die Wiederherstellung besteht dann aus dem Einspielen der Basissicherung und dem Nachfahren der Protokolle bis zu einem gewählten Zeitstempel.

Drei Punkte entscheiden darüber, ob das im Ernstfall funktioniert:

• Die Protokolle liegen auf einem anderen System als die Datenbank. Sonst nimmt ein Datenträgerdefekt beides mit.
• Die Aufbewahrungsfrist der Protokolle deckt die Aufbewahrungsfrist der Basissicherungen ab. Eine Basissicherung ohne passende Protokollkette erlaubt keine Wiederherstellung auf einen Zeitpunkt.
• Der Vorgang wurde mindestens einmal vollständig durchgespielt, inklusive Zeitmessung. Erst dann kennen Sie Ihre tatsächliche Wiederherstellungszeit.

Bei großen Datenbeständen ist die Wiederherstellungsdauer häufig die eigentliche Überraschung. Das Einspielen mehrerer hundert Gigabyte dauert, und das Nachfahren von Transaktionsprotokollen ist in der Regel ein serieller Vorgang, der sich nicht beliebig beschleunigen lässt.

Failover: automatisch oder bewusst manuell

Ein automatisches Failover klingt attraktiv, bringt aber eine eigene Fehlerklasse mit: den Split Brain. Verliert die Replik lediglich die Netzwerkverbindung zum Primärserver, hält sie ihn für tot und befördert sich selbst. Schreiben danach beide Instanzen, laufen die Datenstände auseinander, und das Zusammenführen ist manuelle Arbeit mit ungewissem Ausgang.

Deshalb braucht automatisches Failover immer ein Quorum, also eine dritte Instanz als Schiedsrichter, und ein Verfahren, das die alte Primärinstanz zuverlässig vom Schreiben abhält. Wer das nicht aufsetzen will oder kann, fährt mit einem dokumentierten manuellen Umschaltvorgang oft besser. Entscheidend ist, dass dieser Vorgang beschrieben, getestet und nicht nur einer Person bekannt ist.

Zum Failover gehört außerdem die Frage, wie die Anwendung den neuen Primärserver findet. Fest verdrahtete IP-Adressen in Konfigurationsdateien machen jede Umschaltung zum Deployment. Üblich sind stattdessen ein Proxy vor der Datenbank, ein virtueller IP-Wechsel oder ein DNS-Eintrag mit kurzer TTL.

Verbindungen und Connection Pooling

Viele Datenbankprobleme sind in Wahrheit Verbindungsprobleme. Jede Verbindung kostet Arbeitsspeicher, und Anwendungen öffnen gern mehr davon, als die Datenbank sinnvoll bedienen kann. Unter Last entstehen dann Wartezeiten, die wie ein Leistungsproblem aussehen, aber keines sind.

Ein Connection Pool zwischen Anwendung und Datenbank begrenzt die Zahl der tatsächlichen Verbindungen und reicht sie an die Anwendungsprozesse durch. Wichtig ist, dass die Obergrenze des Pools zur Konfiguration der Datenbank passt und nicht jeder Applikationscontainer seinen eigenen, unbegrenzten Pool mitbringt. Bei horizontaler Skalierung multipliziert sich sonst genau das Problem, das der Pool lösen sollte.

Wartung im laufenden Betrieb

Datenbanken brauchen regelmäßige Pflege, die über Updates hinausgeht. Dazu gehören aktuelle Statistiken für den Query-Planer, das Aufräumen alter Zeilenversionen und das Beobachten von Indexwachstum. Wird das über Monate ignoriert, verschlechtern sich Abfragepläne schleichend, bis eine bisher unauffällige Abfrage plötzlich Minuten braucht.

Auch Schemaänderungen gehören in diese Kategorie. Das Hinzufügen einer Spalte mit Standardwert, das Anlegen eines Index auf einer großen Tabelle oder eine Typänderung können Sperren erzeugen, die den Schreibbetrieb anhalten. Solche Operationen gehören in ein Wartungsfenster oder in eine sperrarme Variante, die vorher auf einer Kopie der Produktionsdaten getestet wurde.

Major-Upgrades rechtzeitig planen

Minor-Updates einer Datenbank sind in der Regel unkritisch: Paket aktualisieren, Dienst neu starten. Major-Upgrades sind etwas anderes. Das interne Datenformat ändert sich, das Verhalten des Query-Planers kann sich ändern, und einzelne Funktionen oder Datentypen entfallen.

Zwei Wege sind üblich. Der direkte Weg konvertiert die Daten im Stillstand, was bei großen Beständen ein längeres Wartungsfenster bedeutet. Der zweite Weg nutzt logische Replikation auf eine Instanz der neuen Version und schaltet anschließend um, was das Fenster auf wenige Minuten verkürzt, aber mehr Vorbereitung verlangt.

In beiden Fällen gilt: Vor dem Upgrade läuft die Anwendung testweise gegen die neue Version, mit realistischem Datenvolumen. Die häufigste unangenehme Überraschung ist nicht ein Fehler beim Upgrade selbst, sondern eine Abfrage, die danach einen anderen Plan wählt und deutlich langsamer wird.

Was Sie überwachen sollten

Vier Kennzahlen reichen für den Einstieg: die Replikationsverzögerung in Sekunden, die Zahl aktiver und wartender Verbindungen, das Alter der jüngsten erfolgreich geprüften Sicherung und der freie Speicherplatz auf dem Datenverzeichnis. Jede dieser Größen kündigt einen Ausfall an, bevor er eintritt.

Ergänzend lohnt ein Blick auf die langsamsten Abfragen. Nicht täglich, aber regelmäßig. Leistungsprobleme in Datenbanken entstehen selten plötzlich. Sie wachsen mit dem Datenbestand, und wer sie früh sieht, löst sie mit einem Index statt mit einem größeren Server.