Référence des descriptions de prévérification pour Aurora MySQL

Niveau de prévérification : Erreur

Problèmes signalés par la check table x for upgrade commande pour le mysql schéma

Avant de démarrer la mise à niveau vers Aurora MySQL version 3, check table for upgrade elle est exécutée sur chaque table du mysql schéma de l'instance de base de données. La check table for upgrade commande examine les tables pour détecter tout problème potentiel pouvant survenir lors d'une mise à niveau vers une version plus récente de MySQL. L'exécution de cette commande avant de tenter une mise à niveau peut aider à identifier et à résoudre les incompatibilités à l'avance, ce qui facilite le processus de mise à niveau proprement dit.

Cette commande effectue différentes vérifications sur chaque table, telles que les suivantes :

Pour plus d'informations, consultez l'instruction CHECK TABLE dans la documentation MySQL.

Exemple de sortie :

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

Le résultat de cette prévérification dépend de l'erreur rencontrée et du moment où elle check table for upgrade se produit, car plusieurs vérifications sont effectuées.

Si vous rencontrez des erreurs lors de cette prévérification, ouvrez un dossier auprès du AWS Support pour demander que l'incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en effectuant un vidage logique, puis en effectuant une restauration vers un nouveau cluster de base de données Aurora MySQL version 3.

Niveau de prévérification : Erreur

Références de répertoire circulaires dans les chemins de fichiers de données des tablespaces

Depuis MySQL 8.0.17, la CREATE TABLESPACE ... ADD DATAFILE clause n'autorise plus les références circulaires à des répertoires. Pour éviter les problèmes de mise à niveau, supprimez toutes les références de répertoire circulaires des chemins de fichiers de données des espaces de table avant de passer à Aurora MySQL version 3.

Exemple de sortie :

{
  "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 cette erreur s'affiche, reconstruisez vos tables à l'aide d'un file-per-table tablespace. Utilisez les chemins de fichier par défaut pour tous les espaces de table et toutes les définitions de tables.

Après la reconstruction, le précontrôle passe, ce qui permet à la mise à niveau de se poursuivre.

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

Niveau de prévérification : Erreur

Colonnes ne pouvant pas avoir de valeurs par défaut

Avant MySQL 8.0.13,, BLOB TEXTGEOMETRY, et les JSON colonnes ne pouvaient pas avoir de valeurs par défaut. Supprimez toutes les clauses par défaut de ces colonnes avant de passer à Aurora MySQL version 3. Pour plus d'informations sur les modifications apportées à la gestion par défaut de ces types de données, consultez les valeurs par défaut des types de données dans la documentation MySQL.

Exemple de sortie :

{
  "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 prévérification renvoie une erreur car la geo_col colonne de la test.test_blob_default table utilise un type de JSON données BLOBTEXT,GEOMETRY, ou avec une valeur par défaut spécifiée.

En regardant la définition de la table, nous pouvons voir que la geo_col colonne est définie commegeo_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

Suppression de cette clause par défaut pour permettre à la prévérification de réussir.

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 prévérification est réussie et vous pouvez réessayer la mise à niveau.

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

Niveau de prévérification : Erreur

Utilisation de mots clés dépréciés dans la définition

MySQL 8.0 a supprimé le cache de requêtes. Par conséquent, certaines syntaxes SQL spécifiques au cache de requêtes ont été supprimées. Si l'un des objets de votre base de données contient les SQL_NO_CACHE mots clés QUERY CACHESQL_CACHE, ou, une erreur de prévérification est renvoyée. Pour résoudre ce problème, recréez ces objets en supprimant les mots clés mentionnés.

Exemple de sortie :

{
  "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"
      }
  ]
}

Le précontrôle indique que la procédure test.no_query_cache_check stockée utilise l'un des mots clés supprimés. En regardant la définition de la procédure, nous pouvons voir qu'elle utiliseSQL_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)

Supprimez le mot clé.

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 ;

Une fois le mot clé supprimé, la prévérification est terminée avec succès.

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

Niveau de prévérification : Erreur

Tables reconnues par InnoDB qui appartiennent à un autre moteur

De même schemaInconsistencyCheck, cette prévérification vérifie que les métadonnées des tables dans MySQL sont cohérentes avant de procéder à la mise à niveau.

Si vous rencontrez des erreurs lors de cette prévérification, ouvrez un dossier auprès du AWS Support pour demander que l'incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en effectuant un vidage logique, puis en effectuant une restauration vers un nouveau cluster de base de données Aurora MySQL version 3.

Exemple de sortie :

{
  "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"
      }
  ]
}

Niveau de prévérification : Erreur

ENUMet des définitions de SET colonnes contenant des éléments de plus de 255 caractères

Les tables et les procédures stockées ne doivent pas comporter ENUM ni éléments de SET colonne supérieurs à 255 caractères ou 1 020 octets. Avant MySQL 8.0, la longueur maximale combinée était de 64 Ko, mais la version 8.0 limite les éléments individuels à 255 caractères ou 1 020 octets (supportant le multioctet). En cas d'échec de la prévérification pourenumSetElementLengthCheck, modifiez tous les éléments dépassant ces nouvelles limites avant de réessayer la mise à niveau.

Exemple de sortie :

{
  "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 prévérification signale une erreur car la colonne s du test.large_set tableau contient un SET élément de plus de 255 caractères.

Après avoir réduit la SET taille de cette colonne, le précontrôle est réussi, ce qui permet à la mise à niveau de se poursuivre.

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

Niveau de prévérification : Erreur

Noms de contraintes de clé étrangère de plus de 64 caractères

Dans MySQL, la longueur des identifiants est limitée à 64 caractères, comme indiqué dans la documentation MySQL. En raison de problèmes identifiés selon lesquels la longueur des clés étrangères pouvait être égale ou supérieure à cette valeur, entraînant des échecs de mise à niveau, cette prévérification a été mise en œuvre. Si vous rencontrez des erreurs lors de cette prévérification, vous devez modifier ou renommer votre contrainte afin qu'elle comporte moins de 64 caractères avant de réessayer la mise à niveau.

Exemple de sortie :

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

Niveau de prévérification : Erreur

Tous les noms de déclencheurs d'une base de données doivent être uniques.

En raison des modifications apportées à l'implémentation du dictionnaire de données, MySQL 8.0 ne prend pas en charge les déclencheurs distinguant majuscules et minuscules dans une base de données. Ce précontrôle vérifie que votre cluster de bases de données ne possède pas une ou plusieurs bases de données contenant des déclencheurs dupliqués. Pour plus d'informations, consultez la section Sensibilité majuscules/minuscules de l'identifiant dans la documentation MySQL.

Exemple de sortie :

{
  "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 prévérification signale une erreur indiquant que le cluster de base de données possède deux déclencheurs portant le même nom, mais dans des cas différents : test.before_insert_product ettest.before_insert_PRODUCT.

Avant la mise à niveau, renommez les déclencheurs ou supprimez-les et recréez-les sous un nouveau nom.

Une fois le nom renommé test.before_insert_PRODUCT entest.before_insert_product_2, le précontrôle réussit.

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

Niveau de prévérification : Erreur

La colonne de définition pour ne mysql.event peut pas être nulle ou vide.

L'DEFINERattribut indique le compte MySQL qui possède une définition d'objet stockée, telle qu'un déclencheur, une procédure stockée ou un événement. Cet attribut est particulièrement utile dans les situations où vous souhaitez contrôler le contexte de sécurité dans lequel s'exécute l'objet stocké. Lors de la création d'un objet stocké, si aucun a DEFINER n'est spécifié, la valeur par défaut est l'utilisateur qui a créé l'objet.

Lors de la mise à niveau vers MySQL 8.0, vous ne pouvez stocker aucun objet contenant un défineur null ou un définisseur vide dans le dictionnaire de données MySQL. Si vous avez de tels objets stockés, une erreur de prévérification est générée. Vous devez le corriger avant de procéder à la mise à niveau.

Exemple d'erreur :

{
  "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 prévérification renvoie une erreur pour l'test.get_versionévénement car celui-ci possède un null définisseur.

Pour résoudre ce problème, vous pouvez vérifier la définition de l'événement. Comme vous pouvez le constater, le définisseur est vide null ou vide.

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)

Supprimez ou recréez l'événement avec un définisseur valide.

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)

Maintenant, le précontrôle est passé.

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

Niveau de prévérification : Erreur

Incompatibilité de définition de colonne entre le dictionnaire de données InnoDB et la définition réelle de la table

De même schemaInconsistencyCheck, cette prévérification vérifie que les métadonnées des tables dans MySQL sont cohérentes avant de procéder à la mise à niveau. Dans ce cas, le précontrôle vérifie que les définitions de colonnes correspondent entre le dictionnaire de données InnoDB et la définition de table MySQL. Si une incompatibilité est détectée, la mise à niveau ne se poursuit pas.

Si vous rencontrez des erreurs lors de cette prévérification, ouvrez un dossier auprès du AWS Support pour demander que l'incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en effectuant un vidage logique, puis en effectuant une restauration vers un nouveau cluster de base de données Aurora MySQL version 3.

Exemple de sortie :

{
  "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 prévérification signale une incohérence dans les métadonnées de la id colonne de la table. test.mismatchTable Plus précisément, les métadonnées MySQL ont le nom de colonne commeiD, tandis qu'InnoDB l'a comme nom de colonne. id

Niveau de prévérification : Erreur

La colonne de définition pour « information_schema.triggers Impossible d'être » null ou « vide ».

La prévérification vérifie que votre base de données ne possède aucun déclencheur défini avec null ou sans définisseur. Pour plus d'informations sur les exigences du définisseur pour les objets stockés, consultez getEventsWithNullDefiner.

Exemple de sortie :

{
  "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 prévérification renvoie une erreur car le example_trigger déclencheur du test schéma possède un null définisseur. Pour corriger ce problème, corrigez le définisseur en recréant le déclencheur avec un utilisateur valide, ou supprimez le déclencheur. Pour plus d'informations, consultez l'exemple dans getEventsWithNullDefiner.

Niveau de prévérification : Erreur

Tous les noms de base de données ou de tables doivent être en minuscules lorsque le lower_case_table_names paramètre est défini sur. 1

Avant MySQL 8.0, les noms de base de données, les noms de tables et les autres objets correspondaient à des fichiers du répertoire de données, tels que des métadonnées basées sur des fichiers (.frm). La variable système lower_case_table_names permet aux utilisateurs de contrôler la façon dont le serveur gère la distinction majuscules/majuscules des identificateurs pour les objets de base de données et le stockage de ces objets de métadonnées. Ce paramètre peut être modifié sur un serveur déjà initialisé après un redémarrage.

Cependant, dans MySQL 8.0, bien que ce paramètre contrôle toujours la façon dont le serveur gère la distinction majuscules/majuscules, il ne peut pas être modifié une fois le dictionnaire de données initialisé. Lors de la mise à niveau ou de la création d'une base de données MySQL 8.0, lower_case_table_names la valeur définie lors du premier démarrage du dictionnaire de données sur MySQL est utilisée pendant toute la durée de vie de cette base de données. Cette restriction a été mise en place dans le cadre de l'implémentation de l'Atomic Data Dictionary, où les objets de base de données sont migrés des métadonnées basées sur des fichiers vers les tables InnoDB internes du schéma. mysql

Pour plus d'informations, consultez la section Modifications du dictionnaire de données dans la documentation MySQL.

Pour éviter les problèmes lors de la mise à niveau lors de la mise à jour des métadonnées basées sur des fichiers vers le nouveau dictionnaire de données atomiques, cette prévérification permet de vérifier que toutes les tables sont stockées sur le disque en minuscules. lower_case_table_names = 1 Si ce n'est pas le cas, une erreur de prévérification est renvoyée et vous devez corriger les métadonnées avant de procéder à la mise à niveau.

Exemple de sortie :

{
  "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"
      }
  ]
}

Une erreur est renvoyée car le tableau test.TEST contient des lettres majuscules, mais lower_case_table_names est défini sur. 1

Pour résoudre ce problème, vous pouvez renommer la table en minuscules ou modifier le lower_case_table_names paramètre sur le cluster de base de données avant de démarrer la mise à niveau.

Niveau de prévérification : Erreur

Utilisation de la GROUP BY ASC/DESC syntaxe supprimée

Depuis MySQL 8.0.13, la DESC syntaxe obsolète ASC des GROUP BY clauses a été supprimée. Les requêtes basées sur le GROUP BY tri peuvent désormais produire des résultats différents. Pour obtenir un ordre de tri spécifique, utilisez plutôt une ORDER BY clause. Si des objets utilisent cette syntaxe dans votre base de données, vous devez les recréer à l'aide d'une ORDER BY clause avant de réessayer la mise à niveau. Pour plus d'informations, consultez les modifications apportées au code SQL dans la documentation MySQL.

Exemple de sortie :

{
  "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"
      }
  ]
}

Niveau de prévérification : Erreur

Vérifiez la .<table> syntaxe obsolète utilisée dans les routines.

Dans MySQL 8.0, les routines ne peuvent plus contenir la syntaxe d'identifiant obsolète ()\".<table>\". Si des routines ou des déclencheurs enregistrés contiennent de tels identifiants, la mise à niveau échoue. Par exemple, la .dot_table référence suivante n'est plus autorisée :

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)

Une fois que vous avez recréé les routines et les déclencheurs afin d'utiliser la syntaxe d'identifiant correcte et de les éviter, le précontrôle est réussi et la mise à niveau peut se poursuivre. Pour plus d'informations sur les identifiants, consultez la section Noms des objets Schema dans la documentation MySQL.

Exemple de sortie :

{
  "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 prévérification renvoie une erreur pour la incorrect_procedure routine de la test base de données car elle contient une syntaxe obsolète.

Une fois que vous avez corrigé la routine, le précontrôle aboutit et vous pouvez réessayer la mise à niveau.

Niveau de prévérification : Erreur

Vérifiez les index trop grands pour fonctionner sur les versions de MySQL supérieures à 5.7

Pour les formats de ligne compacts ou redondants, il ne devrait pas être possible de créer un index avec un préfixe supérieur à 767 octets. Cependant, avant la version 5.7.35 de MySQL, cela était possible. Pour plus d'informations, consultez les notes de mise à jour de MySQL 5.7.35.

Tous les index affectés par ce bogue deviendront inaccessibles après la mise à niveau vers MySQL 8.0. Cette prévérification identifie les index incriminés qui doivent être reconstruits avant que la mise à niveau ne soit autorisée.

 {
  "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 prévérification renvoie une erreur car la test.table_with_large_idx table contient un index sur une table utilisant un format de ligne compact ou redondant de plus de 767 octets. Ces tables deviendraient inaccessibles après la mise à niveau vers MySQL 8.0. Avant de procéder à la mise à niveau, effectuez l'une des opérations suivantes :

Ici, nous reconstruisons la table pour résoudre l'échec du précontrôle. Avant de reconstruire la table, assurez-vous que innodb_file_format est défini sur et que innodb_default_row_format est défini sur. Barracuda dynamic Ce sont les valeurs par défaut de MySQL 5.7. Pour plus d'informations, consultez les formats de ligne InnoDB et la gestion des formats de fichiers InnoDB dans la documentation 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)

Après avoir reconstruit la table, le précontrôle est réussi et la mise à niveau peut se poursuivre.

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

Niveau de prévérification : Erreur

Vérifiez les noms de table et de schéma non valides utilisés dans MySQL 5.7

Lors de la migration vers le nouveau dictionnaire de données dans MySQL 8.0, votre instance de base de données ne peut pas contenir de schémas ou de tables préfixés par. #mysql50# Si de tels objets existent, la mise à niveau échoue. Pour résoudre ce problème, exécutez mysqlcheck sur les schémas et les tables renvoyés.

Exemple de sortie :

{
  "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"
      }
  ]
}

Le précontrôle indique que le nom du schéma #mysql50#fix_db_names n'est pas valide.

Après avoir corrigé le nom du schéma, le précontrôle est réussi, ce qui permet à la mise à niveau de se poursuivre.

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

Niveau de prévérification : Erreur

Vérifiez les routines orphelines dans la version 5.7

Lors de la migration vers le nouveau dictionnaire de données dans MySQL 8.0, s'il existe des procédures stockées dans la base de données où le schéma n'existe plus, la mise à niveau échoue. Ce précontrôle vérifie que tous les schémas référencés dans les procédures stockées de votre instance de base de données existent toujours. Pour autoriser la mise à niveau, supprimez ces procédures stockées.

Exemple de sortie :

{
  "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"
      }
  ]
},

Le précontrôle indique que la procédure get_version stockée dans la dropped_db base de données est orpheline.

Pour nettoyer cette procédure, vous pouvez recréer le schéma manquant.

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

Une fois le schéma recréé, vous pouvez abandonner la procédure pour permettre à la mise à niveau de se poursuivre.

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

Niveau de prévérification : Erreur

Les noms des tables dans le mysql schéma entrent en conflit avec les nouvelles tables de MySQL 8.0

Le nouveau dictionnaire de données atomiques introduit dans MySQL 8.0 stocke toutes les métadonnées dans un ensemble de tables InnoDB internes du mysql schéma. Au cours de la mise à niveau, les nouvelles tables du dictionnaire de données internes sont créées dans le mysql schéma. Pour éviter les collisions de noms, qui pourraient entraîner des échecs de mise à niveau, le précontrôle examine tous les noms de table du mysql schéma afin de s'assurer qu'aucun des nouveaux noms de table n'est déjà utilisé. Si tel est le cas, une erreur est renvoyée et la mise à niveau n'est pas autorisée à se poursuivre.

Exemple de sortie :

{
  "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"
      }
  ]
}

Une erreur est renvoyée car une table est nommée tablespaces dans le mysql schéma. Il s'agit de l'un des nouveaux noms de tables de dictionnaires de données internes de MySQL 8.0. Vous devez renommer ou supprimer ces tables avant de procéder à la mise à niveau, à l'aide de la RENAME TABLE commande.

Niveau de prévérification : Erreur

Tables partitionnées à l'aide de moteurs avec partitionnement non natif

Selon la documentation MySQL 8.0, deux moteurs de stockage fournissent actuellement un support de partitionnement natif : InnoDB et NDB. Parmi celles-ci, seule InnoDB est prise en charge dans la version 3 d'Aurora MySQL, compatible avec MySQL 8.0. Toute tentative de création de tables partitionnées dans MySQL 8.0 à l'aide d'un autre moteur de stockage échoue. Cette prévérification recherche les tables de votre cluster de base de données qui utilisent un partitionnement non natif. Le cas échéant, vous devez supprimer le partitionnement ou convertir le moteur de stockage en InnoDB.

Exemple de sortie :

{
  "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"
      }
  ]
}

Ici, une table MyISAM utilise le partitionnement, ce qui nécessite une action avant que la mise à niveau puisse commencer.

Niveau de prévérification : Erreur

Utilisation de l'ancien type temporel

Les « anciens temporels » font référence aux colonnes de type temporel (telles que TIMESTAMP etDATETIME) créées dans les versions 5.5 et antérieures de MySQL. Dans MySQL 8.0, la prise en charge de ces anciens types de données temporelles est supprimée, ce qui signifie que les mises à niveau sur place de MySQL 5.7 à 8.0 ne sont pas possibles si la base de données contient ces anciens types temporels. Pour résoudre ce problème, vous devez reconstruire toutes les tables contenant ces anciens types de dates temporelles avant de procéder à la mise à niveau.

Pour plus d'informations sur la dépréciation des anciens types de données temporelles dans MySQL 5.7, consultez ce blog. Pour plus d'informations sur la suppression des anciens types de données temporelles dans MySQL 8.0, consultez ce blog.

Exemple de sortie :

{
  "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"
      }
  ]
},

Une erreur est signalée pour la colonne timestamp_column du tableautest.55_temporal_table, car elle utilise un ancien format de stockage sur disque temporel qui n'est plus pris en charge.

Pour résoudre ce problème et permettre la mise à niveau, reconstruisez la table pour convertir l'ancien format de stockage sur disque temporel vers le nouveau format introduit dans MySQL 5.6. Pour plus d'informations et pour connaître les conditions préalables, consultez la section Conversion entre des jeux de caractères Unicode de 3 octets et de 4 octets dans la documentation MySQL.

L'exécution de la commande suivante pour reconstruire les tables mentionnées dans cette prévérification convertit les anciens types temporels au nouveau format avec une précision d'une fraction de seconde.

ALTER TABLE ... ENGINE=InnoDB;

Pour plus d'informations sur la reconstruction des tables, consultez l'instruction ALTER TABLE dans la documentation MySQL.

Après avoir reconstruit la table en question et redémarré la mise à niveau, le contrôle de compatibilité réussit, ce qui permet à la mise à niveau de se poursuivre.

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

Niveau de prévérification : Erreur

Utilisation de tables partitionnées dans des tablespaces partagés

Depuis MySQL 8.0.13, la prise en charge du placement de partitions de table dans des tablespaces partagés est supprimée. Avant la mise à niveau, déplacez ces tables des espaces disque logiques partagés vers file-per-table les espaces disque logiques.

Exemple de sortie :

{
  "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 prévérification échoue car la partition p1 de la table test.partInnoDBTable se trouve dans le tablespace système.

Pour résoudre ce problème, reconstruisez la test.partInnodbTable table en plaçant la partition p1 en cause dans un file-per-table tablespace.

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

Une fois cela fait, le précontrôle est réussi.

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

Niveau de prévérification : Erreur

Utilisation de fonctions supprimées de la dernière version de MySQL

Dans MySQL 8.0, un certain nombre de fonctions intégrées ont été supprimées. Cette prévérification examine votre base de données à la recherche d'objets susceptibles d'utiliser ces fonctions. S'ils sont trouvés, une erreur est renvoyée. Vous devez résoudre les problèmes avant de réessayer la mise à niveau.

La majorité des fonctions supprimées sont des fonctions spatiales, qui ont été remplacées par des ST_* fonctions équivalentes. Dans ces cas, vous modifiez les objets de base de données pour utiliser le nouveau nom de procédure. Pour en savoir plus, consultez Fonctionnalités supprimées dans MySQL 8.0 dans la documentation MySQL.

Exemple de sortie :

{
  "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"
      }
  ]
},

Le précontrôle indique que la procédure test.GetLocationsInPolygon stockée utilise deux fonctions supprimées : POLYGONFROMTEXT et POINTFROMTEXT. Il suggère également d'utiliser les nouveaux ST_POLYGONFROMTEXT et ST_POINTFROMTEXT en remplacement. Après avoir recréé la procédure à l'aide des suggestions, la prévérification s'est terminée avec succès.

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

Niveau de prévérification : Erreur

Vérification de la syntaxe MySQL pour les objets de type routine

MySQL 8.0 a introduit des mots clés réservés qui n'étaient pas réservés auparavant. Le prévérificateur de mise à niveau évalue l'utilisation de mots clés réservés dans les noms des objets de base de données, dans leurs définitions et dans leur corps. S'il détecte des mots clés réservés utilisés dans des objets de base de données, tels que des procédures stockées, des fonctions, des événements et des déclencheurs, la mise à niveau échoue et une erreur est publiée dans le upgrade-prechecks.log fichier. Pour résoudre ce problème, vous devez mettre à jour ces définitions d'objets et placer ces références entre guillemets simples (') avant de procéder à la mise à niveau. Pour plus d'informations sur l'évasion des mots réservés dans MySQL, consultez String literals dans la documentation MySQL.

Vous pouvez également remplacer le nom par un autre nom, ce qui peut nécessiter des modifications de l'application.

Exemple de sortie :

{
  "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"
      }
  ]
}

Pour résoudre ce problème, vérifiez la définition de la routine.

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)

La procédure utilise une table nomméeexcept, qui est un nouveau mot clé dans MySQL 8.0. Recréez la procédure en échappant à la chaîne littérale.

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

Le précontrôle est maintenant réussi.

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

Niveau de prévérification : Erreur

Incohérences du schéma résultant de la suppression ou de la corruption de fichiers

Comme décrit précédemment, MySQL 8.0 a introduit l'Atomic Data Dictionary, qui stocke toutes les métadonnées dans un ensemble de tables InnoDB internes du mysql schéma. Cette nouvelle architecture fournit une méthode transactionnelle conforme à l'ACID pour gérer les métadonnées des bases de données, résolvant ainsi le problème du « DDL atomique » issu de l'ancienne approche basée sur les fichiers. Avant MySQL 8.0, les objets de schéma pouvaient devenir orphelins en cas d'interruption inattendue d'une opération DDL. La migration des métadonnées basées sur des fichiers vers les nouvelles tables du dictionnaire de données atomiques lors de la mise à niveau garantit l'absence d'objets de schéma orphelins de ce type dans l'instance de base de données. Si des objets orphelins sont détectés, la mise à niveau échoue.

Pour aider à détecter ces objets orphelins avant de lancer la mise à niveau, la schemaInconsistencyCheck prévérification est exécutée pour s'assurer que tous les objets de métadonnées du dictionnaire de données sont synchronisés. Si des objets de métadonnées orphelins sont détectés, la mise à niveau ne se poursuit pas. Pour procéder à la mise à niveau, nettoyez ces objets de métadonnées orphelins.

Si vous rencontrez des erreurs lors de cette prévérification, ouvrez un dossier auprès du AWS Support pour demander que l'incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en effectuant un vidage logique, puis en effectuant une restauration vers un nouveau cluster de base de données Aurora MySQL version 3.

Exemple de sortie :

{
  "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"
      }
  ]
}

Le précontrôle indique que les métadonnées de la test.schemaInconsistencyCheck_failure table ne sont pas cohérentes. Dans ce cas, la table existe dans les métadonnées du moteur de stockage InnoDB (information_schema.INNODB_SYS_TABLES), mais pas dans les métadonnées MySQL (information_schema.TABLES).

Niveau de prévérification : Erreur

Vérifiez la présence d'artefacts liés à la fonction de restauration DDL d'Aurora

Dans le cadre de l'implémentation de la restauration DDL (Data Definition Language) dans Aurora MySQL, les métadonnées des instructions DDL en vol sont conservées dans les ddl_log_table tables ddl_log_md_table et du schéma. mysql L'implémentation de la restauration DDL par Aurora n'est pas prise en charge à partir de la version 3, car cette fonctionnalité fait partie de la nouvelle implémentation du dictionnaire de données atomiques dans MySQL 8.0. Si des instructions DDL sont en cours d'exécution pendant les contrôles de compatibilité, cette prévérification risque d'échouer. Nous vous recommandons d'essayer la mise à niveau tant qu'aucune instruction DDL n'est en cours d'exécution.

Si cette prévérification échoue sans qu'aucune instruction DDL ne soit exécutée, ouvrez un dossier auprès du AWS Support pour demander que l'incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en effectuant un vidage logique, puis en effectuant une restauration vers un nouveau cluster de base de données Aurora MySQL version 3.

Si des instructions DDL sont en cours d'exécution, la sortie de prévérification affiche le message suivant :

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

Exemple de sortie :

{
  "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."
      }
  ]
}

Le précontrôle a renvoyé une erreur en raison d'un DDL en vol exécuté en même temps que les contrôles de compatibilité. Nous vous recommandons de réessayer la mise à niveau sans l' DDLs exécuter.

Niveau de prévérification : Erreur

Vérifier l'existence de la mysql.rds_upgrade_prechecks table

Il s'agit d'un précontrôle interne uniquement effectué par le service RDS. Toute erreur sera automatiquement traitée lors de la mise à niveau et pourra être ignorée en toute sécurité.

Si vous rencontrez des erreurs lors de cette prévérification, ouvrez un dossier auprès du AWS Support pour demander que l'incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en effectuant un vidage logique, puis en effectuant une restauration vers un nouveau cluster de base de données Aurora MySQL version 3.

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

Niveau de prévérification : Erreur

Vérifiez la présence d'artefacts liés à la fonctionnalité DDL rapide d'Aurora

L'optimisation Fast DDL a été introduite en mode laboratoire sur Aurora MySQL version 2 afin d'améliorer l'efficacité de certaines opérations DDL. Dans la version 3 d'Aurora MySQL, le mode laboratoire a été supprimé et l'implémentation de Fast DDL a été remplacée par la fonctionnalité MySQL 8.0 appelée Instant DDL.

Avant la mise à niveau vers Aurora MySQL version 3, toutes les tables utilisant Fast DDL en mode laboratoire devront être reconstruites en exécutant la ALTER TABLE ... ENGINE=InnoDB commande OPTIMIZE TABLE or pour garantir la compatibilité avec Aurora MySQL version 3.

Cette prévérification renvoie une liste de ces tables. Une fois les tables renvoyées reconstruites, vous pouvez réessayer la mise à niveau.

Exemple de sortie :

{
  "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."
      }
  ]
}

Le précontrôle indique que la table test.test contient des opérations Fast DDL en attente.

Pour permettre la mise à niveau, vous pouvez reconstruire la table, puis réessayer la mise à niveau.

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)

Après avoir reconstruit la table, le précontrôle aboutit.

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

Niveau de prévérification : Erreur

Tableaux avec référence d'FULLTEXTindex suspendue

Avant MySQL 5.6.26, il était possible qu'après la suppression d'un index de recherche en texte intégral, les colonnes masquées FTS_DOC_ID et les FTS_DOC_ID_INDEX colonnes deviennent orphelines. Pour plus d'informations, consultez Bug #76012.

Si cela s'est produit dans des tables créées sur des versions antérieures de MySQL, cela peut entraîner l'échec des mises à niveau vers la version 3 d'Aurora MySQL. Cette prévérification vérifie qu'aucun index de texte intégral orphelin ou « suspendu » n'existe sur votre cluster de base de données avant la mise à niveau vers MySQL 8.0. Si cette prévérification échoue, reconstruisez toutes les tables contenant de tels index de texte intégral suspendus.

Exemple de sortie :

{
  "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 prévérification signale une erreur pour le test.table_with_fts_index tableau car celui-ci contient un index de texte intégral suspendu. Pour permettre la mise à niveau, reconstruisez la table pour nettoyer les tables auxiliaires d'index en texte intégral. Utiliser OPTIMIZE TABLE test.table_with_fts_index ou ALTER TABLE test.table_with_fts_index, ENGINE=INNODB.

Après avoir reconstruit la table, le précontrôle est réussi.

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

Niveau de prévérification : Erreur

Vérifiez les incohérences liées au chemin ibd du fichier

Cette prévérification s'applique uniquement à Aurora MySQL version 3.03.0 et antérieures. Si vous rencontrez une erreur lors de cette prévérification, effectuez une mise à niveau vers Aurora MySQL version 3.04 ou supérieure.

Exemple de sortie :

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

Niveau de prévérification : Erreur

Vérifiez l'index de texte intégral avec un identifiant d'espace égal à zéro

Dans MySQL, lorsque vous ajoutez un index en texte intégral à une table InnoDB, un certain nombre de tablespaces d'index auxiliaires sont créés. En raison d'un bogue dans les versions antérieures de MySQL, corrigé dans la version 5.6.20, il est possible que ces tables d'index auxiliaires aient été créées dans le tablespace système, plutôt que dans leur propre tablespace InnoDB.

Si de tels tablespaces auxiliaires existent, la mise à niveau échouera. Recréez les index de texte intégral mentionnés dans l'erreur de prévérification, puis réessayez la mise à niveau.

Exemple de sortie :

{
  "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 prévérification signale une erreur pour la test.fts_space_zero_check table, car elle contient des tables auxiliaires de recherche en texte intégral (FTS) dans l'espace disque logique du système.

Une fois que vous avez supprimé et recréé les index FTS associés à cette table, la prévérification aboutit.

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

Niveau de prévérification : Erreur

Vérifiez les transactions XA en état de préparation

Lors de l'exécution du processus de mise à niveau de la version majeure, il est essentiel que l'instance de base de données Aurora MySQL version 2 soit complètement arrêtée. Cela garantit que toutes les transactions sont validées ou annulées, et qu'InnoDB a purgé tous les enregistrements du journal d'annulation. L'annulation des transactions étant nécessaire, si votre base de données contient des transactions XA dans un état préparé, cela peut empêcher la poursuite de l'arrêt complet. Pour cette raison, si des transactions XA préparées sont détectées, la mise à niveau ne pourra pas se poursuivre tant que vous n'aurez pas pris les mesures nécessaires pour les valider ou les annuler.

Pour plus d'informations sur la recherche de transactions XA dans un état préparé à l'aide XA RECOVER des instructions SQL de transaction XA dans la documentation MySQL. Pour plus d'informations sur les états des transactions XA, consultez les états des transactions XA dans la documentation MySQL.

Exemple de sortie :

{
  "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."
      }
  ]
}

Ce précontrôle signale une erreur car certaines transactions préparées doivent être validées ou annulées.

Une fois connecté à la base de données, vous pouvez consulter la table information_schema.innodb_trx et le résultat pour plus d'informations. XA RECOVER

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)

Dans ce cas, nous annulons la transaction préparée.

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

Une fois la transaction XA annulée, le précontrôle aboutit.

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

Niveau de prévérification : Erreur

Vérifiez si la mise à niveau est prise en charge sur la classe d'instance actuelle

L'exécution d'une mise à niveau sur place depuis Aurora MySQL version 2.12.0 ou 2.12.1, où la classe d'instance de base de données du rédacteur est db.r6i.32xlarge, n'est actuellement pas prise en charge. Dans ce cas, le précontrôle renvoie une erreur. Pour autoriser la mise à niveau, vous pouvez modifier votre classe d'instance de base de données en db.r6i.24xlarge ou en une classe inférieure. Vous pouvez également effectuer une mise à niveau vers Aurora MySQL version 2.12.2 ou supérieure, où la mise à niveau sur place vers Aurora MySQL version 3 est prise en charge sur db.r6i.32xlarge.

Exemple de sortie :

{
  "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 prévérification renvoie une erreur car l'instance de base de données du rédacteur utilise la classe d'instance db.r6i.32xlarge et s'exécute sur Aurora MySQL version 2.12.1.

Niveau de prévérification : Erreur

Vérifier la présence d'utilisateurs internes de la version 8.0

Cette prévérification s'applique uniquement à Aurora MySQL version 3.03.0 et antérieures. Si vous rencontrez une erreur lors de cette prévérification, effectuez une mise à niveau vers Aurora MySQL version 3.04 ou supérieure.

Exemple de sortie :

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

Niveau de prévérification : Erreur

Vérifiez si l'utilisateur principal RDS existe

MySQL 8 a ajouté un nouveau modèle de privilèges prenant en charge les rôles et les privilèges dynamiques afin de rendre la gestion des privilèges plus facile et plus précise. Dans le cadre de cette modification, Aurora MySQL a introduit la nouvelle versionrds_superuser_role, qui est automatiquement accordée à l'utilisateur principal de la base de données lors de la mise à niveau d'Aurora MySQL version 2 vers la version 3.

Pour plus d'informations sur les rôles et les privilèges attribués à l'utilisateur principal dans Aurora MySQL, consultezPrivilèges du compte utilisateur principal. Pour plus d'informations sur le modèle de privilèges basé sur les rôles dans Aurora MySQL version 3, consultez. Modèle de privilège basé sur les rôles

Ce précontrôle vérifie que l'utilisateur principal existe dans la base de données. Si l'utilisateur principal n'existe pas, le précontrôle échoue. Pour autoriser la mise à niveau, recréez l'utilisateur principal en réinitialisant le mot de passe de l'utilisateur principal ou en le créant manuellement. Réessayez ensuite la mise à niveau. Pour plus d'informations sur la réinitialisation du mot de passe de l'utilisateur principal, consultezModification du mot de passe de l'utilisateur principal de la base de données.

Exemple de sortie :

{
  "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 '%'"
      }
  ]
}

Une fois que vous avez réinitialisé votre mot de passe d'utilisateur principal, la prévérification est validée et vous pouvez réessayer la mise à niveau.

L'exemple suivant utilise le AWS CLI pour réinitialiser le mot de passe. Les modifications de mot de passe sont appliquées immédiatement.

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

Ensuite, le précontrôle réussit.

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

Niveau de prévérification : Erreur

Vérifiez la présence de colonnes de géométrie sur les index de préfixes

Depuis MySQL 8.0.12, il n'est plus possible de créer un index préfixé sur une colonne en utilisant le type de données GEOMETRY. Pour plus d'informations, consultez WL #11808.

Si de tels index existent, votre mise à niveau échouera. Pour résoudre le problème, supprimez les GEOMETRY index préfixés sur les tables mentionnées dans l'échec de la prévérification.

Exemple de sortie :

{
  "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 prévérification signale une erreur car la test.geom_index_prefix table contient un index avec un préfixe sur une GEOMETRY colonne.

Une fois que vous avez supprimé cet index, la prévérification aboutit.

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

Niveau de prévérification : Erreur

Vérifiez les incohérences liées aux caractères spéciaux dans les procédures stockées

Avant MySQL 8.0, les noms de base de données, les noms de tables et les autres objets correspondaient à des fichiers du répertoire de données, c'est-à-dire à des métadonnées basées sur des fichiers. Dans le cadre de la mise à niveau vers MySQL 8.0, tous les objets de base de données sont migrés vers les nouvelles tables du dictionnaire de données internes qui sont stockées dans le mysql schéma pour prendre en charge le dictionnaire de données atomique récemment implémenté. Dans le cadre de la migration des procédures stockées, la définition et le corps de chaque procédure sont validés au fur et à mesure de leur intégration dans le nouveau dictionnaire de données.

Avant MySQL 8, dans certains cas, il était possible de créer des routines stockées ou d'insérer directement dans la mysql.proc table des procédures contenant des caractères spéciaux. Par exemple, vous pouvez créer une procédure stockée contenant un commentaire contenant un espace non conforme et incassable. \xa0 Si de telles procédures sont rencontrées, la mise à niveau échoue.

Ce précontrôle vérifie que les corps et les définitions de vos procédures stockées ne contiennent pas de tels caractères. Pour permettre la mise à niveau, recréez ces procédures stockées sans aucun caractère masqué ou spécial.

Exemple de sortie :

{
  "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."
      }
  ]
}

Le précontrôle indique que le cluster de base de données contient une procédure appelée get_version_proc dans la test base de données dont le corps de la procédure contient des caractères spéciaux.

Après avoir supprimé et recréé la procédure stockée, le précontrôle réussit, permettant ainsi à la mise à niveau de se poursuivre.

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

Niveau de prévérification : Erreur

Vérifiez que le type d'objet ne correspond pas au schéma sys

Le schéma sys est un ensemble d'objets et de vues dans une base de données MySQL qui aide les utilisateurs à dépanner, optimiser et surveiller leurs instances de base de données. Lorsque vous effectuez une mise à niveau de version majeure d'Aurora MySQL version 2 vers la version 3, les vues du sys schéma sont recréées et mises à jour selon les nouvelles définitions d'Aurora MySQL version 3.

Dans le cadre de la mise à niveau, si des objets du sys schéma sont définis à l'aide de moteurs de stockage (sys_config/BASE TABLEdans INFORMATION_SCHEMA.TABLES), plutôt que de vues, la mise à niveau échouera. Ces tableaux se trouvent dans le information_schema.tables tableau. Ce comportement n'est pas attendu, mais dans certains cas, il peut se produire en raison d'une erreur de l'utilisateur.

Ce précontrôle valide tous les objets de sys schéma pour s'assurer qu'ils utilisent les bonnes définitions de table et que les vues ne sont pas définies par erreur comme des tables InnoDB ou MyISAM. Pour résoudre le problème, corrigez manuellement les objets renvoyés en les renommant ou en les supprimant. Réessayez ensuite la mise à niveau.

Exemple de sortie :

{
  "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 prévérification indique que la vue sys.waits_global_by_latency du sys schéma présente une incompatibilité de type qui empêche la mise à niveau de se poursuivre.

Une fois connecté à l'instance de base de données, vous pouvez voir que cet objet est défini comme une table InnoDB, alors qu'il devrait s'agir d'une vue.

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)

Pour résoudre ce problème, nous pouvons soit supprimer et recréer la vue avec la bonne définition, soit la renommer. Au cours du processus de mise à niveau, il sera automatiquement créé avec la bonne définition de table.

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

Après cela, le précontrôle est réussi.

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

Niveau de prévérification : Erreur

Vérifiez la limite supérieure du nom de colonne affiché

La longueur maximale autorisée d'un nom de colonne dans MySQL est de 64 caractères. Avant MySQL 8.0, dans certains cas, il était possible de créer une vue avec un nom de colonne supérieur à 64 caractères. Si de telles vues existent sur votre instance de base de données, une erreur de prévérification est renvoyée et la mise à niveau échouera. Pour permettre la mise à niveau, vous devez recréer les vues en question, en vous assurant que la longueur de leurs colonnes est inférieure à 64 caractères. Réessayez ensuite la mise à niveau.

Exemple de sortie :

{
  "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 prévérification indique que la test.colname_view_test vue contient une colonne col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad dont la longueur de colonne dépasse la longueur maximale autorisée de 64 caractères.

En regardant la définition de la vue, nous pouvons voir la colonne incriminée.

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)

Pour permettre la mise à niveau, recréez la vue en vous assurant que la longueur de la colonne ne dépasse pas 64 caractères.

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)

Après cela, le précontrôle réussit.

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

Niveau de prévérification : Erreur

Vérifiez les tables dont les index sont définis avec une longueur de préfixe supérieure à 255 octets sur de petites colonnes

Lorsque vous créez un index sur une colonne à l'aide d'un type de données binaire dans MySQL, vous devez ajouter une longueur de préfixe dans la définition de l'index. Avant MySQL 8.0, dans certains cas, il était possible de spécifier une longueur de préfixe supérieure à la taille maximale autorisée pour ces types de données. Prenons l'exemple TINYTEXT des TINYBLOB colonnes, où la taille de données maximale autorisée est de 255 octets, mais où les préfixes d'index supérieurs à cette valeur étaient autorisés. Pour plus d'informations, consultez les limites d'InnoDB dans la documentation MySQL.

Si cette prévérification échoue, supprimez l'index incriminé ou réduisez la longueur du préfixe TINYTEXT et des TINYBLOB colonnes de l'index à moins de 255 octets. Réessayez ensuite la mise à niveau.

Exemple de sortie :

{
  "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 prévérification signale une erreur pour la test.tintxt_prefixed_index table, car elle contient un index PRIMARY dont le préfixe est supérieur à 255 octets sur une colonne TINYTEXT ou TINYBLOB.

En regardant la définition de ce tableau, nous pouvons voir que la clé primaire a un préfixe de 65 sur la TINYTEXT colonnecol1. Comme la table est définie à l'aide du jeu de utf8mb4 caractères, qui stocke 4 octets par caractère, le préfixe dépasse la limite de 255 octets.

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)

La modification du préfixe d'index à 63 lors de l'utilisation du jeu de utf8mb4 caractères permettra à la mise à niveau de se poursuivre.

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

Après cela, le précontrôle réussit.

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

Niveau de prévérification : Erreur

Vérifiez l'incohérence des métadonnées InnoDB manquantes pour la table mysql.host

Il s'agit d'un précontrôle interne uniquement effectué par le service RDS. Toute erreur sera automatiquement traitée lors de la mise à niveau et pourra être ignorée en toute sécurité.

Si vous rencontrez des erreurs lors de cette prévérification, ouvrez un dossier auprès du AWS Support pour demander que l'incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en effectuant un vidage logique, puis en effectuant une restauration vers un nouveau cluster de base de données Aurora MySQL version 3.

Niveau de prévérification : Erreur

Vérifier la présence de commentaires de colonne utf8mb3 non valides

Cette prévérification identifie les tables contenant des commentaires de colonne dont le codage de caractères utf8mb3 n'est pas valide. Dans MySQL 8.0, une validation plus stricte est appliquée au codage des caractères dans les métadonnées, y compris les commentaires de colonne. Si des commentaires de colonne contiennent des caractères non valides dans le jeu de caractères utf8mb3, la mise à niveau échouera.

La cause la plus courante de ce problème est la présence de caractères non BMP (Basic Multilingual Plane) dans les commentaires des colonnes. Les caractères non BMP nécessitent un codage UTF-8 sur 4 octets (utf8mb4), mais utf8mb3 ne prend en charge que les séquences de 3 octets, qui ne peuvent pas représenter ces caractères.

Pour résoudre ce problème, vous devez modifier les commentaires des colonnes afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau. Vous pouvez utiliser l'ALTER TABLEinstruction pour mettre à jour les commentaires des colonnes.

Exemple de sortie :

{
  "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 prévérification indique que le test.t2 tableau contient des caractères utf8mb3 non valides dans un ou plusieurs commentaires de colonne, notamment en raison de la présence de caractères non BMP.

Pour résoudre ce problème, vous pouvez identifier les colonnes problématiques et mettre à jour leurs commentaires. Examinez d'abord la structure du tableau pour identifier les colonnes contenant des commentaires :

mysql> SHOW CREATE TABLE test.t2\G

Une fois que vous avez identifié les colonnes contenant des commentaires problématiques, mettez-les à jour à l'aide de l'ALTER TABLEinstruction. Par exemple :

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

Vous pouvez également supprimer complètement le commentaire :

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

Après avoir mis à jour tous les commentaires de colonne problématiques, la prévérification sera validée et la mise à niveau pourra se poursuivre :

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

Niveau de prévérification : Avertissement

Considérations relatives au nouveau plugin d'authentification par défaut

Dans MySQL 8.0, le plugin caching_sha2_password d'authentification a été introduit, fournissant un cryptage des mots de passe plus sécurisé et de meilleures performances que le plugin obsolète. mysql_native_password Pour Aurora MySQL version 3, le plugin d'authentification par défaut utilisé par les utilisateurs de base de données est le mysql_native_password plugin.

Cette prévérification indique que ce plugin sera supprimé et que sa valeur par défaut sera modifiée dans une future version majeure. Envisagez d'évaluer la compatibilité des clients et des utilisateurs de votre application avant cette modification.

Pour plus d'informations, consultez les problèmes de compatibilité avec caching_sha2_password et leurs solutions dans la documentation MySQL.

Exemple de sortie :

{
  "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"
},

Niveau de prévérification : Avertissement

Utilisation d'un MAXDB sql_mode drapeau obsolète

Dans MySQL 8.0, un certain nombre d'options de variables système sql_mode obsolètes ont été supprimées, dont l'une était. MAXDB Cette prévérification examine toutes les sessions actuellement connectées, ainsi que les routines et les déclencheurs, pour s'assurer qu'aucune d'entre elles n'est sql_mode définie sur une combinaison incluantMAXDB.

Exemple de sortie :

{
  "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"
      }
  ]
}

Le précontrôle indique que la test.maxdb_stored_routine routine contient une option non prise en chargesql_mode.

Une fois connecté à la base de données, vous pouvez le voir dans la définition de routine qui sql_mode contientMAXDB.

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

Pour résoudre le problème, recréez la procédure après avoir défini la bonne configuration sql_mode sur le client.

Recréez la procédure sans les éléments non pris en charge. sql_mode

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)

Le précontrôle aboutit.

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

Niveau de prévérification : Avertissement

Vérifiez l'utilisation déconseillée des signes d'un dollar dans les noms d'objets

Depuis MySQL 8.0.32, l'utilisation du signe dollar ($) comme premier caractère d'un identifiant sans guillemets est obsolète. Si vous avez des schémas, des tables, des vues, des colonnes ou des routines contenant un $ comme premier caractère, cette prévérification renvoie un avertissement. Bien que cet avertissement n'empêche pas la mise à niveau de se poursuivre, nous vous recommandons de prendre rapidement des mesures pour résoudre ce problème. À partir de MySQL 8.4, tout identifiant de ce type renverra une erreur de syntaxe plutôt qu'un avertissement.

Exemple de sortie :

{
  "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 prévérification signale un avertissement car le $deprecated_syntx tableau du test schéma contient un $ comme premier caractère.

Niveau de prévérification : Avertissement

Utilisation d'objets de base de données dont les noms sont en conflit avec les nouveaux mots clés réservés

Cette vérification est similaire à la vérification routineSyntaxCheck, dans la mesure où elle vérifie l'utilisation d'objets de base de données dont les noms sont en conflit avec les nouveaux mots clés réservés. Bien qu'ils ne bloquent pas les mises à niveau, vous devez évaluer attentivement les avertissements.

Exemple de sortie :

En utilisant l'exemple précédent avec le nom de la tableexcept, le précontrôle renvoie un avertissement :

{
  "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"
      }
  ]
}

Cet avertissement vous indique qu'il est possible que certaines requêtes relatives à l'application soient à examiner. Si les requêtes de votre application n'échappent pas correctement aux chaînes littérales, elles risquent de rencontrer des erreurs après la mise à niveau vers MySQL 8.0. Passez en revue vos applications pour confirmer, en les testant par rapport à un clone ou à un instantané de votre cluster de base de données Aurora MySQL exécuté sur la version 3.

Exemple de requête d'application non échappée qui échouera après la mise à niveau :

SELECT * FROM escape;

Exemple de requête d'application correctement échappée qui aboutira après la mise à niveau :

SELECT * FROM 'escape';

Niveau de prévérification : Avertissement

Utilisation du jeu de utf8mb3 caractères

Dans MySQL 8.0, le jeu de utf8mb3 caractères est obsolète et sera supprimé dans une future version majeure de MySQL. Cette prévérification est mise en œuvre pour émettre un avertissement si des objets de base de données utilisant ce jeu de caractères sont détectés. Cela n'empêchera pas la mise à niveau de se poursuivre, mais nous vous recommandons vivement de penser à migrer les tables vers le jeu de utf8mb4 caractères, qui est le jeu de caractères par défaut depuis MySQL 8.0. Pour plus d'informations sur utf8mb3 et utf8mb4, consultez la section Conversion entre des jeux de caractères Unicode de 3 octets et de 4 octets dans la documentation MySQL.

Exemple de sortie :

{
  "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"
      }
  ]
}

Pour résoudre ce problème, vous devez reconstruire les objets et les tables référencés. Pour plus d'informations et pour connaître les conditions préalables, consultez la section Conversion entre des jeux de caractères Unicode de 3 octets et de 4 octets dans la documentation MySQL.

Niveau de prévérification : Avertissement

Aucune valeur de date, de date/heure et d'horodatage

MySQL applique désormais des règles plus strictes concernant l'utilisation de valeurs nulles dans les colonnes date, datetime et timestamp. Nous vous recommandons d'utiliser les NO_ZERO_DATE SQL modes NO_ZERO_IN_DATE et conjointement avec le strict mode, car ils seront fusionnés avec le strict mode dans une future version de MySQL.

Si le sql_mode paramètre de l'une de vos connexions à la base de données, au moment de l'exécution de la prévérification, n'inclut pas ces modes, un avertissement est émis lors de la prévérification. Les utilisateurs peuvent toujours insérer des valeurs de date, de dateheure et d'horodatage contenant des valeurs nulles. Cependant, nous vous conseillons vivement de remplacer les valeurs nulles par des valeurs valides, car leur comportement pourrait changer à l'avenir et elles pourraient ne pas fonctionner correctement. Comme il s'agit d'un avertissement, il ne bloquera pas les mises à niveau, mais nous vous recommandons de commencer à planifier des actions.

Exemple de sortie :

{
  "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"
      }
  ]
}

Niveau de prévérification : Avertissement

Vérifie si la longueur de la liste d'historique des segments de restauration pour le cluster est élevée

Comme indiqué dans auroraUpgradeCheckForIncompleteXATransactions, lors de l'exécution du processus de mise à niveau de la version majeure, il est essentiel que l'instance de base de données Aurora MySQL version 2 soit complètement arrêtée. Cela garantit que toutes les transactions sont validées ou annulées, et qu'InnoDB a purgé tous les enregistrements du journal d'annulation.

Si la longueur de la liste d'historique des segments (HLL) de votre cluster de base de données est élevée, cela peut prolonger le temps nécessaire à InnoDB pour purger les enregistrements du journal d'annulation, ce qui peut entraîner une interruption prolongée pendant le processus de mise à niveau de la version majeure. Si le précontrôle détecte que le HLL de votre cluster de base de données est élevé, il émet un avertissement. Bien que cela n'empêche pas votre mise à niveau de se poursuivre, nous vous recommandons de surveiller de près le HLL sur votre cluster de base de données. Le maintenir à de faibles niveaux réduit les temps d'arrêt requis lors d'une mise à niveau majeure d'une version. Pour plus d'informations sur la surveillance du HLL, consultezLa longueur de la liste d'historique InnoDB a considérablement augmenté.

Exemple de sortie :

{
  "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 prévérification renvoie un avertissement car elle a détecté que le HLL d'annulation d'InnoDB était élevé sur le cluster de bases de données (82989114). Bien que la mise à niveau se poursuive, en fonction du nombre d'annulations à purger, elle peut prolonger le temps d'arrêt requis pendant le processus de mise à niveau.

Nous vous recommandons d'examiner les transactions ouvertes sur votre cluster de base de données avant d'exécuter la mise à niveau en production, afin de vous assurer que votre HLL reste à une taille gérable.

Niveau de prévérification : Avertissement

Vérifie s'il existe de nombreuses modifications de ligne non validées

Comme indiqué dans auroraUpgradeCheckForIncompleteXATransactions, lors de l'exécution du processus de mise à niveau de la version majeure, il est essentiel que l'instance de base de données Aurora MySQL version 2 soit complètement arrêtée. Cela garantit que toutes les transactions sont validées ou annulées, et qu'InnoDB a purgé tous les enregistrements du journal d'annulation.

Si votre cluster de base de données contient des transactions qui ont modifié un grand nombre de lignes, cela peut prolonger le temps nécessaire à InnoDB pour annuler cette transaction dans le cadre du processus d'arrêt complet. Si le précontrôle détecte des transactions de longue durée comportant un grand nombre de lignes modifiées sur votre cluster de bases de données, un avertissement s'affiche. Bien que cela n'empêche pas votre mise à niveau de se poursuivre, nous vous recommandons de surveiller de près la taille des transactions actives sur votre cluster de bases de données. Le maintenir à de faibles niveaux réduit les temps d'arrêt requis lors d'une mise à niveau majeure d'une version.

Exemple de sortie :

{
  "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."
      }
  ]
},

Le précontrôle indique que le cluster de base de données contient une transaction contenant 11 000 000 de modifications de lignes non validées qui devront être annulées pendant le processus d'arrêt complet. La mise à niveau va se poursuivre, mais pour réduire les temps d'arrêt pendant le processus de mise à niveau, nous vous recommandons de surveiller et d'étudier cette question avant d'exécuter la mise à niveau sur vos clusters de production.

Pour afficher les transactions actives sur votre instance de base de données Writer, vous pouvez utiliser la table information_schema.innodb_trx. La requête suivante sur l'instance de base de données Writer indique les transactions en cours, la durée d'exécution, l'état et les lignes modifiées pour le cluster de base de données.

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

Une fois la transaction validée ou annulée, le précontrôle ne renvoie plus d'avertissement. Consultez la documentation MySQL et l'équipe de votre application avant d'annuler des transactions importantes, car la restauration peut prendre un certain temps, en fonction de la taille de la transaction.

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

Pour plus d'informations sur l'optimisation de la gestion des transactions InnoDB et sur l'impact potentiel de l'exécution et de l'annulation de transactions importantes sur les instances de base de données MySQL, consultez Optimisation de la gestion des transactions InnoDB dans la documentation MySQL.

Niveau de prévérification : Remarque

Utilisation de sql_mode drapeaux obsolètes

En outreMAXDB, un certain nombre d'autres sql_mode options ont été supprimées : DB2MSSQL,MYSQL323, MYSQL40ORACLE,POSTGRESQL,NO_FIELD_OPTIONS,NO_KEY_OPTIONS, etNO_TABLE_OPTIONS. Depuis MySQL 8.0, aucune de ces valeurs ne peut être affectée à la variable sql_mode système. Si cette prévérification détecte des sessions ouvertes utilisant ces sql_mode paramètres, assurez-vous que les groupes de paramètres de votre instance de base de données et de cluster de base de données, ainsi que les applications et configurations clientes, sont mis à jour pour les désactiver.- Pour plus d'informations, consultez la documentation MySQL.

Exemple de sortie :

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

Pour résoudre l'un de ces échecs de précontrôle, consultez maxdbFlagCheck.

Niveau de prévérification : erreur, avertissement ou avis

Problèmes signalés par la check table x for upgrade commande

Avant de commencer la mise à niveau vers Aurora MySQL version 3, elle check table for upgrade est exécutée sur chaque table des schémas utilisateur de votre cluster de base de données. Cette prévérification n'est pas identique à checkTableMysqlSchema.

La check table for upgrade commande examine les tables pour détecter tout problème potentiel pouvant survenir lors d'une mise à niveau vers une version plus récente de MySQL. L'exécution de cette commande avant de tenter une mise à niveau peut aider à identifier et à résoudre les incompatibilités à l'avance, ce qui facilite le processus de mise à niveau proprement dit.

Cette commande effectue différentes vérifications sur chaque table, telles que les suivantes :

Contrairement aux autres prévérifications, il peut renvoyer une erreur, un avertissement ou une notification en fonction de la check table sortie. Si cette prévérification renvoie des tables, examinez-les attentivement, ainsi que le code de retour et le message, avant de lancer la mise à niveau. Pour plus d'informations, consultez l'instruction CHECK TABLE dans la documentation MySQL.

Nous fournissons ici un exemple d'erreur et un exemple d'avertissement.

Exemple d'erreur :

{
  "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 prévérification signale une erreur indiquant que la test.parent table n'existe pas.

Le mysql-error.log fichier de l'instance de base de données Writer indique qu'il existe une erreur de clé étrangère.

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.

Connectez-vous à l'instance de base de données Writer et exécutez show engine innodb status\G pour obtenir plus d'informations sur l'erreur de clé étrangère.

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

Le LATEST FOREIGN KEY ERROR message indique que la contrainte de clé fk_pname étrangère dans la test.child table, qui fait référence à la test.parent table, comporte un index manquant ou une incompatibilité du type de données. La documentation MySQL sur les contraintes liées aux clés étrangères indique que les colonnes référencées dans une clé étrangère doivent avoir un index associé, et que les colonnes parent/enfant doivent utiliser le même type de données.

Pour vérifier si cela est lié à un index manquant ou à une incompatibilité de type de données, connectez-vous à la base de données et vérifiez les définitions des tables en désactivant temporairement la variable de session foreign_key_checks. Après cela, nous pouvons voir que la contrainte enfant en question (fk_pname) fait référence p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL à la table parentname varchar(20) NOT NULL. La table parent l'utiliseDEFAULT CHARSET=utf8, mais la p_name colonne de la table enfant l'utiliselatin1, de sorte que l'erreur de non-concordance du type de données est renvoyée.

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)

Pour résoudre ce problème, nous pouvons soit modifier la table enfant pour qu'elle utilise le même jeu de caractères que la table parent, soit modifier la table parent pour qu'elle utilise le même jeu de caractères que la table enfant. Ici, comme la table enfant l'utilise explicitement latin1 dans la définition de p_name colonne, nous exécutons ALTER TABLE pour modifier le jeu de caractères surutf8.

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)

Après cela, le précontrôle est réussi et la mise à niveau peut se poursuivre.

Exemple d'avertissement :

{
  "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 prévérification signale un avertissement concernant le delete_audit_trigg déclencheur sur la test.orders table car celui-ci ne possède pas d'CREATEDattribut. Selon la section Vérification de la compatibilité des versions dans la documentation MySQL, ce message est informatif et est imprimé pour les déclencheurs créés avant MySQL 5.7.2.

Comme il s'agit d'un avertissement, il n'empêche pas la mise à niveau de se poursuivre. Toutefois, si vous souhaitez résoudre le problème, vous pouvez recréer le déclencheur en question, et le précontrôle aboutit sans avertissement.

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