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.
# Vérifiez les descriptions pour la mise à niveau d'Aurora MySQL version 2 vers la version 3
Les prévérifications suivantes sont exécutées lorsque vous mettez à niveau un cluster de base de données Aurora MySQL de la version 2 (compatible avec MySQL 5.7) à la version 3 (compatible avec MySQL 8.0). Pour les prévérifications exécutées lors des mises à niveau d'Aurora MySQL version 3 vers la version 8.4, consultez[Vérifiez les descriptions pour la mise à niveau d'Aurora MySQL version 3 vers la version 8.4](AuroraMySQL.upgrade-prechecks-v3-to-v84.descriptions.md).
**Contents**
+ [Erreurs](#precheck-descriptions-errors)
+ [Vérifications préalables de MySQL qui signalent des erreurs](#precheck-descriptions-errors.mysql)
+ [Vérifications préalables d’Aurora MySQL qui signalent des erreurs](#precheck-descriptions-errors.aurora)
+ [Avertissements](#precheck-descriptions-warnings)
+ [Vérifications préalables de MySQL qui signalent des avertissements](#precheck-descriptions-warnings.mysql)
+ [Vérifications préalables d’Aurora MySQL qui signalent des avertissements](#precheck-descriptions-warnings.aurora)
+ [Notifications](#precheck-descriptions-notices)
+ [Erreurs, avertissements ou notifications](#precheck-descriptions-all)
## 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.
**Topics**
+ [Vérifications préalables de MySQL qui signalent des erreurs](#precheck-descriptions-errors.mysql)
+ [Vérifications préalables d’Aurora MySQL qui signalent des erreurs](#precheck-descriptions-errors.aurora)
### Vérifications préalables de MySQL qui signalent des erreurs
Les vérifications préalables suivantes sont tirées de Community MySQL :
+ [vérifier TableMysqlSchema](#checkTableMysqlSchema)
+ [circulaire DirectoryCheck](#circularDirectoryCheck)
+ [colonnes WhichCannotHaveDefaultsCheck](#columnsWhichCannotHaveDefaultsCheck)
+ [déprécié SyntaxCheck](#depreciatedSyntaxCheck)
+ [moteur MixupCheck](#engineMixupCheck)
+ [énumération SetElementLengthCheck](#enumSetElementLengthCheck)
+ [étranger KeyLengthCheck](#foreignKeyLengthCheck)
+ [getDuplicateTriggers](#getDuplicateTriggers)
+ [getEventsWithNullDefiner](#getEventsWithNullDefiner)
+ [getMismatchedMetadata](#getMismatchedMetadata)
+ [getTriggersWithNullDefiner](#getTriggersWithNullDefiner)
+ [obtenir les noms de ValueOfVariablelower \_case\_tables](#getValueOfVariable)
+ [groupByAscSyntaxCheck](#groupByAscSyntaxCheck)
+ [mysqlEmptyDotTableSyntaxCheck](#mysqlEmptyDotTableSyntaxCheck)
+ [mysqlIndexTooLargeCheck](#mysqlIndexTooLargeCheck)
+ [mysqlInvalid57NamesCheck](#mysqlInvalid57NamesCheck)
+ [mysqlOrphanedRoutinesCheck](#mysqlOrphanedRoutinesCheck)
+ [mysqlSchemaCheck](#mysqlSchemaCheck)
+ [non NativePartitioningCheck](#nonNativePartitioningCheck)
+ [oldTemporalCheck](#oldTemporalCheck)
+ [partitionné Partagé TablesIn TablespaceCheck](#partitionedTablesInSharedTablespace)
+ [supprimé FunctionsCheck](#removedFunctionsCheck)
+ [routine SyntaxCheck](#routineSyntaxCheck)
+ [schémaInconsistencyCheck](#schemaInconsistencyCheck)
**vérifier TableMysqlSchema**
**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](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) 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](https://aws.amazon.com/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.
**circulaire DirectoryCheck**
**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](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-17.html), 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](https://dev.mysql.com/doc/refman/8.0/en/innodb-file-per-table-tablespaces.html). Utilisez les chemins de fichier par défaut pour tous les espaces de table et toutes les définitions de tables.
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](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) 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": []
},
```
**colonnes WhichCannotHaveDefaultsCheck**
**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](https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html). 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](https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html) 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.
Avant d’exécuter des instructions `ALTER TABLE` ou de reconstruire des espaces de table, consultez [Opérations DDL en ligne](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) 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": []
},
```
**déprécié SyntaxCheck**
**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](https://dev.mysql.com/doc/refman/5.7/en/query-cache.html). 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": []
}
```
**moteur MixupCheck**
**Niveau de vérification préalable : erreur**
**Tables reconnues par InnoDB et qui appartiennent à un autre moteur**
Comme pour le [schéma InconsistencyCheck](#schemaInconsistencyCheck), cette prévérification vérifie que les métadonnées des tables dans MySQL sont cohérentes avant de procéder à la mise à niveau.
Si vous rencontrez des erreurs lors de cette vérification préalable, ouvrez une demande d’assistance auprès d’[AWS Support](https://aws.amazon.com/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"
}
]
}
```
**énumération SetElementLengthCheck**
**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": []
},
```
**étranger KeyLengthCheck**
**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](https://dev.mysql.com/doc/refman/8.0/en/identifier-length.html). En raison de [problèmes](https://bugs.mysql.com/bug.php?id=88118) 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](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) 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": []
}
```
**obtenir DuplicateTriggers**
**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](https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html) 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": []
}
```
**obtenir EventsWithNullDefiner**
**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](https://dev.mysql.com/doc/refman/5.7/en/events-overview.html) `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.
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](https://dev.mysql.com/doc/refman/5.7/en/stored-objects-security.html) 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": []},
```
**obtenir MismatchedMetadata**
**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**
Comme pour le [schéma InconsistencyCheck](#schemaInconsistencyCheck), cette prévérification vérifie que les métadonnées des tables dans MySQL sont cohérentes avant de procéder à la mise à niveau. Dans ce cas, 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](https://aws.amazon.com/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`.
**obtenir TriggersWithNullDefiner**
**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 du définisseur pour les objets stockés, voir [get EventsWithNullDefiner](#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 [get EventsWithNullDefiner](#getEventsWithNullDefiner).
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](https://dev.mysql.com/doc/refman/5.7/en/stored-objects-security.html) dans la documentation MySQL.
**obtenir les noms de ValueOfVariablelower \_case\_tables**
**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](https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html) 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](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html), 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](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-data-dictionary-changes) 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.
Testez et examinez attentivement la documentation sur la [sensibilité à la casse](https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html) 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](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_lower_case_table_names) dans MySQL 8.0.
**groupe ByAscSyntaxCheck**
**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](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-sql-changes) 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"
}
]
}
```
**mysql EmptyDotTableSyntaxCheck**
**Niveau de vérification préalable : erreur**
**Rechercher l’utilisation de la syntaxe `.` obsolète dans les routines.**
Dans MySQL 8.0, les routines ne peuvent plus contenir la syntaxe d’identifiant obsolète (`\".\"`). 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](https://dev.mysql.com/doc/refman/8.0/en/identifiers.html) dans la documentation PostgreSQL.
**Exemple de sortie :**
```
{
"id": "mysqlEmptyDotTableSyntaxCheck",
"title": "Check for deprecated '.' syntax used in routines.",
"status": "OK",
"description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".\"), 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.
**mysql IndexTooLargeCheck**
**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](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-35.html).
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](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_format) est défini sur `Barracuda` et qu’[innodb\_default\_row\_format](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_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](https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html) et [Gestion des formats de fichier InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html) dans la documentation MySQL.
Avant de reconstruire les espaces de table, consultez [Online DDL operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) 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": []
},
```
**mysql Invalid57NamesCheck**
**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](https://dev.mysql.com/doc/refman/8.0/en/mysqlcheck.html) sur les schémas et les tables renvoyés.
Assurez-vous d’utiliser une [version MySQL 5.7](https://downloads.mysql.com/archives/community/) de `mysqlcheck`, car [--fix-db-names](https://dev.mysql.com/doc/refman/5.7/en/mysqlcheck.html#option_mysqlcheck_fix-db-names) et [--fix-table-names](https://dev.mysql.com/doc/refman/5.7/en/mysqlcheck.html#option_mysqlcheck_fix-table-names) ont été supprimés de [MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html).
**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": []
},
```
**mysql OrphanedRoutinesCheck**
**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": []
},
```
**mysql SchemaCheck**
**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](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) 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](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-schema.html) 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`.
**non NativePartitioningCheck**
**Niveau de vérification préalable : erreur**
**Tables partitionnées à l’aide de moteurs avec partitionnement non natif**
Selon la [documentation MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html), deux moteurs de stockage prennent actuellement en charge le partitionnement natif : [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) et [NDB](https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster.html). 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.
**vieux TemporalCheck**
**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](https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html) 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](https://dev.mysql.com/blog-archive/how-to-easily-identify-tables-with-temporal-types-in-old-format/). Pour plus d’informations sur la suppression des types de données « anciens temporels » dans MySQL 8.0, consultez ce [blog](https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/).
Avant de reconstruire les espaces de table, consultez [Online DDL operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) 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 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](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) 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](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) 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": []
}
```
**partitionné Partagé TablesIn TablespaceCheck**
**Niveau de vérification préalable : erreur**
**Utilisation de tables partitionnées dans les espaces de table partagés**
Depuis [MySQL 8.0.13](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html), 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.
Avant de reconstruire les espaces de table, consultez [Partitioning operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning) 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": []
}
```
**supprimé FunctionsCheck**
**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](https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html), 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](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals) 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](https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html#function_polyfromtext) et [POINTFROMTEXT](https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html#function_st-mpointfromtext). Elle suggère également d’utiliser les nouvelles fonctions [ST\_POLYGONFROMTEXT](https://dev.mysql.com/doc/refman/8.0/en/gis-wkt-functions.html#function_st-polyfromtext) et [ST\_POINTFROMTEXT](https://dev.mysql.com/doc/refman/8.0/en/gis-wkt-functions.html#function_st-mpointfromtext) à 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": []
},
```
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.
**routine SyntaxCheck**
**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](https://dev.mysql.com/doc/mysqld-version-reference/en/keywords-8-0.html#keywords-new-in-8-0) 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](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html) 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. Re-create la procédure en échappant à la chaîne littérale.
```
> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)
> DELIMITER $$
> CREATE PROCEDURE select_res_word()
-> BEGIN
-> SELECT * FROM 'except';
-> END$$
Query OK, 0 rows affected (0.00 sec)
> DELIMITER ;
```
Désormais, la vérification préalable aboutit.
```
{
"id": "routineSyntaxCheck",
"title": "MySQL syntax check for routine-like objects",
"status": "OK",
"detectedProblems": []
}
```
**schéma InconsistencyCheck**
**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](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html), 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](https://en.wikipedia.org/wiki/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](https://aws.amazon.com/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](#auroraCheckDDLRecovery)
+ [aurore CheckRdsUpgradePrechecksTable](#auroraCheckRdsUpgradePrechecksTable)
+ [aurore FODUpgradeCheck](#auroraFODUpgradeCheck)
+ [aurore GetDanglingFulltextIndex](#auroraGetDanglingFulltextIndex)
+ [aurore UpgradeCheckForDatafilePathInconsistency](#auroraUpgradeCheckForDatafilePathInconsistency)
+ [aurore UpgradeCheckForFtsSpaceIdZero](#auroraUpgradeCheckForFtsSpaceIdZero)
+ [aurore UpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions)
+ [aurore UpgradeCheckForInstanceLimit](#auroraUpgradeCheckForInstanceLimit)
+ [aurore UpgradeCheckForInternalUsers](#auroraUpgradeCheckForInternalUsers)
+ [aurore UpgradeCheckForInvalidUtf8mb3CharacterStringInViews](#auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews)
+ [aurore UnsupportedComponentsCheck](#auroraUnsupportedComponentsCheck)
+ [aurore UnsupportedPluginsCheck](#auroraUnsupportedPluginsCheck)
+ [aurore UpgradeCheckForInvalidUtf8mb3ColumnComments](#auroraUpgradeCheckForInvalidUtf8mb3ColumnComments)
+ [aurore UpgradeCheckForInvalidUtf8mb3IndexComments](#auroraUpgradeCheckForInvalidUtf8mb3IndexComments)
+ [aurore UpgradeCheckForInvalidUtf8mb3TableComments](#auroraUpgradeCheckForInvalidUtf8mb3TableComments)
+ [aurore UpgradeCheckForMasterUser](#auroraUpgradeCheckForMasterUser)
+ [aurore UpgradeCheckForPrefixIndexOnGeometryColumns](#auroraUpgradeCheckForPrefixIndexOnGeometryColumns)
+ [aurore UpgradeCheckForSpecialCharactersInProcedures](#auroraUpgradeCheckForSpecialCharactersInProcedures)
+ [aurore UpgradeCheckForSysSchemaObjectTypeMismatch](#auroraUpgradeCheckForSysSchemaObjectTypeMismatch)
+ [aurore UpgradeCheckForViewColumnNameLength](#auroraUpgradeCheckForViewColumnNameLength)
+ [aurore UpgradeCheckIndexLengthLimitOnTinyColumns](#auroraUpgradeCheckIndexLengthLimitOnTinyColumns)
+ [aurore UpgradeCheckMissingInnodbMetadataForMysqlHostTable](#auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable)
**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](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) 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](https://aws.amazon.com/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.
**aurore CheckRdsUpgradePrechecksTable**
**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](https://aws.amazon.com/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": []
}
```
**aurore FODUpgradeCheck**
**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](AuroraMySQL.Managing.FastDDL.md) a été introduite en [mode Lab](AuroraMySQL.Updates.LabMode.md) 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](https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl-operations.html).
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 ' 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.
Avant de reconstruire les espaces de table, consultez [Online DDL operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) 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": []
}
```
**aurore GetDanglingFulltextIndex**
**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](https://bugs.mysql.com/bug.php?id=76012).
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": []
},
```
**aurore UpgradeCheckForDatafilePathInconsistency**
**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": []
}
```
**aurore UpgradeCheckForFtsSpaceIdZero**
**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](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html) à une table InnoDB, plusieurs espaces de table d’index auxiliaires sont créés. En raison d’un [bogue](https://bugs.mysql.com/bug.php?id=72132) 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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace), plutôt que dans leur propre espace de table InnoDB.
Si de tels tablespaces auxiliaires existent, la mise à niveau échouera. Re-create les index en texte intégral mentionnés dans l'erreur de prévérification, puis réessayez la mise à niveau.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.fts_space_zero_check",
"description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
},
```
La 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.
Avant de reconstruire les espaces de table, consultez [Partitioning operations](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning) 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": []
}
```
**aurore UpgradeCheckForIncompleteXATransactions**
**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](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). 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](https://dev.mysql.com/doc/refman/5.7/en/xa.html) à 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](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html) dans la documentation MySQL. Pour plus d’informations, consultez [États des transactions XA](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html) 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](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) et la sortie `XA RECOVER` pour plus d’informations.
Avant de valider ou d’annuler une transaction, nous vous recommandons de vérifier la [documentation MySQL](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html) 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": []
}
```
**aurore UpgradeCheckForInstanceLimit**
**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](Concepts.DBInstanceClass.md) 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.
**aurore UpgradeCheckForInternalUsers**
**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": []
}
```
**aurore UpgradeCheckForInvalidUtf8mb3CharacterStringInViews**
**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": []
}
```
**aurore UpgradeCheckForInvalidUtf8mb3ColumnComments**
**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`. Par exemple :
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
Vous pouvez également supprimer complètement le commentaire :
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
Après 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": []
}
```
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.
**aurore UpgradeCheckForInvalidUtf8mb3IndexComments**
**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.
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": []
},
```
**aurore UpgradeCheckForInvalidUtf8mb3TableComments**
**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": []
},
```
**aurore UpgradeCheckForMasterUser**
**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](https://dev.mysql.com/doc/refman/8.0/en/roles.html) et les [privilèges dynamiques](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges) 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](UsingWithRDS.MasterAccounts.md). Pour plus d’informations sur le modèle de privilèges basé sur les rôles dans Aurora MySQL version 3, consultez [Role-based modèle de privilège](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
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.](Aurora.Modifying.md#Aurora.Modifying.Password).
**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 le AWS CLI pour réinitialiser le mot de passe. Les modifications de mot de passe sont appliquées immédiatement.
```
aws rds modify-db-cluster \
--db-cluster-identifier {{my-db-cluster}} \
--master-user-password {{my-new-password}}
```
Ensuite, la vérification préalable aboutit.
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**aurore UpgradeCheckForPrefixIndexOnGeometryColumns**
**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](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support), il n’est plus possible de créer un index [avec préfixe](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) sur une colonne avec le type de données [GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html). Pour plus d’informations, consultez [WL\#11808](https://dev.mysql.com/worklog/task/?id=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": []
}
```
**aurore UpgradeCheckForSpecialCharactersInProcedures**
**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](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) 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](https://en.wikipedia.org/wiki/Non-breaking_space) 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": []
},
```
**aurore UpgradeCheckForSysSchemaObjectTypeMismatch**
**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](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) 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 `sys` schéma sont définis à l'aide de moteurs de stockage (`sys_config/BASE TABLE`dans [INFORMATION\_ SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)), plutôt que 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](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) 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](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql), 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": []
}
```
**aurore UpgradeCheckForViewColumnNameLength**
**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](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) 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": []
}
```
**aurore UpgradeCheckIndexLengthLimitOnTinyColumns**
**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](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html) dans MySQL, vous devez ajouter une longueur de [préfixe](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) 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](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) 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": []
}
```
**aurore UpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**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](https://aws.amazon.com/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.
**aurore UnsupportedComponentsCheck**
**Niveau de vérification préalable : erreur**
**Vérifiez les composants non pris en charge installés dans la base de données**
Cette prévérification identifie les composants installés dans la base de données mais qui ne sont pas pris en charge dans la version cible d'Aurora MySQL. Ces composants doivent être désinstallés avant que la mise à niveau puisse se poursuivre.
**Exemple de sortie :**
```
{
"id": "auroraUnsupportedComponentsCheck",
"title": "Check for unsupported components",
"status": "OK",
"description": "Checks for unsupported components installed in the database",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Component file://component_log_sink_json loaded in the engine. To proceed with the upgrade, uninstall this component."
}
]
}
```
Pour résoudre ce problème :
1. Identifiez les composants non pris en charge répertoriés dans le message d'erreur.
1. Désinstallez chaque composant non pris en charge :
```
UNINSTALL COMPONENT 'file://{{component_name}}';
```
1. Vérifiez la suppression en consultant la liste des composants :
```
SELECT * FROM mysql.component;
```
1. Re-run le précontrôle pour confirmer la résolution.
**aurore UnsupportedPluginsCheck**
**Niveau de vérification préalable : erreur**
**Vérifiez l'utilisation de plugins non prise en charge**
Cette prévérification identifie les plug-ins qui ne sont pas pris en charge dans la version cible d'Aurora MySQL et qui doivent être supprimés avant la mise à niveau.
Si vous rencontrez des erreurs lors de cette prévérification, désinstallez les plug-ins non pris en charge répertoriés dans le message d'erreur avant de procéder à la mise à niveau.
**Exemple de sortie :**
```
{
"id": "auroraUnsupportedPluginsCheck",
"title": "Check for unsupported plugins",
"status": "OK",
"description": "Checks for unsupported plugins installed in the database",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Plugin simple_parser loaded in the engine. To proceed with the upgrade, remove this plugin."
}
]
}
```
Pour résoudre ce problème :
1. Identifiez les plug-ins non pris en charge répertoriés dans le message d'erreur.
1. Désinstallez chaque plugin non pris en charge :
```
UNINSTALL PLUGIN {{plugin_name}};
```
1. Vérifiez la suppression en consultant la liste des plugins :
```
SHOW PLUGINS;
```
1. Re-run le précontrôle pour confirmer la résolution.
## 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.
**Topics**
+ [Vérifications préalables de MySQL qui signalent des avertissements](#precheck-descriptions-warnings.mysql)
+ [Vérifications préalables d’Aurora MySQL qui signalent des avertissements](#precheck-descriptions-warnings.aurora)
### Vérifications préalables de MySQL qui signalent des avertissements
Les vérifications préalables suivantes sont tirées de Community MySQL :
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdb FlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [réservé KeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zDatesCheck](#zeroDatesCheck)ero
+ [obsolèteDefaultAuth](#deprecatedDefaultAuth)
**par défaut AuthenticationPlugin**
**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](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues) 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"
},
```
**maxdb FlagCheck**
**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](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) obsolètes ont été [supprimées](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html), 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.
Selon la [documentation MySQL](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html), 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](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) dans la documentation MySQL. Évaluez soigneusement tout impact potentiel de cette action sur votre application.
Re-create la procédure sans le support non pris en charge`sql_mode`.
```
mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
-> SQL SECURITY DEFINER
-> BEGIN
-> SELECT * FROM test;
-> END$$
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
La vérification préalable aboutit.
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysql DollarSignNameCheck**
**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](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal), 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](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html), 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.
**réservé KeywordsCheck**
**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 à la [routine SyntaxCheck](#routineSyntaxCheck), dans la mesure où elle vérifie l'utilisation d'objets de base de données dont les noms sont en conflit avec les nouveaux mots clés réservés. Bien 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](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html), 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](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) et [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html), consultez [Conversion entre les jeux de caractères Unicode à 3 octets et à 4 octets](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) 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](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) dans la documentation MySQL.
**zéro DatesCheck**
**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"
}
]
}
```
**déprécié DefaultAuth**
**Niveau de vérification préalable : avertissement**
**Vérifiez la méthode d'authentification par défaut obsolète dans les variables système**
Ce précontrôle vérifie que le plugin d'authentification par défaut configuré dans les variables système est compatible avec la version cible d'Aurora MySQL. Pour Aurora MySQL, `mysql_native_password` génère un avertissement plutôt qu'une erreur, car Aurora MySQL continue de prendre en charge cette méthode d'authentification.
**Exemple de sortie :**
```
{
"id": "deprecatedDefaultAuth",
"title": "Check for deprecated or invalid default authentication methods in system variables",
"status": "OK",
"description": "mysql_native_password authentication method is deprecated and it should be considered to correct this before upgrading to 8.4.0 release.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "default_authentication_plugin",
"description": "System variable default_authentication_plugin is set to mysql_native_password which is deprecated."
}
]
}
```
Sur le groupe de paramètres de votre cluster cible, il est recommandé de définir la valeur du `authentication_policy` paramètre `*:caching_sha2_password` à utiliser `caching_sha2_password` comme méthode d'authentification par mot de passe par défaut.
### Vérifications préalables d’Aurora MySQL qui signalent des avertissements
Les vérifications préalables suivantes sont spécifiques à Aurora MySQL :
+ [aurore UpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [aurore UpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
+ [aurore ValidatePasswordPluginCheck](#auroraValidatePasswordPluginCheck)
**aurore UpgradeCheckForRollbackSegmentHistoryLength**
**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 [Aurora UpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), lors de l'exécution du processus de mise à niveau de la version majeure, il est essentiel que l'instance de base de données Aurora MySQL version 2 [soit complètement arrêtée](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). 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é](proactive-insights.history-list.md).
**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](proactive-insights.history-list.md) 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.
**aurore UpgradeCheckForUncommittedRowModifications**
**Niveau de vérification préalable : avertissement**
**Vérifie s’il existe de nombreuses modifications de ligne non validées**
Comme indiqué dans [Aurora UpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), lors de l'exécution du processus de mise à niveau de la version majeure, il est essentiel que l'instance de base de données Aurora MySQL version 2 [soit complètement arrêtée](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown). 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](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html). 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](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) dans la documentation MySQL.
**aurore ValidatePasswordPluginCheck**
**Niveau de vérification préalable : avertissement**
**Vérifiez l'utilisation obsolète du plugin validate\_password**
Le `validate_password` plugin est obsolète dans la version 8.4 d'Aurora MySQL et sera supprimé dans une future version. Cet avertissement ne bloque pas la mise à niveau mais indique que vous devez planifier la transition vers le `validate_password` composant.
**Exemple de sortie :**
```
{
"id": "auroraValidatePasswordPluginCheck",
"title": "Check for deprecated validate_password plugin",
"status": "OK",
"description": "The validate_password plugin is deprecated and will be removed in a future release. It is recommended to transition to the validate_password component.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "validate_password",
"description": "The validate_password plugin is installed. Consider transitioning to the validate_password component."
}
]
}
```
Pour résoudre cet avertissement, procédez comme suit :
1. Assurez-vous que le `aurora_enable_validate_password_component` paramètre est activé dans le groupe de paramètres de votre cluster cible pour activer le composant dans votre cluster cible. Personnalisez les autres paramètres des composants selon vos besoins.
1. Après la mise à niveau, exécutez la commande suivante pour supprimer le `validate_password` plugin :
```
UNINSTALL PLUGIN validate_password;
```
## 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.
**sql ModeFlagCheck**
**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](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html) : `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](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html).
**Exemple de sortie :**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
Pour résoudre l'un de ces échecs de précontrôle, consultez [FlagCheckmaxdb](#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.
**vérifier TableOutput**
**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 prévérification n'est pas la même chose que la [vérification TableMysqlSchema](#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](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) 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 de clé étrangère](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) indique que les colonnes référencées dans une clé étrangère doivent avoir un index associé et que les parent/child colonnes 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](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#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](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility) 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": []
},
```