Mise à l’échelle des ressources dans le serveur flexible Azure Database pour PostgreSQL
S’APPLIQUE À : 
Azure Database pour PostgreSQL - Serveur flexible
Le serveur flexible Azure Database pour PostgreSQL prend en charge les options de mise à l’échelle verticales et horizontales.
Mise à l’échelle verticale : vous pouvez effectuer une mise à l’échelle verticale en ajoutant davantage de ressources à l’instance de serveur flexible Azure Database pour PostgreSQL, par exemple en augmentant le nombre de processeurs et de mémoires attribués par l’instance. Le débit réseau de votre instance dépend des valeurs que vous choisissez pour le processeur et la mémoire.
Une fois qu’une instance de serveur flexible Azure Database pour PostgreSQL est créée, vous pouvez modifier indépendamment les éléments suivants :
- Processeur (vCores)
- Volume de stockage
- Période de rétention des sauvegardes
Le nombre de vCores peut être mis à l’échelle vers le haut ou vers le bas, mais la taille de stockage peut uniquement être augmentée. Vous pouvez aussi augmenter ou diminuer la période de rétention de sauvegarde de 7 à 35 jours. Les ressources peuvent être mises à l’échelle à l’aide de plusieurs outils, par exemple, le portail Microsoft Azure ou l’interface de ligne de commande Azure.
Remarque
Une fois que vous avez augmenté la taille du stockage, vous ne pouvez pas revenir à une taille de stockage plus petite.
mise à l’échelle horizontale : vous pouvez effectuer une mise à l’échelle horizontale en créant des réplicas en lecture. Les réplicas en lecture vous permettent de mettre à l’échelle vos charges de travail de lecture sur des instances de serveur flexible Azure Database pour PostgreSQL distinctes. Ils n’affectent pas les performances et la disponibilité de l’instance principale.
Lorsque vous modifiez le nombre de vCores ou le niveau de calcul, l’instance redémarre pour que le nouveau type de serveur prenne effet. Pendant ce temps, le système bascule vers le nouveau type de serveur. Aucune nouvelle connexion ne peut être établie et toutes les transactions non validées sont restaurées.
Le temps total nécessaire au redémarrage de votre serveur dépend du processus de récupération après l’incident et de l’activité de la base de données au moment du redémarrage. Le redémarrage prend généralement une minute ou moins, mais il peut s’agir de plusieurs minutes. Le minutage dépend de l’activité transactionnelle lorsque le redémarrage a été lancé.
Si votre application est sensible à la perte de transactions en cours d’exécution qui peuvent se produire pendant la mise à l’échelle du calcul, nous vous recommandons d’implémenter une transaction modèle de nouvelle tentative.
La mise à l’échelle du stockage ne nécessite pas de redémarrage du serveur dans la plupart des cas. Pour plus d’informations, reportez-vous à options de stockage dans Azure Database pour PostgreSQL - Serveur flexible De même, les modifications de la période de rétention des sauvegardes sont une opération en ligne. Pour améliorer le temps de redémarrage, nous vous recommandons d’effectuer les opérations de mise à l’échelle pendant les heures creuses. Cette approche réduit le temps nécessaire au redémarrage du serveur de base de données.
Mise à l’échelle de temps d’arrêt quasi nul
La mise à l’échelle de temps d’arrêt quasi nul est une fonctionnalité conçue pour réduire les temps d’arrêt lorsque vous modifiez des niveaux de stockage et de calcul. Si vous modifiez le nombre de cœurs virtuels ou le niveau de calcul, le serveur subit un redémarrage pour appliquer la nouvelle configuration. Aucune nouvelle connexion ne peut être établie pendant cette transition vers le nouveau serveur.
En règle générale, ce processus peut durer de 2 à 10 minutes avec mise à l'échelle régulière. Avec la nouvelle fonctionnalité de mise à l’échelle de temps d’arrêt quasi nul, cette durée est réduite à moins de 30 secondes. Cette réduction du temps d’arrêt pendant la mise à l’échelle des ressources améliore la disponibilité globale de votre instance de base de données.
Fonctionnement
Lorsque vous mettez à jour votre instance de serveur flexible Azure Database pour PostgreSQL dans des scénarios de mise à l’échelle, nous créons une nouvelle copie de votre serveur (VM) avec la configuration mise à jour. Nous la synchronisons avec votre version actuelle et basculons vers la nouvelle copie avec une interruption de 30 secondes. Ensuite, nous mettons hors service l’ancien serveur. Le processus se produit sans frais supplémentaires pour vous.
Ce processus permet des mises à jour transparentes tout en réduisant les temps d’arrêt et en garantissant l’efficacité des coûts. Ce processus de mise à l’échelle est déclenché lorsque des modifications sont apportées aux niveaux de stockage et de calcul. Aucune action du client n’est requise pour mettre à l’échelle la base de données.
Pour les serveurs configurés en réplica en lecture, les opérations de mise à l'échelle doivent suivre une séquence spécifique afin de garantir la cohérence des données et de minimiser les temps d'arrêt. Pour plus d’informations sur cette séquence, reportez-vous à la mise à l’échelle avec des réplicas en lecture.
Remarque
Le processus de mise à l’échelle de temps d’arrêt quasi nul est l’opération par défaut. Lorsque les limitations suivantes sont rencontrées, le système passe à une mise à l’échelle ordinaire, ce qui implique des temps d’arrêt plus longs par rapport à la mise à l’échelle de temps d’arrêt quasi nul.
Attentes précises en matière de temps d’arrêt
- Durée du temps d’arrêt : dans la plupart des cas, le temps d’arrêt varie de 10 à 30 secondes.
- Autres considérations : Après un événement de mise à l’échelle, il existe une période
Time-To-Live(TTL) DNS inhérente d’environ 30 secondes. Cette période n’est pas directement contrôlée par le processus de mise à l’échelle. Il s’agit d’une partie standard du comportement DNS. Ainsi, du point de vue d’un client, le temps d’arrêt total rencontré pendant la mise à l'échelle peut être compris entre 40 et 60 secondes.
Observations et limitations
- Pour que la mise à l’échelle des temps d’arrêt quasi nul fonctionne, activez toutes les connexions entrantes/sortantes entre les adresses IP du sous-réseau délégué lorsque vous utilisez la mise en réseau intégrée au réseau virtuel. Si ces connexions ne sont pas activées, le processus de mise à l’échelle quasi nul ne fonctionne pas et la mise à l’échelle se produit via le flux de travail de mise à l’échelle standard.
- La mise à l’échelle de temps d’arrêt quasi nul ne fonctionne pas si des contraintes de capacité régionales ou des limites de quota sont imposées aux abonnements clients.
- La mise à l’échelle d’un temps d’arrêt quasi nul ne fonctionne pas pour un serveur réplica, car elle n’est prise en charge que sur le serveur principal. Un serveur réplica passe automatiquement par le processus de mise à l’échelle ordinaire.
- La mise à l’échelle d’un temps d’arrêt quasi nul ne fonctionne pas si un serveur injecté de réseau virtuel avec un sous-réseau délégué n’a pas suffisamment d’adresses IP utilisables. Si vous disposez d’un serveur autonome, une adresse IP supplémentaire est nécessaire. Pour un serveur à haute disponibilité, deux adresses IP supplémentaires sont requises.
- Les emplacements de réplication logique ne sont pas conservés lors d’un événement de basculement de temps d’arrêt quasi nul. Pour maintenir les emplacements de réplication logique et garantir la cohérence des données après une opération de mise à l'échelle, utilisez l’extension pg_failover_slot. Pour plus d’informations, consultez Activation de l’extension dans un serveur flexible.
- La mise à l’échelle à temps d’arrêt quasi-nul ne fonctionne pas avec les tables non journalisées. Les clients qui utilisent des tables non journalisées pour l’une de leurs données perdent toutes les données de ces tables après la mise à l’échelle à temps d’arrêt quasi-nul.