Pasar de MySQL 8.0 a 8.4 en Cloud SQL ya no exige una ventana de mantenimiento de varias horas un sábado de madrugada. Desde el 28 de octubre de 2026, Cloud SQL para MySQL ofrece en preview despliegues blue-green gestionados: una copia actualizada que se mantiene sincronizada con producción, se prueba con tráfico real y toma el relevo en segundos sin cambiar la IP ni el nombre de la instancia. Es lo que Amazon RDS tiene desde noviembre de 2022.
Qué cambia
Hasta ahora, una actualización de versión mayor en Cloud SQL era in place: la instancia se paraba mientras se actualizaba, y si algo salía mal, volver atrás significaba restaurar un backup durante horas. Con blue-green el proceso se divide en tres fases:
- Azul: la instancia de producción sigue sirviendo tráfico sin interrupción.
- Verde: Cloud SQL crea un clon temporal, lo actualiza a la versión destino y lo mantiene al día con replicación continua. Puedes lanzar contra él consultas y tráfico real de la aplicación; si algo no cuadra, borras el despliegue sin tocar producción.
- Switchover: Cloud SQL pone el azul brevemente en solo lectura, termina la última sincronización y promueve el verde como nuevo primario. La IP, el nombre de la instancia y los backups pasan al verde, así que las cadenas de conexión no cambian.
El antiguo azul se conserva como respaldo manual hasta que lo borras. Sirve para actualizaciones de versión mayor y para cambios de configuración, en instancias primarias de MySQL independientes, también con alta disponibilidad. PostgreSQL llegará más adelante, según Google.
Cómo se hace
Además de la consola, todo el ciclo está en gcloud. Estos son los comandos del anuncio para una actualización de 8.0 a 8.4:
# Crea el entorno verde, actualizado y sincronizado
gcloud sql blue-green-deployments create my-upgrade \
--source-instance=prod-mysql-db \
--target-database-version=MYSQL_8_4
# Comprueba el estado y obtén el endpoint de pruebas
gcloud sql blue-green-deployments describe my-upgrade \
--region=us-central1
# Conéctate a la copia actualizada y pruébala
gcloud sql connect TARGET_INSTANCE_NAME --user=admin
# Pasa el tráfico de producción al verde
gcloud sql blue-green-deployments switchover my-upgrade
# Borra el antiguo azul cuando ya no lo necesites
gcloud sql blue-green-deployments delete my-upgrade \
--region=us-central1 \
--delete-old-sourceEntre el describe y el switchover está la parte que justifica todo esto: apuntar un entorno de staging o una réplica de tu carga al verde y comparar planes de consulta, latencias y errores con la versión nueva antes de que lo note ningún cliente.
Cloud SQL frente a Amazon RDS
| Cloud SQL (MySQL) | Amazon RDS / Aurora | |
|---|---|---|
| Disponible | Preview, desde el 28/10/2026 | GA desde el 27/11/2022 |
| Motores | MySQL; PostgreSQL anunciado | Aurora MySQL, RDS for MySQL, RDS for MariaDB (en el lanzamiento) |
| Corte anunciado | "En segundos" | "En apenas un minuto" |
| Endpoint | Conserva IP, nombre y backups | Sin cambios en el código de la aplicación |
| Protección | Borrar el verde antes del switchover | Guardrails: cancela el switchover si supera un timeout |
| Coste del verde | No detallado en el anuncio | Se paga como cualquier otra instancia |
Google llega cuatro años tarde, pero con un detalle a favor: que la IP y el nombre se traspasen evita tocar secretos, DNS internos o la configuración del Cloud SQL Auth Proxy. A cambio, RDS tiene la ventaja de la madurez y de los guardrails, que abortan el switchover si va a tardar más de lo que has fijado; el anuncio de Cloud SQL no menciona nada equivalente.
Trampas y casos límite
- La ventana de solo lectura existe. Aunque dure segundos, durante el switchover las escrituras fallan. Comprueba que tu aplicación reintenta escrituras y que ningún job crítico (colas, cron de facturación) coincide con el corte.
- Volver atrás no es simétrico. Antes del switchover, cancelar es gratis. Después, el antiguo azul solo es un respaldo manual: las escrituras que ya han entrado en el verde no están en él.
- Dos instancias a la vez. El verde es un clon completo del azul, así que mientras dure la prueba tienes el doble de capacidad en marcha. Planifica pruebas cortas y no olvides el
deletecon--delete-old-source. - Es preview. Para una base de datos crítica, haz primero el ensayo completo con una instancia de staging.