Debido al calendario de soporte de versiones de DB de RDS de AWS muchos clientes se han visto obligados a plantear una actualización exprés de versión, ya que el coste que implicaba quedarse con el soporte extendido se acercaba en muchos casos al doble de meses anteriores.
Fuente: AWS
Fuente: AWS
Teniendo en cuenta la naturaleza de negocio, las aplicaciones de cada cliente y las ventanas de mantenimiento posibles hemos contemplado los siguientes escenarios:
Método |
Procedimiento |
Consideraciones |
Actualización directa |
1. Snapshot de la DB.
2. Paro de la plataforma. 3. Upgrade de la versión |
Ventajas
– El endpoint de la DB se mantiene por lo que no hay que hacer cambios de hostname en la connection string (la aplicación debe ser capaz de reconectar automáticamente). – A nivel de costes no hay impacto, pues el número de instancias siempre es el mismo Desventajas – El downtime de la plataforma es considerable. – En caso de rollback cambiaría el endpoint de la DB y el tiempo de indisponibilidad sería el que tarde en restaurar el snapshot y cambiar el hostname de la connection string en la plataforma. |
Actualización en nueva instancia |
1. Snapshot de la DB.
2. Paro de aplicaciones de escritura. 3. Restauración del snapshot en una nueva DB. 4. Upgrade de la versión. 5. Cambio del hostname de la connection string. |
Ventajas
– La indisponibilidad solo afecta a los procesos de escritura de la plataforma. – En caso de rollback podemos usar la base de datos original, pero deberemos cambiar el endpoint de la DB. Desventajas – El endpoint de la DB cambia y hay que hacer cambios de hostname en la connection string (la aplicación debe ser capaz de reconectar automáticamente). – A nivel de costes se pagará el doble de la instancia original durante el tiempo que la instancia secundaria esté activa. |
Actualización vía blue-green deployment |
1. Creación del blue-green.
2. Upgrade de la version. 3. Switch over del tráfico.
|
Ventajas
– Permite mantener las escrituras aun con versiones de la base de datos diferentes. – El endpoint de la DB se mantiene, por lo que no hay que hacer cambios de hostname en la connection string (la aplicación debe ser capaz de reconectar automáticamente). – La plataforma no se ve casi afectada por indisponibilidad ya que el switch over se realiza en 30 segundos si las bases de datos están sincronizadas. Desventajas – En caso de entornos con mucha transacción es posible que se produzcan retrasos importantes de replicación ya que la réplica no puede seguir el ritmo de la instancia principal. – En caso de rollback deberemos ejecutar un procedimiento manual para seguir manteniendo el endpoint de la base de datos y puede haber pérdida de datos, ya que en el momento que ejecutamos el switch las escrituras dejan de replicar. – A nivel de costes se pagará el doble de la instancia original durante el tiempo que la instancia secundaria esté activa. |
Dependiendo de los límites y requisitos de nuestros entornos elegiremos un escenario u otro.
En nuestro próximo artículo analizaremos el upgrade de MySQL a la versión 8 siguiendo la estrategia de blue-green deployment.
Si tienes alguna pregunta o necesitas más detalles, no dudes en contactar con nosotros o dejar un comentario.
