Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# 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).