Migraron una base de datos PostgreSQL con 11 segundos de downtime
(gds.blog.gov.uk)Cómo migraron una base de datos PostgreSQL
- GOV.UK Notify está trasladando toda su infraestructura a su propia cuenta de AWS porque el PaaS que usa actualmente será descontinuado.
- Este artículo explica cómo migraron una base de datos PostgreSQL con el menor downtime posible.
Migración de la base de datos
- Usan una base de datos AWS RDS PostgreSQL provista por el PaaS y necesitaban moverla a una nueva base de datos en su propia cuenta de AWS.
- El principal reto era configurar la nueva base de datos PostgreSQL y hacer que todas las apps se comunicaran con ella.
Más información sobre la base de datos de origen
- La base de datos de origen tiene un tamaño de alrededor de 400 GB, con 130 millones de filas, 85 tablas, 185 índices y 120 claves foráneas.
- En días hábiles se realizan alrededor de 1,000 inserciones o actualizaciones por segundo, y GOV.UK Notify envía millones de notificaciones importantes y oportunas cada día.
AWS Database Migration Service
- Usaron AWS Database Migration Service (DMS) para transferir los datos desde la base de datos de origen hacia la base de datos de destino.
- DMS copia todos los datos hasta un momento específico mediante una tarea de "full load" y, en modo de replicación, hace que todas las transacciones nuevas de la base de datos de origen se reflejen en la base de datos de destino.
Proceso de migración de la base de datos
Configuración de la instancia de DMS
- Crearon una instancia de DMS en la cuenta de AWS de origen y le dieron credenciales de PostgreSQL con acceso tanto a la base de datos de origen como a la de destino.
Configuración de la base de datos de destino
- Crearon la instancia RDS de destino en su propia cuenta de AWS y actualizaron la versión de PostgreSQL a la 15.
- Usaron
pg_dumppara volcar el esquema de la base de datos de origen y aplicaron las definiciones de tablas en la base de datos de destino.
Full load
- Después de crear las tablas en la base de datos de destino, iniciaron la tarea de full load de DMS, que terminó en unas 6 horas.
- Una vez completada la tarea de full load, agregaron los índices y las restricciones de claves.
Replicación
- Tras completar la tarea de full load, iniciaron la tarea de replicación continua de DMS (change data capture) para sincronizar la base de datos de origen con la de destino.
Preparación para migrar el tráfico
- Planearon el proceso para que la app dejara de comunicarse con la base de datos de origen y comenzara a comunicarse con la base de datos de destino.
Interrupción del tráfico hacia la base de datos de origen
- Usaron un script para detener todo el tráfico hacia la base de datos de origen.
Verificación de la replicación
- Confirmaron que la base de datos de destino estuviera completamente sincronizada.
Cambio fluido del tráfico
- Proporcionaron mediante variables de entorno la ubicación, el nombre de usuario y la contraseña que la app necesitaba para conectarse a la base de datos, y cambiaron rápidamente de base de datos mediante un cambio de DNS.
Lo que pasó el día de la migración
- Ejecutaron con éxito el script de migración para que la app dejara de comunicarse con la base de datos de origen y empezara a hacerlo con la nueva base de datos de destino.
- Durante la migración hubo un breve downtime de aproximadamente 11 segundos.
Lecciones aprendidas
- Eligieron usar DMS porque estaba bien soportado en GOV.UK PaaS y también podían recibir apoyo de AWS.
- Si en el futuro realizan otra migración de base de datos entre instancias de PostgreSQL, dedicarán más tiempo a probar otras herramientas como pglogical.
Próximos pasos en la migración de GOV.UK Notify a AWS
- Después de completar la migración de la base de datos, planean mover la app a AWS Elastic Container Service (ECS).
Opinión de GN⁺:
- Lo más importante de este artículo es que el equipo de GOV.UK Notify migró con éxito una base de datos PostgreSQL usando AWS Database Migration Service (DMS).
- Este artículo ofrece una guía útil basada en un caso real para profesionales técnicos que estén planeando una migración de base de datos.
- También aporta ideas sobre cómo minimizar el downtime y mantener la consistencia de los datos durante la migración, lo que puede ayudar a otras organizaciones o personas que enfrenten una situación similar.
1 comentarios
Opiniones de Hacker News
Cuestiona por qué el gobierno usa AWS, y sostiene que construir una nube para el sector público o adoptar un enfoque on-premises podría reducir el desperdicio de impuestos a largo plazo.
Comparte la experiencia de haber realizado con éxito una migración de base de datos usando AWS RDS Blue-Green Deployments con aproximadamente 20 segundos de downtime.
Menciona varias formas de pausar consultas de PostgreSQL y explica que se puede reducir el downtime retrasando las consultas hasta que la replicación se ponga al día.
Describe el proceso de migrar una base de datos PostgreSQL autohospedada de la versión 12 a la 16, y comparte que hubo alrededor de 30 minutos de downtime por problemas inesperados.
Señala que usar AWS Database Migration Service y cambiar la entrada DNS, aceptando 11 segundos de downtime, es una forma de evitar complejidad.
Indica que las consultas de larga duración son el enemigo de las migraciones de bajo downtime, y explica la dificultad de manejar ese tipo de consultas.
Comparte el proceso de migración de PostgreSQL 14 a 16 y menciona que la próxima vez planea usar AWS Blue-Green Deployments para evitar downtime.
Explica cómo, usando registros DNS de AWS Route53, el script de migración de base de datos actualiza el peso del DNS y espera a que expire un TTL de 1 segundo.
Hace una broma sobre esperar que Amazon lance un producto de "gobierno-como-servicio".
Comparte la experiencia de migrar un dataset desde AWS RDS MySQL a RDS PostgreSQL usando AWS DMS, y no recomienda usar la herramienta de conversión de esquemas.