Partage via

Limites dans Azure Database pour PostgreSQL - Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Les sections suivantes décrivent les limites de capacité et les limites fonctionnelles de Azure Database pour PostgreSQL – Serveur flexible. Si vous souhaitez en savoir plus sur les niveaux de ressources (calcul, mémoire, stockage), consultez les articles sur le calcul et le stockage.

Nombre maximal de connexions

Le tableau suivant montre le nombre maximal de connexions par défaut pour chaque niveau tarifaire et configuration vCore. Azure Database pour PostgreSQL – Serveur flexible réserve 15 connexions pour la réplication physique et la surveillance de l’instance d’Azure Database pour PostgreSQL – Serveur flexible. Par conséquent, la valeur des connexions utilisateur maximales répertoriées dans la table est réduite de 15 par rapport au nombre total de connexions maximales.

Nom du produit vCores Taille de la mémoire Nombre maximal de connexions Nombre maximal de connexions utilisateur
Expansible
B1ms 1 2 Gio 50 35
B2s 2 4 Gio 429 414
B2ms 2 8 Gio 859 844
B4ms 4 16 Gio 1 718 1 703
B8ms 8 32 Gio 3 437 3 422
B12ms 12 48 Gio 5 000 4 985
B16ms 16 64 Gio 5 000 4 985
B20ms 20 80 Gio 5 000 4 985
Usage général
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 Gio 859 844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 4 16 Gio 1 718 1 703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32 Gio 3 437 3 422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64 Gio 5 000 4 985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 Go 5 000 4 985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 48 192 Gio 5 000 4 985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 64 256 Gio 5 000 4 985
D96ds_v5 / D96ads_v5 96 384 Gio 5 000 4 985
Mémoire optimisée
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 Gio 1 718 1 703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32 Gio 3 437 3 422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64 Gio 5 000 4 985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 Go 5 000 4 985
E20ds_v4 / E20ds_v5 / E20ads_v5 20 160 Gio 5 000 4 985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 Gio 5 000 4 985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 Gio 5 000 4 985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 64 432 Gio 5 000 4 985
E96ds_v5 / E96ads_v5 96 672 Gio 5 000 4 985

Les emplacements de connexion réservés, actuellement au nombre de 15, sont susceptibles de changer. Nous vous conseillons de vérifier régulièrement le nombre total de connexions réservées sur le serveur. Vous calculez ce nombre en additionnant les valeurs des paramètres de serveur reserved_connections et superuser_reserved_connections. Le nombre maximal de connexions utilisateur disponibles est max_connections – (reserved_connections + superuser_reserved_connections).

La valeur par défaut du paramètre de serveur max_connections est calculée lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom du produit que vous sélectionnez pour son calcul. Toute modification ultérieure de la sélection de produit au calcul qui prend en charge le serveur flexible n’aura aucun effet sur la valeur par défaut pour le paramètre de serveur max_connections de cette instance. Nous vous recommandons que chaque fois que vous modifiez le produit attribué à une instance, vous ajustez également la valeur du paramètre max_connections en fonction des valeurs du tableau précédent.

Modification de la valeur max_connections

Lorsque vous configurez d’abord votre instance de serveur flexible Azure Database pour Postgres, elle détermine automatiquement le nombre de connexions le plus élevé qu’elle peut gérer simultanément. Ce nombre est basé sur la configuration de votre serveur et ne peut pas être modifié.

Toutefois, vous pouvez utiliser le paramètre max_connections pour ajuster le nombre de connexions autorisées à un moment donné. Après avoir modifié ce paramètre, vous devez redémarrer votre serveur pour que la nouvelle limite prenne effet.

Attention

Bien qu’il soit possible d’augmenter la valeur de max_connections au-delà du paramètre par défaut, nous vous déconseillons de le faire.

Les instances peuvent rencontrer des difficultés lorsque la charge de travail augmente et demande plus de mémoire. À mesure que le nombre de connexions augmente, l’utilisation de la mémoire augmente également. Les instances avec une mémoire limitée peuvent être confrontées à des problèmes tels que des incidents ou une latence élevée. Bien qu’une valeur plus élevée pour max_connections puisse être acceptable quand la plupart des connexions sont inactives, elle peut entraîner des problèmes de performances importants une fois qu’elles sont actives.

Si vous avez besoin de connexions supplémentaires, nous vous suggérons d’utiliser plutôt PgBouncer, la solution Azure intégrée pour la gestion des pools de connexions. Utilisez-le en mode de transaction. Pour commencer, nous vous recommandons d’utiliser des valeurs conservatrices en multipliant les vCores dans la plage de 2 à 5. Ensuite, surveillez attentivement l’utilisation des ressources et les performances des applications pour garantir un fonctionnement fluide. Pour plus d’informations sur PgBouncer, reportez-vous à PgBouncer dans Azure Database pour PostgreSQL – Serveur flexible.

Lorsque la limite du nombre de connexions est dépassée, vous pouvez recevoir l’erreur suivante :

FATAL: sorry, too many clients already.

Lors de l’utilisation d’Azure Database pour PostgreSQL – Serveur flexible pour une base de données très active avec un grand nombre de connexions simultanées, il peut y avoir une pression importante sur les ressources. Cette contrainte peut entraîner une utilisation élevée du processeur, en particulier lorsque de nombreuses connexions sont établies simultanément et quand des connexions sont de courte durée (moins de 60 secondes). Ces facteurs peuvent avoir un impact négatif sur les performances globales d’une base de données en augmentant le temps consacré au traitement des connexions et des déconnexions.

N’oubliez pas que chaque connexion dans Azure Database pour PostgreSQL – Serveur flexible, qu’elle soit inactive ou active, consomme une quantité importante de ressources de votre base de données. Cette consommation peut entraîner des problèmes de niveau de performance au-delà d’une utilisation élevée du processeur, tels qu’une contention de verrouillage ou de disque. L’article Nombre de connexions de base de données sur le Wiki PostgreSQL décrit ce sujet plus en détail. Pour en savoir plus, consultez Identifier et résoudre les performances des connexions dans Azure Database pour PostgreSQL – Serveur flexible.

Limitations fonctionnelles

Les sections suivantes répertorient les considérations relatives à ce qui est ou non pris en charge dans le serveur flexible Azure Database pour PostgreSQL.

Opérations de mise à l’échelle

  • Actuellement, effectuer un scale-up du stockage du serveur nécessite son redémarrage.
  • Le stockage du serveur ne peut être mis à l’échelle que par incréments de 2x. Pour plus d’informations, consultez Stockage.
  • La diminution de la taille de stockage du serveur n’est pas prise en charge pour le moment. La seule façon de procéder est de créer une image mémoire et de la restaurer sur une nouvelle instance Azure Database pour PostgreSQL – Serveur flexible.

Stockage

  • Après avoir configuré la taille de stockage, vous ne pouvez pas la réduire. Vous devez créer un serveur offrant la taille de stockage souhaitée, effectuer une opération manuelle de vidage et restauration, puis migrer vos bases de données vers le nouveau serveur.
  • Quand l’utilisation du stockage atteint 95 % ou quand la capacité disponible est inférieure à 5 Gio (la plus élevée des deux), le serveur passe automatiquement en mode Lecture seule pour éviter les erreurs liées à la saturation des disques. Dans de rares cas, si le taux de croissance des données dépasse le temps nécessaire au passage en mode lecture seule, votre serveur peut néanmoins toujours se retrouver à court d’espace de stockage. Vous pouvez activer la croissance automatique du stockage pour éviter ces problèmes et mettre automatiquement à l’échelle votre stockage en fonction des besoins de votre charge de travail.
  • Nous vous recommandons de définir des règles d’alerte pour storage used ou storage percent lorsque ceux-ci dépassent certains seuils, afin que vous puissiez prendre des mesures de manière proactive, par exemple en augmentant la taille de stockage. Par exemple, vous pouvez définir une alerte si le pourcentage de stockage dépasse les 80 % d’utilisation.
  • Si vous utilisez la réplication logique, vous devez abandonner l’emplacement de réplication logique dans le serveur primaire si l’abonné correspondant n’existe plus. Sinon, les fichiers de journaux WAL (write-ahead log) s’accumulent dans le serveur principal et remplissent le stockage. Si le stockage dépasse un certain niveau et si l’emplacement de réplication logique n’est pas utilisé (en raison d’un abonné non disponible), Azure Database pour PostgreSQL – Serveur flexible supprime automatiquement cet emplacement de réplication logique inutilisé. Cette action libère les fichiers WAL accumulés et empêche votre serveur de devenir indisponible, car le stockage est rempli.
  • Nous ne prenons pas en charge la création d’espaces de table. Si vous créez une base de données, ne fournissez pas de nom d’espace de table. Azure Database pour PostgreSQL – Serveur flexible utilise la valeur par défaut qui est héritée du modèle de base de données. Il est dangereux de fournir un espace de table de type temporaire, car nous ne pouvons pas nous assurer que ces objets restent persistants après des événements tels que les redémarrages du serveur et les basculements haute disponibilité (HA).

Mise en réseau

  • Le déplacement vers et hors d’un réseau virtuel n’est actuellement pas pris en charge.
  • La combinaison de l’accès public avec un déploiement au sein d’un réseau virtuel n’est pas prise en charge actuellement.
  • Les règles de pare-feu ne sont pas prises en charge sur les réseaux virtuels. Vous pouvez utiliser des groupes de sécurité réseau à la place.
  • Les serveurs de base de données avec accès public peuvent se connecter à l’Internet public, par exemple via postgres_fdw. Vous ne pouvez pas restreindre cet accès. Les serveurs des réseaux virtuels peuvent avoir un accès sortant restreint via des groupes de sécurité réseau.

Haute disponibilité

Zones de disponibilité

  • Le déplacement manuel de serveurs vers une zone de disponibilité différente n’est pas pris en charge pour le moment. Toutefois, en utilisant la zone de disponibilité préférée comme zone de secours, vous pouvez activer la haute disponibilité. Après avoir établi la zone de secours, vous pouvez basculer vers celle-ci, puis désactiver la haute disponibilité.

Moteur Postgres, extensions et PgBouncer

  • Postgres 10 et versions antérieures ne sont pas pris en charge, car la communauté open source les a mis hors service. Si vous devez travailler avec une de ces versions, vous devez utiliser l’option Azure Database pour PostgreSQL – Serveur unique, qui prend en charge les anciennes versions majeures 9.5, 9.6 et 10.
  • Azure Database pour PostgreSQL – Serveur flexible prend en charge toutes les extensions contrib et d’autres. (pour plus d’informations, consultez la page Extensions de PostgreSQL).
  • Le regroupement de connexions PgBouncer intégré n’est pas disponible actuellement pour les serveurs Burstable.

Opérations d’arrêt/de démarrage

  • Une fois que vous avez arrêté l’instance Azure Database pour PostgreSQL – Serveur flexible, elle démarre automatiquement après 7 jours.

Maintenance planifiée

  • Vous pouvez remplacer la fenêtre de maintenance personnalisée par n’importe quel jour ou heure de la semaine. Toutes les modifications apportées après la réception de la notification de maintenance n’ont toutefois aucun impact sur la maintenance suivante. Les changements ne prennent effet que lors de la maintenance planifiée le mois suivant.

Sauvegardes de serveur

  • Le système gère les sauvegardes. Il n’existe actuellement aucun moyen d’exécuter manuellement des sauvegardes. Nous vous recommandons d’utiliser pg_dump à la place.

  • Le premier instantané est une sauvegarde complète et les instantanés consécutifs sont des sauvegardes différentielles. Les sauvegardes différentielles ne sauvegardent que les données modifiées depuis la dernière sauvegarde d’instantané.

    Si la taille de votre base de données est par exemple de 40 Go et celle de votre stockage approvisionné de 64 Go, la première sauvegarde d’instantané est de 40 Go. Maintenant, si vous modifiez 4 Go de données, la taille de sauvegarde différentielle d’instantané suivante n’est que de 4 Go. Les journaux des transactions (journaux WAL, write-ahead log) sont distincts des sauvegardes complètes et différentielles et sont archivés en permanence.

Restauration du serveur

  • Lors de l’utilisation de la fonctionnalité de restauration à un instant dans le passé, le nouveau serveur est créé avec les mêmes configurations de calcul et de stockage que le serveur sur lequel il est basé.
  • Les serveurs de base de données dans les réseaux virtuels sont restaurés dans les mêmes réseaux virtuels lorsque vous effectuez une restauration à partir d’une sauvegarde.
  • Le nouveau serveur créé lors d’une restauration ne dispose pas des règles de pare-feu qui existaient sur le serveur d’origine. Vous devez créer des règles de pare-feu séparément pour le nouveau serveur.
  • La restauration vers un autre abonnement n’est pas prise en charge. Comme solution de contournement, vous pouvez restaurer le serveur au sein du même abonnement, puis effectuer une migration du serveur restauré vers un autre abonnement.

Sécurité

  • Le hachage MD5 est désactivé à partir de Postgres 14 et versions ultérieures, et les mots de passe Postgres natifs seront hachés à l’aide de la méthode SCRAM-SHA-256 uniquement.

Contenu connexe