Prácticas recomendadas para las implementaciones azul/verde
Estos son los procedimientos recomendados para las implementaciones azul/verde.
Temas
Prácticas recomendadas generales
-
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.
Procedimientos recomendados en RDS para MySQL
-
Evite utilizar motores de almacenamiento no transaccionales, como MyISAM, que no estén optimizados para la replicación.
-
Optimice las réplicas de lectura y el entorno verde para la replicación de registros binarios. Si lo admite su motor de base de datos, habilite la replicación GTID, paralela y a prueba de fallos para garantizar la coherencia y la durabilidad de los datos antes de crear una implementación azul/verde. Para obtener más información, consulte Uso de la replicación basada en GTID.
-
Si el entorno verde presenta un retraso en las réplicas, tenga en cuenta lo siguiente:
-
Establezca temporalmente
sync_binlog=0
yinnodb_flush_log_at_trx_commit=2
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, vuelva a los valores predeterminados antes de la transición. Si se produce un cierre o bloqueo inesperado con los valores de los parámetros temporales, reconstruya el entorno verde para evitar que los datos se corrompan de forma no detectada. -
Cambie temporalmente las instancias de base de datos Multi-AZ de color verde por instancias de base de datos Single-AZ para reducir la latencia de escritura y mejorar el rendimiento de la replicación. Vuelva a habilitar Multi-AZ justo antes de la transición.
-
Procedimientos recomendados en RDS para PostgreSQL
-
En RDS para PostgreSQL versión 13 o superior, 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 de CloudWatchFreeableMemory
. Para obtener más información, consulte la documentación de PostgreSQL sobre https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-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. Para obtener más información, consulte Métricas de nivel de instancia de Amazon CloudWatch para Amazon RDS. -
En RDS para PostgreSQL versión 14 y superior, puede supervisar el tamaño de los archivos de desbordamiento lógico mediante la vista de sistema
pg_stat_replication_slots
. -
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 en bases de datos de RDS para 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 depg_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 Realización de una actualización de la versión principal de RDS para PostgreSQL. -
Evite configurar desencadenadores como
ENABLE REPLICA
oENABLE 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.
-
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.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.
-
-
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
en0
en el entorno azul y el parámetrowal_receiver_timeout
en0
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 posteriores, establezca el parámetrowal_keep_size
en 1 TiB, si hay suficiente espacio de almacenamiento libre.