Como comentamos en el post Posibles escenarios para actualización de RDS (AWS) a una major version, la fecha donde el extended support de RDS empezó a aplicarse provocó un aumento considerable de costes en muchos casos y esto derivó en un plan de actualización de la base de datos.
Fuente: AWS
En este artículo abordaremos un upgrade de MySQL 5.7 a MySQL 8 usando blue-green deployment, ya que el escenario no admitía casi afectación de escrituras y no se contemplaba el cambio de endpoint de la DB como opción, pues era muy costoso.
Fuente: AWS
Estas son las fases del proceso:
Fase de análisis
El primer paso fue usar la herramienta upgrade utility checker que nos puede desvelar cosas a corregir antes del update.
En nuestro caso aparecieron los siguientes errores:
- Uso de objetos de base de datos con nombres en conflicto con nuevas palabras reservadas.
- Uso del charset utf8.
- Tablas con redundant row format.
A nivel de código se comprobó que las nuevas palabras reservadas se escapaban con comillas.
A nivel de charset se comprobó la afectación y se decidió que el cambio de charset para las columnas afectadas se haría a posteriori.
A nivel de tabla se preparó el cambio a row format dynamic.
SELECT
CONCAT("ALTER TABLE `", table_schema, "`.`", table_name, "` ROW_FORMAT=DYNAMIC;")
FROM
information_schema.TABLES
WHERE
table_schema = 'project_production'
AND ROW_FORMAT <> 'Dynamic';
Fase de preparación
Para poder ejecutar cambios en la réplica green deberemos crear un parameter group copia de la blue donde le especifiquemos que no queremos que sea read only.
read_only {TrueIfReplica}
==>
read_only 0
También crearemos un parameter group para MySQL 8 con los valores de los parámetros modificados por el usuario en el parameter group de la blue y que no sea read only.
Fase de ejecución
- Crearemos el blue-green deployment
- Esperaremos a tener la base de datos ready.
- Una vez en estado ready ejecutaremos los cambios que hemos preparado.
- Y ejecutaremos el upgrade de versión.
Durante todo este proceso deberemos monitorizar el estado de la replicación básicamente con 2 métricas:
- Blue: BinLogDiskUsage es donde se guardan los eventos pendientes de replicar.
- Green: ReplicaLag es básicamente cuánta diferencia existe entre la réplica y el máster.
Fase de standby
Una vez acabado el upgrade de versión tenemos que revisar los eventos del blue-green para asegurarnos que todo estaba correcto.
En nuestro caso nos aparecieron transacciones con sintaxis inválida ya que la sintaxis de la transacción era exclusiva de la versión 5.7 o anteriores.
Esto nos obligó a revisar bien el entorno y, una vez identificadas las fuentes de estas transacciones, volvimos a ejecutar el plan otra vez hasta que la replicación fue correcta.
Fase de switch over
Llegados al punto donde la replicación es correcta y todo está listo ejecutamos el switch over y en 3 minutos tuvimos todo funcionando correctamente.
Fase de cleanup
Para finalizar, después de verificar el entorno y esperar un tiempo prudencial borramos el blue-green deployment y la instancia blue.
Fase de rollback
Esta fase, por suerte, no la tuvimos que ejecutar, pero en todo caso habíamos comprobado que si se modifica el nombre de la green y a la blue se la renombra con el nombre antiguo el endpoint original se mantendría, aunque habría una pérdida de datos igual al tiempo desde el switch over.
Resumen
El blue-green deployment es una muy buena herramienta para muchos escenarios y nos asegura tener muy poco downtime y prevenir errores en producción.
Cuando trabajas con datos críticos siempre hay que tener preparada la vuelta atrás.
Si tienes alguna pregunta o necesitas más detalles, no dudes en contactar con nosotros o dejar un comentario.
