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
- Planificación de una actualización de versión principal para un clúster Aurora MySQL
- Comprobaciones previas de actualización de versiones principales para Aurora MySQL
- Rutas de actualización de versión principal Aurora MySQL
- Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL
- Implementaciones azul/verde
- Pasos para realizar una actualización local
- Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster
- Cambios en las propiedades del clúster entre versiones de Aurora MySQL
- Actualizaciones mayores en el lugar para bases de datos globales
- Consideraciones sobre el Backtrack
- Tutorial de actualización de Aurora MySQL en el lugar
- Búsqueda de motivos de los errores de actualización
- Solución de problemas para la actualización Aurora MySQL en el lugar
- Limpieza posterior a la actualización para Aurora MySQL versión 3
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:
-
nota
Si utiliza la AWS CLI o la API de RDS para el método de actualización de restauración de instantáneas, debe ejecutar una operación posterior para crear una instancia de base de datos de escritor en el clúster de base de datos restaurado.
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.
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:
-
Si va a convertir desde RDS para MySQL 8.0 o MySQL 8.0 Community Edition, consulte Comparación de Aurora MySQL versión 3 y MySQL 8.0 Community Edition.
-
Si va a actualizar desde Aurora MySQL versión 2, RDS para MySQL 5.7 o la comunidad MySQL 5.7, consulte Comparación de Aurora MySQL versión 2 y Aurora MySQL versión 3.
-
Cree nuevas versiones compatibles con MySQL 8.0 de cualquier grupo de parámetros personalizados. Aplique los valores de parámetros personalizados necesarios a los nuevos grupos de parámetros. Consulte Cambios de parámetros para Aurora MySQL versión 3 para obtener más información sobre los cambios de parámetros.
-
Revise las definiciones de objeto y el esquema de base de datos de Aurora MySQL versión 2 para ver el uso de las nuevas palabras clave reservadas introducidas en MySQL 8.0 Community Edition. Hágalo antes de realizar la actualización. Para obtener más información, consulte la página sobre palabras clave y palabras reservadas de MySQL 8.0
en la documentación de MySQL.
También puede encontrar más consideraciones y sugerencias sobre la actualización específica de MySQL en Cambios en MySQL 8.0mysqlcheck --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:
-
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.
-
Configure un conjunto similar de instancias de base de datos de escritor y lector como en el clúster original.
-
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.
-
Pruebe los procedimientos de compatibilidad, rendimiento y administración de las aplicaciones, etc., utilizando el clúster clonado.
-
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.
-
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.
-
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.
Uso de la técnica de actualización azul/verde
También puede crear una implementación azul/verde que ejecuta los clústeres antiguo y nuevo, uno junto a otro. 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.
Comprobaciones previas de actualización de versiones principales para Aurora MySQL
MySQL 8.0 presenta numerosas incompatibilidades con MySQL 5.7. Dichas incompatibilidades pueden causar problemas durante una actualización de Aurora MySQL versión 2 a la versión 3. Puede requerirse cierta preparación con respecto a su base de datos para que la actualización se realice correctamente.
Si inicia una actualización de Aurora MySQL versión 2 a la versión 3, Amazon Aurora ejecutará comprobaciones previas de forma automática para detectar estas incompatibilidades.
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. Luego podrá usar el registro para preparar su base de datos para la actualización a la versión 3 y reducir así las incompatibilidades. Para obtener información detallada acerca de cómo eliminar incompatibilidades, consulte Preparing your installation for upgrade
en la documentación de MySQL y Upgrading to MySQL 8.0? Here is what you need to know... en el blog de MySQL Server. Para obtener más información acerca de cómo actualizar a MySQL 8.0, consulte la sección sobre la actualización de MySQL
en la documentación de MySQL.
Entre las comprobaciones previas se incluyen algunas que a su vez se incluyen con MySQL y otras que el equipo de Aurora creó específicamente. Para obtener información acerca de las comprobaciones previas que proporciona MySQL, consulte la sección sobre la utilidad del comprobador de actualización
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.
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.
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.
Comprobaciones previas de actualización de MySQL en la comunidad
A continuación, se muestra una lista general de incompatibilidades entre MySQL 5.7 y 8.0:
-
Su clúster de base de datos compatible con MySQL 5.7 no puede usar características que no sean compatibles con MySQL 8.0.
Para obtener más información, consulte la sección sobre características eliminadas en MySQL 8.0
, en la documentación de MySQL. -
No debe haber ninguna infracción de la palabra clave ni de la palabra reservada. Es posible que en MySQL 8.0 haya algunas palabras clave reservadas que no estaban reservadas previamente.
Para obtener más información, consulte la página sobre Palabras clave y palabras reservadas
en la documentación de MySQL. -
Para mejorar la compatibilidad de Unicode, piense en convertir objetos que usen el conjunto de caracteres
utf8mb3
para usar el conjunto de caracteresutf8mb4
. El conjunto de caracteresutf8mb3
ha quedado obsoleto. Asimismo, piense en utilizarutf8mb4
para referencias de conjuntos de caracteres, en vez de utilizarutf8
, ya que actualmenteutf8
es un alias del conjunto de caracteresutf8mb3
.Para obtener más información, consulte la sección sobre el conjunto de caracteres utf8mb3 (codificación Unicode UTF-8 de 3 bytes)
en la documentación de MySQL. -
No debe haber tablas InnoDB con un formato de fila que no sea el predeterminado.
-
No debe haber atributos de tipo de longitud
ZEROFILL
odisplay
. -
Ninguna tabla particionada debe usar un motor de almacenamiento que no tenga soporte de particiones nativo.
-
No tiene que haber tablas en la base de datos del sistema
mysql
de MySQL 5.7 que tengan el mismo nombre que una tabla usada por el diccionario de datos de MySQL 8.0. -
Ninguna tabla debe usar tipos o funciones de datos obsoletos.
-
No tiene que haber nombres de restricción de clave externa que superen los 64 caracteres.
-
No tiene que haber modos SQL obsoletos en su configuración de variable del sistema
sql_mode
. -
No tiene que haber tablas ni procedimientos almacenados que tengan elementos de columna
ENUM
oSET
individuales que superen los 255 caracteres de longitud. -
Ninguna partición de tabla debe residir en espacios de tablas InnoDB compartidos.
-
No debe haber referencias circulares en las rutas de los archivos de datos de los espacios de tablas.
-
No tiene que haber consultas ni definiciones de programas almacenadas que usen calificadores
ASC
oDESC
para cláusulasGROUP BY
. -
No debe haber ninguna variable de sistema eliminada y las variables de sistema deben usar los nuevos valores predeterminados para MySQL 8.0.
-
No debe haber valores de fecha, fecha y hora o marca temporal que sean cero (
0
). -
No debe haber inconsistencias en el esquema causadas por la eliminación o la corrupción de un archivo.
-
No debe haber nombres de tablas que contengan la cadena de caracteres
FTS
. -
No debe haber tablas InnoDB que pertenezcan a un motor diferente.
-
No debe haber nombres de tablas o esquemas que no sean válidos para MySQL 5.7.
Para obtener más información acerca de cómo actualizar a MySQL 8.0, consulte la sección sobre la actualización de MySQL
Comprobaciones previas de actualización de Aurora MySQL
Aurora MySQL tiene sus propios requisitos específicos al actualizar de la versión 2 a la versión 3:
-
No debe haber ninguna sintaxis SQL obsoleta, como
SQL_CACHE
,SQL_NO_CACHE
yQUERY_CACHE
, en las vistas, las rutinas, los disparadores y los eventos. -
No debe haber ninguna columna
FTS_DOC_ID
en ninguna tabla sin el índiceFTS
. -
No debe haber ninguna discrepancia en la definición de columna entre el diccionario de datos de InnoDB y la definición real de la tabla.
-
Todos los nombres de bases de datos y tablas deben estar en minúscula cuando el parámetro
lower_case_table_names
esté configurado como1
. -
No debe haber un definidor vacío ni faltar un definidor en los eventos y disparadores, y el contexto de creación de los disparadores tiene que ser válido.
-
Todos los nombres de los activadores de una base de datos tienen que ser únicos.
-
La recuperación de DDL y la DDL rápida no son compatibles con la versión 3 de Aurora MySQL. No debe haber artefactos en las bases de datos relacionados con estas características.
-
Las tablas con el formato de fila
REDUNDANT
oCOMPACT
no pueden tener índices de más de 767 bytes. -
La longitud del prefijo de los índices definidos en las columnas de texto
tiny
no puede superar los 255 bytes. Con el conjunto de caracteresutf8mb4
configurado, esto limita la longitud de prefijo admitida a 63 caracteres.Se permitía una longitud de prefijo mayor en MySQL 5.7 utilizando el parámetro
innodb_large_prefix
. Este parámetro ha quedado obsoleto en MySQL 8.0. -
No debe haber ninguna incoherencia en los metadatos de InnoDB en la tabla
mysql.host
. -
No debe haber ninguna discrepancia en los tipos de datos de las columnas en las tablas del sistema.
-
No debe haber transacciones XA en el estado
prepared
. -
Los nombres de las columnas de las vistas no pueden tener más de 64 caracteres.
-
Los caracteres especiales de los procedimientos almacenados no pueden ser incoherentes.
-
Las tablas no pueden tener incoherencias en las rutas de los archivos de datos.
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 Aurora MySQL, 2.0 o superior |
Sí |
La actualización i situ es compatible con clústeres de Aurora MySQL compatibles con 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 Aurora MySQL, 3.01.0 o superior |
N/A |
Utilice un procedimiento de actualización de versiones secundarias para actualizar entre las versiones 3 de Aurora MySQL. |
Aurora Serverless v1Clúster de |
N/A |
En la actualidad, Aurora Serverless v1 solo se admite para Aurora MySQL versión 2. |
Aurora Serverless v2Clúster de |
N/A |
En la actualidad, Aurora Serverless v2 solo se admite para Aurora MySQL versión 3. |
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 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 |
Clúster de consultas paralelas |
Sí |
Puede realizar una actualización local. En este caso, elija 2.09.1 o superior para la versión Aurora MySQL. |
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 en el lugar para un clúster Aurora MySQL que utilice la función 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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
-
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.
-
-
Aurora actualiza la versión del motor en las instancias de base de datos del lector.
-
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.
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.
Pasos para realizar una actualización local
También le recomendamos que revise el material de referencia en Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL.
Realice cualquier planificación y prueba previas a la actualización, tal y como se describe en Planificación de una actualización de versión principal para un clúster Aurora MySQL.
En el ejemplo siguiente se actualiza el clúster de base de datos mydbcluster-cluster
a la versión Aurora MySQL 3.04.1.
Para actualizar la versión principal de un clúster de base de datos Aurora MySQL
-
Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/
. -
Si utilizó un grupo de parámetros personalizado con el clúster de base de datos original, cree un grupo de parámetros compatible con la nueva versión principal. Realice los ajustes necesarios en los parámetros de configuración del nuevo grupo de parámetros. Para obtener más información, consulte Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster.
-
En el panel de navegación, seleccione Databases (Bases de datos).
-
En la lista, elija el clúster de base de datos que desea modificar.
-
Elija Modify.
-
Para Version (Versión), elija una nueva versión principal de Aurora.
También le recomendamos que utilice la versión secundaria de la versión principal. A continuación, elegimos la versión predeterminada actual.
-
Elija Continue.
-
En la página siguiente, especifique cuándo realizar la actualización. Seleccione During the next scheduled maintenance window (Durante la siguiente ventana de mantenimiento programado) o Immediately (Inmediatamente).
-
(Opcional) Examine periódicamente la página Events (Eventos) de la consola RDS durante la actualización. Esto le ayuda a supervisar el progreso de la actualización e identificar cualquier problema. Si la actualización encuentra algún problema, consulte Solución de problemas para la actualización Aurora MySQL en el lugar para conocer los pasos a seguir.
-
Si creó un nuevo grupo de parámetros al inicio de este procedimiento, asocie el grupo de parámetros personalizados con el clúster actualizado. Para obtener más información, consulte Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster.
nota
Para realizar este paso, deberá reiniciar el clúster de nuevo para aplicar el nuevo grupo de parámetros.
-
(Opcional) Después de completar las pruebas posteriores a la actualización, elimine la instantánea manual que Aurora creó al comienzo de la actualización.
Para actualizar la versión principal de un clúster de base de datos de Aurora MySQL, utilice el comando modify-db-cluster de la AWS CLI con los siguientes parámetros requeridos:
-
--db-cluster-identifier
-
--engine-version
-
--allow-major-version-upgrade
-
--apply-immediately
o--no-apply-immediately
Si el clúster utiliza algún grupo de parámetros personalizados, incluya también una o ambas opciones:
-
--db-cluster-parameter-group-name
, si el clúster utiliza un grupo de parámetros de clúster personalizado -
--db-instance-parameter-group-name
, si alguna instancia del clúster utiliza un grupo de parámetros de base de datos personalizado
En el ejemplo siguiente se actualiza el clúster de base de datos sample-cluster
a la versión Aurora MySQL 3.04.1. La actualización se realiza inmediatamente, en lugar de esperar la siguiente ventana de mantenimiento.
ejemplo
Para Linux, macOS o Unix:
aws rds modify-db-cluster \ --db-cluster-identifier sample-cluster \ --engine-version 8.0.mysql_aurora.3.04.1 \ --allow-major-version-upgrade \ --apply-immediately
En Windows:
aws rds modify-db-cluster ^ --db-cluster-identifier sample-cluster ^ --engine-version 8.0.mysql_aurora.3.04.1 ^ --allow-major-version-upgrade ^ --apply-immediately
Puede combinar otros comandos de CLI con modify-db-cluster
para crear un proceso automatizado de extremo a extremo para realizar y verificar actualizaciones. Para obtener más información y ejemplos, consulte Tutorial de actualización de Aurora MySQL en el lugar.
nota
Si el clúster forma parte de una base de datos global Aurora, el procedimiento de actualización en el lugar es ligeramente diferente. Se llama a la operación de comando modify-global-cluster en lugar de modify-db-cluster
. Para obtener más información, consulte Actualizaciones mayores en el lugar para bases de datos globales.
Para actualizar la versión principal de un clúster de base de datos Aurora MySQL, utilice la operación de la API de RDS ModifyDBCluster con los siguientes parámetros requeridos:
-
DBClusterIdentifier
-
Engine
-
EngineVersion
-
AllowMajorVersionUpgrade
-
ApplyImmediately
(establecido entrue
ofalse
)
nota
Si el clúster forma parte de una base de datos global Aurora, el procedimiento de actualización en el lugar es ligeramente diferente. Se llama a la operación ModifyGlobalCluster en lugar de ModifyDBCluster
. Para obtener más información, consulte Actualizaciones mayores en el lugar para bases de datos globales.
Cómo afectan las actualizaciones en el lugar a los grupos de parámetros de un clúster
Los grupos de parámetros de Aurora tienen diferentes conjuntos de opciones de configuración para los clústeres compatibles con MySQL 5.7 u 8.0. Al realizar una actualización en el centro, el clúster actualizado y todas sus instancias deben utilizar los grupos de parámetros de clúster e instancia correspondientes.
Es posible que el clúster y las instancias usen los grupos de parámetros predeterminados compatibles con la versión 5.7. Si es así, el clúster y la instancia actualizados comienzan con los grupos predeterminados de parámetros compatibles con 8.0. Si su clúster e instancias utilizan algún grupo de parámetros personalizado, asegúrese de crear los correspondientes grupos de parámetros compatibles con 8.0. También asegúrese de especificarlos durante el proceso de actualización.
nota
Para la mayoría de las configuraciones de parámetros, puede elegir el grupo de parámetros personalizado en dos puntos. Esto es al crear el clúster o asociar el grupo de parámetros al clúster más adelante.
Sin embargo, si utiliza una configuración no predeterminada para el parámetro lower_case_table_names
, debe configurar el grupo de parámetros personalizado con esta configuración de antemano. A continuación, especifique el grupo de parámetros durante la restauración de instantáneas para la creación de clúster. Cualquier cambio en el parámetro lower_case_table_names
no tiene efecto después de crear el clúster.
Le recomendamos que utilice la misma configuración para lower_case_table_names
cuando actualice de la versión 2 de Aurora MySQL a la versión 3.
Con una base de datos global de Aurora basada en Aurora MySQL, 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 sobre los métodos que puede utilizar, consulte Actualizaciones de la versión principal.
importante
Si especifica algún grupo de parámetros personalizado durante el proceso de actualización, asegúrese de reiniciar manualmente el clúster una vez finalizada la actualización. Al hacerlo, el clúster comienza a usar la configuración de parámetros personalizados.
Cambios en las propiedades del clúster entre versiones de Aurora MySQL
Cuando actualice de la versión 2 a la versión 3 de Aurora MySQL, asegúrese de comprobar cualquier aplicación o script que utilice para configurar o administrar clústeres e instancias de base de datos de Aurora MySQL.
Además, cambie el código que manipula los grupos de parámetros para tener en cuenta el hecho de que los nombres de grupos de parámetros predeterminados son diferentes para los clústeres compatibles con 5.7 y 8.0. Los nombres de los grupos de parámetros predeterminados para los clústeres de las versiones 2 y 3 de Aurora MySQL son default.aurora-mysql5.7
y default.aurora-mysql8.0
, respectivamente.
Por ejemplo, es posible que tenga código como el siguiente que se aplique al clúster antes de una actualización.
# Check the default parameter values for MySQL 5.7–compatible clusters. aws rds describe-db-parameters
--db-parameter-group-name default.aurora-mysql5.7
--region us-east-1
Después de actualizar la versión principal del clúster, modifique ese código de la siguiente manera.
# Check the default parameter values for MySQL 8.0–compatible clusters. aws rds describe-db-parameters
--db-parameter-group-name default.aurora-mysql8.0
--region us-east-1
Actualizaciones mayores en el lugar para bases de datos globales
Para una base de datos global de Aurora, actualice el clúster de la base de datos global. Aurora actualiza automáticamente todos los clústeres al mismo tiempo y se asegura de que todos ejecuten la misma versión del motor. Este requisito se debe a que cualquier cambio en las tablas del sistema, formatos de archivo de datos, etc., se replican automáticamente en todos los clústeres secundarios.
Siga las instrucciones en Cómo funciona la actualización de la versión principal en el lugar Aurora MySQL. Cuando especifique qué actualizar, asegúrese de elegir el clúster de base de datos global en lugar de uno de los clústeres que contiene.
Si utiliza la AWS Management Console, elija el elemento con el rol Global database (Base de datos global).
![Actualización del clúster de base de datos global](images/aurora-global-databases-major-upgrade-global-cluster.png)
Si utiliza la AWS CLI o la API de RDS, inicie el proceso de actualización llamando al comando modify-global-cluster o la operación ModifyGlobalCluster. Se usa uno de estos en lugar de modify-db-cluster
o ModifyDBCluster
.
nota
No puede especificar un grupo de parámetros personalizado para el clúster de base de datos global mientras realiza una actualización importante de la versión de esa base de datos global de Aurora. Cree grupos de parámetros personalizados en cada región del clúster global. A continuación, aplíquelos manualmente a los clústeres regionales después de la actualización.
Para actualizar la versión principal de un clúster de base de datos global de Aurora MySQL, utilice el comando modify-global-cluster de la AWS CLI con los siguientes parámetros requeridos:
-
--global-cluster-identifier
-
--engine aurora-mysql
-
--engine-version
-
--allow-major-version-upgrade
En el ejemplo siguiente se actualiza el clúster de base de datos global a la versión 2.10.2 de Aurora MySQL.
ejemplo
Para Linux, macOS o Unix:
aws rds modify-global-cluster \ --global-cluster-identifier
global_cluster_identifier
\ --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.10.2 \ --allow-major-version-upgrade
En Windows:
aws rds modify-global-cluster ^ --global-cluster-identifier
global_cluster_identifier
^ --engine aurora-mysql ^ --engine-version 5.7.mysql_aurora.2.10.2 ^ --allow-major-version-upgrade
Consideraciones sobre el Backtrack
Si el clúster que actualizó tenía habilitada la característica Backtrack, no podrá realizar un retroceso del clúster actualizado a una hora anterior a la actualización.
Tutorial de actualización de Aurora MySQL en el lugar
En los siguientes ejemplos de Linux se muestra cómo se pueden realizar los pasos generales del procedimiento de actualización en el lugar utilizando AWS CLI.
Este primer ejemplo crea un clúster de base de datos Aurora que ejecuta una versión 2.x de Aurora MySQL. El clúster incluye una instancia de base de datos de escritura y una instancia de base de datos de lector. El comando wait
db-instance-available
se detiene hasta que la instancia de base de datos del escritor esté disponible. Ese es el momento en que el clúster está listo para ser actualizado.
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \ --db-cluster-version 5.7.mysql_aurora.2.10.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \ --db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
Las versiones de Aurora MySQL 3.x en las que puede actualizar el clúster dependen de la versión 2.x en la que se está ejecutando actualmente el clúster y en la Región de AWS donde se encuentra el clúster. El primer comando, con --output text
, solo muestra la versión de destino disponible. El segundo comando muestra la salida JSON completa de la respuesta. En esa respuesta, puede ver detalles como el valor aurora-mysql
que utiliza para el parámetro engine
. También puede ver el hecho de que la actualización a 3.02.0 es una actualización de la versión principal.
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \ --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \ --query '*[].[ValidUpgradeTarget]'... { "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "Description": "Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23)", "AutoUpgrade": false, "IsMajorVersionUpgrade": true, "SupportedEngineModes": [ "provisioned" ], "SupportsParallelQuery": true, "SupportsGlobalDatabases": true, "SupportsBabelfish": false }, ...
En este ejemplo, se muestra que si ingresa un número de versión de destino que no es un destino de actualización válido para el clúster, Aurora no realiza la actualización. Aurora tampoco realiza una actualización de versión principal, a menos que incluya el parámetro --allow-major-version-upgrade
. De esta manera, no puede realizar accidentalmente una actualización que tenga el potencial de requerir pruebas exhaustivas y cambios en el código de su aplicación.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \ --engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.10.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \ --engine-version 8.0.mysql_aurora.3.02.0 --region us-east-1 --apply-immediatelyAn error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \ --engine-version 8.0.mysql_aurora.3.02.0 --apply-immediately --allow-major-version-upgrade{ "DBClusterIdentifier": "mynewdbcluster", "Status": "available", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.2" }
El estado del clúster y las instancias de base de datos asociadas tardan unos minutos en cambiar a upgrading
. Los números de versión del clúster y de las instancias de base de datos solo cambian cuando finaliza la actualización. De nuevo, puede utilizar el comando wait
db-instance-available
para que la instancia de base de datos de escritor espere hasta que finalice la actualización antes de continuar.
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \ --query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.10.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \ --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'{ "DBInstanceIdentifier": "mynewdbcluster-instance1", "DBInstanceStatus": "upgrading" }
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
En este punto, el número de versión del clúster coincide con el especificado para la actualización.
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \ --query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.02.0
En el ejemplo anterior se realizó una actualización inmediata especificando el parámetro --apply-immediately
. Para permitir que la actualización se realice en un momento conveniente cuando no se espera que el clúster esté ocupado, puede especificar el parámetro --no-apply-immediately
. Al hacerlo, la actualización se iniciará durante la siguiente ventana de mantenimiento del clúster. La ventana de mantenimiento define el período durante el cual se pueden iniciar las operaciones de mantenimiento. Es posible que una operación de larga duración no finalice durante el período de mantenimiento. Por lo tanto, no necesita definir una ventana de mantenimiento más grande, incluso si espera que la actualización pueda tardar mucho tiempo.
En el ejemplo siguiente, se actualiza un clúster que ejecuta inicialmente Aurora MySQL 2.10.2. En la salida de describe-db-engine-versions
, los valores False
y True
representan la propiedad IsMajorVersionUpgrade
. Desde la versión 2.10.2, puede actualizar a otras versiones 2.*. Esas actualizaciones no se consideran actualizaciones de versión principales, por lo que no requieren una actualización in situ. La actualización local solo está disponible para las actualizaciones a las versiones 3.* que se muestran en la lista.
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \ --query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.10.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \ --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text5.7.mysql_aurora.2.10.3 False 5.7.mysql_aurora.2.11.0 False 5.7.mysql_aurora.2.11.1 False 8.0.mysql_aurora.3.01.1 True 8.0.mysql_aurora.3.02.0 True 8.0.mysql_aurora.3.02.2 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \ --engine-version 8.0.mysql_aurora.3.02.0 --no-apply-immediately --allow-major-version-upgrade...
Cuando se crea un clúster sin una ventana de mantenimiento especificada, Aurora selecciona un día aleatorio de la semana. En este caso, el comando modify-db-cluster
se envía un lunes. Por lo tanto, cambiamos la ventana de mantenimiento para que sea el martes por la mañana. Todas las horas se representan en la zona horaria UTC. El periodo tue:10:00-tue:10:30
se corresponde a las 2:00-2:30 h, hora del Pacífico. El cambio en la ventana de mantenimiento surte efecto inmediatamente.
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[ [ "sat:08:20-sat:08:50" ] ]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30" aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'[ [ "tue:10:00-tue:10:30" ] ]
En el siguiente ejemplo se muestra cómo obtener un informe de los eventos generados por la actualización. El argumento --duration
representa el número de minutos para recuperar la información del evento. Este argumento es necesario porque, de forma predeterminada, describe-events
solo devuelve eventos de la última hora.
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{ "Events": [ { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "DB cluster created", "EventCategories": [ "creation" ], "Date": "2022-11-17T01:24:11.093000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Upgrade in progress: Performing online pre-upgrade checks.", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T22:57:08.450000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Upgrade in progress: Performing offline pre-upgrade checks.", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T22:57:59.519000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T23:00:22.318000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Upgrade in progress: Cloning volume.", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T23:01:45.428000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T23:02:25.141000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T23:06:23.036000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Upgrade in progress: Upgrading database objects.", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T23:06:48.208000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" }, { "SourceIdentifier": "mynewdbcluster", "SourceType": "db-cluster", "Message": "Database cluster major version has been upgraded", "EventCategories": [ "maintenance" ], "Date": "2022-11-18T23:10:28.999000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster" } ] }
Búsqueda de motivos de los errores de actualización
En el tutorial anterior, la actualización de Aurora MySQL versión 2 a la versión 3 se realizó correctamente. Pero si la actualización hubiera fallado, querría saber por qué.
Puede empezar por utilizar el comando describe-events
de la AWS CLI para ver los eventos del clúster de base de datos. En este ejemplo, se muestran los eventos de mydbcluster
de las últimas 10 horas.
aws rds describe-events \ --source-type db-cluster \ --source-identifier mydbcluster \ --duration 600
En este caso, se produjo un error en la comprobación previa de la actualización.
{ "Events": [ { "SourceIdentifier": "mydbcluster", "SourceType": "db-cluster", "Message": "Database cluster engine version upgrade started.", "EventCategories": [ "maintenance" ], "Date": "2024-04-11T13:23:22.846000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster" }, { "SourceIdentifier": "mydbcluster", "SourceType": "db-cluster", "Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting.", "EventCategories": [ "maintenance" ], "Date": "2024-04-11T13:23:24.373000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster" } ] }
Para diagnosticar la causa exacta del problema, examine los registros de la base de datos de la instancia de base de datos de escritor. Cuando se produce un fallo en una actualización a Aurora MySQL versión 3, la instancia de escritor contiene un archivo de registro con el nombre upgrade-prechecks.log
. En este ejemplo se muestra cómo detectar la presencia de ese registro y, luego, descargarlo en un archivo local para su análisis.
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \ --query '*[].[LogFileName]' --output text error/mysql-error-running.log error/mysql-error-running.log.2024-04-11.20 error/mysql-error-running.log.2024-04-11.21 error/mysql-error.log external/mysql-external.log upgrade-prechecks.log aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \ --log-file-name upgrade-prechecks.log \ --starting-token 0 \ --output text >upgrade_prechecks.log
El archivo upgrade-prechecks.log
está en formato JSON. Lo descargamos con la opción --output text
para evitar codificar la salida JSON dentro de otro contenedor JSON. Para las actualizaciones a la versión 3 de Aurora MySQL, este registro siempre incluye ciertos mensajes informativos y de advertencia. Solo incluye mensajes de error si no se puede actualizar. Si se actualiza correctamente, el archivo de registro ya no se produce.
Para resumir todos los errores y mostrar los campos de objeto y descripción asociados, puede ejecutar el comando grep -A 2 '"level": "Error"'
en el contenido del archivo upgrade-prechecks.log
. Al hacerlo, se muestra cada línea de error y las dos líneas posteriores. Estas contienen el nombre del objeto de base de datos correspondiente e instrucciones sobre cómo corregir el problema.
$
cat upgrade-prechecks.log | grep -A 2 '"level": "Error"' "level": "Error", "dbObject": "problematic_upgrade.dangling_fulltext_index", "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
En este ejemplo, puede ejecutar el siguiente comando de SQL en la tabla infractora para intentar solucionar el problema, o bien puede volver a crear la tabla sin el índice pendiente.
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
A continuación, vuelva a intentar la actualización.
Solución de problemas para la actualización Aurora MySQL en el lugar
Utilice las siguientes sugerencias para solucionar problemas con las actualizaciones in situ de Aurora MySQL. Estas sugerencias no se aplican a los clústeres de base de datos de Aurora Serverless.
Motivo por el que la actualización en el lugar se cancela o se ralentiza | Efecto | Solución para permitir que la actualización en el lugar se complete dentro de la ventana de mantenimiento |
---|---|---|
La réplica entre regiones de Aurora asociadas aún no cuenta con revisión | Aurora cancela la actualización. | Actualice la réplica entre regiones de Aurora e inténtelo de nuevo. |
El clúster tiene transacciones XA en el estado preparado | Aurora cancela la actualización. | Confirme o revierta todas las transacciones XA preparadas. |
El clúster está procesando cualquier declaración de lenguaje de definición de datos (DDL) | Aurora cancela la actualización. | Considere la posibilidad de esperar y realizar la actualización una vez finalizadas todas las instrucciones DDL. |
El clúster tiene cambios no confirmados para muchas filas | Esto puede llevar mucho tiempo. |
El proceso de actualización revierte los cambios no confirmados. El indicador para esta condición es el valor de Considere la posibilidad de realizar la actualización solo después de que todas las transacciones grandes se hayan confirmado o deshecho. |
El clúster tiene un gran número de registros de deshacer | Esto puede llevar mucho tiempo. |
Incluso si las transacciones no confirmadas no afectan a un gran número de filas, pueden implicar un gran volumen de datos. Por ejemplo, puede que esté insertando BLOBs grandes. Aurora no detecta ni genera automáticamente un evento para este tipo de actividad de transacción. El indicador de esta condición es la longitud de la lista de historial (HLL). El proceso de actualización revierte los cambios no confirmados. Puede comprobar el HLL en la salida del comando SQL
También puede monitorizar la métrica Considere la posibilidad de realizar la actualización solo después de que la HLL sea menor. |
El clúster está en el proceso de confirmar una transacción de registro binario grande | Esto puede llevar mucho tiempo. |
El proceso de actualización espera hasta que se apliquen los cambios en el registro binario. Más transacciones o instrucciones DDL podrían comenzar durante este período, lo que ralentiza aún más el proceso de actualización. Programe el proceso de actualización cuando el clúster no esté ocupado con la generación de cambios de reproducción de registros binarios. Aurora no detecta ni genera automáticamente un evento para esta condición. |
Inconsistencias en el esquema causadas por la eliminación o la corrupción de un archivo | Aurora cancela la actualización. |
Cambie el motor de almacenamiento predeterminado para las tablas temporales de MyISAM a InnoDB. Siga estos pasos:
|
Se ha eliminado el usuario maestro | Aurora cancela la actualización. |
importanteNo elimine el usuario maestro. Sin embargo, si por alguna razón elimina el usuario maestro, restáurelo mediante los siguientes comandos SQL:
|
Para obtener más información sobre la solución de problemas que provocan el error de las comprobaciones previas a la actualización, consulte los siguientes blogs:
Puede utilizar los siguientes pasos para realizar sus propias comprobaciones de algunas de las condiciones de la tabla anterior. De esta forma, puede programar la actualización en un momento en que sepa que la base de datos se encuentra en un estado en el que la actualización puede completarse correctamente y rápidamente.
-
Puede comprobar si hay transacciones XA abiertas ejecutando la instrucción
XA RECOVER
. A continuación, puede confirmar o revertir las transacciones XA antes de iniciar la actualización. -
Puede comprobar si hay instrucciones DDL ejecutando una instrucción
SHOW PROCESSLIST
y buscando las instruccionesCREATE
,DROP
,ALTER
,RENAME
yTRUNCATE
en la salida. Permita que todas las instrucciones DDL finalicen antes de iniciar la actualización. -
Puede comprobar el número total de filas no confirmadas consultando la tabla
INFORMATION_SCHEMA.INNODB_TRX
. La tabla contiene una fila para cada transacción. La columnaTRX_ROWS_MODIFIED
contiene el número de filas modificadas o insertadas por la transacción. -
Puede verificar la longitud de la lista de historial de InnoDB ejecutando la instrucción
SHOW ENGINE INNODB STATUS SQL
y buscando elHistory list length
en la salida. También puede comprobar el valor directamente ejecutando la siguiente consulta:SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
La longitud de la lista de historial corresponde a la cantidad de información de deshacer almacenada por la base de datos para implementar el control de concurrencia multiversión (MVCC).
Limpieza posterior a la actualización para Aurora MySQL versión 3
Una vez que haya terminado de actualizar cualquier clúster de Aurora MySQL versión 2 a Aurora MySQL versión 3, puede realizar estas otras acciones de limpieza:
-
Cree nuevas versiones compatibles con MySQL 8.0 de cualquier grupo de parámetros personalizados. Aplique los valores de parámetros personalizados necesarios a los nuevos grupos de parámetros.
-
Actualice las alarmas de CloudWatch, los scripts de configuración, etc. para utilizar los nuevos nombres para cualquier métrica cuyos nombres se hayan visto afectados por cambios de idioma inclusivos. Para ver una lista de estas métricas, consulte Cambios de idioma inclusivos para Aurora MySQL versión 3.
-
Actualice cualquier plantilla AWS CloudFormation para utilizar los nuevos nombres para cualquier parámetro de configuración cuyos nombres se hayan visto afectados por cambios de idioma inclusivos. Para obtener una lista completa de estos parámetros, consulte Cambios de idioma inclusivos para Aurora MySQL versión 3.
Índices espaciales
Después de actualizar a Aurora MySQL versión 3, verifique si necesita eliminar o volver a crear objetos e índices relacionados con los índices espaciales. Antes de MySQL 8.0, Aurora podía optimizar las consultas espaciales utilizando índices que no contenían un identificador de recursos espaciales (SRID). Aurora MySQL versión 3 solo utiliza índices espaciales que contienen SRID. Durante una actualización, Aurora elimina automáticamente cualquier índice espacial sin SRID e imprime mensajes de advertencia en el registro de la base de datos. Si observa estos mensajes de advertencia, cree nuevos índices espaciales con SRID después de la actualización. Para obtener más información sobre los cambios en las funciones espaciales y los tipos de datos de MySQL 8.0, consulte Cambios en MySQL 8.0