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 Amazon Aurora My SQL DB
Dans un numéro de SQL version d'Aurora My tel que 3.04.1, le 3 représente la version majeure. SQLLa version 2 d'Aurora My est compatible avec My SQL 5.7. SQLLa version 3 d'Aurora My est compatible avec My SQL 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, Cela peut être dû, par exemple, à des différences de SQL compatibilité ou au fonctionnement de certaines fonctionnalités SQL liées à Mon compte. 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 My SQL version 2 vers la version 3
- Chemins de mise à niveau SQL des versions majeures d'Aurora My
- Comment fonctionne la mise à niveau SQL sur place de la version majeure d'Aurora My
- Planification d'une mise à niveau de version majeure pour un SQL cluster Aurora My
- Prévérifications de mise à niveau des versions majeures pour Aurora My SQL
- Processus de prévérification pour Aurora My SQL
- Prévérification du format du journal pour Aurora My SQL
- Exemples de sorties de journal de prévérification pour Aurora My SQL
- Prévérifier les performances d'Aurora My SQL
- Résumé des prévérifications effectuées par Community My SQL Upgrade
- Résumé des prévérifications de SQL mise à niveau d'Aurora My
- Prévérifiez la référence des descriptions pour Aurora My SQL
- Comment effectuer une mise à niveau sur place
- Comment les mises à niveau sur place affectent les groupes de paramètres d'un cluster
- Modifications apportées aux propriétés du cluster entre les SQL versions d'Aurora My
- Mises à niveau majeures sur place des bases de données globales
- Mises à niveau sur place pour les clusters de bases de données avec des répliques de lecture entre régions
- Tutoriel de mise à niveau SQL sur place d'Aurora My
- Déterminer les causes des échecs de mise à niveau de la version SQL majeure d'Aurora My
- Résolution des problèmes liés à la mise à niveau SQL sur place d'Aurora My
- Nettoyage après la mise à niveau pour Aurora My SQL version 3
Mise à niveau d'Aurora My SQL version 2 vers la version 3
Si vous possédez un cluster SQL compatible My 5.7 et que vous souhaitez le mettre à niveau vers un cluster compatible My SQL —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 Comment fonctionne la mise à niveau SQL sur place de la version majeure d'Aurora My.
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 :
-
Note
Si vous utilisez la méthode AWS CLI ou RDS API pour la mise à niveau de restauration instantanée, vous devez exécuter une opération suivante pour créer une instance de base de données d'écriture dans le cluster de base de données restauré.
Pour obtenir des informations générales sur SQL la version 3 d'Aurora My et ses nouvelles fonctionnalités, consultezAurora 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 pour un SQL cluster Aurora My et Comment effectuer une mise à niveau sur place.
Chemins de mise à niveau SQL des versions majeures d'Aurora My
Tous les types ou versions de SQL clusters Aurora My ne peuvent pas utiliser le mécanisme de mise à niveau sur place. Vous pouvez connaître le chemin de mise à niveau approprié pour chaque SQL cluster Aurora My en consultant le tableau suivant.
Type de cluster Aurora My SQL DB | Peut-il utiliser la mise à niveau sur place ? | Action |
---|---|---|
Cluster SQL provisionné Aurora My, version 2 |
Oui |
La mise à niveau sur place est prise en charge pour les clusters Aurora My SQL compatibles avec My 5.7. SQL Pour plus d'informations sur la mise à niveau vers Aurora My SQL version 3, reportez-vous Planification d'une mise à niveau de version majeure pour un SQL cluster Aurora My aux sections etComment effectuer une mise à niveau sur place. |
Cluster SQL provisionné Aurora My, version 3 |
Ne s’applique pas |
Utilisez une procédure de mise à niveau de version mineure pour effectuer une mise à niveau entre les versions d'Aurora My SQL version 3. |
Aurora Serverless v1 cluster |
Ne s’applique pas |
Aurora Serverless v1 n'est pris en charge pour Aurora My SQL que sur la version 2. |
Aurora Serverless v2 cluster |
Ne s’applique pas |
Aurora Serverless v2 est pris en charge pour Aurora My SQL uniquement sur la version 3. |
Cluster d'une base de données Aurora globale |
Oui |
Pour mettre à niveau Aurora My SQL de la version 2 à la version 3, suivez la procédure de mise à niveau sur place pour les clusters d'une base de données globale Aurora. 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 le AWS CLI ou RDSAPI, appelez la Vous ne pouvez pas effectuer de mise à niveau sur place d'Aurora My SQL version 2 vers la version 3 si le |
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 du journal binaire provient d'un SQL cluster Aurora My, vous pouvez effectuer une mise à niveau sur place. Vous ne pouvez pas effectuer la mise à niveau si la réplication du journal binaire provient d'une instance RDS for My SQL ou d'une instance My SQL DB locale. 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 du AWS CLI ou du RDSAPI, vous pouvez créer un SQL cluster Aurora My sans aucune instance de base de données attachée. De la même manière, vous pouvez également supprimer toutes les instances de base de données d'un SQL cluster Aurora My tout en laissant intactes les données du volume du cluster. 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 le AWS CLI ou le RDS API 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 SQL cluster Aurora My 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. |
Comment fonctionne la mise à niveau SQL sur place de la version majeure d'Aurora My
Aurora My SQL effectue une mise à niveau de version majeure dans le cadre d'un 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 My SQL enregistre un événement. Vous pouvez examiner les événements tels qu'ils se produisent sur la page Événements de la RDS console. 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 :
-
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é ni traiter d'instructions du langage de définition des données (DDL). Par exemple, vous devrez peut-être fermer les applications qui soumettent certains types d'SQLinstructions. 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.
-
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.
-
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.
-
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.
-
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 tels qu'ils se produisent sur la page Événements de la RDS console.
-
Aurora purge les enregistrements d'annulation des anciennes versions des lignes.
-
Aurora restaure toutes les transactions non validées.
-
-
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 Writer pour mettre à niveau vos données au format SQL compatible My 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. Aurora met notamment à niveau les métadonnées des partitions dans les tables système afin de les rendre compatibles avec le format de partition My SQL 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 Mes journaux SQL d'erreurs. 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é.
-
-
Aurora met à niveau la version du moteur des instances de base de données du scripteur.
-
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 pour un SQL cluster Aurora My
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 SQL version 3 d'Aurora My et votre environnement actuel :
-
Si vous effectuez une conversion RDS depuis My SQL 8.0 ou My SQL 8.0 Community Edition, consultezComparaison entre Aurora My SQL version 3 et My SQL 8.0 Community Edition.
-
Si vous effectuez une mise à niveau depuis Aurora My SQL version 2, RDS pour My SQL 5.7, ou depuis la communauté My SQL 5.7, consultezComparaison entre Aurora My SQL version 2 et Aurora My SQL version 3.
-
Créez de nouvelles versions SQL compatibles avec My 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. Consultez Changements de paramètres pour Aurora My SQL version 3 pour en savoir plus sur les changements de paramètres.
-
Passez en revue le schéma de votre base de données Aurora My SQL version 2 et vos définitions d'objets pour vérifier l'utilisation des nouveaux mots clés réservés introduits dans My SQL 8.0 Community Edition. Faites-le avant la mise à niveau. Pour plus d'informations, consultez Mes nouveaux mots clés et mots réservés SQL 8.0
dans la section Ma SQL documentation.
Vous trouverez également d'autres considérations et astuces de mise à niveau SQL spécifiques à My dans la section Changes in My SQL 8.0mysqlcheck --check-upgrade
pour analyser vos SQL bases de données Aurora My existantes et identifier les problèmes de mise à niveau potentiels.
Note
Nous recommandons d'utiliser des classes d'instances de base de données plus grandes lors de la mise à niveau vers Aurora My SQL version 3 en utilisant la technique de mise à niveau sur place ou de restauration instantanée. Exemples : db.r5.24xlarge et db.r6g.16xlarge. Cela permet d'accélérer le processus de mise à niveau en utilisant la majorité de la CPU capacité 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 RDS depuis My SQL ou depuis 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 binaire des journaux pour synchroniser vos données avec un cluster Aurora My SQL 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 RDS API basées sur des scripts, consultezComment 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 SQL versions d'Aurora My.
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 l'opération. Aurora My SQL 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 :
-
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.
-
Configurez un ensemble d'instances de base de données d'écriture et de lecture similaire à celui du cluster d'origine.
-
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.
-
Testez la compatibilité des applications, les performances, les procédures d'administration, etc., à l'aide du cluster cloné.
-
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é.
-
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.
-
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 Aurora Blue/Green pour les mises à jour de bases de données.