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 (para las versiones 2 y 3 de Aurora MySQL)

• Activación de actualizaciones automáticas entre versiones secundarias de Aurora MySQL

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.

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

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

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 AWS Management Console, la AWS CLI o la API de RDS. Por ejemplo, si el clúster está ejecutando Aurora MySQL 2.x, elija una versión posterior a la 2.x.

Si está realizando una actualización menor 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.03.* o posterior, o a la versión 2.12.* Aurora MySQL, utilice el siguiente proceso:

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

2. Actualice la versión del motor de la región principal a la versión 3.03.* o posterior, o a la versión 2.12.*, según corresponda. Siga los pasos de To modify the engine version of a DB cluster.

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

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 cluster (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.

• Mediante la AWS CLI: llame al comando modify-db-cluster 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 2.12.1 de Aurora MySQL, establezca la opción --engine-version en 5.7.mysql_aurora.2.12.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 ModifyDBCluster 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, use la propiedad de actualización automática de versión secundaria del clúster de base de datos mediante la AWS Management Console, la AWS CLI o la API de RDS.

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 la actualización automática si todas las instancias de base de datos del clúster de base de datos tienen esta configuración activada. Para obtener información sobre cómo configurar la actualización automática de versiones secundarias y cómo funciona la configuración 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.

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 no es compatible con Aurora Serverless v1 o las bases de datos globales de Aurora.

La siguiente tabla muestra las versiones de Aurora MySQL y las clases de base de datos donde está disponible ZDP.

Versión	Clases de instancia db.r*	Clases de instancia db.t*	Clases de instancia db.r*	Clases de instancia db.serverless
Versión 2.07.9 y versiones posteriores a la 2.07	No	Sí	No	N/A
Versiones 2.10.0 posteriores a la 2.x	Sí	Sí	Sí	N/A
3.01.0 y 3.01.1	Sí	Sí	Sí	N/A
Versión 3.02.0 y versiones posteriores a la 3.x	Sí	Sí	Sí	Sí

nota

Recomendamos que las clases de instancia de base de datos T se utilicen solo 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.

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 AWS Management Console.

En Aurora MySQL versión 2.10 y posteriores y la versión 3, 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 2.10 y versiones posteriores. 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. Antes de Aurora MySQL 2.10, la ZDP se aplica únicamente a la instancia de base de datos de escritor de un clúster.

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 ZDP en este caso, se cancelarán las transacciones abiertas.

• Se están utilizando tablas temporales o bloqueos de tabla, por ejemplo mientras se ejecutan instrucciones de lenguaje de definición de datos (DDL). Si Aurora puede llevar a cabo ZDP en este caso, se cancelarán las transacciones abiertas.

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

nota

Para la versión 2 de Aurora MySQL anterior a la 2.11.0 y la versión 3 anterior a la 3.04.0, es posible que ZDP no se complete correctamente si hay conexiones Secure Socket Layer (SSL) o Transport Layer Security (TLS) abiertas.

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.

• 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 más información, consulte Uso de las implementaciones azul/verde de Amazon RDS para actualizar las bases de datos.