Qu’en est-il du Serveur unique Azure Database pour MySQL ?

  • Article

S’APPLIQUE À : Azure Database pour MySQL - Serveur unique

Bonjour Nous avons des actualités à partager : Azure Database pour MySQL – Serveur unique est en voie de mise hors service, devrait être mis hors service d’ici le 16 septembre 2024.

Dans le cadre de cette mise hors service, nous ne prendrons plus en charge la création de nouvelles instances de serveurs uniques à partir du portail Azure à compter du 16 janvier 2023 et à partir d’Azure CLI à compter du 19 mars 2024. 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. 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.

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 recommandons de procéder à la mise à niveau vers le Serveur flexible Azure Database pour MySQL.

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 de serveur unique Azure Database pour MySQL hébergeant des serveurs de production, nous sommes heureux de vous informer que vous pouvez effectuer la migration de vos serveurs uniques Azure Database pour MySQL vers le service de serveur flexible Azure Database pour MySQL 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.

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 Outil(s) 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 Nomination de migration automatique sur place [formulaire] (https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR4lhLelkCklCuumNujnaQ-ZUQzRKSVBBV0VXTFRMSDFKSUtLUDlaNTA5Wi4u) 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 disposez d’une charge de travail de serveur unique avec une référence SKU De base ou GP, le stockage de données utilisait <= 20 Gio et qu’aucune fonctionnalité complexe (CMK, AAD, Réplica en lecture, Private Link) activée, vous pouvez maintenant 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 via ce formulaire. 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.

Que se passera-t-il après la date de mise hors service (16 septembre 2024) ?

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 vers une instance de serveur flexible appropriée de manière progressive. Nous vous recommandons vivement d’utiliser l’interface CLI d’importation Azure Database pour MySQL ou Azure Data Migration Service pour migrer vers Azure Database pour MySQL – Serveur flexible avant le 16 septembre 2024 (consultez le FAQ pour en savoir plus) afin d’éviter toute interruption causée par la migration forcée et de garantir la continuité de l’activité.

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 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 de 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 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 de serveur flexible migrée :

  • Liaison privée
  • Chiffrement des données (CMK)
  • Authentification Microsoft Entra (anciennement AAD)
  • Points de terminaison de service
  • Chiffrement double de l’infrastructure
  • Réplicas en lecture

Action requise après la migration forcée

Après la migration forcée, vous devez reconfigurer les fonctionnalités répertoriées ci-dessus sur l’instance de serveur flexible migrée pour garantir la continuité de l’activité :

  • Private Link : apprenez-en davantage sur la configuration ici.
  • Chiffrement des données (CMK) : apprenez-en davantage sur la configuration ici.
  • Authentification Microsoft Entra (anciennement AAD) : 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 : apprenez-en davantage sur la configuration ici.

Important : Les serveurs uniques avec des fonctionnalités réseau et de sécurité 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é.

Remarque

Si votre serveur se trouve dans une région où Azure Database pour MySQL – Serveur flexible 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. Votre instance ne sera pas migrée de manière forcée vers un serveur flexible. 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é.

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.

Q : Pourquoi suis-je invité à migrer vers le Serveur flexible Azure Database pour MySQL ?

A.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 ?

R. Vos charges de travail de Serveur unique Azure Database pour MySQL existantes continueront de fonctionner comme avant et seront officiellement prises en charge jusqu’à la date de mise hors service. Toutefois, aucune nouvelle mise à jour ne sera publiée pour le Serveur unique et nous vous conseillons vivement de commencer dès que possible la migration vers le Serveur flexible Azure Database pour MySQL. 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 de 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ù Azure Database pour MySQL – Serveur flexible 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.

Q : Mon serveur unique est déployé dans une région qui ne prend pas en charge le serveur flexible. Qu’arrivera-t-il à mon serveur après la date de mise hors service ? A. Si votre serveur se trouve dans une région où Azure Database pour MySQL – Serveur flexible 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. 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ù Azure Database pour MySQL – Serveur flexible 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 dans une région appropriée.

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 de 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 ?

R. Si vous sélectionnez la même zone ou la haute disponibilité redondante interzone pour le serveur flexible cible, votre facture sera plus élevée que celle 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é de 99,99 % du serveur flexible diffère-t-il de celui du serveur unique ?

R. 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 serveur de secours actif 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 serveur unique est déployé dans une région qui ne prend pas en charge le 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 insights 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é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. 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 ?

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. 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 :

  1. Pour Résumé, entrez une description de votre problème.
  2. Pour Type de problème, sélectionnez Technique.
  3. Pour Abonnement, sélectionnez votre abonnement.
  4. Pour Service, sélectionnez Mes services.
  5. Pour Type de service, sélectionnez Serveur unique Azure Database pour MySQL.
  6. Pour Ressource, sélectionnez votre ressource.
  7. Pour Type de problème, sélectionnez Migration.
  8. Pour Sous-type de problème, sélectionnez Problèmes de migration d’un serveur unique vers un serveur flexible

Vous pouvez également contacter l’équipe produit Azure Database pour MySQL à l’adresse AskAzureDBforMySQL@service.microsoft.com.

Avertissement

Cet article n’est pas destiné aux utilisateurs du service Serveur flexible Azure Database pour MySQL. Il s’adresse aux clients du Serveur unique Azure Database pour MySQL qui doivent effectuer une mise à niveau vers le Serveur flexible MySQL.

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.

Étapes suivantes