Cambio de una implementación azul/verde - Amazon Aurora
Tiempo de espera de la conmutaciónBarreras de protección de la conmutaciónAcciones de conmutaciónPrácticas recomendadas para realizar la conmutaciónVerificación de las métricas de CloudWatch antes de la conmutaciónMonitoreo del retardo de réplica antes de la transiciónConmutación de una implementación azul/verdeDespués de la conmutación

Cambio de una implementación azul/verde

Una conmutación hace que el clúster de base de datos, incluidas sus instancias de base de datos, en el entorno verde se convierta en el clúster de base de datos de producción. Antes de conmutar, el tráfico de producción se dirige al clúster en el entorno azul. Tras conmutar, el tráfico de producción se dirige al clúster de base de datos en el entorno verde.

Tiempo de espera de la conmutación

Puede especificar un tiempo de espera para la conmutación de entre 30 y 3600 segundos (una hora). Si la conmutación dura más de lo especificado, los cambios se revierten y no se realiza ningún cambio en ninguno de los entornos. El valor predeterminado del tiempo de espera es de 300 segundos (cinco minutos).

Barreras de protección de la conmutación

Al iniciar una conmutación, Amazon RDS realiza algunas comprobaciones básicas para comprobar si los entornos azul y verde están preparados para ella. Estas comprobaciones se conocen como barreras de protección de la conmutación. Estas barreras de protección de la conmutación evitan que este se realice si los entornos no están preparados para ello. Por lo tanto, evitan que haya tiempos de inactividad más prolongados de lo esperado y evitan la pérdida de datos entre los entornos azul y verde que podría producirse si se iniciara la conmutación.

Amazon RDS ejecuta las siguientes comprobaciones de barreras de protección en el entorno verde:

  • Estado de la replicación: comprueba si el estado de replicación del clúster de bases de datos es correcto. El clúster de base de datos verde es una réplica del clúster de base de datos azul.

  • Retraso de replicación: comprueba si el retraso del clúster de bases de datos verde está dentro de los límites permisibles para la transición. Los límites permitidos se basan en el tiempo de espera especificado. El retardo de la réplica indica qué retardo tiene el clúster de base de datos verde con respecto al clúster de base de datos azul. Para obtener más información, consulte Diagnóstico y resolución de retardos entre réplicas de lectura para Aurora MySQL y Monitoreo de replicación de Aurora PostgreSQL para Aurora PostgreSQL.

  • Escrituras activas: asegúrese de que no haya escrituras activas en el clúster de bases de datos verde.

Amazon RDS ejecuta las siguientes comprobaciones de barreras de protección en el entorno azul:

  • Replicación externa: en el caso de Aurora PostgreSQL, se asegura de que el entorno azul no sea un origen lógico autoadministrado (publicador) o una réplica (suscriptor). Si es así, le recomendamos que elimine las ranuras de replicación autoadministradas y las suscripciones en todas las bases de datos del entorno azul, proceda con la transición y, a continuación, vuelva a crearlos para reanudar la replicación. En el caso de Aurora MySQL, comprueba si la base de datos azul no es una réplica binlog externa. Si es así, asegúrese de que no se esté replicando activamente.

  • Escrituras activas de ejecución prolongada: asegúrese de que no haya escrituras activas de ejecución prolongada en el clúster de bases de datos azul, ya que pueden aumentar el retardo de la réplica.

  • Instrucciones DDL de ejecución prolongada: asegúrese de que no haya instrucciones DDL de ejecución prolongada en el clúster de bases de datos azul, ya que pueden aumentar el retardo de la réplica.

  • Cambios en PostgreSQL no compatibles: en el caso de los clústeres de bases de datos de Aurora PostgreSQL, se asegura de que no se haya habido cambios de DDL ni adiciones o modificaciones de objetos grandes en el entorno azul. Para obtener más información, consulte Limitaciones de la replicación lógica de PostgreSQL para las implementaciones azul/verde.

    Si Amazon RDS detecta cambios no compatibles en PostgreSQL, cambia el estado de la replicación a Replication degraded y le notifica de que la transición no está disponible para la implementación azul/verde. Para continuar con la transición, le recomendamos que elimine y vuelva a crear la implementación azul/verde y todas las bases de datos verdes. Para ello, seleccione Acciones, Eliminar con bases de datos verdes.

Acciones de conmutación

Al conmutar una implementación azul/verde, RDS realiza las siguientes acciones:

  1. Realiza comprobaciones de barreras de protección para verificar si los entornos azul y verde están listos para la conmutación.

  2. Detiene las nuevas operaciones de escritura en el clúster de base de datos en ambos entornos.

  3. Elimina las conexiones a las instancias de base de datos en ambos entornos y no permite nuevas conexiones.

  4. Espera a que la replicación alcance el entorno verde para que el entorno verde esté sincronizado con el entorno azul.

  5. Cambia el nombre del clúster y las instancias de base de datos en ambos entornos.

    RDS cambia el nombre del clúster y las instancias de base de datos del entorno verde para que coincidan con el del clúster y las instancias de base de datos del entorno azul. Por ejemplo, suponga que el nombre de una instancia de base de datos en el entorno azul es mydb. Suponga también que el nombre de la instancia de base de datos correspondiente en el entorno verde es mydb-green-abc123. Durante la conmutación, el nombre de la instancia de base de datos del entorno verde se cambia a mydb.

    RDS cambia el nombre del clúster y las instancias de base de datos en el entorno azul añadiendo -oldn al nombre actual, donde n es un número. Por ejemplo, suponga que el nombre de una instancia de base de datos en el entorno azul es mydb. Tras la conmutación, el nombre de la instancia de base de datos puede ser mydb-old1.

    RDS también cambia el nombre de los puntos de conexión del entorno verde para que coincidan con los puntos de conexión correspondientes del entorno azul, de modo que no sea necesario realizar cambios en la aplicación.

  6. Permite conexiones a bases de datos en ambos entornos.

  7. Permite operaciones de escritura en el clúster de base de datos del nuevo entorno de producción.

    Tras la conmutación, el clúster de base de datos de producción anterior solo permite operaciones de lectura. Incluso si deshabilita el parámetro read_only en el clúster de base de datos, permanece como de solo lectura hasta que elimine la implementación azul/verde.

Puede supervisar el estado de una conmutación mediante Amazon EventBridge. Para obtener más información, consulte Eventos de implementación azul/verde.

Si tiene etiquetas configuradas en el entorno azul, estas etiquetas se copian en el nuevo entorno de producción durante la transición. Para obtener más información acerca de las etiquetas, consulte Etiquetado de recursos de Amazon RDS.

Si se inicia la conmutación y, a continuación, se detiene antes de finalizar por cualquier motivo, los cambios se revierten y no se realiza ningún cambio en ninguno de los entornos.

Prácticas recomendadas para realizar la conmutación

Antes de la transición, le recomendamos encarecidamente que siga los procedimientos recomendadas y complete las siguientes tareas:

  • Pruebe minuciosamente los recursos en el entorno verde. Asegúrese de que funcionan de manera adecuada y eficiente.

  • Supervise las métricas relevantes de Amazon CloudWatch. Para obtener más información, consulte Verificación de las métricas de CloudWatch antes de la conmutación.

  • Identifique el mejor momento para realizar la conmutación.

    Durante la conmutación, las escrituras se interrumpen en las bases de datos de ambos entornos. Identifique un momento en el que el tráfico sea menor en su entorno de producción. Las transacciones de larga duración, como las DDL activas, pueden aumentar el tiempo de la conmutación, lo que se traduce en un tiempo de inactividad más prolongado para las cargas de trabajo de producción.

    Si hay una gran cantidad de conexiones en el clúster de base de datos y las instancias de base de datos, considere la posibilidad de reducirlas manualmente hasta la cantidad mínima necesaria para su aplicación antes de cambiar a la implementación azul/verde. Una forma de lograrlo consiste en crear un script que supervise el estado de la implementación azul/verde y comience a limpiar las conexiones cuando detecte que el estado ha cambiado a SWITCHOVER_IN_PROGRESS.

  • Asegúrese de que el clúster y las instancias de base de datos de ambos entornos se encuentren en el estado Available.

  • Asegúrese de que el clúster de base de datos del entorno verde se encuentre en buen estado y se esté replicando.

  • Asegúrese de que las configuraciones de red y cliente no aumenten el tiempo de vida (TTL) de la caché de DNS más de cinco segundos, que es el valor predeterminado para las zonas DNS de Aurora.
 De lo contrario, las aplicaciones seguirán enviando tráfico de escritura al entorno azul después del cambio.

  • Para los clústeres de base de datos Aurora PostgreSQL, haga lo siguiente:

nota

Durante una conmutación, no puede modificar ningún clúster de base de datos incluido en la conmutación.

Verificación de las métricas de CloudWatch antes de la conmutación

Antes de conmutar una implementación azul/verde, le recomendamos que compruebe los valores de las siguientes métricas en Amazon CloudWatch.

  • DatabaseConnections: utilice esta métrica para calcular el nivel de actividad de la implementación azul/verde y asegúrese de que el valor esté en un nivel aceptable para su implementación antes de realizar la conmutación. Si Información sobre rendimiento está activado, DBLoad es una métrica más precisa.

  • ActiveTransactions: si innodb_monitor_enable está configurado en all en el grupo de parámetros de base de datos para cualquiera de sus instancias de base de datos, utilice esta métrica para comprobar si hay un número elevado de transacciones activas que puedan impedir la conmutación.

Para obtener más información sobre estas métricas, consulte Métricas de Amazon CloudWatch para Amazon Aurora.

Monitoreo del retardo de réplica antes de la transición

Antes de conmutar una implementación azul/verde, asegúrese de que el retardo de réplica en la base de datos verde esté próximo a cero para reducir el tiempo de inactividad.

  • En Aurora MySQL, utilice la métrica AuroraBinlogReplicaLag de CloudWatch para identificar el retardo de replicación actual en el entorno verde.

  • Para Aurora PostgreSQL, utilice la siguiente consulta SQL:

    SELECT slot_name,
       confirmed_flush_lsn as flushed,
       pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lsn_distance
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical';

slot_name        |    flushed    | pg_current_wal_lsn | lsn_distance
-----------------+---------------+--------------------+------------
logical_replica1 | 47D97/CF32980 | 47D97/CF3BAC8      | 37192

    confirmed_flush_lsn representa el número de secuencia de registro (LSN) más reciente que se envió a la réplica. pg_current_wal_lsn representa la ubicación actual de la base de datos. Un valor 0 en lsn_distance significa que la réplica está funcionando al mismo ritmo.

Conmutación de una implementación azul/verde

Puede conmutar una implementación azul/verde mediante la AWS Management Console, la AWS CLI o la API de RDS.

Para conmutar una implementación azul/verde

  1. Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

  2. En el panel de navegación, elija Databases (Bases de datos) y, a continuación, seleccione la implementación azul/verde que desee conmutar.

  3. En Actions (Acciones), elija Switch over (Conmutar).

    Aparece la página Switch over (Conmutar).

    Conmutar una implementación azul/verde

  4. En la página Switch over (Conmutar), consulte el resumen de la conmutación. Asegúrese de que los recursos de ambos entornos coincidan con lo que espera. Si no es así, seleccione Cancel (Cancelar).

  5. En Ajustes de tiempo de espera, introduzca el límite de tiempo para la transición.

  6. Si el clúster ejecuta Aurora PostgreSQL, revise y confirme las recomendaciones previas a la transición. Para obtener más información, consulte Limitaciones de la replicación lógica de PostgreSQL para las implementaciones azul/verde.

  7. Elija Switch over (Conmutar).

Para conmutar una implementación azul/verde mediante la AWS CLI, utilice el comando switchover-blue-green-deploy con las siguientes opciones:

  • --blue-green-deployment-identifier: especifique el ID de recurso de la implementación azul/verde.

  • --switchover-timeout: especifique el límite de tiempo para la conmutación, en segundos. El valor predeterminado es 300.

ejemplo Conmutar una implementación azul/verde

Para Linux, macOS o Unix:

aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-1234567890abcdef \
    --switchover-timeout 600

En Windows:

aws rds switchover-blue-green-deployment ^
    --blue-green-deployment-identifier bgd-1234567890abcdef ^
    --switchover-timeout 600

Para conmutar una implementación azul/verde mediante la API de Amazon RDS, utilice la operación SwitchoverBlueGreenDeployment con los siguientes parámetros:

  • BlueGreenDeploymentIdentifier: especifique el ID de recurso de la implementación azul/verde.

  • SwitchoverTimeout: especifique el límite de tiempo para la conmutación, en segundos. El valor predeterminado es 300.

Después de la conmutación

Tras una conmutación, se conservan el clúster y las instancias de base de datos del entorno azul anterior. A estos recursos se les aplican los costes estándar. La replicación y el registro binario entre los entornos azul y verde se detienen.

RDS cambia el nombre del clúster y las instancias de base de datos en el entorno azul añadiendo -oldn al nombre del recurso actual, donde n es un número. Se fuerza el paso del clúster de base de datos a un estado de solo lectura. Incluso si deshabilita el parámetro read_only en el clúster de base de datos, permanece como de solo lectura hasta que elimine la implementación azul/verde.

Tras cambiar una implementación azul/verde

Actualización del nodo principal para los consumidores

Tras realizar la transición de una implementación azul/verde de Aurora MySQL, si el clúster de base de datosazul tenía réplicas externas o consumidores de registros binarios antes de la transición, debe actualizar su nodo principal tras la transición para mantener la continuidad de la replicación.

Tras la transición, la instancia de base de datos de escritura que anteriormente estaba en el entorno verde emite un evento que contiene el nombre del archivo de registro maestro y la posición del registro maestro. Por ejemplo:

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier

{
    "Events": [
...
        {
            "SourceIdentifier": "db-instance-identifier",
            "SourceType": "db-instance",
            "Message": "Binary log coordinates in green environment after switchover:
             file mysql-bin-changelog.000003 and position 804",
            "EventCategories": [],
            "Date": "2023-11-10T01:33:41.911Z",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier"
        }
    ]
}

En primer lugar, asegúrese de que el consumidor o la réplica hayan aplicado todos los registros binarios del antiguo entorno azul. A continuación, utilice las coordenadas del registro binario proporcionadas para reanudar la aplicación en los consumidores. Por ejemplo, si ejecuta una réplica de MySQL en EC2, puede usar el comando CHANGE MASTER TO:

CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;