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.
Mises à niveau de version majeures RDS pour for My SQL
Amazon RDS prend en charge les mises à niveau sur place suivantes pour les versions majeures du moteur My SQL database :
Mon SQL 5,6 à mon SQL 5,7
Mon SQL 5,7 à mon SQL 8,0
Note
Vous ne pouvez créer des instances de base de données My SQL versions 5.7 et 8.0 qu'avec des classes d'instance de base de données de dernière génération et de génération actuelle, en plus de la classe d'instance de base de données db.m3 de génération précédente.
Dans certains cas, vous souhaitez mettre à niveau une instance de base de données My SQL version 5.6 exécutée sur une classe d'instance de base de données de génération précédente (autre que db.m3) vers une instance de base de données My SQL version 5.7. Dans ce cas, commencez par modifier l'instance de base de données afin d'utiliser une classe d'instance de base de données de génération actuelle ou de dernière génération. Ensuite, vous pouvez modifier l'instance de base de données pour utiliser le moteur de base de données My SQL version 5.7. Pour plus d'informations sur les classes d'instances Amazon RDS DB, consultezClasses d'instances de base de données .
Rubriques
Vue d'ensemble des mises à niveau de mes versions SQL majeures
Les mises à niveau de version majeure peuvent contenir des modifications de base de données qui ne sont pas rétrocompatibles avec les applications existantes. Par conséquent, Amazon RDS n'applique pas automatiquement les mises à niveau des versions majeures ; vous devez modifier manuellement votre instance de base de données. Nous vous recommandons de tester soigneusement toute mise à niveau avant de l'appliquer à vos instances de production.
Pour effectuer une mise à niveau de version majeure d'une instance de base de données My SQL version 5.6 sur Amazon RDS vers My SQL version 5.7 ou ultérieure, effectuez d'abord toutes les mises à jour du système d'exploitation disponibles. Une fois les mises à jour du système d'exploitation terminées, mettez à niveau vers chaque version majeure : 5.6 vers 5.7, puis 5.7 vers 8.0. Mes SQL instances de base de données créées avant le 24 avril 2014 affichent une mise à jour du système d'exploitation disponible jusqu'à ce que la mise à jour soit appliquée. Pour de plus amples informations sur les mises à jour du système d'exploitation, veuillez consulter Application des mises à jour pour une instance de base de données.
Lors d'une mise à niveau de version majeure de MySQL, Amazon RDS exécute le SQL binaire My mysql_upgrade
pour mettre à niveau les tables, si nécessaire. Amazon RDS vide également les general_log
tables slow_log
et lors d'une mise à niveau majeure d'une version. Pour conserver les informations de journal, enregistrez le contenu du journal avant la mise à niveau de version majeure.
Les mises à niveau de mes versions SQL majeures se terminent généralement en 10 minutes environ. Certaines mises à niveau peuvent durer plus longtemps en raison de la taille de la classe d'instance de base de données ou parce que l'instance ne suit pas certaines directives opérationnelles indiquées dans Bonnes pratiques pour Amazon RDS. Si vous mettez à niveau une instance de base de données depuis la RDS console Amazon, le statut de l'instance de base de données indique quand la mise à niveau est terminée. Si vous effectuez la mise à niveau à l'aide de AWS Command Line Interface
(AWS CLI), utilisez la describe-db-instancescommande et vérifiez la Status
valeur.
Les mises à niveau vers Ma SQL version 5.7 peuvent être lentes
Ma SQL version 5.6.4 a introduit un nouveau format de date et d'heure pour les timestamp
colonnes datetime
time
, et qui autorise des composantes fractionnaires dans les valeurs de date et d'heure. Lors de la mise à niveau d'une instance de base de données vers My SQL version 5.7, My SQL force la conversion de tous les types de colonnes de date et d'heure au nouveau format.
Étant donné que cette conversion recrée vos tables, cela peut prendre beaucoup de temps pour terminer la mise à niveau de l'instance de base de données. La conversion forcée se produit pour toutes les instances de base de données qui exécutent une version antérieure à My SQL version 5.6.4. Cela se produit également pour toutes les instances de base de données mises à niveau d'une version antérieure à My SQL version 5.6.4 vers une version autre que 5.7.
Si votre instance de base de données exécute une version antérieure à My SQL version 5.6.4 ou a été mise à niveau à partir d'une version antérieure à la version 5.6.4, nous vous recommandons d'effectuer une étape supplémentaire. Dans ces cas, nous vous recommandons de convertir les timestamp
colonnes datetime
time
, et de votre base de données avant de mettre à niveau votre instance de base de données vers My SQL version 5.7. Cette conversion peut réduire considérablement le temps nécessaire à la mise à niveau de l'instance de base de données vers My SQL version 5.7. Pour mettre à niveau les colonnes de date et d'heure vers le nouveau format, vous devez émettre la commande ALTER TABLE
pour chaque table qui contient des colonnes de date ou d'heure. Comme la modification d'une table la verrouille en lecture seule, il est recommandé d'effectuer cette mise à jour pendant une fenêtre de maintenance.<table_name>
FORCE;
Pour trouver toutes les tables de votre base de données qui comportent des colonnes datetime
, time
ou timestamp
, et créer une commande ALTER
TABLE
pour chaque table, utilisez la requête suivante.<table_name>
FORCE;
SET show_old_temporals = ON; SELECT table_schema, table_name,column_name, column_type FROM information_schema.columns WHERE column_type LIKE '%/* 5.5 binary format */'; SET show_old_temporals = OFF;
Prévérifications pour les mises à niveau de My SQL 5.7 à 8.0
My SQL 8.0 inclut un certain nombre d'incompatibilités avec My SQL 5.7. Ces incompatibilités peuvent entraîner des problèmes lors d'une mise à niveau de My SQL 5.7 vers My SQL 8.0. Une certaine préparation est donc nécessaire sur votre base de données pour garantir la réussite de la mise à niveau. La liste suivante est une liste généralisée de ces incompatibilités :
-
Les tables ne doivent pas utiliser de fonctions ou de types de données obsolètes.
-
Il ne doit y avoir aucun fichier *.frm orphelin.
-
Les déclencheurs ne doivent pas avoir de definer manquant ou vide, ni de contexte de création invalide.
-
Aucune table partitionnée ne doit utiliser de moteur de stockage dépourvu de prise en charge native du partitionnement.
-
Il ne doit y avoir aucune violation de mot clé ou de mot réservé. Certains mots clés qui n'ont pas été réservés auparavant peuvent être réservés dans My SQL 8.0.
Pour plus d'informations, consultez la section Mots clés et mots réservés
dans la section Ma SQL documentation. -
Aucune table de la base de données
mysql
système My SQL 5.7 ne doit porter le même nom qu'une table utilisée par le dictionnaire de données My SQL 8.0. -
Aucun SQL mode obsolète ne doit être défini dans le réglage des variables de votre
sql_mode
système. -
Aucune table ni procédure stockée avec des éléments de colonne
ENUM
ouSET
individuels ne doit dépasser 255 caractères ou 1 020 octets de longueur. -
Avant la mise à niveau vers My SQL 8.0.13 ou une version ultérieure, aucune partition de table ne doit résider dans des tablespaces InnoDB partagés.
-
Aucune requête ou définition de programme enregistrée à partir de My SQL 8.0.12 ou d'une version antérieure ne doit utiliser
ASC
deDESC
qualificatifs pour les clauses.GROUP BY
-
Votre installation My SQL 5.7 ne doit pas utiliser de fonctionnalités qui ne sont pas prises en charge dans My SQL 8.0.
Pour plus d'informations, consultez la section Fonctionnalités supprimées dans My SQL 8.0
dans la section Ma SQL documentation. -
Aucun nom de contrainte de clé étrangère ne doit dépasser 64 caractères.
-
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èresutf8mb4
. Le jeu de caractèresutf8mb3
est obsolète. Envisagez également d'utiliserutf8mb4
pour référencer les jeux de caractères au lieu deutf8
. Actuellement,utf8
est un alias du jeu de caractèresutf8mb3
.Pour plus d'informations, consultez le jeu de caractères utf8mb3 (encodage Unicode 3 octets UTF -8
) dans la section Ma documentation. SQL
Lorsque vous lancez une mise à niveau de My SQL 5.7 vers la version 8.0, Amazon RDS exécute automatiquement des prévérifications pour détecter ces incompatibilités. Pour plus d'informations sur la mise à niveau vers My SQL 8.0, consultez la section Mise à niveau de My SQL
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 RDS 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 My SQL 8.0 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
dans Ma SQL documentation et Mise à niveau vers My 8.0 ? SQL Voici ce que vous devez savoir... sur le blog My SQL Server.
Parmi les prévérifications, certaines sont incluses dans My SQL et d'autres ont été créées spécifiquement par l'RDSéquipe Amazon. Pour plus d'informations sur les prévérifications fournies par MySQL, consultez la section 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é, Amazon annule RDS automatiquement la mise à niveau avant que l'instance de base de données ne soit arrêtée. Amazon génère RDS également un événement en cas d'incompatibilité. Pour plus d'informations sur les RDS événements Amazon, consultezUtilisation des notifications d'RDSévénements Amazon.
Amazon RDS enregistre des informations détaillées sur chaque incompatibilité dans le fichier PrePatchCompatibility.log
journal. Dans la plupart des cas, l'entrée du journal inclut un lien vers Ma SQL documentation pour 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.
Note
Amazon RDS exécute toutes ces vérifications préalables uniquement pour une mise à niveau de My SQL 5.7 vers My SQL 8.0. Pour une mise à niveau de My SQL 5.6 vers My SQL 5.7, les prévérifications se limitent à confirmer qu'il n'y a pas de tables orphelines et qu'il y a suffisamment d'espace de stockage pour reconstruire les tables. Les prévérifications ne sont pas effectuées pour les mises à niveau vers des versions inférieures à My SQL 5.7.
Annulation après échec de la mise à niveau de My SQL 5.7 vers la version 8.0
Lorsque vous mettez à niveau une instance de base de données de Ma SQL version 5.7 vers Ma SQL version 8.0, la mise à niveau peut échouer. Elle peut échouer en particulier si le dictionnaire de données contient des incompatibilités qui n'ont pas été détectées alors des vérifications préalables. Dans ce cas, la base de données ne démarre pas correctement dans la nouvelle version de My SQL 8.0. À ce stade, Amazon RDS annule les modifications effectuées pour la mise à niveau. Après le rollback, l'instance My SQL DB exécute My SQL version 5.7. Lorsqu'une mise à niveau échoue et est annulée, Amazon RDS génère un événement avec l'ID d'RDSévénement EVENT -0188.
Généralement, une mise à niveau échoue en raison d'incompatibilités dans les métadonnées entre les bases de données de votre instance de base de données et la version cible MySQL. En cas d'échec d'une mise à niveau, vous pouvez afficher les détails de ces incompatibilités dans le fichier upgradeFailure.log
. Vous devez résoudre les incompatibilités avant de répéter la tentative de mise à niveau.
Lors d'une tentative de mise à niveau infructueuse et d'une restauration, votre instance de base de données est redémarrée. Tous les changements de paramètres en attente sont appliqués lors du redémarrage et sont maintenus après la restauration.
Pour plus d'informations sur la mise à niveau vers My SQL 8.0, consultez les rubriques suivantes dans la SQL documentation My :
Note
Actuellement, la restauration automatique après un échec de mise à niveau n'est prise en charge que pour les mises à niveau des versions majeures de My SQL 5.7 à 8.0.