Référence des vérifications préalables avec description pour Aurora MySQL - Amazon Aurora
ErreursAvertissementsNotificationsErreurs, avertissements ou notifications

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Référence des vérifications préalables avec description pour Aurora MySQL

Les vérifications préalables de mise à niveau pour Aurora MySQL sont décrites ici en détail.

Erreurs

Les vérifications préalables suivantes génèrent des erreurs lorsque la vérification préalable échoue et que la mise à niveau ne peut pas avoir lieu.

Vérifications préalables de MySQL qui signalent des erreurs

Les vérifications préalables suivantes sont tirées de Community MySQL :

checkTableMysqlSchema

Niveau de vérification préalable : erreur

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

Avant de démarrer la mise à niveau vers Aurora MySQL version 3, check table for upgrade est exécuté sur chaque table du schéma mysql de l’instance de base de données. La commande check table for upgrade 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 contribue à identifier et à résoudre les incompatibilités à l’avance, ce qui facilite le processus de mise à niveau réel.

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

  • Vérification de la compatibilité de la structure et des métadonnées de la table avec la version MySQL cible

  • Identification des fonctionnalités obsolètes ou supprimées qui sont utilisées par la table

  • Confirmation de la possibilité de mettre à niveau la table sans perte de données

Pour plus d’informations, consultez 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 vérification préalable dépend de l’erreur rencontrée et du moment où elle est détectée, car check table for upgrade effectue plusieurs vérifications.

Si vous rencontrez des erreurs lors de cette vérification préalable, ouvrez une demande d’assistance auprès d’AWS Support pour que l’incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en procédant à un vidage logique, puis en effectuant une restauration sur un nouveau cluster de bases de données Aurora MySQL version 3.

circularDirectoryCheck

Niveau de vérification préalable : erreur

Références circulaires à des répertoires dans les chemins de fichiers de données des espaces de table

Depuis MySQL 8.0.17, la clause CREATE TABLESPACE ... ADD DATAFILE 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 circulaires à des répertoires dans les 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 vous recevez cette erreur, reconstruisez vos tables à l’aide d’un espace de table de fichier par table. Utilisez les chemins de fichier par défaut pour tous les espaces de table et toutes les définitions de tables.

Note

Aurora MySQL ne prend pas en charge les espaces de table généraux ni les commandes CREATE TABLESPACE.

Avant de reconstruire les espaces de table, consultez Online DDL operations dans la documentation MySQL pour comprendre les effets du verrouillage et du déplacement des données sur les transactions de premier plan.

Après la reconstruction, la vérification préalable aboutit, ce qui permet à la mise à niveau d’avoir lieu.

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

Niveau de vérification préalable : erreur

Colonnes ne pouvant pas avoir de valeur par défaut

Avant MySQL 8.0.13, les colonnes BLOB, TEXT, GEOMETRY et JSON ne pouvaient pas avoir de valeur par défaut. Supprimez toutes les clauses par défaut sur ces colonnes avant de procéder à la mise à niveau vers 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 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 vérification préalable renvoie une erreur, car la colonne geo_col de la table test.test_blob_default utilise un type de données BLOB, TEXT, GEOMETRY ou JSON avec une valeur par défaut spécifiée.

En regardant la définition de la table, nous pouvons voir que la colonne geo_col est définie comme geo_col geometry NOT NULL default ''.

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

Supprimez cette clause par défaut pour permettre à la vérification préalable d’aboutir.

Note

Avant d’exécuter des instructions ALTER TABLE ou de reconstruire des espaces de table, consultez Opérations DDL en ligne dans la documentation MySQL pour comprendre les effets du verrouillage et du déplacement des données sur les transactions de premier plan.

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 vérification préalable aboutit. Vous pouvez donc réessayer la mise à niveau.

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

Niveau de vérification préalable : 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 mots clés QUERY CACHE, SQL_CACHE ou SQL_NO_CACHE, une erreur de vérification préalable 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"
      }
  ]
}

La vérification préalable indique que la procédure stockée test.no_query_cache_check utilise l’un des mots clés supprimés. En regardant la définition de la procédure, nous pouvons voir qu’elle utilise SQL_NO_CACHE.

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

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 vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

Tables reconnues par InnoDB et qui appartiennent à un autre moteur

Semblable à schemaInconsistencyCheck, cette vérification préalable s’assure 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 vérification préalable, ouvrez une demande d’assistance auprès d’AWS Support pour que l’incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en procédant à un vidage logique, puis en effectuant une restauration sur un nouveau cluster de bases 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"
      }
  ]
}
enumSetElementLengthCheck

Niveau de vérification préalable : erreur

Définitions de colonnes ENUM et SET contenant des éléments de plus de 255 caractères

Les tables et les procédures stockées ne doivent pas comporter d’éléments de colonne ENUM ou SET de plus de 255 caractères ou 1 020 octets. Avant MySQL 8.0, la longueur combinée maximale était de 64K, mais la version 8.0 limite les éléments individuels à 255 caractères ou 1 020 octets (en prenant en charge les multioctets). En cas d’échec de la vérification préalable pour enumSetElementLengthCheck, 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 vérification préalable signale une erreur, car la colonne s dans la table test.large_set contient un élément SET de plus de 255 caractères.

Après avoir réduit la taille SET de cette colonne, la vérification préalable aboutit, ce qui permet à la mise à niveau d’avoir lieu.

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

Niveau de vérification préalable : erreur

Noms de contrainte de clé étrangère dépassant 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 où la longueur des clés étrangères pouvait être égale ou supérieure à cette valeur, entraînant des échecs de mise à niveau, cette vérification préalable a été mise en œuvre. Si vous rencontrez des erreurs lors de cette vérification préalable, 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": []
}
getDuplicateTriggers

Niveau de vérification préalable : 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 sensibles à la casse dans une base de données. Cette vérification préalable s’assure que votre cluster de bases de données ne possède pas de bases de données contenant des déclencheurs dupliqués. Pour plus d’informations, consultez Sensibilité à la casse des identifiants 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 vérification préalable signale une erreur indiquant que le cluster de bases de données a deux déclencheurs portant le même nom, mais dans avec une casse différente : test.before_insert_product et test.before_insert_PRODUCT.

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

Une fois que le nom test.before_insert_PRODUCT est remplacé par test.before_insert_product_2, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

La colonne DEFINER pour mysql.event ne peut pas être nulle ou vide.

L’attribut DEFINER 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é. Lorsque vous créez un objet stocké, si DEFINER n’est pas spécifié, sa 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 attribut DEFINER null ou vide dans le dictionnaire de données MySQL. Si vous avez des objets stockés de ce type, une erreur de vérification préalable sera générée. Vous devrez la corriger avant de pouvoir 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 vérification préalable renvoie une erreur pour l’événement test.get_version, car celui-ci possède un attribut DEFINER null.

Pour résoudre ce problème, vous pouvez vérifier la définition de l’événement. Comme vous pouvez le constater, l’attribut DEFINER est 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 attribut DEFINER valide.

Note

Avant de supprimer ou de redéfinir un DEFINER, examinez attentivement votre demande et vérifiez les exigences en matière de privilèges. Pour plus d’informations, consultez Stored object access control dans la documentation MySQL.

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, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

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

Semblable à schemaInconsistencyCheck, cette vérification préalable s’assure que les métadonnées des tables dans MySQL sont cohérentes avant de procéder à la mise à niveau. Dans ce cas, la vérification préalable s’assure 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 n’a pas lieu.

Si vous rencontrez des erreurs lors de cette vérification préalable, ouvrez une demande d’assistance auprès d’AWS Support pour que l’incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en procédant à un vidage logique, puis en effectuant une restauration sur un nouveau cluster de bases 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 vérification préalable signale une incohérence des métadonnées dans la colonne id de la table test.mismatchTable. Plus précisément, les métadonnées MySQL utilisent le nom de colonne iD, tandis qu’InnoDB utilise le nom de colonne id.

getTriggersWithNullDefiner

Niveau de vérification préalable : erreur

La colonne DEFINER pour information_schema.triggers ne peut pas être null ou vide.

La vérification préalable s’assure que votre base de données ne possède aucun déclencheur défini avec un attribut DEFINER null ou vide. Pour plus d’informations sur les exigences relatives à l’attribut DEFINER 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 vérification préalable renvoie une erreur, car l’attribut DEFINER du déclencheur example_trigger du schéma test est null. Pour corriger ce problème, corrigez cet attribut en recréant le déclencheur avec un utilisateur valide, ou supprimez le déclencheur. Pour plus d’informations, consultez l’exemple dans getEventsWithNullDefiner.

Note

Avant de supprimer ou de redéfinir un DEFINER, examinez attentivement votre demande et vérifiez les exigences en matière de privilèges. Pour plus d’informations, consultez Stored object access control dans la documentation MySQL.

getValueOfVariablelower_case_table_names

Niveau de vérification préalable : erreur

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

Avant MySQL 8.0, les noms de base de données, les noms de table 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 sensibilité à la casse des identifiants pour les objets de base de données et le stockage de ces objets de métadonnées. Ce paramètre pouvait ê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 sensibilité à la casse, 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, la valeur définie pour lower_case_table_names 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 à partir de métadonnées basées sur des fichiers vers des tables InnoDB internes du schéma mysql.

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

Pour éviter les problèmes lors de la mise à niveau quand les métadonnées basées sur des fichiers sont migrées vers le nouveau dictionnaire Atomic Data Dictionary, cette vérification préalable permet de s’assurer que toutes les tables sont stockées sur le disque en minuscules quand lower_case_table_names = 1. Si ce n’est pas le cas, une erreur de vérification préalable est renvoyée et vous devrez 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 la table test.TEST contient des majuscules alors que lower_case_table_names est défini sur 1.

Pour résoudre ce problème, vous pouvez modifier le nom de la table pour qu’il soit en minuscules ou modifier le paramètre lower_case_table_names sur le cluster de bases de données avant de démarrer la mise à niveau.

Note

Testez et examinez attentivement la documentation sur la sensibilité à la casse dans MySQL et sur la manière dont ce type de changements pourrait affecter votre application.

Consultez également la documentation de MySQL 8.0 pour déterminer les différences liées à la gestion de lower_case_table_names dans MySQL 8.0.

groupByAscSyntaxCheck

Niveau de vérification préalable : erreur

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

Depuis MySQL 8.0.13, la syntaxe ASC ou DESC obsolète pour les clauses GROUP BY a été supprimée. Les requêtes basées sur le tri GROUP BY peuvent désormais générer des résultats différents. Pour obtenir un ordre de tri spécifique, utilisez plutôt une clause ORDER BY. Si des objets utilisent cette syntaxe dans votre base de données, vous devrez les recréer à l’aide d’une clause ORDER BY avant de réessayer la mise à niveau. Pour plus d’informations, consultez Modifications 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"
      }
  ]
}
mysqlEmptyDotTableSyntaxCheck

Niveau de vérification préalable : erreur

Rechercher l’utilisation de la syntaxe .<table> obsolète 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 stockés contiennent ce type d’identifiants, la mise à niveau échouera. Par exemple, la référence .dot_table 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 et les caractères d’échappement corrects, la vérification préalable aboutit et la mise à niveau peut avoir lieu. Pour plus d’informations, consultez Noms des objets de schéma dans la documentation PostgreSQL.

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

Une fois que vous avez corrigé la routine, la vérification préalable aboutit et vous pouvez réessayer la mise à niveau.

mysqlIndexTooLargeCheck

Niveau de vérification préalable : erreur

Rechercher les index qui sont trop volumineux 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 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 vérification préalable identifie les index incriminés qui devront ê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 vérification préalable renvoie une erreur, car la table test.table_with_large_idx 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 actions suivantes :

  • Supprimez l’index mentionné dans la vérification préalable.

  • Ajoutez un index mentionné dans la vérification préalable.

  • Modifiez le format de ligne utilisé par la table.

Dans ce cas, nous reconstruirons la table pour résoudre l’échec de la vérification préalable. Avant de reconstruire la table, assurez-vous qu’innodb_file_format est défini sur Barracuda et qu’innodb_default_row_format est défini sur dynamic. Ce sont les valeurs par défaut dans MySQL 5.7. Pour plus d’informations, consultez Formats de ligne InnoDB et Gestion des formats de fichier InnoDB dans la documentation MySQL.

Note

Avant de reconstruire les espaces de table, consultez Online DDL operations dans la documentation MySQL pour comprendre les effets du verrouillage et du déplacement des données sur les transactions de premier plan.

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, la vérification préalable aboutit et la mise à niveau peut avoir lieu.

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

Niveau de vérification préalable : erreur

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

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

Note

Assurez-vous d’utiliser une version MySQL 5.7 de mysqlcheck, car --fix-db-names et --fix-table-names ont été supprimés de MySQL 8.0.

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

La vérification préalable indique que le schéma #mysql50#fix_db_names n’est pas valide.

Après avoir corrigé le nom du schéma, la vérification préalable aboutit, 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": []
},
mysqlOrphanedRoutinesCheck

Niveau de vérification préalable : erreur

Rechercher 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. Cette vérification préalable s’assure 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 permettre à la mise à niveau de se poursuivre, 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"
      }
  ]
},

La vérification préalable indique que la procédure stockée get_version dans la base de données dropped_db 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 supprimer la procédure pour permettre à la mise à niveau de se poursuivre.

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

Niveau de vérification préalable : erreur

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

Le nouveau dictionnaire Atomic Data Dictionary introduit dans MySQL 8.0 stocke toutes les métadonnées dans un ensemble de tables InnoDB internes du schéma mysql. Au cours de la mise à niveau, les nouvelles tables du dictionnaire de données interne sont créées dans le schéma mysql. Pour éviter les conflits de noms, qui pourraient entraîner des échecs de mise à niveau, la vérification préalable examine tous les noms de table du schéma mysql 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 schéma mysql. Il s’agit de l’un des nouveaux noms de tables du dictionnaire de données interne de MySQL 8.0. Vous devrez renommer ou supprimer ces tables avant de procéder à la mise à niveau, à l’aide de la commande RENAME TABLE.

nonNativePartitioningCheck

Niveau de vérification préalable : erreur

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

Selon la documentation MySQL 8.0, deux moteurs de stockage prennent actuellement en charge le partitionnement natif : InnoDB et NDB. Parmi eux, seul InnoDB est pris en charge dans Aurora MySQL version 3, 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 échouera. Cette vérification préalable recherche les tables de votre cluster de bases de données qui utilisent un partitionnement non natif. Le cas échéant, vous devrez supprimer le partitionnement ou remplacer le moteur de stockage par 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. Une action est donc nécessaire avant que la mise à niveau puisse commencer.

oldTemporalCheck

Niveau de vérification préalable : erreur

Utilisation du type « anciens temporels »

Les « anciens temporels » font référence aux colonnes de type temporel (comme TIMESTAMP et DATETIME) créées dans les versions 5.5 et antérieures de MySQL. Dans MySQL 8.0, la prise en charge de ces types de données « anciens temporels » 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 en contient encore. Pour résoudre ce problème, vous devez reconstruire toutes les tables contenant ces types de données « anciens temporels » avant de procéder à la mise à niveau.

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

Note

Avant de reconstruire les espaces de table, consultez Online DDL operations dans la documentation MySQL pour comprendre les effets du verrouillage et du déplacement des données sur les transactions de premier plan.

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 de la table test.55_temporal_table, car elle utilise un format de stockage sur disque ancien temporel qui n’est plus pris en charge.

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

L’exécution de la commande suivante pour reconstruire les tables mentionnées dans cette vérification préalable convertit les types de données « anciens 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 Instruction ALTER TABLE dans la documentation MySQL.

Après avoir reconstruit la table en question et redémarré la mise à niveau, la vérification de la compatibilité aboutit, ce qui permet à la mise à niveau de se poursuivre.

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

Niveau de vérification préalable : erreur

Utilisation de tables partitionnées dans les espaces de table partagés

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

Note

Avant de reconstruire les espaces de table, consultez Partitioning operations dans la documentation MySQL pour comprendre les effets du verrouillage et du déplacement des données sur les transactions de premier plan.

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 vérification préalable échoue, car la partition p1 de la table test.partInnoDBTable se trouve dans l’espace de table du système.

Pour résoudre ce problème, reconstruisez la table test.partInnodbTable en plaçant la partition p1 en cause dans un espace de table de fichier par table.

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

Après cela, la vérification préalable aboutira.

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

Niveau de vérification préalable : erreur

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

Dans MySQL 8.0, plusieurs fonctions intégrées ont été supprimées. Cette vérification préalable examine votre base de données à la recherche d’objets susceptibles d’utiliser ces fonctions. Si elle en trouve, une erreur est renvoyée. Vous devrez résoudre ces 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 fonctions ST_* équivalentes. Dans ce cas, modifiez les objets de base de données pour qu’ils utilisent le nom de la nouvelle procédure. Pour plus d’informations, 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"
      }
  ]
},

La vérification préalable indique que la procédure stockée test.GetLocationsInPolygon utilise deux fonctions supprimées : POLYGONFROMTEXT et POINTFROMTEXT. Elle suggère également d’utiliser les nouvelles fonctions ST_POLYGONFROMTEXT et ST_POINTFROMTEXT à la place. Après avoir recréé la procédure à l’aide des suggestions, la vérification préalable aboutit.

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

Bien que, dans la plupart des cas, les fonctions obsolètes soient directement remplacées, assurez-vous de tester votre application et de consulter la documentation pour détecter tout changement de comportement résultant de ce changement.

routineSyntaxCheck

Niveau de vérification préalable : erreur

Recherche d’objets de type routine dans la syntaxe MySQL

MySQL 8.0 a introduit des mots clés réservés qui ne l’étaient pas auparavant. La vérification préalable à la mise à niveau évalue l’utilisation des mots clés réservés dans les noms des objets de base de données, dans leurs définitions et dans leur corps. Si elle 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 fichier upgrade-prechecks.log. 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’échappement des mots réservés dans MySQL, consultez Littéraux de chaîne dans la documentation MySQL.

Vous pouvez également remplacer le nom par un autre, ce qui peut impliquer 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ée except, qui est un nouveau mot clé dans MySQL 8.0. Recréez la procédure en échappant le littéral de la chaîne.

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

Désormais, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

Incohérences de schéma résultant de la suppression ou de l’endommagement 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 schéma mysql. 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 de « DDL atomique » rencontré par 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 de l’Atomic Data Dictionary 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 vérification préalable schemaInconsistencyCheck 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 vérification préalable, ouvrez une demande d’assistance auprès d’AWS Support pour que l’incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en procédant à un vidage logique, puis en effectuant une restauration sur un nouveau cluster de bases 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"
      }
  ]
}

La vérification préalable indique que les métadonnées de la table test.schemaInconsistencyCheck_failure 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).

Vérifications préalables d’Aurora MySQL qui signalent des erreurs

Les vérifications préalables suivantes sont spécifiques à Aurora MySQL :

auroraCheckDDLRecovery

Niveau de vérification préalable : erreur

Rechercher la présence d’artefacts liés à la fonctionnalité 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 transit sont conservées dans les tables ddl_log_md_table et ddl_log_table 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 l’implémentation du nouvel Atomic Data Dictionary dans MySQL 8.0. Si des instructions DDL sont en cours d’exécution pendant les vérifications de la compatibilité, cette vérification préalable risque d’échouer. Nous vous recommandons d’essayer la mise à niveau quand aucune instruction DDL n’est en cours d’exécution.

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

Si des instructions DDL sont en cours d’exécution, la sortie de la vérification préalable 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."
      }
  ]
}

La vérification préalable a renvoyé une erreur en raison d’une instruction DDL en transit exécutée en même temps que les vérifications de la compatibilité. Nous vous recommandons de réessayer la mise à niveau sans qu’aucune instruction DDL ne soit active.

auroraCheckRdsUpgradePrechecksTable

Niveau de vérification préalable : erreur

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

Il s’agit d’une vérification préalable interne, qui est effectuée par le service RDS. Toutes les erreurs seront traitées automatiquement lors de la mise à niveau et peuvent être ignorées sans risque.

Si vous rencontrez des erreurs lors de cette vérification préalable, ouvrez une demande d’assistance auprès d’AWS Support pour que l’incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en procédant à un vidage logique, puis en effectuant une restauration sur un nouveau cluster de bases de données Aurora MySQL version 3.

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

Niveau de vérification préalable : erreur

Rechercher la présence d’artefacts liés à la fonctionnalité DDL rapide d’Aurora

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

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

Cette vérification préalable renvoie la liste de ces tables. Une fois que les tables renvoyées ont été 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."
      }
  ]
}

La vérification préalable 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.

Note

Avant de reconstruire les espaces de table, consultez Online DDL operations dans la documentation MySQL pour comprendre les effets du verrouillage et du déplacement des données sur les transactions de premier plan.

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, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

Tables avec référence d’index FULLTEXT 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 FTS_DOC_ID et FTS_DOC_ID_INDEX masquées deviennent orphelines. Pour plus d’informations, consultez le bogue n° 76 012.

Si cela s’est produit dans des tables créées sur des versions antérieures de MySQL, les mises à niveau vers la version 3 d’Aurora MySQL peuvent échouer. Cette vérification préalable s’assure qu’aucun index de texte intégral orphelin ou « suspendu » n’existe sur votre cluster de bases de données avant la mise à niveau vers MySQL 8.0. Si cette vérification préalable échoue, reconstruisez toutes les tables contenant des 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 vérification préalable signale une erreur pour la table test.table_with_fts_index, car elle contient un index de texte intégral suspendu. Pour permettre la mise à niveau, reconstruisez la table pour nettoyer les tables auxiliaires d’index de 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, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

Rechercher les incohérences liées au chemin du fichier ibd

Cette vérification préalable ne s’applique qu’à Aurora MySQL 3.03.0 ou version antérieure. Si vous rencontrez une erreur lors de cette vérification préalable, procédez à une mise à niveau vers Aurora MySQL 3.04 ou version ultérieure.

Exemple de sortie :

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

Niveau de vérification préalable : erreur

Rechercher l’index de texte intégral avec un identifiant d’espace égal à zéro

Dans MySQL, lorsque vous ajoutez un index de texte intégral à une table InnoDB, plusieurs espaces de table 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 était possible que ces tables d’index auxiliaires soient créées dans l’espace de table du système, plutôt que dans leur propre espace de table InnoDB.

S’il existe de tels espaces de table auxiliaires, la mise à niveau échouera. Recréez les index de texte intégral mentionnés dans l’erreur générée par la vérification préalable, 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 vérification préalable signale une erreur pour la table test.fts_space_zero_check, car elle contient des tables auxiliaires de recherche de texte intégral (FTS) dans l’espace de table du système.

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

Note

Avant de reconstruire les espaces de table, consultez Partitioning operations dans la documentation MySQL pour comprendre les effets du verrouillage et du déplacement des données sur les transactions de premier plan.

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

Niveau de vérification préalable : erreur

Rechercher les transactions XA à l’état préparé

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 à l’état préparé, cela peut empêcher l’arrêt complet d’avoir lieu. Pour cette raison, si des transactions XA préparées sont détectées, la mise à niveau ne pourra pas avoir lieu tant que vous n’aurez pas pris les mesures nécessaires pour les valider ou les annuler.

Pour plus d’informations sur la recherche des transactions XA à l’état préparé à l’aide de XA RECOVER, consultez Instructions SQL des transactions XA dans la documentation MySQL. Pour plus d’informations, consultez É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."
      }
  ]
}

Cette vérification préalable 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 la sortie XA RECOVER pour plus d’informations.

Important

Avant de valider ou d’annuler une transaction, nous vous recommandons de vérifier la documentation MySQL et les exigences de votre application.

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 que la transaction XA est annulée, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

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

L’exécution d’une mise à niveau sur place à partir d’Aurora MySQL version 2.12.0 ou 2.12.1, où la classe d’instance de base de données d’enregistreur est db.r6i.32xlarge, n’est actuellement pas prise en charge. Dans ce cas, la vérification préalable renvoie une erreur. Pour autoriser la mise à niveau, vous pouvez remplacer votre classe d’instance de base de données par db.r6i.24xlarge ou par 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 vérification préalable renvoie une erreur, car l’instance de base de données d’enregistreur utilise la classe d’instance db.r6i.32xlarge et s’exécute sur Aurora MySQL version 2.12.1.

auroraUpgradeCheckForInternalUsers

Niveau de vérification préalable : erreur

Rechercher les utilisateurs internes de la version 8.0

Cette vérification préalable ne s’applique qu’à Aurora MySQL 3.03.0 ou version antérieure. Si vous rencontrez une erreur lors de cette vérification préalable, procédez à une mise à niveau vers Aurora MySQL 3.04 ou version ultérieure.

Exemple de sortie :

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

Niveau de vérification préalable : erreur

Rechercher la présence de caractères utf8mb3 non valides dans la définition de la vue

Cette vérification préalable identifie les vues contenant des commentaires dont l’encodage de caractères utf8mb3 n’est pas valide. Dans MySQL 8.0, une validation plus stricte est appliquée à l’encodage des caractères dans les métadonnées, y compris les commentaires de vue. Si une définition de vue contient des caractères non valides dans le jeu de caractères utf8mb3, la mise à niveau échoue.

Pour résoudre ce problème, modifiez la définition de la vue afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau.

Exemple de sortie :

{
"id": "auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews",
"title": "Check for invalid utf8mb3 character string.",
"status": "OK",
"description": "Definition of following view(s) has/have invalid utf8mb3 character string.",
"detectedProblems": [
        {
            "level": "Error",
            "dbObject": "precheck.utf8mb3_invalid_char_view",
            "description": "Definition of view precheck.utf8mb3_invalid_char_view contains an invalid utf8mb3 character string. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify the view definition to not use non-BMP characters and try the upgrade again."
        }
    ]
},

La vérification préalable indique que la définition de la vue utf8mb3_invalid_char_view contient des caractères utf8mb3 non valides dans sa définition.

Pour résoudre ce problème, identifiez la vue contenant les caractères non pris en charge et mettez à jour les commentaires. Tout d’abord, examinez la structure de la vue et identifiez les commentaires.

MySQL> SHOW CREATE VIEW precheck.utf8mb3_invalid_char_view\G
*************************** 1. row ***************************
                View: utf8mb3_invalid_char_view
        Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`admin`@`%` SQL SECURITY DEFINER VIEW `utf8mb3_invalid_char_view` AS select 'This row contains a dolphin 🐬' AS `message`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set, 1 warning (0.00 sec)

Une fois que vous avez identifié la vue contenant l’erreur, remplacez-la par l’instruction CREATE OR REPLACE VIEW.

MySQL> CREATE OR REPLACE VIEW precheck.utf8mb3_invalid_char_view AS select 'This view definition to not use non-BMP characters' AS message;

Après avoir mis à jour toutes les définitions de vue contenant des caractères non pris en charge, la vérification préalable aboutit et la mise à niveau peut avoir lieu.

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

Niveau de vérification préalable : erreur

Rechercher la présence de commentaires de colonne utf8mb3 non valides

Cette vérification préalable identifie les tables contenant des commentaires de colonne dont l’encodage de caractères utf8mb3 n’est pas valide. Dans MySQL 8.0, une validation plus stricte est appliquée à l’encodage 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.

Pour résoudre ce problème, vous devez modifier les commentaires de ces colonnes afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau. Vous pouvez utiliser l’instruction ALTER TABLE 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 vérification préalable indique que le tableau test.t2 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. Tout d’abord, examinez la structure de la table 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’instruction ALTER TABLE. Exemples :

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 que vous avez mis à jour tous les commentaires de colonne problématiques, la vérification préalable aboutit et la mise à niveau peut avoir lieu :

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

Avant de modifier les commentaires de colonne, assurez-vous que tout code d’application ou toute documentation reposant sur ces commentaires est mis à jour en conséquence. Envisagez d’adopter le jeu de caractères utf8mb4 pour une meilleure prise en charge Unicode si votre application nécessite des caractères non BMP.

auroraUpgradeCheckForInvalidUtf8mb3IndexComments

Niveau de vérification préalable : erreur

Rechercher la présence de commentaires d’index utf8mb3 non valides

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

Pour résoudre ce problème, vous devez modifier ces commentaires d’index afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau.

Exemple de sortie :

{
    "id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
    "title": "Check for invalid utf8mb3 index comments.",
    "status": "OK",
    "description": "Following table(s) has/have invalid utf8mb3 comments on the index.",
    "detectedProblems": [
        {
            "level": "Error",
            "dbObject": "precheck.utf8mb3_tab_index_comment",
            "description": "Table precheck.utf8mb3_tab_index_comment has invalid utf8mb3 comments in it's index. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
        }
    ]
},

La vérification préalable indique que le tableau utf8mb3_tab_index_comment 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, examinez d’abord la structure de la table afin d’identifier l’index contenant des commentaires problématiques.

MySQL> SHOW CREATE TABLE precheck.utf8mb3_tab_index_comment\G
*************************** 1. row ***************************
    Table: utf8mb3_tab_index_comment
Create Table: CREATE TABLE `utf8mb3_tab_index_comment` (
`id` int(11) DEFAULT NULL,
`name` varchar(100) DEFAULT NULL,
KEY `idx_name` (`name`) COMMENT 'Name index 🐬'
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.01 sec)

Une fois que vous avez identifié l’index contenant des commentaires utilisant des caractères non pris en charge, supprimez-le et recréez-le.

Note

La suppression et la recréation d’un index de table peuvent entraîner une durée d’indisponibilité. Nous vous recommandons de planifier cette opération pendant la maintenance.

MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment DROP INDEX idx_name;
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment ADD INDEX idx_name(name);

L’exemple suivant présente une autre façon de recréer l’index.

MySQL> ALTER TABLE utf8mb3_tab_index_comment DROP INDEX idx_name, ADD INDEX idx_name (name) COMMENT 'Updated comment without non-BMP characters';

Une fois que vous avez supprimé ou mis à jour tous les commentaires d’index non pris en charge, la vérification préalable aboutit et la mise à niveau peut avoir lieu.

{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"detectedProblems": []
},
auroraUpgradeCheckForInvalidUtf8mb3TableComments

Niveau de vérification préalable : erreur

Rechercher la présence de caractères utf8mb3 non valides dans la définition de la table

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

Pour résoudre ce problème, vous devez modifier ces commentaires de table afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau.

Exemple de sortie :

{
    "id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
    "title": "Check for invalid utf8mb3 table comments.",
    "status": "OK",
    "description": "Following table(s) has/have invalid utf8mb3 comments.",
    "detectedProblems": [
        {
            "level": "Error",
            "dbObject": "precheck.utf8mb3_table_with_comment",
            "description": "Table precheck.utf8mb3_table_with_comment has invalid utf8mb3 comments. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
        }
        
    ]
},

La vérification préalable signale des commentaires utf8mb3 non valides définis pour les tables utf8mb3_table_with_comment dans la base de données de test.

Pour résoudre ce problème, identifiez la table contenant les caractères non pris en charge et mettez à jour les commentaires. Tout d’abord, examinez la structure de la table et identifiez les commentaires.

MySQL> SHOW CREATE TABLE precheck.utf8mb3_table_with_comment\G
*************************** 1. row ***************************
    Table: utf8mb3_table_with_comment
Create Table: CREATE TABLE `utf8mb3_table_with_comment` (
`id` int(11) NOT NULL,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='This table comment contains flag 🏳️'
1 row in set (0.00 sec)

Une fois que vous avez identifié les commentaires de table contenant des caractères non pris en charge, mettez-les à jour avec l’instruction ALTER TABLE.

MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='Updated comment without non-BMP characters';

Vous pouvez également supprimer le commentaire.

MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='';

Une fois que vous avez supprimé tous les caractères non pris en charge de tous les commentaires de table, la vérification préalable aboutit.

{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"detectedProblems": []
},
auroraUpgradeCheckForMasterUser

Niveau de vérification préalable : erreur

Vérifier 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 le nouveau rôle rds_superuser_role, qui est automatiquement accordé à 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 privilèges attribués à l’utilisateur principal dans Aurora MySQL, consultez Privilè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.

Cette vérification préalable s’assure que l’utilisateur principal se trouve dans la base de données. Si l’utilisateur principal n’y est pas, la vérification préalable échoue. Pour autoriser la mise à niveau, recréez l’utilisateur principal en réinitialisant son mot de passe ou en créant manuellement l’utilisateur. Réessayez ensuite la mise à niveau. Pour plus d’informations sur la réinitialisation du mot de passe de l’utilisateur principal, consultez Modification 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é le mot de passe de l’utilisateur principal, la vérification préalable aboutit et vous pouvez réessayer la mise à niveau.

L’exemple suivant utilise l’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, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

Recherche la présence de colonnes de géométrie sur les index à préfixe

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

Si de tels index existent, la mise à niveau échouera. Pour résoudre le problème, supprimez les index GEOMETRY à préfixe dans les tables mentionnées lors de l’échec de la vérification préalable.

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

Une fois que vous supprimez cet index, la vérification préalable aboutit.

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

Niveau de vérification préalable : erreur

Rechercher 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 schéma mysql afin de prendre en charge l’Atomic Data Dictionary 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 lors de leur ingestion 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 table mysql.proc des procédures contenant des caractères spéciaux. Par exemple, vous pouviez créer une procédure stockée avec un commentaire contenant un espace incassable non conforme, \xa0. Si de telles procédures sont identifiées, la mise à niveau échouera.

Cette vérification préalable s’assure que les corps et les définitions de vos procédures stockées ne contiennent pas ces 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."
      }
  ]
}

La vérification préalable indique que le cluster de bases de données contient une procédure appelée get_version_proc dans la base de données test dont le corps de la procédure contient des caractères spéciaux.

Après avoir supprimé et recréé la procédure stockée, la vérification préalable aboutit, permettant ainsi à la mise à niveau de se poursuivre.

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

Niveau de vérification préalable : erreur

Vérifier les incohérences de type d’objet par rapport au schéma sys

Le schéma sys est un ensemble d’objets et de vues d’une base de données MySQL, qui aident les utilisateurs à dépanner, optimiser et surveiller leurs instances de base de données. Lorsque vous effectuez une mise à niveau d’une version majeure d’Aurora MySQL version 2 vers Aurora MySQL version 3, les vues du schéma sys 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 schéma sys sont définis à l’aide de moteurs de stockage (sys_config/BASE TABLE dans INFORMATION_SCHEMA.TABLES) au lieu de vues, la mise à niveau échouera. Ces tables se trouvent dans information_schema.tables. Ce comportement n’est pas attendu, mais dans certains cas, il peut se produire en raison d’une erreur de l’utilisateur.

Cette vérification préalable valide tous les objets de schéma sys pour s’assurer qu’ils utilisent les définitions de table correctes 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 vérification préalable indique que la vue sys.waits_global_by_latency du schéma sys présente une incompatibilité de type qui empêche la mise à niveau d’avoir lieu.

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 définition appropriée, soit la renommer. Au cours du processus de mise à niveau, l’objet sera automatiquement créé avec la définition de table appropriée.

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, la vérification préalable aboutira.

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

Niveau de vérification préalable : erreur

Vérifier la limite supérieure du nom de colonne dans la vue

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 des vues de ce type existent sur votre instance de base de données, une erreur est générée par la vérification préalable et la mise à niveau échoue. 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 vérification préalable indique que la vue test.colname_view_test contient une colonne col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad dont la longueur dépasse la longueur maximale autorisée de 64 caractères.

En examinant 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, la vérification préalable aboutira.

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

Niveau de vérification préalable : erreur

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

Lorsque vous créez un index dans 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 des colonnes TINYTEXT et TINYBLOB, où la taille de données maximale autorisée est de 255 octets, mais où des préfixes d’index ont une taille supérieure. Pour plus d’informations, consultez Limites InnoDB dans la documentation MySQL.

Si cette vérification préalable échoue, supprimez l’index incriminé ou réduisez la longueur du préfixe des colonnes TINYTEXT et TINYBLOB de l’index pour qu’elle ne dépasse pas 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 vérification préalable signale une erreur pour la table test.tintxt_prefixed_index, car elle contient un index PRIMARY dont le préfixe est supérieur à 255 octets sur une colonne TINYTEXT ou TINYBLOB.

En examinant la définition de cette table, nous pouvons voir que la clé primaire a le préfixe 65 sur la colonne TINYTEXT col1. Comme la table est définie à l’aide du jeu de caractères utf8mb4, 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)

Le remplacement du préfixe d’index par 63 lors de l’utilisation du jeu de caractères utf8mb4 permettra à la mise à niveau d’avoir lieu.

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, la vérification préalable aboutira.

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

Niveau de vérification préalable : erreur

Rechercher toute incohérence des métadonnées InnoDB pour la table mysql.host

Il s’agit d’une vérification préalable interne, qui est effectuée par le service RDS. Toutes les erreurs seront traitées automatiquement lors de la mise à niveau et peuvent être ignorées sans risque.

Si vous rencontrez des erreurs lors de cette vérification préalable, ouvrez une demande d’assistance auprès d’AWS Support pour que l’incohérence des métadonnées soit résolue. Vous pouvez également réessayer la mise à niveau en procédant à un vidage logique, puis en effectuant une restauration sur un nouveau cluster de bases de données Aurora MySQL version 3.

Avertissements

Les vérifications préalables suivantes génèrent des avertissements en cas d’échec, mais la mise à niveau peut tout de même avoir lieu.

Vérifications préalables de MySQL qui signalent des avertissements

Les vérifications préalables suivantes sont tirées de Community MySQL :

defaultAuthenticationPlugin

Niveau de vérification préalable : avertissement

Considérations relatives au nouveau plug+in d’authentification par défaut

Dans MySQL 8.0, le plug-in d’authentification caching_sha2_password a été introduit afin de fournir un chiffrement des mots de passe plus sécurisé et de meilleures performances que le plug-in mysql_native_password obsolète. Pour Aurora MySQL version 3, le plug-in d’authentification par défaut utilisé par les utilisateurs de base de données est le plug-in mysql_native_password.

Cette vérification préalable indique que ce plug-in sera supprimé et sera remplacé dans une future version majeure. Pensez à évaluer la compatibilité des clients et des utilisateurs de votre application avant cette modification.

Pour plus d’informations, consultez Problèmes de compatibilité avec caching_sha2_password et 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"
},
maxdbFlagCheck

Niveau de vérification préalable : avertissement

Utilisation d’un indicateur MAXDB sql_mode obsolète

Dans MySQL 8.0, plusieurs options de variables système sql_mode obsolètes ont été supprimées, y compris MAXDB. Cette vérification préalable examine toutes les sessions actuellement connectées, ainsi que les routines et les déclencheurs, pour s’assurer que sql_mode n’est défini sur aucune combinaison incluant MAXDB pour aucune session, aucune routine ni aucun déclencheur.

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

La vérification préalable indique que la routine test.maxdb_stored_routine contient une option sql_mode non prise en charge.

Une fois connecté à la base de données, vous pouvez voir dans la définition de routine que sql_mode contient MAXDB.

 > SHOW CREATE PROCEDURE test.maxdb_stored_routine\G

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

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

Note

Selon la documentation MySQL, MySQL stocke le paramètre sql_mode en vigueur lorsqu’une routine est créée ou modifiée. Il exécute toujours la routine avec ce paramètre, quel que soit le paramètre sql_mode au moment où la routine démarre.

Avant de modifier sql_mode, consultez Modes SQL Server dans la documentation MySQL. Évaluez soigneusement tout impact potentiel de cette action sur votre application.

Recréez la procédure sans l’élément sql_mode non pris en charge.

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

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

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

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

La vérification préalable aboutit.

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

Niveau de vérification préalable : avertissement

Rechercher l’utilisation obsolète du signe 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 utilisant $ comme premier caractère, cette vérification préalable renvoie un avertissement. Bien que cet avertissement n’empêche pas la mise à niveau d’avoir lieu, 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 vérification préalable signale un avertissement, car la table $deprecated_syntx du schéma test contient un $ comme premier caractère.

reservedKeywordsCheck

Niveau de vérification préalable : 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 à routineSyntaxCheck, dans la mesure où il recherche 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 que les avertissements ne bloquent pas les mises à niveau, vous devez les évaluer attentivement.

Exemple de sortie :

En utilisant l’exemple précédent avec la table nommée except, la vérification préalable 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 que vous pouvez avoir à vérifier certaines requêtes d’application. Si vos requêtes d’application n’échappent pas correctement les littéraux de chaîne, elles risquent de rencontrer des erreurs après la mise à niveau vers MySQL 8.0. Vérifiez vos applications pour confirmer ce comportement, en les testant par rapport à un clone ou à un instantané de votre cluster de bases 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';
utf8mb3Check

Niveau de vérification préalable : avertissement

Utilisation du jeu de caractères utf8mb3

Dans MySQL 8.0, le jeu de caractères utf8mb3 est obsolète et sera supprimé dans une future version majeure de MySQL. Cette vérification préalable 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 d’avoir lieu, mais nous vous recommandons vivement de penser à migrer les tables vers le jeu de caractères utf8mb4, qui est le jeu de caractères par défaut à partir de MySQL 8.0. Pour plus d’informations sur utf8mb3 et utf8mb4, consultez Conversion entre les jeux de caractères Unicode à 3 octets et à 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 Conversion entre les jeux de caractères Unicode à 3 octets et à 4 octets dans la documentation MySQL.

zeroDatesCheck

Niveau de vérification préalable : avertissement

Aucune valeur de date, de date/heure ni 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 modes NO_ZERO_IN_DATE et NO_ZERO_DATE SQL conjointement avec le mode strict, car ils seront fusionnés avec le mode strict dans une future version de MySQL.

Si le paramètre sql_mode de l’une de vos connexions à la base de données, au moment de l’exécution de la vérification préalable, n’inclut pas ces modes, un avertissement sera émis lors de la vérification préalable. Il est possible que les utilisateurs puissent toujours insérer des valeurs nulles pour la date, les date et heure ou l’horodatage. Cependant, nous vous conseillons vivement de remplacer les valeurs nulles par des valeurs valides, car leur comportement pourrait changer à l’avenir et elles pourraient cesser de fonctionner correctement. Comme il s’agit d’un avertissement, la mises à niveau ne sera pas bloquée, mais nous vous recommandons de commencer à planifier d’apporter les modifications nécessaires.

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

Vérifications préalables d’Aurora MySQL qui signalent des avertissements

Les vérifications préalables suivantes sont spécifiques à Aurora MySQL :

auroraUpgradeCheckForRollbackSegmentHistoryLength

Niveau de vérification préalable : 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 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 de restauration de votre cluster de bases de données est élevée, cela peut prolonger le temps nécessaire à InnoDB pour purger les enregistrements du journal d’annulation. Cela peut entraîner une durée d’indisponibilité prolongée pendant le processus de mise à niveau de la version majeure. Si la vérification préalable détecte que la longueur de cette liste sur votre cluster de bases de données est élevé, elle émet un avertissement. Bien que cet avertissement n’empêche pas la mise à niveau d’avoir lieu, nous vous recommandons de surveiller de près la longueur de cette liste sur votre cluster de bases de données. Une longueur de liste d’historique faible réduit la durée d’indisponibilité requise pendant une mise à niveau de version majeure. Pour plus d’informations sur la surveillance de la longueur de la liste d’historique, consultez La 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 vérification préalable renvoie un avertissement, car elle a détecté que la longueur de la liste d’historique d’annulation d’InnoDB était élevée 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 la durée d’indisponibilité requise pendant le processus de mise à niveau.

Nous vous recommandons d’examiner les transactions en cours sur votre cluster de bases de données avant d’exécuter la mise à niveau en production, afin de vous assurer que la longueur de votre liste d’historique reste à une taille gérable.

auroraUpgradeCheckForUncommittedRowModifications

Niveau de vérification préalable : 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 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 bases 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 la vérification préalable 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 cet avertissement n’empêche pas la mise à niveau d’avoir lieu, nous vous recommandons de surveiller de près la taille des transactions actives sur votre cluster de bases de données. Une longueur de liste d’historique faible réduit la durée d’indisponibilité requise pendant une mise à niveau de version majeure.

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

La vérification préalable indique que le cluster de bases de données contient une transaction avec 11 000 000 modifications de lignes non validées qui devront être annulées pendant le processus d’arrêt complet. La mise à niveau aura lieu, mais pour réduire la durée d’indisponibilité pendant le processus de mise à niveau, nous vous recommandons de surveiller et d’étudier ce cas avant d’exécuter la mise à niveau sur vos clusters de production.

Pour consulter les transactions actives sur votre instance de base de données d’enregistreur, vous pouvez utiliser la table information_schema.innodb_trx. La requête suivante sur l’instance de base de données d’enregistreur indique les transactions en cours, la durée d’exécution, l’état et les lignes modifiées pour le cluster de bases 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, la vérification préalable ne renvoie plus d’avertissement. Consultez la documentation MySQL et faites appel l’équipe chargée de votre application avant d’annuler des transactions importantes, car la restauration peut prendre un certain temps, en fonction de la taille des transactions.

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

Notifications

La vérification préalable suivante génère une notification en cas d’échec, mais la mise à niveau peut tout de même avoir lieu.

sqlModeFlagCheck

Niveau de vérification préalable : notification

Utilisation d’indicateurs sql_mode obsolètes

Outre MAXDB, plusieurs autres options sql_mode ont été supprimées : DB2, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS et NO_TABLE_OPTIONS. Depuis MySQL 8.0, aucune de ces valeurs ne peut être affectée à la variable système sql_mode. Si cette vérification préalable détecte des sessions en cours utilisant ces paramètres sql_mode, assurez-vous que les groupes de paramètres de votre instance de base de données et de cluster de bases de données, ainsi que les applications et les 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 vérification préalable, consultez maxdbFlagCheck.

Erreurs, avertissements ou notifications

La vérification préalable suivante peut renvoyer une erreur, un avertissement ou une notification en fonction de sa sortie.

checkTableOutput

Niveau de vérification préalable : erreur, avertissement ou notification

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

Avant de commencer la mise à niveau vers Aurora MySQL version 3, check table for upgrade est exécuté sur chaque table dans les schémas utilisateur de votre cluster de bases de données. Cette vérification préalable n’est la même que checkTableMysqlSchema.

La commande check table for upgrade 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 contribue à identifier et à résoudre les incompatibilités à l’avance, ce qui facilite le processus de mise à niveau réel.

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

  • Vérification de la compatibilité de la structure et des métadonnées de la table avec la version MySQL cible

  • Identification des fonctionnalités obsolètes ou supprimées qui sont utilisées par la table

  • Confirmation de la possibilité de mettre à niveau la table sans perte de données

Contrairement aux autres vérifications préalables, celle-ci peut renvoyer une erreur, un avertissement ou une notification en fonction de la sortie check table. Si cette vérification préalable 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 Instruction CHECK TABLE dans la documentation MySQL.

Nous fournissons ci-dessous 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 vérification préalable signale une erreur indiquant que la table test.parent n’existe pas.

Le fichier mysql-error.log de l’instance de base de données d’enregistreur 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 d’enregistreur 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 message LATEST FOREIGN KEY ERROR indique que la contrainte de clé étrangère fk_pname dans la table test.child, qui référence la table test.parent, présente un problème d’index manquant ou d’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 le problème est lié à un index manquant ou à une incompatibilité du type de données, connectez-vous à la base de données et vérifiez les définitions de table en désactivant temporairement la variable de session foreign_key_checks. Nous pouvons maintenant voir que la contrainte enfant en question (fk_pname) utilise p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL pour référencer la table parent name varchar(20) NOT NULL. La table parent utilise DEFAULT CHARSET=utf8, mais la colonne p_name de la table enfant utilise latin1, de sorte que l’erreur d’incompatibilité 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 utilise explicitement latin1 dans la définition de colonne p_name, nous exécutons ALTER TABLE pour modifier le jeu de caractères sur utf8.

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

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

Après cela, la vérification préalable aboutira et la mise à niveau pourra avoir lieu.

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 vérification préalable signale un avertissement concernant le déclencheur delete_audit_trigg sur la table test.orders, car celui-ci ne possède pas d’attribut CREATED. Selon la section Vérification de la compatibilité des versions de la documentation MySQL, ce message est informatif et s’affiche 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 d’avoir lieu. Toutefois, si vous souhaitez résoudre le problème, vous pouvez recréer le déclencheur en question pour que la vérification préalable aboutisse sans avertissement.

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