Migration d’applications

6 minutes

Une fois que vous avez migré votre base de données locale vers Azure, vous devez mettre à jour vos applications existantes pour leur permettre d’accéder à MySQL à son nouvel emplacement.

Le serveur et la base de données d’origine que vous utilisiez localement contiendront les rôles qui définissent les privilèges associés aux utilisateurs, les opérations qu’ils peuvent exécuter et les objets sur lesquels ils effectuent ces opérations. Azure Database pour MySQL utilise les mêmes mécanismes d’authentification et d’autorisation que PostgreSQL s’exécutant en local.

Dans cette unité, vous allez explorer les mises à jour que vous devez apporter à vos applications pour vous connecter à votre instance Azure Database pour MySQL nouvellement migrée.

Créer les utilisateurs manuellement

Le serveur et la base de données d’origine qui vous utilisiez en local contiendront les utilisateurs, les opérations qu’ils exécutent et les objets sur lesquels ils effectuent ces opérations. Azure Database pour MySQL utilise les mêmes mécanismes d’authentification et d’autorisation que MySQL s’exécutant en local.

Quand vous transférez une base de données MySQL vers Azure Database pour MySQL à l’aide d’Azure Database Migration Service, les utilisateurs ne sont pas copiés. Vous devez recréer manuellement les comptes d’utilisateurs nécessaires pour l’administrateur et les utilisateurs des tables de la base de données cible. Pour effectuer ces tâches, vous devez utiliser le langage SQL ou un utilitaire tel que MySQL Workbench. Exécutez la commande CREATE USER. Utilisez la commande GRANT pour attribuer les privilèges nécessaires à un utilisateur. Par exemple :

CREATE USER 'myuseraccount'@'%' IDENTIFIED BY 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE [Database Name].* TO myuseraccount;
FLUSH PRIVILEGES;

Pour afficher les attributions existantes dans la base de données locale, exécutez l’instruction SQL suivante :

USE [Database Name];

SHOW GRANTS FOR 'myuseraccount'@'%';;

Reconfigurer les applications

Reconfigurer une application de sorte qu’elle se connecte à Azure Database pour MySQL est un processus simple. Cependant, il est essentiel d’élaborer une stratégie de migration des applications.

Considérations relatives à la reconfiguration d’applications MySQL

Dans un environnement d’entreprise, les applications s’exécutant sur les mêmes bases de données MySQL peuvent être nombreuses. De même, ces applications peuvent être exécutées par un grand nombre d’utilisateurs. Aussi, vous voulez être assuré que lorsque vous passerez du système existant à Azure Database pour MySQL, vos systèmes fonctionneront toujours, que les utilisateurs pourront continuer à effectuer leurs tâches et que les opérations stratégiques resteront opérationnelles. Dans le module 1, leçon 2, Considérations relatives à la migration, la plupart des problèmes ont été abordés dans les grandes lignes.

Au moment de migrer une base de données MySQL vers Azure, il y a certains détails à prendre en considération :

Si vous effectuez une migration hors connexion, les données de la base de données MySQL d’origine et les nouvelles bases de données s’exécutant dans Azure risquent de commencer à diverger rapidement si l’ancienne base de données est toujours utilisée. Une migration hors connexion est indiquée si vous mettez un système entièrement à l’arrêt sur une courte période et que vous basculez toutes les applications vers le nouveau système avant de le redémarrer. Cette approche peut ne pas être applicable à un système vital pour l’entreprise. Si vous migrez vers une instance MySQL s’exécutant sur une machine virtuelle Azure, vous pouvez configurer la réplication MySQL entre votre système local et celui qui s’exécute dans Azure. La réplication MySQL native fonctionne dans une seule direction, mais il existe des solutions tierces qui prennent en charge la réplication bidirectionnelle entre les serveurs MySQL. Ces solutions ne fonctionnent pas avec Azure Database pour MySQL.
Si vous effectuez une migration en ligne, le service Azure Database pour MySQL configure la réplication de la base de données locale vers la base de données s’exécutant dans Azure. Après le transfert de données initial, la réplication vérifie que les modifications éventuellement apportées à la base de données locale sont copiées dans la base de données dans Azure, mais pas l’inverse.

Dans les deux cas, vous devez veiller à ne pas perdre de données actives du fait d’un remplacement accidentel. Par exemple, dans le scénario en ligne, les modifications dans une application connectée à la base de données s’exécutant dans Azure Database pour MySQL pourraient être remplacées aveuglément par une application utilisant toujours la base de données locale. Par conséquent, vous devez envisager les approches suivantes :

Migrez les applications en fonction du type de leur charge de travail. Une application qui accède aux données en lecture seule peut basculer sans risque vers la base de données s’exécutant dans Azure Database pour MySQL ; toutes les modifications apportées par les applications qui utilisent encore la base de données locale seront visibles. Vous pouvez aussi adopter la stratégie inverse si les applications en lecture seule n’ont pas besoin de données entièrement à jour.
Migrez les utilisateurs en fonction du type de leur charge de travail. Cette stratégie est comparable à la précédente, sauf que des utilisateurs peuvent générer uniquement des rapports pendant que d’autres modifient les données. Vous pouvez configurer une même application de sorte qu’elle se connecte à la base de données appropriée en fonction des besoins de l’utilisateur.
Migrez les applications en fonction des jeux de données qu’elles utilisent. Si vos applications n’utilisent pas les mêmes sous-ensembles de données, vous pouvez migrer ces applications séparément.

Reconfiguration d’une application

Pour reconfigurer une application, faites-la pointer vers la nouvelle base de données. La plupart des applications bien écrites doivent isoler la logique de connexion (c’est la seule partie du code qui doit être modifiée). Dans de nombreux cas, les informations de connexion peuvent être stockées sous forme d’informations de configuration. Vous n’avez donc que ces informations à mettre à jour.

Vous trouverez les informations de connexion de votre service Azure Database pour MySQL sur le portail Azure, dans la page Chaînes de connexion de votre service Azure Database pour MySQL. Azure fournit les informations pour de nombreux langages et frameworks de programmation courants.

Ouvrir des ports réseau

Comme nous l’avons vu dans la leçon 1 de ce module, Azure Database pour MySQL est un service protégé qui s’exécute derrière un pare-feu. Les clients ne peuvent pas se connecter tant que leur adresse IP n’est pas reconnue par le service. Vous devez ajouter les adresses IP, ou les plages de blocs d’adresses, des clients exécutant des applications qui doivent se connecter à vos bases de données.

Tester et vérifier les applications

Avant de faire basculer les applications et les utilisateurs vers la nouvelle base de données, il est important de vérifier que vous avez tout bien configuré.

Commencez par tester les applications à blanc et connectez-vous sous chaque rôle pour vérifier que les fonctionnalités appropriées sont disponibles.

Ensuite, effectuez des « tests d’imprégnation » pour reproduire le nombre d’utilisateurs exécutant les charges de travail types de manière simultanée sur une période donnée. Supervisez le système et vérifiez que vous avez alloué suffisamment de ressources à votre service Azure Database pour MySQL.

Vous pouvez maintenant commencer à déployer le système pour les utilisateurs. Il peut être utile d’implémenter une forme de test de contrôle de validité (ou « canari »), où un petit sous-ensemble d’utilisateurs est transféré à son insu vers le système. Vous pourrez ainsi vous faire une idée non biaisée de l’expérience utilisateur avec la nouvelle base de données (inchangée, meilleure ou dégradée).