Prévérifications de mise à niveau des versions majeures pour Aurora My SQL - Amazon Aurora

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.

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

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 d'Aurora My SQL 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 My SQL 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 les sections 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.

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

Les prévérifications incluent certaines qui sont incluses dans My SQL et d'autres qui ont été créées spécifiquement par l'équipe Aurora. 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é, 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, consultezUtilisation des notifications d'RDSévénements Amazon.

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

Communauté Mes prévérifications de SQL mise à niveau

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

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

    Pour plus d'informations, consultez la section Fonctionnalités supprimées dans My SQL 8.0 dans la section Ma SQL documentation.

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

  • 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 plus d'informations, consultez le jeu de caractères utf8mb3 (encodage Unicode 3 octets UTF -8) dans la section Ma documentation. SQL

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

  • 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 SQL mode obsolète ne doit être défini dans le réglage des variables de votre sql_mode système.

  • 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 My SQL 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 My SQL 5.7.

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

Vérifications préliminaires de SQL mise à niveau d'Aurora My

Aurora My SQL 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 SQL syntaxe 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 base 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.

  • DDLrecovery et Fast DDL ne sont pas pris en charge dans Aurora My SQL 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 My SQL 5.7 à l'aide du innodb_large_prefix paramètre. Ce paramètre est obsolète dans My SQL 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 comporter plus de 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.