Solución de problemas de alta actividad de WAL y gestión del espacio en disco de registros de archivo

La alta actividad de registros de escritura anticipada (WAL) en PostgreSQL no es automáticamente un problema. Una base de datos ocupada debería generar WAL. El problema ocurre cuando la tasa de WAL te sorprende, cuando el WAL archivado nunca se limpia, o cuando pg_wal crece porque algo impide que PostgreSQL recicle segmentos antiguos.

La forma más rápida de empeorar un incidente de WAL es eliminar archivos de pg_wal manualmente. No hagas eso. Trata un disco de WAL lleno como una situación de recuperación: identifica qué está reteniendo el WAL, crea espacio si puedes hacerlo de forma segura, y luego arregla el archivo fallido, el standby rezagado o el slot abandonado que causó el crecimiento.

Comprendiendo el registro de escritura anticipada (WAL)

PostgreSQL escribe registros de cambios en el WAL antes de que las páginas de datos relacionadas se escriban de forma segura. Después de un fallo, PostgreSQL reproduce el WAL para que los cambios confirmados no se pierdan. El mismo flujo también se utiliza para la replicación en streaming y la recuperación a un punto en el tiempo.

Los archivos WAL se almacenan en archivos de segmento de tamaño fijo. Muchas instalaciones utilizan segmentos de 16 MB porque es el valor predeterminado común, pero el tamaño se elige cuando se inicializa el clúster. Una carga de trabajo intensiva en escritura puede crear una gran cantidad de segmentos rápidamente. Los segmentos antiguos se reciclan o eliminan solo después de que PostgreSQL ya no los necesita para la recuperación tras fallos, los puntos de control, el archivado, la replicación o los slots.

Conceptos clave de WAL:

Durabilidad: las transacciones confirmadas se pueden recuperar después de un fallo.
Replicación: los standbys reciben registros WAL del primario.
Recuperación a un punto en el tiempo (PITR): las copias de seguridad base más el WAL archivado permiten recuperar hasta un punto elegido dentro de la ventana de retención.
Segmentos WAL: el WAL se almacena en archivos de segmento bajo pg_wal.

Causas comunes de alta actividad de WAL

Varios factores pueden contribuir a un volumen inusualmente alto de generación de WAL. Identificar la causa raíz es el primer paso para una solución de problemas efectiva.

1. Carga masiva de datos y modificaciones

Operaciones como INSERT, UPDATE, DELETE, TRUNCATE y COPY pueden generar cantidades significativas de WAL. Las operaciones masivas, especialmente en tablas grandes, producirán naturalmente más registros WAL que las transacciones pequeñas e individuales.

Ejemplo: Un solo comando COPY FROM para insertar millones de filas puede generar gigabytes de datos WAL.
Ejemplo: Ejecutar una migración de datos a gran escala o un script de actualización por lotes.

2. Retraso de replicación y problemas de standby

Si tus servidores standby no siguen el ritmo del primario (retraso de replicación), los archivos WAL se acumularán en el primario. El servidor primario no puede eliminar segmentos WAL completados hasta que se haya confirmado que han sido enviados y procesados por todos los standbys conectados (si wal_keep_size o max_slot_wal_keep_size no están configurados, o si los slots no se usan correctamente).

Escenario: Un servidor standby está caído, desconectado o experimentando problemas de rendimiento, lo que impide que consuma registros WAL del primario.

3. Escrituras de página completa después de puntos de control

Después de un punto de control, el primer cambio en una página de datos puede registrar una imagen de página completa cuando full_page_writes está habilitado. Esa configuración protege la recuperación de páginas rotas y normalmente se deja activada. Si los puntos de control ocurren con demasiada frecuencia, las imágenes de página completa pueden aumentar notablemente el volumen de WAL. La solución suele ser ajustar el comportamiento del punto de control, no deshabilitar las protecciones de durabilidad.

4. Crecimiento no gestionado del directorio `pg_wal`

Si el archivado de WAL está habilitado y falla, PostgreSQL conserva los segmentos WAL que aún necesitan ser archivados. Si el archivado no está habilitado, pg_wal debería reciclar los segmentos antiguos cuando ya no sean necesarios, a menos que la replicación, los slots o la presión del punto de control los retengan.

5. Slots de replicación no reclamados

Los slots de replicación garantizan que los segmentos WAL no se eliminen antes de ser consumidos por un standby específico o un cliente de decodificación lógica. Si se crea un slot pero el consumidor se detiene o se desconecta sin que se elimine el slot, los segmentos WAL requeridos por ese slot se retendrán, incluso si el standby ya no está activo.

Gestión del espacio en disco de WAL: configuración y soluciones

Abordar la alta actividad de WAL requiere un enfoque multifacético que involucra monitoreo, ajuste de configuración y procedimientos de mantenimiento adecuados.

1. Habilitar y monitorear el archivado de WAL

El archivado de WAL es el mecanismo más crítico para gestionar el espacio en disco y habilitar PITR. Cuando el archivado está habilitado, los archivos WAL completados se copian a una ubicación separada (por ejemplo, un recurso compartido de red, un bucket de S3 o un disco diferente).

Configuración:

Modifica tu archivo postgresql.conf:

wal_level = replica         # O logical para replicación lógica
archive_mode = on           # Habilitar archivado
archive_command = 'cp %p /ruta/al/archivo/%f'

# Ejemplo para S3 usando wal-g o una herramienta similar:
# archive_command = 'wal-g wal-push %p'

%p: Marcador de posición para la ruta completa al archivo WAL que se va a archivar.
%f: Marcador de posición para el nombre del archivo WAL.

Importante: El archive_command debe poder ejecutarse correctamente. Si devuelve un código de salida distinto de cero, PostgreSQL considerará que el archivado ha fallado, lo que puede provocar que los archivos WAL no se eliminen. Asegúrate de que el directorio de destino tenga suficiente espacio y que el usuario que ejecuta PostgreSQL tenga permisos de escritura.

Monitoreo del archivado

Usa consultas SQL para verificar el estado del archivado:

SELECT archived_count,
       failed_count,
       last_archived_wal,
       last_archived_time,
       last_failed_wal,
       last_failed_time
FROM pg_stat_archiver;

Si failed_count sigue aumentando o last_archived_time es antiguo mientras la base de datos sigue escribiendo, arregla el destino del archivo antes de ajustar los parámetros de tamaño de WAL.

2. Gestión del tamaño del directorio `pg_wal`

Incluso con el archivado habilitado, el directorio pg_wal en el primario puede crecer si los segmentos WAL no se eliminan después del archivado. Esto sucede si:

Los standbys no siguen el ritmo y el primario retiene WAL adicional para la replicación.
Los slots de replicación retienen archivos WAL.

`wal_keep_size`

Este parámetro mantiene WAL adicional en el primario para la replicación en streaming. Reemplazó la configuración anterior wal_keep_segments en PostgreSQL 13. Es útil para standbys que no usan slots, pero no es una garantía de que un standby muy rezagado pueda ponerse al día.

# postgresql.conf en el primario
wal_keep_size = 1024 # Mantener 1GB de WAL en disco

Los slots de replicación a menudo se prefieren cuando necesitas que el primario retenga WAL para un consumidor específico, pero los slots deben monitorearse porque pueden retener WAL indefinidamente.

`max_slot_wal_keep_size` (PostgreSQL 13+)

Esta configuración limita la cantidad de WAL que un slot de replicación puede retener. Es una protección contra el crecimiento ilimitado de un slot roto, pero también puede hacer que un consumidor rezagado pierda el WAL que necesita y requiera reinicialización.

# postgresql.conf en el primario
max_slot_wal_keep_size = 2048 # Limitar los slots a retener 2GB de WAL

# También considera: wal_keep_size -- sigue siendo relevante para streaming sin slots
# wal_keep_size = 1024 # Mantener 1GB para streaming sin slots

Si un slot se queda muy atrás y supera este límite, PostgreSQL puede eliminar el WAL necesario en el momento del punto de control. Eso protege el espacio en disco, pero el standby afectado o el cliente de replicación lógica pueden no poder continuar desde su posición anterior.

Slots de replicación

Los slots de replicación son cruciales para prevenir la pérdida de WAL y garantizar una replicación confiable. Sin embargo, pueden causar la acumulación de archivos WAL si no se gestionan correctamente.

Problema: Se crea un slot de replicación, pero el consumidor (standby o cliente lógico) se desconecta o falla, y el slot nunca se elimina. El servidor primario mantendrá todos los archivos WAL que el slot está esperando.
Solución: Monitorea regularmente los slots de replicación y elimina aquellos que ya no estén en uso.

-- Listar slots de replicación
SELECT slot_name,
       plugin,
       slot_type,
       active,
       restart_lsn,
       wal_status,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots
ORDER BY pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) DESC NULLS LAST;

-- Eliminar un slot no utilizado
SELECT pg_drop_replication_slot('nombre_del_slot_a_eliminar');

Advertencia: Eliminar un slot de replicación hará que cualquier consumidor conectado pierda su posición. Asegúrate de que el consumidor ya no sea necesario o haya sido reinicializado correctamente antes de eliminarlo.

3. Ajuste de `min_wal_size` y `max_wal_size`

Estos parámetros influyen en la frecuencia de los puntos de control y en la cantidad de WAL que PostgreSQL intenta mantener para reutilizar. No limitan el WAL retenido para archivado o replicación.

min_wal_size: anima a PostgreSQL a mantener al menos esta cantidad de WAL para reutilizar en lugar de eliminarlo inmediatamente.
max_wal_size: el volumen de WAL que tiende a desencadenar un punto de control. No es un máximo estricto cuando el WAL se retiene por otras razones.

# postgresql.conf
min_wal_size = 1GB
max_wal_size = 4GB

Aumentar max_wal_size puede dar al sistema más margen durante picos de carga de escritura, pero también significa que se ocupará más espacio en disco con archivos WAL preasignados.

4. Limpieza regular de archivos WAL archivados

El archivado de WAL, aunque esencial para la recuperación, también puede provocar problemas de espacio en disco si los archivos archivados nunca se limpian. Debes tener una estrategia para gestionar la retención de tus archivos WAL archivados.

Estrategia: Implementa un script o utiliza una herramienta dedicada (como pg_archivecleanup, pgBackRest, wal-g, barman) para eliminar archivos WAL antiguos de la ubicación de archivo una vez que ya no sean necesarios para PITR o replicación.
Usando pg_archivecleanup: Esta utilidad se puede ejecutar en el servidor primario para eliminar archivos WAL antiguos del directorio de archivo.
```
pg_archivecleanup /ruta/a/la/ubicacion/de/archivo 0000000100000037000000AF
```
El segundo argumento es el nombre del archivo WAL más antiguo que aún debe conservarse, no una antigüedad arbitraria. En la práctica, herramientas de copia de seguridad como pgBackRest, Barman y WAL-G son más seguras porque entienden la retención de copias de seguridad y el WAL necesario para la recuperación.

Importante: Asegúrate siempre de que tu estrategia de limpieza esté alineada con tus requisitos de copia de seguridad y recuperación a un punto en el tiempo (PITR). Necesitas retener archivos WAL el tiempo suficiente para cubrir tu ventana de recuperación deseada.

5. Monitoreo del espacio en disco y la tasa de generación de WAL

El monitoreo proactivo es clave para prevenir el agotamiento del espacio en disco.

Monitorear el espacio en disco: Rastrea el espacio libre en el directorio de datos, pg_wal, las ubicaciones de archivos temporales y los destinos de archivo.
Monitorear la generación de WAL: Usa diferencias de LSN a lo largo del tiempo para estimar la tasa de generación.
```
SELECT now() AS sample_time,
       pg_current_wal_lsn() AS current_lsn;
```
Almacena ese valor periódicamente y compara muestras con pg_wal_lsn_diff(new_lsn, old_lsn). Para una vista rápida del tamaño actual del directorio pg_wal:
```
SELECT pg_size_pretty(sum(size)) AS pg_wal_size
FROM pg_ls_waldir();
```

Pasos para solucionar problemas de discos llenos

Si tu disco ya está lleno debido a la actividad de WAL, se requiere acción inmediata:

Identificar la causa: Verifica pg_stat_archiver para fallos de archivado. Examina pg_replication_slots en busca de slots no utilizados o problemáticos. Verifica el retraso de replicación en los standbys.
Liberar espacio sin dañar la recuperación:
- No elimines archivos de pg_wal manualmente.
- Si el destino del archivo está lleno, elimina el WAL archivado antiguo solo cuando esté fuera de tu ventana de retención de copias de seguridad.
- Si es posible, agrega almacenamiento o mueve el destino del archivo, luego deja que PostgreSQL archive y recicle normalmente.
Abordar la causa raíz:
- Arreglar el archivado: Asegúrate de que archive_command sea correcto y que el destino tenga espacio.
- Gestionar slots: Elimina cualquier slot de replicación no utilizado.
- Arreglar la replicación: Aborda los problemas que causan el retraso del standby.
- Aumentar el espacio en disco: Agrega más almacenamiento temporal o permanentemente.
Empujar al archivador: Después de arreglar el comando de archivo o el destino, PostgreSQL debería reintentar. Una recarga puede ser suficiente para cambios de configuración; un reinicio completo debe ser el último recurso durante un incidente de disco.

Un modelo mental más seguro

Cuando pg_wal está creciendo, haz tres preguntas en orden:

¿Está PostgreSQL generando más WAL de lo habitual porque la carga de trabajo cambió?
¿PostgreSQL no puede archivar WAL?
¿Se le está diciendo a PostgreSQL que retenga WAL para replicación o un slot?

Esas respuestas apuntan a diferentes soluciones. Las escrituras masivas pueden necesitar programación, procesamiento por lotes o ajuste de puntos de control. Los fallos de archivo necesitan soluciones de almacenamiento y comandos. La retención de slots necesita recuperación del consumidor, limpieza del slot o un límite de retención. Adivinar con max_wal_size rara vez resuelve el problema real por sí solo.