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 3Chemins de mise à niveau d'une version majeure Aurora MySQLFonctionnement de la mise à niveau sur place d'une version majeure de Aurora MySQLPlanification d'une mise à niveau de version majeure d'un cluster Aurora MySQL

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 3.04.1, le 3 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.

Table des matières

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 de plus amples informations, veuillez consulter 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 My SQL version 3 compatible avec My SQL 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.

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 provisionné Aurora MySQL, version 2

Oui

La mise à niveau sur place est prise en charge pour les clusters Aurora MySQL compatibles avec MySQL 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 provisionné Aurora MySQL, version 3

Ne s’applique pas

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

Aurora Serverless v1 cluster

Ne s’applique pas

Aurora Serverless v1 est pris en charge pour Aurora MySQL uniquement sur la version 2.

Aurora Serverless v2 cluster

Ne s’applique pas

 Aurora Serverless v2 est pris en charge pour Aurora MySQL uniquement sur la 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 pouvez effectuer une mise à niveau sur place d'Aurora MySQL version 2 vers la version 3 uniquement si le lower_case_table_names paramètre est défini par défaut et si vous redémarrez votre base de données globale. Pour de plus amples informations, veuillez consulter Mises à niveau de version majeure..

Cluster compatible avec les requêtes parallèles

Oui

Vous pouvez effectuer une mise à niveau sur place.

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 qui utilise la fonctionnalité Backtrack. 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 Utilisation des notifications d'RDSévénements Amazon.

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 Résolution des problèmes liés à la mise à niveau SQL sur place d'Aurora My. 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.

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 après la mise à niveau pour Aurora My SQL 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 Amazon Aurora My SQL DB. 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, consultezRésolution des problèmes liés à la mise à niveau SQL sur place d'Aurora My. 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 que l'opération a lieu. 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.

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 de plus amples informations, veuillez consulter Utilisation des déploiements (Amazon Aurora Blue/Green) pour les mises à jour de bases de données.