Vérifications préalables aux mises à niveau de version majeure pour Aurora MySQL - Amazon Aurora
Processus de vérification préalable pour Aurora MySQLFormat du journal des vérifications préalables pour Aurora MySQLExemples de sorties du journal de vérification préalable pour Aurora MySQLVérification préalable des performances pour Aurora MySQLRésumé des vérifications préalables de mise à niveau de Community MySQLRésumé des vérifications préalables de mise à niveau d’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.

Vérifications préalables aux mises à niveau de version majeure pour Aurora MySQL

Les mises à niveau de version majeure de MySQL (lorsque vous passez de MySQL 5.7 à MySQL 8.0, par exemple) impliquent des modifications architecturales significatives qui nécessitent une planification et une préparation minutieuses. Contrairement aux mises à niveau de version mineure qui se concentrent principalement sur la mise à jour du logiciel du moteur de base de données et, dans certains cas, des tables système, les mises à niveau majeures de MySQL impliquent souvent des changements fondamentaux dans la façon dont la base de données stocke et gère ses métadonnées.

Pour vous aider à identifier ces incompatibilités, lors de la mise à niveau d’Aurora MySQL version 2 vers la version 3, Aurora exécute automatiquement des vérifications de la compatibilité de la mise à niveau (vérifications préalables) pour examiner les objets de votre cluster de bases de données et identifier les incompatibilités connues susceptibles d’empêcher la mise à niveau d’avoir lieu. Pour plus d’informations sur les vérifications préalables d’Aurora MySQL, consultez Référence des vérifications préalables avec description pour Aurora MySQL. Les vérifications préalables d’Aurora s’exécutent en plus de celles effectuées par l’utilitaire de vérification de mise à niveau de Community MySQL.

Ces vérifications préalables sont obligatoires. Vous ne pouvez pas choisir de les ignorer. Elles offrent les avantages suivants :

  • Elles limitent le risque d’échecs de mise à niveau susceptibles d’entraîner une durée d’indisponibilité prolongée.

  • En cas d’incompatibilités, Amazon Aurora empêche la mise à niveau d’avoir lieu et vous fournit un journal vous permettant d’en savoir plus. Vous pouvez ensuite utiliser ce journal pour préparer votre base de données pour la mise à niveau vers la version 3 de MySQL en résolvant ces incompatibilités. Pour obtenir des informations détaillées sur la résolution des incompatibilités, consultez Préparation de votre installation pour la mise à niveau dans la documentation MySQL et Mise à niveau vers MySQL 8.0 ? Ce que vous devez savoir… (langue française non garantie) sur le blog MySQL Server.

    Pour plus d’informations sur la mise à niveau vers MySQL 8.0, consultez Mise à niveau de MySQL dans la documentation MySQL.

Les vérifications préalables s’exécutent avant que votre cluster de bases de données ne soit mis hors ligne pour la mise à niveau de la version majeure. Si les vérifications préalables identifient une incompatibilité, Aurora annule automatiquement la mise à niveau avant que l’instance de base de données soit arrêtée. Aurora génère également un événement pour cette incompatibilité. Pour plus d’informations sur les événements Amazon Aurora, consultez Utiliser la notification d’événements d’Amazon RDS.

Une fois les vérifications préalables terminées, Aurora enregistre des informations détaillées sur chaque incompatibilité dans le fichier upgrade-prechecks.log. Dans la plupart des cas, l’entrée de journal inclut un lien vers la documentation MySQL permettant de corriger l’incompatibilité. Pour plus d’informations sur l’affichage des fichiers journaux, consultez Liste et affichage des fichiers journaux de base de données.

Note

En raison de la nature des vérifications préalables, elles 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. Pour plus d’informations sur les considérations relatives aux performances de la vérification préalable, consultez Processus de vérification préalable pour Aurora MySQL.

Table des matières

Processus de vérification préalable pour Aurora MySQL

Comme décrit précédemment, le processus de mise à niveau d’Aurora MySQL implique l’exécution de vérifications de la compatibilité (vérifications préalables) sur votre base de données avant de procéder à la mise à niveau de la version majeure.

Pour les mises à niveau sur place, les vérifications préalables s’exécutent sur votre instance de base de données d’enregistreur lorsqu’elle est en ligne. Si la vérification préalable aboutit, la mise à niveau a lieu. Si des erreurs sont détectées, elles sont journalisées dans le fichier upgrade-prechecks.log, et la mise à niveau est annulée. Avant de tenter une nouvelle mise à niveau, corrigez les erreurs renvoyées dans le fichier upgrade-prechecks.log.

Pour les mises à niveau basées sur la restauration d’un instantané, la vérification préalable s’exécute pendant le processus de restauration. En cas de succès, votre base de données sera mise à niveau vers la nouvelle version d’Aurora MySQL. Si des erreurs sont détectées, elles sont journalisées dans le fichier upgrade-prechecks.log, et la mise à niveau est annulée. Avant de tenter une nouvelle mise à niveau, corrigez les erreurs renvoyées dans le fichier upgrade-prechecks.log.

Pour plus d’informations, consultez Identification de la cause des échecs de mise à niveau de version majeure Aurora MySQL et Référence des vérifications préalables avec description pour Aurora MySQL.

Pour surveiller l’état de la vérification préalable, vous pouvez consulter les événements suivants sur votre cluster de bases de données.

État de la vérification préalable Message d’événement Action

Démarré(e)

Préparation de la mise à niveau en cours : lancement des vérifications préalables à la mise à niveau en ligne.

 Aucun

Échec

Le cluster de bases de données est dans un état qui ne permet pas la mise à niveau : les vérifications préalables à la mise à niveau ont échoué. Pour plus de détails, consultez le fichier upgrade-prechecks.log.

Pour plus d’informations sur le dépannage de la cause de l’échec de la mise à niveau, consultez

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html

Recherchez les erreurs dans upgrade-prechecks.log.

Corrigez les erreurs.

Réessayez la mise à niveau.

Réussi(e)

Préparation de la mise à niveau en cours : vérifications préalables à la mise à niveau en ligne terminées.

La vérification préalable a abouti et aucune erreur n’a été renvoyée.

Recherchez les avertissements et les notifications dans upgrade-prechecks.log.

Pour plus d’informations sur l’affichage des événements, consultez Affichage d’événements Amazon RDS.

Format du journal des vérifications préalables pour Aurora MySQL

Une fois que les vérifications de la compatibilité de la mise à niveau (vérifications préalables) sont terminées, vous pouvez consulter le fichier upgrade-prechecks.log. Ce fichier journal contient les résultats, les objets concernés et les informations de correction de chaque vérification préalable.

Toute erreur bloque la mise à niveau. Vous devez les résoudre avant de réessayer la mise à niveau.

Les avertissements et les notifications sont moins critiques, mais nous vous recommandons tout de même de les examiner attentivement pour vous assurer qu’il n’y a aucun problème de compatibilité avec la charge de travail de l’application. Résolvez rapidement tous les problèmes identifiés.

Le fichier journal a le format suivant :

  • targetVersion : version compatible avec MySQL de la mise à niveau d’Aurora MySQL.

  • auroraServerVersion : version d’Aurora MySQL sur laquelle la vérification préalable a été exécutée.

  • auroraTargetVersion : version d’Aurora MySQL vers laquelle vous effectuez la mise à niveau.

  • checksPerformed : contient la liste des vérifications préalables effectuées.

  • id : nom de la vérification préalable en cours d’exécution.

  • title : description de la vérification préalable en cours d’exécution.

  • status : n’indique pas si la vérification préalable a réussi ou échoué, mais indique l’état de la requête correspondante :

    • OK : la requête de vérification préalable a été exécutée et s’est terminée avec succès.

    • ERROR : la requête de vérification préalable n’a pas pu être exécutée. Cela peut être dû à des problèmes tels que des contraintes de ressources, des redémarrages inattendus d’instances ou l’interruption de la requête de vérification préalable de la compatibilité.

      Pour plus d’informations, consultez cet exemple.

  • description : description générale de l’incompatibilité et de la procédure à suivre pour remédier au problème.

  • documentationLink : le cas échéant, un lien vers la documentation pertinente d’Aurora MySQL ou de MySQL est indiqué ici. Pour plus d’informations, consultez Référence des vérifications préalables avec description pour Aurora MySQL.

  • detectedProblems : si la vérification préalable renvoie une erreur, un avertissement ou une notification, cela indique les détails de l’incompatibilité et les objets incompatibles le cas échéant :

    • level : niveau d’incompatibilité détecté par la vérification préalable. Les niveaux valides sont les suivants :

      • Error : la mise à niveau ne peut pas être effectuée tant que vous n’avez pas résolu l’incompatibilité.

      • Warning : la mise à niveau peut avoir lieu, mais un objet, une syntaxe ou une configuration obsolète a été détecté. Lisez attentivement les avertissements et résolvez-les rapidement afin d’éviter des problèmes dans les futures versions.

      • Notice : la mise à niveau peut avoir lieu, mais un objet, une syntaxe ou une configuration obsolète a été détecté. Lisez attentivement les notifications et résolvez-les rapidement afin d’éviter des problèmes dans les futures versions.

    • dbObject : nom de l’objet de base de données dans lequel l’incompatibilité a été détectée.

    • description : description détaillée de l’incompatibilité et de la procédure à suivre pour remédier au problème.

  • errorCount : nombre d’erreurs d’incompatibilité détectées. Ces erreurs bloquent la mise à niveau.

  • warningCount : nombre d’avertissements d’incompatibilité détectés. Ils ne bloquent pas la mise à niveau, mais traitez-les rapidement afin d’éviter des problèmes dans les futures versions.

  • noticeCount : nombre de notifications d’incompatibilité détectées. Elles ne bloquent pas la mise à niveau, mais traitez-les rapidement afin d’éviter des problèmes dans les futures versions.

  • Summary : résumé du nombre d’erreurs, d’avertissements et de notifications de compatibilité générés par la vérification préalable.

Exemples de sorties du journal de vérification préalable pour Aurora MySQL

Les exemples suivants montrent la sortie du journal de vérification préalable que vous pourriez voir. Pour plus de détails sur les vérifications préalables exécutées, consultez Référence des vérifications préalables avec description pour Aurora MySQL.

État de la vérification préalable OK, aucune incompatibilité détectée

La requête de vérification préalable s’est terminée avec succès. Aucune incompatibilité n’a été détectée.

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinytext",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny text columns",
  "status": "OK",
  "detectedProblems": []
},
État de la vérification préalable OK, erreur détectée

La requête de vérification préalable s’est terminée avec succès. Une erreur a été détectée.

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexes",
  "status": "OK",
  "description": "Consider dropping the prefix indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test25.sbtest1",
        "description": "Table `test25`.`sbtest1` has an index `idx_t1` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `idx_t1` ON `test25`.`sbtest1`;"
      },
 }
État de la vérification préalable OK, avertissement détecté

Des avertissements peuvent être renvoyés en cas de réussite ou d’échec d’une vérification préalable.

Ici, la requête de vérification préalable s’est terminée avec succès. Deux avertissements ont été détectés.

{
  "id": "zeroDatesCheck",
  "title": "Zero Date, Datetime, and Timestamp values",
  "status": "OK",
  "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
  "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "global.sql_mode",
        "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      },
      {
        "level": "Warning",
        "dbObject": "session.sql_mode",
        "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      }
    ]
}
État de la vérification préalable ERROR, aucune incompatibilité signalée

La requête de vérification préalable a échoué avec une erreur. Les incompatibilités n’ont donc pas pu être vérifiées.

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "ERROR",
  "description": "Can't connect to MySQL server on 'localhost:3306' (111) at 13/08/2024 12:22:20 UTC. This failure can occur due to low memory available on the instance for executing upgrade prechecks. Please check 'FreeableMemory' Cloudwatch metric to verify the available memory on the instance while executing prechecks. If instance ran out of memory, we recommend to retry the upgrade on a higher instance class."
}

Cet échec peut être dû à un redémarrage inattendu de l’instance ou à l’interruption d’une requête de vérification préalable de la compatibilité sur la base de données pendant l’exécution. Par exemple, sur des classes d’instance de base de données de petite taille, vous pouvez rencontrer ce problème lorsque la mémoire disponible sur l’instance est insuffisante.

Vous pouvez utiliser la métrique FreeableMemory d’Amazon CloudWatch pour vérifier la mémoire disponible sur l’instance lors de l’exécution des vérifications préalables. Si l’instance n’a pas suffisamment de mémoire, nous vous recommandons de réessayer la mise à niveau sur une classe d’instance de base de données plus grande. Dans certains cas, vous pouvez utiliser un déploiement bleu/vert. Cela permet aux vérifications préalables et aux mises à niveau de s’exécuter sur le cluster de bases de données « vert » indépendamment de la charge de travail de production, qui consomme également des ressources système.

Pour plus d’informations, consultez Résolution des problèmes d’utilisation de la mémoire pour les bases de données Aurora MySQL.

Résumé d’une vérification préalable : une erreur et trois avertissements détectés

Les vérifications préalables de la compatibilité contiennent également des informations sur les versions source et cible d’Aurora MySQL, ainsi qu’un résumé du nombre d’erreurs, d’avertissements et de notifications à l’issue de la vérification préalable.

Par exemple, la sortie suivante indique qu’une tentative de mise à niveau d’Aurora MySQL 2.11.6 vers Aurora MySQL 3.07.1 a été effectuée. Cette mise à niveau a renvoyé une erreur, trois avertissements et aucune notification. Comme les mises à niveau ne peuvent pas être effectuées lorsqu’une erreur est renvoyée, vous devez résoudre le problème de compatibilité routineSyntaxCheck, puis réessayer la mise à niveau.

{
  "serverAddress": "/tmp%2Fmysql.sock",
  "serverVersion": "5.7.12 - MySQL Community Server (GPL)",
  "targetVersion": "8.0.36",
  "auroraServerVersion": "2.11.6",
  "auroraTargetVersion": "3.07.1",
  "outfilePath": "/rdsdbdata/tmp/PreChecker.log",
  "checksPerformed": [{
      ... output for each individual precheck ...
      .
      .
      {
        "id": "oldTemporalCheck",
        "title": "Usage of old temporal type",
        "status": "OK",
          "detectedProblems": []
      },
      {
        "id": "routinesSyntaxCheck",
        "title": "MySQL 8.0 syntax check for routine-like objects",
        "status": "OK",
        "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
        "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
        "detectedProblems": [{
            "level": "Error",
            "dbObject": "test.select_res_word",
            "description": "at line 2,18: unexpected token 'except'"
        }]
      },
      .
      .
      .
      {
        "id": "zeroDatesCheck",
        "title": "Zero Date, Datetime, and Timestamp values",
        "status": "OK",
        "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
        "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
        "detectedProblems": [{
            "level": "Warning",
            "dbObject": "global.sql_mode",
            "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
            },
            {
            "level": "Warning",
            "dbObject": "session.sql_mode",
            "description": " of 8 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
            }
          ]
       },
       .
       .
       .
  }],
  "errorCount": 1,
  "warningCount": 3,
  "noticeCount": 0,
  "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues."
}

Vérification préalable des performances pour Aurora MySQL

Les vérifications préalables de la compatibilité s’exécutent avant que l’instance de base de données soit mise hors ligne pour la mise à niveau. Leur exécution n’implique donc aucune durée d’indisponibilité. Cependant, elles peuvent avoir un impact sur la charge de travail de l’application exécutée sur l’instance de base de données d’enregistreur. Les vérifications préalables accèdent au dictionnaire de données via les tables information_schema, un processus qui peut être lent si le nombre d’objets de base de données est élevé. Prenez en compte les facteurs suivants :

  • La durée de la vérification préalable varie en fonction du nombre d’objets de base de données tels que les tables, les colonnes, les routines et les contraintes. L’exécution des clusters de bases de données contenant un grand nombre d’objets peut prendre plus de temps.

    Par exemple, removedFunctionsCheck peut prendre plus de temps et utiliser davantage de ressources en fonction du nombre d’objets stockés.

  • Pour les mises à niveau sur place, l’utilisation d’une classe d’instance de base de données de grande taille (par exemple, db.r5.24xlarge ou db.r6g.16xlarge) peut accélérer la mise à niveau grâce à davantage de processeur. Vous pourrez réduire la taille de la classe d’instance de base de données après la mise à niveau.

  • Les requêtes portant sur information_schema entre plusieurs bases de données peuvent être lentes, notamment si le nombre d’objets est élevé et si les instances de base de données sont de petite taille. Dans ce cas, envisagez d’utiliser le clonage, la restauration d’instantané ou un déploiement bleu/vert pour les mises à niveau.

  • L’utilisation des ressources (processeur, mémoire) par la vérification préalable peut augmenter avec la hausse du nombre d’objets, ce qui entraîne des durées d’exécution plus longues sur les instances de base de données de petite taille. Dans ce cas, envisagez d’utiliser le clonage, la restauration d’instantané ou un déploiement bleu/vert pour les mises à niveau afin d’effectuer des tests.

    Si les vérifications préalables échouent en raison de ressources insuffisantes, vous pouvez détecter ce problème dans le journal de vérification préalable à l’aide de la sortie d’état :

    "status": "ERROR",

Pour plus d’informations, consultez Fonctionnement de la mise à niveau sur place d’une version majeure de Aurora MySQL et Planification d’une mise à niveau de version majeure d’un cluster Aurora MySQL.

Résumé des vérifications préalables de mise à niveau de Community MySQL

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

  • Votre cluster de bases de données compatible avec MySQL 5.7 ne doit pas utiliser de fonctionnalités non prises en charge par MySQL 8.0.

    Pour plus d’informations, consultez Fonctionnalités supprimées dans MySQL 8.0 dans la documentation MySQL.

  • Il ne doit y avoir aucune violation de mot clé ou de mot réservé. Certains mots clés doivent être réservés dans MySQL 8.0 alors qu’ils ne l’étaient pas par le passé.

    Pour en savoir plus, consultez la section Mots clés et mots réservés dans la documentation MySQL.

  • 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 en savoir plus, consultez la section Le jeu de caractères utf8mb3 (encodage Unicode 3 octets en UTF-8) dans la documentation MySQL.

  • 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 de type longueur ZEROFILL ou display.

  • 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 du système mysqldans MySQL 5.7 ne doit avoir le même nom que la table utilisée dans le dictionnaire de données MySQL 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 mode SQL obsolète ne doit être défini dans la configuration variable de votre système sql_mode.

  • Aucune table ni procédure stockée avec des éléments de colonne ENUM ou SET individuels ne doit dépasser 255 caractères de longueur.

  • Aucune partition de table ne doit se trouver dans les espaces de table InnoDB partagés.

  • Il ne doit pas y avoir aucune référence circulaire dans les chemins des fichiers de données des espaces de table.

  • Aucune requête ni définition de programme stockée ne doit utiliser de qualificateur ASC ou DESC pour les clauses GROUP BY.

  • Aucune variable système ne doit être supprimée, et les variables système doivent utiliser les nouvelles valeurs par défaut pour MySQL 8.0.

  • Aucune valeur de date, de date/heure ou d’horodatage ne doit correspondre à zéro (0).

  • Il ne doit y avoir aucune incohérence de schéma résultant de la suppression ou de la corruption de fichiers.

  • Aucun nom de table ne doit contenir la chaîne de caractères FTS.

  • Aucune table InnoDB ne doit appartenir à un autre moteur.

  • Tous les noms de table ou de schéma doivent être valides pour MySQL 5.7.

Pour plus de détails sur les vérifications préalables exécutées, consultez Référence des vérifications préalables avec description pour Aurora MySQL.

Pour plus d’informations sur la mise à niveau vers MySQL 8.0, consultez Mise à niveau de MySQL dans la documentation MySQL. Pour une description générale des modifications apportées dans MySQL 8.0, consultez Nouveautés de MySQL 8.0 dans la documentation MySQL.

Résumé des vérifications préalables de mise à niveau d’Aurora MySQL

Aurora MySQL a des exigences spécifiques lors de la mise à niveau de la version 2 vers la version 3, notamment les suivantes :

  • Il ne doit pas y avoir de syntaxe SQL obsolète, telle que SQL_CACHE, SQL_NO_CACHE et QUERY_CACHE, dans les vues, les routines, les déclencheurs et les événements.

  • Aucune colonne FTS_DOC_ID ne peut se trouver dans une table sans l’index FTS.

  • Il ne doit y avoir aucune incompatibilité de définition de colonne entre le dictionnaire de données InnoDB et la définition réelle de la table.

  • Tous les noms de bases de données et de tables doivent être en minuscules lorsque le paramètre lower_case_table_names est défini sur 1.

  • Les déclencheurs ne doivent pas avoir de definer 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.

  • Les restaurations DDL et Fast DDL ne sont pas prises en charge dans Aurora MySQL version 3. Les bases de données ne doivent contenir aucun artefact lié à ces fonctionnalités.

  • Les tables au format de ligne REDUNDANT ou COMPACT ne peuvent pas avoir d’index supérieurs à 767 octets.

  • La longueur du préfixe des index définis sur les colonnes de texte tiny ne peut pas dépasser 255 octets. Avec le jeu de caractères utf8mb4, cela limite la longueur de préfixe prise en charge à 63 caractères.

    Une longueur de préfixe plus grande était autorisée dans MySQL 5.7 en utilisant le paramètre innodb_large_prefix. Ce paramètre est obsolète dans MySQL 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 à l’état prepared.

  • Les noms de colonne dans les vues ne peuvent pas dépasser 64 caractères.

  • Les caractères spéciaux des procédures stockées ne peuvent pas être incohérents.

  • Les tables ne peuvent pas avoir d’incohérences entre les chemins des fichiers de données.

Pour plus de détails sur les vérifications préalables exécutées, consultez Référence des vérifications préalables avec description pour Aurora MySQL.