Actualización de Postgres sin tiempo de inactividad

Preparación para la actualización de Postgres

• Evaluación de riesgos: elaborar una lista de los riesgos que pueden surgir durante el proceso de actualización y ordenarlos según su importancia.
• Búsqueda de soluciones para los riesgos: considerar soluciones que eliminen por completo los riesgos o que permitan distribuirlos a lo largo del tiempo.
• Actualización de la lista de riesgos: actualizar la lista cuando se descubran nuevos riesgos durante el avance del proyecto.

Sobre monitoreo y métricas

• Monitoreo del sistema: usar herramientas exhaustivas para monitorear la salud de la base de datos y del sistema.
• Observación de métricas clave: monitorear métricas principales como ID de transacción, uso de CPU, sesiones en espera, latencia de consultas y latencia de respuesta de la API.

Opciones de actualización de Postgres

Actualización in-place (no adecuada para una actualización con cero downtime)

• Limitaciones de la actualización in-place: al ejecutarse en AWS RDS se requiere reiniciar la base de datos, y el tiempo necesario depende de la cantidad de datos.

Actualización basada en replicación

• Elección de la actualización basada en replicación: permite una migración gradual, probar la nueva base de datos con carga de trabajo y datos reales, y obtener mayor control sobre la actualización.
• Configuración de la base de datos de origen y destino: configurar el slot de replicación y establecer wal_level en logical.

Elección del método de replicación de tablas

Replicación de tablas "pequeñas"

• Replicación de tablas pequeñas: se pueden replicar con una adición simple y una actualización de la suscripción.

Tablas grandes de solo anexado

• Replicación de tablas de solo anexado: establecer la opción copy_data en false para replicar solo los cambios futuros y luego rellenar los datos anteriores desde un respaldo.

Tablas grandes con muchas actualizaciones

• Replicación de tablas grandes con muchas actualizaciones: reducir el tamaño de la tabla, ejecutar VACUUM y considerar la partición de tablas.

Verificación del estado de replicación de tablas

• Monitoreo del estado de replicación: verificar el estado de replicación mediante la tabla del sistema pg_subscription_rel; se recomienda replicar una tabla a la vez.

Interrupción de la replicación

• Cómo detener la replicación: si es necesario, se puede detener la replicación de tablas y hacer rollback actualizando la suscripción.

Precaución sobre la migración de slots de replicación

• Problema al migrar slots de replicación: el LSN de un slot de replicación es único de la base de datos principal, por lo que no se puede copiar directamente a una base de datos nueva.

Cierre de la migración

• Verificación de consistencia de tablas: confirmar que el número de filas de las tablas coincida entre ambas bases de datos y, si hace falta, validar la consistencia de los datos con muestreo aleatorio.

Cambios a nivel de aplicación

• Cambio de conexión de base de datos: modificar la aplicación para que se conecte a la nueva base de datos y definir una estrategia de cambio de tráfico.

Consideraciones adicionales sobre secuencias

• Sincronización de secuencias: como los valores de las secuencias no se sincronizan durante la replicación, deben establecerse manualmente.

Checklist de revisión final

• Revisión final: consistencia de tablas, estado de la suscripción, coincidencia del esquema, tamaño de la base de datos, adición de réplicas, reconstrucción de índices, pruebas de rendimiento, evaluación de riesgos y práctica en un entorno de staging.

Cambio final

• Ejecución del cambio final: replicar tablas en horario nocturno, practicar varias veces en el entorno de staging y luego realizar la revisión final y el cambio de flags.

Opinión de GN⁺

• Importancia: Knock completó con éxito el complejo proceso de actualizar Postgres de la versión 11.9 a la 15.3 con cero downtime. Esto marca un hito importante en la administración de bases de datos y la disponibilidad del servicio.
• Interés: el enfoque de actualización basado en replicación permite a los administradores de bases de datos hacer una transición fluida hacia una nueva base de datos, algo que puede generar gran interés en la comunidad técnica.
• Lo destacable: el proceso de actualización de Knock muestra un caso ejemplar de cómo superar desafíos técnicos complejos mediante una gestión sistemática de riesgos y resolución de problemas.

[GN⁺]

Opiniones en Hacker News

• Existe una mejor forma que copiar tablas de gran tamaño.

  • Se puede crear una réplica lógica mediante la creación de un replication slot, la obtención de un snapshot, la restauración de ese snapshot en una nueva instancia, avanzar el LSN e iniciar la replicación.
  • Un artículo de Instacart explica este proceso.
  • Puede que el artículo tenga pequeños errores, pero se ha usado con éxito varias veces para actualizar instancias de tamaño TB.

• El enfoque presentado aquí es interesante y está bien documentado, pero no están de acuerdo con la frase "los clientes modernos esperan 100% de disponibilidad".

  • Según su experiencia como clientes o proveedores, la consistencia es mucho más importante que la disponibilidad.
  • Cuando un vendor anuncia downtime, lo toman como una señal de que está manejando los datos con cuidado y eso les da tranquilidad.

• AWS ahora ya soporta despliegues blue-green.

• Escribieron una herramienta que automatiza la mayoría de los problemas.

  • La herramienta se comparte en GitHub y se puede ampliar con feedback o ideas.

• En hava.io están migrando de AWS RDS PostgreSQL 11.13 a 15.5.

  • Eligieron un método de replicación unidireccional usando pglogical.
  • Este método no es rápido, pero puede tardar varios días en replicar gradualmente la base de datos a la nueva instancia.
  • Ofrece más libertad para cambiar el tipo y el tamaño del almacenamiento.

• Expresan dudas sobre la afirmación de que cualquier downtime sería inaceptable para el servicio Knock.

  • Los sistemas complejos tienen incidentes y downtime.
  • Un downtime de 15 minutos anunciado con anticipación no sería un problema para la mayoría de los negocios SaaS.
  • Invertir tiempo de ingeniería en desarrollar el producto o mejorar la velocidad del equipo de desarrollo podría dar más satisfacción a los usuarios.
  • En migraciones de bases de datos, hay una gran diferencia en la carga de trabajo entre lograr "poco downtime" y una migración de "cero downtime".

• Les sorprende que no se pueda inicializar la replicación desde un backup.

  • Eso habría reducido la molestia de hacer streaming del contenido de una DB estable existente hacia un nuevo servidor.
  • Dicen "cero downtime", pero en realidad hay unos segundos de downtime al cambiar al nuevo servidor.
  • Faltan detalles sobre cómo mantener la consistencia.
  • No se menciona ninguna opción de rollback, y al hacer una tarea única de migración para grandes volúmenes de datos siempre hace falta un plan para volver al estado anterior.

• Preguntan si hay interés en una herramienta todo en uno que permita actualizar Postgres con cero downtime solo ingresando las credenciales de la base de datos.

• Les parece interesante el tema del uso de secuencias.

  • En lugar de secuencias, suelen usar UUID secuenciales o el algoritmo HiLo.

• Bromean con que los problemas que surgen en sistemas distribuidos se pueden resolver con un adecuado sleep(1000).

  • Postgres no es un sistema familiar para los DBA, pero está mejor que antes.