WAL-Prinzip

Das sogenannte write ahead logging (WAL) ist ein Verfahren der Datenbanktechnologie, das zur Gewährleistung der Atomarität und Dauerhaftigkeit von Transaktionen beiträgt. Es besagt, dass Modifikationen vor dem eigentlichen Schreiben (dem Einbringen in die Datenbank) protokolliert werden müssen.^[1]

Durch das WAL-Prinzip wird ein sogenanntes „update-in-place“ ermöglicht, d. h. die alte Version eines Datensatzes wird durch die neue Version an gleicher Stelle überschrieben.^[2] Das hat vor allem den Vorteil, dass Indexstrukturen bei Änderungsoperationen nicht mit aktualisiert werden müssen, weil die geänderten Datensätze immer noch an der gleichen Stelle zu finden sind. Die vorherige Protokollierung einer Änderung ist erforderlich, um im Fehlerfall die Wiederholbarkeit der Änderung sicherstellen zu können. Durch dieses Verfahren ist es nicht notwendig, Daten-Seiten bei jedem Transaktionsabschluss auf die Festplatte zu schreiben. Im Falle des Verlustes der Integrität kann die Datenbank mithilfe des Protokolls wiederhergestellt werden, indem alle Änderungen, die nicht auf die Daten-Seiten angewendet wurden, aus dem Protokoll neu durchgeführt werden (Roll-Forward-Recovery oder REDO).^[3] WAL führt zu einer erheblichen Reduzierung der Festplattenschreibvorgänge, da nur die Protokolldatei auf die Festplatte geschrieben werden muss, um eine Transaktion zu bestätigen, anstatt jede durch die Transaktion geänderte Datenbankdatei. Dies ist besonders vorteilhaft für Server, die viele kleine Transaktionen verarbeiten und auf verschiedene Bereiche des Datenspeichers zugreifen, da die Protokolldatei sequentiell geschrieben wird. Durch Archivieren der WAL-Daten ist es möglich, zu jedem Zeitpunkt, der durch die verfügbaren Protokolldaten abgedeckt ist, zurückzukehren. Dabei wird einfach eine frühere physische Sicherung der Datenbank rückgesichert, und das Protokoll wird bis zum gewünschten Zeitpunkt wieder abgespielt.^[4]

Beim herkömmlichen Rollback-Journal wird eine Kopie des unveränderten Originaldatenbankinhalts in eine separate Rollback-Journal-Datei geschrieben, und die Änderungen werden dann direkt in die Datenbankdatei geschrieben. Im Falle des Verlustes der Integrität oder eines ROLLBACK wird der ursprüngliche Inhalt des Rollback-Journals in die Datenbankdatei zurückgespielt, um die Datenbankdatei in ihren ursprünglichen Zustand zurückzubringen. Das COMMIT erfolgt, wenn das Rollback-Journal gelöscht wird. Der WAL-Ansatz kehrt dies um. Der ursprüngliche Inhalt bleibt in der Datenbankdatei erhalten, und die Änderungen werden an eine separate WAL-Datei angehängt. Ein COMMIT tritt auf, wenn ein spezieller Datensatz, der einen Commit anzeigt, an die WAL-Datei angehängt wird. Somit kann ein COMMIT erfolgen, ohne dass jemals in die ursprüngliche Datenbank geschrieben wird, was Lesezugriffe auf die ursprüngliche, unveränderte Datenbank ermöglicht, während gleichzeitig Änderungen in die WAL übertragen werden. Mehrere Transaktionen können an das Ende einer einzigen WAL-Datei angehängt werden.^[5]

1. ↑ 30.3. Write-Ahead Logging (WAL). In: Documentation, PostgreSQL 16. The PostgreSQL Global Development Group, 2024, abgerufen am 30. Januar 2024 (englisch): „Write-Ahead Logging (WAL) is a standard method for ensuring data integrity. [...] Briefly, WAL's central concept is that changes to data files (where tables and indexes reside) must be written only after those changes have been logged, that is, after WAL records describing the changes have been flushed to permanent storage.“ 
2. ↑ Russell Sears, UC Berkeley; Eric Brewer, UC Berkeley: Segment-Based Recovery: Write-ahead logging revisited. (PDF) VLDB Endowment, 28. August 2009, abgerufen am 30. Januar 2024 (englisch): „Write-ahead logging algorithms from the database literature were traditionally optimized for small, concurrent, update-in-place transactions, and later extended for larger objects such as images and other file types.“ 
3. ↑ 30.3. Write-Ahead Logging (WAL). In: Documentation, PostgreSQL 16. The PostgreSQL Global Development Group, 2024, abgerufen am 30. Januar 2024 (englisch): „If we follow this procedure, we do not need to flush data pages to disk on every transaction commit, because we know that in the event of a crash we will be able to recover the database using the log: any changes that have not been applied to the data pages can be redone from the log records. (This is roll-forward recovery, also known as REDO.)“ 
4. ↑ 30.3. Write-Ahead Logging (WAL). In: Documentation, PostgreSQL 16. The PostgreSQL Global Development Group, 2024, abgerufen am 30. Januar 2024 (englisch): „Using WAL results in a significantly reduced number of disk writes, because only the log file needs to be flushed to disk to guarantee that a transaction is committed, rather than every data file changed by the transaction. The log file is written sequentially, and so the cost of syncing the log is much less than the cost of flushing the data pages. This is especially true for servers handling many small transactions touching different parts of the data store. [...] By archiving the WAL data we can support reverting to any time instant covered by the available WAL data: we simply install a prior physical backup of the database, and replay the WAL log just as far as the desired time.“ 
5. ↑ 2. How WAL Works. In: Write-Ahead Logging. SQLite Dokumentation, 8. Januar 2022, abgerufen am 30. Januar 2024 (englisch): „The traditional rollback journal works by writing a copy of the original unchanged database content into a separate rollback journal file and then writing changes directly into the database file. In the event of a crash or ROLLBACK, the original content contained in the rollback journal is played back into the database file to revert the database file to its original state. The COMMIT occurs when the rollback journal is deleted. The WAL approach inverts this. The original content is preserved in the database file and the changes are appended into a separate WAL file. A COMMIT occurs when a special record indicating a commit is appended to the WAL. Thus a COMMIT can happen without ever writing to the original database, which allows readers to continue operating from the original unaltered database while changes are simultaneously being committed into the WAL. Multiple transactions can be appended to the end of a single WAL file.“