Actualización de la versión principal de un clúster de base de datos de Amazon Aurora MySQL - Amazon Aurora
Actualización de Aurora MySQL versión 2 a versión 3Rutas de actualización de versión principal Aurora MySQLCómo funciona la actualización de la versión principal en el lugar Aurora MySQLPlanificación de una actualización de versión principal para un clúster Aurora MySQL

Actualización de la versión principal de un clúster de base de datos de Amazon Aurora MySQL

En un número de versión de Aurora MySQL, como 2.12.1, el 2 representa la versión principal. Aurora MySQL versión 2 es compatible MySQL 5.7 Aurora MySQL versión 3 es compatible MySQL 8.0.

La actualización entre versiones principales requiere una planificación y pruebas más extensas que para una versión secundaria. El proceso puede llevar mucho tiempo. Una vez finalizada la actualización, es posible que también deba hacer trabajo de seguimiento. Por ejemplo, esto puede ocurrir debido a las diferencias en la compatibilidad de SQL o la forma en que funcionan ciertas características relacionadas con MySQL. O puede ocurrir debido a la diferencia en la configuración de los parámetros entre la versión antigua y la nueva.

Contenido

Actualización de Aurora MySQL versión 2 a versión 3

Si tiene un clúster compatible con MySQL 5.7 y desea actualizarlo a un clúster compatible con MySQL-8.0, puede hacerlo ejecutando un proceso de actualización en el propio clúster. Este tipo de actualización es una actualización en el lugar, en contraste con las actualizaciones que se realizan al crear un nuevo clúster. Esta técnica mantiene el mismo punto de enlace y otras características del clúster. La actualización es relativamente rápida ya que no requiere copiar todos los datos en un nuevo volumen de clúster. Esta estabilidad ayuda a minimizar cualquier cambio de configuración en las aplicaciones. También ayuda a reducir la cantidad de pruebas para el clúster actualizado. Esto se debe a que el número de instancias de base de datos y sus clases de instancia permanecen iguales.

El mecanismo de actualización en el lugar implica apagar el clúster de base de datos mientras se lleva a cabo la operación. Aurora realiza un cierre limpio y completa las operaciones pendientes, como la restauración de transacciones y la depuración de deshacer. Para obtener más información, consulte Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL.

El método de actualización in situ es práctico, ya que es fácil de realizar y minimiza los cambios de configuración en las aplicaciones asociadas. Por ejemplo, una actualización en el lugar conserva los puntos de enlace y el conjunto de instancias de base de datos del clúster. Sin embargo, el tiempo necesario para una actualización en el lugar puede variar en función de las propiedades del esquema y de cuán ocupado esté el clúster. Por lo tanto, según las necesidades de su clúster, puede elegir entre las técnicas de actualización:

Para obtener información general sobre Aurora MySQL versión 3 y sus nuevas características, consulte Aurora MySQL versión 3 compatible con MySQL 8.0.

Para obtener más información sobre la planificación de una actualización, consulte Planificación de una actualización de versión principal para un clúster Aurora MySQL y Pasos para realizar una actualización local.

Rutas de actualización de versión principal Aurora MySQL

No todos los tipos o versiones de clústeres Aurora MySQL pueden utilizar el mecanismo de actualización en el lugar. Puede aprender la ruta de actualización adecuada para cada clúster Aurora MySQL consultando la tabla siguiente.

Tipo de clúster de base de datos Aurora MySQL ¿Puede usar la actualización en el lugar? Acción

Clúster aprovisionado de Aurora MySQL, versión 2

Sí

La actualización in situ está disponible para clústeres de Aurora MySQL compatibles con MySQL 5.7.

Para obtener información acerca de la actualización a Aurora MySQL versión 3, consulte Planificación de una actualización de versión principal para un clúster Aurora MySQL y Pasos para realizar una actualización local.

Clúster aprovisionado de Aurora MySQL, versión 3

No aplicable

Utilice un procedimiento de actualización de versiones secundarias para actualizar entre las versiones 3 de Aurora MySQL.

Aurora Serverless v1Clúster de

No aplicable

Aurora Serverless v1 solo es compatible para la versión 2 de Aurora MySQL.

Aurora Serverless v2Clúster de

No aplicable

 Aurora Serverless v2 solo es compatible para la versión 3 de Aurora MySQL.

Clúster en una base de datos global Aurora

Sí

Para actualizar la versión 2 de Aurora MySQL a la versión 3, siga el procedimiento para realizar una actualización local para clústeres en una base de datos global de Aurora. Realice la actualización en el clúster global. Aurora actualiza el clúster principal y todos los clústeres secundarios en la base de datos global al mismo tiempo.

Si utiliza la API RDS o AWS CLI, llame al comando modify-global-cluster o la operación ModifyGlobalCluster en lugar de modify-db-cluster o ModifyDBCluster.

No se puede realizar una actualización local desde la versión 2 a la versión 3 de Aurora MySQL si el parámetro lower_case_table_names está activado. Para obtener más información, consulte Actualizaciones de la versión principal.

Clúster de consultas paralelas

Sí

Puede realizar una actualización local.

Clúster que es el destino de la replicación de registros binarios

Quizás

Si la replicación del registro binario se realiza desde un clúster de Aurora MySQL, puede realizar una actualización local. No puede realizar la actualización si la replicación del registro binario proviene de una instancia de base de datos de RDS para MySQL o de una instancia de base de datos de MySQL en las instalaciones. En ese caso, puede actualizar utilizando el mecanismo de restauración de instantáneas.

Cluster con cero instancias de base de datos

No

Mediante la AWS CLI o la API RDS, puede crear un clúster de Aurora MySQL sin ninguna instancia de base de datos adjunta. De la misma manera, también puede quitar todas las instancias de base de datos de un clúster Aurora MySQL mientras deja intactos los datos del volumen del clúster. Aunque un clúster tiene cero instancias de base de datos, no puede realizar una actualización en el lugar.

El mecanismo de actualización requiere una instancia de escritor en el clúster para realizar conversiones en las tablas del sistema, archivos de datos, etc. En este caso, utilice AWS CLI o la API de RDS para crear una instancia de escritor para el clúster. Luego, puede realizar una actualización en el lugar.

Clúster con retroceso habilitado

Sí

Puede realizar una actualización in situ para un clúster Aurora MySQL que utilice la característica de retroceso. Sin embargo, después de la actualización, no puede realizar un retroceso del clúster hasta un momento anterior a la actualización.

Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL

Aurora MySQL realiza una actualización de versión principal como un proceso de varias etapas. Puede comprobar el estado actual de una actualización. Algunos de los pasos de actualización también proporcionan información sobre el progreso. A medida que comienza cada etapa, Aurora MySQL registra un evento. Puede examinar los eventos a medida que se producen en la página Eventos de la consola de RDS. Para obtener más información sobre el trabajo con eventos, consulte Uso de notificaciones de eventos de Amazon RDS.

importante

Una vez que el proceso comienza, se ejecuta hasta que la actualización se realiza correctamente o falla. No puede cancelar la actualización mientras está en marcha. Si la actualización falla, Aurora revierte todos los cambios y el clúster tiene la misma versión del motor, metadatos, etc. que antes.

El proceso de actualización consta de tres pasos:

  1. Aurora realiza una serie de comprobaciones previas antes de comenzar el proceso de actualización. El clúster sigue ejecutándose mientras Aurora realiza estas comprobaciones. Por ejemplo, el clúster no puede tener transacciones XA en el estado preparado ni procesar ninguna declaración de lenguaje de definición de datos (DDL). Por ejemplo, es posible que deba cerrar las aplicaciones que están enviando ciertos tipos de instrucciones SQL. O puede simplemente esperar hasta que se terminen ciertas instrucciones de larga duración. A continuación, intente la actualización de nuevo. Algunas comprobaciones prueban las condiciones que no impiden la actualización, pero pueden hacer que la actualización tarde mucho tiempo.

    Si Aurora detecta que no se cumplen las condiciones requeridas, modifique las condiciones identificadas en los detalles del evento. Siga la guía de Solución de problemas para la actualización Aurora MySQL en el lugar. Si Aurora detecta condiciones que podrían provocar una actualización lenta, planee supervisar la actualización durante un período prolongado.

  2. Aurora desconecta el clúster. Luego, Aurora realiza un conjunto similar de pruebas que en la etapa anterior, para confirmar que no surgieron nuevos problemas durante el proceso de apagado. Si Aurora detecta alguna condición en este punto que impida la actualización, Aurora cancela la actualización y vuelve a conectarla. En este caso, confirme cuándo ya no se aplican las condiciones e inicie la actualización nuevamente.

  3. Aurora crea una instantánea del volumen del clúster. Supongamos que descubre problemas de compatibilidad u otros tipos de problemas una vez finalizada la actualización. O supongamos que desea realizar pruebas utilizando tanto los clústeres originales como los actualizados. En tales casos, puede restaurar a partir de esta instantánea para crear un nuevo clúster con la versión original del motor y los datos originales.

    sugerencia

    Esta instantánea es una instantánea manual. Sin embargo, Aurora puede crearla y continuar con el proceso de actualización incluso si ha alcanzado la cuota de instantáneas manuales. Esta instantánea permanecerá permanentemente (en caso necesario) hasta que la elimine. Después de finalizar todas las pruebas posteriores a la actualización, puede eliminar esta instantánea para minimizar los cargos de almacenamiento.

  4. Aurora clona el volumen del clúster. La clonación es una operación rápida que no implica copiar los datos reales de la tabla. Si Aurora encuentra un problema durante la actualización, se revierte a los datos originales del volumen del clúster clonado y vuelve a poner el clúster en línea. El volumen clonado temporal durante la actualización no está sujeto al límite habitual en el número de clones para un único volumen de clúster.

  5. Aurora realiza un apagado limpio para la instancia de base de datos del escritor. Durante el apagado limpio, los eventos de progreso se registran cada 15 minutos para las siguientes operaciones. Puede examinar los eventos a medida que se producen en la página Eventos de la consola de RDS.

    • Aurora purga los registros de deshacer de versiones antiguas de filas.

    • Aurora revierte cualquier transacción no confirmada.

  6. Aurora actualiza la versión del motor en la instancia de base de datos de escritor:

    • Aurora instala el binario para la nueva versión del motor en la instancia de base de datos del escritor.

    • Aurora utiliza la instancia de base de datos del escritor para actualizar sus datos al formato compatible con MySQL 5.7. Durante esta etapa, Aurora modifica las tablas del sistema y realiza otras conversiones que afectan a los datos del volumen del clúster. En particular, Aurora actualiza los metadatos de partición en las tablas del sistema para que sean compatibles con el formato de partición MySQL 5.7. Esta etapa puede tardar mucho tiempo si las tablas del clúster tienen un gran número de particiones.

      Si se producen errores durante esta etapa, puede encontrar los detalles en los registros de errores de MySQL. Una vez iniciada esta etapa, si el proceso de actualización falla por cualquier motivo, Aurora restaura los datos originales del volumen del clúster clonado.

  7. Aurora actualiza la versión del motor en las instancias de base de datos del lector.

  8. Se ha completado el proceso de actualización. Aurora registra un evento final para indicar que el proceso de actualización se completó correctamente. Ahora su clúster de base de datos está ejecutando la nueva versión principal.

Planificación de una actualización de versión principal para un clúster Aurora MySQL

Para ayudarle a decidir el momento y el método adecuados para la actualización, infórmese sobre las diferencias entre Aurora MySQL versión 3 y su entorno actual:

También puede encontrar más consideraciones y sugerencias sobre la actualización específica de MySQL en Cambios en MySQL 8.0 en el Manual de referencia de MySQL. Por ejemplo, puede usar el comando mysqlcheck --check-upgrade para analizar las bases de datos Aurora MySQL existentes e identificar posibles problemas de actualización.

nota

Recomendamos usar clases de instancias de base de datos más grandes, al actualizar a Aurora MySQL versión 3 mediante la actualización in situ o la técnica de restauración de instantáneas. Algunos ejemplos son db.r5.24xlarge y db.r6g.16xlarge. Esto ayuda a que el proceso de actualización se complete más rápido al usar la mayor parte de la capacidad de CPU disponible en la instancia de base de datos. Puede cambiar a la clase de instancia de base de datos que desee una vez finalizada la actualización de la versión principal.

Una vez finalizada la actualización, puede seguir los procedimientos posteriores a la actualización en Limpieza posterior a la actualización para Aurora MySQL versión 3. Por último, pruebe la funcionalidad y el rendimiento de su aplicación.

Si va a convertir desde RDS para MySQL o la comunidad MySQL, siga el procedimiento de migración que se explica en Migración de datos a un clúster de base de datos de Amazon Aurora MySQL. En algunos casos, puede utilizar la replicación de registros binarios para sincronizar los datos con un clúster Aurora MySQL versión 3 como parte de la migración. Si es así, el sistema de origen debe ejecutar una versión compatible con su clúster de base de datos de destino.

Para asegurarse de que las aplicaciones y los procedimientos de administración funcionan sin problemas después de actualizar un clúster de una versión principal a otra, realice tareas de planificación y preparación con antelación. Para ver qué tipos de código de administración se deben actualizar para sus scripts de AWS CLI o aplicaciones basadas en la API de RDS, consulte Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster. Consulte también Cambios en las propiedades del clúster entre versiones de Aurora MySQL.

Para obtener información sobre los problemas que pueden surgir durante la actualización, consulte Solución de problemas para la actualización Aurora MySQL en el lugar. En caso de problemas que podrían hacer que la actualización tarde mucho tiempo, puede probar esas condiciones con antelación y corregirlas.

nota

Un mecanismo de actualización in situ implica apagar el clúster de base de datos mientras se lleva a cabo la operación. Aurora MySQL realiza un apagado limpio y completa las operaciones pendientes, como la depuración de deshacer. Una actualización puede tardar mucho tiempo si hay que depurar muchos registros de deshacer. Recomendamos realizar la actualización solo después de que la longitud de la lista de historial (HLL) sea baja. Un valor generalmente aceptable de HLL es de 100 000 o menos. Para obtener más información, consulte esta entrada del blog.

Simulación de la actualización mediante la clonación del clúster de base de datos

También puede comprobar los procedimientos de compatibilidad, rendimiento y mantenimiento de las aplicaciones y consideraciones similares para el clúster actualizado. Para ello, puede realizar una simulación de la actualización antes de realizar la actualización en sí. Esta técnica puede ser especialmente útil para clústeres de producción. Aquí, es importante minimizar el tiempo de inactividad y tener listo el clúster actualizado tan pronto como finalice la actualización.

Utilice los siguientes pasos:

  1. Cree un clon del clúster original. Siga el procedimiento indicado en Clonación de un volumen de clúster de base de datos de Amazon Aurora.

  2. Configure un conjunto similar de instancias de base de datos de escritor y lector como en el clúster original.

  3. Realice una actualización en el lugar del clúster clonado. Siga el procedimiento indicado en Pasos para realizar una actualización local.

    Inicie la actualización inmediatamente después de crear el clon. De esta forma, el volumen del clúster sigue siendo idéntico al estado del clúster original. Si el clon se encuentra inactivo antes de realizar la actualización, Aurora realiza procesos de limpieza de la base de datos en segundo plano. En ese caso, la actualización del clon no es una simulación precisa de la actualización del clúster original.

  4. Pruebe los procedimientos de compatibilidad, rendimiento y administración de las aplicaciones, etc., utilizando el clúster clonado.

  5. Si encuentra algún problema, ajuste sus planes de actualización para que los tengan en cuenta. Por ejemplo, adapte cualquier código de aplicación para que sea compatible con el conjunto de características de la versión superior. Calcule cuánto tiempo puede tardar la actualización en función de la cantidad de datos del clúster. También puede programar la actualización para un momento en el que el clúster no esté ocupado.

  6. Una vez que esté satisfecho con el funcionamiento de las aplicaciones y la carga de trabajo en el clúster de prueba, puede realizar la actualización en el lugar para el clúster de producción.

  7. Esfuércese para minimizar el tiempo de inactividad total de su clúster durante una actualización de versión principal. Para ello, asegúrese de que la carga de trabajo del clúster sea baja o nula en el momento de la actualización. En particular, asegúrese de que no haya transacciones en curso durante mucho tiempo al iniciar la actualización.

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