Acerca de las implementaciones azul-verde en Cloud SQL

En este documento, se proporciona una descripción general de las implementaciones azul-verde de Cloud SQL, que te permiten realizar actualizaciones de bases de datos, como actualizaciones de versiones principales y modificaciones de hardware, y, al mismo tiempo, minimizar el tiempo de inactividad.

Intenciones y casos de uso de la Deployment

Puedes crear una implementación azul-verde con o sin la intención de realizar una actualización de versión principal:

  • Crear con intención (actualización de versión principal): Actualiza tu motor de base de datos a una versión principal más reciente. Durante la creación de la implementación, Cloud SQL ejecuta la API de verificación previa a la actualización de la versión principal para verificar la compatibilidad antes de continuar con el flujo de trabajo de actualización.
  • Crear sin intención (cambios de configuración o hardware): Organiza las modificaciones en la versión actual de la base de datos. Los casos de uso incluyen cambiar los tipos de máquinas (ajuste de CPU/RAM), probar marcas de bases de datos o evaluar modificaciones de almacenamiento sin actualizar la versión del motor.

Cómo funcionan las implementaciones azul-verde

Las implementaciones azul-verde de Cloud SQL proporcionan un flujo de trabajo automatizado que organiza los cambios en un entorno secundario temporal antes de cambiar el tráfico en vivo.

Durante una implementación azul-verde, Cloud SQL crea un entorno de pruebas independiente (verde) que refleja tu entorno de producción existente (azul). El servicio mantiene la replicación lógica continua de azul a verde. Puedes probar a fondo la compatibilidad y el rendimiento de la aplicación en el entorno verde sin afectar el tráfico de producción. Cuando esté todo listo, activa un cambio rápido que asigna el entorno verde al estado de lectura y escritura de producción con un tiempo de inactividad mínimo de la aplicación (por lo general, en segundos).

Componentes de una implementación azul-verde

Una implementación azul-verde consta de los siguientes componentes:

  • Entorno azul (origen): Es tu entorno de producción existente que publica tráfico de aplicaciones de forma activa. Consta de la instancia de lectura y escritura de la fuente y cualquier configuración asociada.
  • Entorno verde (destino): Es un entorno de pruebas aislado y temporal que Cloud SQL crea como clon del entorno azul. El entorno verde incorpora los cambios solicitados (como una versión de base de datos más reciente) y se mantiene sincronizado con el entorno azul a través de la replicación continua. Cloud SQL asigna automáticamente un nombre a la instancia de etapa de pruebas verde con el patrón BLUE_INSTANCE_NAME-green-UNIQUE_ID (donde BLUE_INSTANCE_NAME se trunca a un máximo de 48 caracteres y UNIQUE_ID es un identificador hexadecimal de 8 caracteres).

  • Cambio: Es el proceso planificado que inicia el usuario para convertir el entorno verde en la nueva instancia de producción de lectura y escritura. Durante la conmutación, Cloud SQL intercambia los extremos de conexión para que las aplicaciones se conecten al entorno verde con una breve interrupción de la conexión (por lo general, en segundos). El tiempo de inactividad esperado durante la conmutación por error varía según la edición de Cloud SQL:

    • Edición Enterprise Plus de Cloud SQL: El tiempo de inactividad por conmutación suele ser inferior a un segundo.
    • Edición de Cloud SQL Enterprise: El tiempo de inactividad por conmutación suele ser inferior a 60 segundos, según la carga de trabajo y el retraso de la replicación.

    A diferencia de una conmutación por error no planificada (que se activa automáticamente durante una interrupción), una conmutación es una operación controlada que se usa para la administración de cambios planificados.

  • Eliminación: Proceso de eliminación del recurso de implementación azul-verde. El comportamiento de eliminación difiere según si se produjo el cambio:

    • Antes del cambio: Borrar la implementación quita la instancia de etapa de pruebas verde y el recurso de implementación. Tu instancia de producción azul no se ve afectada y sigue publicando tráfico.
    • Después de la conmutación: Borrar la implementación quita los metadatos de la implementación. De forma predeterminada, se conservan tanto la instancia convertida (verde) como la instancia azul. De manera opcional, puedes borrar la instancia azul para evitar cargos continuos.

Ciclo de vida y estados de la Deployment

Una implementación azul-verde pasa por cuatro fases distintas del ciclo de vida:

  1. Creación y etapa de pruebas (PROVISIONING): Cuando solicitas una implementación azul-verde, Cloud SQL aprovisiona una instancia de destino verde temporal que clona tu entorno de producción azul. En el caso de una actualización de versión principal, Cloud SQL también ejecuta la API de verificación previa de la actualización de versión principal para validar la compatibilidad de la base de datos antes de continuar con el flujo de trabajo de actualización. Cloud SQL aplica la actualización o el cambio de configuración solicitados al entorno verde y comienza la replicación lógica continua del entorno azul al verde.
  2. Verificación de la etapa de pruebas (SWITCHOVER_READY o SWITCHOVER_NOT_READY): Cuando finaliza la replicación inicial, la implementación entra en SWITCHOVER_READY (o SWITCHOVER_NOT_READY si la replicación se interrumpe o si se producen errores). La implementación azul sigue publicando tráfico de producción en vivo. Te conectas a verde para ejecutar pruebas de validación, verificar la compatibilidad de la aplicación y probar el rendimiento de las consultas.
  3. Ejecución del cambio (SWITCHOVER_IN_PROGRESS o SWITCHOVER_COMPLETED): Cuando activas el cambio, Cloud SQL ejecuta verificaciones previas de seguridad, intercambia los extremos de conexión y establece la instancia verde como tu instancia activa de producción de lectura y escritura (SWITCHOVER_COMPLETED), y hace la transición de la instancia azul a una instancia independiente de lectura y escritura. Las operaciones de lectura y escritura activas se enrutan exclusivamente a la instancia verde, y se finaliza la replicación lógica de azul a verde. Para obtener más información, consulta Realiza una conmutación por error de implementación azul-verde.

  4. Borrado (DELETING): Cuando termines de hacer pruebas o después de verificar las operaciones de producción, borra el recurso de implementación. El comportamiento de eliminación difiere según el estado de implementación:

    • Antes del cambio (cancelación): Si decides no continuar con la implementación o si surgen problemas de verificación, borrar la implementación quita la instancia de etapa de pruebas verde y borra los metadatos de la implementación. La instancia de producción azul original permanece sin cambios y sigue publicando tráfico sin interrupciones.
    • Después de la conmutación (limpieza): Después de que se complete la conmutación y verifiques las operaciones en la nueva instancia de producción, borrar la implementación quitará los metadatos de la implementación. De forma predeterminada, tanto la nueva instancia de producción (verde) como la instancia azul se conservan como instancias independientes de lectura y escritura. De manera opcional, puedes especificar la marca --delete-old-source para borrar de forma permanente la instancia azul y dejar de generar cargos por ella.

    Para obtener más información, consulta Borra una implementación azul-verde.

Estados de los recursos de Deployment

Cuando inspeccionas una implementación azul-verde, el campo state indica su estado actual del ciclo de vida:

  • PROVISIONING: Se está creando la implementación. En el caso de las actualizaciones de versión principal, Cloud SQL ejecuta la API de verificación previa para validar la compatibilidad antes de continuar. Cloud SQL aprovisiona el entorno verde, aplica las actualizaciones solicitadas y configura la replicación lógica continua.
  • SWITCHOVER_READY: Se aprovisiona el entorno verde, la replicación lógica de azul a verde está en buen estado y la implementación está lista para la conmutación.
  • SWITCHOVER_NOT_READY: La implementación se aprovisionó, pero no se puede iniciar el cambio. Esto ocurre si la replicación lógica se interrumpe o se detiene, si no se completó la replicación inicial o si un nodo vinculado encontró un error.
  • SWITCHOVER_IN_PROGRESS: Se está ejecutando una operación de conmutación. Cloud SQL intercambia los extremos de conexión y convierte la instancia verde en la instancia activa de producción de lectura y escritura.
  • SWITCHOVER_COMPLETED: La operación de cambio se completó correctamente. La instancia verde ahora es tu instancia de producción activa de lectura y escritura, y la instancia azul se conserva como una instancia independiente de lectura y escritura.
  • DELETING: Se está borrando la implementación. Si se borra antes de la conmutación, Cloud SQL quita la instancia de etapa de pruebas verde y borra los metadatos de implementación. Si se borra después de la conmutación, Cloud SQL quita los metadatos de implementación y, de manera opcional, borra la instancia azul si se especifica la marca --delete-old-source.
  • STATE_UNSPECIFIED: Se desconoce el estado de la implementación.

Estados de cambio y preparación

La preparación para la conmutación depende del estado de replicación y del estado del nodo para proteger tu base de datos de producción contra la pérdida de datos o el tiempo de inactividad prolongado:

  • Estado y retraso de la replicación: Si la replicación lógica entre las versiones azul y verde se interrumpe, se pausa o falla, el estado de la implementación cambia a SWITCHOVER_NOT_READY. El resultado de la implementación state y de la descripción no informa el retraso de replicación, y Cloud SQL no evalúa el retraso de replicación como una verificación previa cuando determina el estado de la implementación. Sin embargo, la operación de cambio falla si el retraso de la replicación es demasiado alto cuando se inicia el cambio. Para garantizar que el cambio sea exitoso, asegúrate de que el retraso de la replicación sea mínimo antes de iniciar el cambio. Puedes supervisar el retraso de la replicación en Cloud Monitoring (consulta métricas como replica_lag en la lista de métricas de Cloud SQL) o directamente en la instancia verde. Para obtener más información, consulta Supervisa el retraso de la replicación.
  • Estado del nodo vinculado: En deploymentMappings, cada nodo vinculado informa su propio estado (como PROVISIONED, UPGRADED, UPGRADE_FAILED, SWITCHOVER_IN_PROGRESS, SWITCHOVER_SUCCEEDED o SWITCHOVER_FAILED). Si un nodo vinculado encuentra un error (UPGRADE_FAILED o SWITCHOVER_FAILED), el estado general de la implementación pasa a SWITCHOVER_NOT_READY. Si falla un cambio, el enrutamiento permanece en la instancia azul sin pérdida de datos.
  • Solución de problemas de preparación para el cambio: Si tu implementación informa SWITCHOVER_NOT_READY, verifica el campo errorDetail para diagnosticar errores de replicación o de nodos. Antes de iniciar la conmutación por error, asegúrate de que el retraso en la replicación sea mínimo y verifica que se hayan completado las operaciones DDL por lotes activas o las transacciones de escritura de larga duración en la instancia azul.

Limitaciones

Revisa las siguientes limitaciones antes de usar las implementaciones azul-verde:

  • Motores y versiones compatibles: Las instancias de Cloud SQL para MySQL en MySQL 5.7 y versiones posteriores son compatibles con la preparación de la configuración (creación sin intención). Las versiones principales de destino de actualización (creadas con intención) son compatibles con MySQL 8.0 a 8.4. MySQL 8.0.18 no es compatible con las implementaciones azul-verde.
  • Motores de bases de datos no compatibles: No se admiten Cloud SQL para PostgreSQL ni Cloud SQL para SQL Server.
  • Instancias con réplicas de lectura: Las implementaciones azul-verde no admiten instancias con réplicas de lectura.
  • Configuraciones de red no admitidas: Las implementaciones azul-verde no admiten configuraciones salientes de Private Service Connect.
  • Autenticación de grupos de IAM: Las implementaciones azul-verde son incompatibles con la autenticación de grupos de IAM de MySQL y pueden causar fallas en la conmutación.
  • Requisito de arquitectura de red: Las instancias de Cloud SQL deben usar la nueva arquitectura de red. No se admiten las instancias que usan la arquitectura de red anterior.
  • Requisito de registro binario: Las instancias de MySQL deben tener habilitadas las copias de seguridad automáticas y el registro binario para admitir la replicación lógica continua en el entorno verde.
  • Requisito de versión de mantenimiento: Tu instancia de origen azul debe ejecutar la versión de mantenimiento más reciente antes de que crees una implementación azul-verde. Para verificar o actualizar la versión de mantenimiento de tu instancia, consulta Realiza el mantenimiento de autoservicio.
  • Disponibilidad de recursos: El aprovisionamiento de instancias durante los flujos de trabajo de implementación azul-verde, incluida la creación de la instancia de etapa de pruebas verde y la creación de la instancia azul después de la conmutación, puede verse afectado por las restricciones de recursos de procesamiento en la zona o región seleccionada.
  • Interrupciones no planificadas y conmutación por error: El cambio de la implementación azul-verde es estrictamente una operación planificada que requiere una instancia de origen azul RUNNING en buen estado. La instancia de etapa de pruebas verde funciona como una réplica de lectura especializada. Al igual que las réplicas de lectura estándar, la instancia verde no se puede usar como destino de conmutación por error durante una interrupción no planificada de la instancia de origen. Para la recuperación automática ante interrupciones, configura tu instancia para la alta disponibilidad o usa una réplica de recuperación ante desastres (DR).

Facturación y precios

No se aplican cargos adicionales por usar implementaciones azul-verde. Sin embargo, como se aprovisiona un entorno verde paralelo completo durante la implementación, se te facturan las tarifas estándar por las instancias azules y verdes durante todo el tiempo que existan ambos entornos.

Para evitar cargos innecesarios, borra la implementación y las instancias asociadas:

  • Antes del cambio: Si cancelas la implementación, bórrala para quitar la instancia de etapa de pruebas verde y detener los cargos por ella.
  • Después de la conmutación: Borra la implementación y especifica la marca --delete-old-source para borrar de forma permanente la instancia azul después de verificar la nueva instancia de producción. Si no borras la instancia azul, se te seguirá facturando por ambas instancias.

¿Qué sigue?