Problèmes connus avec les migrations vers Azure Database pour MySQL
Les sections suivantes décrivent les problèmes connus associés aux migrations vers Azure Database pour MySQL.
Problème de migration de schéma pour une cible de serveur flexible MySQL version 8.0
Erreur : Une migration vers un serveur flexible MySQL avec le moteur version 8.0.30 ou ultérieure peut échouer lorsque la fonctionnalité de génération de clés primaires invisibles pour les tables InnoDB est activée (voir MySQL :: Manuel de référence de MySQL 8.0 :: 13.1.20.11 Clés primaires invisibles générées). L’échec peut se produire lors de la migration du schéma de table de la source vers la cible, lors de l’application de modifications pendant la phase de réplication des migrations en ligne, lors d’une nouvelle tentative de migration ou lors de la migration vers une cible où le schéma a été migré manuellement.
Message d’erreur potentiel :
- « Erreur inconnue. »
- « Échec de la génération d’une clé primaire invisible. La colonne d’incrémentation automatique existe déjà. »
- « La colonne « my_row_id » dans la table cible « nom de table » dans la base de données « base de données » n’existe pas sur la table source. »
Limitation : la migration vers une instance de serveur flexible MySQL où sql_generate_invisible_primary_key est activé n’est pas prise en charge par DMS.
Solution de contournement : Définissez le paramètre de serveur sql_generate_invisible_primary_key pour le serveur flexible MySQL cible sur OFF. Le paramètre de serveur se trouve dans le volet Paramètres du serveur sous l’onglet Tous pour le serveur flexible MySQL cible. En outre, supprimez la base de données cible et redémarrez la migration DMS pour éviter d’avoir des schémas incompatibles.
Mode SQL incompatible
Des modes SQL incompatibles peuvent entraîner de nombreuses erreurs différentes. Vous trouverez ci-dessous un exemple d’erreur avec les modes serveur qui doivent être examinés si cette erreur se produit.
Erreur : Une erreur s’est produite lors de la préparation de la table « {table} » dans la base de données « {base de données} » sur le serveur « {serveur} » pour la migration pendant l’activité « {activité} ». Par conséquent, cette table ne sera pas migrée.
Limitation : cette erreur se produit quand l’un des modes SQL ci-dessous est défini sur un serveur, mais pas sur l’autre serveur.
Solution de contournement :
NO_ZERO_DATE
Lorsque la valeur par défaut d’une date sur une table ou les données sont 0000-00-00 sur la source et que le serveur cible a le mode SQL NO_ZERO_DATE défini, le schéma et/ou la migration des données échouent. Il existe deux solutions de contournement possibles. La première consiste à modifier les valeurs par défaut des colonnes pour qu’elles soient NULL ou une date valide. La deuxième option consiste à supprimer le mode SQL NO_ZERO_DATE de la variable de mode SQL globale.
NO_AUTO_CREATE_USER
Les migrations d’un serveur source MySQL 5.7 vers un serveur cible MySQL 8.0 qui effectuent la migration de schémas de routines rencontrent des erreurs lors de leur exécution si le mode SQL no_auto_create_user est défini sur le serveur source MySQL 5.7.
Problèmes de rétention binlog
Erreur : Erreur irrécupérable lors de la lecture du binlog. Cette erreur peut indiquer que le nom du fichier binlog et/ou la position initiale ont été spécifiés de manière incorrecte.
Limitation : Cette erreur se produit si la période de rétention du binlog est trop courte.
Solution de contournement : Il existe plusieurs variables qui peuvent être configurées dans ce cas : binlog_expire_logs_seconds détermine la période de rétention, et la suppression du binlog peut être empêchée en définissant binlog_expire_logs_auto_purge sur Désactivé. Dans MySQL 5.7, la variable système expire_logs_days est déconseillée.
Expiration du délai d’obtention de verrous de table
Erreur : Une exception s’est produite lors de la tentative d’acquisition d’un verrou de lecture sur le serveur « {serveur} » pour une création d’affichage cohérente.
Limitation : cette erreur se produit en cas d’expiration du délai d’attente lors de l’obtention de verrous sur toutes les tables lorsque la cohérence transactionnelle est activée.
Solution de contournement : Vérifiez que les tables sélectionnées ne sont pas verrouillées, ou qu’aucune transaction de longue durée ne s’exécute sur ces tables.
Écriture de plus de 4 Mo de données dans le stockage Azure
Erreur : Le corps de la requête est trop volumineux et dépasse la limite maximale autorisée.
Limitation : Cette erreur se produit le plus souvent lorsqu’il y a trop de tables à migrer (>10 000). Il existe une limite de 4 Mo pour chaque appel au service de stockage Azure.
Solution de contournement : Contactez le support en créant une demande de support, et nous pourrons vous fournir des scripts personnalisés pour accéder directement à nos API REST.
Problème d’entrée de clé en double
Erreur: L’erreur est souvent un symptôme d’expiration de délai d’attente, de problème réseau ou de mise à l’échelle de la cible.
Message d’erreur potentiel : Un lot n’a pas pu être écrit dans la table « {table} » en raison d’une erreur SQL levée par le serveur cible. Pour le contexte, le lot contenait un sous-ensemble de lignes retournées par la requête source suivante.
Limitation : Cette erreur peut être due à l’expiration d’un délai d’attente ou à une connexion rompue vers la cible, ce qui entraîne la présence de clés primaires en double. Elle peut également être liée à l’exécution simultanée de plusieurs migrations vers la cible ou à l’exécution de charges de travail de test de l’utilisateur sur la cible pendant l’exécution de la migration. En outre, la cible peut nécessiter que les clés primaires soient uniques, même si la source ne le nécessite pas.
Solution de contournement : Pour résoudre ce problème, vérifiez qu’il n’existe aucune migration en double en cours d’exécution, et que les clés primaires sources sont uniques. Si l’erreur persiste, contactez le support technique en créant une demande de support, et nous pourrons vous fournir des scripts personnalisés pour accéder directement à nos API REST.
L’opération répliquée avait une erreur de lignes incompatibles
Erreur : La migration en ligne ne parvient pas à répliquer le nombre attendu de modifications.
Message d’erreur potentiel : Une erreur s’est produite lors de l’application au serveur cible d’enregistrements qui ont été lus à partir du journal binaire du serveur source. Les modifications ont commencé dans le journal binaire « {mysql-bin.log} » à la position « {position} » et se sont terminées dans le journal binaire « {mysql-bin.log} » à la position « {position} ». Tous les enregistrements sur le serveur source avant la position « {position} » dans le journal binaire « {mysql-bin.log} » ont été commités sur la cible.
Limitation : Sur la source, des instructions d’insertion et de suppression se sont produites dans une table, et les suppressions étaient par un index unique apparent.
Solution de contournement : Nous vous recommandons de migrer la table manuellement.
Erreur de données de table tronquées
Erreur : La colonne Enum a une valeur Null dans une ou plusieurs lignes, et le mode SQL cible est défini sur strict.
Message d’erreur potentiel : Un lot n’a pas pu être écrit dans la table « {table} » en raison d’une erreur de troncation de données. Vérifiez que les données ne sont pas trop volumineuses pour le type de données de la colonne de table MySQL. Si le type de colonne est une énumération, vérifiez que le mode SQL n’est pas défini sur TRADITIONAL, STRICT_TRANS_TABLES ou STRICT_ALL_TABLES et qu’il est identique sur la source et la cible.
Limitation : l’erreur se produit lorsque des données historiques ont été écrites sur le serveur source lorsqu’elles avaient un certain paramètre, mais lorsqu’elles sont modifiées, les données ne peuvent pas être déplacées.
Solution de contournement : Pour résoudre le problème, nous vous recommandons de définir le mode SQL cible sur « non-strict », ou de modifier toutes les valeurs Null pour qu’elles soient des valeurs valides.
Échec de création d’objet
Erreur : Une erreur s’est produite après l’échec de la validation de la vue.
Limitation : l’erreur se produit lorsque vous tentez de migrer une vue, et que la table que la vue est censée référencer est introuvable.
Solution de contournement : Nous vous recommandons de migrer les vues manuellement.
Impossible de trouver la table
Erreur : Une erreur s’est produite, car la table de référence est introuvable.
Message d’erreur potentiel : Le pipeline n’a pas pu créer le schéma de l’objet « {objet} » pour l’activité « {activité} » à l’aide de la stratégie MySqlSchemaMigrationViewUsingTableStrategy à cause d’une exécution de requête.
Limitation : l’erreur peut se produire lorsque la vue fait référence à une table qui a été supprimée ou renommée, ou lorsque la vue a été créée avec des informations incorrectes ou incomplètes. Cette erreur peut se produire si un sous-ensemble de tables est migré, mais que les tables dont elles dépendent ne le sont pas.
Solution de contournement : Nous vous recommandons de migrer les vues manuellement. Vérifiez si toutes les tables référencées dans les clés étrangères et les instructions CREATE VIEW sont sélectionnées pour la migration.
Toutes les connexions mises en pool ont été interrompues
Erreur : Toutes les connexions sur le serveur source ont été interrompues.
Limitation : l’erreur se produit lorsque toutes les connexions acquises au début du chargement initial sont perdues en raison du redémarrage du serveur, de problèmes réseau, d’un trafic élevé sur le serveur source ou d’autres problèmes temporaires. Cette erreur n’est pas récupérable. En outre, cette erreur se produit si une tentative de migration d’un serveur est effectuée pendant la fenêtre de maintenance.
Solution de contournement : La migration doit être redémarrée, et nous vous recommandons d’accroître les performances du serveur source. Un autre problème est que les scripts qui arrêtent les connexions de longue durée empêchent ces scripts de fonctionner.
Instantané cohérent rompu
Limitation : L’erreur se produit lorsque le client effectue une modification DDL pendant le chargement initial de l’instance de migration.
Solution de contournement : Pour résoudre ce problème, nous vous recommandons d’éviter d’apporter des modifications DDL pendant le chargement initial.
Contrainte de clé étrangère
Erreur : L’erreur se produit lorsqu’il existe une modification du type de clé étrangère référencée à partir de la table.
Message d’erreur potentiel : La colonne de référence « {colonne pk 1} » et la colonne référencée « {colonne fk 1} » dans la contrainte de clé étrangère « {clé} » sont incompatibles.
Limitation : l’erreur peut entraîner l’échec de la migration de schéma d’une table, car la colonne PK de la table 1 n’est peut-être pas compatible avec la colonne FK de la table 2.
Solution de contournement : Pour résoudre ce problème, nous vous recommandons de supprimer la clé étrangère et de la recréer une fois le processus de migration terminé.