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.

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.

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.

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.

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:

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:

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:

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.

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:

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.

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.

El proceso de actualización consta de tres pasos:

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.

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

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

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.

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

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.

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:

En el ejemplo siguiente se actualiza el clúster de base de datos global a la versión 2.10.2 de Aurora MySQL.

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

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-immediately
An 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 text

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

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

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.

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:

Í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 en el Manual de referencia de MySQL.