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

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.

rds:AddTagsToResource

rds:CreateDBInstanceReadReplica

rds:ModifyDBInstance

rds:PromoteReadReplica

rds:DeleteDBInstance

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 RDS en AWS CloudTrail.

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

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

Si tiene roles de IAM asociados a la instancia 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 instancia 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 utiliza AWS Backup para administrar copias de seguridad automatizadas de los recursos en una implementación azul/verde, ajuste los identificadores de recursos que ha utilizado AWS Backup después de la conmutación. Para obtener más información, consulte Utilizar AWS Backup para administrar copias de seguridad automatizadas.

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

Si desea describir una copia de seguridad automática de una instancia de base de datos del entorno azul anterior o restaurarla en un momento determinado, utilice el identificador del recurso para la operación.

Como el nombre de la instancia de base de datos se modifica durante la conmutación, no puede usar su nombre anterior para las operaciones DescribeDBInstanceAutomatedBackups o RestoreDBInstanceToPointInTime.

Para obtener más información, consulte Restauración de una instancia de base de datos a un momento especificado.

Al añadir una réplica de lectura a una instancia de base de datos en el entorno verde de una implementación azul/verde, la nueva réplica de lectura no reemplazará a una réplica de lectura en el entorno azul cuando conmute. Sin embargo, la nueva réplica de lectura se conserva en el nuevo entorno de producción tras la conmutación.

Al eliminar una instancia 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 el mismo nombre de recurso de Amazon (ARN) que la instancia de base de datos eliminada, tendrá un DbiResourceId diferente, por lo que no forma parte del entorno verde.

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

El mismo comportamiento se aplica a las instancias de base de datos y a las réplicas de lectura.

Pruebe minuciosamente las instancias de base de datos 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.

Tras crear la implementación azul/verde, gestione la carga diferida si es necesario. Asegúrese de que la carga de datos esté completa antes de realizar el cambio. Para obtener más información, consulte Gestión de la carga diferida al crear una implementación azul/verde.

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.

Evite utilizar motores de almacenamiento no transaccionales, como MyISAM, que no estén optimizados para la replicación.

Optimice las réplicas de lectura para replicación de registros binarios.

Por ejemplo, si la versión de su motor de base de datos lo admite, considere la posibilidad de utilizar la replicación GTID, la replicación paralela y la replicación a prueba de fallos en su entorno de producción antes de utilizar la implementación azul/verde. Estas opciones fomentan la coherencia y la durabilidad de los datos antes de conmutar la implementación azul/verde. Para obtener más información sobre la replicación basada en GTID para réplicas de lectura, consulte Uso de la replicación basada en GTID.

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 nivel de instancia de Amazon CloudWatch para Amazon RDS.

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 de la instancia de base 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:

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.

Para evitar que los segmentos de registro de escritura anticipada (WAL) se eliminen del entorno azul, establezca el parámetro wal_keep_segments en 15625 para PostgreSQL versión 13 y versiones anteriores. Para la versión 14 y superiores, establezca el parámetro wal_keep_size en 1 TiB, si hay suficiente espacio de almacenamiento libre.

Las versiones 8.0.11 a 8.0.13 de MySQL tienen un error comunitario que les impide admitir las implementaciones azul/verde.

Se admiten las siguientes versiones de RDS para PostgreSQL como versiones de origen y destino de la actualización: 11.21 y posteriores, 12.16 y posteriores, 13.12 y posteriores, 14.9 y posteriores y 15.4 y posteriores. En las versiones anteriores, puede realizar una actualización de versión secundaria a una versión compatible.

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

En el caso de RDS para PostgreSQL, las tablas no registradas no se replican en el entorno verde

En el caso de RDS para PostgreSQL, la instancia 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 RDS para MySQL, la instancia 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 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:

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.

Si la instancia de base de datos está configurado como el servidor externo de un contenedor de datos externo (FDW), debe usar el nombre del punto de conexión de la instancia 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.

No puede cambiar una instancia de base de datos sin cifrar por una instancia de base de datos con cifrado.

No puede cambiar una instancia de base de datos con cifrado por una instancia de base de datos sin cifrar.

No puede cambiar una instancia de base de datos del entorno azul por una versión del motor superior a su instancia 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.

En RDS para MySQL, si la base de datos de origen está asociada a un grupo de opciones personalizado, no puede especificar una actualización de la versión principal al crear la implementación azul/verde.

En este caso, puede crear una implementación azul/verde sin especificar una actualización de la versión principal. A continuación, puede actualizar la base de datos en el entorno verde. Para obtener más información, consulte Actualización de una versión del motor de una instancia de base de datos.