A standard family of techniques for providing atomicity and durability in database systems and file systems. The fundamental tenet of WAL is that all modifications to data must be recorded in a dedicated, sequential log (the “journal”) before those changes are permanently applied to the actual data files on disk.
Functional Mechanics
In a system using WAL, the process for updating a record follows a specific sequence to ensure data integrity:
- Transaction Initiation: The system receives a change request.
- Log Entry: The system describes the change and writes it to the WAL located on non-volatile storage.
- Commit: Once the log entry is safely flushed to the disk, the transaction is considered committed.
- Data Update: The actual database records (the data pages) are updated in the main storage. This often happens asynchronously or during a checkpoint to optimize performance.
The Role in Crash Recovery
WAL is the primary mechanism that prevents data loss during a power failure or system crash:
- Redo: If the system crashes after a transaction was committed to the log but before it was written to the data file, the system reads the WAL upon reboot and replays the changes to the data file.
- Undo: If a transaction was in progress but not yet committed when the crash occurred, the system uses the log to identify and reverse any partial changes, maintaining a consistent state.
Benefits
- Performance: Disk I/O is optimized because the system only needs to perform sequential writes to the log (which is very fast) during the transaction, rather than seeking and writing to multiple random locations in a large data file.
- Durability: It ensures that even if the main data storage is corrupted, the log provides a chronological record of all successful operations.
- Enabling PITR: WAL files are the essential ingredient for Point-in-Time Recovery. By archiving these logs, an administrator can reconstruct the database to any specific point in time by replaying the logs against a baseline backup.