Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La migration de schéma MySQL est une nouvelle fonctionnalité qui permet aux utilisateurs de migrer le schéma pour des objets tels que des bases de données, des tables, des vues, des déclencheurs, des événements, des procédures stockées et des fonctions. Cette fonctionnalité est utile pour automatiser certaines tâches requises pour préparer la base de données cible avant de démarrer une migration.
Implémentation actuelle
Dans l’implémentation actuelle, les utilisateurs peuvent sélectionner les objets serveur (vues, déclencheurs, événements, routines) qu’ils souhaitent migrer sous l’onglet Sélectionner des bases de données dans la section Sélectionner des objets serveur lors de la configuration du projet de migration DMS. En outre, dans la section Sélectionner des bases de données, ils peuvent sélectionner les bases de données dont le schéma doit être migré.
Pour migrer le schéma d’objets de table, accédez à l’onglet Sélectionner des tables . Avant de remplir l’onglet, DMS extrait les tables de la ou des bases de données sélectionnées sur la source et la cible, puis détermine si la table existe et contient des données. Si vous sélectionnez une table dans la base de données source qui n’existe pas dans la base de données cible, la zone sous Migrer le schéma est sélectionnée par défaut. Pour les tables qui existent dans la base de données cible, une note indique que la table sélectionnée contient déjà des données et qu’elle sera tronquée. En outre, si le schéma d’une table sur le serveur cible ne correspond pas au schéma sur le serveur source, la table sera supprimée avant de continuer la migration.
Lorsque vous passez à l’onglet suivant, DMS valide vos entrées et confirme que les tables sélectionnées correspondent si elles ont été sélectionnées sans l’entrée de migration de schéma. Une fois la validation réussie, vous pouvez commencer le scénario de migration.
À mesure que la migration progresse, chaque table est créée avant de procéder à la migration de ses données de la source vers la cible. À l’exception des déclencheurs et des vues, qui sont migrés une fois la migration des données terminée, les autres objets sont créés pour les tables avant la migration des données.
Fonctionnement de la migration de schéma
La migration de schéma est prise en charge par la syntaxe « SHOW CREATE » de MySQL afin de collecter des informations sur le schéma pour les objets à partir de la source. Lors de la migration du schéma des objets de la source vers la cible, DMS traite l’entrée et migre individuellement les objets. DMS encapsule également le classement, le jeu de caractères et d’autres informations pertinentes fournies par la requête « SHOW CREATE » dans la requête de création qui est ensuite traitée sur la cible.
Les routines et les événements sont migrés avant les données. Le schéma de chaque table individuelle est migré juste avant le déplacement des données pour la table. Les déclencheurs sont migrés après la partie migration des données. Pour les vues, étant donné que MySQL valide leur contenu et qu’elles peuvent dépendre d’autres tables, DMS crée d’abord des tables pour les vues avant le début du déplacement des données de base de données, puis il supprime la table temporaire et crée la vue.
Lors de l’interrogation de la source et de la cible, si une erreur temporaire se produit, DMS réessaye d’exécuter les requêtes. Toutefois, si une erreur se produit et que DMS ne parvient pas à récupérer (par exemple, en cas de syntaxe non valide lors de l’exécution d’une migration de mise à niveau de version), DMS échoue et signale ce message d’erreur à la fin de l’opération. Si l’échec se produit lors de la création d’une table, les données de cette table ne sont pas migrées, mais la migration des données et du schéma pour les autres tables sélectionnées est tentée. Si une erreur irrécupérable se produit pour des événements, des routines ou lors de la création de la table temporaire pour des vues, la migration échoue avant l’exécution de la migration pour les tables sélectionnées et les objets migrés après la partie migration des données.
Étant donné qu’une table temporaire est créée pour les vues, en cas d’échec lors de la migration d’une vue, la table temporaire est laissée sur la cible. Une fois le problème sous-jacent résolu et la migration retentée, DMS supprime cette table avant de créer la vue. En guise d’alternative, si vous choisissez de ne pas utiliser la migration de schéma pour les vues lors d’une migration ultérieure, la table temporaire doit être supprimée manuellement avant de migrer manuellement la vue.
Prérequis
Pour qu’une migration de schéma réussisse, vérifiez que les prérequis suivants sont satisfaits.
Privilège « READ » sur la base de données source.
Privilège « SELECT » pour la possibilité de sélectionner des objets dans la base de données
Si vous migrez des vues, l’utilisateur doit disposer du privilège « SHOW VIEW ».
Si vous migrez des déclencheurs, l’utilisateur doit disposer du privilège « TRIGGER ».
Si vous migrez des routines (procédures et/ou fonctions), l’utilisateur doit être nommé dans la clause definer de la routine. En fonction de la version, l’utilisateur doit également disposer du privilège suivant :
Pour la version 5.7, disposer d’un accès « SELECT » à la table « mysql.proc ».
Pour la version 8.0, disposer du privilège « SHOW_ROUTINE » ou du privilège « CREATE ROUTINE », « ALTER ROUTINE » ou « EXECUTE » accordé à une étendue qui inclut la routine.
Si vous migrez des événements, l’utilisateur doit disposer du privilège « EVENT » pour la base de données à partir de laquelle les événements doivent être affichés.
Limites
Lors de la migration d’objets autres que des objets de table, DMS ne prend pas en charge le renommage des bases de données.
Lors de la migration vers un serveur cible qui a bin_log activé, log_bin_trust_function_creators doit âtre activé pour permettre la création de routines et de déclencheurs.
Actuellement, il n’existe aucune prise en charge de la migration de la clause DEFINER pour les objets. Tous les types d’objets avec des definers sur la source sont supprimés et, après la migration, le definer par défaut pour les tables est défini sur la connexion utilisée pour exécuter la migration.
Certaines mises à niveau de version ne sont pas prises en charge s’il existe des changements cassants dans la compatibilité des versions. Pour plus d’informations sur les mises à niveau de version, consultez la documentation MySQL.
Actuellement, nous ne pouvons migrer le schéma que dans le cadre du déplacement des données. Si rien n’est sélectionné pour le déplacement des données, aucune migration de schéma ne se produit. Si une table est sélectionnée pour la migration de schéma, elle est sélectionnée pour le déplacement des données.