Referencia de descripciones de comprobaciones previas de Aurora MySQL

Nivel de comprobación previa: error

Problemas notificados por el comando check table x for upgrade del esquema de mysql

Antes de iniciar la actualización a la versión 3 de Aurora MySQL, se ejecuta check table for upgrade en cada tabla del esquema de mysql de la instancia de la base de datos. El comando check table for upgrade examina las tablas para detectar posibles problemas que puedan surgir durante una actualización a una versión más reciente de MySQL. Ejecutar este comando antes de intentar una actualización puede ayudar a identificar y resolver cualquier incompatibilidad con antelación, lo que facilita el proceso de actualización propiamente dicho.

Este comando realiza varias comprobaciones en cada tabla, como, por ejemplo:

Para obtener más información, consulte la sección CHECK TABLE statement en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "checkTableMysqlSchema",
  "title": "Issues reported by 'check table x for upgrade' command for mysql schema.",
  "status": "OK",
  "detectedProblems": []
}

El resultado de esta comprobación previa depende del error detectado y de cuándo se produzca, ya que check table for upgrade realiza varias comprobaciones.

Si detecta algún error con esta comprobación previa, abra un caso con AWS Support para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.

Nivel de comprobación previa: error

Referencias circulares a directorios en las rutas de los archivos de datos de los espacios de tablas

A partir de la versión 8.0.17 de MySQL, la cláusula CREATE TABLESPACE ... ADD DATAFILE ya no permite referencias circulares a directorios. Para evitar problemas de actualización, elimine cualquier referencia circular a directorios de las rutas de los archivos de datos de los espacios de tablas antes de actualizar a la versión 3 de Aurora MySQL.

Ejemplo de salida:

{
  "id": "circularDirectory",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "ts2",
        "description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'",
        "dbObjectType": "Tablespace"
      }
  ]
}

Si recibe este error, vuelva a crear las tablas con un espacio de tabla file-per-table. Utilice las rutas de archivos predeterminadas para todas las definiciones de tablas y espacios de tablas.

Una vez que los haya creado de nuevo, se aprueba la comprobación previa, lo que permite continuar con la actualización.

{
  "id": "circularDirectoryCheck",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Columnas que no pueden tener valores predeterminados

En las versiones anteriores a MySQL 8.0.13, las columnas BLOB, TEXT, GEOMETRY y JSON no pueden tener valores predeterminados. Elimine las cláusulas predeterminadas en estas columnas antes de actualizar a la versión 3 de Aurora MySQL. Para obtener más información sobre los cambios en la gestión predeterminada de estos tipos de datos, consulte Data type default values en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "description": "Error: The following columns are defined as either BLOB, TEXT, GEOMETRY or JSON and have a default value set. These data types cannot have default values in MySQL versions prior to 8.0.13, while starting with 8.0.13, the default value must be specified as an expression. In order to fix this issue, please use the ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT statement.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test_blob_default.geo_col",
        "description": "geometry"
      }
  ]
},

La comprobación previa devuelve un error porque la columna geo_col de la tabla test.test_blob_default utiliza un tipo de datos BLOB, TEXT, GEOMETRY o JSON con un valor predeterminado especificado.

Si observamos la definición de la tabla, podemos ver que la columna geo_col se ha definido como geo_col geometry NOT NULL default ''.

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Es necesario eliminar esta cláusula predeterminada para permitir que se apruebe la comprobación previa.

mysql> ALTER TABLE test_blob_default modify COLUMN geo_col geometry NOT NULL;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

La comprobación previa se aprueba y puede volver a intentar la actualización.

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Uso de palabras clave obsoletas en la definición

MySQL 8.0 ha eliminado la caché de consultas. Como resultado, se ha eliminado parte de la sintaxis de SQL específica de la caché de consultas. Si alguno de los objetos de la base de datos incluye las palabras clave QUERY CACHE, SQL_CACHE o SQL_NO_CACHE, se devolverá un error de comprobación previa. Para resolver este problema, vuelva a crear estos objetos. Para ello, elimine las palabras clave mencionadas.

Ejemplo de salida:

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.",
  "detectedProblems": [
      {
"level": "Error",
"dbObject": "test.no_query_cache_check",
"description": "PROCEDURE uses depreciated words in definition"
      }
  ]
}

La comprobación previa indica que el procedimiento almacenado de test.no_query_cache_check utiliza una de las palabras clave eliminadas. Al observar la definición del procedimiento, podemos ver que utiliza SQL_NO_CACHE.

mysql> show create procedure test.no_query_cache_check\G
*************************** 1. row ***************************
           Procedure: no_query_cache_check
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`()
BEGIN
    SELECT SQL_NO_CACHE k from sbtest1 where id > 10 and id < 20 group by k asc;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Elimine la palabra clave.

mysql> drop procedure test.no_query_cache_check;
Query OK, 0 rows affected (0.01 sec)

mysql> delimiter //

mysql> CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`() BEGIN     SELECT k from sbtest1 where id > 10 and id < 20 group by k asc; END//
Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;

Tras eliminar la palabra clave, la comprobación previa se completa correctamente.

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Tablas reconocidas por InnoDB que pertenecen a otro motor

Al igual que en schemaInconsistencyCheck, esta comprobación previa verifica que los metadatos de la tabla de MySQL son coherentes antes de continuar con la actualización.

Si detecta algún error con esta comprobación previa, abra un caso con AWS Support para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.

Ejemplo de salida:

{
  "id": "engineMixupCheck",
  "title": "Tables recognized by InnoDB that belong to a different engine",
  "status": "OK",
  "description": "Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.general_log_backup",
        "description": "recognized by the InnoDB engine but belongs to CSV"
      }
  ]
}

Nivel de comprobación previa: error

Definiciones de las columnas ENUM y SET que incluyen elementos que tienen más de 255 caracteres

Las tablas y los procedimientos almacenados no deben tener elementos de columna ENUM o SET que superen los 255 caracteres o 1020 bytes. En las versiones anteriores a MySQL 8.0, la longitud máxima combinada era de 64 K, pero la versión 8.0 limita los elementos individuales a 255 caracteres o 1020 bytes (en el caso de admitir caracteres multibyte). Si se produce un error en la comprobación previa para enumSetElementLengthCheck, modifique los elementos que superen estos nuevos límites antes de volver a intentar la actualización.

Ejemplo de salida:

{
  "id": "enumSetElementLengthCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "description": "Error: The following columns are defined as either ENUM or SET and contain at least one element longer that 255 characters. They need to be altered so that all elements fit into the 255 characters limit.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.large_set.s",
        "description": "SET contains element longer than 255 characters"
      }
  ]
},

La comprobación previa indica un error porque la columna s de la tabla test.large_set incluye un elemento SET de más de 255 caracteres.

Tras reducir el tamaño de SET de esta columna, se aprueba la comprobación previa, lo que permite continuar con la actualización.

{
  "id": "enumSetElementLenghtCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Nombres de restricción de clave externa que superen los 64 caracteres

En MySQL, la longitud de los identificadores está limitada a 64 caracteres, tal y como se describe en la documentación de MySQL. Debido a problemas detectados en los que la longitud de las claves externas podía ser igual o superior a este valor, lo que provocaba errores en la actualización, se ha implementado esta comprobación previa. Si detecta errores con esta comprobación previa, debe modificar la restricción o cambiarle el nombre para que tenga menos de 64 caracteres antes de volver a intentar la actualización.

Ejemplo de salida:

{
  "id": "foreignKeyLength",
  "title": "Foreign key constraint names longer than 64 characters",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Todos los nombres de desencadenadores de una base de datos deben ser únicos.

Debido a los cambios en la implementación del diccionario de datos, MySQL 8.0 no admite desencadenadores que distingan entre mayúsculas y minúsculas en una base de datos. Esta comprobación previa valida que el clúster de base de datos no tenga una o varias bases de datos que incluyan desencadenadores duplicados. Para obtener más información, consulte la sección Identifier case sensitivity en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "description": "Error: You have one or more database containing duplicate triggers. Mysql 8.0 does not support case sensitive triggers within a database https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html. To upgrade to MySQL 8.0, drop the triggers with case-insensitive duplicate names and recreate with distinct names.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_product"
      },
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_PRODUCT"
      }
  ]
}

La comprobación previa indica que hay un error en el clúster de base de datos, ya que tiene dos desencadenadores con el mismo nombre, pero se diferencian en el uso de mayúsculas y minúsculas: test.before_insert_product y test.before_insert_PRODUCT.

Antes de realizar la actualización, cambie el nombre de los desencadenadores o elimínelos y vuelva a crearlos con un nombre nuevo.

Tras cambiarle el nombre de test.before_insert_PRODUCT a test.before_insert_product_2, la comprobación previa se realiza correctamente.

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

La columna de definidor de mysql.event no puede ser nula ni estar vacía.

El atributo DEFINER especifica la cuenta de MySQL que posee una definición de objeto almacenado, como, por ejemplo, un desencadenador, un procedimiento almacenado o un evento. Este atributo es particularmente útil en situaciones en las que se desea controlar el contexto de seguridad en el que se ejecuta el objeto almacenado. Al crear un objeto almacenado, si no se especifica un atributo DEFINER, el valor predeterminado será el usuario que ha creado el objeto.

Al actualizar a MySQL 8.0, no puede tener ningún objeto almacenado que tenga un definidor null o que esté vacío en el diccionario de datos de MySQL. Si tiene esos objetos almacenados, se generará un error de comprobación previa. Debe solucionarlo antes de continuar con la actualización.

Ejemplo de error:

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "description": "Error: Set definer column in mysql.event to a valid non-null definer.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.get_version",
        "description": "Set definer for event get_version in Schema test"
      }
  ]
}

La comprobación previa devuelve un error para el evento test.get_version, ya que tiene un definidor null.

Para resolver este problema, puede comprobar la definición del evento. Como puede ver, el definidor es null o que esté vacío.

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+---------+
| db   | name        | definer |
+------+-------------+---------+
| test | get_version |         |
+------+-------------+---------+
1 row in set (0.00 sec)

Elimine o vuelva a crear el evento con un definidor válido.

mysql> drop event test.get_version;
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;
mysql> delimiter $$
mysql> CREATE EVENT get_version
    ->     ON SCHEDULE
    ->       EVERY 1 DAY
    ->     DO
    ->      ///DO SOMETHING //
    -> $$
Query OK, 0 rows affected (0.01 sec)

mysql> DELIMITER ;

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+------------+
| db   | name        | definer    |
+------+-------------+------------+
| test | get_version | reinvent@% |
+------+-------------+------------+
1 row in set (0.00 sec)

Ahora se aprueba la comprobación previa.

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "detectedProblems": []},

Nivel de comprobación previa: error

Discrepancia en la definición de columna entre el diccionario de datos de InnoDB y la definición real de la tabla

Al igual que en schemaInconsistencyCheck, esta comprobación previa verifica que los metadatos de la tabla de MySQL son coherentes antes de continuar con la actualización. En este caso, la comprobación previa verifica que las definiciones de columna coincidan entre el diccionario de datos de InnoDB y la definición de tabla de MySQL. Si se detecta una discrepancia, no se continuará con la actualización.

Si detecta algún error con esta comprobación previa, abra un caso con AWS Support para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.

Ejemplo de salida:

{
  "id": "getMismatchedMetadata",
  "title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
  "status": "OK",
  "description": "Error: Your database has mismatched metadata. The upgrade to mysql 8.0 will not succeed until this is fixed.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.mismatchTable",
        "description": "Table `test/mismatchTable` column names mismatch with InnoDb dictionary column names: iD <> id"
      }
  ]
}

La comprobación previa indica que hay una discrepancia en los metadatos de la columna id de la tabla test.mismatchTable. En concreto, los metadatos de MySQL tienen el nombre de la columna como iD, mientras que InnoDB lo tiene como id.

Nivel de comprobación previa: error

La columna de definidor de information_schema.triggers no puede ser null ni estar vacía.

La comprobación previa valida que la base de datos no tenga desencadenadores definidos con definidores null o vacíos. Para obtener más información sobre los requisitos del definidor para los objetos almacenados, consulte getEventsWithNullDefiner.

Ejemplo de salida:

{
  "id": "getTriggersWithNullDefiner",
  "title": "The definer column for information_schema.triggers cannot be null or blank.",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.example_trigger",
        "description": "Set definer for trigger example_trigger in Schema test"
      }
  ]
}

La comprobación previa devuelve un error porque el desencadenador example_trigger del esquema test tiene un definidor null. Para solucionar este problema, corrija el definidor volviendo a crear el desencadenador con un usuario válido o elimínelo. Para obtener más información, consulte el ejemplo en getEventsWithNullDefiner.

Nivel de comprobación previa: error

Todos los nombres de bases de datos y tablas deben estar en minúscula cuando el parámetro lower_case_table_names esté establecido en 1.

En las versiones anteriores a MySQL 8.0, los nombres de bases de datos, los nombres de tablas y otros objetos correspondían a los archivos del directorio de datos, como, por ejemplo, los metadatos basados en archivos (.frm). La variable de sistema lower_case_table_names permite a los usuarios controlar la forma en que el servidor distingue entre mayúsculas y minúsculas en los identificadores de los objetos de la base de datos y el almacenamiento de dichos objetos de metadatos. Este parámetro se puede cambiar en un servidor ya inicializado tras un reinicio.

Sin embargo, en MySQL 8.0, aunque este parámetro sigue controlando la forma en que el servidor distingue entre mayúsculas y minúsculas en los identificadores, no se puede cambiar una vez inicializado el diccionario de datos. Al actualizar o crear una base de datos MySQL 8.0, el valor que se establezca para lower_case_table_names la primera vez que se inicie el diccionario de datos en MySQL será el que se utilice durante toda la vida útil de dicha base de datos. Esta restricción se ha establecido como parte de la implementación del Atomic Data Dictionary, en la que los objetos de la base de datos se migran de los metadatos basados en archivos a las tablas internas de InnoDB del esquema mysql.

Para obtener más información, consulte la sección Data dictionary changes en la documentación de MySQL.

Para evitar problemas a la hora de actualizar los metadatos basados en archivos al nuevo Atomic Data Dictionary, esta comprobación previa valida que, si está establecida la variable lower_case_table_names = 1, todas las tablas se almacenen en el disco en minúsculas. En caso contrario, aparecerá un error de comprobación previa, y tendrá que corregir los metadatos antes de continuar con la actualización.

Ejemplo de salida:

{
  "id": "getValueOfVariablelower_case_table_names",
  "title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.",
  "status": "OK",
  "description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.TEST",
        "description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1"
      }
  ]
}

Se devuelve un error porque la tabla test.TEST incluye letras mayúsculas, pero la variable lower_case_table_names está establecida en 1.

Para resolver este problema, puede cambiar el nombre de la tabla a minúsculas o modificar el parámetro lower_case_table_names del clúster de base de datos antes de iniciar la actualización.

Nivel de comprobación previa: error

Uso de la sintaxis de GROUP BY ASC/DESC eliminada

A partir de la versión 8.0.13 de MySQL, se ha eliminado la sintaxis obsoleta de ASC o DESC para las cláusulas GROUP BY. Las consultas que se basan en la clasificación GROUP BY ahora pueden producir resultados diferentes. Para obtener un orden de clasificación específico, utilice una cláusula ORDER BY. Si existe algún objeto en la base de datos que utilice esta sintaxis, debe volver a crearlo mediante una cláusula ORDER BY antes de volver a intentar la actualización. Para obtener más información, consulte la sección SQL changes en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "groupbyAscSyntaxCheck",
  "title": "Usage of removed GROUP BY ASC/DESC syntax",
  "status": "OK",
  "description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
  "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.groupbyasc",
        "description": "PROCEDURE uses removed GROUP BY ASC syntax",
        "dbObjectType": "Routine"
      }
  ]
}

Nivel de comprobación previa: error

Comprobación de si la sintaxis de .<table> utilizada en las rutinas está obsoleta.

En MySQL 8.0, las rutinas ya no pueden incluir la sintaxis de identificador obsoleta (\".<table>\"). Si alguna de las rutinas o desencadenadores almacenados incluye dichos identificadores, se producirá un error en la actualización. Por ejemplo, ya no se permite la siguiente referencia de .dot_table:

mysql> show create procedure incorrect_procedure\G
*************************** 1. row ***************************
           Procedure: incorrect_procedure
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `incorrect_procedure`()
BEGIN delete FROM .dot_table; select * from .dot_table where 1=1; END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Tras volver a crear las rutinas y los desencadenadores para utilizar la sintaxis de identificador correcta y la secuencia de escape, se aprueba la comprobación previa y se puede continuar con la actualización. Para obtener más información sobre los identificadores, consulte la sección Schema object names en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "mysqlEmptyDotTableSyntaxCheck",
  "title": "Check for deprecated '.<table>' syntax used in routines.",
  "status": "OK",
  "description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".<table>\"), and should be corrected before upgrade:\n",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.incorrect_procedure",
        "description": " routine body contains deprecated identifiers."
      }
  ]
}

La comprobación previa devuelve un error para la rutina incorrect_procedure de la base de datos test, ya que incluye una sintaxis obsoleta.

Tras corregir la rutina, la comprobación previa se realiza correctamente y puede volver a intentar la actualización.

Nivel de comprobación previa: error

Comprobación de si los índices son demasiado grandes para funcionar en las versiones de MySQL posteriores a 5.7

En el caso de formatos de fila compactos o redundantes, no debería ser posible crear un índice con un prefijo superior a 767 bytes. Sin embargo, antes de la versión 5.7.35 de MySQL esto era posible. Para obtener más información, consulte las notas de la versión de MySQL 5.7.35.

No se podrá acceder a los índices afectados por este error tras la actualización a MySQL 8.0. Esta comprobación previa identifica los índices problemáticos que deben volver a crearse antes de continuar con la actualización.

 {
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "description": "Error: The following indexes ware made too large for their format in an older version of MySQL (older than 5.7.34). Normally those indexes within tables with compact or redundant row formats shouldn't be larger than 767 bytes. To fix this problem those indexes should be dropped before upgrading or those tables will be inaccessible.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_large_idx",
        "description": "IDX_2"
      }
  ]
}

La comprobación previa devuelve un error porque la tabla test.table_with_large_idx incluye un índice en una tabla que utiliza un formato de fila compacto o redundante de más de 767 bytes. Ya no se podrá acceder a estar tablas después de actualizar a MySQL 8.0. Antes de continuar con la actualización, realice una de las siguientes acciones:

En este caso, volvemos a crear la tabla para resolver el error de comprobación previa. Antes de volver a crear la tabla, asegúrese de que innodb_file_format esté establecido en Barracuda y que innodb_default_row_format esté establecido en dynamic. Estos son los valores predeterminados en MySQL 5.7. Para obtener más información, consulte las secciones InnoDB row formats y InnoDB file-format management en la documentación de MySQL.

mysql > select @@innodb_file_format,@@innodb_default_row_format;
+----------------------+-----------------------------+
| @@innodb_file_format | @@innodb_default_row_format |
+----------------------+-----------------------------+
| Barracuda            | dynamic                     |
+----------------------+-----------------------------+
1 row in set (0.00 sec)

mysql> optimize table table_with_large_idx;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table                     | Op       | Msg_type | Msg_text                                                          |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| test.table_with_large_idx | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.table_with_large_idx | optimize | status   | OK                                                                |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.02 sec)

# Verify FILE_FORMAT and ROW_FORMAT
mysql>  select * from information_schema.innodb_sys_tables where name like 'test/table_with_large_idx';
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME                      | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
|       43 | test/table_with_large_idx |   33 |      4 |    26 | Barracuda   | Dynamic    |             0 | Single     |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
1 row in set (0.00 sec)

Tras volver a crear la tabla, se aprueba la comprobación previa y se puede continuar con la actualización.

{
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Compruebe si los nombres de tablas y esquemas utilizados en MySQL 5.7 no son válidos

Al migrar al nuevo diccionario de datos de MySQL 8.0, la instancia de base de datos no puede incluir esquemas ni tablas con el prefijo #mysql50#. Si existe alguno de estos objetos, se produce un error en la actualización. Para resolver este problema, ejecute mysqlcheck con los esquemas y tablas devueltos.

Ejemplo de salida:

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "description": "The following tables and/or schemas have invalid names. In order to fix them use the mysqlcheck utility as follows:\n\n  $ mysqlcheck --check-upgrade --all-databases\n  $ mysqlcheck --fix-db-names --fix-table-names --all-databases\n\nOR via mysql client, for eg:\n\n  ALTER DATABASE `#mysql50#lost+found` UPGRADE DATA DIRECTORY NAME;",
  "documentationLink": "https://dev.mysql.com/doc/refman/5.7/en/identifier-mapping.html https://dev.mysql.com/doc/refman/5.7/en/alter-database.html https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "#mysql50#fix_db_names",
        "description": "Schema name"
      }
  ]
}

La comprobación previa indica que el esquema #mysql50#fix_db_names tiene un nombre no válido.

Tras corregir el nombre del esquema, se aprueba la comprobación previa, lo que permite continuar con la actualización.

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Comprobación de si hay rutinas huérfanas en la versión 5.7

Al migrar al nuevo diccionario de datos de MySQL 8.0, si hay algún procedimiento almacenado en la base de datos donde el esquema ya no existe, se producirá un error en la actualización. Esta comprobación previa comprueba que todos los esquemas a los que se hace referencia en los procedimientos almacenados de la instancia de base de datos siguen existiendo. Para poder continuar con la actualización, elimine estos procedimientos almacenados.

Ejemplo de salida:

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "description": "Error: The following routines have been orphaned. Schemas that they are referencing no longer exists.\nThey have to be cleaned up or the upgrade will fail.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "dropped_db.get_version",
        "description": "is orphaned"
      }
  ]
},

La comprobación previa indica que el procedimiento almacenado get_version de la base de datos dropped_db está huérfano.

Para eliminar este procedimiento, puede volver a crear el esquema que falta.

mysql> create database dropped_db;
Query OK, 1 row affected (0.01 sec)

Una vez que se haya vuelto a crear el esquema, puede eliminar el procedimiento para permitir que continúe la actualización.

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Los nombres de las tablas del esquema de mysql entran en conflicto con las nuevas tablas de MySQL 8.0

El nuevo Atomic Data Dictionary introducido en MySQL 8.0 almacena todos los metadatos en un conjunto de tablas internas de InnoDB en el esquema de mysql. Durante la actualización, las nuevas tablas del diccionario de datos interno se crean en el esquema de mysql. Para evitar colisiones de nombres, que podrían provocar errores en la actualización, la comprobación previa examina todos los nombres de las tablas del esquema de mysql para garantizar que ninguno de los nuevos nombres de tabla esté ya en uso. Si lo están, aparece un error y no se permite continuar con la actualización.

Ejemplo de salida:

{
  "id": "mysqlSchema",
  "title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.",
  "status": "OK",
  "description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.tablespaces",
        "description": "Table name used in mysql schema.",
        "dbObjectType": "Table"
      }
  ]
}

Se devuelve un error porque hay una tabla con el nombre tablespaces en el esquema de mysql. Este es uno de los nuevos nombres de tablas de diccionarios de datos internos de MySQL 8.0. Debe cambiar el nombre de dichas tablas o eliminarlas antes de realizar la actualización mediante el comando RENAME TABLE.

Nivel de comprobación previa: error

Tablas particionadas que utilizan motores con particionamiento no nativo

Según la documentación de MySQL 8.0, actualmente hay dos motores de almacenamiento que ofrecen soporte de particionamiento nativo: InnoDB y NDB. De estos, solo InnoDB se admite en la versión 3 de Aurora MySQL, compatible con MySQL 8.0. Se producirá un error al intentar crear tablas particionadas en MySQL 8.0 con cualquier otro motor de almacenamiento. Esta comprobación previa busca tablas en el clúster de la base de datos que utilicen particiones no nativas. Si se devuelve alguna, debe eliminar la partición o convertir el motor de almacenamiento a InnoDB.

Ejemplo de salida:

{
  "id": "nonNativePartitioning",
  "title": "Partitioned tables using engines with non native partitioning",
  "status": "OK",
  "description": "Error: In the latest MySQL storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in the latest MySQL. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partMyisamTable",
         "description": "MyISAM engine does not support native partitioning",
         "dbObjectType": "Table"
      }
  ]
}

En este caso, una tabla MyISAM utiliza la partición, lo que requiere una acción antes de que la actualización pueda continuar.

Nivel de comprobación previa: error

Uso de un tipo temporal antiguo

Los “Tipos temporales antiguos” hacen referencia a las columnas de tipo temporal (como TIMESTAMP y DATETIME) creadas en las versiones 5.5 y anteriores de MySQL. En MySQL 8.0, se ha eliminado la compatibilidad con estos tipos de datos temporales antiguos, lo que significa que las actualizaciones locales de MySQL 5.7 a 8.0 no son posibles si la base de datos los incluye. Para solucionar este problema, debe volver a crear todas las tablas que incluyan estos tipos de fechas temporales antiguos antes de continuar con la actualización.

Para obtener más información sobre la obsolescencia de los tipos de datos temporales antiguos en MySQL 5.7, consulte este blog. Para obtener más información sobre la eliminación de los tipos de datos temporales antiguos en MySQL 8.0, consulte este blog.

Ejemplo de salida:

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "description": "Error: Following table columns use a deprecated and no longer supported temporal disk storage format. They must be converted to the new format before upgrading. It can by done by rebuilding the table using 'ALTER TABLE <table_name> FORCE' command",
  "documentationLink": "https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.55_temporal_table.timestamp_column",
        "description": "timestamp /* 5.5 binary format */",
        "dbObjectType": "Column"
      }
  ]
},

Se informa de un error en la columna timestamp_column de la tabla test.55_temporal_table, ya que utiliza un antiguo formato de almacenamiento en disco temporal que ya no se admite.

Para resolver este problema y permitir que se continúe con la actualización, vuelva a crear la tabla para convertir el antiguo formato de almacenamiento en disco temporal al nuevo introducido en MySQL 5.6. Para obtener más información y conocer los requisitos previos antes de hacerlo, consulte la sección Converting between 3-byte and 4-byte Unicode character sets en la documentación de MySQL.

Al ejecutar el siguiente comando para volver a crear las tablas mencionadas en esta comprobación previa, se convierten los tipos temporales antiguos al formato más nuevo con una precisión de fracción de segundo.

ALTER TABLE ... ENGINE=InnoDB;

Para obtener más información sobre cómo volver a crear tablas, consulte ALTER TABLE statement en la documentación de MySQL.

Tras volver a crear la tabla en cuestión y reiniciar la actualización, se aprueba la comprobación de compatibilidad, lo que permite continuar con la actualización.

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Uso de tablas particionadas en espacios de tablas compartidos

A partir de la versión 8.0.13 de MySQL, se elimina la compatibilidad con la colocación de particiones de tablas en espacios de tabla compartidos. Antes de realizar la actualización, mueva dichas tablas de los espacios de tabla compartidos a los espacios de tabla file-per-table.

Ejemplo de salida:

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "description": "Error: The following tables have partitions in shared tablespaces. They need to be moved to file-per-table tablespace before upgrading. You can do this by running query like 'ALTER TABLE table_name REORGANIZE PARTITION X INTO (PARTITION X VALUES LESS THAN (30) TABLESPACE=innodb_file_per_table);'",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partInnoDBTable",
        "description": "Partition p1 is in shared tablespace innodb",
        "dbObjectType": "Table"
      }
  ]
}

La comprobación previa no se realiza correctamente porque la partición p1 de la tabla test.partInnoDBTable se encuentra en el espacio de tablas del sistema.

Para resolver este problema, vuelva a crear la tabla test.partInnodbTable y coloque la partición problemática p1 en un espacio de tablas file-per-table.

mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1
    ->   INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table);
Query OK, 0 rows affected, 1 warning (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

Después de hacerlo, se aprueba la comprobación previa.

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Uso de funciones que se eliminaron de la última versión de MySQL

En MySQL 8.0, se han eliminado varias funciones integradas. Esta comprobación previa examina la base de datos en busca de objetos que puedan utilizar estas funciones. En el caso de detectarse, se devuelve un error. Debe resolver los problemas antes de volver a intentar la actualización.

La mayoría de las funciones eliminadas son funciones espaciales, que se han sustituido por funciones ST_* equivalentes. En estos casos, modifique los objetos de la base de datos para utilizar la nueva nomenclatura del procedimiento. Para obtener más información, consulte la sección sobre características eliminadas en MySQL 8.0, en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "description": "Error: The following DB objects use functions that were removed in the latest MySQL version. Please make sure to update them to use supported alternatives before upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.GetLocationsInPolygon",
        "description": "PROCEDURE uses removed function POLYGONFROMTEXT (consider using ST_POLYGONFROMTEXT instead)",
        "dbObjectType": "Routine"
      },
      {
        "level": "Error",
        "dbObject": "test.InsertLocation",
        "description": "PROCEDURE uses removed function POINTFROMTEXT (consider using ST_POINTFROMTEXT instead)",
        "dbObjectType": "Routine"
      }
  ]
},

La comprobación previa indica que el procedimiento almacenado test.GetLocationsInPolygon utiliza dos funciones eliminadas: POLYGONFROMTEXT y POINTFROMTEXT. También sugiere que utilice las nuevas funciones ST_POLYGONFROMTEXT y ST_POINTFROMTEXT como sustitutas. Tras volver a crear el procedimiento con las sugerencias, la comprobación previa se completará correctamente.

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Comprobación de sintaxis de MySQL para objetos de tipo rutinario

MySQL 8.0 ha introducido palabras clave reservadas que no estaban reservadas anteriormente. El comprobador previo de actualización evalúa el uso de palabras clave reservadas en los nombres de los objetos de la base de datos, así como en sus definiciones y cuerpo. Si detecta que se utilizan palabras clave reservadas en los objetos de la base de datos, como procedimientos almacenados, funciones, eventos y desencadenadores, la actualización no se realizará correctamente y se publicará un error en el archivo upgrade-prechecks.log. Para resolver el problema, debe actualizar estas definiciones de objetos y escribir dichas referencias entre comillas simples (') antes de realizar la actualización. Para obtener más información sobre cómo aplicar caracteres de escape a las palabras reservadas en MySQL, consulte la sección String literals en la documentación de MySQL.

También puede cambiar el nombre por uno diferente, lo que puede requerir cambios en la aplicación.

Ejemplo de salida:

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "description": "The following objects did not pass a syntax check with the latest MySQL grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
         "level": "Error",
         "dbObject": "test.select_res_word",
         "description": "at line 2,18: unexpected token 'except'",
         "dbObjectType": "Routine"
      }
  ]
}

Para resolver este problema, compruebe la definición de rutina.

SHOW CREATE PROCEDURE test.select_res_word\G

*************************** 1. row ***************************
           Procedure: select_res_word
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    Create Procedure: CREATE PROCEDURE 'select_res_word'()
BEGIN
    SELECT * FROM except;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

El procedimiento utiliza una tabla denominada except, que es una nueva palabra clave en MySQL 8.0. Aplique caracteres de escape al literal de cadena para volver a crear el procedimiento.

> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)

> DELIMITER $$
 > CREATE PROCEDURE select_res_word()
    -> BEGIN
    ->     SELECT * FROM 'except';
    -> END$$
Query OK, 0 rows affected (0.00 sec)

 > DELIMITER ;

Ahora se aprueba la comprobación previa.

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Incoherencias en el esquema provocadas por la eliminación o la corrupción de un archivo

Tal y como se ha descrito anteriormente, MySQL 8.0 ha introducido el Atomic Data Dictionary, que almacena todos los metadatos en un conjunto de tablas internas de InnoDB en el esquema de mysql. Esta nueva arquitectura proporciona una forma transaccional y compatible con ACID para administrar los metadatos de las bases de datos, lo que resuelve el problema de DDL atómico que planteaba el antiguo enfoque basado en archivos. En las versiones anteriores a MySQL 8.0, era posible que los objetos del esquema quedaran huérfanos si una operación de DDL se interrumpía de forma inesperada. La migración de los metadatos basados en archivos a las nuevas tablas del Atomic Data Dictionary durante la actualización garantiza que no haya objetos de esquema huérfanos en la instancia de la base de datos. Si se encuentra algún objeto huérfano, se producirá un error en la actualización.

Con el fin de ayudar a detectar estos objetos huérfanos antes de iniciar la actualización, se realiza una comprobación previa schemaInconsistencyCheck para garantizar que todos los objetos de metadatos del diccionario de datos estén sincronizados. Si se detecta algún objeto de metadatos huérfano, no se continuará con la actualización. Para continuar con la actualización, elimine estos objetos de metadatos huérfanos.

Si detecta algún error con esta comprobación previa, abra un caso con AWS Support para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.

Ejemplo de salida:

{
  "id": "schemaInconsistencyCheck",
  "title": "Schema inconsistencies resulting from file removal or corruption",
  "status": "OK",
  "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.schemaInconsistencyCheck_failure",
        "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
      }
  ]
}

La comprobación previa indica que la tabla test.schemaInconsistencyCheck_failure tiene metadatos incoherentes. En este caso, la tabla existe en los metadatos del motor de almacenamiento de InnoDB (information_schema.INNODB_SYS_TABLES), pero no en los metadatos de MySQL (information_schema.TABLES).

Nivel de comprobación previa: error

Comprobación de si hay artefactos relacionados con la característica de recuperación de Aurora DDL

Como parte de la implementación de recuperación del lenguaje de definición de datos (DDL) en Aurora MySQL, los metadatos de las instrucciones de DDL en curso se mantienen en las tablas ddl_log_md_table y ddl_log_table del esquema de mysql. La implementación de recuperación de DDL de Aurora no es compatible con la versión 3 y versiones posteriores, ya que la funcionalidad forma parte de la nueva implementación de Atomic Data Dictionary en MySQL 8.0. Si se está ejecutando alguna instrucción de DDL durante las comprobaciones de compatibilidad, es posible que se produzca un error en esta comprobación previa. Le recomendamos que intente actualizar cuando no haya en ejecución ninguna instrucción de DDL.

Si se produce un error en esta comprobación previa sin que se estén ejecutando instrucciones de DDL, abra un caso con AWS Support para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.

Si se está ejecutando alguna instrucción de DDL, el resultado de la comprobación previa mostrará el siguiente mensaje:

“There are DDL statements in process. Please allow DDL statements to finish before upgrading.”

Ejemplo de salida:

{
  "id": "auroraCheckDDLRecovery",
  "title": "Check for artifacts related to Aurora DDL recovery feature",
  "status": "OK",
  "description": "Aurora implementation of DDL recovery is not supported from 3.x onwards. This check verifies that the database do not have artifacts realted to the feature",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_md_table",
        "description": "Table mysql.ddl_log_md_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_table",
        "description": "Table mysql.ddl_log_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "information_schema.processlist",
        "description": "There are DDL statements in process. Please allow DDL statements to finish before upgrading."
      }
  ]
}

La comprobación previa ha devuelto un error debido a que una DDL en curso se estaba ejecutando simultáneamente con las comprobaciones de compatibilidad. Le recomendamos que intente de nuevo realizar la actualización sin que se esté ejecutando ninguna DDL.

Nivel de comprobación previa: error

Comprobación de la existencia de la tabla mysql.rds_upgrade_prechecks

Se trata de una comprobación previa exclusivamente interna llevada a cabo por el servicio de RDS. Los errores se gestionarán automáticamente en la actualización y pueden omitirse de forma segura.

Si detecta algún error con esta comprobación previa, abra un caso con AWS Support para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.

{
  "id": "auroraCheckRdsUpgradePrechecksTable",
  "title": "Check existence of mysql.rds_upgrade_prechecks table",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de si hay artefactos relacionados con la característica DDL rápido de Aurora

La optimización de DDL rápido se ha introducido en el modo lab en la versión 2 de Aurora MySQL con el fin de mejorar la eficiencia de algunas operaciones de DDL. En la versión 3 de Aurora MySQL, se ha eliminado el modo lab y la implementación de DDL rápido se ha sustituido por la característica de MySQL 8.0 denominada DDL instantáneo.

Antes de actualizar a la versión 3 de Aurora MySQL, deberá volverse a crear cualquier tabla que utilice DDL rápido en modo laboratorio. Para ello, es necesario ejecutar el comando OPTIMIZE TABLE o ALTER TABLE ... ENGINE=InnoDB para garantizar la compatibilidad con la versión 3 de Aurora MySQL.

Esta comprobación previa devuelve una lista de estas tablas. Una vez se han vuelto a crear las tablas devueltas, puede volver a intentar la actualización.

Ejemplo de salida:

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test",
        "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again."
      }
  ]
}

La comprobación previa indica que la tabla test.test tiene operaciones de DDL rápido pendientes.

Para poder continuar con la actualización, puede volver a crear la tabla y, a continuación, volver a intentar la actualización.

mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table     | Op       | Msg_type | Msg_text                                                          |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status   | OK                                                                |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)

Después de volver a crear la tabla, la comprobación previa se realiza correctamente.

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Tablas con referencia de índice FULLTEXT colgante

En las versiones anteriores a MySQL 5.6.26, era posible que, tras eliminar un índice de búsqueda de texto completo, las columnas ocultas FTS_DOC_ID y FTS_DOC_ID_INDEX quedaran huérfanas. Para obtener más información, consulte Bug #76012.

Si ha creado tablas en versiones anteriores de MySQL en las que esto haya ocurrido, puede provocar un error en las actualizaciones a la versión 3 de Aurora MySQL. Esta comprobación previa verifica que no existan índices de texto completo huérfanos o “colgantes” en el clúster de base de datos antes de actualizar a MySQL 8.0. Si se produce un error en esta comprobación previa, vuelva a crear todas las tablas que incluyan esos índices de texto completo colgantes.

Ejemplo de salida:

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_fts_index",
        "description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
      }
  ]
},

La comprobación previa indica que hay un error en la tabla test.table_with_fts_index porque incluye un índice de texto completo colgante. Para permitir que se continúe con la actualización, vuelva a crear la tabla para eliminar las tablas auxiliares del índice de texto completo. Utilice OPTIMIZE TABLE test.table_with_fts_index o ALTER TABLE test.table_with_fts_index, ENGINE=INNODB.

Después de volver a crear la tabla, se aprueba la comprobación previa.

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Comprobación de si hay incoherencias relacionadas con la ruta de archivo ibd

Esta comprobación previa se aplica únicamente a la versión 3.03.0 y anteriores de Aurora MySQL. Si detecta un error con esta comprobación previa, actualice a la versión 3.04 o versiones posteriores de Aurora MySQL.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación del índice de texto completo con el ID de espacio como cero

En MySQL, al añadir un índice de texto completo a una tabla de InnoDB, se crean varios espacios de tabla de índices auxiliares. Debido a un error en las versiones anteriores de MySQL, que se ha corregido en la versión 5.6.20, era posible que estas tablas de índices auxiliares se crearan en el espacio de tablas del sistema, en lugar de hacerlo en su propio espacio de tablas de InnoDB.

Si existe alguno de estos espacios de tablas auxiliares, se producirá un error en la actualización. Vuelva a crear los índices de texto completo mencionados en el error de comprobación previa y, a continuación, vuelva a intentar la actualización.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForFtsSpaceIdZero",
  "title": "Check for fulltext index with space id as zero",
  "status": "OK",
  "description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.fts_space_zero_check",
        "description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
      }
  ]
},

La comprobación previa indica que hay un error en la tabla test.fts_space_zero_check, ya que tiene tablas auxiliares de búsqueda de texto completo (FTS) en el espacio de tablas del sistema.

Después de eliminar y volver a crear los índices de FTS asociados a esta tabla, la comprobación previa se realizará correctamente.

{
 "id": "auroraUpgradeCheckForFtsSpaceIdZero",
 "title": "Check for fulltext index with space id as zero",
 "status": "OK",
 "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de si las transacciones de XA están preparadas

Mientras se ejecuta el proceso de actualización de la versión principal, es esencial que la instancia de base de datos de la versión 2 de Aurora MySQL se cierre por completo. Esto garantiza que todas las transacciones se confirmen o se reviertan y que InnoDB haya purgado todos los registros de deshacer. Como la reversión de las transacciones es necesaria, si la base de datos tiene alguna transacción de XA preparada, puede impedir que se cierre por completo. Por este motivo, si se detecta alguna transacción de XA preparada, no se podrá continuar con la actualización hasta que se tomen medidas para confirmarla o revertirla.

Para obtener más información sobre cómo detectar transacciones de XA preparadas con XA RECOVER, consulte la sección XA Transaction SQL Statements en la documentación de MySQL. Para obtener más información sobre los estados de las transacciones de XA, consulte la sección XA Transaction States en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
      }
  ]
}

Esta comprobación previa indica que hay un error porque hay transacciones preparadas que deben confirmarse o revertirse.

Tras iniciar sesión en la base de datos, puede consultar la tabla information_schema.innodb_trx y el resultado XA RECOVER para obtener más información.

mysql> select trx_started,
    trx_mysql_thread_id,
    trx_id,trx_state,
    trx_operation_state,
    trx_rows_modified,
    trx_rows_locked 
from 
    information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started         | trx_mysql_thread_id | trx_id  | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 |                   0 | 2849470 | RUNNING   | NULL                |                 1 |               0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)

mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        1 |            6 |            0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)

En este caso, revertimos la transacción preparada.

mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)

Una vez que se ha revertido la transacción de XA, la comprobación previa se realizará correctamente.

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de si la clase de instancia actual admite la actualización

Por el momento, no se puede ejecutar una actualización local desde la versión 2.12.0 o 2.12.1 de Aurora MySQL, donde la clase de instancia de base de datos de escritor sea db.r6i.32xlarge. En este caso, la comprobación previa devuelve un error. Para poder continuar con la actualización, puede cambiar la clase de la instancia de base de datos a db.r6i.24xlarge o a una inferior. También puede actualizar a la versión 2.12.2 de Aurora MySQL, o una versión posterior, donde db.r6i.32xlarge admite la actualización local a la versión 3 de Aurora MySQL.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForInstanceLimit",
  "title": "Checks if upgrade is supported on the current instance class",
  "status": "OK",
  "description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
      }
  ]
},

La comprobación previa devuelve un error porque la instancia de base de datos de escritor utiliza la clase de instancia db.r6i.32xlarge y se ejecuta en la versión 2.12.1 de Aurora MySQL.

Nivel de comprobación previa: error

Comprobación de si hay usuarios internos de la versión 8.0

Esta comprobación previa se aplica únicamente a la versión 3.03.0 y anteriores de Aurora MySQL. Si detecta un error con esta comprobación previa, actualice a la versión 3.04 o versiones posteriores de Aurora MySQL.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForInternalUsers",
  "title": "Check for 8.0 internal users.",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de si existe el usuario maestro de RDS

MySQL 8 ha añadido un nuevo modelo de privilegios con soporte de rol y privilegios dinámicos para hacer que la administración de privilegios sea más fácil y detallada. Como parte de este cambio, Aurora MySQL ha introducido el nuevo rds_superuser_role, que se otorga automáticamente al usuario maestro de la base de datos al actualizar de la versión 2 a la versión 3 de Aurora MySQL.

Para obtener más información sobre los roles y privilegios asignados al usuario maestro en Aurora MySQL, consulte Privilegios de la cuenta de usuario maestro. Para obtener más información sobre el modelo de privilegios basado en roles de la versión 3 de Aurora MySQL, consulte Modelo de privilegios basado en roles.

Esta comprobación previa verifica que el usuario maestro existe en la base de datos. Si el usuario maestro no existe, se producirá un error en la comprobación previa. Para poder continuar con la actualización, vuelva a crear el usuario maestro. Para ello, restablezca la contraseña del usuario maestro o cree manualmente el usuario. A continuación, vuelva a intentar la actualización. Para obtener más información sobre cómo restablecer la contraseña del usuario maestro, consulte Cambio de la contraseña del usuario maestro de la base de datos.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForMasterUser",
  "title": "Check if master user exists",
  "status": "OK",
  "description": "Throws error if master user has been dropped!",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
      }
  ]
}

Tras restablecer la contraseña del usuario maestro, se aprobará la comprobación previa y podrá volver a intentar la actualización.

En el siguiente ejemplo se utiliza la AWS CLI para restablecer la contraseña. Los cambios de contraseña se aplican inmediatamente.

aws rds modify-db-cluster \
    --db-cluster-identifier my-db-cluster \
    --master-user-password my-new-password

A continuación, la comprobación previa se realiza correctamente.

{
  "id": "auroraUpgradeCheckForMasterUser",
  title": "Check if master user exists",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de si hay columnas geométricas en los índices de prefijos

A partir de la versión 8.0.12 de MySQL, ya no se puede crear un índice con prefijo en una columna con el tipo de datos GEOMETRY. Para obtener más información, consulte WL#11808.

Si existe alguno de estos índices, se producirá un error en la actualización. Para resolver el problema, elimine los índices con prefijo de GEOMETRY en las tablas mencionadas en el error de la comprobación previa.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.geom_index_prefix",
        "description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
      }
  ]
}

La comprobación previa indica que hay un error porque la tabla test.geom_index_prefix incluye un índice con un prefijo en una columna GEOMETRY.

Tras eliminar este índice, la comprobación previa se realizará correctamente.

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de si hay incoherencias relacionadas con los caracteres especiales en los procedimientos almacenados

En las versiones anteriores a MySQL 8.0, los nombres de bases de datos, los nombres de tablas y otros objetos correspondían a los archivos del directorio de datos, como, por ejemplo, los metadatos basados en archivos. Como parte de la actualización a MySQL 8.0, todos los objetos de la base de datos se migran a las nuevas tablas del diccionario de datos interno que se almacenan en el esquema de mysql para admitir el Atomic Data Dictionary recientemente implementado. Como parte de la migración de los procedimientos almacenados, la definición y el cuerpo del procedimiento se validan a medida que se van incorporando al nuevo diccionario de datos.

En las versiones anteriores a MySQL 8, era posible, en algunos casos, crear rutinas almacenadas o insertar directamente en la tabla mysql.proc procedimientos que incluían caracteres especiales. Por ejemplo, se podía crear un procedimiento almacenado que incluyera un comentario con el carácter de espacio no divisible y no compatible \xa0. Si se detecta alguno de estos procedimientos, se producirá un error en la actualización.

Esta comprobación previa valida que los cuerpos y las definiciones de los procedimientos almacenados no incluyan dichos caracteres. Para poder continuar con la actualización, vuelva a crear estos procedimientos almacenados sin ningún carácter oculto ni especial.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "description": "Following procedure(s) has special characters inconsistency.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "information_schema.routines",
        "description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
      }
  ]
}

La comprobación previa indica que el clúster de base de datos incluye un procedimiento denominado get_version_proc en la base de datos de test que incluye caracteres especiales en el cuerpo del procedimiento.

Tras eliminar y volver a crear el procedimiento almacenado, la comprobación previa se realiza correctamente, lo que permite continuar con la actualización.

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "detectedProblems": []
},

Nivel de comprobación previa: error

Comprobación de si el tipo de objeto no coincide con el esquema sys

El esquema sys es un conjunto de objetos y vistas en una base de datos de MySQL que ayuda a los usuarios a solucionar problemas, optimizar y supervisar las instancias de base de datos. Al realizar una actualización de la versión principal de la versión 2 a la versión 3 de Aurora MySQL, las vistas del esquema sys se vuelven a crear y actualizar a las nuevas definiciones de la versión 3 de Aurora MySQL.

Como parte de la actualización, si algún objeto del esquema sys se define mediante motores de almacenamiento (sys_config/BASE TABLE en INFORMATION_SCHEMA.TABLES) y no mediante vistas, se producirá un error en la actualización. Estas tablas pueden encontrarse en la tabla information_schema.tables. Este no es el comportamiento esperado, pero en algunos casos puede ocurrir debido a un error del usuario.

Esta comprobación previa valida todos los objetos del esquema sys para garantizar que utilizan las definiciones de tabla correctas y que las vistas no se definen erróneamente como tablas de InnoDB o MyISAM. Para resolver el problema, corrija manualmente los objetos devueltos cambiándoles el nombre o eliminándolos. A continuación, vuelva a intentar la actualización.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "description": "Database contains objects with type mismatch for sys schema.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "sys.waits_global_by_latency",
        "description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
      }
  ]
}

La comprobación previa indica que la vista sys.waits_global_by_latency del esquema sys presenta una discrepancia de tipos que impide que se continúe con la actualización.

Tras iniciar sesión en la instancia de base de datos, puede ver que este objeto se define como una tabla de InnoDB, cuando debería ser una vista.

mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
       Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
  `events` varchar(128) DEFAULT NULL,
  `total` bigint(20) unsigned DEFAULT NULL,
  `total_latency` text,
  `avg_latency` text,
  `max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Para resolver este problema, podemos eliminar y volver a crear la vista con la definición correcta o cambiarle el nombre. Durante el proceso de actualización, se creará automáticamente con la definición de tabla correcta.

mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)

Una vez hecho esto, se aprueba la comprobación previa.

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación del límite superior del nombre de columna en la vista

La longitud máxima permitida de un nombre de columna en MySQL es de 64 characters. En las versiones anteriores a MySQL 8.0, en algunos casos era posible crear una vista con un nombre de columna de más de 64 caracteres. Si existe alguna de estas vistas en la instancia de la base de datos, se mostrará un error de comprobación previa y no se realizará correctamente la actualización. Para poder continuar con la actualización, debe volver a crear las vistas en cuestión, asegurándose de que la longitud de sus columnas sea inferior a 64 caracteres. A continuación, vuelva a intentar la actualización.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "description": "Following view(s) has column(s) with length greater than 64.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
        "description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
      }
  ]
}

La comprobación previa indica que la vista test.colname_view_test incluye una columna col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad que supera la longitud máxima permitida de 64 caracteres.

Si observamos la definición de la vista, podemos ver la columna problemática.

mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field                                                            | Type        | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1                                                             | varchar(20) | YES  |     | NULL    |       |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11)     | YES  |     | NULL    |       |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Para poder continuar con la actualización, vuelva a crear la vista y asegúrese de que la longitud de la columna no supere los 64 caracteres.

mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)

mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)

mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1       | varchar(20) | YES  |     | NULL    |       |
| col2_nopad | int(11)     | YES  |     | NULL    |       |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Una vez hecho esto, la comprobación previa se realizará correctamente.

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de si hay tablas con índices definidos con una longitud de prefijo superior a 255 bytes en columnas pequeñas

Al crear un índice en una columna con un tipo de datos binario en MySQL, debe añadir una longitud de prefijo en la definición del índice. En las versiones anteriores a MySQL 8.0, en algunos casos era posible especificar una longitud de prefijo superior al tamaño máximo permitido para estos tipos de datos. Un ejemplo son las columnas TINYTEXT y TINYBLOB, en las que el tamaño máximo de datos permitido es de 255 bytes, pero se permitían prefijos de índice mayores. Para obtener más información, consulte la sección InnoDB limits en la documentación de MySQL.

Si esta comprobación previa no se realiza correctamente, elimine el índice problemático o reduzca la longitud del prefijo de las columnas TINYTEXT y TINYBLOB del índice a menos de 255 bytes. A continuación, vuelva a intentar la actualización.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.tintxt_prefixed_index.col1",
        "description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
      }
  ]
}

La comprobación previa indica que hay un error en la tabla test.tintxt_prefixed_index, ya que tiene un índice PRIMARY con un prefijo superior a 255 bytes en una columna TINYTEXT o TINYBLOB.

Si observamos la definición de esta tabla, podemos ver que la clave principal tiene el prefijo 65 en la columna TINYTEXT col1. Dado que la tabla se define mediante el conjunto de caracteres utf8mb4, que almacena 4 bytes por carácter, el prefijo supera el límite de 255 bytes.

mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
       Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
  `col1` tinytext NOT NULL,
  `col2` tinytext,
  `col_id` tinytext,
  PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)

Si se modifica el prefijo del índice a 63 mientras se utiliza el conjunto de caracteres utf8mb4, se podrá continuar con la actualización.

mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD  PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

Una vez hecho esto, la comprobación previa se realizará correctamente.

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: error

Comprobación de la incoherencia de los metadatos de InnoDB que faltan en la tabla mysql.host

Se trata de una comprobación previa exclusivamente interna llevada a cabo por el servicio de RDS. Los errores se gestionarán automáticamente en la actualización y pueden omitirse de forma segura.

Si detecta algún error con esta comprobación previa, abra un caso con AWS Support para solicitar que se resuelva la incoherencia de los metadatos. También puede volver a intentar la actualización. Para ello, debe realizar un volcado lógico y, a continuación, restaurar a un nuevo clúster de base de datos que ejecute la versión 3 de Aurora MySQL.

Nivel de comprobación previa: error

Comprobación de si hay comentarios de columnas utf8mb3 no válidos

Esta comprobación previa identifica las tablas que contienen comentarios de columnas con una codificación de caracteres utf8mb3 no válida. En MySQL 8.0, se aplica una validación más estricta a la codificación de caracteres en los metadatos, incluidos los comentarios de las columnas. Si algún comentario de columna contiene caracteres que no son válidos en el conjunto de caracteres utf8mb3, la actualización producirá un error.

La causa más común de este problema es la presencia de caracteres que no pertenecen a BMP (Plano Básico Multilingüe) en los comentarios de las columnas. Los caracteres que no pertenecen al BMP requieren codificación UTF-8 de 4 bytes (utf8mb4), pero utf8mb3 solo admite secuencias de 3 bytes, que no pueden representar estos caracteres.

Para resolver este problema, debe modificar los comentarios de las columnas para eliminar o reemplazar los caracteres que no pertenezcan al BMP antes de intentar la actualización. Puede usar la instrucción ALTER TABLE para actualizar los comentarios de las columnas.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.t2",
        "description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
      }
  ]
}

La comprobación previa indica que la tabla test.t2 contiene caracteres utf8mb3 no válidos en uno o más comentarios de columna, específicamente debido a la presencia de caracteres que no son del BMP.

Para resolver este problema, puede identificar las columnas problemáticas y actualizar sus comentarios. Primero, examine la estructura de la tabla para identificar las columnas con comentarios:

mysql> SHOW CREATE TABLE test.t2\G

Una vez que haya identificado las columnas con comentarios problemáticos, actualícelas mediante la instrucción ALTER TABLE. Por ejemplo:

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';

Alternativamente, puede eliminar el comentario por completo:

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';

Tras actualizar todos los comentarios problemáticos de las columnas, se aprobará la comprobación previa y la actualización podrá continuar:

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: advertencia

Aspectos a tener en cuenta sobre el nuevo complemento de autenticación predeterminado

En MySQL 8.0, se ha introducido el complemento de autenticación caching_sha2_password, que proporciona un cifrado de contraseñas más seguro y un mejor rendimiento que el complemento obsoleto mysql_native_password. En el caso de la versión 3 de Aurora MySQL, el complemento de autenticación predeterminado que se usa para los usuarios de bases de datos es mysql_native_password.

Esta comprobación previa advierte que este complemento se eliminará y se cambiará el predeterminado en una futura versión principal. Plantéese la posibilidad de evaluar la compatibilidad de los clientes y usuarios de la aplicación antes de realizar este cambio.

Para obtener más información, consulte la sección caching_sha2_password Compatibility Issues and Solutions en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "defaultAuthenticationPlugin",
  "title": "New default authentication plugin considerations",
  "description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},

Nivel de comprobación previa: advertencia

Uso de un indicador de MAXDB obsoleto de sql_mode

En MySQL 8.0, se han eliminado una serie de opciones de variables del sistema sql_mode; una de ellos era MAXDB. Esta comprobación previa examina todas las sesiones actualmente conectadas, junto con las rutinas y los desencadenadores, para garantizar que ninguna de ellas tenga el parámetro sql_mode establecido en ninguna combinación que incluya MAXDB.

Ejemplo de salida:

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.maxdb_stored_routine",
        "description": "PROCEDURE uses obsolete MAXDB sql_mode",
        "dbObjectType": "Routine"
      }
  ]
}

La comprobación previa indica que la rutina test.maxdb_stored_routine incluye una opción sql_mode no compatible.

Tras iniciar sesión en la base de datos, podrá ver la definición de rutina en la que sql_mode incluye MAXDB.

 > SHOW CREATE PROCEDURE test.maxdb_stored_routine\G

*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Para resolver el problema, vuelva a crear el procedimiento después de configurar el parámetro sql_mode correcto en el cliente.

Vuelva a crear el procedimiento sin el parámetro sql_mode no compatible.

mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
    -> SQL SECURITY DEFINER
    -> BEGIN
    ->     SELECT * FROM test;
    -> END$$
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

La comprobación previa se realiza correctamente.

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "detectedProblems": []
}

Nivel de comprobación previa: advertencia

Comprobación de si el uso de signos de dólar únicos está obsoleto en los nombres de objetos

A partir de la versión 8.0.32 de MySQL, el uso del signo de dólar ($) como primer carácter de un identificador sin comillas está obsoleto. Si tiene algún esquema, tabla, vista, columna o rutina que incluya un $ como primer carácter, esta comprobación previa mostrará una advertencia. Si bien esta advertencia no impide que se lleve a cabo la actualización, le recomendamos que tome medidas para resolverlo lo antes posible. A partir de MySQL 8.4, cualquier identificador de este tipo devolverá un error de sintaxis en lugar de una advertencia.

Ejemplo de salida:

{
  "id": "mysqlDollarSignNameCheck",
  "title": "Check for deprecated usage of single dollar signs in object names",
  "status": "OK",
  "description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.$deprecated_syntx",
        "description": " name starts with $ sign."
      }
  ]
},

La comprobación previa muestra una advertencia porque la tabla $deprecated_syntx del esquema test incluye un $ como primer carácter.

Nivel de comprobación previa: advertencia

Uso de objetos de base de datos con nombres que entran en conflicto con las nuevas palabras clave reservadas

Esta comprobación es similar a la de routineSyntaxCheck, ya que comprueba el uso de objetos de base de datos cuyos nombres entran en conflicto con las nuevas palabras clave reservadas. Aunque no impiden las actualizaciones, es necesario evaluar detenidamente las advertencias.

Ejemplo de salida:

Si utilizamos el ejemplo anterior con la tabla denominada except, la comprobación previa mostrará una advertencia:

{
  "id": "reservedKeywordsCheck",
  "title": "Usage of db objects with names conflicting with new reserved keywords",
  "status": "OK",
  "description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.except",
        "description": "Table name",
        "dbObjectType": "Table"
      }
  ]
}

Esta advertencia le permite saber que es posible que haya que revisar algunas consultas de la aplicación. Si las consultas de la aplicación no aplican correctamente caracteres de escape a los literales de cadena, es posible que se produzcan errores después de actualizar a MySQL 8.0. Revise las aplicaciones para confirmar esto y compruébelas con un clon o una instantánea del clúster de base de datos de Aurora MySQL que se ejecute en la versión 3.

Ejemplo de una consulta de aplicación a la que no se le hayan aplicado caracteres de escape que no se realizará tras la actualización:

SELECT * FROM escape;

Ejemplo de una consulta de aplicación a la que se le hayan aplicado correctamente caracteres de escape que se realizará tras la actualización:

SELECT * FROM 'escape';

Nivel de comprobación previa: advertencia

Uso del conjunto de caracteres utf8mb3

En MySQL 8.0, el conjunto de caracteres utf8mb3 está obsoleto y se eliminará en una futura versión principal de MySQL. Esta comprobación previa se implementa para emitir una advertencia si se detecta algún objeto de la base de datos que utilice este conjunto de caracteres. Si bien esto no impedirá que se continúe con la actualización, le recomendamos encarecidamente que piense en migrar las tablas al conjunto de caracteres utf8mb4, que es el predeterminado a partir de MySQL 8.0. Para obtener más información sobre utf8mb3 y utf8mb4, consulte Converting between 3-byte and 4-byte Unicode character sets en la documentación de MySQL.

Ejemplo de salida:

{
  "id": "utf8mb3",
  "title": "Usage of utf8mb3 charset",
  "status": "OK",
  "description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.t1.col1",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      },
      {
        "level": "Warning",
        "dbObject": "test.t1.col2",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      }
  ]
}

Para resolver este problema, vuelva a crear los objetos y las tablas a los que se ha hecho referencia. Para obtener más información y conocer los requisitos previos antes de hacerlo, consulte la sección Converting between 3-byte and 4-byte Unicode character sets en la documentación de MySQL.

Nivel de comprobación previa: advertencia

Valores cero de fecha, fecha y hora y marca de tiempo

MySQL ahora aplica reglas más estrictas con respecto al uso de valores cero en las columnas de fecha, fecha y hora y marca de tiempo. Le recomendamos que utilice los modos NO_ZERO_IN_DATE y NO_ZERO_DATE SQL junto con el modo strict, ya que se fusionarán con el modo strict en una versión futura de MySQL.

Si la configuración de sql_mode de alguna de las conexiones de la base de datos, en el momento de ejecutar la comprobación previa, no incluye estos modos, aparecerá una advertencia en la comprobación previa. Es posible que los usuarios aún puedan insertar los valores de fecha, fecha y hora y marca de tiempo que incluyan valores cero. Sin embargo, recomendamos encarecidamente sustituir los valores cero por valores válidos, ya que su comportamiento podría cambiar en el futuro y puede que no funcionen correctamente. Como se trata de una advertencia, no impedirá las actualizaciones, pero le recomendamos que empiece a planificar las medidas necesarias.

Ejemplo de salida:

{
  "id": "zeroDatesCheck",
  "title": "Zero Date, Datetime, and Timestamp values",
  "status": "OK",
  "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
  "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "global.sql_mode",
        "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      },
      {
        "level": "Warning",
        "dbObject": "session.sql_mode",
        "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      }
  ]
}

Nivel de comprobación previa: advertencia

Comprueba si la longitud de la lista del historial de segmentos de reversión del clúster es alta

Tal y como se ha mencionado en auroraUpgradeCheckForIncompleteXATransactions, mientras se ejecuta el proceso de actualización de la versión principal, es esencial que la instancia de base de datos de la versión 2 de Aurora MySQL se cierre por completo. Esto garantiza que todas las transacciones se confirmen o se reviertan y que InnoDB haya purgado todos los registros de deshacer.

Si el clúster de base de datos tiene una longitud de la lista del historial (HLL) de segmentos de reversión larga, puede prolongarse el tiempo que InnoDB tarda en completar la purga de los registros de deshacer, lo que provoca un tiempo de inactividad prolongado durante el proceso de actualización de la versión principal. Si la comprobación previa detecta que la HLL del clúster de base de datos es larga, se generará una advertencia. Si bien esto no impide que se continúe con la actualización, le recomendamos que supervise de cerca la HLL del clúster de base de datos. Al mantenerla en niveles bajos, se reducirá el tiempo de inactividad necesario durante una actualización de la versión principal. Para obtener más información sobre la supervisión de HLL, consulte La longitud de la lista de historial de InnoDB ha aumentado de forma significativa.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
  "title": "Checks if the rollback segment history length for the cluster is high",
  "status": "OK",
  "description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_metrics",
        "description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
      }
  ]
}

La comprobación previa devuelve una advertencia porque ha detectado que la HLL de deshacer de InnoDB era larga en el clúster de la base de datos (82989114). Aunque se continúe con la actualización, en función de la cantidad de operaciones de deshacer que se deba purgar, puede prolongar el tiempo de inactividad necesario durante el proceso de actualización.

Le recomendamos que investigue las transacciones abiertas en el clúster de base de datos antes de ejecutar la actualización en producción para asegurarse de que la HLL se mantenga en un tamaño manejable.

Nivel de comprobación previa: advertencia

Comprueba si hay muchas modificaciones de fila sin confirmar

Tal y como se ha mencionado en auroraUpgradeCheckForIncompleteXATransactions, mientras se ejecuta el proceso de actualización de la versión principal, es esencial que la instancia de base de datos de la versión 2 de Aurora MySQL se cierre por completo. Esto garantiza que todas las transacciones se confirmen o se reviertan y que InnoDB haya purgado todos los registros de deshacer.

Si el clúster de base de datos tiene transacciones que han modificado un gran número de filas, esto puede prolongar el tiempo que InnoDB tarda en completar la reversión de esta transacción como parte del proceso de cierre completo. Si la comprobación previa detecta transacciones de larga duración, con un gran número de filas modificadas en el clúster de base de datos, se generará una advertencia. Si bien esto no impide que se continúe con la actualización, le recomendamos que supervise de cerca el tamaño de las transacciones activas del clúster de la base de datos. Al mantenerla en niveles bajos, se reducirá el tiempo de inactividad necesario durante una actualización de la versión principal.

Ejemplo de salida:

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_trx",
        "description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
      }
  ]
},

La comprobación previa indica que el clúster de base de datos incluye una transacción con 11 000 000 de cambios de fila no confirmados que deberán revertirse durante el proceso de cierre completo. La actualización continuará, pero para reducir el tiempo de inactividad durante el proceso de actualización, le recomendamos que lo supervise e investigue antes de ejecutar la actualización en los clústeres de producción.

Para ver las transacciones activas en la instancia de base de datos de escritor, puede utilizar la tabla information_schema.innodb_trx. La siguiente consulta en la instancia de base de datos de escritor muestra las transacciones actuales, el tiempo de ejecución, el estado y las filas modificadas del clúster de la base de datos.

# Example of uncommitted transaction
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 |                         1592 |                          20041 | 52866130 | RUNNING   |      11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)

# Example of transaction rolling back
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state    | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 |                         1719 |                          20041 | 52866130 | ROLLING BACK |      10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)

Una vez confirmada o revertida la transacción, la comprobación previa ya no mostrará ninguna advertencia. Consulte la documentación de MySQL y hable con el equipo de aplicaciones antes de revertir cualquier transacción grande, ya que la reversión puede tardar algún tiempo en completarse, según el tamaño de la transacción.

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "detectedProblems": []
},

Para obtener más información sobre la optimización de la administración de transacciones de InnoDB y el posible impacto al ejecutar y revertir transacciones de gran tamaño en instancias de bases de datos de MySQL, consulte la sección Optimizing InnoDB Transaction Management en la documentación de MySQL.

Nivel de comprobación previa: aviso

Uso de indicadores de sql_mode obsoletos

Además de MAXDB, se ha eliminado una serie de otras opciones de sql_mode: DB2, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS y NO_TABLE_OPTIONS. A partir de MySQL 8.0, ninguno de estos valores se puede asignar a la variable del sistema sql_mode. Si esta comprobación previa detecta sesiones abiertas con esta configuración de sql_mode, asegúrese de que los grupos de parámetros de la instancia de base de datos y del clúster de base de datos, así como las aplicaciones y configuraciones del cliente, estén actualizados para deshabilitarlos. Para obtener más información, consulte la documentación de MySQL.

Ejemplo de salida:

{
  "id": "sqlModeFlagCheck",
  "title": "Usage of obsolete sql_mode flags",
  "status": "OK",
  "detectedProblems": []
}

Para resolver alguno de estos errores de comprobación previa, consulte maxdbFlagCheck.

Nivel de comprobación previa: error, advertencia o aviso

Problemas notificados por el comando check table x for upgrade

Antes de iniciar la actualización a la versión 3 de Aurora MySQL, se ejecuta check table for upgrade en cada tabla de los esquemas de usuarios del clúster de la base de datos. Esta comprobación previa no es la misma que la de checkTableMysqlSchema.

El comando check table for upgrade examina las tablas para detectar posibles problemas que puedan surgir durante una actualización a una versión más reciente de MySQL. Ejecutar este comando antes de intentar una actualización puede ayudar a identificar y resolver cualquier incompatibilidad con antelación, lo que facilita el proceso de actualización propiamente dicho.

Este comando realiza varias comprobaciones en cada tabla, como, por ejemplo:

A diferencia de otras comprobaciones previas, puede devolver un error, una advertencia o un aviso en función del resultado de check table. Si esta comprobación previa devuelve alguna tabla, revísela detenidamente, junto con el código de devolución y el mensaje antes de iniciar la actualización. Para obtener más información, consulte la sección CHECK TABLE statement en la documentación de MySQL.

A continuación, ofrecemos un ejemplo de error y un ejemplo de advertencia.

Ejemplo de error:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.parent",
        "description": "Table 'test.parent' doesn't exist"
      }
  ]
},

La comprobación previa indica que hay un error porque la tabla test.parent no existe.

El archivo mysql-error.log de la instancia de base de datos de escritor muestra que hay un error de clave externa.

2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

Inicie sesión en la instancia de base de datos de escritor y ejecute show engine innodb status\G para obtener más información sobre el error de clave externa.

mysql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.

El mensaje LATEST FOREIGN KEY ERROR indica que a la restricción de clave externa fk_pname de la tabla test.child, que hace referencia a la tabla test.parent, le falta un índice o el tipo de datos no coincide. La documentación de MySQL sobre las restricciones de claves externas establece que las columnas a las que se hace referencia en una clave externa deben tener un índice asociado y las columnas principales o secundarias deben usar el mismo tipo de datos.

Para verificar si esto se debe a la falta de un índice o a que el tipo de datos no coincide, inicie sesión en la base de datos y compruebe las definiciones de la tabla deshabilitando temporalmente la variable de sesión foreign_key_checks. Después de hacerlo, podemos ver que la restricción secundaria en cuestión (fk_pname) utiliza p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL para hacer referencia a la tabla principal name varchar(20) NOT NULL. La tabla principal utiliza DEFAULT CHARSET=utf8, pero la columna p_name de la tabla secundaria utiliza latin1, por lo que se produce un error de incoherencia entre los tipos de datos.

mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)

mysql> show create table parent\G
*************************** 1. row ***************************
       Table: parent
Create Table: CREATE TABLE `parent` (
  `name` varchar(20) NOT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Para resolver este problema, podemos cambiar la tabla secundaria para que use el mismo conjunto de caracteres que la tabla principal o cambiar la tabla principal para que use el mismo conjunto de caracteres que la tabla secundaria. En este caso, dado que la tabla secundaria usa explícitamente latin1 en la definición de columna p_name, ejecutamos ALTER TABLE para modificar el conjunto de caracteres a utf8.

mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)

Después de hacerlo, se aprueba la comprobación previa y se puede continuar con la actualización.

Ejemplo de advertencia:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.orders",
        "description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
      }
  ]
}

La comprobación previa muestra una advertencia para el desencadenador delete_audit_trigg de la tabla test.orders, ya que no tiene el atributo CREATED. Según la sección Checking Version Compatibility de la documentación de MySQL, este mensaje es informativo y se muestra para los desencadenadores creados en las versiones anteriores a MySQL 5.7.2.

Dado que se trata de una advertencia, no impide que se lleve a cabo la actualización. Sin embargo, si desea resolver el problema, puede volver a crear el desencadenador en cuestión, y la comprobación previa se realizará correctamente sin ningún tipo de advertencia.

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": []
},