Mise à l’échelle des ressources dans Azure Database pour PostgreSQL

Une instance de serveur flexible Azure Database pour PostgreSQL prend en charge les options de mise à l’échelle verticale et horizontale.

Mise à l’échelle verticale

Vous pouvez mettre à l’échelle votre instance verticalement en ajoutant davantage de 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.

Après avoir créé une instance de serveur flexible pour Azure Database for PostgreSQL, vous pouvez évoluer indépendamment :

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

Vous pouvez faire varier la puissance de calcul entre les modes Burst, Usage général et Optimisé pour la mémoire afin de l'adapter aux besoins de votre charge de travail. Dans chacun de ces niveaux, vous pouvez choisir parmi une large sélection de matériel préconfiguré de différentes générations avec différents nombres de processeurs et quantités de mémoire installée. Vous pouvez sélectionner l’option qui prend en charge vos besoins en ressources tout en conservant vos coûts opérationnels réduits et ajustés à vos besoins.

Vous pouvez ajuster le nombre de vCores et la mémoire à la hausse ou à la baisse. Vous pouvez également configurer le niveau de stockage vers le haut ou vers le bas pour répondre aux exigences de débit et d’E/S par seconde requises par votre charge de travail. Vous ne pouvez augmenter la taille de stockage que. Selon vos besoins, vous pouvez augmenter ou diminuer la période de rétention de sauvegarde comprise entre 7 et 35 jours.

Vous pouvez mettre à l’échelle ces ressources à l’aide de plusieurs interfaces. Par exemple, vous pouvez utiliser le portail Azure ou Azure CLI.

Remarque

Une fois que vous augmentez la taille du stockage attribuée à votre instance, vous ne pouvez pas la réduire à une taille plus petite.

Mise à l’échelle horizontale

Les clusters élastiques Azure Database pour PostgreSQL vous permettent d’effectuer un scale-out horizontal de votre base de données pour prendre en charge les charges de travail de données qui s’étendent au-delà des fonctionnalités d’une seule instance de base de données. Les clusters élastiques permettent également d’exécuter simultanément des opérations parallèles sur tous les nœuds d’un cluster, ce qui augmente considérablement le débit et déverrouille une latence ultra-faible. Les clusters élastiques offrent deux modèles de partitionnement de table : le partitionnement basé sur les lignes et le partitionnement basé sur le schéma.

Mise à l'échelle des réplicas en lecture

Une autre approche de la mise à l’échelle horizontale de votre instance consiste à créer des répliques 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 ni la disponibilité de l’instance principale.

Dans une configuration à échelle horizontale, vous pouvez également faire évoluer verticalement l'instance principale et les réplicas en lecture.

Lorsque vous modifiez le nombre de vCores ou le niveau de calcul, l’instance redémarre afin que le nouveau matériel affecté commence à exécuter votre charge de travail 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. La durée dépend de l’activité transactionnelle lorsque le redémarrage a été lancé.

Si votre application est sensible à la perte de transactions en cours pouvant survenir lors de la mise à l'échelle des calculs, implémentez un modèle de nouvelle tentative de transaction.

Dans la plupart des cas, la mise à l'échelle du stockage ne nécessite pas le redémarrage du serveur. Pour plus d’informations, consultez les options de stockage dans Azure Database pour PostgreSQL.

Les modifications apportées à la période de rétention des sauvegardes s’effectuent en ligne.

Pour améliorer le temps de redémarrage, effectuez des 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 vCores ou modifiez le niveau de calcul, le serveur redémarre 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 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, le service crée une machine virtuelle pour votre serveur avec la configuration mise à jour. Ensuite, il se synchronise avec la machine virtuelle qui exécute actuellement votre instance, puis bascule vers la nouvelle machine virtuelle avec une brève interruption. Le processus en arrière-plan élimine ensuite l’ancienne machine virtuelle.

Ce processus permet des mises à jour transparentes avec un temps d’arrêt minimal et est automatiquement déclenchée lorsque vous modifiez les niveaux de stockage ou de calcul. Vous n’avez pas besoin d’effectuer d’action pour utiliser cette fonctionnalité. Cette fonctionnalité est prise en charge pour les instances de serveur flexible Azure Database pour PostgreSQL, qu'elles soient en haute disponibilité (HA) ou non HA.

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.

Remarque

La mise à l’échelle de temps d’arrêt quasi nul est le type d’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. 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 quasi nul 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 vous n’autorisez pas ces connexions, le processus de mise à l’échelle des temps d’arrêt 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 sur votre abonnement.
• La mise à l’échelle de 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. 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 quasi nul ne fonctionne pas si un serveur de réseau virtuel injecté 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 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 l’activation de l’extension pg_failover_slots dans une instance dede serveur flexible.
• La mise à l’échelle à temps d’arrêt quasi-nul ne fonctionne pas avec les tables non journalisées. Si vous utilisez des tables non journalisées pour vos données, vous perdrez toutes les données de ces tables après la mise à l'échelle avec un temps d'arrêt quasi nul.
• La valeur proche de zéro ne fonctionne pas si vous faites évoluer la puissance de calcul de votre serveur à partir ou vers une taille de calcul de 1 ou 2 vCores du niveau Burstable.

Contenu connexe

• Gérer Azure Database pour PostgreSQL