Migration automatique d’un serveur unique Azure Database pour PostgreSQL vers un serveur flexible
S’APPLIQUE À : 
Azure Database pour PostgreSQL : serveur unique
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 revoir et ajuster le calendrier de migration si nécessaire ou soumettre une demande d'assistance pour refuser la migration automatique pour vos serveurs.
La migration automatique tire parti du 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 variera en fonction des caractéristiques de la charge de travail, les charges de travail les plus importantes pouvant nécessiter jusqu'à 20 minutes. Pour connaître les benchmarks de vitesse de migration, consultez Évaluation de la vitesse de migration d’Azure PostgreSQL. Cette migration élimine la nécessité d'une migration manuelle du serveur, ce qui vous permet de bénéficier des fonctionnalités de serveur flexible après la migration, notamment un meilleur rapport prix/performance, un contrôle granulaire de la configuration de la base de données et des fenêtres de maintenance personnalisées.
Remarque
Le service de migration automatique sélectionne un serveur unique à migrer en fonction des critères suivants :
- Version 11 du serveur unique
- Serveurs sans fonctionnalité complexe tels que CMK, Microsoft Entra ID, Replica en lecture et point de terminaison privé
- Taille des données <= 10 Go
- L’accès public est activé
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 correspondre aux performances et au coût de votre référence SKU 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 Single Server source est configuré en lecture seule et toutes les données, schémas, rôles d'utilisateur, privilèges et propriété des objets de la base de données sont migrés vers le serveur flexible.
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 du serveur unique et du serveur 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 Microsoft 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 Microsoft 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.
Nommer des serveurs uniques pour la migration automatique
Le processus de nomination est destiné aux utilisateurs qui souhaitent effectuer librement le suivi rapide de 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.
Comment vérifier si votre serveur unique est programmé pour une migration automatique
Pour déterminer si votre Single Server est sélectionné pour la migration automatique, procédez comme suit :
- Notifications Intégrité des services : dans le Portail Microsoft Azure, accédez aux événements Intégrité des services > Maintenance planifiée. 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, 14 et 7 jours avant la date de migration, et à 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
Par défaut, ces notifications n'arrivent pas dans votre boîte de réception. Pour les recevoir par e-mail ou SMS, vous devez configurer les Azure Service Health en suivant les étapes ci-dessous
- Page Vue d’ensemble du serveur unique : accédez à votre instance de serveur unique dans le Portail Microsoft Azure et consultez la page Vue d’ensemble. Si la migration automatique est programmée, vous en trouverez les détails ici, y compris la possibilité de reporter la migration d'un mois à la fois ou de la reprogrammer dans le mois en cours.
Remarque
La planification de la migration est verrouillée 7 jours avant la fenêtre de migration planifiée, après quoi vous ne pourrez 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 les migrations automatiques à venir.
Vérifications préalables pour la migration automatique
Vérifiez 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 afin que la migration automatique se produise.
- Pour l’instance de serveur unique avec SSL activé, vérifiez que tous les certificats (autorité racine DigiCertGlobalRootG2 et autorité racine DigiCertGlobalRootCA) 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.
- Si votre serveur unique source Azure Database pour PostgreSQL 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 du 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.)
Comment le serveur flexible PostgreSQL cible est-il approvisionné ?
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, comme affiché ci-dessous.
| Niveau tarifaire du serveur unique | VCores du serveur unique | Niveau du serveur flexible | Nom SKU du serveur flexible |
|---|---|---|---|
| De base | 1 | Expansible | B1ms |
| De base | 2 | Expansible | B2s |
| Usage général | 2 | GeneralPurpose | Standard_D2s_v3 |
| Usage général | 4 | GeneralPurpose | Standard_D4s_v3 |
| Usage général | 8 | GeneralPurpose | Standard_D8s_v3 |
| Usage général | 16 | GeneralPurpose | Standard_D16s_v3 |
| Usage général | 32 | GeneralPurpose | Standard_D32s_v3 |
| Usage général | 64 | GeneralPurpose | 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 PostgreSQL, 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 avec une exigence de stockage supérieure, le stockage nécessaire qui est alloué équivaut à 1,25 fois plus ou 25 % de plus que le stockage utilisé dans le serveur unique. Pendant la copie de base initiale 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). Jusqu’à ce que ces fichiers WAL soient archivés, les journaux consomment du stockage sur la cible, d’où la nécessité d’une marge de sécurité.
- 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é.
Étapes post-migration
Voici les informations dont vous avez besoin pour connaître suite à la migration automatique :
- Les paramètres de serveur dans le serveur flexible sont paramétrés par rapport aux normes de la communauté. Si vous souhaitez conserver les mêmes valeurs de paramètre 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.
- Pour activer une requête des insights de performance, vous devez activer le magasin de requêtes sur le serveur flexible qui n’est pas activé par défaut
- Si une haute disponibilité est nécessaire, vous pouvez l’activer sans temps d’arrêt.
Gestion des règles VNet dans le serveur flexible
Dans Azure Database pour PostgreSQL – Serveur unique, une règle de réseau virtuel (VNet) est un sous-réseau figurant dans la liste de contrôle d’accès (ACL) du serveur. Cette règle permet au serveur unique d’accepter la communication provenant de nœuds au sein de ce sous-réseau 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 en sécurité via le réseau principal Azure, ce qui élimine la nécessité d’une exposition à 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 en utilisant le Portail Microsoft Azure ou Azure CLI. Une fois cette étape terminée, votre connectivité réseau reste intacte sur le serveur flexible après la migration depuis un 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 le serveur flexible Azure Database for PostgreSQL avec une conservation à long terme à l'aide d'Azure Backup.
Forum Aux Questions (FAQ)
Q. Pourquoi je fais l’objet d’une migration automatique ?
A. Votre instance de serveur unique Azure Database pour PostgreSQL est éligible pour la migration automatique vers notre offre phare de serveur flexible Azure Database pour PostgreSQL. Cette migration automatique supprime la charge d’une migration manuelle de votre serveur. Vous pouvez bénéficier des avantages du serveur flexible, notamment de meilleures performances à un meilleur prix, un contrôle précis sur la configuration de la base de données et des fenêtres de maintenance personnalisées.
Q : Comment se déroule la migration automatique ? Quels sont les éléments qu’il migre ?
A. Le serveur flexible est configuré pour correspondre aux mêmes vCores et stockage que celui 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 lorsque vous voyez des temps d’arrêt allant jusqu’à 20 minutes.
Q : Comment puis-je configurer ou afficher des alertes de migration automatique ?
A. Voici les façons dont vous pouvez configurer des alertes :
- Configurez des alertes d’intégrité des services pour recevoir des notifications de la planification et la progression de la migration automatique par e-mail/SMS en suivant les étapes ici.
- Vérifiez la notification de migration automatique sur le Portail Azure en suivant les étapes ici.
Q : Comment différer la migration planifiée de mon serveur unique ?
A. Vous pouvez vérifier la planification de la migration en accédant à la page de Présentation de votre instance de serveur unique. Si vous souhaitez différer la migration, vous pouvez différer d’un mois au maximum en accédant à la page Présentation de votre instance de serveur unique sur le portail Azure. Vous pouvez replanifier la migration en sélectionnant une autre fenêtre de migration dans un délai d’un mois. Les détails de la migration sont verrouillés sept jours avant la fenêtre de migration planifiée, après quoi vous ne pourrez pas replanifier. Cette migration automatique peut être différée mensuellement jusqu’au 30 mars 2025.
Q : Comment désactiver une migration automatique planifiée de mon serveur unique ?
A. Si vous souhaitez refuser la 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 VNet ?
R : Les règles VNet ne sont pas prises en charge sur le serveur flexible. Veuillez vous référer à cette section
Q : Dois-je reconfigurer les sauvegardes de rétention à long terme sur un serveur flexible ?
R : Oui. Veuillez vous référer à cette section
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 : Verrai-je une différence de prix sur le déplacement potentiel du serveur unique de base PostgreSQL vers le serveur flexible sur le PostgreSQL ??
A. Un petit nombre de serveurs seulement peuvent 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, veuillez vous référer à ce document