Regroupement de connexions PostgreSQL :Partie 2 – PgBouncer

En ce qui concerne le regroupement de connexions dans le monde PostgreSQL, PgBouncer est probablement l'option la plus populaire. C'est un utilitaire très simple qui fait exactement une chose - il se situe entre la base de données et les clients et parle le protocole PostgreSQL, émulant un serveur PostgreSQL. Un client se connecte à PgBouncer avec exactement la même syntaxe qu'il utiliserait lors d'une connexion directe à PostgreSQL - PgBouncer est essentiellement invisible.

PgBouncer est pris en charge par presque tous les fournisseurs PostgreSQL DBaaS et largement utilisé dans la communauté. Dans cet article de blog, nous expliquerons comment fonctionne PgBouncer, les avantages et les inconvénients de son utilisation et comment configurer le pooler de connexion. Si vous souhaitez en savoir plus sur le regroupement de connexions en général, ou si vous vous demandez s'il convient à votre déploiement, consultez notre article sur le regroupement de connexions PostgreSQL :Partie 1 - Avantages et inconvénients.

Comment fonctionne PgBouncer ?

Lorsque PgBouncer reçoit une connexion client, il effectue d'abord l'authentification au nom du serveur PostgreSQL. PgBouncer prend en charge tous les mécanismes d'authentification pris en charge par le serveur PostgreSQL, y compris une configuration d'accès basée sur l'hôte (remarque :nous ne pouvons pas acheminer les connexions de réplication via PgBouncer). Si un mot de passe est fourni, l'authentification peut se faire de deux manières :

1. PgBouncer vérifie d'abord le fichier userslist.txt - ce fichier spécifie un ensemble de tuples (nom d'utilisateur, mots de passe cryptés md5). Si le nom d'utilisateur existe dans ce fichier, le mot de passe est comparé à la valeur donnée. Aucune connexion au serveur PostgreSQL n'est établie.
2. Si l'authentification unique est configurée et que l'utilisateur n'est pas trouvé dans le fichier userslist.txt, PgBouncer recherche un auth_query. Il se connecte à PostgreSQL en tant qu'utilisateur prédéfini (dont le mot de passe doit être présent dans le fichier userslist.txt) et exécute la requête auth pour trouver le mot de passe de l'utilisateur et le faire correspondre à la valeur fournie.

Une fois l'authentification réussie :

1. PgBouncer recherche une connexion en cache, avec la même combinaison nom d'utilisateur + base de données.
2. Si une connexion en cache est trouvée, il renvoie la connexion au client.
3. Si une connexion en cache n'est pas trouvée, il crée une nouvelle connexion, à condition que la création d'une nouvelle connexion ne :
   • Augmenter le nombre de connexions à> pool_size
   • Augmenter le nombre de connexions du client à> max_client_connections
   • Augmenter le nombre de connexions à la base de données à > max_db_connections
   • Augmenter le nombre de connexions de l'utilisateur à> max_user_connections
4. Toutes ces valeurs peuvent être définies dans les paramètres de PgBouncer.
5. Si la création d'une nouvelle connexion viole l'un des paramètres, PgBouncer met la connexion en file d'attente jusqu'à ce qu'une nouvelle puisse être créée, sauf si elle viole la restriction max_client_connections.
   

   Remarque :la durée des étapes de post-authentification diffère légèrement en fonction du mode PgBouncer. En mode de regroupement de transactions ou d'instructions, les étapes de post-authentification ne sont exécutées que lorsque le client commence à exécuter une transaction/instruction. Nous discutons plus en détail des modes de regroupement ci-dessous.

6. S'il enfreint la restriction max_client_connections, il interrompt la connexion.

Basé sur la mise en commun mode, PgBouncer attend une opportunité de renvoyer la connexion à la base de données :

• En mode de regroupement de sessions, une connexion est renvoyée au pool uniquement lorsqu'un client ferme la session.
• En mode de regroupement de transactions, une connexion est renvoyée au pool uniquement lorsqu'un client termine une transaction (généralement, une annulation ou une validation est exécutée). Par conséquent, les fonctionnalités basées sur la session ne sont pas prises en charge dans ce mode. Il n'y a aucune garantie que deux transactions exécutées sur la même connexion client PgBouncer s'exécuteront sur la même connexion serveur PgBouncer.
• En mode de regroupement d'instructions, une connexion est renvoyée au pool dès qu'une instruction est exécutée. Ici, la validation automatique est toujours activée.

Avant de renvoyer la connexion à la base de données, PgBouncer exécute une requête de réinitialisation pour la supprimer de toutes les informations de session, ce qui permet de partager en toute sécurité les connexions entre les clients. Il est possible de paramétrer cette requête en fonction des besoins de l'application.

Le mode de regroupement des transactions est le plus souvent utilisé, bien que le mode de regroupement des sessions puisse être utile pour des charges de travail particulières. Vous pouvez en savoir plus sur PgBouncer sur leur page Wiki.

Pourquoi choisir PgBouncer ?

Il existe de nombreuses raisons pour lesquelles PgBouncer est le choix le plus populaire en matière de regroupement de connexions dans PostgreSQL. Voici quelques-unes des meilleures fonctionnalités et avantages offerts par PgBouncer :

• Modes de regroupement - En donnant aux utilisateurs le pouvoir de décider quand une connexion est renvoyée au pool, PgBouncer est capable de prendre en charge une vaste gamme de cas d'utilisation. Et, puisque cette configuration est au niveau du pool, vous pouvez utiliser le mode transaction (meilleures performances) pour vos connexions habituelles à la base de données, et le mode session uniquement lorsque vous avez besoin de fonctionnalités telles que des instructions préparées !
• Configuration et utilisation faciles - PgBouncer est l'un des pooleurs de connexions PostgreSQL les plus faciles à configurer, et il ne nécessite également aucune modification du code côté client.
• Authentification directe - PgBouncer est l'un des rares pooleurs de connexions "middleware" qui peut authentifier en toute sécurité un utilisateur sans avoir accès à ses mots de passe (en clair ou sous forme cryptée). Cela rend PgBouncer plus sécurisé et beaucoup plus facile à entretenir - vous n'avez pas besoin de mettre à jour PgBouncer chaque fois qu'un utilisateur met à jour son mot de passe.
• Léger – Il s'agit d'un processus unique, et toutes les commandes du client et les réponses du serveur passent par PgBouncer sans aucun traitement. Ainsi, il n'a pas besoin de "voir" l'intégralité du contenu en une seule fois et, par conséquent, conserve une très faible empreinte mémoire.
• Évolutivité et performances - Comme nous le verrons plus en détail dans la dernière partie de notre série, PgBouncer peut améliorer considérablement les transactions par seconde que votre serveur PostgreSQL peut prendre en charge, et il s'adapte très bien à un très grand nombre de clients.

Qu'est-ce que PgBouncer ne fait pas ?

PgBouncer, bien qu'un excellent pooleur de connexions, ne prend pas en charge l'équilibrage de charge automatisé ou la haute disponibilité. Il recommande d'utiliser d'autres outils Linux courants comme HAProxy pour créer une architecture prenant en charge ces fonctionnalités.

Jetez un œil à l'exemple d'architecture PostgreSQL pour les lectures à charge équilibrée ci-dessous :

Remarque - Le nœud maître (que tous ces esclaves serait répliqué à partir de) n'est pas affiché dans le diagramme.

Comment configurer PgBouncer

Si vous avez un déploiement ScaleGrid PostgreSQL, vous pouvez configurer PgBouncer en quelques clics. Accédez à la vue détaillée de votre cluster PostgreSQL et cliquez sur l'icône PgBouncer. Une fois que vous avez sélectionné "Activer PgBouncer", des options de configuration vous seront présentées pour personnaliser votre mode de regroupement et la taille de votre pool - vous pouvez accepter les valeurs par défaut (ne vous inquiétez pas, vous pouvez les modifier à tout moment sans temps d'arrêt), et cliquez sur Activer !

Et c'est tout ! Vous êtes prêt à partir.

Si vous avez un déploiement non-ScaleGrid, PgBouncer est distribué dans le cadre du référentiel PostgreSQL et peut être installé à l'aide des gestionnaires de packages respectifs. Pour des instructions plus détaillées ou pour construire à partir de la source, vous pouvez suivre les instructions de leur blog.

Une fois installé, PgBouncer ne vous demande de configurer que quelques paramètres de configuration pour être opérationnel :

1. Une liste de (nom d'utilisateur, mot de passe crypté md5) pour authentifier les clients ou une configuration d'authentification unique pour un déploiement plus sécurisé.
2. Interfaces/IP :ports pour écouter les connexions entrantes.
3. Définitions de pool. Un "pool" est un nom que les clients utilisent comme nom de base de données lors de la connexion à PgBouncer - il peut être mappé à une chaîne de connexion complète (hôte, port, nom de base de données et utilisateur). La définition la plus simple est de la forme :
   * = host=
   Cela créera des pools dynamiques pour chaque combinaison dbname+user et se connectera à l'hôte défini à l'aide du port, du dbname et du nom d'utilisateur fournis par l'utilisateur.

Et c'est tout ! Vous pouvez être opérationnel très rapidement avec PgBouncer. Cependant, il existe de nombreux autres paramètres qui doivent être réglés pour toute distribution de production - ceux-ci dépassent le cadre de cet article de blog, mais vous pouvez en savoir plus à leur sujet dans cet aperçu des configurations de PgBouncer.

PgBouncer, cependant, n'est pas la seule option pour le regroupement de connexions PostgreSQL - dans notre prochain article, nous discuterons de Pgpool-II, qui est probablement le principal concurrent de PgBouncer. Restez à l'écoute pour notre quatrième article de cette série en quatre parties où nous comparons PgBouncer à Pgpool-II.