El Write-Ahead Logging (WAL) es un método estándar para garantizar la integridad de los datos. Se puede encontrar una descripción detallada en la mayoría de los libros (si no en todos) sobre el procesamiento de transacciones. Brevemente, el concepto central de WAL es que los cambios en los archivos de datos (donde residen las tablas y los índices) deben escribirse sólo después de que esos cambios hayan sido registrados, es decir, después de que los registros WAL que describen los cambios hayan sido vaciados al almacenamiento permanente. Si seguimos este procedimiento, no necesitamos vaciar las páginas de datos al disco en cada confirmación (commit) de transacción, porque sabemos que en caso de un fallo podremos recuperar la base de datos utilizando el registro: cualquier cambio que no se haya aplicado a las páginas de datos se puede rehacer a partir de los registros WAL. (Esta es la recuperación hacia adelante o roll-forward, también conocida como REDO).
Debido a que el WAL restaura el contenido de los archivos de la base
de datos después de un fallo, no son necesarios los sistemas de archivos transaccionales
(journaled file systems) para el almacenamiento confiable de los archivos de datos o archivos WAL.
De hecho, la sobrecarga de la transacción de registro (journaling) puede reducir el rendimiento,
especialmente si el journaling hace que los datos del sistema de archivos se
vacíen en el disco. Afortunadamente, el vaciado de datos durante el journaling a menudo se puede
desactivar con una opción de montaje del sistema de archivos, por ejemplo,
data=writeback en un sistema de archivos ext3 de Linux.
Los sistemas de archivos transaccionales sí mejoran la velocidad de arranque después de un fallo.
El uso de WAL da como resultado una cantidad significativamente menor de
escrituras en el disco, porque sólo el archivo WAL debe vaciarse en el disco para garantizar
que una transacción se confirme, en lugar de cada archivo de datos modificado por la transacción.
El archivo WAL se escribe secuencialmente, por lo que el costo de sincronizar el WAL es mucho
menor que el costo de vaciar las páginas de datos. Esto es especialmente true para los servidores
que manejan muchas transacciones pequeñas que tocan diferentes partes del almacén de datos.
Además, cuando el servidor procesa muchas transacciones pequeñas concurrentes, un solo
fsync del archivo WAL puede ser suficiente para confirmar muchas transacciones.
El WAL también hace posible admitir copias de seguridad en línea y recuperación en un punto en el tiempo (point-in-time recovery), como se describe en Section 25.3. Al archivar los datos del WAL, podemos admitir la reversión a cualquier instante de tiempo cubierto por los datos del WAL disponibles: simplemente instalamos una copia de seguridad física previa de la base de datos y reproducimos el WAL exactamente hasta el momento deseado. Es más, la copia de seguridad física no tiene por qué ser una instantánea (snapshot) instantánea del estado de la base de datos; si se realiza durante un período de tiempo, reproducir el WAL para ese período corregirá cualquier inconsistencia interna.