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 Serveur flexible est une migration initiée par le service pendant un temps d’arrêt planifié pour un serveur unique exécutant PostgreSQL 11 et des charges de travail de base de données avec la référence SKU Essentiel, à Usage général ou à Mémoire optimisée. Stockage de données utilisé <= 10 Gio et aucune fonctionnalité complexe (CMK, Microsoft Entra ID, Réplica en lecture ou Private Link) n’est activée. Les serveurs éligibles sont identifiés par le service et reçoivent des notifications préalables détaillant les étapes permettant de passer en revue les détails de la migration et d’apporter des modifications si nécessaire.

La migration automatique fournit une expérience de migration hors connexion hautement résiliente et auto-adaptative pendant une fenêtre de migration planifiée, allant jusqu’à20 minutes de temps d’arrêt. Le service de migration est une solution hébergée qui utilise le système binaire appelé pgcopydb et qui fournit un moyen rapide et efficace de copier des bases de données depuis l’instance source PostgreSQL vers la cible. Cette migration supprime la charge d’une migration manuelle de votre serveur. Après la migration, 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 des données et des fenêtres de maintenance personnalisées. Voici les étapes clés détaillées de la migration ci-dessous :

• Le serveur flexible cible est déployé et correspond à la référence SKU de votre serveur unique en termes de performances et de coût,et hérite de toutes les règles de pare-feu du serveur unique source.

• La date est migrée pendant la fenêtre de migration choisie par le service ou par vous-même. Si la fenêtre est choisie par le service, elle est généralement en dehors des heures d’ouverture de la région spécifique dans laquelle le serveur est hébergé. Le serveur unique source est défini en lecture seule, et les données ainsi que le schéma sont migrés du serveur unique source vers le serveur flexible cible. Les rôles d’utilisateur, les privilèges et la propriété de tous les objets de base de données sont également migrés vers le serveur flexible.

• Le changement et le basculement du DNS sont effectués dans la fenêtre de migration planifiée avec un temps d’arrêt minimal, ce qui permet l’utilisation de la même chaîne de connexion après la migration. Les applications clientes se connectent sans interruption au serveur flexible cible sans qu’aucune mise à jour ou changement ne soit pilotés manuellement par l’utilisateur. En plus des deux formats de chaîne de connexion (serveur unique et serveur flexible) pris en charge sur le serveur flexible migré, les deux formats de nom d’utilisateur (username@server_name et nom d’utilisateur) sont également pris en charge sur le serveur flexible migré.

• Le serveur flexible migré est en ligne et peut désormais être géré via le Portail Azure/CLI.

• Les chaînes de connexion mises à jour pour vous connecter à votre ancien serveur unique sont partagées par e-mail si vous avez activé les notifications d’intégrité du service sur le portail Azure. Vous pouvez également trouver les chaînes de connexion dans la page portail serveur unique sous Paramètres>chaînes de connexion. Les chaînes de connexion peuvent être utilisées pour vous connecter au serveur unique si vous souhaitez copier des paramètres sur votre nouveau serveur flexible.

• Le serveur unique d’origine est supprimé sept jours après la migration.

Les filtres précédents sont utilisés pour sélectionner les serveurs à migrer automatiquement. Les serveurs peuvent également être nommés pour la migration automatique par l’utilisateur. Le processus de nomination est plus flexible et tous les filtres ne sont pas applicables.

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.

Configurer des alertes de migration et passer en revue la planification de la migration

Les serveurs éligibles à la migration automatique reçoivent au préalable des notifications d’intégrité Azure envoyées par le service. Les notifications d’intégrité sont envoyées 30 jours, 14 jours et 7 jours avant la date de migration. Les notifications sont également envoyées lorsque la migration est en cours, terminée et 6 jours après la migration, avant la suppression du serveur unique hérité. Vous pouvez vérifier et configurer le portail Azure pour recevoir les notifications de migration automatique par e-mail ou SMS.

Voici les méthodes détaillées pour vérifier et configurer les notifications de migration automatique :

• Les propriétaires d’abonnements pour les serveurs uniques planifiés pour la migration automatique reçoivent une notification par e-mail.
• Configurez des alertes d’intégrité des services pour recevoir des notifications de planification et de progression de la migration automatique par e-mail/SMS en suivant les étapes ici.
• Vérifiez la notification sur le Portail Azure de la migration automatique en suivant les étapes ici.

Voici les méthodes détaillées pour passer en revue votre planification de migration une fois que vous avez reçu la notification de migration automatique :

• La page de vue d’ensemble du serveur unique pour votre instance affiche une bannière de portail contenant des informations sur votre planification de migration.
• Pour les serveurs uniques planifiés pour la migration automatique, la page de Présentation est mise à jour avec les informations pertinentes. 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 à la fois 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.

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.

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

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 : 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, cliquez ici

Contenu connexe

• Gérer un serveur flexible Azure Database pour PostgreSQL à l’aide du portail Azure.