# Descripción general de las implementaciones azul/verde de Amazon Aurora Con las implementaciones azul/verde de Amazon Aurora, 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 provisional y está sincronizado con el entorno de producción actual. 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é todo listo, puede *realizar una transición* a 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, Aurora PostgreSQL y la base de datos global de Aurora. Para conocer la disponibilidad de Amazon RDS, consulte [Descripción general de las implementaciones azul/verde de Amazon RDS para Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html) en la *Guía del usuario de Amazon RDS*. **Topics** + [Disponibilidad en regiones y versiones](#blue-green-deployments-region-version-availability) + [Ventajas de utilizar las implementaciones azul/verde de Amazon RDS](#blue-green-deployments-benefits) + [Flujo de trabajo de una implementación azul/verde](#blue-green-deployments-major-steps) + [Autorización del acceso a las operaciones de la implementación azul/verde de Amazon Aurora](blue-green-deployments-authorizing-access.md) + [Limitaciones y consideraciones para implementaciones azul/verde de Amazon Aurora](blue-green-deployments-considerations.md) + [Prácticas recomendadas para las implementaciones azul/verde de Amazon Aurora](blue-green-deployments-best-practices.md) ## 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](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md). ## 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. ![\[Clúster de base de datos de Aurora (azul) en una implementación azul/verde\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png) 1. Cree la implementación azul/verde. Para obtener instrucciones, consulte [Creación de una implementación azul/verde en Amazon Aurora](blue-green-deployments-creating.md). 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**). ![\[Implementación azul/verde para Amazon Aurora\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png) 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 no permite las operaciones de escritura de forma predeterminada. Sin embargo, esto no se aplica a los usuarios que tienen el privilegio `CONNECTION_ADMIN`, incluido el usuario maestro de Aurora. Los usuarios con este privilegio pueden anular el comportamiento de `read_only`. Para obtener más información, consulte [Modelo de privilegios basado en roles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). 1. Realice cambios en el entorno de almacenamiento provisional. Por ejemplo, puede cambiar la clase de instancia de la base de datos que utilizan una o más instancias de base de datos en el entorno verde. Para obtener información acerca de la modificación de un clúster de base de datos, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). 1. 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. 1. Cuando esté todo listo, realice una transición 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 en Amazon Aurora](blue-green-deployments-switching.md). 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. ![\[Clúster de base de datos e instancias de base de datos después de cambiar a una implementación azul/verde de Amazon Aurora\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png) 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 al que le acaba de realizar la transición, 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`. 1. Si ya no necesita una implementación azul/verde, puede eliminarla. Para obtener instrucciones, consulte [Eliminación de una implementación azul/verde en Amazon Aurora](blue-green-deployments-deleting.md). 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. # Autorización del acceso a las operaciones de la implementación azul/verde de Amazon Aurora 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](UsingWithRDS.IAM.md). El usuario que crea una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS: + `rds:CreateBlueGreenDeployment` + `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:SwitchoverBlueGreenDeployment` + `rds:ModifyDBCluster` + `rds:PromoteReadReplicaDBCluster` El usuario que elimina una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS: + `rds:DeleteBlueGreenDeployment` + `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 (\$1). 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 ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html). ## Permisos adicionales para las implementaciones azul/verde de base de datos de Aurora Global Al crear implementaciones azul/verde para los clústeres de la base de datos de Aurora Global, además del permiso mencionado anteriormente, los usuarios necesitan los siguientes permisos para realizar operaciones de administración de la topología de clústeres global. El usuario que crea una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS: + `rds:CreateGlobalCluster` El usuario que cambia a una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS: + `rds:ModifyGlobalCluster` + `rds:PromoteReadReplicaDBCluster` El usuario que elimina una implementación azul/verde debe tener permisos para realizar las siguientes operaciones de RDS: + `rds:DeleteGlobalCluster` # Limitaciones y consideraciones para implementaciones azul/verde de Amazon Aurora 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. **Topics** + [Limitaciones de las implementaciones azul/verde](#blue-green-deployments-limitations) + [Limitaciones de base de datos global de Aurora para implementaciones azul/verde](#blue-green-deployments-limitations-agd) + [Consideraciones acerca de las implementaciones azul/verde](#blue-green-deployments-consider) ## Limitaciones de las implementaciones azul/verde Las siguientes limitaciones se aplican a las implementaciones azul/verde. **Topics** + [Limitaciones generales de las implementaciones azul/verde](#blue-green-deployments-limitations-general) + [Limitaciones de Aurora MySQL en implementaciones azul/verde](#blue-green-deployments-limitations-mysql) + [Limitaciones de Aurora PostgreSQL para implementaciones azul/verde](#blue-green-deployments-limitations-postgres-logical) ### 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 en el clúster de base de datos azul no se copian en el entorno verde. Debe volver a configurarlas después de la transición, independientemente de si se configuraron inicialmente en el entorno azul o 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 + Aurora Serverless v1Clústeres de base de datos de + 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](AuroraMySQL.Managing.Backtrack.md). + Las implementaciones azul/verde no admiten el controlador JDBC de AWS para MySQL. Para obtener más información, consulte [Known Limitations](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#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](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) 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 (publicador) ni una réplica (suscriptor). + Si el clúster de bases de datos azul está configurado como el servidor externo de una extensión de 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. + 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](AuroraPostgreSQL.QPM.Plancapturereplicas.md). + El [proceso de aplicación](https://www.postgresql.org/docs/current/logical-replication-architecture.html) de replicación lógica en el entorno verde es de un solo subproceso. Si el entorno azul genera un gran volumen de tráfico de escritura, es posible que el entorno verde no pueda seguirle el ritmo. Esto puede provocar un retardo o un error en la replicación, sobre todo en el caso de las cargas de trabajo que producen un alto rendimiento continuo de escritura. Asegúrese de probar a fondo las cargas de trabajo. En los escenarios que requieran actualizaciones de versiones principales y administrar cargas de trabajo de escritura de gran volumen, considere enfoques alternativos como utilizar [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) o la [replicación lógica autoadministrada](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html). + La creación de nuevas particiones en tablas particionadas no es compatible durante las implementaciones azul/verde de Aurora. La creación de nuevas particiones implica operaciones de lenguaje de definición de datos (DDL)`CREATE TABLE`, que no se replican desde el entorno azul al entorno verde. Sin embargo, las tablas particionadas existentes y sus datos se replicarán en el entorno 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](AuroraPostgreSQL.Optimize.overview.md). + 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](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md). #### Limitaciones específicas de la replicación lógica para las implementaciones azul/verde 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. Para obtener más información, consulte [Restricciones](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) en la documentación de replicación lógica de 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**. Debe eliminar la implementación azul/verde y todas las bases de datos verdes y, a continuación, volver a crearla. | | Las instrucciones del lenguaje de control de datos (DCL), como GRANT y REVOKE, no se replican desde el entorno azul al entorno verde. | Si Aurora detecta un intento de ejecutar una instrucción de DCL en el entorno azul, aparecerá un mensaje de advertencia. No hay ninguna configuración o API disponible para cambiar este comportamiento, ya que se trata de una limitación del proceso de 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. | | Los objetos grandes en el entorno azul no se replican en el entorno verde. Esto incluye los objetos grandes existentes como cualquier objeto grande recién creado o modificado durante el proceso de implementación azul/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**. Debe eliminar la implementación azul/verde y todas las bases de datos verdes y, a continuación, volver a crearla. | | La actualización de las vistas materializadas interrumpe la replicación. | La actualización de las vistas materializadas en el entorno azul interrumpe la replicación en el entorno verde. Absténgase de actualizar las vistas materializadas en el entorno azul. Tras una transición, puede actualizarlos manualmente mediante el comando [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) 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 tengan una clave principal o usen `REPLICA IDENTITY FULL`. Sin embargo, use `REPLICA IDENTITY FULL` solo si no existe una clave principal o única, ya que afecta al rendimiento de la replicación. Para obtener más información, consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). | ## Limitaciones de base de datos global de Aurora para implementaciones azul/verde Además de las limitaciones generales y específicas del motor indicadas anteriormente, se aplican las siguientes limitaciones a las implementaciones azul/verde de la base de datos global de Aurora: + Todas las operaciones se deben iniciar desde la misma región que el clúster de redacción de la base de datos global. + Si se realiza una transición global o una conmutación por error global, la implementación azul/verde activa dejará de ser válida. La implementación azul/verde debe eliminarse y volver a crearse desde la nueva región principal. + Para Aurora PostgreSQL, si tiene habilitado el reenvío de escritura global en su entorno de producción y crea una implementación azul/verde, el reenvío de escritura está desactivado en el clúster verde. Se habilita en el entorno verde solo después de la transición azul/verde, cuando el entorno verde se convierte en el nuevo entorno de producción. Tras la transición, el reenvío de escritura se desactiva en el clúster `-old1`. + Si se modifica la topología de la base de datos global tras la creación de la implementación azul/verde, la implementación azul/verde activa dejará de ser válida. La implementación azul/verde debería eliminarse y volver a crearse desde la nueva región principal. + Las instantáneas automatizadas se retienen según los días de retención de la copia de seguridad que se configuraron originalmente en el antiguo entorno azul. Las instantáneas automatizadas del antiguo clúster azul no se copian a verde. + La conmutación por error global se admite durante una transición azul/verde, pero una transición global no se admite durante una transición azul/verde. + Asegúrese de que el clúster de base de datos y los grupos de parámetros de base de datos para el entorno verde existan en todas las regiones secundarias con nombres idénticos. Si el grupo de parámetros de alguna región no está disponible, se utiliza el grupo de parámetros predeterminado de las regiones. + Evite usar el RDS Proxy en algún miembro de la base de datos global durante la transición de implementación azul/verde. ## 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](logging-using-cloudtrail.md). + 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](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md). + 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](USER_PerfInsights.md). 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](UsingWithRDS.IAM.md). + 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 el clúster de base de datos con la [autenticación de base de datos de IAM](UsingWithRDS.IAMDBAuth.md), 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 mostradas 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](UsingWithRDS.IAMDBAuth.IAMPolicy.md). + 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](aurora-restore-snapshot.md). + Tras la transición, las tareas de replicación de AWS Database Migration Service (AWS DMS) no se pueden reanudar porque el punto de control del entorno azul no es válido en el entorno verde. Debe volver a crear la tarea de DMS con un nuevo punto de control para continuar con la replicación. + 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](Aurora.Managing.Clone.md). + 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. + Si utiliza etiquetas de recursos para el control de acceso o la administración operativa, debe comprender que los cambios en las etiquetas no se sincronizan entre los entornos azules y verdes hasta que se produce la transición. Al crear una implementación azul/verde, las etiquetas del entorno azul se copian en el entorno verde. Tras la creación, las modificaciones de etiquetas que realice en cualquiera de los entornos no se sincronizan automáticamente. Durante la transición, las etiquetas de entorno azules sustituyen a todas las etiquetas del entorno verde. Aplique todas las etiquetas necesarias al entorno azul antes de crear la implementación azul/verde o vuelva a aplicar las etiquetas necesarias al nuevo entorno de producción tras la transición. Para obtener más información acerca de las etiquetas, consulte [Etiquetado de los recursos de Amazon Aurora y Amazon RDS](USER_Tagging.md). # Prácticas recomendadas para las implementaciones azul/verde de Amazon Aurora Estos son los procedimientos recomendados para las implementaciones azul/verde. **Topics** + [Prácticas recomendadas generales para las implementaciones azul/verde](#blue-green-deployments-best-practices-general) + [Prácticas recomendadas de Aurora MySQL para las implementaciones azul/verde](#blue-green-deployments-best-practices-mysql) + [Prácticas recomendadas de Aurora PostgreSQL para las implementaciones azul/verde](#blue-green-deployments-best-practices-postgres) + [Prácticas recomendadas de base de datos global de Aurora para las implementaciones azul/verde](#blue-green-deployments-best-practices-agd) ## Prácticas recomendadas generales para las implementaciones azul/verde Tenga en cuenta las prácticas recomendadas generales al crear una implementación azul/verde. + 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. + Si utiliza una implementación azul/verde para implementar cambios en el esquema, realice solo 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](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) en la documentación de MySQL y [Restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) 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](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices). ## Prácticas recomendadas de Aurora MySQL para las implementaciones azul/verde Tenga en cuenta las siguientes prácticas recomendadas a la hora de crear una implementación azul/verde a partir de un clúster de base de datos de Aurora MySQL. + Si el entorno verde presenta un retraso en las réplicas, tenga en cuenta lo siguiente: + Deshabilite la retención de registros binarios si no es necesaria, o deshabilítela temporalmente hasta que la replicación se ponga al día. Para ello, vuelva a establecer el parámetro del clúster de base de datos `binlog_format` en `0` y reinicie la instancia de base de datos del escritor verde. + Establezca temporalmente el parámetro `innodb_flush_log_at_trx_commit` en `0` en el grupo de parámetros de base de datos verde. Una vez que la replicación se ponga al mismo nivel que los valores predeterminados de `1`, vuelva a los valores predeterminados antes de la transición. Si se produce un cierre o bloqueo inesperado con el valor de los parámetros temporales, reconstruya el entorno verde para evitar que los datos se corrompan de forma no detectada. Para obtener más información, consulte [Configuración de la frecuencia de vaciado del búfer de registro](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). ## Prácticas recomendadas de Aurora PostgreSQL para las implementaciones azul/verde Tenga en cuenta las siguientes prácticas recomendadas a la hora de crear una implementación azul/verde a partir de un clúster de base de datos de 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 [Supervisión de la memoria caché de escritura indirecta de la replicación lógica en Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache). + 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. Para obtener más información, consulte [Ajuste de la memoria de trabajo para la descodificación lógica](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem). + Puede supervisar el desbordamiento de transacciones que se escribe en el disco mediante la métrica de CloudWatch `ReplicationSlotDiskUsage`. Esta métrica ofrece información sobre el uso del disco en las ranuras de replicación, lo que ayuda a identificar cuándo los datos de las transacciones superan la capacidad de la memoria y se almacenan en el disco. Puede supervisar la memoria liberable con la métrica `FreeableMemory` de CloudWatch. Para obtener más información, consulte [Métricas de nivel de instancia para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). + En Aurora PostgreSQL versión 14 y posteriores, puede supervisar el tamaño de los archivos de desbordamiento lógico mediante la vista del sistema `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)`. + 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](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). + Si utiliza la extensión `aws_s3`, otorgue acceso al clúster de bases de datos verde 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](postgresql-s3-export-access-bucket.md). + 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 [Actualización a una versión principal](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md). + 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 subtransacciones y transacciones de larga duración que pueden retrasarse hasta que el entorno verde se ponga al mismo nivel que el entorno azul. + Reduzca las operaciones masivas en el entorno azul 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 obtener instrucciones, consulte [Realización de una inmovilización de vacío manual](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html). + En la versión 12 y posteriores de PostgreSQL, deshabilite el parámetro `index_cleanup` en tablas grandes u ocupadas para mejorar la eficiencia del mantenimiento normal en las bases de datos azules. Para obtener más información, consulte [Vaciado de una tabla lo más rápido posible](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing). **nota** Omitir regularmente la limpieza del índice durante la aspiración puede provocar una sobrecarga del índice, lo que podría degradar el rendimiento del escaneo. Como práctica recomendada, utilice este enfoque únicamente cuando utilice una implementación azul/verde. Una vez finalizada la implementación, se recomienda reanudar el mantenimiento y la limpieza periódicos de los índices. + Se puede producir un retraso en la réplica si las instancias de base de datos azules y verdes tienen un tamaño insuficiente para la carga de trabajo. Asegúrese de que sus instancias de base de datos no estén alcanzando sus límites de recursos para el tipo de instancia. Para obtener más información, consulte [Uso de las métricas de Amazon CloudWatch para analizar el uso de los recursos de Aurora PostgreSQL](AuroraPostgreSQL_AnayzeResourceUsage.md). + 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. + Revise el rendimiento de sus instrucciones UPDATE y DELETE y evalúe si la creación de un índice en la columna utilizada en la cláusula WHERE puede optimizar estas consultas. Esto puede mejorar el rendimiento cuando las operaciones se reproducen en un entorno verde. Para obtener más información, consulte [Verificar los filtros de predicado para las consultas que generan esperas](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters). + Si se utilizan desencadenadores, asegúrese de que no interfieran con la creación, actualización y eliminación de objetos `pg_catalog.pg_publication`, `pg_catalog.pg_subscription` y `pg_catalog.pg_replication_slots` objetos cuyos nombres comiencen por “rds”. + Si Babelfish está activado en el clúster de base de datos de origen, los siguientes parámetros deben tener la misma configuración en el grupo de parámetros del clúster de base de datos de destino para el entorno verde que en el grupo de parámetros del clúster de base de datos de origen: + rds.babelfish\$1status + babelfishpg\$1tds.tds\$1default\$1numeric\$1precision + babelfishpg\$1tds.tds\$1default\$1numeric\$1scale + babelfishpg\$1tsql.default\$1locale + babelfishpg\$1tsql.migration\$1mode + babelfishpg\$1tsql.server\$1collation\$1name Para obtener más información sobre estos parámetros, consulte [Configuración del grupo de parámetros del clúster de base de datos para Babelfish](babelfish-configuration.md). ## Prácticas recomendadas de base de datos global de Aurora para las implementaciones azul/verde Además de las prácticas recomendadas generales y específicas del motor mostradas anteriormente, tenga en cuenta las siguientes prácticas recomendadas para la base de datos global de Aurora. + Supervise las siguientes métricas de CloudWatch para identificar los períodos de baja actividad en el entorno de producción: + `DatabaseConnections` + `ActiveTransactions` Programe la transición azul/verde durante el periodo de mantenimiento planificado o durante un periodo de baja actividad. + La duración de la transición azul/verde varía en función de la carga de trabajo y del número de regiones secundarias. Al iniciar una transición azul/verde, el servicio espera a que el retraso de la réplica llegue a cero antes de continuar. Se recomienda comprobar el retraso de la réplica antes de iniciar una transición. + Si piensa utilizar un parámetro de base de datos o un grupo de parámetros de clúster de base de datos distinto del predeterminado para el entorno verde, cree el grupo de parámetros deseado con el mismo nombre en todas las regiones secundarias antes de iniciar la implementación azul/verde.