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