Begriff
WAL (Write-Ahead Logging)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Datenbanken speichern Daten im RAM (schnell). Aber RAM ist flüchtig (Strom weg = Daten weg).
Wie garantiert man, dass eine Transaktion "Durable" (Dauerhaft) ist?
Die Regel: Logge es, bevor du es tust.
Bevor die DB irgendwas in die echte Datendatei schreibt, schreibt sie die Änderung in ein Logfile (Append-Only).
Erst wenn das Logfile auf der Platte ist (fsync), sagt die DB "Success".
Wenn der Strom ausfällt:
Beim Neustart liest die DB das Log ("Replay").
"Ah, hier steht, ich wollte X=5 setzen. Habe ich das getan? Nein. Also tue ich es jetzt."
Das ist der Standard-Trick für Zuverlässigkeit in PostgreSQL, MySQL, Oracle und Filesystemen (ext4, NTFS).
Merksatz: Ein Verfahren zur Gewährleistung der Atomarität und Dauerhaftigkeit (Durability) in Datenbanksystemen, bei dem alle Änderungen zuerst in ein sequenzielles Protokoll geschrieben werden, bevor sie in den eigentlichen Datenbestand übernommen werden.
Als Admin: Das WAL ist dein Rettungsanker. Wenn die DB crasht, lösche niemals das WAL-Verzeichnis. Du kannst das WAL auch für Replication nutzen. Schicke das WAL an einen anderen Server (Standby). Der spielt es ab und hat die gleichen Daten. (PostgreSQL Streaming Replication).
1. ARIES Algorithm
Der Goldstandard für Recovery. Phasen:
Analysis: Scanne das WAL von vorne bis hinten. Was war offen beim Crash?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Als Admin: Das WAL ist dein Rettungsanker. Wenn die DB crasht, lösche niemals das WAL-Verzeichnis. Du kannst das WAL auch für Replication nutzen. Schicke das WAL an einen anderen Server (Standby). Der spielt es ab und hat die gleichen Daten. (PostgreSQL Streaming Replication).- Redo: Spiele alles ab, was im Log steht (wiederhole die Geschichte).
- Undo: Mache alle Transaktionen rückgängig, die beim Crash nicht "Committed" waren. Das garantiert den ACID-Zustand.
2. Group Commit
fsync (Platte syncen) ist teuer (10ms).
Wenn 100 User gleichzeitig schreiben, wartet die DB kurz (z. B. 5ms) und schreibt alle 100 Logs in einem Rutsch auf die Platte.
Das erhöht den Durchsatz massiv.
1. LSN (Log Sequence Number) & Dirty Pages
In der Produktion korrespondiert das WAL direkt mit dem Buffer Cache im RAM. Jeder Log-Eintrag bekommt eine eindeutige LSN (eine stetig steigende Zahl). Jede Datenseite im RAM ("Dirty Page") speichert die LSN der letzten Änderung, die an ihr vorgenommen wurde. Das entscheidende Gesetz: Eine Seite darf niemals auf die Platte geschrieben werden, bevor die entsprechende LSN im WAL physisch geloggt wurde (WAL Rule). So ist sichergestellt, dass bei einem Absturz immer ein Log-Eintrag existiert, um die Daten auf der Platte zu korrigieren.
2. Log Shipping & Point-in-Time Recovery (PITR)
WAL ist die Basis für Backups. Anstatt Terabytes an Daten zu kopieren, sichert man einmal die Woche die Datendateien ("Base Backup") und archiviert danach kontinuierlich die kleinen WAL-Dateien.
Wenn ein Admin versehentlich DROP TABLE users macht, kann man das Base Backup einspielen und die WAL-Files bis exakt eine Sekunde vor dem Befehl abspielen.
In PostgreSQL heißt dieses Verzeichnis pg_wal. Wenn dieses Verzeichnis vollläuft (Disk Full), steht die gesamte Datenbank still, da kein Commit mehr bestätigt werden kann. Monitoring der WAL-Disk-Quota ist daher SRE-Pflichtaufgabe Nr. 1.
3. Write Amplification & WAL Compression
Ein Problem ist die Write Amplification. Bei jedem Update einer einzigen Zeile schreibt die DB einen kompletten WAL-Record. In PostgreSQL gibt es zudem das "Full Page Write"-Feature: Nach einem Checkpoint wird beim ersten Update einer Seite die ganze 8kb Seite ins Log geschrieben (um Korruption durch OS-Crashs zu vermeiden). Das kann den Log-Traffic explodieren lassen. Moderne Systeme nutzen daher WAL Compression (z. B. mit LZ4 oder ZSTD), um die Menge der auf Disk geschriebenen Bytes zu reduzieren und so den I/O-Flaschenhals zu weiten.
Quick-Check
Warum Append-Only?
Sequenzielles Schreiben ist auf HDDs 100x schneller als Random Write. Das WAL muss extrem schnell sein, weil jeder Commit darauf wartet.Checkpoints?
Wenn das WAL unendlich wächst, dauert Recovery ewig. Checkpoint heißt: "Ich schreibe jetzt alles vom RAM auf die Platte." Danach kann man das alte WAL löschen.No-Steal/Force?
Datenbank-Theorie-Begriffe. WAL erlaubt "Steal" (Buffer Manager darf unfertige Daten auf Platte schreiben, weil Undo möglich) und "No-Force" (Muss bei Commit nicht Daten, sondern nur Log schreiben).