Robocikowo>ROBOCIKOWO
Infrastruktura

WAL

1992AktywnyOpublikowany
Technika trwałości i atomowości w systemach bazodanowych: zmiany są najpierw zapisywane do logu na trwałym nośniku, a dopiero potem aplikowane do właściwych struktur danych.
Kluczowa innowacja
Zapis opisu zmiany do sekwencyjnego logu na trwałym nośniku PRZED modyfikacją właściwych plików danych — commit wymaga wyłącznie zrzutu logu, a nie wszystkich zmienionych stron danych.
Kategoria
Infrastruktura
Poziom abstrakcji
Wzorzec
Poziom operacji
DaneUdostępnianie
Zastosowania
Trwałość i odzyskiwanie po awarii w relacyjnych bazach danych (PostgreSQL, SQLite, Db2, SQL Server)Replikacja i strumieniowanie zmian (log shipping, logical/physical replication)Odtwarzanie do punktu w czasie (PITR) i kopie zapasowe onlineTrwałość zapisów w bazach wektorowych i magazynach stanu dla systemów AIDzienniki trwałości w rozproszonych systemach storage i kolejkach

Jak działa

1. Każda modyfikacja generuje rekord logu (WAL record) opisujący zmianę. 2. Rekordy logu są dopisywane sekwencyjnie do pliku logu i zrzucane na trwały nośnik (fsync) PRZED zmianą właściwych plików danych. 3. Commit transakcji następuje w momencie trwałego zapisania rekordu commit do logu — zmienione strony danych mogą trafić na dysk później. 4. Jeden fsync logu może zatwierdzić wiele małych, współbieżnych transakcji. 5. Checkpoint przenosi zaaplikowane zmiany z logu do właściwych plików danych i pozwala obciąć (lub zarchiwizować) stary log. 6. Po awarii manager odzyskiwania odtwarza zatwierdzone zmiany z logu (REDO), a niezatwierdzone wycofuje (UNDO). WAL umożliwia też kopie zapasowe online i odtwarzanie do punktu w czasie (PITR) przez archiwizację i ponowne odtworzenie logu.

Rozwiązany problem

Jak zagwarantować trwałość i atomowość zatwierdzonych transakcji mimo awarii (crash) bez konieczności kosztownego zrzucania wszystkich zmienionych stron danych na dysk przy każdym commicie. Naiwne podejście (zapis zmian in-place) traci dane przy awarii w trakcie zapisu lub wymusza wiele losowych zapisów na dysk.

Komponenty

Rekordy logu (WAL records)Trwały, uporządkowany zapis intencji zmian

Sekwencyjnie dopisywane wpisy opisujące każdą zmianę danych; zrzucane na trwały nośnik przed modyfikacją plików danych.

CheckpointOgraniczenie rozmiaru logu i czasu odzyskiwania

Operacja przenosząca zaaplikowane zmiany z logu do właściwych plików danych, umożliwiająca obcięcie lub archiwizację starego logu.

Manager odzyskiwania (REDO/UNDO)Odtworzenie spójnego stanu po awarii

Po awarii odtwarza z logu zmiany transakcji zatwierdzonych (REDO) i wycofuje zmiany transakcji niezatwierdzonych (UNDO).

Implementacja

Implementacje referencyjne
PostgreSQL — Write-Ahead Logging
C · PostgreSQL Global Development Group
Oficjalna
SQLite — WAL mode
C · SQLite (D. Richard Hipp / SQLite Consortium)
Oficjalna
Pułapki implementacyjne
WAL nie działa na sieciowych systemach plikówWysoka

Implementacje oparte na pamięci współdzielonej (np. SQLite) wymagają lokalnego systemu plików; WAL nie działa poprawnie na NFS/sieciowych FS.

Rozwiązanie:Używać lokalnego magazynu dla pliku WAL; dla współdzielenia stosować replikację/log shipping zamiast współdzielonego FS.
Niekontrolowany wzrost pliku WALŚrednia

Jeśli checkpointy nie przebiegają (np. długo trwający czytelnicy trzymają stary snapshot), log rośnie bez ograniczeń, pochłaniając miejsce i wydłużając odzyskiwanie.

Rozwiązanie:Konfigurować automatyczne checkpointy, limitować długie transakcje czytające i monitorować rozmiar logu.
Trwałość zależy od poprawności fsyncWysoka

Gwarancje trwałości zakładają, że pamięć masowa rzetelnie realizuje fsync. Skłamane/zbuforowane fsync (np. w tanim sprzęcie lub niektórych FS) mogą prowadzić do utraty zatwierdzonych danych po awarii zasilania.

Rozwiązanie:Weryfikować, że sprzęt/FS honoruje fsync; wyłączyć zapisowe cache dysku bez zasilania awaryjnego lub użyć sprzętu z bateryjnym podtrzymaniem.
Słabsza wydajność dla bardzo dużych transakcjiNiska

WAL działa najlepiej dla małych transakcji; dla transakcji rzędu setek MB tryb rollback journal bywa szybszy (dot. SQLite).

Rozwiązanie:Dla bardzo dużych transakcji rozważyć inny tryb journalingu lub podział pracy na mniejsze transakcje.

Ewolucja

Oryginalny paper · 1992 · ACM Transactions on Database Systems (TODS), Vol. 17, No. 1, s. 94–162 · C. Mohan
ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging
C. Mohan, Donald Haderle, Bruce Lindsay, Hamid Pirahesh, Peter Schwarz
1992
Publikacja algorytmu ARIES
Punkt przełomowy

Mohan i in. (IBM) formalizują metodę odzyskiwania opartą na Write-Ahead Logging z drobnoziarnistym blokowaniem i częściowym rollbackiem. Stosowana m.in. w IBM Db2 i Microsoft SQL Server.

2010
Tryb WAL w SQLite 3.7.0

SQLite 3.7.0 (2010-07-21) wprowadza tryb WAL jako alternatywę dla rollback journal: większa współbieżność (czytelnicy nie blokują pisarza), bardziej sekwencyjne I/O i mniej wywołań fsync().

Hiperparametry (konfigurowalne osie)

Częstotliwość checkpointówWysoka

Jak często log jest przenoszony do plików danych. Rzadsze checkpointy = mniej I/O w tle, ale większy log i dłuższe odzyskiwanie.

Polityka trwałości (fsync na commit)Krytyczna

Czy commit czeka na trwały zrzut logu. Synchroniczny commit daje pełną trwałość kosztem opóźnienia; asynchroniczny zwiększa przepustowość ryzykiem utraty ostatnich transakcji.

Próg rozmiaru loguŚrednia

Maksymalny rozmiar logu wyzwalający checkpoint/obcięcie. Zapobiega nadmiernemu wzrostowi pliku WAL.

Równoległość

Poziom równoległości
Sekwencyjny

Log jest dopisywany sekwencyjnie, co nadaje zapisom charakter sekwencyjny (tani fsync), ale serializuje strumień logu. Jeden fsync logu może jednak zatwierdzić wiele współbieżnych transakcji (group commit).

Wymagania sprzętowe

Podstawowe

WAL to technika programowa niezależna od akceleratorów; korzysta głównie z szybkiego, sekwencyjnego zapisu na trwałym nośniku (SSD/NVMe) i wydajnego fsync.