# Actualización de la versión secundaria o el nivel de parche de un clúster de bases de datos Aurora MySQL
Puede utilizar los métodos siguientes para actualizar la versión secundaria de un clúster de bases de datos o para aplicar parches a un clúster de bases de datos:
+ [Actualización de Aurora MySQL mediante la modificación de la versión del motor](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md) (para las versiones 2 y 3 de Aurora MySQL)
+ [Activación de actualizaciones automáticas entre versiones secundarias de Aurora MySQL](AuroraMySQL.Updates.AMVU.md)
Para obtener información acerca de cómo la aplicación de parches sin tiempo de inactividad puede reducir las interrupciones durante el proceso de actualización, consulte [Uso de parches sin tiempo de inactividad](AuroraMySQL.Updates.ZDP.md).
Para obtener información sobre cómo realizar una actualización de una versión secundaria del clúster de base de datos de Aurora MySQL, consulte los siguientes temas.
**Topics**
+ [Antes de realizar una actualización de versión secundaria](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [Comprobaciones previas de actualización de versiones secundarias para Aurora MySQL](#AuroraMySQL.minor-upgrade-prechecks)
+ [Actualización de Aurora MySQL mediante la modificación de la versión del motor](AuroraMySQL.Updates.Patching.ModifyEngineVersion.md)
+ [Activación de actualizaciones automáticas entre versiones secundarias de Aurora MySQL](AuroraMySQL.Updates.AMVU.md)
+ [Uso de parches sin tiempo de inactividad](AuroraMySQL.Updates.ZDP.md)
+ [Técnica alternativa de actualización azul/verde](#AuroraMySQL.UpgradingMinor.BlueGreen)
## Antes de realizar una actualización de versión secundaria
Le recomendamos que lleve a cabo las siguientes acciones para reducir el tiempo de inactividad durante una actualización de versión secundaria:
+ El mantenimiento del clúster de base de datos Aurora debe realizarse durante un periodo de poco tráfico. Utilice Performance Insights para identificar estos periodos de tiempo y configurar correctamente los plazos de mantenimiento. Para obtener más información sobre Performance Insights, consulte [Monitoreo de la carga de base de datos con Performance Insights en Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html). Para obtener más información sobre los periodos de mantenimiento de clústeres de base de datos, consulte [Ajuste de la ventana de mantenimiento preferida para un clúster de base de datos](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
+ Utilice los SDK de AWS que admitan fluctuaciones y retrocesos exponenciales como procedimiento recomendado. Para obtener más información, consulte [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/).
## Comprobaciones previas de actualización de versiones secundarias para Aurora MySQL
Al iniciar una actualización de una versión secundaria, Amazon Aurora ejecuta comprobaciones previas automáticamente.
Estas comprobaciones previas son obligatorias. No tiene la opción de omitirlas. Las comprobaciones previas proporcionan las siguientes ventajas:
+ Le permiten evitar tiempos de inactividad no planeados durante la actualización.
+ Si hay incompatibilidades, Amazon Aurora impide la actualización y proporciona un registro para que se informe sobre ellas. A continuación, podrá usar el registro para preparar la base de datos para la actualización reduciendo así las incompatibilidades. Para obtener información detallada acerca de cómo eliminar incompatibilidades, consulte [Preparing your installation for upgrade](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) en la documentación de MySQL.
Las comprobaciones previas se ejecutan antes de detenerse la instancia de base de datos para la actualización, lo que quiere decir que no causan tiempos de inactividad al ejecutarse. Si las verificaciones previas encuentran una incompatibilidad, Aurora cancela automáticamente la actualización antes de detenerse la instancia de base de datos. Aurora también genera un evento por la incompatibilidad. Para obtener más información acerca de los eventos de Amazon Aurora, consulte [Uso de notificaciones de eventos de Amazon RDS](USER_Events.md).
Aurora registra información detallada acerca de cada incompatibilidad en el archivo de registro `PrePatchCompatibility.log`. En la mayoría de los casos, la entrada de registro incluye un vínculo a la documentación de SQL para corregir la incompatibilidad. Para obtener más información acerca de cómo visualizar los archivos de registro, consulte [Visualización y descripción de archivos de registro de base de datos](USER_LogAccess.Procedural.Viewing.md).
Debido a la naturaleza de las comprobaciones previa, analizan objetos en su base de datos. Este análisis genera un consumo de recursos y aumenta el tiempo de ejecución de la actualización.
# Actualización de Aurora MySQL mediante la modificación de la versión del motor
La actualización de la versión secundaria de un clúster de base de datos de Aurora MySQL aplica correcciones adicionales y nuevas características a un clúster existente.
Este tipo de actualización se aplica a los clústeres de Aurora MySQL en los que la versión original y la versión actualizada tienen la misma versión principal de Aurora MySQL, ya sea 2 o 3. El proceso es rápido y sencillo, ya que no implica ninguna conversión para los metadatos de Aurora MySQL o la reorganización de los datos de la tabla.
Para realizar este tipo de actualización modificando la versión del motor del clúster de bases de datos mediante la Consola de administración de AWS, la AWS CLI o la API de RDS. Por ejemplo, si el clúster está ejecutando Aurora MySQL 3.x, elija una versión posterior a la 3.x.
Si está realizando una actualización secundaria en una base de datos global de Aurora, actualice todos los clústeres secundarios antes de actualizar el clúster principal.
**nota**
Para realizar una actualización de la versión secundaria a la versión 3.04.\$1 o posterior, o a la versión 2.12.\$1 de Aurora MySQL, utilice el siguiente proceso:
Elimine todas las regiones secundarias del clúster global. Siga los pasos de [Eliminación de un clúster de una base de datos global de Amazon Aurora](aurora-global-database-detaching.md).
Actualice la versión del motor de la región principal a la versión 3.04.\$1 o posterior, o a la versión 2.12.\$1, según corresponda. Siga los pasos de [To modify the engine version of a DB cluster](#modify-db-cluster-engine-version).
Añada regiones secundarias al clúster global. Siga los pasos de [Incorporación de una Región de AWS a una base de datos global de Amazon Aurora](aurora-global-database-attaching.md).
**Para modificar la versión del motor de un clúster de bases de datos**
+ **Mediante la consola**: modifique las propiedades del clúster. En la ventana **Modify DB clúster (Modificar clúster de bases de datos)**, cambie la versión del motor de Aurora MySQL en la casilla **DB engine version (Versión del motor de base de datos)**. Si no está familiarizado con el procedimiento general para modificar un clúster, siga las instrucciones de [Modificación del clúster de base de datos con la consola, CLI y API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
+ **Mediante la:AWS CLI** llame al comando [modify-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de la AWS CLI y especifique el nombre del clúster de bases de datos para la opción `--db-cluster-identifier` y la versión del motor para la opción `--engine-version`.
Por ejemplo, para actualizar a la versión 3.04.1 de Aurora MySQL, establezca la opción `--engine-version` en `8.0.mysql_aurora.3.04.1`. Especifique la opción `--apply-immediately` para actualizar inmediatamente la versión del motor para su clúster de bases de datos.
+ **Mediante la API de RDS**: llame a la operación [ModifyDBclúster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) de la API y especifique el nombre de su clúster de bases de datos para el parámetro `DBClusterIdentifier` y la versión del motor para el parámetro `EngineVersion`. Establezca el parámetro `ApplyImmediately` en `true` para actualizar inmediatamente la versión del motor para el clúster de bases de datos.
# Activación de actualizaciones automáticas entre versiones secundarias de Aurora MySQL
Para un clúster de bases de datos Amazon Aurora MySQL puede especificar que Aurora actualice automáticamente el clúster de base de datos a nuevas versiones secundarias. Para ello, establezca la propiedad `AutoMinorVersionUpgrade` (**Actualización automática de la versión secundaria** en la Consola de administración de AWS) del clúster de base de datos.
La actualización automática se produce durante el período de mantenimiento. Si las instancias de base de datos individuales del clúster de base de datos tienen períodos de mantenimiento diferentes a las de la ventana de mantenimiento del clúster, la ventana de mantenimiento del clúster tiene prioridad.
La actualización automática de versiones secundarias no se aplica a los siguientes tipos de clústeres de Aurora MySQL:
+ Clústeres que forman parte de una base de datos de Aurora global
+ Clústeres que tienen réplicas entre regiones
La duración de la interrupción varía en función de la carga de trabajo, el tamaño del clúster, la cantidad de datos de registro binarios y si Aurora puede utilizar la característica de parches de tiempo de inactividad cero (ZDP). Aurora reinicia el clúster de bases de datos, por lo que es posible que experimente un breve periodo de falta de disponibilidad antes de reanudar el uso del clúster. En concreto, la cantidad de datos de log binario afecta al tiempo de recuperación. La instancia de base de datos procesa los datos del registro binario durante la recuperación. Por lo tanto, un gran volumen de datos de registro binario aumenta el tiempo de recuperación.
**nota**
Aurora solo realiza actualizaciones automáticas si todas las instancias de base de datos del clúster tienen la configuración `AutoMinorVersionUpgrade` habilitada. Para obtener información sobre cómo configurarla y cómo funciona cuando se aplica a los niveles de clúster e instancia, consulte [Actualizaciones de versiones secundarias automáticas para clústeres de base de datos de Aurora](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
A continuación, si existe una ruta de actualización para las instancias del clúster de base de datos a una versión secundaria del motor de base de datos que tenga `AutoUpgrade` establecido en true, se realizará la actualización. La opción `AutoUpgrade` es dinámica y la establece RDS.
Las actualizaciones de versiones secundarias automáticas se realizan a la versión secundaria predeterminada.
Puede utilizar un comando de la CLI como el siguiente para comprobar el estado de la configuración `AutoMinorVersionUpgrade` para todas las instancias de base de datos de los clústeres de Aurora MySQL.
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
El resultado de este comando debería ser similar al siguiente:
```
[
{
"DBInstanceIdentifier": "db-t2-medium-instance",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": true
},
{
"DBInstanceIdentifier": "db-t2-small-original-size",
"DBClusterIdentifier": "cluster-57-2020-06-03-6411",
"AutoMinorVersionUpgrade": false
},
{
"DBInstanceIdentifier": "instance-2020-05-01-2332",
"DBClusterIdentifier": "cluster-57-2020-05-01-4615",
"AutoMinorVersionUpgrade": true
},
... output omitted ...
```
En este ejemplo, **Habilitar actualización automática de versiones secundarias** está desactivado para el clúster de base de datos `cluster-57-2020-06-03-6411`, porque está desactivado para una de las instancias de base de datos del clúster.
# Uso de parches sin tiempo de inactividad
Realizar actualizaciones para clústeres de base de datos de Aurora MySQL implica la posibilidad de una interrupción cuando se cierra la base de datos y mientras se actualiza. De forma predeterminada, si comienza la actualización cuando la base de datos está ocupada, perderá todas las conexiones y transacciones que el clúster de bases de datos tiene en proceso. Si espera hasta que la base de datos esté inactiva para realizar la actualización, es posible que tenga que esperar mucho tiempo.
La característica de aplicación de parches sin tiempo de inactividad (ZDP) intenta, en la medida de lo posible, conservar las conexiones de cliente a través de una actualización de Aurora MySQL. Si la ZDP se completa correctamente, las sesiones de aplicación se conservan y el motor de base de datos se reinicia a la vez que la actualización está en curso. El reinicio del motor de base de datos puede provocar una disminución del rendimiento de unos segundos a aproximadamente un minuto.
La ZDP no se aplica a lo siguiente:
+ Revisiones y actualizaciones del sistema operativo (OS)
+ Actualizaciones de la versión principal
ZDP está disponible para todas las versiones de Aurora MySQL y todas las clases de instancia de base de datos admitidas.
ZDP no es compatible con Aurora Serverless v1 o las bases de datos globales de Aurora.
**nota**
Recomendamos que se usen solo las clases de instancia de base de datos T para los servidores de desarrollo y de pruebas, o para otros servidores que no se utilicen para la producción. Para obtener más detalles sobre las clases de instancia T, consulte [Utilización de clases de instancia T para el desarrollo y la prueba](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
Puede ver métricas de atributos importantes durante la ZDP en el registro de errores de MySQL. También puede ver información sobre cuándo Aurora MySQL utiliza la ZDP o elige no usar la ZDP en la página **Eventos** en la Consola de administración de AWS.
En Aurora MySQL, Aurora puede realizar una revisión de tiempo de inactividad cero esté o no habilitada la replicación de registros binarios. Si la replicación de registros binarios está habilitada, Aurora MySQL elimina automáticamente la conexión al destino binlog durante una operación ZDP. Aurora MySQL se reconecta automáticamente al destino binlog y reanuda la reproducción después de que finalice el reinicio.
La ZDP también funciona en combinación con las mejoras de reinicio de Aurora MySQL. La aplicación de parches a la instancia de base de datos del escritor aplica parches de forma automática a los lectores a la vez. Después de aplicar el parche, Aurora restaura las conexiones tanto en las instancias de base de datos del escritor como del lector.
Es posible que la ZDP no se complete correctamente en las siguientes condiciones:
+ Hay en curso consultas o transacciones de ejecución prolongada. Si Aurora puede llevar a cabo una ZDP en este caso, se cancelarán las transacciones abiertas, pero se mantendrán las conexiones.
+ Se están utilizando tablas temporales, bloqueos de usuario o bloqueos de tabla; por ejemplo, mientras se ejecutan instrucciones de lenguaje de definición de datos (DDL). Aurora interrumpe estas conexiones.
+ Existen cambios de parámetros pendientes.
Si no hubiera un período de tiempo apropiado para la realización de la ZDP debido a una o varias de estas condiciones, la aplicación de parches vuelve al comportamiento estándar.
Aunque las conexiones permanecen intactas tras una operación de ZDP correcta, se reinicializan algunas variables y características. Los siguientes tipos de información no se conservan durante un reinicio causado por una aplicación de parches sin tiempo de inactividad:
+ Variables globales. Aurora restaura las variables de sesión, pero no restaura las variables globales después del reinicio.
+ Variables de estado. En particular, el valor del tiempo de actividad que informa el estado del motor se restablece tras un reinicio que utiliza los mecanismos de ZDR o ZDP.
+ `LAST_INSERT_ID`.
+ Estado `auto_increment` en memoria para tablas. El estado de incremento automático en memoria se reinicializa. Para obtener más información sobre los valores de incremento automático, consulte el [Manual de referencia de MySQL](https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization).
+ Información de diagnóstico de las tablas `INFORMATION_SCHEMA` y `PERFORMANCE_SCHEMA`. Esta información de diagnóstico también aparece en la salida de comandos como `SHOW PROFILE` y `SHOW PROFILES`.
Las siguientes actividades relacionadas con el reinicio sin tiempo de inactividad se indican en la página **Events (Eventos)**:
+ Intento de actualizar la base de datos sin tiempo de inactividad.
+ Intento de actualizar la base de datos sin tiempo de inactividad finalizado. El evento informa cuánto tiempo tardó el proceso. El evento también informa sobre cuántas conexiones se conservaron durante el reinicio y cuántas se han eliminado. Puede consultar el registro de errores de la base de datos para ver más detalles sobre lo que ocurrió durante el reinicio.
## Técnica alternativa de actualización azul/verde
En algunas situaciones, su prioridad principal es realizar un cambio inmediato del clúster antiguo a uno actualizado. En tales situaciones, puede utilizar un proceso de varios pasos que ejecuta los clústeres antiguo y nuevo en paralelo. Aquí, replicará los datos del clúster anterior al nuevo hasta que esté listo para que el nuevo clúster asuma el control. Para obtener información, consulte [Uso de las implementaciones azul/verde de Amazon Aurora para actualizar las bases de datos](blue-green-deployments.md).