Cambio de una implementación azul/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.

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

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.

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:

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.

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.

Utilice la métrica de CloudWatch OldestReplicationSlotLag para supervisar el retardo de replicación actual en el entorno verde. Para minimizar el tiempo de inactividad, asegúrese de que este valor sea cercano a cero antes de realizar la conmutación. Para obtener más información, consulte Métricas de nivel de instancia para Amazon Aurora.