Descripción general de las implementaciones azul/verde de Amazon RDS para Aurora

Con las implementaciones azul/verde de Amazon RDS, puede realizar y probar cambios en las bases de datos antes de implementarlas en un entorno de producción. Una implementación azul/verde crea un área de almacenamiento provisional que copia el entorno de producción. En una implementación azul/verde, el entorno azul es el entorno de producción actual. El entorno verde es el entorno de almacenamiento provisional. El entorno de almacenamiento provisional permanece sincronizado con el entorno de producción actual mediante la replicación lógica.

Puede realizar cambios en el clúster de base de datos de Aurora en un entorno verde sin que eso afecte a las cargas de trabajo de producción. Por ejemplo, puede actualizar la versión principal o secundaria del motor de base de datos o cambiar los parámetros de la base de datos en el entorno de almacenamiento provisional. Puede probar exhaustivamente los cambios en el entorno verde. Cuando esté listo, puede conmutar los entornos para hacer que el entorno verde sea el nuevo entorno de producción. La conmutación suele tardar menos de un minuto sin que se produzca una pérdida de datos y sin la necesidad de realizar cambios en la aplicación.

Como el entorno verde es una copia de la topología del entorno de producción, el clúster de base de datos y todas sus instancias de base de datos se copian en la implementación. El entorno verde también incluye las características que utiliza el clúster de base de datos, como las instantáneas del clúster de base de datos, Información sobre rendimiento, monitorización mejorada yAurora Serverless v2.

nota

Las implementaciones azul/verde son compatibles con Aurora MySQL y Aurora PostgreSQL. Para conocer la disponibilidad de Amazon RDS, consulte Uso de las implementaciones azules/verdes de Amazon RDS para actualizar las bases de datos en la Guía del usuario de Amazon RDS.

Disponibilidad en regiones y versiones

La disponibilidad de las características varía según las versiones específicas de cada motor de base de datos y entre Regiones de AWS. Para obtener más información, consulte Regiones y motores de base de datos de Aurora admitidos para implementaciones azul/verde.

Ventajas de utilizar las implementaciones azul/verde de Amazon RDS

Al utilizar las implementaciones azul/verde de Amazon RDS, puede mantenerse al día con los parches de seguridad, mejorar el rendimiento de las bases de datos y adoptar nuevas características de bases de datos con un tiempo de inactividad breve y predecible. Las implementaciones azules y verdes reducen los riesgos y el tiempo de inactividad de las actualizaciones de las bases de datos, como las actualizaciones principales o secundarias de las versiones del motor.

Las implementaciones azul/verde ofrecen los siguientes beneficios:

• Cree fácilmente un entorno de almacenamiento provisional listo para la producción.

• Replique automáticamente los cambios de la base de datos del entorno de producción al entorno de almacenamiento provisional.

• Pruebe los cambios en la base de datos en un entorno de almacenamiento provisional seguro sin que eso afecte al entorno de producción.

• Manténgase al día con los parches de las bases de datos y las actualizaciones del sistema.

• Implemente y pruebe las características más recientes de las bases de datos.

• Conmute su entorno de almacenamiento provisional para convertirlo en el nuevo entorno de producción sin cambios en la aplicación.

• Cambie de forma segura mediante el uso de barreras de protección de conmutaciones integradas.

• Elimine la pérdida de datos durante la conmutación.

• Conmutar rápidamente, normalmente en menos de un minuto, según su carga de trabajo.

Flujo de trabajo de una implementación azul/verde

Realice los siguientes pasos principales cuando utilice una implementación azul/verde para las actualizaciones del clúster de base de datos de Aurora.

1. Identifique un clúster de base de datos de producción que requiera actualizaciones.

   En la imagen siguiente, se muestra un ejemplo de un clúster de base de datos de producción.

   

2. Cree la implementación azul/verde. Para obtener instrucciones, consulte Creación de una implementación azul/verde.

   La siguiente imagen muestra un ejemplo de una implementación azul/verde del entorno de producción del paso 1. Al crear la implementación azul/verde, RDS copia la topología y la configuración completas del clúster de base de datos de Aurora para crear el entorno verde. Los nombres del clúster de base de datos copiado y de las instancias de base de datos se adjuntan con -green-random-characters. El entorno de almacenamiento provisional de la imagen contiene el clúster de base de datos (auroradb-green-abc123). También contiene las tres instancias de base de datos del clúster de base de datos (auroradb-instance1-green-abc123, auroradb-instance2-green-abc123 y auroradb-instance3-green-abc123).

   

   Al crear la implementación azul/verde, puede actualizar la versión más alta del motor de base de datos y un grupo de parámetros de base de datos diferente para el clúster de base de datos del entorno verde. También puede especificar un grupo de parámetros de base de datos diferente para las instancias de base de datos del clúster de base de datos.

   RDS también configura la replicación desde la instancia de base de datos principal en el entorno azul hasta la instancia de base de datos principal en el entorno verde.

   importante

   En la versión 3 de Aurora MySQL, tras crear la implementación azul/verde, el clúster de base de datos del entorno verde permite las operaciones de escritura de forma predeterminada. Se recomienda hacer que el clúster de base de datos sea de solo lectura, poniendo para ello el parámetro read_only en 1 y reiniciando el clúster.

3. Realice cambios en el entorno de almacenamiento provisional.

   Por ejemplo, puede realizar cambios de esquema en la base de datos o cambiar la clase de instancia de base de datos que utilizan una o más instancias de base de datos en el entorno verde.

   Para obtener más información acerca de la modificación de un clúster de bases de datos, consulte Modificación de un clúster de base de datos de Amazon Aurora.

4. Ponga a prueba su entorno de almacenamiento temporal.

   Durante las pruebas, le recomendamos que mantenga como solo lectura las bases de datos de un entorno verde. Habilite las operaciones de escritura en el entorno verde con precaución, ya que pueden provocar conflictos de replicación. También pueden generar datos no deseados en las bases de datos de producción después de la conmutación. Para habilitar las operaciones de escritura en Aurora MySQL, ponga el parámetro read_only en 0 y reinicie la instancia de base de datos. En el caso de Aurora PostgreSQL, ponga el parámetro default_transaction_read_only en off en el nivel de sesión.

5. Cuando esté listo, conmútelo para hacer que el entorno de almacenamiento provisional sea el nuevo entorno de producción. Para obtener instrucciones, consulte Cambio de una implementación azul/verde.

   La conmutación provoca un tiempo de inactividad. El tiempo de inactividad suele ser inferior a un minuto, pero puede prolongarse en función de la carga de trabajo.

   En la imagen siguiente, se muestran los clústeres de base de datos después de la conmutación.

   

   Tras la conmutación, el clúster de base de datos de Aurora en el entorno verde se convierte en el nuevo clúster de base de datos de producción. Los nombres y puntos de conexión del entorno de producción actual se asignan al entorno de producción que se acaba de promocionar, por lo que no es necesario realizar cambios en la aplicación. Como resultado, el tráfico de producción ahora fluye al nuevo entorno de producción. El nombre del clúster de base de datos y de las instancias de base de datos del entorno azul se cambian de nombre añadiendo -oldn al nombre actual, donde n es un número. Por ejemplo, suponga que el nombre de la instancia de base de datos en el entorno azul es auroradb-instance-1. Tras la conmutación, el nombre de la instancia de base de datos puede ser auroradb-instance-1-old1.

   En el ejemplo de la imagen, se producen los siguientes cambios durante la conmutación:

   • El clúster de base de datos de entorno verde auroradb-green-abc123 pasa a ser el clúster de base de datos de producción denominado auroradb.

   • La instancia de base de datos de entorno verde denominada auroradb-instance1-green-abc123 se convierte en la instancia de base de datos de producción auroradb-instance1.

   • La instancia de base de datos de entorno verde denominada auroradb-instance2-green-abc123 se convierte en la instancia de base de datos de producción auroradb-instance2.

   • La instancia de base de datos de entorno verde denominada auroradb-instance3-green-abc123 se convierte en la instancia de base de datos de producción auroradb-instance3.

   • El clúster de base de datos del entorno azul denominado auroradb se convierte en auroradb-old1.

   • La instancia de base de datos del entorno azul denominada auroradb-instance1 se convierte en auroradb-instance1-old1.

   • La instancia de base de datos del entorno azul denominada auroradb-instance2 se convierte en auroradb-instance2-old1.

   • La instancia de base de datos del entorno azul denominada auroradb-instance3 se convierte en auroradb-instance3-old1.

6. Si ya no necesita una implementación azul/verde, puede eliminarla. Para obtener instrucciones, consulte Eliminación de una implementación azul/verde.

   Tras la conmutación, el entorno de producción anterior no se elimina, por lo que puede usarlo para realizar pruebas de regresión, si es necesario.

Permitir el acceso a las operaciones de la implementación azul/verde

Los usuarios deben tener los permisos necesarios para realizar operaciones relacionadas con las implementaciones azul/verde. Puede crear políticas de IAM que concedan permisos a los usuarios y a los roles para realizar operaciones de la API concretas en los recursos especificados que necesiten. A continuación, puede asociar esas políticas a los roles o conjuntos de permisos de IAM que necesiten esos permisos. Para obtener más información, consulte Administración de la identidad y el acceso en Amazon Aurora.

El usuario que crea una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS:

• rds:AddTagsToResource

• rds:CreateDBCluster

• rds:CreateDBInstance

• rds:CreateDBClusterEndpoint

El usuario que cambia a una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS:

• rds:ModifyDBCluster

• rds:PromoteReadReplicaDBCluster

El usuario que elimina una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS:

• rds:DeleteDBCluster

• rds:DeleteDBInstance

• rds:DeleteDBClusterEndpoint

Aurora aprovisiona y modifica los recursos en el entorno de almacenamiento provisional en su nombre. Estos recursos incluyen instancias de base de datos que utilizan una convención de nomenclatura definida internamente. Por lo tanto, las políticas de IAM asociadas no pueden contener patrones de nombres de recursos parciales, como my-db-prefix-*. Solo se admite el uso de comodines (*). En general, se recomienda utilizar etiquetas de recursos y otros atributos compatibles para controlar el acceso a estos recursos, en lugar de utilizar comodines. Para obtener más información, consulte Acciones, recursos y claves de condición de Amazon .

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 de clúster de base de datos:

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 promocionan 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 cambiar a una implementación azul/verde, considere la posibilidad de actualizar los identificadores 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 añadir los identificadores de los recursos que se acaban de promocionar 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.

Prácticas recomendadas para las implementaciones azul/verde

Estas son las prácticas recomendadas para las implementaciones azul/verde

Prácticas recomendadas generales

• Pruebe minuciosamente el clúster de base de datos de Aurora en el entorno verde antes de realizar el cambio.

• Mantenga sus bases de datos del entorno verde en modo de solo lectura. Se recomienda habilitar las operaciones de escritura en el entorno verde con precaución, ya que pueden provocar conflictos de replicación. También pueden generar datos no deseados en las bases de datos de producción después de la conmutación.

• Cuando utilice una implementación azul/verde para implementar cambios en el esquema, realice únicamente cambios compatibles con la replicación.

  Por ejemplo, puede añadir nuevas columnas al final de una tabla, sin interrumpir la replicación de la implementación azul a la implementación verde. Sin embargo, los cambios en el esquema, como cambiar el nombre de las columnas o las tablas, interrumpen la replicación en la implementación verde.

  Para obtener más información sobre los cambios compatibles con la replicación, consulte Replication with Differing Table Definitions on Source and Replica en la documentación de MySQL y Restrictions en la documentación de la replicación lógica de PostgreSQL.

• Utilice el punto de conexión del clúster, el punto de conexión del lector o el punto de conexión personalizado para todas las conexiones en ambos entornos. No utilice puntos de conexión de instancia ni puntos de conexión personalizados con listas estáticas o de exclusión.

• Al cambiar a una implementación azul/verde, siga las prácticas recomendadas de conmutación. Para obtener más información, consulte Prácticas recomendadas para realizar la conmutación.

Procedimientos recomendados en Aurora PostgreSQL

• Supervise la memoria caché de escritura de la replicación lógica de Aurora PostgreSQL y haga ajustes en el búfer de memoria caché si es necesario. Para obtener más información, consulte Administración de la memoria caché de escritura de la replicación lógica de Aurora PostgreSQL.

• Si su base de datos tiene suficiente memoria liberable, aumente el valor del parámetro de base de datos logical_decoding_work_mem en el entorno azul. De este modo, se reduce la decodificación en el disco y, en su lugar, se utiliza memoria. Puede supervisar la memoria liberable con la métrica FreeableMemory de CloudWatch. Para obtener más información, consulte Métricas de Amazon CloudWatch para Amazon Aurora.

• Actualice todas las extensiones de PostgreSQL a la versión más reciente antes de crear una implementación azul/verde. Para obtener más información, consulte Actualización de las extensiones de PostgreSQL.

• Si utiliza la extensión aws_s3, asegúrese de permitir el acceso del clúster de bases de datos a Amazon S3 a través de un rol de IAM tras crear el entorno verde. Esto permite que los comandos de importación y exportación sigan funcionando después de la transición. Para obtener instrucciones, consulte Configuración del acceso a un bucket de Amazon S3.

• Si especifica una versión de motor superior para el entorno verde, ejecute la operación ANALYZE en todas las bases de datos para actualizar la tabla de pg_statistic. Las estadísticas del optimizador no se transfieren durante una actualización de la versión principal, por lo que debe regenerar todas las estadísticas para evitar problemas de rendimiento. Para conocer prácticas recomendadas adicionales durante las actualizaciones de versiones principales, consulte Cómo realizar una actualización de versión principal.

• Evite configurar desencadenadores como ENABLE REPLICA o ENABLE ALWAYS si el desencadenador se utiliza en el origen para manipular los datos. De lo contrario, el sistema de replicación propaga los cambios y ejecuta el desencadenador, lo que provoca la duplicación.

• Las transacciones de larga duración pueden provocar un retraso significativo en las réplicas. Para reducir el retraso en las réplicas, realice lo siguiente:

  • Reduzca las transacciones de larga duración que pueden retrasarse hasta que el entorno verde se ponga al mismo nivel que el entorno azul.

  • Inicie una operación de inmovilización de vacío manual en tablas ocupadas antes de crear la implementación azul/verde.

  • Para la versión 12 y posteriores de PostgreSQL, desactive el parámetro index_cleanup en tablas grandes u ocupadas para aumentar la tasa de mantenimiento normal en las bases de datos azules.

• La replicación lenta puede provocar que los remitentes y los destinatarios se reinicien con frecuencia, lo que retrasa la sincronización. Para garantizar que permanezcan activos, deshabilite los tiempos de espera configurando el parámetro wal_sender_timeout en 0 en el entorno azul y el parámetro wal_receiver_timeout en 0 en el entorno verde.

Limitaciones de las implementaciones azul/verde

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

Temas

• Limitaciones generales de las implementaciones azul/verde
• Limitaciones de las extensiones de PostgreSQL para las implementaciones azul/verde
• Limitaciones para los cambios en implementaciones azul/verde
• Limitaciones de la replicación lógica de PostgreSQL para las implementaciones azul/verde

Limitaciones generales de las implementaciones azul/verde

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

• Las versiones 2.08 y 2.09 de Aurora MySQL no se admiten como versiones de origen o destino de la actualización.

• 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 crea una implementación azul/verde a partir de un clúster de base de datos de origen de Aurora MySQL que 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.

  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.

• En Aurora MySQL, el clúster de bases 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.

• En el caso 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. Se recomienda no modificar 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.

• En el caso de Aurora PostgreSQL, el clúster de base de datos del entorno azul no puede ser un origen lógico autoadministrado (publicador) ni una réplica (suscriptor). En el caso de Aurora MySQL, el clúster de base de datos del entorno azul no puede ser una réplica binlog externa.

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

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

• 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

  • Babelfish para Aurora PostgreSQL

  • AWS CloudFormation

Limitaciones de las extensiones de PostgreSQL para las implementaciones azul/verde

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.

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

• Las extensiones pglogical y pg_active deben estar deshabilitadas en el entorno azul al crear una implementación azul/verde. Después de promover el 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 para los cambios en implementaciones azul/verde

Estas son las limitaciones de los cambios en una implementación azul/verde:

• No puede cambiar un clúster de base de datos sin cifrar por un clúster de base de datos con cifrado.

• 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 del entorno azul por una versión del motor superior a su clúster de base de datos del entorno verde correspondiente.

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

• Si el entorno azul contiene políticas de escalado automático de Aurora, estas políticas no se copian en el entorno verde. Debe volver a agregar las políticas al entorno verde de forma manual.

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 programar una actualización de las vistas materializadas.
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.