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è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 -
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 typedisplay
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 deSET
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 deDESC
qualificatif pour lesGROUP 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
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_CACHE
SQL_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'FTS
index. -
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
ligneREDUNDANT
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 deutf8mb4
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.