Write-Ahead-Log

Eine Datenbank speichert Informationen dauerhaft auf einem Speichermedium wie einer Festplatte. Das Problem: Zwischen dem Moment, in dem ein Programm eine Änderung befiehlt, und dem Moment, in dem sie wirklich auf der Festplatte steht, kann der Strom ausfallen. Die Daten wären dann in einem unklaren Zustand — halb alt, halb neu. Ein Write-Ahead-Log, kurz WAL, löst dieses Problem mit einer einfachen Regel: Bevor die Datenbank irgendetwas ändert, schreibt sie zuerst einen Eintrag in ein fortlaufendes Protokoll. Erst dann verändert sie die eigentlichen Daten. „Write-Ahead“ bedeutet wörtlich „zuerst schreiben“ — das Protokoll ist immer einen Schritt voraus.

Absturzsicherheit in Datenbanken

Ohne WAL ist jeder Absturz ein Glücksspiel. Wenn ein Server mitten in einer Änderung ausfällt, weiß das System danach nicht mehr, wie weit es gekommen ist. Wurden fünf von zehn Schritten ausgeführt? Drei? Keiner? Das Ergebnis kann unbrauchbar oder widersprüchlich sein.

Mit einem WAL ist die Antwort immer eindeutig. Nach einem Neustart liest das System das Protokoll durch. Einträge, die dort vollständig stehen, aber in den eigentlichen Daten fehlen, werden einfach nachgeholt. Einträge, die nur halb eingetragen wurden, werden verworfen. So landet die Datenbank garantiert in einem sauberen Zustand — egal, wann genau der Strom ausgefallen ist.

Dieses Verhalten nennt man in der Informatik Atomarität: Eine Änderung gilt entweder als vollständig durchgeführt oder als gar nicht durchgeführt. Es gibt keinen Zwischenzustand. Das WAL ist das Werkzeug, mit dem Datenbanken diese Garantie technisch einlösen.

Wie das Protokoll aufgebaut ist und wirkt

Das Log ist eine einfache, fortlaufende Datei. Jeder Eintrag beschreibt eine geplante Änderung: welche Tabelle betroffen ist, welcher alte Wert dort stand und welcher neue Wert geschrieben werden soll. Diese Einträge werden immer ans Ende angehängt — nie mittendrin verändert. Das macht das Schreiben ins Log sehr schnell, weil kein wahlfreier Zugriff auf die Festplatte nötig ist.

Erst nachdem ein Eintrag sicher im Log steht, darf die eigentliche Datei angefasst werden. Wenn nun etwas schiefgeht, gilt: Was im Log steht, war gewollt. Was nicht im Log steht, zählt nicht. Der Wiederherstellungsprozess nach einem Absturz heißt Recovery und läuft bei modernen Datenbanken vollautomatisch ab — er dauert meist nur Sekunden.

Ältere Einträge im Log werden irgendwann nicht mehr gebraucht. Sie werden dann gelöscht oder überschrieben — ein Vorgang, den man Checkpointing nennt. Dabei wird der aktuelle Stand der Daten komplett auf die Festplatte geschrieben, sodass das System beim nächsten Absturz nur ab diesem Punkt wiederherstellen muss und nicht das gesamte Log von Anfang an durcharbeiten muss.

WAL in Produkten und Debatten

WAL ist kein theoretisches Konzept — es steckt in fast jeder Datenbank, die heute im Einsatz ist. PostgreSQL und MySQL, zwei der weltweit meistgenutzten Datenbanksysteme, setzen seit Jahrzehnten auf WAL. Auch SQLite, die Datenbank, die auf praktisch jedem Smartphone läuft, hat seit 2010 einen WAL-Modus, der unter anderem parallele Lesezugriffe deutlich beschleunigt.

In Tech-News taucht der Begriff oft im Zusammenhang mit Datenbankausfällen auf. Wenn ein Cloud-Anbieter nach einem Serverausfall meldet, dass „keine Daten verloren gegangen“ seien, ist das WAL meistens der Grund dafür. Auch bei der Replikation — also dem automatischen Kopieren einer Datenbank auf mehrere Server gleichzeitig — spielt das Log eine zentrale Rolle: Der Replikationsserver liest einfach das WAL des Hauptservers und führt dieselben Schritte nach.

Ein verbreiteter Irrtum ist, dass WAL die Datenbank langsamer macht, weil ja alles doppelt geschrieben wird. In der Praxis ist das Gegenteil oft der Fall. Das Schreiben ans Ende einer Datei ist für Festplatten viel effizienter als das gezielte Verändern einzelner Stellen an beliebigen Positionen. Viele Datenbanken sind mit WAL schneller als ohne.