Qu’en est-il du Serveur unique Azure Database pour MySQL ?
S’APPLIQUE À : 
Azure Database pour MySQL – Serveur unique
Important
Azure Database pour MySQL – Serveur unique est en voie d’être mis hors service et a été mis hors service prévue le 16 septembre 2024.
Après avoir évolué pendant des années le service Serveur unique Azure Database pour MySQL ne peut plus gérer toutes les nouvelles fonctionnalités, fonctions et besoins de sécurité. Nous vous recommandons de procéder à la mise à niveau vers le serveur flexible Azure Database pour MySQL avant le 16 septembre 2024 pour éviter l’indisponibilité involontaire de la migration forcée et du serveur.
Le Serveur flexible Azure Database pour MySQL est un service de base de données prêt pour la production, entièrement géré et conçu pour offrir un contrôle et une flexibilité plus précis des fonctions de gestion de base de données et des paramètres de configuration. Pour plus d’informations sur le Serveur flexible, consultez Serveur flexible Azure Database pour MySQL.
Si vous disposez d’un service Azure Database pour MySQL – Serveur unique hébergeant des serveurs de production, nous sommes heureux de vous informer que vous pouvez effectuer la migration de vos serveurs Azure Database pour MySQL – Serveur unique vers le service Azure Database pour MySQL – Serveur flexible gratuitement en utilisant l’importation Azure Database pour MySQL, la migration automatique sur place ou Azure Database Migration Service (classique). Passez en revue les différentes méthodes de migration dans la section ci-dessous.
Dans le cadre de cette mise hors service, nous ne prenons plus en charge la création de nouvelles instances de serveurs uniques à partir du portail Azure depuis le 16 janvier 2023 et à partir d’Azure CLI depuis le 19 mars 2024. Vous pourrez encore créer des réplicas en lecture et effectuer des restaurations (restauration à un instant dans le passé et géorestauration) pour votre instance de serveur unique existante. Cette capacité continuera d’être prise en charge jusqu’à la date de mise hors service du 16 septembre 2024.
Migrer d’un serveur unique vers un serveur flexible
Migration d’une base de données Azure Database pour MySQL - Serveur unique vers Azure Database pour MySQL - Serveur flexible.
| Scénario | outils | Détails |
|---|---|---|
| Hors connexion/en ligne | Importation Azure Database pour MySQL et Azure CLI | Tutoriel : importation Azure Database pour MySQL avec Azure CLI |
| Hors connexion | Database Migration Service (classique) et le Portail Azure | Tutoriel : DMS (classique) avec le Portail Azure (hors connexion) |
| En ligne | Database Migration Service (classique) et le Portail Azure | Tutoriel : DMS (classique) avec le Portail Azure (en ligne) |
| Hors connexion | Demande de migration automatique sur place (Ouvrir un ticket de support Azure) | Migration automatique sur place à partir d’Azure Database pour MySQL – Serveur unique vers Serveur flexible |
Pour plus d’informations sur la migration du Serveur unique vers le Serveur flexible en utilisant d’autres outils de migration, consultez Sélectionner les outils appropriés en vue de la migration vers Azure Database pour MySQL.
Remarque
La migration automatique sur place à partir d’Azure Database pour MySQL : serveur unique vers serveur flexible est une migration sur place lancée par le service pendant la fenêtre de maintenance planifiée aux fins de sélection des charges de travail de bases de données à serveur unique. 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. Si vous êtes propriétaire d’une charge de travail à serveur unique sans fonctionnalité complexe (Réplica en lecture, Réseau virtuel, Chiffrement d’infrastructure double, Point de terminaison de service/Règles de réseau virtuel) activée, vous pouvez désormais vous nommer (si le service ne l’a pas déjà planifié) pour la migration automatique en créant un ticket de support Azure. Pour toutes les autres charges de travail Serveur unique, il est recommandé d’utiliser les outils de migration lancés par l’utilisateur offerts par Azure, c’est-à-dire Azure DMS et Importation Azure Database pour MySQL, pour migrer. En savoir plus sur la migration automatique sur place ici.
Vérifications prérequises lors de la migration d’un serveur unique vers un serveur flexible
- 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 le moteur version v8.x, veillez à mettre à niveau la version de TLS de votre serveur source de v1.0 ou v1.1 vers TLS v1.2 avant la migration, car les versions de TLS antérieures ont été déconseillées pour le serveur flexible.
- 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.
- Les balises de service (SQL) dans les règles de trafic sortant ne sont pas prises en charge sur le serveur flexible Azure Database pour MySQL. Veuillez utiliser le nom de domaine complet (FQDN) dans les règles de trafic sortant lorsque vous configurez les paramètres du pare-feu pour le serveur flexible.
Que se passe-t-il après la date de mise hors service (16 septembre 2024) ?
Nous avons envoyé des notifications périodiques au cours des deux dernières années pour effectuer la migration vers le serveur flexible Azure Database pour MySQL, à la fois via des canaux publics tels qu’Azure Update et des blogs, ainsi que via des contacts directs par des e-mails clients, des pages de produits et des bannières du portail Azure. Dans le cadre de notre communication et de notre assistance en continu pour effectuer la migration des clients en toute sécurité vers leur nouvel environnement, cette section fournit plus d’informations sur l’expérience client pour toutes les charges de travail qui restent en production à compter du 16 septembre 2024.
À compter du 17 septembre, les serveurs non réactifs qui n’ont pas encore été migrés seront régulièrement arrêtés. Vous devrez accéder au portail Azure, accuser réception des actions de migration et démarrer votre serveur. Une fois que vous avez démarré le serveur, utilisez l’interface CLI d’importation Azure Database pour MySQL ou le service Azure Data Migration pour migrer vers Azure Database pour MySQL – Serveur flexible. En revanche, si vous souhaitez poursuivre la migration automatique, envoyez un ticket de support Azure afin de planifier la migration automatique. Veillez à démarrer le serveur et à migrer vers le serveur flexible afin d’éviter une migration forcée involontaire ultérieurement, qui entraînerait une indisponibilité du serveur car seules des fonctionnalités limitées peuvent être migrées.
L’exécution de l’instance de serveur unique au-delà de la date de mise hors service présentera un risque de sécurité, car il n’y aura pas de maintenance de correctifs de sécurité et de bogues sur la plateforme de serveur unique déconseillée. Pour garantir notre engagement envers l’exécution des instances managées sur une plateforme approuvée et sécurisée après la date de mise hors service, votre instance de serveur unique, ainsi que ses fichiers de données, seront migrés de manière forcée en guise de dernier recours vers une instance de serveur flexible appropriée de manière progressive.
Remarque
Aucun contrat SLA, correctif de bogues, correctif de sécurité ou support en direct ne sera respecté pour votre instance de serveur unique après la date de mise hors service.
Migration forcée après la mise hors service
Après la date de mise hors service, votre instance de serveur unique, ainsi que ses fichiers de données, seront migrés de manière forcée vers une instance de serveur flexible appropriée de manière progressive. Cela entraînera une disponibilité limitée des fonctionnalités, car certaines fonctionnalités avancées ne peuvent pas être migrées de force sans entrées client sur l’instance de serveur flexible. Cela entraînera l’indisponibilité du serveur pour les serveurs avec des fonctionnalités de sécurité et de mise en réseau. Apprenez-en davantage sur les étapes de reconfiguration de ces fonctionnalités après la migration forcée afin de réduire l’impact potentiel ci-dessous.
Les fonctionnalités suivantes ne peuvent pas être migrées de manière forcée, car elles nécessitent une entrée client pour la configuration et ne seront pas activées sur l’instance Serveur flexible migrée :
- Liaison privée
- Chiffrement des données (CMK)
- Authentification Microsoft Entra (anciennement Microsoft Entra ID)
- Points de terminaison de service
- Chiffrement double de l’infrastructure
- Réplicas en lecture
Action requise après la migration forcée
Important : Les serveurs uniques avec des fonctionnalités réseau, de sécurité et de chiffrement de données activées sont migrés de force vers une instance de serveur flexible avec un accès public à l’état désactivé afin de protéger les données client. Vous devez activer l’accès approprié après la migration forcée pour garantir la continuité de l’activité.
Après la migration forcée, vous devez reconfigurer les fonctionnalités répertoriées ci-dessus sur l’instance Serveur flexible migrée pour garantir la continuité de l’activité :
- Private Link : vous pouvez choisir d’activer l’accès public pour vous connecter immédiatement à votre serveur ou supprimer l’instance de serveur unique et supprimer le point de terminaison privé associé afin de pouvoir configurer le même point de terminaison privé pour l’instance de serveur flexible migrée. Apprenez-en davantage sur la configuration des points de terminaison privés pour un serveur flexible ici.
- Chiffrement des données (CMK) : apprenez-en davantage sur la configuration ici.
- Authentification Microsoft Entra (anciennement Microsoft Entra ID) : apprenez-en davantage sur la configuration ici.
- Points de terminaison de service : le point de terminaison de service (règle de réseau virtuel) n’est pas pris en charge sur Azure Database pour MySQL – Serveur flexible. Nous vous recommandons de configurer Private Link pour répondre à la parité des fonctionnalités. Apprenez-en davantage sur la manière de configurer Private Link ici.
- Chiffrement double de l’infrastructure : le chiffrement double de l’infrastructure n’est pas pris en charge sur Azure Database pour MySQL – Serveur flexible. Nous vous recommandons de configurer le chiffrement des données pour répondre à la parité des fonctionnalités. Apprenez-en davantage sur la manière de configurer le chiffrement des données (CMK) ici.
- Réplicas en lecture : les réplicas en lecture seront migrés en tant que serveurs autonomes distincts. Configurez des réplicas en lecture pour votre serveur principal en faisant référence au serveur autonome secondaire migré, qui peut être supprimé après la configuration. En savoir plus sur la configuration ici
Remarque
Si votre serveur se trouve dans une région où le serveur flexible Azure Database pour MySQL n’est pas pris en charge, après la date de mise hors service, votre instance de serveur unique sera disponible avec des opérations limitées pour accéder aux données et pour pouvoir migrer vers un serveur flexible jusqu’au 15 novembre 2024. Votre instance ne sera pas migrée de manière forcée vers un serveur flexible avant le 15 novembre 2024. Vos serveurs seront arrêtés durant la première semaine de décembre 2024. Vous pouvez redémarrer votre serveur via le portail Azure ou l’interface CLI et migrer dans un délai de sept jours. Si votre serveur n’est pas migré durant la période de grâce mentionnée ci-dessus, il sera migré de force au cours de la deuxième semaine de décembre 2024. Après le 31 décembre, les serveurs seront supprimés pour mettre hors service la plateforme. Nous vous recommandons vivement d’utiliser l’une des options suivantes pour migrer avant le 22 novembre 2024, afin d’éviter toute interruption de la continuité d’activité :
- Utilisez Azure DMS pour effectuer une migration interrégion vers un serveur flexible dans une région Azure appropriée.
- Migrez vers le serveur MySQL hébergé sur une machine virtuelle dans la région, si vous ne parvenez pas à changer de région en raison de problèmes de conformité.
Configurer les propriétés de Microsoft Defender pour le cloud dans Serveur flexible
Lorsque vous effectuer une migration d’Azure Database pour MySQL – Serveur unique vers Serveur flexible avec Defender pour le cloud activé, l’état d’activation est conservé. Pour obtenir la parité dans Serveur flexible pour les propriétés que vous pouvez configurer dans Serveur unique, tenez compte des détails du tableau suivant.
| Propriété | Configuration |
|---|---|
| Supprimer des types d’alertes spécifiques | Désactivez des types d’alertes spécifiques avec la plateforme Microsoft Defender pour le cloud. Pour plus d’informations, consultez le Guide de suppression des alertes de Microsoft Defender pour le cloud. Les utilisateurs du serveur unique peuvent utiliser la propriété d’API : properties.disabledAlerts |
| Notifications par e-mail | Définissez un e-mail de notification pour les alertes Microsoft Defender pour le cloud pour toutes les ressources d’un abonnement. Pour plus d’informations, consultez Configurer des e-mails de notification pour les alertes de sécurité. Les utilisateurs du serveur unique peuvent utiliser les propriétés d’API : properties.emailAccountAdmins properties.emailAddresses |
| Exporter des alertes pour les traiter et/ou les archiver ultérieurement | Les alertes sont stockées dans la plateforme Microsoft Defender pour le cloud et exposées 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, consultez Configurer l’exportation continue dans le portail Azure – Microsoft Defender pour le cloud. Les utilisateurs du serveur unique peuvent utiliser les propriétés d’API : properties.retentionDays properties.storageAccountAccessKey properties.storageEndpoint |
Forum Aux Questions (FAQ)
Q. Pourquoi le service Serveur unique Azure Database pour MySQL est-il mis hors service ?
R. Le service Serveur unique Azure Database pour MySQL a été mis en disponibilité générale en 2018. Toutefois, étant donné les commentaires des clients et les nouvelles avancées dans les fonctionnalités de calcul, de disponibilité, de scalabilité et de performances dans le paysage des bases de données Azure, l’offre Serveur unique doit être mise hors service et mise à niveau avec une nouvelle architecture (Azure Database pour MySQL – Serveur flexible) afin de vous offrir le meilleur de la plateforme de base de données open source d’Azure. Vous trouverez l’annonce de mise hors service ici.
Q : Pourquoi suis-je invité à migrer vers le Serveur flexible Azure Database pour MySQL ?
A. Le Serveur flexible Azure Database pour MySQL est la plateforme idéale pour exécuter toutes vos charges de travail MySQL sur Azure. Tout en étant économique, le Serveur flexible Azure MySQL offre de meilleures performances dans tous les niveaux de service et d’autres méthodes de contrôle de vos coûts, pour une reprise d’activité moins coûteuse et plus rapide :
- Plus de façons d’optimiser les coûts, notamment la prise en charge des options de calcul de niveau Burstable.
- Amélioration des performances pour les charges de travail de production vitales pour l’entreprise qui nécessitent une faible latence, une haute concurrence élevée, un basculement rapide et une scalabilité élevée.
- Amélioration de la durée de bon fonctionnement avec la possibilité de configurer un serveur de secours sur la même zone ou sur une autre zone, et une fenêtre de temps d’une heure pour la maintenance de serveur planifiée.
Q. À quel moment dois-je migrer mon serveur unique vers un serveur flexible ?
R. La mise hors service du service Serveur unique Azure Database pour MySQL est prévu d’ici le 16 septembre 2024. Nous vous recommandons donc vivement de migrer votre serveur unique vers un serveur flexible dès que possible afin d’être sûr de disposer de suffisamment de temps pour exécuter tout le cycle de vie de la migration, appliquer les avantages offerts par le Serveur flexible et assurer la continuité de votre activité.
Q. Qu’advient-il de mes instances de Serveur unique Azure Database pour MySQL existantes ?
A. Vos charges de travail de serveur unique Azure Database pour MySQL existantes continuent de fonctionner comme avant et sont officiellement prises en charge jusqu’à la date d’expiration. Toutefois, aucune nouvelle mise à jour n’est publiée pour Serveur unique et nous vous conseillons vivement de commencer dès que possible la migration vers Azure Database pour MySQL – Serveur flexible. Après la date de mise hors service, votre instance de serveur unique, ainsi que ses fichiers de données, seront migrés de manière forcée vers une instance de serveur flexible appropriée de manière progressive.
Q : Puis-je choisir de continuer à exécuter le service Serveur unique après la date de mise hors service ?
R. Malheureusement, nous ne prévoyons pas de prendre en charge le Serveur unique au-delà de la date de mise hors service du 16 septembre 2024. Nous vous conseillons donc vivement de commencer dès que possible à planifier votre migration. Après la date de mise hors service, votre instance de serveur unique, ainsi que ses fichiers de données, seront migrés de manière forcée vers une instance de serveur flexible appropriée de manière progressive. Cela peut entraîner une disponibilité limitée des fonctionnalités, car certaines fonctionnalités avancées ne peuvent pas être migrées de force sans entrées client sur l’instance Serveur flexible. Apprenez-en davantage sur les étapes de reconfiguration de ces fonctionnalités après la migration forcée afin de réduire l’impact potentiel ici. Si votre serveur se trouve dans une région où le serveur flexible Azure Database pour MySQL n’est pas pris en charge, après la date de mise hors service, votre instance de serveur unique est disponible avec des opérations limitées pour accéder aux données et pour pouvoir migrer vers un serveur flexible jusqu’au 15 novembre.
Q : Mon instance Serveur unique est déployée dans une région qui ne prend pas en charge Serveur flexible. Qu’arrivera-t-il à mon serveur après la date de mise hors service ?
R : Si votre serveur se trouve dans une région où le serveur flexible Azure Database pour MySQL n’est pas pris en charge, après la date de mise hors service, votre instance de serveur unique est disponible avec des opérations limitées pour accéder aux données et pour pouvoir migrer vers un serveur flexible jusqu’au 15 novembre. Nous vous recommandons vivement d’utiliser l’une des options suivantes pour migrer avant la date de mise hors service, afin d’éviter toute interruption de la continuité des activités :
- Utilisez Azure DMS pour effectuer une migration interrégion vers un serveur flexible dans une région Azure appropriée.
- Migrez vers le serveur MySQL hébergé sur une machine virtuelle dans la région, si vous ne parvenez pas à changer de région en raison de problèmes de conformité.
Q : Après la date de mise hors service, y aura-t-il une perte de données pour mon serveur unique ?
A. Non, votre instance de serveur unique ne subira aucune perte de données. Après la date de mise hors service, votre instance de serveur unique, ainsi que ses fichiers de données, seront migrés de manière forcée vers une instance de serveur flexible appropriée. Si votre serveur se trouve dans une région où le serveur flexible Azure Database pour MySQL n’est pas pris en charge, après la date de mise hors service, votre instance de serveur unique est disponible avec des opérations limitées pour accéder aux données et pour pouvoir migrer vers un serveur flexible dans une région appropriée jusqu’au 15 novembre.
Q : Après l’annonce de la mise hors service du Serveur unique, que se passe-t-il si j’ai encore besoin de créer un serveur unique pour répondre aux besoins de mon entreprise ?
A. Dans le cadre de cette mise hors service, nous ne prendrons plus en charge la création de nouvelles instances de serveur unique à partir du portail Azure à compter du 16 janvier 2023. De plus, à compter du 19 mars 2024, vous ne pourrez plus créer de nouvelles instances de serveur unique Azure Database pour MySQL à l’aide d’Azure CLI. Si vous devez encore créer des instances de serveurs uniques pour répondre à des besoins de continuité de l’activité, créez un ticket de support Azure.
Q : Après l’annonce de la mise hors service du Serveur unique, que se passe-t-il si j’ai encore besoin de créer un réplica en lecture pour mon instance de serveur unique ?
A. Vous pourrez encore créer des réplicas en lecture pour votre instance Serveur unique existante à partir du panneau Réplication, et cela continuera d’être pris en charge jusqu’à la date de mise hors service du 16 septembre 2024.
Q : Des coûts supplémentaires sont-ils associés à l’exécution de la migration ?
R. Lors de l’exécution de la migration, vous payez pour le serveur flexible cible et le serveur unique source. La configuration et le calcul du serveur flexible cible déterminent les coûts supplémentaires engendrés. Pour plus d’informations, consultez les tarifs. Une fois que vous avez désactivé le serveur unique source une fois la migration réussie, vous payez uniquement pour votre serveur flexible en cours d’exécution. L’exécution de la migration par le biais d’Azure Database Migration Service (classique), de la migration automatique sur place ou des outils de migration d’importation Azure Database pour MySQL est gratuite.
Q : Ma facturation sera-t-elle affectée par l’exécution du Serveur flexible par rapport au Serveur unique ?
A. Si vous sélectionnez la haute disponibilité dans la même zone ou redondante interzone pour le serveur flexible cible, le montant de votre facture est plus élevé que celui que vous aviez pour le serveur unique. La même zone ou la haute disponibilité redondante interzone nécessitent qu’un serveur de secours à chaud soit mis en service, avec le stockage de la sauvegarde redondante, ce qui engendre donc un coût supplémentaire. Cette architecture permet de réduire les temps d’arrêt pendant les interruptions non planifiées et la maintenance planifiée. En outre, en fonction de votre charge de travail, les serveurs flexibles peuvent offrir de meilleures performances par rapport aux serveurs uniques, ce qui vous permet d’exécuter votre charge de travail avec une référence SKU inférieure sur les serveurs flexibles, et votre coût global peut donc être similaire à celui d’un serveur unique.
Q : Dois-je subir un temps d’arrêt pour migrer le Serveur unique vers le Serveur flexible ?
R. Pour limiter tout temps d’arrêt que vous risquez de subir, effectuez une migration en ligne vers le Serveur flexible, ce qui réduit les temps d’arrêt.
Q. Y-aura-t-il de futures mises à jour du Serveur unique pour prendre en charge les dernières versions de MySQL ?
R. La dernière mise à niveau de version mineure vers le Serveur unique version 8.0 sera la version 8.0.15. Envisagez de migrer vers le Serveur flexible pour tirer parti des avantages des dernières mises à niveau de version.
Q : En quoi le contrat SLA de disponibilité à 99,99 % du serveur flexible diffère-t-il de celui du serveur unique ?
A. Le déploiement redondant interzone du serveur flexible fournit une disponibilité de 99,99 % avec une résilience au niveau de la zone, tandis que le serveur unique offre une résilience dans une seule zone de disponibilité. L’architecture de haute disponibilité du serveur flexible déploie un secours semi-automatique avec un calcul et un stockage redondants (avec les données de chaque site stockées dans 3 copies), alors que l’architecture de haute disponibilité du serveur unique n’a pas de serveur de secours passif pour faciliter la récupération après des défaillances zonales. L’architecture de haute disponibilité du serveur flexible permet de réduire les temps d’arrêt pendant les interruptions non planifiées et la maintenance planifiée.
Q : Quelles sont les options de migration disponibles pour m’aider à migrer mon serveur unique vers un serveur flexible ?
A. Vous pouvez utiliser l’importation Azure Database pour MySQL (recommandé) pour effectuer la migration. Par ailleurs, vous pouvez utiliser Database Migration Service (classique) pour exécuter des migrations en ligne ou hors connexion.
Q : Mon instance Serveur unique est déployée dans une région qui ne prend pas en charge Serveur flexible. Comment dois-je procéder avec la migration ?
R. Azure Database Migration Service (classique) prend en charge la migration inter-régions. Vous pouvez donc sélectionner une région appropriée pour votre serveur flexible cible, puis procéder à la migration DMS (classique).
Q : J’ai configuré le Magasin des requêtes pour mon serveur unique, et cette fonctionnalité n’est pas prise en charge sur le serveur flexible. Comment effectuer la migration ?
R. Vous pouvez configurer des journaux de requête lentes sur le serveur flexible cible après la migration en suivant les étapes fournies ici pour atteindre la parité des fonctionnalités avec le Magasin des requêtes. Vous pouvez ensuite afficher des aperçus de requête à l’aide d’un modèle de classeurs.
Q : J’ai configuré le point de terminaison de service (règles de réseau virtuel) pour mon serveur unique, et cette fonctionnalité n’est pas prise en charge sur le serveur flexible. Comment effectuer la migration ?
R. Le point de terminaison de service (règle de réseau virtuel) n’est pas pris en charge sur Azure Database pour MySQL – Serveur flexible. Nous vous recommandons de configurer Private Link sur l’instance de serveur flexible migrée pour répondre à la parité des fonctionnalités. Apprenez-en davantage sur la manière de configurer Private Link ici.
Q : J’ai configuré le chiffrement double de l’infrastructure pour mon serveur unique, et cette fonctionnalité n’est pas prise en charge sur le serveur flexible. Comment effectuer la migration ?
R. Le chiffrement double de l’infrastructure n’est pas pris en charge sur Azure Database pour MySQL – Serveur flexible. Nous vous recommandons de configurer le chiffrement des données sur le serveur flexible migré pour répondre à la parité des fonctionnalités. Apprenez-en davantage sur la manière de configurer le chiffrement des données (CMK) ici.
Q : TLS v1.0/1.1 est configuré pour mon serveur unique v8.0, et cette fonctionnalité n’est actuellement pas prise en charge dans le Serveur flexible. Comment effectuer la migration ?
R. Pour prendre en charge les normes de sécurité modernes, l’édition communautaire de MySQL a cessé de prendre en charge la communication via les protocoles TLS (Transport Layer Security) 1.0 et 1.1 à partir de la version 8.0.28. Nous vous recommandons de mettre à niveau vos pilotes clients pour prendre en charge TLSv1.2 afin de vous connecter en toute sécurité à Azure Database pour MySQL - Serveur unique, puis de procéder à la migration vers un serveur flexible.
Q. Existe-t-il une option pour restaurer une migration de serveur unique vers un serveur flexible ?
R. 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érationnel 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. U ne fois que vous avez effectué une migration finale vers le Serveur flexible et que le serveur unique source a été arrêté, vous ne pouvez pas effectuer de restauration du Serveur flexible vers le Serveur unique.
Q : La taille de ma base de données est supérieure à 1 To. Comment dois-je effectuer ma migration ?
A. Vous pouvez utiliser l’importation Azure Database pour MySQL (recommandé) pour la migration des ressources très performantes pour les charges de travail plus volumineuses.
Q : La migration inter-régions est-elle prise en charge ?
R. 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.
Q. La migration entre abonnements est-elle prise en charge ?
R. 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.
Q. L’abonnement inter-ressources est-il pris en charge ?
R. 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.
Q. Existe-t-il une prise en charge inter-versions ?
A. Oui, la migration de serveurs MySQL de versions antérieures (v5.6 et versions ultérieures) vers des versions ultérieures est prise en charge par le biais de migrations Azure Database Migration Service.
Q : Azure Database pour MySQL – Serveur unique utilise des ports autres que les ports par défaut, tels que 3308 3309 et 3310, ce qui n’est pas pris en charge sur Serveur flexible. Que dois-je faire pour garantir la connectivité lors de la migration vers Serveur flexible ?
A. 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.
Q : J’ai d’autres questions sur la mise hors service. Comment puis-je obtenir de l’aide à ce sujet ?
A. Si vous avez des questions, vous pouvez obtenir des réponses des experts de la communauté dans Microsoft Q&A. Si vous disposez d’un plan de support et que vous avez besoin d’une aide technique, créez une demande de support :
- Pour Résumé, entrez une description de votre problème.
- Pour Type de problème, sélectionnez Technique.
- Pour Abonnement, sélectionnez votre abonnement.
- Pour Service, sélectionnez Mes services.
- Pour Type de service, sélectionnez Serveur unique Azure Database pour MySQL.
- Pour Ressource, sélectionnez votre ressource.
- Pour Type de problème, sélectionnez Migration.
- Pour Sous-type de problème, sélectionnez Problèmes de migration d’un serveur unique vers un serveur flexible
Pour plus d’informations sur l’utilisation d’Azure Database Migration Service (classique) pour les migrations du Serveur unique vers le Serveur flexible Azure Database pour MySQL, consultez la FAQ.
Nous savons que la migration de services peut être une expérience frustrante, et nous nous excusons à l’avance pour le désagrément que cela pourrait vous causer. Vous pouvez choisir le scénario qui vous convient le mieux et qui est le mieux adapté à votre environnement.