Forum Aux Questions (FAQ)
Lors de l’utilisation d’Azure Database Migration Service, quelle est la différence entre une migration en ligne et une migration hors connexion ? Azure Database Migration Service prend en charge les migrations hors connexion et en ligne. Dans le cas d’une migration hors connexion, le temps d’arrêt de l’application commence en même temps que le lancement de la migration. Dans le cas d’une migration en ligne, le temps d’arrêt est limité à la durée du basculement à la fin de la migration. Nous vous suggérons de tester une migration hors connexion pour déterminer si le temps d’arrêt est acceptable ; dans le cas contraire, privilégiez une migration en ligne. Les migrations en ligne et hors connexion sont comparées dans le tableau suivant :
Domaine Migration en ligne Migration hors connexion Disponibilité de la base de données pour les lectures pendant la migration Disponible Disponible Disponibilité de la base de données pour les écritures pendant la migration Disponible Cela n’est généralement pas recommandé. Toutes les « écritures » lancées après la migration ne sont pas capturées ou migrées Convenance des applications Applications qui ont besoin d’une durée maximale d’activité Applications qui peuvent se permettre une fenêtre de temps d’arrêt planifiée Adéquation de l’environnement Environnement de production Généralement, le développement, l’environnement de test et certaines production peuvent se permettre un temps d’arrêt Adéquation aux charges de travail lourdes en écriture Approprié, mais risque de réduire la charge de travail lors de la migration Non applicable. Les écritures à la source après le début de la migration ne sont pas répliquées vers la cible Basculement manuel Obligatoire Non requis Temps d’arrêt nécessaire Less Plus Heure de migration Dépend de la taille de la base de données et de l’activité d’écriture jusqu’au basculement Dépend de la taille de la base de données Je configure un projet de migration dans DMS et je rencontre des difficultés pour me connecter à ma base de données source. Que dois-je faire ? Si vous avez des difficultés à vous connecter à votre système de base de données source quand vous travaillez sur la migration, créez une machine virtuelle dans le même sous-réseau de réseau virtuel que celui avec lequel vous avez configuré votre instance DMS. Dans la machine virtuelle, vous devez pouvoir exécuter un test de connexion. Si le test de connexion réussit, vous ne devriez pas avoir de problème de connexion à votre base de données source. Si le test de connexion échoue, contactez votre administrateur réseau.
Pourquoi Azure Database Migration Service est-il arrêté ou indisponible ? Si l’utilisateur arrête de manière explicite Azure Database Migration Service (DMS) ou si le service est inactif pendant une période de 24 heures, le service est dans un état arrêté ou de pause automatique. Dans tous les cas, le service est indisponible et dans un état arrêté. Pour reprendre les migrations actives, redémarrez le service.
Existe-t-il des recommandations pour optimiser les performances d’Azure Database Migration Service ? Vous pouvez essayer d’accélérer la migration de votre base de données à l’aide de DMS :
- Utilisez le niveau tarifaire Usage général avec plusieurs processeurs lorsque vous créez votre instance de service pour permettre au service de tirer parti de multiples processeurs virtuels pour la parallélisation et le transfert plus rapide des données.
- Montez temporairement en puissance votre instance cible Azure MySQL Database vers la référence SKU de niveau Premium pendant l’opération de migration des données pour réduire la limitation Azure MySQL Database pouvant avoir un impact sur les activités de transfert de données lors de l’utilisation de références SKU de niveau inférieur.
Quels composants de données, de schéma et de métadonnées sont migrés dans le cadre de la migration ? Azure Database Migration Service migre le schéma, les données et les métadonnées de la source vers la destination. Tous les composants de données, de schéma et de métadonnées suivants sont migrés dans le cadre de la migration de base de données :
- Migration des données : toutes les tables de toutes les bases de données/schémas.
- Migration de schéma : Affectation de noms, clé primaire, type de données, position ordinale, valeur par défaut, possibilité null, attributs d’incrémentation automatique, index secondaires
- Migration des métadonnées, procédures stockées, fonctions, déclencheurs, vues, contraintes de clé étrangère
Existe-t-il une option pour restaurer une migration de serveur unique vers un serveur flexible ? Vous pouvez effectuer n’importe quel nombre de migrations de test, et après avoir obtenu la confiance grâce au test, effectuez la migration finale. Une migration de test n’a pas d’effet sur le serveur unique source, qui reste opérationnelle et continue la réplication jusqu’à ce que vous effectuiez la migration réelle. Si des erreurs se sont produites pendant la migration de test, vous pouvez choisir de reporter la migration finale et de laisser votre serveur source fonctionner. Vous pouvez retenter la migration finale une fois que vous avez résolu les erreurs. Notez qu’une fois que vous avez effectué une migration finale vers un serveur flexible et que le serveur unique source a été arrêté, vous ne pouvez pas effectuer de restauration du serveur flexible vers un serveur unique.
La taille de ma base de données est supérieure à 1 To. Comment dois-je procéder à la migration ? Pour prendre en charge les migrations de bases de données de 1 To+, déclenchez un ticket de support avec Azure Database Migration Service pour effectuer un scale-up de l’agent de migration pour prendre en charge vos migrations de base de données de 1 To+.
La migration inter-régions est-elle prise en charge ? Azure Database Migration Service prend en charge les migrations inter-régions. Vous pouvez donc migrer votre serveur unique vers un serveur flexible déployé dans une autre région à l’aide de DMS.
La migration entre abonnements est-elle prise en charge ? Azure Database Migration Service prend en charge les migrations entre abonnements. Vous pouvez donc migrer votre serveur unique vers un serveur flexible déployé sur un autre abonnement à l’aide de DMS.
L’abonnement inter-ressources est-il pris en charge ? Azure Database Migration Service prend en charge les migrations entre les groupes de ressources. Vous pouvez donc migrer votre serveur unique vers un serveur flexible déployé dans un autre groupe de ressources à l’aide de DMS.
Existe-t-il une prise en charge inter-versions ? Oui, la migration de serveurs MySQL d’une version antérieure (v5.6 et versions ultérieures) vers des versions ultérieures est prise en charge.