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

PDFRSS

La mise à niveau SQL de My d'une version majeure à une autre, par exemple le passage de My SQL 5.7 à My SQL 8.0, implique des modifications architecturales importantes qui nécessitent une planification et une préparation minutieuses. Contrairement aux mises à niveau de versions mineures, où l'accent est principalement mis sur la mise à jour du logiciel du moteur de base de données et, dans certains cas, des tables système, les SQL mises à niveau majeures de My introduisent souvent des modifications fondamentales 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 My SQL version 2 vers la version 3, Aurora exécute automatiquement des contrôles de compatibilité des mises à niveau (prévérifications) 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 de se poursuivre. Pour plus de détails sur les SQL prévérifications Aurora My, consultezPrévérifiez la référence des descriptions pour Aurora My SQL. Les prévérifications Aurora s'exécutent en plus de celles exécutées par l'utilitaire Community My SQL Upgrade Checker.

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

• Ils peuvent réduire le risque de défaillances de mise à niveau susceptibles d'entraîner des temps d'arrêt prolongés.

• En cas d'incompatibilités, Amazon Aurora empêche la mise à niveau de se poursuivre 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ésolvant les incompatibilités. Pour obtenir des informations détaillées sur la résolution 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 s'exécutent avant que votre cluster de base de données ne soit mis hors ligne pour la mise à niveau de la version majeure. 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.

Une fois les prévérifications terminées, Aurora enregistre des informations détaillées sur chaque incompatibilité du upgrade-prechecks.log fichier. 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.

Note

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. Pour plus d'informations sur les considérations relatives aux performances du précontrôle, consultezProcessus de prévérification pour Aurora My SQL.

Table des matières

• 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

  • Erreurs

    • Mes SQL prévérifications qui signalent des erreurs

    • Aurora My SQL prévérifications qui signalent des erreurs

  • Avertissements

    • Mes SQL prévérifications qui signalent des avertissements

    • Aurora My SQL précontrôles qui signalent des avertissements

  • Avis

  • Erreurs, avertissements ou avis

Processus de prévérification pour Aurora My SQL

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

Pour les mises à niveau sur place, les prévérifications s'exécutent sur votre instance de base de données Writer lorsqu'elle est en ligne. Si le précontrôle aboutit, la mise à niveau se poursuit. Si des erreurs sont détectées, elles sont enregistrées dans le upgrade-prechecks.log fichier et la mise à niveau est annulée. Avant de recommencer la mise à niveau, corrigez les erreurs renvoyées dans le upgrade-prechecks.log fichier.

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

Pour plus d’informations, consultez Déterminer les causes des échecs de mise à niveau de la version SQL majeure d'Aurora My et Prévérifiez la référence des descriptions pour Aurora My SQL.

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

Prévérification de l'état	Message d’événement	Action
Démarré(e)	Préparation de la mise à niveau en cours : lancement des prévérifications de mise à niveau en ligne.	Aucun
Échec	Le cluster de base de données est dans un état qui ne peut pas être mis à niveau : les prévérifications de 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, voir https://docs.aws.amazon.com/AmazonRDS/dernier//.upgrading.Troubleshooting.html AuroraUserGuide AuroraMy SQL	Vérifiez s'il upgrade-prechecks.log y a des erreurs. Corrigez les erreurs. Réessayez la mise à niveau.
Réussi	Préparation de la mise à niveau en cours : les prévérifications de mise à niveau en ligne ont été effectuées.	Le précontrôle a réussi et aucune erreur n'a été renvoyée. Vérifiez upgrade-prechecks.log les avertissements et les avis.

Pour plus d'informations sur l'affichage des événements, consultezConsulter les RDS événements Amazon.

Prévérification du format du journal pour Aurora My SQL

Une fois les vérifications de compatibilité des mises à niveau (prévérifications) terminées, vous pouvez consulter le upgrade-prechecks.log fichier. Le fichier journal contient les résultats, les objets concernés et les informations de correction pour chaque précontrôle.

Des erreurs bloquent 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 consulter 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 est au format suivant :

• targetVersion— La version SQL compatible My de la mise à SQL niveau d'Aurora My.

• auroraServerVersion— La SQL version d'Aurora My sur laquelle la prévérification a été exécutée.

• auroraTargetVersion— La SQL version d'Aurora My vers laquelle vous effectuez la mise à niveau.

• checksPerformed— Contient la liste des prévérifications effectuées.

• id— Nom du précontrôle en cours d'exécution.

• title— Description de la prévérification en cours d'exécution.

• status— Cela n'indique pas si le précontrôle a réussi ou échoué, mais indique l'état de la requête de précontrôle :

  • OK— La requête de prévérification a été exécutée et s'est terminée avec succès.

  • ERROR— La requête de prévérification 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 prévérification de compatibilité.

    Pour plus d'informations, consultez cet exemple.

• description— Une description générale de l'incompatibilité et de la manière de remédier au problème.

• documentationLink— Le cas échéant, un lien vers la SQL documentation Aurora My SQL ou My pertinente est indiqué ici. Pour de plus amples informations, veuillez consulter Prévérifiez la référence des descriptions pour Aurora My SQL.

• detectedProblems— Si le précontrôle 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— Le niveau d'incompatibilité détecté par le précontrôle. 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 se poursuivre, mais un objet, une syntaxe ou une configuration obsolètes ont été détectés. Lisez attentivement les avertissements et corrigez-les rapidement afin d'éviter des problèmes dans les futures versions.

    • Notice— La mise à niveau peut se poursuivre, mais un objet, une syntaxe ou une configuration obsolètes ont été détectés. Lisez attentivement les notifications et corrigez-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— Une description détaillée de l'incompatibilité et de la procédure à suivre pour y remédier.

• errorCount— Le nombre d'erreurs d'incompatibilité détectées. Ils bloquent la mise à niveau.

• warningCount— Le nombre d'avertissements d'incompatibilité détectés. Ils ne bloquent pas la mise à niveau, mais les corrigent rapidement afin d'éviter des problèmes dans les futures versions.

• noticeCount— Le nombre de notifications d'incompatibilité détectées. Ils ne bloquent pas la mise à niveau, mais les corrigent rapidement pour éviter des problèmes dans les futures versions.

• Summary— Un résumé du nombre d'erreurs, d'avertissements et de notifications de compatibilité avant la vérification.

Exemples de sorties de journal de prévérification pour Aurora My SQL

Les exemples suivants montrent le résultat du journal de prévérification que vous pourriez voir. Pour plus de détails sur les prévérifications exécutées, consultezPrévérifiez la référence des descriptions pour Aurora My SQL.

Prévérification de l'état OK, aucune incompatibilité détectée

La requête de prévérification 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": []
},

Prévérification de l'état OK, erreur détectée

La requête de prévérification 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`;"
      },
 }

Prévérification de l'état OK, avertissement détecté

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

Ici, la requête de prévérification 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 prévérificationERROR, aucune incompatibilité signalée

La requête de prévérification 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 prévérification de compatibilité sur la base de données pendant l'exécution. Par exemple, sur des classes d'instance de base de données plus petites, cela peut se produire lorsque la mémoire disponible sur l'instance est insuffisante.

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

Pour de plus amples informations, veuillez consulter Résolution des problèmes d'utilisation de la mémoire pour les SQL bases de données Aurora My.

Résumé de la prévérification, une erreur et trois avertissements détectés

Les prévérifications de compatibilité contiennent également des informations sur les SQL versions source et cible d'Aurora My, ainsi qu'un résumé du nombre d'erreurs, d'avertissements et de notifications à la fin de la sortie de prévérification.

Par exemple, le résultat suivant indique qu'une tentative de mise à niveau d'Aurora My SQL 2.11.6 vers Aurora My 3.07.1 a été effectuée. SQL La 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 routineSyntaxCheckcompatibilité et 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."
}

Prévérifier les performances d'Aurora My SQL

Les précontrôles de compatibilité s'exécutent avant que l'instance de base de données ne soit mise hors ligne pour la mise à niveau. Ainsi, dans des circonstances normales, ils n'entraînent pas de temps d'arrêt de l'instance de base de données pendant son exécution. Cependant, ils peuvent avoir un impact sur la charge de travail de l'application exécutée sur l'instance de base de données Writer. Les prévérifications accèdent au dictionnaire de données via les tables information_schema, ce qui peut être lent s'il existe de nombreux objets de base de données. Tenez compte des facteurs suivants :

• La durée du précontrôle varie en fonction du nombre d'objets de base de données tels que les tables, les colonnes, les routines et les contraintes. Les clusters de base de données contenant un grand nombre d'objets peuvent prendre plus de temps à s'exécuter.

  Par exemple, cela removedFunctionsCheckpeut prendre plus de temps et utiliser plus 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 plus grande (par exemple, db.r5.24xlarge ou db.r6g.16xlarge) peut accélérer la mise à niveau en utilisant davantage. CPU Vous pouvez réduire les effectifs après la mise à niveau.

• Les requêtes sur information_schema plusieurs bases de données peuvent être lentes, en particulier lorsqu'il s'agit de nombreux objets et de petites instances de base de données. Dans de tels cas, envisagez d'utiliser le clonage, la restauration de snapshots ou un déploiement bleu/vert pour les mises à niveau.

• L'utilisation des ressources (CPUmémoire) par précontrôle peut augmenter avec l'augmentation du nombre d'objets, ce qui entraîne des durées d'exécution plus longues sur des instances de base de données plus petites. Dans de tels cas, pensez à effectuer des tests à l'aide du clonage, de la restauration de snapshots ou d'un déploiement bleu/vert pour les mises à niveau.

  Si les prévérifications échouent en raison d'un manque de ressources, vous pouvez le détecter dans le journal de précontrôle à 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 prévérifications effectuées par Community My SQL Upgrade

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 de détails sur les prévérifications exécutées, consultezPrévérifiez la référence des descriptions pour Aurora My SQL.

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. Pour une description générale des modifications apportées à My SQL 8.0, consultez la section Nouveautés de My SQL 8.0 dans la SQL documentation My.

Résumé des prévérifications 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, notamment les suivantes :

• 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 bases 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 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 présenter d'incohérence entre les chemins des fichiers de données.

Pour plus de détails sur les prévérifications exécutées, consultezPrévérifiez la référence des descriptions pour Aurora My SQL.