Partager via

Limites dans le serveur flexible Azure Database pour PostgreSQL

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

Les sections suivantes décrivent les limites de capacité et les limites fonctionnelles d’un 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. 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 du nombre total de connexions utilisateur répertoriées dans le tableau 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
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 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 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. 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 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 un serveur flexible 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.

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 un 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 aborde ce sujet plus en détail. Pour en savoir plus, consultez Identifier et résoudre les performances des connexions dans un serveur flexible Azure Database pour PostgreSQL.

Limitations fonctionnelles

Les sections suivantes répertorient les considérations relatives à ce qui est ou non pris en charge dans un serveur flexible 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 d’un 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 d’un serveur n’est pas prise en charge pour le moment. La seule façon de procéder est de la sauvegarder et de la restaurer sur 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.
  • 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 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 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 ce type d’objets demeure après des événements tels que les redémarrages du serveur et les basculements haute disponibilité (HA).

Réseaux

  • 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 les versions antérieures ne sont pas pris en charge, car la communauté open source les a retirés. Si vous devez utiliser l’une de ces versions, vous devez utiliser l’option Serveur unique Azure Database pour PostgreSQL, 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 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 de serveur flexible Azure Database pour PostgreSQL, celle-ci démarre automatiquement après 7 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. 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, 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é.

    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 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

  • 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