Migration de bases de données vers Azure

La migration de bases de données locales vers Azure offre notamment les avantages suivants : réduction de la charge opérationnelle (aucun matériel à gérer), haute disponibilité et sauvegardes intégrées, ainsi que possibilité de faire évoluer élastiquement le calcul et le stockage à la demande. Les organisations migrent également pour respecter des obligations donnant la priorité au cloud, retirer du matériel vieillissant de leurs centres de données ou tirer parti de fonctionnalités avancées telles que la géoréplication et l’optimisation intelligente des requêtes.

La migration d’une base de données suit généralement l’une de deux grandes stratégies. Une migration hors ligne met la base de données source hors ligne, copie les données vers la cible, puis bascule les applications vers le nouveau point de terminaison — cette approche est simple, mais nécessite une fenêtre de maintenance. Une migration en ligne utilise la réplication continue des données pour maintenir la cible synchronisée avec la source pendant que celle-ci reste active, puis effectue le basculement avec un temps d’interruption minimal, de l’ordre de quelques secondes ou minutes.

Azure Database Migration Service (DMS) est un outil entièrement géré qui orchestre les migrations de bases de données depuis un large éventail de sources — SQL Server, MySQL, PostgreSQL, MongoDB, Oracle, etc. — vers les cibles Azure gérées correspondantes. DMS gère la conversion du schéma, le déplacement des données et la réplication, et affiche l’état de la migration ainsi que les erreurs dans un tableau de bord unique.

Avant de migrer, exécutez une évaluation préalable à la migration afin d’identifier les problèmes de compatibilité entre la base de données source et le service Azure cible. L’extension Database Migration Assessment for SQL Server d’Azure Data Studio analyse les procédures stockées, les déclencheurs et les requêtes pour détecter les fonctionnalités qui ne sont pas prises en charge dans Azure SQL Database ou SQL Managed Instance, puis vous fournit une liste hiérarchisée des éléments à corriger avant le basculement.

La migration de SQL Server vers Azure SQL Database (base de données unique) convient bien aux applications dotées d’une seule base de données et n’utilisant aucune fonctionnalité au niveau de l’instance (comme SQL Agent ou les requêtes interbases). Si l’évaluation révèle des dépendances au niveau de l’instance, Azure SQL Managed Instance constitue une migration quasiment 100 % compatible du moteur SQL Server vers un conteneur PaaS, tout en conservant les tâches SQL Agent, les serveurs liés et les objets CLR.

Azure DMS utilise Log Replay Service (LRS) pour les migrations en ligne de SQL Server vers Azure SQL Managed Instance. LRS lit en continu les sauvegardes des journaux de transactions depuis un conteneur Azure Blob Storage et les rejoue sur l’instance Managed Instance cible, afin de la maintenir synchronisée avec la source. Le basculement final est déclenché manuellement et s’achève en quelques secondes, réduisant presque à zéro la fenêtre de maintenance.

Pour déplacer des bases de données PostgreSQL vers Azure, DMS prend en charge à la fois la migration hors ligne (pg_dump/pg_restore) et la migration en ligne via la réplication logique. Le serveur PostgreSQL source doit avoir la réplication logique activée (wal_level = logical) et l’utilisateur de migration doit disposer des privilèges de réplication. DMS gère la migration du schéma, le chargement initial complet et la capture des modifications jusqu’au basculement final.

DMS migre les bases de données MySQL vers Azure Database for MySQL Flexible Server en utilisant le journal binaire MySQL pour assurer la réplication continue. L’instance MySQL source doit avoir binlog_format = ROW et la journalisation binaire activée. L’assistant de migration du portail Azure vous guide pour connecter la source et la cible, sélectionner les bases de données et surveiller la progression de la migration ainsi que le retard avant le basculement.

Pour réaliser une migration avec peu d’interruptions, il faut terminer le chargement initial massif suffisamment à l’avance, puis laisser la capture des modifications s’exécuter jusqu’à ce que le retard de réplication soit presque nul. À ce stade, vous devez : arrêter les écritures sur la source, attendre que les dernières modifications soient transmises à la cible, mettre à jour la chaîne de connexion de l’application, puis commencer les écritures sur la nouvelle cible. Une gestion attentive de la durée de vie TTL du DNS et un basculement bleu-vert peuvent réduire encore davantage l’impact.

Après le basculement, validez la migration en comparant le nombre de lignes des tables source et cible, en exécutant les principales requêtes de l’application pour vérifier l’exactitude des données et en vous assurant que toutes les procédures stockées, vues et fonctions renvoient les résultats attendus. Surveillez la cible pour détecter les régressions des performances des requêtes en comparant les plans d’exécution, puis mettez à jour les statistiques et reconstruisez les index sur la cible afin de garantir des performances optimales dès le premier jour.

Azure Migrate fournit des fonctionnalités de détection et d’évaluation des bases de données en complément de ses fonctions d’évaluation des serveurs. L’appliance Azure Migrate analyse votre environnement local pour inventorier les instances SQL Server, estimer leur dimensionnement et leur coût équivalents dans Azure, et signaler les problèmes de compatibilité. Il constitue donc le point de départ logique avant d’utiliser DMS pour exécuter la migration.

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris qu’Azure Database Migration Service orchestre les migrations depuis de nombreux moteurs sources, que les migrations en ligne utilisent la capture des modifications pour réduire les interruptions lors du basculement, et qu’une évaluation préalable à la migration permet d’identifier les problèmes de compatibilité avant de commencer. Nous allons maintenant découvrir Azure Identity et Microsoft Entra ID.