Cambio de una implementación azul/verde

Una conmutación hace que el entorno verde sea el nuevo entorno de producción. Cuando la instancia de base de datos verde tiene réplicas de lectura, estas también se promocionan. Antes de conmutar, el tráfico de producción se dirige a la instancia de base de datos y las réplicas de lectura en el entorno azul. Tras conmutar, el tráfico de producción se dirige a la instancia de base de datos y las réplicas de lectura 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 de la instancia de base de datos principal es correcto. La instancia de base de datos principal verde es una réplica de la instancia de base de datos principal azul.

• Retraso de replicación: comprueba si el retraso de la instancia de base de datos principal 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 la instancia de base de datos principal verde con respecto a la instancia de base de datos principal azul. Para obtener más información, consulte Diagnóstico y resolución de retardos entre réplicas de lectura para RDS para MySQL y Supervisión y ajuste del proceso de replicación para RDS para PostgreSQL.

• Escrituras activas: asegúrese de que no haya escrituras activas en la instancia de base de datos principal verde.

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

• Replicación externa: en el caso de RDS para 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 RDS para MySQL y RDS para MariaDB, 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 la instancia de base de datos principal 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 la instancia de base de datos principal azul, ya que pueden aumentar el retardo de la réplica.

• Cambios en PostgreSQL no compatibles: en el caso de las instancias de base de datos de RDS para 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 la instancia de base de datos principal 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 de las instancias de base de datos en ambos entornos.

   RDS cambia el nombre de las instancias de base de datos del entorno verde para que coincidan con el de 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 de 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 la instancia de base de datos principal del nuevo entorno de producción.

   Tras la conmutación, la instancia de base de datos principal de producción anterior solo permite operaciones de lectura hasta que ajuste el parámetro read_only en 0 y reinicie la instancia de base de datos.

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 mueven al nuevo entorno de producción durante la conmutación. El entorno de producción anterior también conserva estas etiquetas. 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 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 las instancias de base de datos de ambos entornos se encuentren en el estado Available.

• Asegúrese de que la instancia de base de datos principal 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 RDS.
 De lo contrario, las aplicaciones seguirán enviando tráfico de escritura al entorno azul después del cambio.

• Asegúrese de que la carga de datos esté completa antes de realizar el cambio. Para obtener más información, consulte Gestión de la carga diferida al crear una implementación azul/verde.

• Para las instancias de base de datos de RDS para PostgreSQL, haga lo siguiente:

  • Revise las limitaciones de la replicación lógica y tome las medidas necesarias antes de la transición. Para obtener más información, consulte Limitaciones de la replicación lógica de PostgreSQL para las implementaciones azul/verde.

  • Ejecute la operación ANALYZE para actualizar la tabla pg_statistics. Esto reduce el riesgo de problemas de rendimiento tras la transición.

nota

Durante una conmutación, no puede modificar ninguna instancia 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.

• ReplicaLag: utilice esta métrica para identificar el retardo de replicación actual en el entorno verde. Para reducir el tiempo de inactividad, asegúrese de que este valor sea cercano a cero antes de realizar la conmutación.

• 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.

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

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.

Consola

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).

   

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 la instancia ejecuta RDS para 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).

AWS CLI

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

API de RDS

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 las instancias de base de datos del entorno azul anterior. A estos recursos se les aplican los costes estándar. La replicación entre los entornos azul y verde se detienen.

RDS cambia el nombre de las instancias de base de datos en el entorno azul añadiendo -oldn al nombre del recurso actual, donde n es un número. Las instancias de base de datos son de solo lectura hasta que defina el parámetro read_only en 0.

Actualización del nodo principal para los consumidores

Tras realizar la transición de una implementación azul/verde de RDS para MariaDB o RDS para MySQL, si la instancia de base de datos azul 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 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;

nota

Si el consumidor es otra instancia de base de datos de RDS para MariaDB, puede ejecutar los siguientes procedimientos almacenados en orden: mysql.rds_stop_replication, mysql.rds_reset_external_master, mysql.rds_set_external_master y mysql.rds_start_replication.