La trampa del estado 'active' en PostgreSQL cuando el disco se llena

PostgreSQL estaba active. Nginx estaba active. PHP-FPM estaba active. Y aun así, la aplicación devolvía un HTTP 503. El autor de Dev.to recreó este escenario exacto en su laboratorio con Ubuntu y KVM para demostrar un error de diagnóstico común: asumir que el estado del proceso equivale a la salud del servicio. La causa raíz era un sistema de archivos lleno que respaldaba una tablespace de PostgreSQL, generando errores ENOSPC.

La arquitectura de prueba constaba de tres máquinas virtuales: un nodo web con Nginx y PHP-FPM, un nodo de base de datos con PostgreSQL 14 y un disco dedicado montado en /mnt/inc012-db, y un nodo de monitoreo con Prometheus y Alertmanager. Esta separación permitía simular presión de almacenamiento en la base de datos sin afectar el sistema de archivos raíz de la VM.

El experimento comienza estableciendo una línea base estable. El uso del disco de la base de datos era del 8,03 %, las escrituras funcionaban y Prometheus reportaba silencio en las alertas. Al llenar el disco de forma controlada, el sistema de monitoreo disparó la alerta DBDiskNearlyFull cuando el uso alcanzó el 88,49 %. Este es el momento crítico donde una monitorización efectiva debería permitir una ventana de intervención antes del fallo operativo, pero la aplicación seguía respondiendo con HTTP 200.

Al llegar al 100 % de ocupación, el comportamiento revela la fragilidad de las comprobaciones superficiales. El proceso de PostgreSQL seguía reportando active y aceptaba conexiones de red. Sin embargo, cualquier operación que requiriera asignar nuevos bloques en el sistema de archivos fallaba inmediatamente con el mensaje ERROR: could not extend file No space left on device. Los registros de PostgreSQL confirmaban la condición ENOSPC.

Aquí es donde la distinción técnica se vuelve operativa: la salud del proceso de PostgreSQL no garantiza la salud de las escrituras, ni estas garantizan la salud de la aplicación. Un administrador que detenga su investigación en systemctl is-active postgresql concluirá erróneamente que la base de datos está sana. De hecho, todos los procesos clave seguían vivos mientras la aplicación entraba en estado degradado.

El camino de resolución efectivo descrito requiere navegar hacia abajo por la cadena de dependencias. Ante el 503, verificar que Nginx y PHP-FPM están activos es solo el primer paso. Luego se confirma la conectividad a PostgreSQL. Si la conexión responde, el siguiente paso no es asumir funcionamiento, sino forzar una escritura de prueba. Cuando esa escritura falla con ENOSPC, la investigación se desplaza desde la red o la memoria hacia el almacenamiento físico de la tablespace específica.

La recuperación fue inmediata tras eliminar los datos de relleno generados artificialmente. No fue necesario reiniciar PostgreSQL. El uso del disco bajó al 8,27 %, las escrituras volvieron a funcionar y las alertas de Prometheus se silenciaron. El dato más relevante del ejercicio es que el proceso de la base de datos nunca se detuvo en ningún momento; la interrupción del servicio fue puramente lógica y operativa, derivada de la incapacidad de realizar operaciones de entrada/salida.

Este caso recuerda que el estado de systemd es solo una señal entre muchas. Para garantizar la disponibilidad, la monitorización debe verificar la capacidad funcional de las operaciones críticas, no solo la existencia del binario en memoria. Una base de datos que no puede escribir datos no es usable, independientemente de su estado activo.