Partager via

Migration automatique d’un serveur unique Azure Database pour PostgreSQL vers un serveur flexible

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

Le serveur unique Azure Database pour PostgreSQL a maintenant été mis hors service. Par conséquent, les articles de migration liés à ce service seront bientôt supprimés. Il est essentiel de migrer vers un serveur flexible Azure Database pour PostgreSQL afin de garantir un service et une prise en charge continus. Passez en revue et effectuez toutes les migrations nécessaires vers le serveur flexible avant que ces ressources ne soient plus disponibles.

La migration automatique d’Azure Database pour PostgreSQL – Serveur unique vers un serveur flexible est une migration initiée par le service qui se déroule pendant une fenêtre de temps d’arrêt planifiée pour un serveur unique, distincte de sa fenêtre de mise à jour corrective ou de maintenance. Le service identifie les serveurs éligibles et envoie des notifications préalables contenant les étapes détaillées du processus de migration automatique. Vous pouvez examiner et ajuster le calendrier de migration si nécessaire ou soumettre une demande de support pour refuser la migration automatique pour vos serveurs.

La migration automatique utilise le service de migration Azure PostgreSQL pour fournir une migration hors connexion résiliente pendant la fenêtre de migration planifiée. Le temps d’arrêt varie en fonction des caractéristiques de la charge de travail. Pour connaître les benchmarks de vitesse de migration, consultez l’évaluation de la vitesse de migration d’Azure PostgreSQL. Cette migration supprime la nécessité de la migration manuelle du serveur. Après la migration, vous pouvez bénéficier de fonctionnalités de serveur flexible, telles que des performances améliorées, un contrôle de configuration de base de données granulaire et des fenêtres de maintenance personnalisées.

Remarque

Le service de migration automatique peut migrer tous les serveurs individuels, sauf dans les cas suivants :

  • Serveurs avec des clés gérées par le client configurées
  • Serveurs avec refuser l’accès réseau public défini sur Oui

Nommer des serveurs uniques pour la migration automatique

Le processus de nomination est destiné aux utilisateurs qui souhaitent accélérer volontairement leur migration vers un serveur flexible. Si vous possédez une charge de travail de serveur unique, vous pouvez vous nommer vous-même (si ce n’est pas déjà planifié par le service) pour la migration automatique. Envoyez les détails de votre serveur via ce formulaire.

Vérifications préalables à la migration automatique

Passez en revue les prérequis suivants pour garantir la réussite de la migration automatique :

  • L’instance de serveur unique doit être en état prêt pendant la fenêtre de migration planifiée pour que la migration automatique se produise.

  • L’instance serveur unique doit avoir le paramètre Refuser l’accès réseau public configuré sur Non. Vous trouverez cette option dans la page Sécurité des connexions dans le portail Azure.

  • Pour une instance de serveur unique avec SSL activé, vérifiez que vous disposez de tous les certificats (Racine de l'Autorité de Certification de DigiCertGlobalRootG2 et Racine de l'Autorité de Certification de DigiCertGlobalRootCA) disponibles dans le dépôt racine de confiance. 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.

  • Si votre serveur unique Azure Database pour PostgreSQL source a des noms de règles de pare-feu dépassant 80 caractères, renommez-les pour être sûr que leur longueur est inférieure à 80 caractères. (La longueur des noms de règle de pare-feu prise en charge sur un serveur flexible est de 80 caractères, tandis que la longueur autorisée sur un serveur unique est de 128 caractères.)

Processus de migration automatique

Le processus de migration automatique comprend plusieurs phases clés :

  • Création de serveur flexible cible : un serveur flexible est créé pour équivaloir aux performances et au coût de votre SKU de serveur unique. Il hérite de toutes les règles de pare-feu du serveur unique source.

  • Migration des données : la migration de données se produit pendant la fenêtre de migration désignée, généralement planifiée en dehors des heures d’ouverture du serveur pour la région d’hébergement du serveur (si la fenêtre est choisie par le service). Le serveur source unique est configuré en lecture seule. La migration transfère toutes les données, schémas, rôles d’utilisateur, privilèges et propriété d’objet de base de données au serveur flexible. Il copie également toutes les règles de pare-feu existantes sur le serveur flexible, garantissant ainsi une connectivité ininterrompue.

  • Commutateur DNS : après la migration des données, un commutateur DNS est effectué, ce qui permet à la chaîne de connexion serveur unique existante de se connecter en toute transparence au nouveau serveur flexible. Les formats de chaîne de connexion serveur unique et flexible, ainsi que les formats de nom d’utilisateur (username@server_name et nom d’utilisateur), sont pris en charge sur le serveur flexible migré.

  • Visibilité du serveur flexible : après une migration de données réussie et un commutateur DNS, le nouveau serveur flexible apparaît sous votre abonnement et peut être géré via le portail Azure ou l’interface CLI.

  • Chaînes de connexion à serveur unique mises à jour : les chaînes de connexion mises à jour pour le serveur unique hérité sont envoyées via des notifications Service Health sur le portail Azure. Ils sont également accessibles sur la page portail serveur unique sous Paramètres -> Chaînes de connexion.

  • Suppression d’un serveur unique : le serveur unique est conservé pendant sept jours après la migration avant sa suppression.

Comment le serveur flexible Postgresql cible est-il approvisionné ?

Le niveau de calcul et la référence SKU du serveur flexible cible sont provisionnés en fonction du niveau tarifaire et des vCores du serveur unique source.

Niveau tarifaire du serveur unique VCores du serveur unique Niveau du serveur flexible Nom SKU du serveur flexible
De base 1 Burstable B1ms
De base 2 Burstable B2s
Usage général 2 Usage Général Standard_D2s_v3
Usage général 4 Usage Général Standard_D4s_v3
Usage général 8 Usage Général Standard_D8s_v3
Usage général 16 Usage Général Standard_D16s_v3
Usage général 32 Usage Général Standard_D32s_v3
Usage général 64 Usage Général Standard_D64s_v3
À mémoire optimisée 2 MemoryOptimized Standard_E2s_v3
À mémoire optimisée 4 MemoryOptimized Standard_E4s_v3
À mémoire optimisée 8 MemoryOptimized Standard_E8s_v3
À mémoire optimisée 16 MemoryOptimized Standard_E16s_v3
À mémoire optimisée 32 MemoryOptimized Standard_E32s_v3
  • La version, la région, la chaîne de connexion, l’abonnement et le groupe de ressources du serveur flexible cible restent 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 32 Gio, car il s’agit de la limite de stockage minimale sur le serveur flexible Azure Database pour PostgreSQL.
  • Pour les serveurs uniques qui ont besoin d’un plus grand stockage, le stockage nécessaire qui est alloué équivaut à 1,25 fois plus ou 25 % de plus que le stockage utilisé sur les serveurs uniques. Pendant la première copie de base des données, plusieurs instructions d’insertion sont exécutées sur la cible, ce qui génère des journaux WAL (Write Ahead Logs). Tant que les journaux WAL ne sont pas archivés, ils consomment du stockage sur la cible, d’où la nécessité d’une marge de sécurité.
  • Les deux formats de nom d’utilisateur ( nomutilisateur@nom_serveur [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é.

Migration automatique sur les versions majeures de PostgreSQL

Cette migration peut impliquer le déplacement de données du serveur unique PostgreSQL (versions 9.5, 9.6 ou 10) vers PostgreSQL 11 sur un serveur flexible. La communauté PostgreSQL a mis hors service ces versions antérieures. Pour garantir la sécurité, la stabilité et les performances, il est recommandé d’adopter les versions de la communauté prises en charge.

Quand vous effectuez une migration sur des versions majeures de PostgreSQL, prenez en compte les facteurs clés suivants pour garantir une transition réussie et fluide :

  • Fonctionnalités supprimées : les fonctionnalités mises hors service dans les versions antérieures peuvent ne plus être disponibles dans PostgreSQL 11. Il est important de passer en revue les notes de publication pour identifier les changements cassants ou les fonctionnalités déconseillées susceptibles d’affecter votre application.

  • Test des applications : effectuez des tests approfondis de votre application sur PostgreSQL 11. Faites attention aux problèmes potentiels liés aux requêtes, fonctions ou outils tiers SQL, car ils peuvent se comporter différemment ou échouer entièrement en raison des modifications apportées à la version la plus récente.

  • Modifications de configuration : les mises à niveau de version majeures introduisent souvent des modifications apportées aux paramètres du serveur, soit en ajoutant de nouveaux paramètres, soit en modifiant les valeurs par défaut des valeurs existantes. Ces changements peuvent affecter le classement, l’exécution des requêtes et le stockage des données. Pour garantir la compatibilité, testez votre application en fonction de ces paramètres mis à jour et résolvez les problèmes qui surviennent. Si vous rencontrez des problèmes, utilisez le script fourni dans la section des étapes postérieures à la migration pour copier les paramètres de serveur existants de votre instance serveur unique vers le serveur flexible automigrated.

Étapes post-migration

Voici les informations dont vous avez besoin concernant les étapes postérieures à la migration automatique.

  • Si la migration automatique implique une migration sur les versions majeures de PostgreSQL, testez votre application en profondeur pour identifier l’impact des changements cassants et des ajustements de paramètres. Apportez les changements nécessaires pour garantir la compatibilité et des performances optimales.

  • Tous les scripts Terraform/CLI que vous hébergez pour gérer votre instance de serveur unique doivent être mis à jour avec les références du serveur flexible.

  • Les paramètres de serveur du serveur flexible sont définis par rapport aux normes de la communauté. Si vous souhaitez conserver les mêmes valeurs de paramètres de serveur que votre serveur unique, vous pouvez vous connecter via PowerShell et exécuter le script ici pour copier les valeurs des paramètres.

  • Les paramètres de contrôle d’accès (IAM) de votre serveur flexible sont hérités des paramètres d’abonnement. Si vous avez fourni des attributions de rôles spécifiques au serveur unique, vous devez créer ces attributions de rôles sur votre serveur flexible.

  • Copiez les paramètres de la page de surveillance (Alertes, Métriques et Paramètres de diagnostic) sur le serveur flexible.

  • Pour activer les analyses sur les requêtes, vous devez activer le stockage des requêtes sur le serveur flexible, car il n'est pas activé par défaut.

  • Si la haute disponibilité est nécessaire, vous pouvez l’activer sans temps d’arrêt.

  • Vérifiez que la référence SKU de votre serveur flexible correspond à celle mentionnée dans la notification d’automigration Service Health. S’il est différent, rétablissez-le à la référence SKU spécifiée dans la notification. Cette opération est essentielle pour que la facturation soit exacte.

  • Les chaînes de connexion existantes de votre serveur unique pointent désormais vers le serveur flexible. Pour accéder à votre serveur unique, un nouvel ensemble de chaînes de connexion est généré. Vous pouvez les récupérer à partir de la notification Service Health envoyée pour la migration automatique de votre serveur unique.

Gestion des règles de réseau virtuel dans un serveur flexible

Dans Azure Database pour PostgreSQL Single Server, une règle de réseau virtuel (réseau virtuel) est un sous-réseau répertorié dans la liste de contrôle d’accès (ACL) du serveur. Cette règle permet au serveur unique d’accepter les communications provenant de nœuds au sein de ce sous-réseau en particulier. Pour le serveur flexible, les règles de réseau virtuel ne sont pas prises en charge. Au lieu de cela, le serveur flexible permet la création de points de terminaison privés, ce qui permet au serveur de fonctionner au sein de votre réseau virtuel. Un point de terminaison privé affecte une adresse IP privée au serveur flexible, et tout le trafic entre votre réseau virtuel et le serveur transite ainsi en sécurité via le réseau principal Azure sans avoir besoin d’être exposé à l’Internet public.

Après la migration, vous devez ajouter un point de terminaison privé à votre serveur flexible pour tous les sous-réseaux précédemment couverts par des règles de réseau virtuel sur votre serveur unique. Vous pouvez effectuer ce processus à l’aide du portail Azure ou d’Azure CLI. Une fois cette étape terminée, votre connectivité réseau reste intacte sur le serveur flexible après la migration depuis le serveur unique.

Sauvegarde de conservation à long terme

La migration automatique de serveurs uniques ne configure pas automatiquement la sauvegarde de rétention à long terme (LTR) après la migration vers un serveur flexible. Vous pouvez sauvegarder Azure Database pour PostgreSQL serveur flexible avec une rétention à long terme à l'aide de Azure Backup.

Comment vérifier si votre serveur unique est planifié pour une migration automatique

Pour déterminer si votre serveur unique est sélectionné pour la migration automatique, suivez ces étapes :

  • Notifications de l'état du service - Dans le portail Azure, accédez aux événements de maintenance planifiée de l'état du service>. Recherchez les événements étiquetés « Notification pour la migration automatique planifiée vers un serveur unique Azure Database pour PostgreSQL ». Les notifications sont envoyées 30 jours, 14 jours et 7 jours avant la date de migration, puis à nouveau pendant les étapes de la migration : en cours, terminée et six jours avant que le serveur unique ne soit mis hors service.

    Remarque

    Ces notifications ne atterrissent pas dans votre boîte de réception par défaut. Pour les recevoir par e-mail ou SMS, vous devez configurer les alertes de santé du service. Pour plus d’informations, consultez Configurer des alertes Service Health.

  • Page Vue d’ensemble du serveur unique : accédez à votre instance de serveur unique dans le portail Azure et consultez la page Vue d’ensemble. Si la migration automatique est planifiée, vous trouverez les détails ici.

    Remarque

    Le calendrier de migration est fixé sept jours avant la fenêtre de migration, au cours de laquelle vous ne pouvez pas replanifier.

  • Notifications par e-mail Azure CXP : Azure Customer Experience(CXP) envoie également des e-mails directs aux rôles classiques et aux rôles RBAC associés à l’abonnement contenant le serveur unique, fournissant des informations sur lesmigrations automatiques à venir.

Forum aux questions (FAQ)

Q. Pourquoi fais-je l’objet d’une migration automatique ?

R. Votre instance de serveur unique Azure Database pour PostgreSQL est éligible à la migration automatique vers notre offre phare de serveur flexible Azure Database pour PostgreSQL. Cette migration automatique remplace le traitement manuel de la migration de votre serveur. Vous pouvez bénéficier des avantages du serveur flexible, notamment de meilleures performances à un meilleur prix, d’un contrôle précis sur la configuration des bases de données et de fenêtres de maintenance personnalisées.

Q. Comment se déroule la migration automatique ? Quels sont les éléments qu’elle migre ?

R. Le serveur flexible est configuré pour correspondre aux mêmes vCores et stockage que ceux de votre serveur unique. Une fois que le serveur unique source est mis en lecture seule, le schéma et les données sont copiés 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 les bases de données (y compris le schéma, les données, les utilisateurs/rôles et les privilèges). La migration est hors connexion où vous voyez des temps d’arrêt de quelques minutes jusqu’à quelques heures en fonction de la taille de votre charge de travail. Pour connaître les benchmarks de vitesse de migration, consultez l’évaluation de la vitesse de migration d’Azure PostgreSQL.

Q. Comment configurer ou afficher des alertes de migration automatique ?

R. Voici comment vous pouvez configurer des alertes :

  • Configurez les alertes de santé du service pour recevoir la planification de la migration automatique et les notifications de progression par e-mail ou SMS en suivant les étapes ici.
  • Consultez la notification d’migration automatique sur le portail Azure en suivant les étapes ci-dessous.

Q. Comment refuser une migration automatique planifiée de mon serveur unique ?

R. Si vous souhaitez refuser une migration automatique, vous pouvez créer un ticket de support à cet effet.

Q. Quelles étapes post-migration dois-je suivre si mon serveur unique utilise des règles de réseau virtuel ?

A. Les règles de réseau virtuel ne sont pas prises en charge sur un serveur flexible. Reportez-vous à cette section

Q. Dois-je reconfigurer les sauvegardes de conservation à long terme sur un serveur flexible ?

R. Oui. Reportez-vous à cette section

Q. Quel nom d’utilisateur et quelle chaîne de connexion sont pris en charge pour le serveur flexible migré ? ​​

R. Les formats de nom d’utilisateur nomutilisateur@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. Je vois une différence de prix sur mon déplacement potentiel de postgresql Basic Single Server vers postgresql Flexible Server

R. Seul un petit nombre de serveurs peut faire l’objet d’une révision mineure du prix après la migration, car la limite de stockage minimale sur les deux offres est différente (5 Gio sur un serveur unique et 32 Gio sur un serveur flexible). Le coût de stockage du serveur flexible est légèrement supérieur à celui du serveur unique. Toute augmentation de prix est compensée par un meilleur débit et de meilleures performances par rapport au serveur unique. Pour plus d’informations sur la tarification du serveur flexible, consultez ce document

Q. Que se passe-t-il si je ne migre pas ou si mon serveur n’est pas migré automatiquement le 28 mars 2025

R. Après l’échéance de mise hors service du 28 mars 2025, tous les serveurs uniques existants qui ne sont pas migrés seront migrés par force vers un serveur flexible. Les serveurs dotés de fonctionnalités supplémentaires telles que le point de terminaison privé et les réplicas de lecture nécessitent davantage d’actions de la part de l’utilisateur après la migration pour garantir un fonctionnement normal. Il n’existe aucune prolongation de la date de mise hors service.

Q. Existe-t-il des mises en garde lors de l’exécution d’une mise à niveau de version majeure (MVU) sur un serveur automigrat ?

A. Oui, il y a une mise en garde importante dont il faut être conscient. Bien que les mises à niveau de version majeure vers n’importe quelle version de PostgreSQL prise en charge sur le serveur Flexible soient entièrement prises en charge pour les serveurs automigrées, le format de la chaîne de connexion change légèrement après une mise à niveau réussie. Plus précisément, le format de nom d’utilisateur « username@servername » ne sera plus pris en charge après la mise à niveau. Si votre application ou vos scripts utilisent actuellement ce format dans la chaîne de connexion, vous devez les mettre à jour pour utiliser le format standard : simplement « nom d’utilisateur ». Veillez à passer en revue et à mettre à jour toutes les chaînes de connexion affectées après la mise à niveau pour éviter les problèmes de connexion.

Q. La migration automatique prend-elle en charge la migration des rôles Microsoft Entra authentifiés ?

A. Oui, la migration automatique prend en charge la migration des rôles authentifiés Microsoft Entra. Une fois que votre serveur est automatiquement ajouté à un serveur flexible, vous devez utiliser le format entraid@servername comme nom d’utilisateur lors de la connexion avec votre ID Entra. Le format entraid plus simple n’est actuellement pas pris en charge.

Exemple :

Si votre ID Entra est abc@xyz.com et que le nom de votre serveur est server1, le nom d’utilisateur pour la connexion au serveur flexible automatiquement ajouté est abc@xyz.com@server1. Toute tentative de connexion à l’aide du nom abc@xyz.com d’utilisateur ne fonctionnera pas.

Il s’agit d’un problème connu et Microsoft travaille activement à l’aborder dans les futures mises à jour.

Contenu connexe