PostgreSQL WAL ist kein Fisch ...

... sondern die Abkürzung für Write-Ahead Logging, eine gebräuchliche Technik zum Protokollieren von Transaktionen.

Im normalen Betrieb läuft PostgreSQL im autocommit-Modus, in dem jedes Kommando vom System stillschweigend in eine Transaktion eingeschlossen und mit einem impliziten COMMIT beendet wird.

Unmittelbar nach dem COMMIT wird jede Transaktion von PostgreSQL in ein Transaktionslog auf der Platte geschrieben, genauer gesagt in das Verzeichnis /data/pg_xlog. Standardmäßig besteht es aus 3 Protokolldateien, den WAL-Segmenten, die jeweils 16 MB groß sind. Alle Änderungen in den Datendateien (Tabellen, Indexe ...) werden zunächst in diesen Log-Dateien protokolliert, bevor sie permanent in die Datenbank geschrieben werden.

Dieser Schreibvorgang findet statt, wenn entweder die vorhandenen WAL-Segmente vollgeschrieben sind, oder wenn eine vorher festgelegte Zeitspanne verstrichen ist (oder wenn der Administrator mit dem Kommando CHECKPOINT den Schreibprozess erzwingt). Dieser Zeitpunkt heisst Checkpoint, die Zeitspanne zwischen zwei Checkpoints ist der checkpoint_timeout (Standard 300 sec = 5 min).

Nach einem Checkpoint ist garantiert, daß die protokollierten Transaktionen aus den WAL-Segmenten permanent in die Datendateien auf die Platte geschrieben sind und dass die Datenbank in einem konsistenten Zustand ist. Nicht mehr benötigte WAL-Segmente werden wiederverwendet (recycled).

Da alle Transaktionen seit dem letzten Checkpoint in den WAL-Segmenten verzeichnet sind, können sie im Falle eines Systemabsturzes wiederhergestellt werden. (Deshalb nennt man die Transaktionslogs auch REDO-Logs.) Der Datenbankserver setzt bei einem Neustart auf dem letzten Checkpoint (das ist der letzte konsistente Zustand) auf. Dann liest er die Transaktionslogs und führt alle darin aufgezeichneten Transaktionen aus (REDO). Damit ist die Datenbank wieder in dem Zustand, in dem sie vor dem Absturz war.

Anmerkungen

Checkpoints können eine hohe I/O-Last verursachen und sollten daher mit Überlegung konfiguriert werden. Wenn es zu wenige WAL-Segmente gibt, werden die Checkpoints zu häufig ausgeführt. Gibt es zu viele oder ist der checkpoint-timeout zu großzügig gewählt, ist die Zahl der zu schreibenden Änderungen an einem Checkpoint sehr groß und ein Neustart des Systems nimmt sehr viel Zeit in Anspruch.

Um die Lastkurve bei einem Checkpoint abzuflachen, kann man die Änderungen auch verzögert auf die Platte schreiben, was die normale Operation der Datenbank weniger, dafür aber länger, belastet.

Die Strategie des Write-Ahead-Logs bietet Geschwindigkeitsvorteile, da die Anzahl der Festplattenzugriffe erheblich gesenkt werden kann. Die Änderungen in den Transaktionslogs werden in einem Schreibzyklus in die Datendateien geschrieben, anstatt nach jeder Transaktion alle geänderten Datenseiten zurückzuschreiben. Außerdem ist es viel einfacher und schneller, Daten sequentiell an ein Logfile anzuhängen, als den Festplattenkopf bei jeder Änderung ständig an die passende Schreibpostion zu bewegen.

Bei stark frequentierten Datenbanken mit vielen Schreiboperationen empfiehlt es sich, die Transaktionslogs (das Verzeichnis pg_xlog) auf eine zweite Platte auszulagern. Das bringt Geschwindigkeit, weil zwei Festplattenköpfe parallel schreiben können. Dazu genügt ein symbolischer Link für das Verzeichnis pg_xlog.)

Dieser Grönlandwal wurde geklaut bei http://kuesten-segeln.de