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

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

Mise à l’échelle verticale

Mettez à l’échelle votre serveur verticalement en ajoutant davantage de ressources à votre 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 serveur dépend des valeurs que vous choisissez pour le processeur et la mémoire.

Après avoir créé un serveur flexible pour Azure Database pour PostgreSQL, vous pouvez effectuer une mise à l’échelle indépendante des éléments suivants :

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

Faites évoluer le niveau de calcul à la hausse ou à la baisse entre Burstable, General Purpose et Memory Optimized afin de répondre aux besoins de votre charge de travail. Dans chacun de ces niveaux, choisissez 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. Sélectionnez 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.

Mettez à l’échelle le nombre de vCores et la mémoire installée vers le haut ou vers le bas. 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.

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

Mise à l’échelle horizontale

Les clusters élastiques Azure Database pour PostgreSQL vous permettent de faire évoluer horizontalement votre base de données afin de prendre en charge des charges de travail liées aux données qui dépassent les capacités d’un seul serveur de base de données. Les clusters élastiques offrent également le potentiel d’exécuter des opérations parallèles simultanément 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

Vous pouvez faire évoluer votre serveur horizontalement en créant des répliques de lecture. Les réplicas en lecture vous permettent de mettre à l’échelle vos charges de travail de lecture sur des serveurs flexibles distincts Azure Database pour PostgreSQL. Ils n’affectent pas les performances et la disponibilité du serveur principal.

Dans une architecture à mise à l’échelle horizontale, vous pouvez également augmenter verticalement la capacité du serveur principal et des réplicas de lecture.

Lorsque vous modifiez le nombre de vCores ou le niveau de calcul, le serveur 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. Vous ne pouvez pas établir de nouvelles connexions, et toutes les transactions non validées sont annulé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. Pendant cette transition vers le nouveau serveur, vous ne pouvez pas établir de nouvelles connexions.

En règle générale, ce processus prend de 2 à 10 minutes avec une mise à l’échelle régulière. En utilisant la fonctionnalité de mise à l’échelle des temps d’arrêt quasi-zéro, vous réduisez cette durée à 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 Azure Database pour PostgreSQL serveur flexible dans les 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 serveur, puis bascule vers la nouvelle machine virtuelle avec une brève interruption. Un processus en arrière-plan élimine 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 serveurs flexibles Azure Database pour PostgreSQL avec ou sans haute disponibilité.

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.

Considérations 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 un serveur avec une 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