Azure Database for PostgreSQL flexible server con pgbouncer failed en puerto 6432 post mantenimiento programado HJXF-S1Z

Hola @Guillermo Paez ,

El equipo de Producto (PG) respondió a las preguntas de seguimiento.

1. ¿Podría este problema volver a ocurrir durante futuras actualizaciones de mantenimiento?

El defecto específico que experimentó fue un error de código que provocó que el contenedor PgBouncer se iniciara con una configuración de red incorrecta en servidores con inyección de VNet y PgBouncer habilitado, pero únicamente cuando el servidor se actualizaba mediante el nuevo marco de implementación mejorado. Ahora existen dos medidas de protección:

• Se ha desarrollado una corrección permanente y se está implementando en producción. Una vez completado el despliegue, el error subyacente quedará eliminado y este modo de fallo ya no será aplicable.
• Mientras tanto, las actualizaciones para los servidores afectados (VNet-injected + PgBouncer) se están encaminando a través del marco de actualización anterior, que no se ve afectado por este error. Por lo tanto, incluso antes de que la corrección termine de implementarse, sus servidores estarán protegidos durante las ventanas de mantenimiento.

En resumen: este escenario no debería volver a ocurrir en sus servidores porque están siendo gestionados por el marco no afectado hasta que la corrección permanente quede implementada.

2. ¿Cómo podemos garantizar que un servicio de producción no se vea interrumpido en casos como este? Más importante aún, ¿cómo podemos evitar situaciones en las que no se nos notifique proactivamente de un problema y, en cambio, tengamos que abrir un ticket y esperar varios días para su resolución?

Algunas recomendaciones que reducen significativamente tanto el riesgo como el tiempo de detección:

• Configure ventanas de mantenimiento programadas en el servidor flexible para que el mantenimiento de la plataforma ocurra en un horario predecible y de baja actividad que usted controle, en lugar de durante el horario laboral.
• Habilite alertas de conectividad/disponibilidad, para que se le notifique en cuestión de minutos.

Reconocemos que la experiencia de detección reactiva no fue aceptable en este caso; las recomendaciones anteriores están dirigidas específicamente a cerrar esa brecha de su lado, mientras que la corrección de la plataforma la cierra del nuestro.

3. Para las próximas ventanas de mantenimiento, ¿podrían confirmar si es posible validar que el conector de red está funcionando correctamente antes de cerrar la actividad? En caso de cualquier problema, ¿se consideraría una reversión (rollback)?

Sí. La mitigación aplicada por el equipo de ingeniería fue precisamente este tipo de validación: verificar que el contenedor PgBouncer se iniciara con el modo de red correcto (del contenedor) y, si no era así, recrearlo correctamente. La corrección permanente garantiza que el contenedor se inicie con la configuración de red correcta desde el principio, y la validación de estado posterior a la actualización forma parte del marco de implementación en adelante.