Partager via

Limites dans Azure Database pour PostgreSQL

Les sections suivantes décrivent les limites fonctionnelles et de capacité pour les instances de serveur flexible Azure Database pour PostgreSQL. Si vous souhaitez découvrir 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 de vCore. Une instance de serveur flexible Azure Database pour PostgreSQL réserve 15 connexions pour la réplication physique et la surveillance de l’instance de serveur flexible Azure Database pour PostgreSQL. Par conséquent, la table réduit la valeur des connexions utilisateur maximales 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
Burstable
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 Gio 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 Gio 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 à 15, peuvent 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).

Le système calcule la valeur par défaut du paramètre de max_connections serveur lorsque vous approvisionnez l’instance du serveur flexible Azure Database pour PostgreSQL, en fonction du nom de produit que vous sélectionnez pour son calcul. Les modifications suivantes de la sélection de produit au calcul qui prend en charge l’instance n’ont aucun effet sur la valeur par défaut du max_connections paramètre serveur de cette instance. Nous vous recommandons que chaque fois que vous changez le produit attribué à une instance, vous ajustez également la valeur du paramètre max_connections en fonction des valeurs du tableau précédent.

Changement de la valeur max_connections

Lorsque vous configurez d’abord votre instance de serveur flexible Azure Database pour Postgres, celle-ci détermine automatiquement le nombre de connexions le plus élevé qu’elle peut gérer simultanément. La configuration de votre serveur détermine ce nombre et vous ne pouvez pas le modifier.

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 risquent de rencontrer des difficultés lorsque la charge de travail augmente et exige 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 une plage de 2 à 5. Ensuite, surveillez attentivement l’utilisation des ressources et les performances des applications pour vous assurer que tout fonctionne correctement. Pour plus d’informations sur PgBouncer, consultez PgBouncer dans Azure Database pour PostgreSQL.

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

FATAL: sorry, too many clients already.

Lorsque vous utilisez une instance de serveur flexible Azure Database pour PostgreSQL pour une base de données occupée avec un grand nombre de connexions simultanées, il peut y avoir une contrainte significative 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.

Chaque connexion dans une instance de serveur flexible Azure Database pour PostgreSQL, 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 performance qui vont au-delà d’une utilisation élevée du processeur, tels qu’une contention de verrous ou de disques. L’article Nombre de connexions de base de données sur le Wiki PostgreSQL traite de cet article plus en détail. Pour en savoir plus, consultez Identifier et résoudre les performances de connexion dans Azure Postgres.

Limitations fonctionnelles

Les sections suivantes répertorient les considérations relatives à ce qui est et n'est pas pris en charge pour vos instances de serveur flexible d'Azure Database pour PostgreSQL.

Opérations de mise à l’échelle

  • Actuellement, effectuer un scale-up du stockage d’un serveur nécessite de le redémarrer.
  • Le stockage serveur ne peut être mis à l’échelle que par multiples de 2. Pour plus d’informations, consultez Stockage .
  • Actuellement, nous ne prenons pas en charge la diminution de la taille de stockage du serveur. La seule façon de procéder à cette opération consiste à exporter et restaurer dans une nouvelle instance de serveur flexible Azure Database pour PostgreSQL.

Stockage

  • Après avoir configuré la taille du 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.
  • Lorsque l’utilisation du stockage atteint 95% ou si la capacité disponible est inférieure à 5 Gio (selon ce qui est plus), le système bascule automatiquement le serveur en mode lecture seule pour éviter les erreurs associées aux situations complètes du disque. Dans de rares cas, si le taux de croissance des données dépasse le temps qu’il faut pour passer en mode lecture seule, votre serveur peut quand même se retrouver à court 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 du stockage. Par exemple, vous pouvez définir une alerte si le pourcentage de stockage dépasse les 80 % d’utilisation.
  • Si vous utilisez une réplication logique, vous devez abandonner l’emplacement de réplication logique sur 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 seuil et si l’emplacement de réplication logique n’est pas utilisé (en raison d’un abonné indisponible), une instance de serveur flexible Azure Database pour PostgreSQL supprime automatiquement cet emplacement de réplication logique inutilisé. Cette action libère les fichiers WAL cumulé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. Une instance de serveur flexible Azure Database pour PostgreSQL utilise l’espace de table par défaut hérité par la base de données de modèle. Il est dangereux de fournir un espace de table de type temporaire, car nous ne pouvons pas nous assurer que ce type d’objets demeure après des événements tels que les redémarrages du serveur et les basculements haute disponibilité (HA).
  • Différences d’utilisation des fichiers de données et des disques orphelins : Dans de rares cas, PostgreSQL peut laisser derrière les fichiers de données orphelins sur disque, les fichiers qui n’ont plus d’entrées correspondantes dans le catalogue système de la base de données (qui effectue le suivi de toutes les tables et données). Cela peut se produire si une table est créée et remplie dans une transaction qui ne parvient pas à se terminer correctement (par exemple, en raison d’un incident ou d’une interruption du serveur), ce qui entraîne une incompatibilité entre la taille signalée par la base de données et l’utilisation réelle du disque. Ce comportement provient de la base de code base de la communauté PostgreSQL et n’est pas spécifique à Azure. La communauté PostgreSQL est consciente du problème et explore les améliorations apportées au nettoyage automatique dans les versions ultérieures. Pour plus d’informations, consultez : PostgreSQL : Fichiers orphelins dans PostgreSQL. Cela peut entraîner une consommation inattendue de disque ou de stockage.
    • Guide pratique pour détecter : comparer la taille signalée par la base de données (à l’aide de requêtes telles que SELECT pg_database_size('your_database')) avec les métriques du portail Azure pour l’utilisation réelle du disque. S’il existe une différence significative, les fichiers orphelins peuvent être la cause. Si c’est le cas :
      • Exécutez VACUUM FULL sur les tables affectées pour récupérer de l’espace (remarque : il s’agit d’une ressource intensive, nécessite un verrou de table et peut nécessiter un temps d’arrêt).
      • Vous pouvez également utiliser d'outils tels que les extensions pg_repack ou pg_squeeze pour la réorganisation sans temps d’arrêt, mais testez d’abord dans un environnement non-production.
      • Surveillez via les métriques du portail Azure pour les seuils d’utilisation du disque. Si le problème persiste ou si vous n’êtes pas sûr, contactez le support Azure pour obtenir de l’aide.
    • Comment empêcher : assurez-vous que les transactions sont correctement gérées dans vos applications pour réduire les opérations incomplètes. Surveillez régulièrement l’utilisation du disque via les métriques du portail Azure. La mise à niveau vers la dernière version de PostgreSQL prise en charge peut inclure des correctifs de communauté pour les problèmes connexes.

Réseaux

  • Actuellement, nous ne prenons pas en charge le déplacement vers et hors d’un réseau virtuel.
  • Actuellement, nous ne prenons pas en charge la combinaison de l’accès public avec le déploiement dans un réseau virtuel.
  • Les réseaux virtuels ne prennent pas en charge les règles de pare-feu. 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é

  • Actuellement, nous ne prenons pas en charge le déplacement manuel de serveurs vers une autre zone de disponibilité. 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

  • Une instance de serveur flexible Azure Database pour PostgreSQL prend en charge toutes les fonctionnalités du moteur PostgreSQL, notamment le partitionnement, la réplication logique et les wrappers de données étrangers.
  • Une instance de serveur flexible Azure Database pour PostgreSQL prend en charge toutes les contrib extensions et bien plus encore. Pour plus d’informations, consultez Extensions de PostgreSQL.
  • Les serveurs Burstable n’ont actuellement pas accès au pooleur de connexion intégré de PgBouncer.

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

  • Après avoir arrêté l’instance de serveur flexible Azure Database pour PostgreSQL, elle démarre automatiquement après sept jours.

Maintenance planifiée

  • Vous pouvez changer la fenêtre de maintenance personnalisée en définissant n’importe quel jour/n’importe quelle 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. Vous ne pouvez pas exécuter manuellement les sauvegardes. Nous vous recommandons d’utiliser pg_dump à la place.

  • Le premier instantané est une sauvegarde complète, tandis que les instantanés qui suivent sont des sauvegardes différentielles. Les sauvegardes différentielles sauvegardent uniquement les données qui ont été modifiées depuis la dernière sauvegarde d’instantané.

    Par exemple, si la taille de votre base de données est de 40 Go et que votre stockage approvisionné est 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 la prochaine sauvegarde d’instantané différentielle ne sera 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

  • Lorsque vous utilisez la fonctionnalité de restauration dans le temps (PITR), le système crée le nouveau serveur avec les mêmes configurations de calcul et de stockage que le serveur sur lequel il est basé.
  • Le système restaure les serveurs de base de données dans des réseaux virtuels 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.
  • Nous ne prenons pas en charge la restauration vers un autre abonnement. 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é

  • Postgres 14 et les versions ultérieures désactivent le hachage MD5 et les mots de passe natifs de Postgres sont hachés par le système uniquement à l'aide de la méthode SCRAM-SHA-256.

Contenu connexe

  • Last updated on