Qu’advient-il de Azure Database pour PostgreSQL - Serveur unique après l’annonce de la mise hors service ?
S’APPLIQUE À :
Azure Database pour PostgreSQL – Serveur unique
Azure Database pour PostgreSQL - Serveur unique est en voie d’être mis hors service avec une mise hors service prévue d’ici le 28 mars 2025.
Azure Database pour PostgreSQL : le serveur unique est généralement devenu disponible en 2018. É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 de Serveur unique doit être mise hors service et remplacée par une nouvelle architecture. La nouvelle génération du service, Azure Database pour PostgreSQL - Serveur flexible, vous offre le meilleur de la plateforme de base de données open source Azure.
Dans le cadre de cette mise hors service, nous ne prenons plus en charge la création de nouvelles instances du serveur unique depuis le portail Azure à compter du 30 novembre 2023. Si vous devez créer des instances de serveur unique pour répondre à des besoins de continuité d’activité, vous pouvez utiliser Azure CLI et le modèle ARM. Toutefois, à compter de mars 2025, ces méthodes ne seront plus utilisées.
Si vous disposez actuellement d’un service de serveur unique Azure Database pour PostgreSQL hébergeant des serveurs de production, nous sommes heureux de vous informer que vous pouvez migrer votre Serveur unique Azure Database pour PostgreSQL vers un Serveur flexible Azure Database pour PostgreSQL.
Le Serveur flexible Azure Database pour PostgreSQL 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 Azure Database pour PostgreSQL, consultez Azure Database pour PostgreSQL - Serveur flexible.
Migrer d’un Serveur unique Azure Database pour PostgreSQL vers un Serveur flexible Azure Database pour PostgreSQL
Découvrez comment migrer d’un Serveur unique Azure Database pour PostgreSQL vers un Serveur flexible Azure Database pour PostgreSQL à l’aide de l’outil de migration d’un Serveur unique vers un Serveur flexible.
Forum Aux Questions (FAQ)
Q. Pourquoi le Serveur unique Azure Database pour PostgreSQL est-il mis hors service ?
R. Azure Database pour PostgreSQL : le serveur unique est généralement devenu disponible en 2018. É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 de Serveur unique doit être mise hors service et remplacée par une nouvelle architecture. La nouvelle génération du service, Azure Database pour PostgreSQL - Serveur flexible, vous offre le meilleur de la plateforme de base de données open source Azure.
Q. Pourquoi suis-je invité à migrer vers le Serveur flexible Azure Database pour PostgreSQL ?
A.Le Serveur flexible Azure Database pour PostgreSQL est la plateforme idéale pour exécuter toutes vos charges de travail open source PostgreSQL sur Azure. Le Serveur flexible Azure Database pour PostgreSQL est économique et offre de meilleures performances dans tous les niveaux de service et plus de possibilités de contrôler vos coûts grâce à une récupération d’urgence moins coûteuse et plus rapide. Voici d’autres améliorations apportées au serveur flexible :
- Prise en charge de Postgres version 11 et ultérieure, ainsi que des améliorations de sécurité intégrées
- Meilleures performances de prix avec prise en charge des options de calcul de niveau burstable.
- Amélioration de la durée de fonctionnement en configurant la veille à chaud sur la même zone de disponibilité ou sur une autre zone de disponibilité et des fenêtres de maintenance contrôlées par l’utilisateur.
- Expérience de développement simplifiée pour les charges de travail de données hautes performances.
Q. Quand dois-je migrer mon Serveur unique vers un Serveur flexible ?
R. La mise hors service du Serveur unique Azure Database pour PostgreSQL est prévue d’ici le 28 mars 2025. Nous vous recommandons donc vivement de migrer votre Serveur unique vers un Serveur flexible dès que possible pour être sûr de disposer de suffisamment de temps pour exécuter tout le cycle de vie de la migration et de bénéficier des avantages offerts par le Serveur flexible.
Q. Qu’advient-il de mes instances de Serveur unique Azure Database pour PostgreSQL existantes ?
R. Les charges de travail existantes sur votre Serveur unique Azure Database pour PostgreSQL restent prises en charge jusqu’en mars 2025.
Q. Puis-je toujours créer une instance de Serveur unique Azure Database pour PostgreSQL version 11 après l’EOL de la communauté en novembre 2023 ?
A. À compter du 30 novembre 2023, vous ne pourrez plus créer d’instances de serveur unique pour PostgreSQL version 11 via le portail Azure. Toutefois, vous pouvez toujours les créer via l’interface CLI jusqu’en novembre 2024. Nous continuerons à prendre en charge les serveurs uniques par le biais de notre stratégie de prise en charge du contrôle de version. Il est préférable de commencer immédiatement la migration vers le Serveur flexible Azure Database pour PostgreSQL.
Q. Puis-je continuer à exécuter mon Serveur unique Azure Database pour PostgreSQL au-delà de la date de fin du 28 mars 2025 ?
R. Nous prévoyons de prendre en charge le Serveur unique jusqu’à la date de fin au 28 mars 2025 et vous conseillons vivement de commencer à planifier votre migration dès que possible. Nous prévoyons de mettre fin à la prise en charge des déploiements de serveur unique à la date de fin du 28 mars 2025.
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 ?
R. Nous n’arrêtons pas immédiatement la capacité à créer de nouveaux serveurs uniques. Vous pouvez donc continuer à créer des serveurs uniques via l’interface CLI pour répondre aux besoins de votre entreprise pour toutes les versions de PostgreSQL prises en charge sur le Azure Database pour PostgreSQL – Serveur unique. Nous vous encourageons vivement à étudier le Serveur flexible et voir s’il répond à vos besoins. N’hésitez pas à nous contacter le cas échéant afin que nous puissions vous guider et vous suggérer la meilleure voie à suivre.
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étermineront les coûts supplémentaires encourus (pour plus d’informations, consultez Tarification). Une fois que vous avez désactivé le serveur unique source une fois la migration réussie, vous payez uniquement pour votre serveur flexible. L’utilisation de l’outil de migration du Serveur unique vers le Serveur flexible n’entraînera pas de coûts supplémentaires. Si vous avez des questions ou des préoccupations concernant le coût de la migration de votre serveur unique vers un serveur flexible, contactez votre représentant de compte Microsoft.
Q. Ma facturation sera-t-elle affectée par l’exécution de Azure Database pour PostgreSQL - Serveur flexible au lieu de Azure Database pour PostgreSQL - Serveur unique ?
R. La facturation doit être comparable si vous choisissez une configuration similaire à votre Azure Database pour PostgreSQL - Serveur unique. Toutefois, si vous sélectionnez la même zone ou une haute disponibilité redondante interzone pour votre serveur flexible cible, votre facture sera plus élevée que celle de votre serveur unique. La même zone ou haute disponibilité redondante interzone nécessite qu’un serveur de secours supplémentaire soit lancé et stocke des données de sauvegarde redondantes, d’où le coût supplémentaire pour le deuxième serveur. Cette architecture permet de réduire les temps d’arrêt pendant les interruptions non planifiées et la maintenance planifiée. En règle générale, le Serveur flexible offre de meilleures performances tarifaires, toutefois, cela dépend de votre charge de travail.
Q. Est-ce que je vais subir un temps d’arrêt lors de la migration du Serveur unique Azure Database pour PostgreSQL vers le Serveur flexible ?
R. Actuellement, l’outil de migration du Serveur unique vers le Serveur flexible prend uniquement en charge les migrations hors connexion. La migration hors connexion nécessite un temps d’arrêt pour vos applications pendant le processus de migration. Pour plus d’informations, consultez Outil de migration – Serveur unique vers serveur flexible Azure Database pour PostgreSQL.
Le temps d’arrêt nécessaire dépend de plusieurs facteurs, notamment du nombre de bases de données, de la taille des bases de données, du nombre de tables à l’intérieur de chaque base de données, du nombre d’index et de la répartition des données entre les tables. Il dépend également de la référence SKU du serveur source et du serveur cible ainsi que des IOPS disponibles sur le serveur source et le serveur cible.
Compte tenu des nombreux facteurs impliqués dans une migration, la meilleure approche pour estimer le temps d’arrêt de votre application consiste à essayer la migration sur un serveur PITR restauré à partir du serveur principal pour planifier votre migration de production.
Les migrations hors connexion sont moins complexes, avec peu de risques d’échec, et sont la méthode recommandée pour effectuer des migrations d’un serveur unique vers un serveur flexible pour les charges de travail avec des fenêtres de service.
Vous pouvez contacter les équipes de votre compte si les conditions de temps d’arrêt ne sont pas satisfaites par les migrations hors connexion fournies par un outil de migration d’un serveur unique vers un serveur flexible.
Notes
La prise en charge de la migration en ligne sera disponible prochainement.
Q. Y aura-t-il de futures mises à jour du Serveur unique pour prendre en charge les dernières versions de PostgreSQL ?
R. Nous vous recommandons de migrer vers un Serveur flexible si vous devez fonctionner sur les dernières versions du moteur PostgreSQL. Nous continuons à déployer des versions mineures publiées par la communauté pour Postgres version 11 jusqu’à sa mise hors service en novembre 2023.
Notes
Nous étendons la prise en charge de Postgres version 11 après la date de mise hors service de la communauté et nous prendrons en charge PostgreSQL version 11 sur Serveur unique et Serveur flexible pour faciliter cette transition. Envisagez de migrer vers le Serveur flexible pour tirer parti des avantages des dernières versions du moteur Postgres.
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 offre une disponibilité de 99,99 % avec une résilience au niveau de la zone, tandis que le Serveur unique offre une disponibilité de 99,99 % mais sans résilience de zone. L’architecture de haute disponibilité (HA) du Serveur flexible déploie un serveur de secours avec un calcul et un stockage redondants (les données de chaque site étant stockées en 3 exemplaires). L’architecture de haute disponibilité (HA) du Serveur unique n’offre pas de serveur de secours passif permettant la récupération après des défaillances zonales. L’architecture de haute disponibilité (HA) du Serveur flexible réduit les temps d’arrêt lors d’interruptions non prévues et de maintenance planifiée.
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. Nous sommes proches de la parité régionale avec le Serveur unique. Ce sont des régions sans présence de Serveur flexible.
- Chine Est (CE et CE2),
- Chine Nord (CN et CN2)
- Inde Ouest
- Suède Nord
Nous vous recommandons de migrer vers les régions CN3/CE3, Inde Centre, Suède Centre et Suède Sud. Q. Je dispose d’une liaison privée configurée pour mon serveur unique et cette fonctionnalité n’est actuellement pas prise en charge par le Serveur flexible. Comment effectuer la migration ?
R. La prise en charge de la liaison privée par le Serveur flexible est la principale priorité de notre feuille de route. Le lancement de cette fonctionnalité est prévu au 4ème trimestre 2023. Une autre option consiste à envisager de migrer vers un serveur flexible injecté de réseau virtuel.
Q. Existe-t-il une option pour restaurer un Serveur unique d’une migration vers un Serveur flexible ?
R. Vous pouvez effectuer n’importe quel nombre de migrations de test, tester la réussite de votre migration et effectuer la migration finale une fois que vous êtes prêt. Les migrations de test n’affectent pas la source de serveur unique, qui reste opérationnelle jusqu’à ce que vous effectuiez la migration. 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. Une fois que vous avez effectué une migration finale vers un serveur flexible et que vous l’avez ouvert pour la charge de travail de production, vous perdez la possibilité de revenir à un serveur unique sans entraîner de perte de données.
Q. Comment migrer ma base de données (> 1 To)
A.L’outil de migration d’un Serveur unique vers un Serveur flexible peut migrer les bases de données de toutes tailles d’un Serveur unique vers un Serveur flexible. La nouvelle version de l’outil n’a aucune restriction concernant la taille des bases de données.
Q. La migration inter-régions est-elle prise en charge ?
R. Actuellement, l’outil de migration d’un Serveur unique vers un Serveur flexible ne prend pas en charge les migrations entre régions. Elles le seront ultérieurement. Vous pouvez utiliser le pg_dump/pg_restore pour effectuer des migrations entre régions.
Les migrations de données entre régions doivent être évitées, car la migration prend beaucoup de temps. Une façon plus simple de procéder consiste à démarrer une réplica en lecture dans la géorégion cible, à basculer votre application et à suivre les étapes décrites précédemment.
Q. La migration entre abonnements est-elle prise en charge ?
R. L’outil de migration d’un Serveur unique vers un Serveur flexible prend en charge les migrations entre abonnements.
Q. L’abonnement inter-ressources est-il pris en charge ?
R. L’outil de migration d’un Serveur unique vers un Serveur flexible prend en charge les migrations inter-ressources.
Q. Existe-t-il une prise en charge inter-versions ?
R. Le service de migration d’un Serveur unique vers un Serveur flexible prend en charge la migration d’une version PostgreSQL inférieure (PG 9.5 et ultérieure) vers toute version supérieure. Comme toujours, la compatibilité des applications avec les versions de PostgreSQL supérieures doit être vérifiée au préalable.
Outil de migration d’un Serveur unique vers un Serveur flexible
L’outil de migration d’un Serveur unique vers un Serveur flexible est un outil puissant qui vous permet de migrer facilement votre base de données SQL Server d’un serveur unique vers un serveur flexible. Avec cet outil, vous pouvez facilement déplacer votre base de données d’un serveur local ou d’une machine virtuelle vers un serveur flexible dans le cloud, ce qui vous permet de tirer parti de la scalabilité et de la flexibilité du cloud computing.
Q. Quels composants de données, de schéma et de métadonnées sont migrés dans le cadre de la migration ?
R. L’outil de migration d’un Serveur unique vers un Serveur flexible migre le schéma, les données et les métadonnées depuis la source vers la destination. Tous les composants de données, de schéma et de métadonnées suivants sont migrés dans le cadre de la migration de base de données :
Migration de données
- Toutes les tables de toutes les bases de données/schémas.
Migration de schéma :
- Dénomination
- Clé primaire
- Type de données
- Position ordinale
- Valeur par défaut
- Possibilité de valeurs nulles
- Attributs d’auto-incrément
- Index secondaires
Migration de métadonnées :
- Procédures stockées
- Fonctions
- Déclencheurs
- Vues
- Contraintes de clés étrangères
Q. Quelle est la différence entre la migration hors connexion et la migration en ligne ?
R. L’outil de migration d’un Serveur unique vers un Serveur flexible prend désormais en charge la migration hors connexion. Les migrations en ligne seront disponibles prochainement. Dans le cas d’une migration hors connexion, le temps d’arrêt de l’application commence quand la migration commence. Dans le cas d’une migration en ligne, le temps d’arrêt est limité à la durée du basculement à la fin de la migration mais utilise un mécanisme de réplication logique. Vos données/schémas doivent passer ces restrictions de moteur PG open source pour la migration en ligne. Nous vous recommandons de tester une migration hors connexion pour déterminer si le temps d’arrêt est acceptable.
Les migrations en ligne et hors connexion sont comparées dans le tableau suivant :
| Domaine | Migration en ligne | Migration hors connexion |
|---|---|---|
| Disponibilité de la base de données pour les lectures pendant la migration | Disponible | Disponible |
| Disponibilité de la base de données pour les écritures pendant la migration | Disponible | Cela n’est généralement pas recommandé. Toutes les « écritures » lancées après la migration ne sont pas capturées ou migrées |
| Convenance des applications | Applications qui ont besoin d’une durée maximale d’activité | Applications qui peuvent se permettre une fenêtre de temps d’arrêt planifié ou ont des restrictions de schéma/de charge de travail qui interdisent la migration en ligne |
| Adéquation aux charges de travail lourdes en écriture | Approprié, mais risque de réduire la charge de travail lors de la migration | Il s’agit d’une solution recommandée uniquement si vous pouvez désactiver les écritures pendant la migration. Les écritures au niveau de la source ne sont pas migrées vers le serveur cible après le début de la migration |
| Basculement manuel | Obligatoire | Non requis |
| Temps d’arrêt nécessaire | Petite et fixe quelle que soit la taille des données | Proportionnelle à la taille des données et à d’autres facteurs. Il peut s’agir de quelques minutes pour les bases de données plus petites et de quelques heures pour les bases de données plus volumineuses |
| Heure de migration | Dépend de la taille de la base de données et de l’activité d’écriture jusqu’au basculement | Dépend de la taille de la base de données |
Q. Existe-t-il des recommandations d’optimisation des performances de l’outil de migration d’un Serveur unique vers un Serveur flexible ?
R. Oui. Pour effectuer des migrations plus rapides, choisissez une référence SKU supérieure pour votre serveur flexible. Choisissez au minimum une référence SKU 4VCore ou supérieure pour effectuer rapidement la migration. Vous pouvez toujours changer de référence SKU en fonction des besoins de l’application après la migration.
Q. Combien de temps prend l’exécution d’une migration hors connexion avec l’outil de migration d’un Serveur unique vers un Serveur flexible ?
R. Le tableau suivant indique le temps nécessaire pour effectuer des migrations hors connexion de bases de données de diverses tailles à l’aide de l’outil de migration d’un Serveur unique vers un Serveur flexible. La migration a été effectuée à l’aide d’un serveur flexible avec la référence SKU :
Standard_D4ds_v4 (4 cœurs, 16 Go de mémoire, 128 Go de disque et 500 IOPS)
| Taille de la base de données | Temps (HH:mm) |
|---|---|
| 1 Go | 00:01 |
| 5 Go | 00:03 |
| 10 Go | 00:08 |
| 50 Go | 00:35 |
| 100 Go | 01:00 |
| 500 Go | 04:00 |
| 1 000 Go | 07:00 |
Notes
Les chiffres ci-dessus vous donnent une idée approximative du temps nécessaire pour mener à bien la migration. Pour avoir une idée précise du temps que va prendre la migration de votre serveur, nous vous recommandons vivement de prendre une restauration à un instant dans le passé (PITR) de votre serveur unique et de l’exécuter avec l’outil de migration d’un Serveur unique vers un Serveur flexible.
Q. Combien de temps prend l’exécution d’une migration en ligne avec l’outil de migration d’un Serveur unique vers un Serveur flexible ?
R. La migration en ligne implique les étapes suivantes :
- Copie initiale des bases de données
- Capture de données modifiées : relecture de toutes les transactions sur la source pendant l’étape #1 vers la cible.
Le temps nécessaire à l’étape #1 est le même que pour les migrations hors connexion (reportez-vous à la question précédente).
Le temps nécessaire à l’étape #2 dépend des transactions qui se produisent sur la source. S’il s’agit d’une charge de travail gourmande en écriture, le temps nécessaire à l’étape #2 sera plus long.
Support supplémentaire
Q. J’ai d’autres questions sur la mise hors service.
R. Vous pouvez obtenir de plus amples informations de plusieurs manières différentes.
Obtenez des réponses des experts de la communauté dans Microsoft Q&A.
Vous pouvez contacter l’équipe produit Azure Database pour PostgreSQL.
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 PostgreSQL.
- Pour Ressource, sélectionnez votre ressource.
- Pour Type de problème, sélectionnez Migration vers Azure DB pour PostgreSQL.
- Pour Sous-type de problème, sélectionnez Problèmes de migration d’un serveur unique vers un serveur flexible.
Avertissement
Cet article n’est pas destiné aux utilisateurs du service Serveur flexible Azure Database pour PostgreSQL. Il s’adresse aux clients d’un serveur unique Azure Database pour PostgreSQL qui doivent effectuer une mise à niveau vers un Serveur flexible Azure Database pour PostgreSQL.
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.