# WAL
## Write-Ahead Logging
* Asegurar **integridad de datos** mejorando el **rendimiento**
* Los cambios a un archivo de log en disco **antes** de aplicarlos
* Objetivo: **evitar escrituras** a disco
* Problemas y cambios no están en disco? Podemos recuperar del log
* **Aprovechable** : Master/esclavo, backup contínuo, restauración punto en el tiempo
* [Introducción a WAL en la doc de postgresql](http://www.postgresql.org/docs/9.3/static/wal-intro.html)
* [Wal en depesz.com](http://www.depesz.com/2011/07/14/write-ahead-log-understanding-postgresql-conf-checkpoint_segments-checkpoint_timeout-checkpoint_warning/)
# Presenter Notes
Write-Ahead Logging (WAL) WAL es un método estándar para asegurar integridad de
datos. El método es complejo pero, en resumen, se basa en que no se aplica
ningún cambio en los archivos de datos (tablas e índices) hasta que los cambios
se han logueado. Es decir, que estén bajo almacenamiento permanente (disco).
Aplicando este procedimiento no es necesario que ante cada commit escribir las
páginas de datos a disco, pues en caso de caída seremos capaces de recuperar la
base de datos utilizando el log. Cualquier cambio que no esté aplicado en las
páginas de datos puede ser rehecho con los registros en los logs. (Roll-forward
recovery, también conocido como REDO)
Esto tiene grandes implicaciones en mejora de rendimiento, pues el número de
escrituras a disco muy reducido.
Además gracias al WAL, tenemos la oportunidad de aprovecharlo para cluster
Master/Esclavo (streaming replication), el backup contínuo (online-backup) y la
restauración de cualquier punto en el tiempo (point-in-time recovery)
[Introducción a WAL en la doc de postgresql](http://www.postgresql.org/docs/9.3/static/wal-intro.html)
---
.fx: imageslide
---
# WAL
* Abrir fichero xlog, en modo *append*
* Escribir, en un fichero, en un *offset*.
* Cerrar fichero
* Asegurar escritura: `fsync()`
* Cambiar *datafile*
* Marcar operación como realizada en *xlog*.
---
# WAL
* INSERT
* Se carga `page` (8kb) en shared_buffers.
* Se esribe en `shared_buffers` y tambien WAL (no fsync())
* COMMIT: Se realiza `fsync()`
* Dos copias:
* Página modificada en shared_buffers
* WAL
* ¿Cuando escribimos a *datafiles* ?
* check_point
* page_swap (la página se necesita)
---
# Archivos en el servidor
* /var/lib/postgresql/9.3/main/pg_xlog
---
# Formato archivos
* Formato de los archivos WAL
* TLI: TimelineID , identifica el timeline
* LSN: Log Serial Number, Identificador del LOG
* [Nomenclatura de WAL](http://eulerto.blogspot.com.es/2011/11/understanding-wal-nomenclature.html)
# Presenter Notes
Los archivos de WAL postgres los mantiene en el directorio: /var/lib/postgresql/9.3/main/pg_xlog
La nomenclatura de estos archivos es incremental (en hexadecimal)
Solo se guardan cierto tiempo, luego se borran.
Si no puede escribir en pg_xlog, p.e. por falta de espacio, postgresql hará un PANIC shutdown.
El número de WAL's varia dependiendo de la carga y lo que vaya haciendo el server, pero se puede establecer una cota máxima con una de las siguientes formulas:
(2 + checkpoint_completion_target) * checkpoint_segments + 1
or
checkpoint_segments + wal_keep_segments + 1 files
TLI: TimelineID , identifica el timeline. El número de timeline solo cambia al terminar un proceso de recuperación, para que no se sobreescriban archivos.