Write-Ahead Log
Das WAL macht Datenseiten-Schreibvorgänge vom Commitzeitpunkt unabhängig und ermöglicht Wiederherstellung.
- Write aheadDie Wiederherstellungsinformation wird vor der veränderten Datenseite dauerhaft.
- CommitDie Datenbank bestätigt eine Transaktion nach ihrer konfigurierten Dauerhaftigkeitsregel.
- ReplayNach einem Absturz rekonstruiert die Datenbank bestätigte Änderungen aus dem Log.
Einordnung
Warum das wichtig ist
Für Architekturentscheidungen zählt, welcher Fehler nach welcher Bestätigung überlebt wird.
Das Profil erklärt die Datenbankmechanik. Die getrennte Zahlungsdatenbank ist hypothetisch; der aktuelle Shop nutzt sieben Module und eine gemeinsame Datenbank.
WAL-Zusagen unterscheiden
Der heutige Shop führt Katalog, Warenkorb, Bestellung, Zahlung, Lager, Versand und Rechnung als sieben Module in einem modularen Monolithen mit gemeinsamer Datenbank. Für eine hypothetische getrennte Zahlungsdatenbank bestätigt der Datenbankserver eine Autorisierung erst, nachdem die nötigen WAL-Einträge dauerhaft geschrieben sind. Das Team beendet den Prozess nach Commit und vor dem Schreiben der Datenseite und prüft beim Neustart die Wiederherstellung. Erst eine zusätzlich konfigurierte synchrone Replikationsregel würde die Bestätigung eines zweiten Knotens in die Commit-Zusage aufnehmen.
So liest du das Bild
- Write ahead WAL-Flush vor Seiten-Flush
- Commit Lokale oder synchrone Bestätigung benennen
- Replay Fehlerpunkt und Ergebnis reproduzierbar prüfen
| Vergleich | Mechanik | Belegt | Belegt noch nicht |
|---|---|---|---|
| Lokaler WAL-Commit | Logeintrag auf dem bestätigenden Knoten dauerhaft | Lokale Crash Recovery nach Konfiguration | Kopie auf zweitem Knoten |
| Synchrone Replikation | Geforderte Replikatbestätigung vor Commitantwort | Überleben des vereinbarten Knotenausfalls | Fachliche Verarbeitung durch einen Konsumenten |
| Logische Decodierung | Änderungen in konsumierbarer Form | Positionierter Änderungsstrom | Genau-einmal-Fachwirkung |
Nutzen & Grenzen
Hilft, wenn
- Ein WAL passt als Datenbankmechanik, wenn bestätigte Transaktionen nach einem Prozess- oder Maschinenabsturz wiederhergestellt werden müssen.
- WAL-basierte Replikation passt, wenn Replikate denselben Änderungsverlauf auf Speicher- oder logischer Ebene nachführen sollen.
- Logische Decodierung passt, wenn ausgewählte bestätigte Änderungen außerhalb der Datenbank konsumiert werden sollen.
Grenzen
- Die Commit-Zusage hängt von Flush-, Speicher- und Synchronisationskonfiguration ab; ein erfolgreicher API-Aufruf allein beschreibt sie nicht.
- Ein lokaler WAL-Commit garantiert weder die Bestätigung durch ein Replikat noch die fachliche Verarbeitung in einem Folgesystem.
- Archivierung und Replikationspositionen können WAL-Segmente lange binden. Das Team braucht Grenzwerte für Lag, Speicher und Wiederherstellungszeit.
In der Praxis
- Ordne einen bestätigten Zahlungscommit den dauerhaften Logeinträgen und den später geschriebenen Datenseiten zu. Prüfe, welche Information für Wiederherstellung benötigt wird.
- Simuliere einen Datenbankneustart nach Commit und vor dem Zurückschreiben der Datenseite. Verfolge, wie das WAL den bestätigten Zustand wiederherstellt.
- Bewerte, welche Aufbewahrung und Archivierung das gewählte WAL-Verfahren verlangt. Trenne lokale Crash Recovery von einer Replikationszusage an andere Knoten.
Ausführliche Erklärung lesen
Beim Commit stellt die Datenbank sicher, dass die erforderlichen WAL-Einträge dauerhaft sind. Datenseiten dürfen später geschrieben werden; nach einem Absturz spielt die Wiederherstellung die protokollierten Änderungen erneut ein und verwirft unvollständige Arbeit.
WAL-Reihenfolge und Datenbanktransaktionen gehören zusammen, sind jedoch kein fertiger Fachereignisvertrag. Physische Replikation überträgt Speicheränderungen; logische Decodierung übersetzt ausgewählte Änderungen in eine konsumierbare Form.
Transaktionen definieren die atomare fachliche Änderung innerhalb der Datenbank. Replikation ergänzt Kopien und Verfügbarkeitsregeln. Ein WAL-Commit belegt lokale Dauerhaftigkeit nach der konkreten Datenbankkonfiguration.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was muss vor der Datenseite dauerhaft sein?
Lösung mit Begründung ansehen
Die für Wiederherstellung benötigten WAL-Einträge.
AnwendenAuf eine neue Lage übertragen
Welche Probe belegt Crash Recovery im Shop-Szenario?
Lösung mit Begründung ansehen
Ein Abbruch nach Commit und vor Seiten-Flush mit anschließendem Nachweis, dass die bestätigte Autorisierung wiederhergestellt wird.
BewertenEine Alternative abwägen
Wann darf ein Team von Replikatdauerhaftigkeit sprechen?
Lösung mit Begründung ansehen
Wenn die konkrete synchrone Bestätigungsregel, der beteiligte Knoten und der geprüfte Ausfall benannt sind.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.