Mise à niveau de la version majeure d'un cluster de bases de données Amazon Aurora MySQL - Amazon Aurora
Mise à niveau d'Aurora MySQL version 2 vers la version 3Planification d'une mise à niveau de version majeure d'un cluster Aurora MySQL Prévérifications de mise à niveau des versions majeures pour Aurora MySQLChemins de mise à niveau d'une version majeure Aurora MySQLFonctionnement de la mise à niveau sur place d'une version majeure de Aurora MySQLDéploiements bleu/vertComment effectuer une mise à niveau sur placeComment les mises à niveau sur place affectent les groupes de paramètres d'un clusterModifications apportées aux propriétés du cluster entre les versions d'Aurora MySQLMises à niveau majeures sur place des bases de données globalesConsidérations relatives au retour en arrièreTutoriel de mise à niveau sur place d'Aurora MySQLDéterminer les causes des échecs de mise à niveauDépannage de la mise à niveau sur place d'Aurora MySQLNettoyage postérieur à la mise à niveau pour Aurora MySQL version 3

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.

Mise à niveau de la version majeure d'un cluster de bases de données Amazon Aurora MySQL

Dans un numéro de version d'Aurora MySQL tel que 2.12.1, le 2 représente la version majeure. Aurora MySQL version 2 est déjà compatible avec MySQL 5.7. Aurora MySQL version 3 est déjà compatible avec MySQL 8.0.

La mise à niveau entre les versions majeures nécessite une planification et des tests plus étendus que pour une version mineure. Le processus peut prendre beaucoup de temps. Une fois la mise à niveau terminée, il se peut que vous ayez également un travail de suivi à faire, Par exemple, cela peut se produire en raison des différences de compatibilité SQL ou du fonctionnement de certaines fonctions liées à MySQL. Cela peut également se produire en raison de paramètres différents entre l'ancienne et la nouvelle version.

Mise à niveau d'Aurora MySQL version 2 vers la version 3

Si vous avez un cluster compatible MySQL 5.7 et souhaitez le mettre à niveau vers un cluster compatible MySQL 8.0, vous pouvez le faire en exécutant un processus de mise à niveau sur le cluster lui-même. Ce type de mise à niveau est appelé mise à niveau sur place, en opposition aux mises à niveau que vous effectuez en créant un nouveau cluster. Cette technique conserve le point de terminaison et d'autres caractéristiques du cluster. La mise à niveau est relativement rapide car elle ne nécessite pas la copie de toutes vos données vers un nouveau volume de cluster. Cette stabilité permet de réduire au minimum les modifications de configuration de vos applications. Elle aide également à réduire la quantité de tests du cluster mis à niveau. En effet, le nombre d'instances de base de données et leurs classes d'instance restent les mêmes.

Le mécanisme de mise à niveau sur place implique l'arrêt de votre cluster de bases de données pendant que l'opération. Aurora effectue un arrêt propre et termine les opérations en suspens telles que la restauration des transactions et la purge des annulations. Pour plus d’informations, consultez Fonctionnement de la mise à niveau sur place d'une version majeure de Aurora MySQL.

La méthode de mise à niveau sur place est pratique, car elle est simple à effectuer et réduit au minimum les modifications de configuration des applications associées. Par exemple, une mise à niveau sur place conserve les points de terminaison et l'ensemble d'instances de base de données de votre cluster. Toutefois, le temps nécessaire pour une mise à niveau sur place peut varier en fonction des propriétés de votre schéma et du niveau d'activité de votre cluster. Ainsi, en fonction des besoins de votre cluster, vous pouvez choisir parmi les techniques de mise à niveau suivantes :

Pour obtenir des informations générales sur Aurora MySQL version 3, ainsi que ses nouvelles fonctions, consultez Aurora MySQL version 3 compatible avec MySQL 8.0.

Pour plus de détails sur la planification d'une mise à niveau, consultez Planification d'une mise à niveau de version majeure d'un cluster Aurora MySQL et Comment effectuer une mise à niveau sur place.

Planification d'une mise à niveau de version majeure d'un cluster Aurora MySQL

Pour vous aider à choisir le bon moment et la bonne approche pour effectuer la mise à niveau, vous pouvez découvrir les différences entre la version 3 d'Aurora MySQL et votre environnement actuel :

Vous trouverez également d'autres considérations et astuces de mise à niveau spécifiques à MySQL dans Changements dans MySQL 8.0 dans le manuel de référence MySQL. Par exemple, vous pouvez utiliser la commande mysqlcheck --check-upgrade pour analyser les bases de données Aurora MySQL existantes et identifier les problèmes potentiels de mise à niveau.

Note

Nous recommandons d'utiliser des classes d'instance de base de données plus importantes lors de la mise à niveau vers Aurora MySQL version 3 en utilisant la technique de mise à niveau sur place ou de restauration des instantanés. Exemples : db.r5.24xlarge et db.r6g.16xlarge. Cela permet au processus de mise à niveau de se terminer plus rapidement en utilisant la majorité de la capacité CPU disponible sur l'instance de base de données. Vous pouvez passer à la classe d'instance de base de données de votre choix une fois la mise à niveau de la version majeure terminée.

Une fois la mise à niveau terminée, vous pouvez suivre les procédures post-mise à niveau dans Nettoyage postérieur à la mise à niveau pour Aurora MySQL version 3. Enfin, testez les fonctionnalités et les performances de votre application.

Si vous effectuez une conversion depuis RDS depuis MySQL ou la communauté MySQL, suivez la procédure de migration expliquée dansMigration de données vers un cluster de base de données Amazon Aurora MySQL. Dans certains cas, vous pouvez utiliser la réplication des journaux binaires pour synchroniser vos données avec un cluster Aurora MySQL version 3 dans le cadre de la migration. Si tel est le cas, le système source doit exécuter une version compatible avec votre cluster de base de données cible.

Pour vous assurer que vos applications et procédures d'administration fonctionnent correctement après la mise à niveau d'un cluster entre les versions majeures, effectuez une planification et une préparation anticipées. Pour connaître les types de code de gestion à mettre à jour pour vos AWS CLI scripts ou applications basées sur l'API RDS, consultez. Comment les mises à niveau sur place affectent les groupes de paramètres d'un cluster Voir aussi Modifications apportées aux propriétés du cluster entre les versions d'Aurora MySQL.

Pour connaître les problèmes que vous pourriez rencontrer lors de la mise à niveau, consultezDépannage de la mise à niveau sur place d'Aurora MySQL. Pour les problèmes pouvant entraîner une mise à niveau longue, vous pouvez tester ces conditions au préalable et les corriger.

Note

Une mise à niveau sur place implique l'arrêt de votre cluster de base de données pendant l'opération. Aurora MySQL effectue un arrêt complet et effectue les opérations en suspens, telles que l'annulation de la purge. Une mise à niveau peut prendre beaucoup de temps s'il y a de nombreux enregistrements annulés à purger. Nous recommandons d'effectuer la mise à niveau uniquement lorsque la longueur de la liste d'historique (HLL) est faible. Une valeur généralement acceptable pour le HLL est de 100 000 ou moins. Pour plus d'informations, consultez ce billet de blog.

Simulation de la mise à niveau en clonant votre cluster de base de données

Vous pouvez vérifier la compatibilité des applications, les performances, les procédures de maintenance et d'autres considérations pour le cluster mis à niveau. Pour ce faire, vous pouvez effectuer une simulation de la mise à niveau avant de procéder à la mise à niveau elle-même. Cette technique peut être particulièrement utile pour les clusters de production. Ici, il est important de limiter les temps d'arrêt et que le cluster mis à niveau soit opérationnel dès la fin de la mise à niveau.

Procédez comme suit :

  1. Créez un clone du cluster d'origine. Suivez la procédure décrite dans Clonage d'un volume pour un cluster de base de données Amazon Aurora.

  2. Configurez un ensemble d'instances de base de données d'écriture et de lecture similaire à celui du cluster d'origine.

  3. Effectuez une mise à niveau sur place du cluster cloné. Suivez la procédure décrite dans Comment effectuer une mise à niveau sur place.

    Démarrez la mise à niveau immédiatement après avoir créé le clone. Ainsi, le volume de cluster reste identique à l'état du cluster d'origine. Si le clone est inactif avant la mise à niveau, Aurora effectue des processus de nettoyage de base de données en arrière-plan. Dans ce cas, la mise à niveau du clone n'est pas une simulation précise de la mise à niveau du cluster d'origine.

  4. Testez la compatibilité des applications, les performances, les procédures d'administration, etc., à l'aide du cluster cloné.

  5. Si vous rencontrez des problèmes, modifiez vos plans de mise à niveau de manière à en tenir compte. Par exemple, adaptez n'importe quel code d'application pour qu'il soit compatible avec le jeu de fonctions de la version ultérieure. Estimez la durée de la mise à niveau en fonction de la quantité de données dans votre cluster. Vous pouvez également choisir de planifier la mise à niveau à un moment où le cluster n'est pas occupé.

  6. Après avoir vérifié le bon fonctionnement de vos applications et de votre charge de travail avec le cluster de test, vous pouvez effectuer la mise à niveau sur place de votre cluster de production.

  7. Essayez de limiter le temps d'arrêt total de votre cluster pendant une mise à niveau de version majeure. Pour ce faire, assurez-vous que la charge de travail sur le cluster est faible ou nulle au moment de la mise à niveau. En particulier, assurez-vous qu'aucune transaction longue n'est en cours lorsque vous lancez la mise à niveau.

Utilisation de la technique de mise à niveau bleu-vert

Vous pouvez également créer un déploiement bleu/vert qui exécute les anciens et les nouveaux clusters. side-by-side Dans ce cas, répliquez les données de l'ancien cluster au nouveau jusqu'à ce que ce dernier soit prêt à prendre le relais. Pour plus de détails, consultez Utilisation des déploiements bleu/vert Amazon RDS pour les mises à jour de base de données.

Prévérifications de mise à niveau des versions majeures pour Aurora MySQL

MySQL 8.0 inclut plusieurs incompatibilités avec MySQL 5.7. Ces incompatibilités peuvent entraîner des problèmes lors d'une mise à niveau d'Aurora MySQL version 2 vers la version 3. Une certaine préparation de votre base de données peut être nécessaire pour que la mise à niveau soit réussie.

Lorsque vous lancez une mise à niveau d'Aurora MySQL version 2 vers la version 3, Amazon Aurora exécute automatiquement des prévérifications pour détecter ces incompatibilités.

Ces vérifications préalables sont obligatoires. Vous ne pouvez pas choisir de les ignorer. Elles offrent les avantages suivants :

  • Elles vous permettent d'éviter les temps d'arrêts non planifiés pendant la mise à niveau.

  • En cas d'incompatibilités, Amazon Aurora empêche la mise à niveau et fournit un journal pour que vous puissiez en savoir plus. Vous pouvez ensuite utiliser le journal pour préparer votre base de données pour la mise à niveau vers la version 3 en réduisant les incompatibilités. Pour obtenir des informations détaillées sur la suppression des incompatibilités, consultez Préparation de votre installation pour la mise à niveau (langue française non garantie) dans la documentation MySQL et Mise à niveau vers MySQL 8.0 ? Ce que vous devez savoir… (langue française non garantie) sur le blog MySQL Server.

    Pour plus d'informations sur la mise à niveau vers MySQL 8.0, consultez la section Mise à niveau de MySQL dans la documentation MySQL.

Les prévérifications incluent certaines qui sont incluses dans MySQL et d'autres qui ont été créées spécifiquement par l'équipe Aurora. Pour de plus amples informations sur les vérifications préalables fournies par MySQL, veuillez consulter Upgrade Checker Utility.

Les vérifications préalables s'exécutent avant que l'instance de base de données soit arrêtée pour la mise à niveau, ce qui signifie que leur exécution n'entraîne aucun temps d'arrêt. Si les prévérifications révèlent une incompatibilité, Aurora annule automatiquement la mise à niveau avant que l'instance de base de données ne soit arrêtée. Aurora génère également un événement pour l'incompatibilité. Pour plus d'informations sur les événements Amazon Aurora, consultezUtiliser la notification d'événements d'Amazon RDS.

Aurora enregistre des informations détaillées sur chaque incompatibilité dans le fichier PrePatchCompatibility.log journal. Dans la plupart des cas, l'entrée de journal inclut un lien vers la documentation MySQL permettant de corriger l'incompatibilité. Pour de plus amples informations sur l'affichage des fichiers journaux, veuillez consulter Liste et affichage des fichiers journaux de base de données.

En raison de la nature des vérifications préalables, elle analysent les objets dans votre base de données. L'analyse entraîne la consommation de ressources et augmente le temps nécessaire pour la mise à niveau.

Prévérifications de mise à niveau de MySQL par la communauté

Voici une liste générale des incompatibilités entre MySQL 5.7 et 8.0 :

  • Votre cluster de base de données compatible avec MySQL 5.7 ne doit pas utiliser de fonctionnalités qui ne sont pas prises en charge dans MySQL 8.0.

    Pour en savoir plus, consultez Fonctionnalités supprimées dans MySQL 8.0 dans la documentation MySQL.

  • Il ne doit y avoir aucune violation de mot clé ou de mot réservé. Certains mots clés doivent être réservés dans MySQL 8.0 alors qu'ils ne l'étaient pas par le passé.

    Pour en savoir plus, consultez Mots clés et mots réservés dans la documentation MySQL.

  • Pour une meilleure prise en charge d'Unicode, envisagez de convertir les objets qui utilisent le jeu de caractères utf8mb3 pour utiliser le jeu de caractères utf8mb4. Le jeu de caractères utf8mb3 est obsolète. Envisagez également d'utiliser utf8mb4 pour référencer les jeux de caractères au lieu de utf8. Actuellement, utf8 est un alias du jeu de caractères utf8mb3.

    Pour en savoir plus, consultez Le jeu de caractères utf8mb3 (encodage Unicode 3 octets en UTF-8) dans la documentation MySQL.

  • Il ne doit y avoir aucune table InnoDB avec un format de ligne autre que celui par défaut.

  • Il ne doit y avoir aucun attribut ZEROFILL ou un attribut de type display longueur.

  • Aucune table partitionnée ne doit utiliser de moteur de stockage dépourvu de prise en charge native du partitionnement.

  • Aucune table de la base de données du système mysqldans MySQL 5.7 ne doit avoir le même nom que la table utilisée dans le dictionnaire de données MySQL 8.0.

  • Les tables ne doivent pas utiliser de fonctions ou de types de données obsolètes.

  • Aucun nom de contrainte de clé étrangère ne doit dépasser 64 caractères.

  • Aucun mode SQL obsolète ne doit être défini dans la configuration variable de votre système sql_mode.

  • Aucune table ou procédure stockée ne doit comporter d'éléments individuels ENUM ou de SET colonnes dont la longueur dépasse 255 caractères.

  • Aucune partition de table ne doit résider dans des tablespaces InnoDB partagés.

  • Il ne doit pas y avoir de références circulaires dans les chemins des fichiers de données des tablespaces.

  • Aucune requête ASC ou définition de programme enregistrée ne doit utiliser de DESC qualificatif pour les GROUP BY clauses.

  • Aucune variable système ne doit être supprimée, et les variables système doivent utiliser les nouvelles valeurs par défaut pour MySQL 8.0.

  • Il ne doit y avoir aucune valeur de date, de date/heure ou d'horodatage zéro (0).

  • Aucune incohérence du schéma ne doit résulter de la suppression ou de la corruption d'un fichier.

  • Aucun nom de table ne doit contenir la chaîne de FTS caractères.

  • Aucune table InnoDB ne doit appartenir à un autre moteur.

  • Aucun nom de table ou de schéma ne doit être invalide pour MySQL 5.7.

Pour plus d'informations sur la mise à niveau vers MySQL 8.0, consultez la section Mise à niveau de MySQL dans la documentation MySQL.

Prévérifications de mise à niveau d'Aurora MySQL

Aurora MySQL a ses propres exigences spécifiques lors de la mise à niveau de la version 2 vers la version 3 :

  • Il ne doit pas y avoir de syntaxe SQL obsolète, telle que, et SQL_CACHESQL_NO_CACHE, dans les vuesQUERY_CACHE, les routines, les déclencheurs et les événements.

  • Aucune FTS_DOC_ID colonne ne doit être présente sur une table sans l'FTSindex.

  • Il ne doit y avoir aucune incompatibilité de définition de colonne entre le dictionnaire de données InnoDB et la définition de table réelle.

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

  • Les événements et les déclencheurs ne doivent pas comporter de définisseur manquant ou vide, ni de contexte de création non valide.

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

  • La restauration DDL et Fast DDL ne sont pas prises en charge dans Aurora MySQL version 3. Les bases de données ne doivent contenir aucun artefact lié à ces fonctionnalités.

  • Les tables au format de COMPACT ligne REDUNDANT ou ne peuvent pas avoir d'index supérieurs à 767 octets.

  • La longueur du préfixe des index définis sur les colonnes de tiny texte ne peut pas dépasser 255 octets. Avec le jeu de utf8mb4 caractères, cela limite la longueur du préfixe prise en charge à 63 caractères.

    Une longueur de préfixe plus grande a été autorisée dans MySQL 5.7 en utilisant le innodb_large_prefix paramètre. Ce paramètre est obsolète dans MySQL 8.0.

  • Il ne doit y avoir aucune incohérence des métadonnées InnoDB dans la table. mysql.host

  • Il ne doit pas y avoir de différence de type de données de colonne dans les tables système.

  • Il ne doit y avoir aucune transaction XA dans l'preparedÉtat.

  • Les noms de colonnes dans les vues ne peuvent pas dépasser 64 caractères.

  • Les caractères spéciaux des procédures stockées ne peuvent pas être incohérents.

  • Les tables ne peuvent pas présenter d'incohérence entre les chemins des fichiers de données.

Chemins de mise à niveau d'une version majeure Aurora MySQL

Tous les types ou versions de clusters Aurora MySQL ne peuvent pas utiliser le mécanisme de mise à niveau sur place. Consultez le tableau suivant pour connaître le chemin de mise à niveau approprié pour chaque cluster Aurora MySQL.

Type de cluster de bases de données Aurora MySQL Peut-il utiliser la mise à niveau sur place ? Action

Cluster Aurora MySQL alloué, version 2.0 ou supérieure

Oui

La mise à niveau sur place est prise en charge pour les clusters Aurora MySQL compatibles 5.7.

Pour en savoir plus sur la mise à niveau vers Aurora MySQL version 3, consultez Planification d'une mise à niveau de version majeure d'un cluster Aurora MySQL et Comment effectuer une mise à niveau sur place.

Cluster Aurora MySQL alloué, version 3.01.0 ou ultérieure

N/A

Utilisez une procédure de mise à niveau de version mineure pour passer aux versions Aurora MySQL version 3.

Aurora Serverless v1Cluster

N/A

Actuellement, Aurora Serverless v1 n'est pris en charge pour Aurora MySQL que sur la version 2.

Aurora Serverless v2Cluster

N/A

 Actuellement, Aurora Serverless v2 est uniquement pris en charge pour Aurora MySQL version 3.

Cluster d'une base de données Aurora globale

Oui

Pour mettre à niveau Aurora MySQL de la version 2 vers la version 3, suivez la procédure de mise à niveau sur place pour les clusters d'une base de données Aurora globale. Effectuez la mise à niveau sur le cluster global. Aurora met à niveau le cluster principal et tous les clusters secondaires dans la base de données globale en même temps.

Si vous utilisez l'API AWS CLI ou RDS, appelez la modify-global-cluster commande ou l'ModifyGlobalClusteropération au lieu de modify-db-cluster ouModifyDBCluster.

Vous ne pouvez pas effectuer une mise à niveau sur place d'Aurora MySQL version 2 vers la version 3 si le paramètre lower_case_table_names est activé. Pour plus d’informations, consultez Mises à niveau de version majeure..

Cluster compatible avec les requêtes parallèles

Oui

Vous pouvez effectuer une mise à niveau sur place. Dans ce cas, choisissez 2.09.1 ou une version supérieure de Aurora MySQL.

Cluster cible de la réplication de journaux binaires

Peut-être

Si la réplication de journaux binaires provient d'un cluster Aurora MySQL, vous pouvez effectuer une mise à niveau sur place. Vous ne pouvez pas effectuer la mise à niveau si la réplication de journaux binaires provient d'une instance de RDS pour MySQL ou d'une instance de base de données MySQL sur site. Dans ce cas, vous pouvez effectuer la mise à niveau à l'aide du mécanisme de restauration d'instantané.

Cluster sans instances de base de données

Non

À l'aide de l'API AWS CLI ou de l'API RDS, vous pouvez créer un cluster Aurora MySQL sans aucune instance de base de données attachée. De la même manière, vous pouvez supprimer toutes les instances de base de données d'un cluster Aurora MySQL tout en laissant les données du volume de cluster intactes. Lorsqu'un cluster ne comporte aucune instance de base de données, vous ne pouvez pas effectuer une mise à niveau sur place.

Le mécanisme de mise à niveau nécessite une instance de scripteur dans le cluster pour effectuer des conversions sur les tables système, les fichiers de données, etc. Dans ce cas, utilisez l'API AWS CLI ou l'API RDS pour créer une instance d'écriture pour le cluster. Ensuite, vous pouvez effectuer une mise à niveau sur place.

Cluster avec retour sur trace activé

Oui

Vous pouvez effectuer une mise à niveau sur place pour un cluster Aurora MySQL utilisant la fonction de retour sur trace. Toutefois, après la mise à niveau, vous ne pouvez pas effectuer de retour sur trace du cluster à un moment antérieur à la mise à niveau.

Fonctionnement de la mise à niveau sur place d'une version majeure de Aurora MySQL

Aurora MySQL effectue les mises à niveau de version majeure en tant que processus en plusieurs étapes. Vous pouvez vérifier l'état actuel d'une mise à niveau. Certaines étapes de la mise à niveau fournissent également des informations sur l'état d'avancement. Au début de chaque étape, Aurora MySQL enregistre un événement. Vous pouvez examiner les événements lorsqu'ils ont lieu sur la page Events (Événements) de la console RDS. Pour en savoir plus sur l'utilisation des événements, consultez Utiliser la notification d'événements d'Amazon RDS.

Important

Une fois que le processus a démarré, il se poursuit jusqu'à ce que la mise à niveau réussisse ou échoue. Vous ne pouvez pas annuler la mise à niveau tant qu'elle est en cours. Si la mise à niveau échoue, Aurora annule toutes les modifications et votre cluster garde la même version du moteur, ainsi que les mêmes métadonnées et autres éléments qu'auparavant.

Le processus de mise à niveau comporte les étapes suivantes :

  1. Aurora effectue une série de prévérifications avant de commencer le processus de mise à niveau. Votre cluster continue de fonctionner pendant que Aurora effectue ces vérifications. Par exemple, le cluster ne peut pas avoir de transactions XA à l'état préparé ou être en train de traiter des instructions en langage de définition de données (DDL). Par exemple, il se peut que vous deviez arrêter les applications qui soumettent certains types d'instructions SQL. Vous pouvez également attendre simplement que certaines instructions à longue exécution soient terminées. Ensuite, tentez de relancer la mise à niveau. Certaines vérifications consistent à examiner les conditions n'empêchant pas la mise à niveau, mais peuvent prendre beaucoup de temps.

    Si Aurora détecte que les conditions requises ne sont pas réunies, modifiez les conditions identifiées dans les détails de l'événement. Suivez les instructions dans Dépannage de la mise à niveau sur place d'Aurora MySQL. Si Aurora détecte des conditions susceptibles de ralentir la mise à niveau, prévoyez de surveiller la mise à niveau sur une longue période.

  2. Aurora met votre cluster hors ligne. Aurora effectue ensuite un ensemble de tests similaire à celui de l'étape précédente pour confirmer qu'aucun problème n'est apparu pendant le processus d'arrêt. Si Aurora détecte à ce stade des conditions pouvant empêcher la mise à niveau, Aurora annule la mise à niveau et remet le cluster en ligne. Dans ce cas, indiquez quand les conditions ne s'appliquent plus et relancez la mise à niveau.

  3. Aurora crée un instantané de votre volume de cluster. Supposons que vous découvriez la compatibilité ou d'autres types de problèmes une fois la mise à niveau terminée. Ou supposons que vous souhaitiez effectuer des tests à l'aide des clusters d'origine et des clusters mis à niveau. Dans ce cas, vous pouvez effectuer une restauration à partir de cet instantané pour créer un nouveau cluster avec la version du moteur d'origine et les données d'origine.

    Astuce

    Cet instantané est un instantané manuel. Cependant, Aurora peut le créer et poursuivre le processus de mise à niveau, même si vous avez atteint votre quota d'instantanés manuels. Cet instantané reste permanent (si nécessaire) jusqu'à ce que vous le supprimiez. Une fois tous les tests postérieurs à la mise à niveau terminés, vous pouvez supprimer cet instantané pour réduire les frais de stockage.

  4. Aurora clone votre volume de cluster. Le clonage est une opération rapide qui n'implique pas la copie des données de la table elles-mêmes. Si Aurora rencontre un problème lors de la mise à niveau, les données d'origine du volume de cluster cloné sont restaurées et le cluster est remis en ligne. Le volume cloné temporairement pendant la mise à niveau n'est pas soumis à la limite habituelle du nombre de clones pour un seul volume de cluster.

  5. Aurora effectue un arrêt propre de l'instance de base de données du scripteur. Pendant l'arrêt propre, les événements de progression sont enregistrés toutes les 15 minutes pour les opérations suivantes. Vous pouvez examiner les événements lorsqu'ils ont lieu sur la page Events (Événements) de la console RDS.

    • Aurora purge les enregistrements d'annulation des anciennes versions des lignes.

    • Aurora restaure toutes les transactions non validées.

  6. Aurora met à niveau la version du moteur de l'instance de base de données du scripteur :

    • Aurora installe le fichier binaire de la nouvelle version du moteur de l'instance de base de données du scripteur.

    • Aurora utilise l'instance de base de données du scripteur pour mettre à niveau vos données au format compatible MySQL 5.7. Lors de cette étape, Aurora modifie les tables système et effectue d'autres conversions qui affectent les données de votre volume de cluster. En particulier, Aurora met à niveau les métadonnées de partition dans les tables système pour qu'elles soient compatibles avec le format de partition MySQL 5.7. Cette étape peut prendre beaucoup de temps si les tables de votre cluster ont de nombreuses partitions.

      Si des erreurs se produisent au cours de cette étape, vous pouvez trouver les détails dans les journaux d'erreurs MySQL. Une fois cette étape démarrée, si le processus de mise à niveau échoue pour une raison quelconque, Aurora restaure les données d'origine du volume de cluster cloné.

  7. Aurora met à niveau la version du moteur des instances de base de données du scripteur.

  8. Le processus de mise à niveau est terminé. Aurora enregistre un événement final pour indiquer que le processus de mise à niveau s'est terminé avec succès. Votre cluster de bases de données exécute désormais la nouvelle version majeure.

Déploiements bleu/vert

Dans certains cas, votre priorité absolue est d'effectuer une commutation immédiate de l'ancien cluster vers un cluster mis à niveau. Dans de telles situations, vous pouvez utiliser un processus en plusieurs étapes qui exécute les anciens et les nouveaux clusters side-by-side. Dans ce cas, répliquez les données de l'ancien cluster au nouveau jusqu'à ce que ce dernier soit prêt à prendre le relais. Pour plus de détails, consultez Utilisation des déploiements bleu/vert Amazon RDS pour les mises à jour de base de données.

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.

Effectuez toute planification et tous les tests préalables à la mise à niveau, comme décrit dansPlanification d'une mise à niveau de version majeure d'un cluster Aurora MySQL.

L'exemple suivant met à niveau le mydbcluster-cluster cluster de base de données 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 console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

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

  3. Dans la panneau de navigation, choisissez Databases (Bases de données).

  4. Dans la liste, sélectionnez le cluster de bases de données à modifier.

  5. Sélectionnez Modify.

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

  7. Choisissez Continuer.

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

  9. (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 pour connaître les étapes à suivre.

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

    Note

    Pour effectuer cette étape, vous devez redémarrer le cluster afin d'appliquer le nouveau groupe de paramètres.

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

Pour mettre à niveau la version majeure d'un cluster de base de données Aurora MySQL, utilisez la commande AWS CLI modify-db-cluster avec les paramètres obligatoires 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 sample-cluster cluster de base de données vers Aurora MySQL version 3.04.1. La mise à niveau se produit immédiatement, au lieu d'attendre la fenêtre de maintenance suivante.

Exemple

Pour LinuxmacOS, 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

Dans 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 CLI modify-db-cluster pour créer un end-to-end processus automatisé d'exécution et de vérification des mises à niveau. Pour plus d'informations et d'exemples, consultez Tutoriel de mise à niveau sur place d'Aurora MySQL.

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 au lieu de modify-db-cluster. Pour plus d'informations, consultez Mises à niveau majeures sur place des bases de données globales.

Pour mettre à niveau la version majeure d'un cluster de bases de données Aurora MySQL, utilisez l'opération d'API RDS ModifyDBCluster 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. Vous appelez l'opération ModifyGlobalCluster au lieu deModifyDBCluster. Pour plus d’informations, consultez Mises à niveau majeures sur place des bases de données globales.

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 pas effectuer une mise à niveau sur place d'Aurora MySQL version 2 vers la version 3 si le paramètre lower_case_table_names est activé. Pour plus d'informations sur les méthodes que vous pouvez utiliser, consultez Mises à niveau de version majeure..

Important

Si vous spécifiez un groupe de paramètres personnalisé pendant le processus de mise à niveau, assurez-vous de redémarrer manuellement le cluster une fois la mise à niveau terminée. Ainsi, le cluster commencera à utiliser vos paramètres personnalisés.

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 base 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. Lorsque vous spécifiez ce qui doit être mis à niveau, veillez à choisir le cluster de base de données global plutôt que l'un des clusters qu'il contient.

Si vous utilisez le AWS Management Console, choisissez l'élément avec le rôle Base de données globale.

Mise à niveau du cluster de base de données

Si vous utilisez l'API AWS CLI ou RDS, lancez le processus de mise à niveau en appelant la commande modify-global-cluster ou l'opération Cluster. ModifyGlobal 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 base 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 base de données global Aurora MySQL à l'aide de AWS CLI, utilisez la commande modify-global-cluster avec les paramètres obligatoires 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 2.10.2.

Exemple

Pour LinuxmacOS, ou Unix :

aws rds modify-global-cluster \
          --global-cluster-identifier global_cluster_identifier \
          --engine aurora-mysql \
          --engine-version 5.7.mysql_aurora.2.10.2 \
          --allow-major-version-upgrade

Dans Windows :

aws rds modify-global-cluster ^
          --global-cluster-identifier global_cluster_identifier ^
          --engine aurora-mysql ^
          --engine-version 5.7.mysql_aurora.2.10.2 ^
          --allow-major-version-upgrade

Considérations relatives au retour en arrière

Si le cluster que vous avez mis à niveau avait le retour sur trace activé, vous ne pouvez pas effectuer un retour sur trace du cluster mis à niveau à une heure antérieure à celle de la mise à niveau.

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 base 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.10.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 d'Aurora MySQL 3.x vers lesquelles vous pouvez mettre à niveau le cluster dépendent de la version 2.x que le cluster exécute actuellement et de l' Région AWS emplacement du cluster. 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.02.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.10.2

aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
  --query '*[].[ValidUpgradeTarget]'
...
{
    "Engine": "aurora-mysql",
    "EngineVersion": "8.0.mysql_aurora.3.02.0",
    "Description": "Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23)",
    "AutoUpgrade": false,
    "IsMajorVersionUpgrade": true,
    "SupportedEngineModes": [
        "provisioned"
    ],
    "SupportsParallelQuery": true,
    "SupportsGlobalDatabases": true,
    "SupportsBabelfish": 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.10.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.02.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.02.0 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "mynewdbcluster",
  "Status": "available",
  "Engine": "aurora-mysql",
  "EngineVersion": "5.7.mysql_aurora.2.10.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.10.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.02.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.10.2. Dans la sortie describe-db-engine-versions, les valeurs False et True représentent la propriété IsMajorVersionUpgrade. À partir de la version 2.10.2, vous pouvez effectuer une mise à niveau vers d'autres versions 2.*. 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.* 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.10.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.10.3 False
5.7.mysql_aurora.2.11.0 False
5.7.mysql_aurora.2.11.1 False
8.0.mysql_aurora.3.01.1 True
8.0.mysql_aurora.3.02.0 True
8.0.mysql_aurora.3.02.2 True


aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
  --engine-version 8.0.mysql_aurora.3.02.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 nécessaire, car par défaut, describe-events seuls les événements de la dernière heure sont renvoyés.

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

Déterminer les causes des échecs de mise à niveau

Dans le didacticiel précédent, la mise à niveau de la version 2 vers la version 3 d'Aurora MySQL a réussi. Mais si la mise à niveau avait échoué, vous voudriez savoir pourquoi.

Vous pouvez commencer par utiliser la describe-events AWS CLI commande pour examiner les événements du cluster de base de données. Cet exemple montre les événements mydbcluster des 10 dernières heures.

aws rds describe-events \
    --source-type db-cluster \
    --source-identifier mydbcluster \
    --duration 600

Dans ce cas, nous avons eu un échec lors de la pré-vérification de la mise à niveau.

{
    "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.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Troubleshooting.",
            "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 du rédacteur. Lorsqu'une mise à niveau vers la version 3 d'Aurora MySQL échoue, l'instance du rédacteur contient un fichier journal portant le nomupgrade-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 upgrade-prechecks.log fichier. 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
La réplique interrégionale Aurora associée n'est pas encore corrigée Aurora annule la mise à niveau. Mettez à niveau la réplique interrégionale 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 le HLL dans la sortie de la commande SHOW ENGINE INNODB STATUS SQL 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 surveiller la RollbackSegmentHistoryListLength métrique sur Amazon CloudWatch.

Envisagez d'effectuer la mise à niveau uniquement lorsque le HLL est plus petit.
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 :

  1. Modifiez le paramètre de base de données default_tmp_storage_engine en spécifiant InnoDB.

  2. Redémarrez le cluster de bases de données.

  3. Après le redémarrage, confirmez que le paramètre de base de données default_tmp_storage_engine est défini sur InnoDB. Utilisez la commande suivante :

    show global variables like 'default_tmp_storage_engine';

  4. Veillez à ne pas créer de tables temporaires utilisant le moteur de stockage MyISAM. Nous vous recommandons de suspendre toute charge de travail de base de données et de ne pas créer de nouvelles connexions de base de données, car vous allez bientôt effectuer une mise à niveau.

  5. Réessayez la mise à niveau sur place.
L'utilisateur principal a été supprimé Aurora annule la mise à niveau.
Important

Ne supprimez pas l'utilisateur principal.

Toutefois, si, pour une raison ou une autre, vous deviez 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 prévérifications de mise à niveau, consultez les blogs suivants :

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 CREATEDROP, 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 les CloudWatch alarmes, les scripts de configuration, etc. afin d'utiliser les nouveaux noms pour toutes les métriques dont les noms ont été affectés par des modifications linguistiques inclusives. Pour connaître la liste des métriques concernées, consultez Changements linguistiques inclusifs pour Aurora MySQL version 3.

  • Mettez à jour tous les AWS CloudFormation modèles afin d'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.

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.0dans le manuel de référence MySQL.