Limitaciones y factores importantes en implementaciones azul/verde - Amazon Aurora

Limitaciones y factores importantes en implementaciones azul/verde

Las implementaciones azul/verde en Amazon RDS requieren una consideración cuidadosa de factores como las ranuras de replicación, la administración de recursos, el tamaño de las instancias y los posibles impactos en el rendimiento de la base de datos. Las siguientes secciones proporcionan orientación para ayudarle a optimizar su estrategia de implementación a fin de garantizar un tiempo de inactividad mínimo, transiciones fluidas y una administración eficaz del entorno de su base de datos.

Limitaciones de las implementaciones azul/verde

Las siguientes limitaciones se aplican a las implementaciones azul/verde.

Limitaciones generales de las implementaciones azul/verde

Las siguientes limitaciones generales se aplican a las implementaciones azul/verde:

  • No puede detener e iniciar un clúster que forme parte de una implementación azul/verde.

  • Las implementaciones azul/verde no admiten la administración de las contraseñas de los usuarios maestros con AWS Secrets Manager

  • Si intenta forzar una búsqueda de datos anteriores en el clúster de base de datos azul, la implementación azul/verde se interrumpe y la transición se bloquea.

  • Durante la conmutación, los entornos azul y verde no pueden tener integración sin ETL con Amazon Redshift. Debe eliminar la integración en primer lugar, realizar la conmutación y, a continuación, volver a crear la integración.

  • El programador de eventos (parámetro event_scheduler) debe estar deshabilitado en el entorno verde al crear una implementación azul/verde. Esto evita que se generen eventos en el entorno verde que provoquen incoherencias.

  • Las políticas de escalado automático de Aurora que se definan en el clúster de base de datos azul no se copian en el entorno verde.

  • No puede cambiar un clúster de base de datos sin cifrar por un clúster de base de datos con cifrado. Además, no puede cambiar un clúster de base de datos con cifrado por un clúster de base de datos sin cifrar.

  • No puede cambiar un clúster de base de datos azul por una versión del motor superior a su clúster de base de datos verde correspondiente.

  • Los recursos del entorno azul y el entorno verde deben estar en la misma Cuenta de AWS.

  • Las implementaciones azul/verde no son compatibles con las siguientes características:

    • Amazon RDS Proxy

    • Réplicas de lectura entre regiones

    • Clústeres de base de datos de Aurora Serverless v1

    • Clústeres de base de datos que forman parte de una base de datos de Aurora global

    • AWS CloudFormation

Limitaciones de Aurora MySQL en implementaciones azul/verde

Las siguientes limitaciones se aplican a las implementaciones azul/verde de Aurora MySQL:

  • El clúster de base de datos de origen no puede contener ninguna base de datos con el nombre tmp. Las bases de datos con este nombre no se copiarán en el entorno verde.

  • La instancia de base de datos azul no puede ser una réplica binlog externa.

  • Si el clúster de base de datos de origen tiene habilitada la función de búsqueda de datos anteriores, el clúster de base de datos verde se crea sin soporte para la búsqueda de datos anteriores. Esto se debe a que la búsqueda de datos anteriores no funciona con la replicación de registros binarios (binlog), que es necesaria para las implementaciones azul/verde. Para obtener más información, consulte Búsqueda de datos anteriores de un clúster de base de datos de Aurora.

  • Las implementaciones azul/verde no admiten el controlador JDBC de AWS para MySQL. Para obtener más información, consulte Known Limitations en GitHub.

Limitaciones de Aurora PostgreSQL para implementaciones azul/verde

Las siguientes limitaciones se aplican a las implementaciones azul/verde de Aurora PostgreSQL:

  • Las tablas no registradas no se replican en el entorno verde a menos que el parámetro rds.logically_replicate_unlogged_tables esté establecido en 1 en el clúster de bases de datos azul. No modifique el valor de este parámetro después de crear una implementación azul/verde, a fin de evitar posibles errores de replicación en tablas no registradas.

  • El clúster de base de datos azul no puede ser un origen lógico autoadministrado (publicador) ni una réplica (suscriptor).

  • Si el clúster de bases de datos está configurado como el servidor externo de un contenedor de datos externo (FDW), debe usar el nombre del punto de conexión del clúster en lugar de las direcciones IP. Esto permite que la configuración siga funcionando después de la transición.

  • En una implementación azul/verde, cada base de datos requiere una ranura de replicación lógica. A medida que aumenta el número de bases de datos, aumenta la sobrecarga de recursos, lo que puede provocar un retardo en la replicación, especialmente si el clúster de base de datos no se ha escalado lo suficiente. El impacto depende de factores como la carga de trabajo de la base de datos y el número de conexiones. Para mitigarlo, valore la posibilidad de escalar verticalmente la clase de instancia de base de datos o de reducir el número de bases de datos en el clúster de origen.

  • Las implementaciones azul/verde son compatibles con Babelfish para Aurora PostgreSQL solo para la versión 15.7 y versiones posteriores a 15, y la versión 16.3 y versiones posteriores a 16.

  • Las siguientes limitaciones se aplican a las extensiones de PostgreSQL:

    • La extensión pg_partman debe estar deshabilitada en el entorno azul al crear una implementación azul/verde. La extensión realiza operaciones de DDL, como CREATE TABLE, lo que rompe la replicación lógica del entorno azul al entorno verde.

    • La extensión pg_cron debe permanecer deshabilitada en todas las bases de datos verdes tras crear la implementación azul/verde. La extensión tiene programas de trabajo en segundo plano que se ejecutan como superusuarios y omiten la configuración de solo lectura del entorno verde, lo que podría provocar conflictos de replicación.

    • La extensión apg_plan_mgmt debe tener el parámetro apg_plan_mgmt.capture_plan_baselines establecido en off en todas las bases de datos verdes, a fin de evitar conflictos con las claves principales si se captura un plan idéntico en el entorno azul. Para obtener más información, consulte Descripción general de la administración de planes de consultas en Aurora PostgreSQL.

      Si desea capturar los planes de ejecución en las réplicas de Aurora, debe proporcionar el punto de conexión del clúster de bases de datos al llamar a la función apg_plan_mgmt.create_replica_plan_capture. Esto garantiza que las capturas de planes sigan funcionando después de la transición. Para obtener más información, consulte Captura de planes de ejecución de Aurora PostgreSQL en réplicas.

    • Las extensiones pglogical y pgactive deben estar deshabilitadas en el entorno azul al crear una implementación azul/verde. Después de realizar una transición del entorno verde para que sea el nuevo entorno de producción, puede volver a habilitar las extensiones. Además, la base de datos azul no puede ser un suscriptor lógico de una instancia externa.

    • Si utiliza la extensión pgAudit, debe permanecer en las bibliotecas compartidas (shared_preload_libraries) de los grupos de parámetros de base de datos personalizados para las instancias de base de datos azules y verdes. Para obtener más información, consulte Configuración de la extensión pgAudit.

Limitaciones de la replicación lógica de PostgreSQL para las implementaciones azul/verde

Las implementaciones azul/verde utilizan la replicación lógica para mantener el entorno de ensayo sincronizado con el entorno de producción. PostgreSQL tiene ciertas restricciones relacionadas con la replicación lógica, que se traducen en limitaciones a la hora de crear implementaciones azul/verde para clústeres de bases de datos de Aurora PostgreSQL.

En la siguiente tabla, se describen las limitaciones de replicación lógica que se aplican a las implementaciones azul/verde para Aurora PostgreSQL.

Limitación Explicación
Las instrucciones del lenguaje de definición de datos (DDL), como CREATE TABLE y CREATE SCHEMA, no se replican desde el entorno azul al entorno verde.

Si Aurora detecta un cambio de DDL en el entorno azul, las bases de datos verdes pasan a un estado de Replicación degradada.

Usted recibe un evento que le notifica que los cambios de DDL en el entorno azul no se pueden replicar en el entorno verde. Debe eliminar la implementación azul/verde y todas las bases de datos verdes y, a continuación, volver a crearla. De lo contrario, no podrá cambiar la implementación azul/verde.

Las operaciones NEXTVAL en los objetos de secuencia no están sincronizadas entre el entorno azul y el entorno verde.

Durante la transición, Aurora incrementa los valores de secuencia en el entorno verde para que coincidan con los del entorno azul. Si tiene miles de secuencias, esto puede retrasar la transición.

La creación o modificación de objetos grandes en el entorno azul no se replica en el entorno verde.

Si Aurora detecta la creación o modificación de objetos grandes en el entorno azul que están almacenados en la tabla de sistema pg_largeobject, las bases de datos verdes pasan a un estado de Replicación degradada.

Aurora genera un evento que le notifica que los cambios de objetos grandes en el entorno azul no se pueden replicar en el entorno verde. Debe eliminar la implementación azul/verde y todas las bases de datos verdes y, a continuación, volver a crearla. De lo contrario, no podrá cambiar la implementación azul/verde.

Las vistas materializadas no se actualizan automáticamente en el entorno verde.

La actualización de las vistas materializadas en el entorno azul no genera una actualización en el entorno verde. Tras la transición, puede actualizarlos manualmente mediante el comando REFRESH MATERIALIZED VIEW o programar una actualización.

Las operaciones UPDATE y DELETE no están permitidas en las tablas que no tengan una clave principal.

Antes de crear una implementación azul/verde, asegúrese de que todas las tablas del clúster de bases de datos tengan una clave principal.

Para obtener más información, consulte Restricciones en la documentación de replicación lógica de PostgreSQL.

Consideraciones acerca de las implementaciones azul/verde

Amazon RDS rastrea los recursos en las implementaciones azul/verde con el DbiResourceId y DbClusterResourceId de cada recurso. Este identificador de recurso es un identificador inmutable único de la Región de AWS para el recurso.

El ID del recurso es independiente del ID del clúster de base de datos: Todos aparecen en la configuración de la base de datos de la consola de RDS.

El nombre (ID de clúster) de un recurso cambia cuando conmuta una implementación azul/verde, pero cada recurso conserva el mismo identificador de recurso. Por ejemplo, un identificador de clúster de base de datos podría ser mycluster en el entorno azul. Tras la conmutación, es posible que el nombre del mismo clúster de base de datos se cambie a mycluster-old1. Sin embargo, el identificador de recurso del clúster de base de datos no se cambia durante la conmutación. Por lo tanto, cuando se realiza una transición de los recursos verdes para que sean los nuevos recursos de producción, sus identificadores de recurso no coinciden con los identificadores de recurso azules que estaban en producción anteriormente.

Tras realizar una transición a una implementación azul/verde, valore la posibilidad de actualizar los ID de recursos a los de los recursos de producción que se acaban de promocionar para las características y los servicios integrados que utilizó con los recursos de producción. Específicamente, tenga en cuenta las siguientes actualizaciones:

  • Si realiza el filtrado mediante la API de RDS y los identificadores de recursos, ajuste los identificadores de recursos utilizados en el filtrado después de la conmutación.

  • Si utiliza CloudTrail para auditar recursos, ajuste los consumidores del CloudTrail para que realicen un seguimiento de los nuevos identificadores de recursos tras la conmutación. Para obtener más información, consulte Supervisión de llamadas a la API de Amazon Aurora en AWS CloudTrail.

  • Si utiliza flujos de actividad de bases de datos para los recursos del entorno azul, ajuste la aplicación para supervisar los eventos de la base de datos para el nuevo flujo después de la conmutación. Para obtener más información, consulte Regiones y motores de base de datos Aurora admitidos para los flujos de actividad de bases de datos.

  • Si utiliza la API de Información de rendimiento, ajuste los identificadores de los recursos en las llamadas a la API después de la conmutación. Para obtener más información, consulte Monitoreo de la carga de base de datos con Performance Insights en Amazon Aurora.

    Puede supervisar una base de datos con el mismo nombre después de la conmutación, pero no contiene los datos de antes de la conmutación.

  • Si usa identificadores de recursos en las políticas de IAM, asegúrese de agregar los identificadores de los recursos a los que se les acaba de realizar una transición cuando sea necesario. Para obtener más información, consulte Administración de la identidad y el acceso en Amazon Aurora.

  • Si tiene roles de IAM asociados al clúster de base de datos, asegúrese de volver a asociarlas tras la transición. Los roles asociados no se copian automáticamente en el entorno verde.

  • Si se autentica en su clúster de base de datos con la autenticación de base de datos de IAM, asegúrese de que la política de IAM usada para acceder a la base de datos tenga las bases de datos azul y verde enumeradas bajo el elemento Resource de la política. Esto es necesario para conectarse a la base de datos verde después del cambio. Para obtener más información, consulte Creación y uso de una política de IAM para el acceso a bases de datos de IAM.

  • Si desea restaurar una instantánea manual de un clúster de base de datos para un clúster de base de datos que formaba parte de una implementación azul/verde, asegúrese de restaurar la instantánea del clúster de base de datos correcta examinando la hora en que se tomó. Para obtener más información, consulte Restauración de una instantánea de clúster de base de datos.

  • Amazon Aurora crea el entorno verde clonando el volumen de almacenamiento Aurora subyacente en el entorno azul. El volumen del clúster verde solo almacena los cambios incrementales que se realizan en el entorno verde. Si elimina el clúster de base de datos del entorno azul, el tamaño del volumen de almacenamiento de Aurora subyacente en el entorno verde aumenta hasta su tamaño completo. Para obtener más información, consulte Clonación de un volumen de clúster de base de datos de Amazon Aurora.

  • Al añadir una instancia de base de datos al clúster de base de datos en el entorno verde de una implementación azul/verde, la nueva instancia de base de datos no reemplazará a la instancia de base de datos del entorno azul cuando conmute. Sin embargo, la nueva instancia de base de datos se conserva en el clúster de base de datos y se convierte en una instancia de base de datos en el nuevo entorno de producción.

  • Al eliminar una instancia de base de datos del clúster de base de datos en el entorno verde de una implementación azul/verde, no puede crear una nueva instancia de base de datos para reemplazarla en la implementación azul/verde.

    Si crea una nueva instancia de base de datos con el mismo nombre y ARN que la instancia de base de datos eliminada, tendrá una DbiResourceId diferente, por lo que no forma parte del entorno verde.

    Si se elimina una instancia de base de datos del clúster de base de datos en el entorno verde, se produce el siguiente comportamiento:

    • Si existe la instancia de base de datos del entorno azul con el mismo nombre, no se cambiará a la instancia de base de datos del entorno verde. El nombre de esta instancia de base de datos no se modificará añadiendo -oldn al nombre de la instancia de base de datos.

    • Cualquier aplicación que apunte a la instancia de base de datos en el entorno azul seguirá utilizando la misma instancia de base de datos después de la conmutación.