Migration automatique sur place à partir d’Azure Database pour MySQL : serveur unique vers serveur flexible
S’APPLIQUE À :
Azure Database pour MySQL - Serveur unique
La migration automatique sur place d’Azure Database pour MySQL – Serveur unique vers Serveur flexible est une migration sur place initiée par le service pendant la fenêtre de maintenance planifiée pour les charges de travail de base de données Serveur unique avec la référence SKU Essentiel, Usage général ou À mémoire optimisée. Le stockage de données utilisé est <= 20 Gio et aucune fonctionnalité complexe (CMK, Microsoft Entra ID, Réplica en lecture, Private Link) n’est activée. Les serveurs éligibles sont identifiés par le service et reçoivent une notification préalable détaillant les étapes à suivre pour passer en revue les détails de la migration.
La migration sur place offre une expérience de migration hors connexion hautement résiliente avec une réparation spontanée pendant une fenêtre de maintenance planifiée, avec moins de 5 minutes de temps d’arrêt. Il utilise la technologie de sauvegarde et de restauration pour accélérer le temps de migration. Cette migration supprime la surcharge liée à la migration manuelle de votre serveur et vous permet de tirer parti des avantages du serveur flexible, notamment de meilleures performances tarifaires, d’un contrôle granulaire de la configuration de la base de données et des fenêtres de maintenance personnalisée. Voici les étapes clés détaillées de la migration ci-dessous :
- Le serveur flexible cible est déployé et hérite de tous les ensembles de fonctionnalités et propriétés (y compris les paramètres de serveur et les règles de pare-feu) du serveur unique source. Le serveur unique source est défini sur lecture seule et la sauvegarde à partir du serveur unique source est copiée vers le serveur flexible cible.
- Le basculement et le commutateur DNS sont exécutés avec succès dans la fenêtre de maintenance planifiée avec un temps d’arrêt minimal, ce qui permet la maintenance de la même chaîne de connexion après la migration. Les applications clientes se connectent sans interruption au serveur flexible cible sans aucune mise à jour manuelle pilotée par l’utilisateur. En plus des deux formats de chaîne de connexion (serveur unique et serveur flexible) pris en charge sur le serveur flexible migré, les deux formats de nom d’utilisateur (username@server_name et nom d’utilisateur) sont également pris en charge sur le serveur flexible migré.
- Le serveur flexible migré est en ligne et peut désormais être géré via le Portail Azure/CLI. Le serveur unique arrêté est supprimé sept jours après la migration.
Remarque
Si votre instance de serveur unique dispose d’un stockage Usage général V1, votre instance planifiée subit une opération de redémarrage supplémentaire 12 heures avant l’heure de migration planifiée. Cette opération de redémarrage permet d’activer le paramètre de serveur log_bin nécessaire pour mettre à niveau l’instance vers le stockage Usage général V2 avant d’effectuer la migration automatique sur place.
Éligibilité
Si vous être propriétaire d’une charge de travail Serveur unique dont le stockage de données utilise <= 100 Gio et sans aucune fonctionnalité complexe (CMK, Microsoft Entra ID, Réplica en lecture, Private Link) activée, vous pouvez à présent vous désigner vous-même (si ce n’est déjà planifié par le service) pour la migration automatique en envoyant les détails de votre serveur dans ce formulaire.
Configurer des alertes de migration et passer en revue la planification de la migration
Le service envoie une notification préalable aux serveurs éligibles pour la migration automatique sur place.
Voici les méthodes détaillées pour vérifier et configurer les notifications de migration automatique :
- Les propriétaires d’abonnements pour les serveurs uniques planifiés pour la migration automatique reçoivent une notification par e-mail.
- Configurez des alertes d’intégrité de service pour recevoir des notifications de planification et de progression de la migration sur place par e-mail/SMS en suivant les étapes ici.
- Vérifiez la notification sur le Portail Azure de migration sur place en suivant les étapes ici.
Voici les méthodes détaillées pour passer en revue votre planification de migration une fois que vous avez reçu la notification de migration automatique sur place :
Remarque
La planification de la migration sera verrouillée 7 jours avant la fenêtre de migration planifiée, après quoi vous ne pourrez pas replanifier.
- La page de vue d’ensemble du serveur unique pour votre instance affiche une bannière de portail contenant des informations sur votre planification de migration.
- Concernant les serveurs uniques planifiés pour la migration automatique, un nouveau panneau Migration est activé sur le portail. Vous pouvez consulter la planification de la migration en accédant au panneau Migration de votre instance de serveur unique.
- Si vous souhaitez différer la migration, vous pouvez le faire d’un mois à la fois en accédant au panneau Migration de votre instance de serveur unique sur le Portail Azure et en rééchelonnant la migration. Pour cela, vous devez sélectionner une autre fenêtre de migration dans un délai d’un mois.
- Si votre serveur unique possède une référence SKU d’usage général, vous avez l’autre option d’activer la haute disponibilité lors de la révision de la planification de la migration. Étant donné que la haute disponibilité ne peut être activée qu’au moment de la création d’un serveur flexible MySQL, il est fortement recommandé d’activer cette fonctionnalité lors de l’examen de la planification de la migration.
Vérifications préalables pour la migration automatique sur place
Passez en revue les conditions préalables suivantes pour garantir la réussite de la migration automatique sur place :
- L’instance de serveur unique doit être à l’état prêt, et ne doit pas être à l’état arrêté pendant la fenêtre de maintenance planifiée pour que l’auto-migration ait lieu.
- Pour le serveur unique instance avec SSL activé, vérifiez que les trois certificats (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA et DigiCertGlobalRootCA Root CA) sont disponibles dans le magasin racine approuvé. En outre, si vous avez épinglé le certificat à la chaîne de connexion, créez un certificat d’autorité de certification combiné avec les trois certificats avant la migration automatique planifiée pour garantir la continuité de l’activité après la migration.
- Le moteur MySQL ne garantit aucun ordre de tri si aucune clause « SORT » n’est présente dans les requêtes. Après la migration automatique sur place, vous pouvez constater une modification de l’ordre de tri. Si la préservation de l’ordre de tri est cruciale, assurez-vous que vos requêtes sont mises à jour pour inclure la clause « SORT » avant la migration automatique sur place planifiée.
- Si votre serveur unique Azure Database pour MySQL source possède la version du moteur v8.x, veillez à mettre à niveau la version du pilote client .NET de votre serveur source vers la version 8.0.32 pour éviter toute incompatibilité d’encodage après la migration vers un serveur flexible.
- Si votre serveur unique Azure Database pour MySQL source a des noms de règles de pare-feu dépassant 80 caractères, renommez-les pour être sûr que la longueur du nom est inférieure à 80 caractères. (La longueur de nom de règle de pare-feu prise en charge sur le serveur flexible est de 80 caractères, tandis que sur le serveur unique, la longueur autorisée est de 128 caractères.)
- Si votre instance source Azure Database pour MySQL – Serveur unique utilise des ports non définis par défaut tels que 3308 3309 et 3310, remplacez votre port de connectivité par 3306, car les ports non définis par défaut mentionnés ci-dessus ne sont pas pris en charge sur Serveur flexible.
Comment le serveur flexible MySQL cible est-il approvisionné automatiquement ?
Le niveau de calcul et la référence SKU du serveur flexible cible sont approvisionnés en fonction du niveau tarifaire et des cœurs virtuels du serveur unique source, en vous basant sur le tableau suivant.
| Niveau tarifaire du serveur unique | VCores du serveur unique | Niveau du serveur flexible | Nom SKU du serveur flexible |
|---|---|---|---|
| De base | 1 | Expansible | Standard_B1s |
| De base | 2 | Expansible | Standard_B2s |
| Usage général | 4 | GeneralPurpose | Standard_D4ds_v4 |
| Usage général | 8 | GeneralPurpose | Standard_D8ds_v4 |
| Usage général | 16 | GeneralPurpose | Standard_D16ds_v4 |
| Usage général | 32 | GeneralPurpose | Standard_D32ds_v4 |
| Usage général | 64 | GeneralPurpose | Standard_D64ds_v4 |
| Mémoire optimisée | 4 | MemoryOptimized | Standard_E4ds_v4 |
| Mémoire optimisée | 8 | MemoryOptimized | Standard_E8ds_v4 |
| Mémoire optimisée | 16 | MemoryOptimized | Standard_E16ds_v4 |
| Mémoire optimisée | 32 | MemoryOptimized | Standard_E32ds_v4 |
- La version, la région, la *taille de stockage, l’abonnement et le groupe de ressources MySQL pour le serveur flexible cible sont identiques à celles du serveur unique source.
- Pour les serveurs uniques avec moins de 20 Gio de stockage, la taille de stockage est définie sur 20 Gio, car il s’agit de la limite de stockage minimale sur Azure Database pour MySQL – Serveur flexible.
- Les deux formats de nom d’utilisateur ( username@server_name [serveur unique] et nom d’utilisateur [serveur flexible]) sont pris en charge sur le serveur flexible migré.
- Les deux formats de chaîne de connexion ( serveur unique et serveur flexible) sont pris en charge sur le serveur flexible migré.
- Pour l’instance de serveur unique avec le magasin de requêtes activé, le paramètre de serveur « slow_query_log » sur l’instance cible est défini sur ACTIVÉ pour garantir la parité des fonctionnalités lors de la migration vers un serveur flexible. Pour certaines charges de travail, cela peut avoir un impact sur les performances. Si vous constatez une dégradation des performances, définissez ce paramètre de serveur sur « Désactivé » sur l’instance Serveur flexible.
Étapes post-migration
Voici les informations que vous devez connaître après la migration sur place :
Remarque
Après la migration, ne redémarrez pas l’instance Serveur unique arrêtée, car cela peut entraver la connectivité de votre client et de votre application.
- Après que l’opération de migration sur place a été effectuée, copier les propriétés du serveur unique source vers le serveur flexible cible :
- Paramètres de la page d’analyse (paramètres d’alertes, de métriques et de diagnostic)
- Tous les scripts Terraform/CLI que vous hébergez pour manager votre instance de serveur unique doivent être mis à jour avec les références du serveur flexible.
- Pour l’instance de serveur unique avec le magasin de requêtes activé, le paramètre de serveur « slow_query_log » sur l’instance cible est défini sur ACTIVÉ pour garantir la parité des fonctionnalités lors de la migration vers un serveur flexible. Pour certaines charges de travail, cela peut avoir un impact sur les performances. Si vous constatez une dégradation des performances, définissez ce paramètre de serveur sur « Désactivé » sur l’instance Serveur flexible.
- Pour une instance Serveur unique avec Microsoft Defender pour le cloud activé, l’état d’activation est migré. Pour obtenir la parité dans Serveur flexible après la migration automatique pour les propriétés que vous pouvez configurer dans Serveur unique, tenez compte des détails du tableau suivant :
| Propriété | Configuration |
|---|---|
| properties.disabledAlerts | Vous pouvez désactiver des types d’alertes spécifiques à l’aide de la plateforme Microsoft Defender pour le cloud. Pour plus d’informations, consultez l’article Supprimer les alertes de Microsoft Defender pour le cloud. |
| properties.emailAccountAdmins, properties.emailAddresses | Vous pouvez définir de manière centralisée une notification par e-mail pour les alertes Microsoft Defender pour le cloud pour toutes les ressources d’un abonnement. Pour plus d’informations, consultez l’article Configurer des notifications par e-mail pour les alertes de sécurité. |
| properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint | La plateforme Microsoft Defender pour le cloud expose des alertes via Azure Resource Graph. Vous pouvez exporter des alertes vers un autre magasin et gérer la rétention séparément. Pour plus d’informations sur l’exportation continue, consultez l’article Configurer l’exportation continue dans le portail Azure – Microsoft Defender pour le cloud. |
Forum Aux Questions (FAQ)
Q. Pourquoi je fais l’objet d’une migration automatique ?
R. Votre Azure Database pour MySQL : serveur unique instance est éligible pour la migration sur place vers notre offre phare Azure Database pour MySQL : serveur flexible. Cette migration sur place supprime la surcharge liée à la migration manuelle de votre serveur et vous permet de tirer parti des avantages du serveur flexible, notamment de meilleures performances & de meilleurs tarifs, d’un contrôle granulaire de la configuration de la base de données et des fenêtres de maintenance personnalisée.
Q : Comment se déroule la migration automatique ? Quels sont les éléments qu’il migre ?
R. Le serveur flexible est configuré pour correspondre aux mêmes VCores et stockage que celui de votre serveur unique. Ensuite, le serveur unique source est mis à l’état d’arrêt, le fichier de données instantané est pris et copié sur le serveur flexible cible. Le commutateur DNS est effectué pour router toutes les connexions existantes vers la cible et le serveur flexible cible est mis en ligne. La migration automatique migre l’ensemble des fichiers de données du serveur (y compris le schéma, les données et les connexions) en plus des paramètres du serveur (tous les paramètres de serveur modifiés sur la source sont copiés sur la cible, les paramètres de serveur non modifiés prennent la valeur par défaut définie par le serveur flexible) et les règles de pare-feu. Il s’agit d’une migration hors connexion où vous voyez un temps d’arrêt de 5 minutes ou moins.
Q. Comment configurer ou afficher des alertes de migration sur place ?
A. Voici les façons dont vous pouvez configurer des alertes :
- Configurez des alertes d’intégrité de service pour recevoir des notifications de planification et de progression de la migration sur place par e-mail/SMS en suivant les étapes ici.
- Vérifiez la notification de migration sur place sur le Portail Azure en suivant les étapes ici.
Q. Comment puis-je différer la migration planifiée ?
R. Vous pouvez consulter la planification de la migration en accédant au panneau Migration de votre instance de serveur unique. Si vous souhaitez différer la migration, vous pouvez le faire d’un mois au maximum en accédant au panneau Migration de votre instance Serveur unique sur le portail Azure et en replanifiant la migration. Pour cela, vous devez sélectionner une autre fenêtre de migration dans un délai d’un mois. Les détails de la migration seront verrouillés sept jours avant la fenêtre de migration planifiée, après quoi vous ne pourrez pas replanifier. Cette migration sur place peut être reportée mensuellement jusqu’au 16 septembre 2024.
Q : Quel nom d’utilisateur et quelle chaîne de connexion sont pris en charge pour le serveur flexible migré ?
A. Les formats de nom d’utilisateur nom d’utilisateur@nom_serveur (format serveur unique) et nom d’utilisateur (format serveur flexible) sont pris en charge pour le serveur flexible migré. Par conséquent, vous n’êtes pas obligé de les mettre à jour pour maintenir la continuité de votre application après la migration. En outre, les deux formats de chaîne de connexion (format serveur unique et flexible) sont également pris en charge pour le serveur flexible migré.
Q : Comment activer la haute disponibilité pour mon serveur migré automatiquement ??
R. Par défaut, la migration automatique configure la migration vers une instance sans haute disponibilité. Étant donné que la haute disponibilité ne peut être activée qu’au moment de la création du serveur, vous devez l’activer avant la migration automatique planifiée à l’aide de l’option de modification de la planification de migration automatique sur le portail. La haute disponibilité ne peut être activée que pour les références SKU Usage général\À mémoire optimisée sur le serveur flexible cible, car la migration des références SKU Essentiel vers Burstable ne prend pas en charge la configuration de la haute disponibilité.
Q : Verrai-je une différence de prix sur mon déplacement potentiel du serveur unique de base MySQL vers le serveur flexible MySQL ??
A. Peu de serveurs peuvent voir une légère augmentation de prix après la migration (les coûts estimés sont visibles en sélectionnant l’option de modification de la planification de migration automatique sur le portail), car la limite de stockage minimale sur les deux offres est différente (5 Gio sur Serveur unique ; 20 Gio sur Serveur flexible) et le coût de stockage (0,1 USD sur Serveur unique ; 0,115 USD sur Serveur flexible) pour Serveur flexible est légèrement plus élevé que pour Serveur unique. Pour les serveurs concernés, cette augmentation du prix de Serveur flexible offre un débit et des performances améliorés par rapport à ceux de Serveur unique.