' 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": []
}
```
**auroraGetDanglingFulltextIndex**
**Niveau de vérification préalable : erreur**
**Tables avec référence d’index `FULLTEXT` suspendue**
Avant MySQL 5.6.26, il était possible qu’après la suppression d’un index de recherche en texte intégral, les colonnes `FTS_DOC_ID` et `FTS_DOC_ID_INDEX` masquées deviennent orphelines. Pour plus d’informations, consultez le [bogue n° 76 012](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": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**Niveau de vérification préalable : erreur**
**Rechercher les incohérences liées au chemin du fichier `ibd`**
Cette vérification préalable ne s’applique qu’à Aurora MySQL 3.03.0 ou version antérieure. Si vous rencontrez une erreur lors de cette vérification préalable, procédez à une mise à niveau vers Aurora MySQL 3.04 ou version ultérieure.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**Niveau de vérification préalable : erreur**
**Rechercher l’index de texte intégral avec un identifiant d’espace égal à zéro**
Dans MySQL, lorsque vous ajoutez un [index de texte intégral](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.
S’il existe de tels espaces de table auxiliaires, la mise à niveau échouera. Recréez les index de texte intégral mentionnés dans l’erreur générée par la vérification préalable, puis réessayez la mise à niveau.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.fts_space_zero_check",
"description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
},
```
La vérification préalable signale une erreur pour la table `test.fts_space_zero_check`, car elle contient des tables auxiliaires de recherche de texte intégral (FTS) dans l’espace de table du système.
Une fois que vous avez supprimé et recréé les index FTS associés à cette table, la vérification préalable aboutit.
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": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**Niveau de vérification préalable : erreur**
**Rechercher les transactions XA à l’état préparé**
Lors de l’exécution du processus de mise à niveau de la version majeure, il est essentiel que l’instance de base de données Aurora MySQL version 2 soit [complètement arrêtée](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\$1schema.innodb\$1trx](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": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**Niveau de vérification préalable : erreur**
**Vérifier si la mise à niveau est prise en charge sur la classe d’instance actuelle**
L’exécution d’une mise à niveau sur place à partir d’Aurora MySQL version 2.12.0 ou 2.12.1, où la [classe d’instance de base de données](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.
**auroraUpgradeCheckForInternalUsers**
**Niveau de vérification préalable : erreur**
**Rechercher les utilisateurs internes de la version 8.0**
Cette vérification préalable ne s’applique qu’à Aurora MySQL 3.03.0 ou version antérieure. Si vous rencontrez une erreur lors de cette vérification préalable, procédez à une mise à niveau vers Aurora MySQL 3.04 ou version ultérieure.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews**
**Niveau de vérification préalable : erreur**
**Rechercher la présence de caractères utf8mb3 non valides dans la définition de la vue**
Cette vérification préalable identifie les vues contenant des commentaires dont l’encodage de caractères `utf8mb3` n’est pas valide. Dans MySQL 8.0, une validation plus stricte est appliquée à l’encodage des caractères dans les métadonnées, y compris les commentaires de vue. Si une définition de vue contient des caractères non valides dans le jeu de caractères `utf8mb3`, la mise à niveau échoue.
Pour résoudre ce problème, modifiez la définition de la vue afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews",
"title": "Check for invalid utf8mb3 character string.",
"status": "OK",
"description": "Definition of following view(s) has/have invalid utf8mb3 character string.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_invalid_char_view",
"description": "Definition of view precheck.utf8mb3_invalid_char_view contains an invalid utf8mb3 character string. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify the view definition to not use non-BMP characters and try the upgrade again."
}
]
},
```
La vérification préalable indique que la définition de la vue `utf8mb3_invalid_char_view` contient des caractères `utf8mb3` non valides dans sa définition.
Pour résoudre ce problème, identifiez la vue contenant les caractères non pris en charge et mettez à jour les commentaires. Tout d’abord, examinez la structure de la vue et identifiez les commentaires.
```
MySQL> SHOW CREATE VIEW precheck.utf8mb3_invalid_char_view\G
*************************** 1. row ***************************
View: utf8mb3_invalid_char_view
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`admin`@`%` SQL SECURITY DEFINER VIEW `utf8mb3_invalid_char_view` AS select 'This row contains a dolphin 🐬' AS `message`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set, 1 warning (0.00 sec)
```
Une fois que vous avez identifié la vue contenant l’erreur, remplacez-la par l’instruction `CREATE OR REPLACE VIEW`.
```
MySQL> CREATE OR REPLACE VIEW precheck.utf8mb3_invalid_char_view AS select 'This view definition to not use non-BMP characters' AS message;
```
Après avoir mis à jour toutes les définitions de vue contenant des caractères non pris en charge, la vérification préalable aboutit et la mise à niveau peut avoir lieu.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**Niveau de vérification préalable : erreur**
**Rechercher la présence de commentaires de colonne utf8mb3 non valides**
Cette vérification préalable identifie les tables contenant des commentaires de colonne dont l’encodage de caractères `utf8mb3` n’est pas valide. Dans MySQL 8.0, une validation plus stricte est appliquée à l’encodage des caractères dans les métadonnées, y compris les commentaires de colonne. Si des commentaires de colonne contiennent des caractères non valides dans le jeu de caractères utf8mb3, la mise à niveau échouera.
Pour résoudre ce problème, vous devez modifier les commentaires de ces colonnes afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau. Vous pouvez utiliser l’instruction `ALTER TABLE` pour mettre à jour les commentaires des colonnes.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.t2",
"description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
}
```
La vérification préalable indique que le tableau `test.t2` contient des caractères `utf8mb3` non valides dans un ou plusieurs commentaires de colonne, notamment en raison de la présence de caractères non BMP.
Pour résoudre ce problème, vous pouvez identifier les colonnes problématiques et mettre à jour leurs commentaires. Tout d’abord, examinez la structure de la table pour identifier les colonnes contenant des commentaires :
```
mysql> SHOW CREATE TABLE test.t2\G
```
Une fois que vous avez identifié les colonnes contenant des commentaires problématiques, mettez-les à jour à l’aide de l’instruction `ALTER TABLE`. Exemples :
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
Vous pouvez également supprimer complètement le commentaire :
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
Après que vous avez mis à jour tous les commentaires de colonne problématiques, la vérification préalable aboutit et la mise à niveau peut avoir lieu :
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
Avant de modifier les commentaires de colonne, assurez-vous que tout code d’application ou toute documentation reposant sur ces commentaires est mis à jour en conséquence. Envisagez d’adopter le jeu de caractères utf8mb4 pour une meilleure prise en charge Unicode si votre application nécessite des caractères non BMP.
**auroraUpgradeCheckForInvalidUtf8mb3IndexComments**
**Niveau de vérification préalable : erreur**
**Rechercher la présence de commentaires d’index utf8mb3 non valides**
Cette vérification préalable identifie les tables contenant des commentaires d’index dont l’encodage de caractères `utf8mb3` n’est pas valide. Dans MySQL 8.0, une validation plus stricte est appliquée à l’encodage des caractères dans les métadonnées, y compris les commentaires d’index. Si des commentaires d’index contiennent des caractères non valides dans le jeu de caractères `utf8mb3`, la mise à niveau échoue.
Pour résoudre ce problème, vous devez modifier ces commentaires d’index afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the index.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_tab_index_comment",
"description": "Table precheck.utf8mb3_tab_index_comment has invalid utf8mb3 comments in it's index. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
La vérification préalable indique que le tableau `utf8mb3_tab_index_comment` contient des caractères `utf8mb3` non valides dans un ou plusieurs commentaires de colonne, notamment en raison de la présence de caractères non BMP.
Pour résoudre ce problème, examinez d’abord la structure de la table afin d’identifier l’index contenant des commentaires problématiques.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_tab_index_comment\G
*************************** 1. row ***************************
Table: utf8mb3_tab_index_comment
Create Table: CREATE TABLE `utf8mb3_tab_index_comment` (
`id` int(11) DEFAULT NULL,
`name` varchar(100) DEFAULT NULL,
KEY `idx_name` (`name`) COMMENT 'Name index 🐬'
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.01 sec)
```
Une fois que vous avez identifié l’index contenant des commentaires utilisant des caractères non pris en charge, supprimez-le et recréez-le.
La suppression et la recréation d’un index de table peuvent entraîner une durée d’indisponibilité. Nous vous recommandons de planifier cette opération pendant la maintenance.
```
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment DROP INDEX idx_name;
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment ADD INDEX idx_name(name);
```
L’exemple suivant présente une autre façon de recréer l’index.
```
MySQL> ALTER TABLE utf8mb3_tab_index_comment DROP INDEX idx_name, ADD INDEX idx_name (name) COMMENT 'Updated comment without non-BMP characters';
```
Une fois que vous avez supprimé ou mis à jour tous les commentaires d’index non pris en charge, la vérification préalable aboutit et la mise à niveau peut avoir lieu.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForInvalidUtf8mb3TableComments**
**Niveau de vérification préalable : erreur**
**Rechercher la présence de caractères utf8mb3 non valides dans la définition de la table**
Cette vérification préalable identifie les tables contenant des commentaires dont l’encodage de caractères `utf8mb3` n’est pas valide. Dans MySQL 8.0, une validation plus stricte est appliquée à l’encodage des caractères dans les métadonnées, y compris les commentaires des tables. Si des commentaires de table contiennent des caractères non valides dans le jeu de caractères `utf8mb3`, la mise à niveau échoue.
Pour résoudre ce problème, vous devez modifier ces commentaires de table afin de supprimer ou de remplacer tout caractère non BMP avant de tenter la mise à niveau.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_table_with_comment",
"description": "Table precheck.utf8mb3_table_with_comment has invalid utf8mb3 comments. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
La vérification préalable signale des commentaires `utf8mb3` non valides définis pour les tables `utf8mb3_table_with_comment` dans la base de données de test.
Pour résoudre ce problème, identifiez la table contenant les caractères non pris en charge et mettez à jour les commentaires. Tout d’abord, examinez la structure de la table et identifiez les commentaires.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_table_with_comment\G
*************************** 1. row ***************************
Table: utf8mb3_table_with_comment
Create Table: CREATE TABLE `utf8mb3_table_with_comment` (
`id` int(11) NOT NULL,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='This table comment contains flag 🏳️'
1 row in set (0.00 sec)
```
Une fois que vous avez identifié les commentaires de table contenant des caractères non pris en charge, mettez-les à jour avec l’instruction `ALTER TABLE`.
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='Updated comment without non-BMP characters';
```
Vous pouvez également supprimer le commentaire.
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='';
```
Une fois que vous avez supprimé tous les caractères non pris en charge de tous les commentaires de table, la vérification préalable aboutit.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForMasterUser**
**Niveau de vérification préalable : erreur**
**Vérifier si l’utilisateur principal RDS existe**
MySQL 8 a ajouté un nouveau modèle de privilèges prenant en charge les [rôles](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 [Modèle de privilège basé sur les rôles](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 l’AWS CLI pour réinitialiser le mot de passe. Les modifications de mot de passe sont appliquées immédiatement.
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
Ensuite, la vérification préalable aboutit.
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**Niveau de vérification préalable : erreur**
**Recherche la présence de colonnes de géométrie sur les index à préfixe**
Depuis [MySQL 8.0.12](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\$111808](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": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**Niveau de vérification préalable : erreur**
**Rechercher les incohérences liées aux caractères spéciaux dans les procédures stockées**
Avant MySQL 8.0, les noms de base de données, les noms de tables et les autres objets correspondaient à des fichiers du répertoire de données, c’est-à-dire à des métadonnées basées sur des fichiers. Dans le cadre de la mise à niveau vers MySQL 8.0, tous les objets de base de données sont migrés vers les nouvelles tables du dictionnaire de données internes qui sont stockées dans le schéma `mysql` afin de prendre en charge l’[Atomic Data Dictionary](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": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**Niveau de vérification préalable : erreur**
**Vérifier les incohérences de type d’objet par rapport au schéma `sys`**
Le [schéma sys](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 schéma `sys` sont définis à l’aide de moteurs de stockage (`sys_config/BASE TABLE` dans [INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)) au lieu de vues, la mise à niveau échouera. Ces tables se trouvent dans `information_schema.tables`. Ce comportement n’est pas attendu, mais dans certains cas, il peut se produire en raison d’une erreur de l’utilisateur.
Cette vérification préalable valide tous les objets de schéma `sys` pour s’assurer qu’ils utilisent les définitions de table correctes et que les vues ne sont pas définies par erreur comme des tables InnoDB ou MyISAM. Pour résoudre le problème, corrigez manuellement les objets renvoyés en les renommant ou en les supprimant. Réessayez ensuite la mise à niveau.
**Exemple de sortie :**
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"description": "Database contains objects with type mismatch for sys schema.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sys.waits_global_by_latency",
"description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
}
]
}
```
La vérification préalable indique que la vue [sys.waits\$1global\$1by\$1latency](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": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**Niveau de vérification préalable : erreur**
**Vérifier la limite supérieure du nom de colonne dans la vue**
La [longueur maximale autorisée d’un nom de colonne](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": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**Niveau de vérification préalable : erreur**
**Rechercher les tables dont les index sont définis avec une longueur de préfixe supérieure à 255 octets dans les petites colonnes**
Lorsque vous créez un index dans une colonne à l’aide d’un [type de données binaire](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": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**Niveau de vérification préalable : erreur**
**Rechercher toute incohérence des métadonnées InnoDB pour la table `mysql.host`**
Il s’agit d’une vérification préalable interne, qui est effectuée par le service RDS. Toutes les erreurs seront traitées automatiquement lors de la mise à niveau et peuvent être ignorées sans risque.
Si vous rencontrez des erreurs lors de cette vérification préalable, ouvrez une demande d’assistance auprès d’[AWS Support](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.
## 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)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**Niveau de vérification préalable : avertissement**
**Considérations relatives au nouveau plug\$1in 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\$1sha2\$1password 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"
},
```
**maxdbFlagCheck**
**Niveau de vérification préalable : avertissement**
**Utilisation d’un indicateur `MAXDB` `sql_mode` obsolète**
Dans MySQL 8.0, plusieurs options de variables système [sql\$1mode](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.
Recréez la procédure sans l’élément `sql_mode` non pris en charge.
```
mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
-> SQL SECURITY DEFINER
-> BEGIN
-> SELECT * FROM test;
-> END$$
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
La vérification préalable aboutit.
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**Niveau de vérification préalable : avertissement**
**Rechercher l’utilisation obsolète du signe dollar dans les noms d’objets**
Depuis [MySQL 8.0.32](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.
**reservedKeywordsCheck**
**Niveau de vérification préalable : avertissement**
**Utilisation d’objets de base de données dont les noms sont en conflit avec les nouveaux mots clés réservés**
Cette vérification est similaire à [routineSyntaxCheck](#routineSyntaxCheck), dans la mesure où il recherche l’utilisation d’objets de base de données dont les noms sont en conflit avec les nouveaux mots clés réservés. Bien que les avertissements ne bloquent pas les mises à niveau, vous devez les évaluer attentivement.
**Exemple de sortie :**
En utilisant l’exemple précédent avec la table nommée `except`, la vérification préalable renvoie un avertissement :
```
{
"id": "reservedKeywordsCheck",
"title": "Usage of db objects with names conflicting with new reserved keywords",
"status": "OK",
"description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.except",
"description": "Table name",
"dbObjectType": "Table"
}
]
}
```
Cet avertissement vous indique que vous pouvez avoir à vérifier certaines requêtes d’application. Si vos requêtes d’application [n’échappent pas correctement les littéraux de chaîne](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.
**zeroDatesCheck**
**Niveau de vérification préalable : avertissement**
**Aucune valeur de date, de date/heure ni d’horodatage**
MySQL applique désormais des règles plus strictes concernant l’utilisation de valeurs nulles dans les colonnes date, datetime et timestamp. Nous vous recommandons d’utiliser les modes `NO_ZERO_IN_DATE` et `NO_ZERO_DATE SQL` conjointement avec le mode `strict`, car ils seront fusionnés avec le mode `strict` dans une future version de MySQL.
Si le paramètre `sql_mode` de l’une de vos connexions à la base de données, au moment de l’exécution de la vérification préalable, n’inclut pas ces modes, un avertissement sera émis lors de la vérification préalable. Il est possible que les utilisateurs puissent toujours insérer des valeurs nulles pour la date, les date et heure ou l’horodatage. Cependant, nous vous conseillons vivement de remplacer les valeurs nulles par des valeurs valides, car leur comportement pourrait changer à l’avenir et elles pourraient cesser de fonctionner correctement. Comme il s’agit d’un avertissement, la mises à niveau ne sera pas bloquée, mais nous vous recommandons de commencer à planifier d’apporter les modifications nécessaires.
**Exemple de sortie :**
```
{
"id": "zeroDatesCheck",
"title": "Zero Date, Datetime, and Timestamp values",
"status": "OK",
"description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
"documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "global.sql_mode",
"description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
},
{
"level": "Warning",
"dbObject": "session.sql_mode",
"description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
}
]
}
```
### Vérifications préalables d’Aurora MySQL qui signalent des avertissements
Les vérifications préalables suivantes sont spécifiques à Aurora MySQL :
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**Niveau de vérification préalable : avertissement**
**Vérifie si la longueur de la liste d’historique des segments de restauration pour le cluster est élevée**
Comme indiqué dans [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), lors de l’exécution du processus de mise à niveau de version majeure, il est essentiel que l’instance de base de données Aurora MySQL version 2 soit [complètement arrêtée](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.
**auroraUpgradeCheckForUncommittedRowModifications**
**Niveau de vérification préalable : avertissement**
**Vérifie s’il existe de nombreuses modifications de ligne non validées**
Comme indiqué dans [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions), lors de l’exécution du processus de mise à niveau de version majeure, il est essentiel que l’instance de base de données Aurora MySQL version 2 soit [complètement arrêtée](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\$1schema.innodb\$1trx](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.
## Notifications
La vérification préalable suivante génère une notification en cas d’échec, mais la mise à niveau peut tout de même avoir lieu.
**sqlModeFlagCheck**
**Niveau de vérification préalable : notification**
**Utilisation d’indicateurs `sql_mode` obsolètes**
Outre `MAXDB`, plusieurs autres options `sql_mode` ont été [supprimées](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 vérification préalable, consultez [maxdbFlagCheck](#maxdbFlagCheck).
## Erreurs, avertissements ou notifications
La vérification préalable suivante peut renvoyer une erreur, un avertissement ou une notification en fonction de sa sortie.
**checkTableOutput**
**Niveau de vérification préalable : erreur, avertissement ou notification**
**Problèmes signalés par la commande `check table x for upgrade`**
Avant de commencer la mise à niveau vers Aurora MySQL version 3, `check table for upgrade` est exécuté sur chaque table dans les schémas utilisateur de votre cluster de bases de données. Cette vérification préalable n’est la même que [checkTableMysqlSchema](#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 liées aux clés étrangères](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 colonnes parent/enfant doivent utiliser le même type de données.
Pour vérifier si le problème est lié à un index manquant ou à une incompatibilité du type de données, connectez-vous à la base de données et vérifiez les définitions de table en désactivant temporairement la variable de session [foreign\$1key\$1checks](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": []
},
```
# Comment effectuer une mise à niveau sur place
Nous vous conseillons de passer en revue la documentation dans [Fonctionnement de la mise à niveau sur place d’une version majeure de Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence).
Effectuez la planification et les tests préalables nécessaires à la mise à niveau, comme décrit dans [Planification d’une mise à niveau de version majeure d’un cluster Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning).
## Console
L’exemple suivant met à niveau le cluster de bases de données `mydbcluster-cluster` vers Aurora MySQL version 3.04.1.
**Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Si vous avez utilisé un groupe de paramètres personnalisé avec le cluster de bases de données d’origine, créez un groupe de paramètres correspondant compatible avec la nouvelle version majeure. Apportez les modifications nécessaires aux paramètres de configuration de ce nouveau groupe de paramètres. Pour plus d’informations, consultez [Comment les mises à niveau sur place affectent les groupes de paramètres d’un cluster](#AuroraMySQL.Upgrading.ParamGroups).
1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.
1. Dans la liste, sélectionnez le cluster de bases de données à modifier.
1. Sélectionnez **Modify**.
1. Pour **Version**, sélectionnez une nouvelle version majeure d’Aurora MySQL.
Nous conseillons généralement d’utiliser la dernière version mineure de la version majeure. Ici, nous choisissons la version par défaut actuelle.
![\[Mise à niveau sur place d’un cluster de bases de données Aurora MySQL de la version 2 vers la version 3\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. Choisissez **Continuer**.
1. Sur la page suivante, indiquez quand effectuer la mise à niveau. Sélectionnez **During the next scheduled maintenance window (Pendant la fenêtre de maintenance planifiée suivante)** ou **Immediately (Immédiatement)**.
1. (Facultatif) Examinez régulièrement la page **Events (Événements)** de la console RDS pendant la mise à niveau pour mieux surveiller la progression de la mise à niveau et identifier les problèmes éventuels. Si la mise à niveau rencontre des problèmes, consultez [Dépannage de la mise à niveau sur place d’Aurora MySQL](AuroraMySQL.Upgrading.Troubleshooting.md) pour connaître les étapes à suivre.
1. Si vous avez créé un nouveau groupe de paramètres au début de cette procédure, associez le groupe de paramètres personnalisé à votre cluster mis à niveau. Pour plus d’informations, consultez [Comment les mises à niveau sur place affectent les groupes de paramètres d’un cluster](#AuroraMySQL.Upgrading.ParamGroups).
**Note**
Pour effectuer cette étape, vous devez redémarrer le cluster afin d’appliquer le nouveau groupe de paramètres.
1. (Facultatif) Après avoir terminé les tests postérieurs à la mise à niveau, supprimez l’instantané manuel créé par Aurora au début de la mise à niveau.
## AWS CLI
Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL, utilisez la commande de l’AWS CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) avec les paramètres requis suivants :
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` ou `--no-apply-immediately`
Si votre cluster utilise des groupes de paramètres personnalisés, incluez également l’une des options suivantes ou les deux :
+ `--db-cluster-parameter-group-name`, si le cluster utilise un groupe de paramètres de cluster personnalisé
+ `--db-instance-parameter-group-name`, si des instances du cluster utilisent un groupe de paramètres de base de données personnalisé
L’exemple suivant met à niveau le cluster de bases de données `sample-cluster` vers Aurora MySQL version 3.04.1. La mise à niveau se produit immédiatement, au lieu d’attendre la fenêtre de maintenance suivante.
**Example**
Pour Linux, macOS ou Unix :
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Pour Windows :
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
Vous pouvez combiner d’autres commandes de la CLI avec `modify-db-cluster` pour créer un processus automatisé de bout en bout permettant d’effectuer et de vérifier les mises à niveau. Pour plus d’informations et d’exemples, consultez [Tutoriel de mise à niveau sur place d’Aurora MySQL](AuroraMySQL.Upgrading.Tutorial.md).
**Note**
Si votre cluster fait partie d’une base de données Aurora globale, la procédure de mise à niveau sur place est légèrement différente. Vous appelez l’opération de commande [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) au lieu de `modify-db-cluster`. Pour plus d’informations, consultez [Mises à niveau majeures sur place des bases de données globales](#AuroraMySQL.Upgrading.GlobalDB).
## API RDS
Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL, utilisez l’opération d’API RDS [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) avec les paramètres requis suivants :
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (défini sur `true` ou `false`).
**Note**
Si votre cluster fait partie d’une base de données Aurora globale, la procédure de mise à niveau sur place est légèrement différente. Appelez l’opération [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) au lieu de `ModifyDBCluster`. Pour plus d’informations, consultez [Mises à niveau majeures sur place des bases de données globales](#AuroraMySQL.Upgrading.GlobalDB).
## Comment les mises à niveau sur place affectent les groupes de paramètres d’un cluster
Les groupes de paramètres Aurora ont différents ensembles de paramètres de configuration pour les clusters compatibles avec MySQL 5.7 ou 8.0. Lorsque vous effectuez une mise à niveau sur place, le cluster mis à niveau et toutes ses instances doivent utiliser les groupes de paramètres de cluster et d’instance correspondants :
Votre cluster et vos instances peuvent utiliser les groupes de paramètres compatibles avec la version 5.7 par défaut. Si tel est le cas, le cluster mis à niveau et l’instance commencent par les groupes de paramètres compatibles avec la version 8.0 par défaut. Si votre cluster et vos instances utilisent des groupes de paramètres personnalisés, assurez-vous de créer des groupes de paramètres correspondants compatibles avec la version 8.0. Assurez-vous également de les spécifier au cours du processus de mise à niveau.
**Note**
Pour la plupart des paramètres, vous pouvez choisir le groupe de paramètres personnalisé à deux points. C’est lorsque vous créez le cluster ou que vous associez le groupe de paramètres au cluster ultérieurement.
Toutefois, si vous utilisez un autre paramètre que le paramètre par défaut pour `lower_case_table_names`, vous devez configurer le groupe de paramètres personnalisés avec ce paramètre à l’avance. Spécifiez ensuite le groupe de paramètres lorsque vous effectuez la restauration des instantanés pour créer le cluster. Les modifications apportées au paramètre `lower_case_table_names` n’ont aucun effet après la création du cluster.
Nous vous recommandons d’utiliser le même paramètre pour `lower_case_table_names` lorsque vous passez de la version 2 à la version 3 de Aurora MySQL.
Avec une base de données globale Aurora basée sur Aurora MySQL, vous ne pouvez effectuer une mise à niveau sur place d’Aurora MySQL version 2 vers la version 3 que si le paramètre `lower_case_table_names` est défini sur sa valeur par défaut et si vous redémarrez la base de données globale. Pour plus d’informations sur les méthodes que vous pouvez utiliser, consultez [Mises à niveau de version majeure.](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
## Modifications apportées aux propriétés du cluster entre les versions d’Aurora MySQL
Lorsque vous effectuez une mise à niveau d’Aurora MySQL version 2 vers la version 3, veillez à vérifier les applications et les scripts que vous utilisez pour configurer ou gérer des clusters et des instances de base de données Aurora MySQL.
En outre, modifiez le code qui manipule les groupes de paramètres afin qu’il tienne compte du fait que les noms de groupes de paramètres par défaut sont différents pour les clusters compatibles avec 5.7 et 8.0. Les noms des groupes de paramètres par défaut pour des clusters Aurora MySQL versions 2 et 3 sont `default.aurora-mysql5.7` et `default.aurora-mysql8.0`, respectivement.
Par exemple, vous pouvez avoir un code semblable au suivant qui s’applique à votre cluster avant une mise à niveau.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
Après la mise à niveau de la version majeure du cluster, modifiez ce code comme suit.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## Mises à niveau majeures sur place des bases de données globales
Pour une base de données Aurora globale, mettez à niveau le cluster de bases de données globale. Aurora met automatiquement à niveau tous les clusters en même temps et s’assure qu’ils utilisent tous la même version du moteur. Cette exigence est due au fait que toutes les modifications apportées aux tables système, aux formats de fichiers de données et autres éléments sont automatiquement répliquées sur tous les clusters secondaires.
Suivez les instructions de la section [Fonctionnement de la mise à niveau sur place d’une version majeure de Aurora MySQL](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence). Lorsque vous spécifiez ce qui doit être mis à niveau, veillez à choisir le cluster de bases de données global plutôt que l’un des clusters qu’il contient.
Si vous utilisez l’AWS Management Console, choisissez l’élément avec le rôle **Global database** (Base de données globale).
![\[Mise à niveau du cluster de bases de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
Si vous utilisez l’AWS CLI ou l’API RDS, lancez le processus de mise à niveau en appelant la commande [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) ou l’opération [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html). Vous utilisez l’un d’entre eux au lieu de `modify-db-cluster` ou `ModifyDBCluster`.
**Note**
Vous ne pouvez pas spécifier un groupe de paramètres personnalisés pour le cluster de bases de données globale pendant que vous effectuez une mise à niveau majeure de la version de cette base de données globale Aurora. Créez vos groupes de paramètres personnalisés dans chaque région du cluster global. Appliquez-les ensuite manuellement aux clusters régionaux après la mise à niveau.
Pour mettre à niveau la version majeure d’un cluster de bases de données Aurora MySQL global à l’aide de l’interface AWS CLI, utilisez la commande [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) avec les paramètres requis suivants :
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
L’exemple suivant met à niveau le cluster de bases de données global vers Aurora MySQL version 3.04.2.
**Example**
Pour Linux, macOS ou Unix :
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.04.2 \
--allow-major-version-upgrade
```
Pour Windows :
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 8.0.mysql_aurora.3.04.2 ^
--allow-major-version-upgrade
```
## Mises à niveau sur place pour les clusters de bases de données ayant des réplicas en lecture entre régions
Vous pouvez mettre à niveau un cluster de bases de données Aurora ayant un réplica en lecture entre régions à l’aide de la procédure de mise à niveau sur place, mais certains éléments doivent être pris en considération :
+ Vous devez d’abord mettre à niveau le cluster de bases de données du réplica en lecture. Si vous essayez d’abord de mettre à niveau le cluster principal, vous recevez un message d’erreur similaire au message suivant :
Impossible de mettre à niveau le cluster de bases de données test-xr-primary-cluster, car le réplica entre régions d’Aurora associé, test-xr-replica-cluster, n’a pas encore reçu les correctifs requis. Mettez à niveau le réplica entre régions d’Aurora et réessayez.
Cela signifie que le cluster de bases de données principal ne peut pas avoir une version de moteur de base de données supérieure à celle du cluster de réplication.
+ Avant de mettre à niveau le cluster de bases de données principal, arrêtez la charge de travail d’écriture et désactivez toute nouvelle demande de connexion à l’instance de base de données d’enregistreur du cluster principal.
+ Lorsque vous mettez à niveau le cluster principal, choisissez un groupe de paramètres de cluster de bases de données personnalisé dont le paramètre `binlog_format` est défini sur une valeur qui prend en charge la réplication des journaux binaires, comme `MIXED`.
Pour plus d’informations sur l’utilisation de la journalisation binaire Aurora, consultez [Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires)](AuroraMySQL.Replication.MySQL.md). Pour plus d’informations sur la modification des paramètres de configuration de Aurora MySQL, consultez [Paramètres de configuration d’Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md) et [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md).
+ N’attendez pas trop longtemps pour mettre à niveau le cluster de bases de données principal après avoir mis à niveau le cluster du réplica. Nous vous recommandons de ne pas attendre au-delà de la fenêtre de maintenance suivante.
+ Après avoir mis à niveau le cluster de bases de données principal, redémarrez son instance de base de données d’enregistreur. Le groupe de paramètres de cluster de bases de données personnalisé qui active la réplication des journaux binaires ne prend effet qu’une fois que l’instance de base de données d’enregistreur est redémarrée.
+ Ne relancez pas la charge de travail d’écriture et n’activez pas les connexions à l’instance de base de données d’enregistreur tant que vous n’avez pas confirmé que la réplication entre régions a redémarré et que le délai de réplication de la Région AWS secondaire est de 0.
# Tutoriel de mise à niveau sur place d’Aurora MySQL
Les exemples Linux suivants montrent comment effectuer les grandes étapes de la procédure de mise à niveau sur place à l’aide de la AWS CLI.
Ce premier exemple crée un cluster de bases de données Aurora exécutant une version 2.x d’Aurora MySQL. Le cluster comprend une instance de base de données de scripteur et une instance de base de données de lecteur. La commande `wait db-instance-available` se suspend tant que l’instance de base de données du scripteur n’est pas disponible. C’est là que le cluster est prêt à être mis à niveau.
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Les versions 3.x d’Aurora MySQL vers lesquelles vous pouvez mettre à niveau le cluster dépendent de la version 2.x que le cluster exécute actuellement et de la Région AWS dans laquelle il se trouve. La première commande, avec `--output text`, montre simplement la version cible disponible. La deuxième commande affiche la sortie JSON complète de la réponse. Dans cette réponse, vous pouvez voir des détails tels que la valeur `aurora-mysql` que vous utilisez pour le paramètre `engine`. Vous pouvez également voir le fait que la mise à niveau vers 3.04.0 représente une mise à niveau de version majeure.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
Cet exemple montre pourquoi, si vous saisissez un numéro de version cible qui n’est pas une cible de mise à niveau valide pour le cluster, Aurora n’effectue pas la mise à niveau. Aurora n’effectue pas non plus de mise à niveau de version majeure, sauf si vous incluez le paramètre `--allow-major-version-upgrade`. Ainsi, vous ne pouvez pas effectuer par erreur une mise à niveau susceptible de nécessiter des tests approfondis et des modifications du code de votre application.
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
Quelques instants sont nécessaires pour que l’état du cluster et des instances de base de données associées passe à `upgrading`. Les numéros de version du cluster et des instances de base de données ne changent que lorsque la mise à niveau est terminée. Encore une fois, vous pouvez utiliser la commande `wait db-instance-available` pour l’instance de base de données du scripteur afin d’attendre la fin de la mise à niveau avant de poursuivre.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
À ce stade, le numéro de version du cluster correspond à celui spécifié pour la mise à niveau.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
L’exemple précédent représente une mise à niveau immédiate en spécifiant le paramètre `--apply-immediately`. Pour que la mise à niveau se produise à un moment opportun, lorsque le cluster ne devrait pas être occupé, vous pouvez spécifier le paramètre `--no-apply-immediately`. Il permet de lancer la mise à niveau lors de la prochaine fenêtre de maintenance du cluster. La fenêtre de maintenance définit la période pendant laquelle les opérations de maintenance peuvent commencer. Une opération de longue durée ne doit pas nécessairement se terminer pendant la fenêtre de maintenance. Par conséquent, vous n’avez pas besoin de définir une fenêtre de maintenance plus grande, même si vous pensez que la mise à niveau peut prendre beaucoup de temps.
L’exemple suivant met à niveau un cluster qui exécute initialement Aurora MySQL version 2.11.2. Dans la sortie `describe-db-engine-versions`, les valeurs `False` et `True` représentent la propriété `IsMajorVersionUpgrade`. À partir de la version 2.11.2, vous pouvez effectuer une mise à niveau vers d’autres versions 2.\$1. Ces mises à niveau ne sont pas considérées comme des mises à niveau de version majeures et ne nécessitent donc pas de mise à niveau sur place. La mise à niveau sur place n’est disponible que pour les mises à niveau vers les versions 3.\$1 répertoriées dans la liste.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
Lorsqu’un cluster est créé sans fenêtre de maintenance spécifiée, Aurora choisit un jour de la semaine de manière aléatoire. Ici, la commande `modify-db-cluster` est soumise un lundi. Nous modifions la fenêtre de maintenance et la définissons sur mardi matin. Toutes les heures sont représentées dans le fuseau horaire UTC. La fenêtre `tue:10:00-tue:10:30` correspond à 2h00-2h30, heure du Pacifique. Les modifications de la fenêtre de maintenance prennent effet immédiatement.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
L’exemple suivant montre comment obtenir un rapport sur les événements générés par la mise à niveau. L’argument `--duration` représente le nombre de minutes nécessaire pour récupérer les informations d’événement. Cet argument est requis, car par défaut, `describe-events` renvoie uniquement les événements de la dernière heure.
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Identification de la cause des échecs de mise à niveau de version majeure Aurora MySQL
Dans le [didacticiel](AuroraMySQL.Upgrading.Tutorial.md), la mise à niveau d’Aurora MySQL version 2 vers la version 3 a réussi. Toutefois, si la mise à niveau avait échoué, vous voudriez savoir pourquoi.
Pour ce faire, commencez par utiliser la commande `describe-events` de l’AWS CLI pour examiner les événements du cluster de bases de données. Cet exemple montre les événements liés à `mydbcluster` pendant les 10 dernières heures.
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
Dans ce cas, la vérification préalable de la mise à niveau a échoué.
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
Pour diagnostiquer la cause exacte du problème, examinez les journaux de base de données de l’instance de base de données d’enregistreur. Lorsqu’une mise à niveau vers Aurora MySQL 3 échoue, l’instance contient un fichier journal portant le nom `upgrade-prechecks.log`. Cet exemple montre comment détecter la présence de ce journal, puis comment le télécharger dans un fichier local pour examen.
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--log-file-name upgrade-prechecks.log \
--starting-token 0 \
--output text >upgrade_prechecks.log
```
Le fichier `upgrade-prechecks.log` est au format JSON. Nous le téléchargeons à l’aide de l’option `--output text` afin d’éviter de coder la sortie JSON dans un autre encapsuleur JSON. Pour les mises à niveau d’Aurora MySQL version 3, ce journal inclut toujours certains messages d’information et d’avertissement. Il inclut uniquement des messages d’erreur si la mise à niveau échoue. Si la mise à niveau réussit, le fichier journal n’est pas créé du tout.
Pour résumer toutes les erreurs et afficher les champs d’objet et de description associés, vous pouvez exécuter la commande `grep -A 2 '"level": "Error"'` sur le contenu du fichier `upgrade-prechecks.log`. Cela permet d’afficher chaque ligne d’erreur et les deux lignes qui la suivent. Elles contiennent le nom de l’objet de base de données correspondant et des conseils sur la façon de corriger le problème.
```
$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
```
Dans cet exemple, vous pouvez exécuter la commande SQL suivante sur la table en cause pour tenter de résoudre le problème, ou vous pouvez recréer la table sans l’index suspendu.
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
Réessayez ensuite la mise à niveau.
# Dépannage de la mise à niveau sur place d’Aurora MySQL
Suivez les conseils suivants pour résoudre les problèmes liés aux mises à niveau sur place d’Aurora MySQL. Ces conseils ne s’appliquent pas aux clusters de bases de données Aurora Serverless.
| Pourquoi la mise à niveau sur place s’est arrêtée ou est lente | Effet | Solution permettant à la mise à niveau sur place de se terminer dans la fenêtre de maintenance |
| --- | --- | --- |
| Le réplica entre régions d’Aurora associé n’a pas encore reçu les correctifs requis | Aurora annule la mise à niveau. | Mettez à niveau le réplica entre régions d’Aurora et réessayez. |
| Le cluster a des transactions XA à l’état préparé. | Aurora annule la mise à niveau. | Validez ou restaurez toutes les transactions XA préparées. |
| Le cluster traite toutes les instructions en langage de définition de données (DDL). | Aurora annule la mise à niveau. | Pensez à attendre et à effectuer la mise à niveau une fois toutes les instructions DDL terminées. |
| Le cluster a des modifications non validées pour de nombreuses lignes. | La mise à niveau pourrait prendre beaucoup de temps. | Le processus de mise à niveau restaure les modifications non validées. L’indicateur de cette condition est la valeur de `TRX_ROWS_MODIFIED` dans la table `INFORMATION_SCHEMA.INNODB_TRX`. Prévoyez d’effectuer la mise à niveau uniquement lorsque toutes les transactions volumineuses ont été validées ou restaurées. |
| Le cluster a un nombre élevé d’enregistrements d’annulation. | La mise à niveau pourrait prendre beaucoup de temps. | Même si les transactions non validées affectent peu de lignes, elles peuvent impliquer un grand volume de données. Par exemple, si vous insérez des objets BLOB volumineux, Aurora ne détecte ni ne génère automatiquement d’événement pour ce type d’activité de transaction. L’indicateur de cette condition est la longueur de la liste d’historique (HLL). Le processus de mise à niveau restaure les modifications non validées. Vous pouvez vérifier la liste HLL dans la sortie de la commande SQL `SHOW ENGINE INNODB STATUS` ou directement à l’aide de la requête SQL suivante : SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
Vous pouvez également utiliser la métrique `RollbackSegmentHistoryListLength` dans Amazon CloudWatch. Prévoyez d’effectuer la mise à niveau uniquement une fois que la longueur de la liste HLL sera plus petite. |
| Le cluster est en train de valider une transaction de journal binaire volumineuse | La mise à niveau pourrait prendre beaucoup de temps. | Le processus de mise à niveau attend que les modifications de journaux binaires soient appliquées. Plus de transactions ou d’instructions DDL pourraient commencer pendant cette période, ce qui ralentirait encore le processus de mise à niveau. Planifiez le processus de mise à niveau lorsque le cluster n’est pas occupé à générer des modifications de réplication de journaux binaires. Aurora ne détecte ni ne génère automatiquement d’événement pour cette condition. |
| Incohérences de schéma résultant de la suppression ou de l’endommagement de fichiers | Aurora annule la mise à niveau. | Changez le moteur de stockage par défaut pour les tables temporaires de MyISAM à InnoDB. Procédez comme suit : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| L’utilisateur principal a été supprimé | Aurora annule la mise à niveau. | Ne supprimez pas l’utilisateur principal. Toutefois, si, pour une raison ou une autre, vous venez à supprimer l’utilisateur principal, restaurez-le à l’aide des commandes SQL suivantes : CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
Pour plus de détails sur la résolution des problèmes à l’origine de l’échec des vérifications préalables de la mise à niveau, consultez les blogs suivants :
+ [Liste de contrôle de mise à niveau d’Amazon Aurora MySQL version 2 (avec compatibilité MySQL 5.7) vers la version 3 (avec compatibilité MySQL 8.0), partie 1](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Liste de contrôle de mise à niveau d’Amazon Aurora MySQL version 2 (avec compatibilité MySQL 5.7) vers la version 3 (avec compatibilité MySQL 8.0), partie 2](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
Vous pouvez suivre les étapes suivantes afin d’effectuer vos propres vérifications pour certaines des conditions du tableau précédent. Ainsi, vous pouvez planifier la mise à niveau à un moment où vous savez que la base de données sera dans un état permettant une mise à niveau rapide.
+ Vous pouvez vérifier les transactions XA ouvertes en exécutant l’instruction `XA RECOVER`. Vous pouvez ensuite valider ou restaurer les transactions XA avant de lancer la mise à niveau.
+ Vous pouvez vérifier les instructions DDL en exécutant une instruction `SHOW PROCESSLIST` et en recherchant les instructions `CREATE``DROP`, `ALTER`, `RENAME` et `TRUNCATE` dans la sortie. Laissez toutes les instructions DDL se terminer avant de commencer la mise à niveau.
+ Vous pouvez vérifier le nombre total de lignes non validées en interrogeant la table `INFORMATION_SCHEMA.INNODB_TRX`. La table contient une ligne pour chaque transaction. La colonne `TRX_ROWS_MODIFIED` contient le nombre de lignes modifiées ou insérées par la transaction.
+ Vous pouvez vérifier la longueur de la liste d’historique InnoDB en exécutant l’instruction `SHOW ENGINE INNODB STATUS SQL` et en recherchant la valeur `History list length` dans la sortie. Vous pouvez également vérifier la valeur directement en exécutant la requête suivante :
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
La longueur de la liste d’historique correspond à la quantité d’informations d’annulation stockées par la base de données pour implémenter le contrôle de concurrence multi-version (MVCC).
# Nettoyage postérieur à la mise à niveau pour Aurora MySQL version 3
Une fois que vous avez terminé de mettre à niveau un cluster Aurora MySQL version 2 vers Aurora MySQL version 3, vous pouvez effectuer les autres actions de nettoyage suivantes :
+ Créez de nouvelles versions compatibles avec MySQL 8.0 de tous les groupes de paramètres personnalisés. Appliquez toutes les valeurs de paramètres personnalisés nécessaires aux nouveaux groupes de paramètres.
+ Mettez à jour toutes les alarmes CloudWatch, les scripts de configuration, etc. pour utiliser les nouveaux noms pour toutes les métriques dont les noms ont été affectés par des changements linguistiques inclusifs. Pour connaître la liste des métriques concernées, consultez [Changements linguistiques inclusifs pour Aurora MySQL version 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
+ Mettez à jour tous les modèles CloudFormation pour utiliser les nouveaux noms pour tous les paramètres de configuration dont les noms ont été affectés par des modifications linguistiques inclusives. Pour obtenir la liste des paramètres convernés, consultez [Changements linguistiques inclusifs pour Aurora MySQL version 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
## Index spatiaux
Après la mise à niveau vers Aurora MySQL version 3, vérifiez si vous devez supprimer ou recréer des objets et des index liés aux index spatiaux. Avant MySQL 8.0, Aurora pouvait optimiser les requêtes spatiales à l’aide d’index qui ne contenaient pas d’identifiant de ressource spatiale (SRID). Aurora MySQL version 3 utilise uniquement des index spatiaux contenant des SRID. Lors d’une mise à niveau, Aurora supprime automatiquement tous les index spatiaux sans SRID et imprime des messages d’avertissement dans le journal de base de données. Si vous observez de tels messages d’avertissement, créez de nouveaux index spatiaux avec des SRID après la mise à niveau. Pour plus d’informations sur les modifications apportées aux fonctions spatiales et les types de données dans MySQL 8.0, consultez [Changements dans MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)dans le *manuel de référence MySQL*.