Una empresa de SaaS experimentó una interrupción total de las operaciones de escritura en su base de datos PostgreSQL debido a un problema de 'transaction ID wraparound'. Este fallo, que bloqueó la base de datos en modo de solo lectura, no fue causado por una alta carga, problemas de infraestructura o cambios recientes, sino por una decisión de configuración previa: la desactivación de autovacuum en varias tablas para resolver un problema de I/O. La desactivación, que se mantuvo durante años, impidió que PostgreSQL 'congelara' versiones antiguas de datos, permitiendo que los IDs de transacción alcanzaran un límite crítico. El problema es sutil, ya que la base de datos puede operar normalmente durante meses o años mientras se acerca silenciosamente al límite, sin mostrar signos de advertencia tradicionales. La recuperación requirió una intervención manual intensiva para forzar el 'freeze' de transacciones y avanzar los IDs. El incidente subraya la importancia de monitorear la salud de los IDs de transacción y la necesidad de reevaluar decisiones de configuración antiguas, incluso si parecen inofensivas a corto plazo, para evitar fallos catastróficos en entornos de producción.
Noticias agregadas con IA