4.4Failure recovery and logging

For a DBA preparing for a sudden power loss or disk failure on a database server, deciding "which logging approach, checkpoint interval, and recovery procedure to use" is an important judgment that balances the durability guarantee against recovery time (RTO). Logging too much increases write overhead, while spacing checkpoints too sparsely lengthens recovery time after a failure. This section builds the judgment needed to decide which recovery approach to apply for each failure type.

4.4.1The WAL (write-ahead logging) principle

• The WAL (write-ahead logging) principle is to write the content of a change—as a log record (before-image and after-image)—to non-volatile storage before the change is actually applied to the database's data pages on disk. Keeping this order means that even if a failure occurs before the change is fully applied to the data itself, as long as the log survives, the change can be reproduced or undone, forming the foundation for guaranteeing both durability and consistency.
• The WAL principle is precisely what lets a DBMS improve write performance by deferring (buffering) the writes to the data pages themselves and applying them in bulk—as long as the log is reliably written first, safety is not compromised even if applying changes to the data pages themselves lags somewhat, since the log can restore them after a failure. Because writing to the log itself is mostly sequential append writes, it can be done faster than data-page updates, which require random I/O.