Mise à l’échelle de ressources dans Azure Database pour PostgreSQL – Serveur flexible

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

Azure Database pour PostgreSQL – Serveur flexible prend en charge les options de mise à l’échelle verticales et horizontales.

Mise à l’échelle verticale

Vous pouvez mettre à l’échelle votre instance de manière verticale en ajoutant d’autres ressources à votre instance de serveur flexible Azure Database pour PostgreSQL. Vous pouvez augmenter ou diminuer le nombre de processeurs et la mémoire qui lui sont attribués.

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 la mise à l’échelle :

• Niveau de calcul et référence SKU.
• Niveau de stockage et taille.
• Période de rétention des sauvegardes

Vous pouvez effectuer un scale-up ou scale-down du niveau de calcul entre Burstable, l’Usage général et à mémoire optimisée pour ajuster les besoins de votre charge de travail. Dans chacun de ces niveaux, il existe une grande sélection de matériels préconfigurés de différentes générations avec plus ou moins de processeurs et de mémoire installée. Au sein de cette vaste gamme, vous pouvez en choisir un qui prend en charge à tout moment les exigences de votre ressource, tout en conservant vos coûts d’exploitation réduits et ajustés à vos besoins.

Vous pouvez effectuer un scale-up ou scale-down de la quantité de cœurs virtuels et de mémoire installés. Le niveau de stockage peut également être configuré à la hausse ou à la baisse pour s’adapter aux exigences de débit et d’IOPS demandés par votre charge de travail. La taille de stockage ne peut être qu’augmentée. En outre, en fonction de vos exigences, vous pouvez augmenter ou diminuer la période de rétention des sauvegardes de 7 à 35 jours.

Ces ressources peuvent être mises à l’échelle en utilisant plusieurs interfaces. Par exemple, vous pouvez utiliser le Portail Azure ou l’interface Azure CLI.

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.

Dans une configuration mise à l’échelle horizontalement, vous pouvez également effectuer une mise à l’échelle horizontale de l’instance primaire et des réplicas en lecture.

Lorsque vous changez le nombre de cœurs virtuels et le niveau de calcul, l’instance redémarre afin que le nouveau matériel attribué commence à exécuter votre charge de travail de serveur. 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.

Dans la plupart des cas, la mise à l'échelle du stockage ne nécessite pas le redémarrage du serveur. Pour découvrir plus d'informations, voir Options de stockage dans Azure Database pour PostgreSQL – Serveur flexible.

Les modifications apportées à la période de rétention des sauvegardes s’effectuent 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 réduit

La mise à l’échelle de temps d’arrêt réduit 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 fonctionnalité de mise à l’échelle de temps d’arrêt réduit, 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, le service crée une machine virtuelle pour votre serveur avec la configuration mise à jour. Elle est ensuite synchronisée avec la machine virtuelle exécutant actuellement votre instance, puis elle passe à la nouvelle avec une courte interruption. Le processus en arrière-plan élimine ensuite l’ancienne machine virtuelle. Tout ce 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 la rentabilité. 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 configurations mises à l’échelle horizontalement, se composant d’un serveur primaire et d’un ou plusieurs réplicas en lecture, les opérations de mise à l’échelle doivent suivre une séquence spécifique pour veiller à une cohérence des données et minimiser les temps d’arrêt. Pour découvrir plus d’informations sur cette séquence, consultez mise à l’échelle avec des réplicas en lecture.

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. Ce processus de mise à l’échelle ne contrôle pas directement cette période. 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 de temps d’arrêt réduit fonctionne, activez toutes les connexions entrantes et 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 autorisées, le processus de mise à l’échelle de temps d’arrêt réduit ne fonctionne pas et la mise à l’échelle se produit via le workflow de mise à l’échelle standard.
• La mise à l’échelle de temps d’arrêt réduit ne fonctionne pas si des contraintes de capacité régionales ou des limites de quota sont imposées sur votre abonnement.
• La mise à l’échelle de temps d’arrêt réduit ne fonctionne pas pour un serveur réplica, car elle n’est prise en charge que sur le serveur primaire. Pour les serveurs réplicas, l’opération de mise à l’échelle passe automatiquement par le processus standard.
• La mise à l’échelle de temps d’arrêt réduit ne fonctionne pas si un serveur injecté de réseau virtuel n’a pas suffisamment d’adresses IP utilisables dans le sous-réseau délégué. Si vous disposez d’un serveur autonome, une adresse IP supplémentaire est nécessaire. Pour une instance avec la haute disponibilité activée, 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 réduit. 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 découvrir plus d’informations, consultez Activation de l’extension dans un serveur flexible.
• La mise à l’échelle de temps d’arrêt réduit ne fonctionne pas avec les tables non journalisées. Si vous utilisez des tables non journalisées pour vos données, vous perdez toutes les données de ces tables après la mise à l’échelle de temps d’arrêt réduit.

Partager vos suggestions et bogues avec l’équipe produit Azure Database pour PostgreSQL.

Partager vos suggestions et bogues avec l’équipe produit Azure Database pour PostgreSQL.

Contenu connexe

• Gérer Azure Database pour PostgreSQL – Serveur flexible