PgBouncer est un pooler de connexions léger pour PostgreSQL. PgBouncer 1.7 a été annoncé le 18 décembre 2015. Dans cet article de blog, nous parlerons des nouvelles améliorations majeures apportées à PgBouncer.

Les fonctionnalités les plus colorées

• PgBouncer 1.7 prend en charge les connexions TLS et, je pense que c'est la plus grande amélioration de la nouvelle version. Ils ont utilisé les bibliothèques OpenSSL/LibreSSL comme implémentation backend de la fonctionnalité.

• PgBouncer prend désormais en charge l'authentification via certificat client TLS .

Examinons les détails des paramètres TLS de PgBouncer. Il existe 14 paramètres de configuration liés à la configuration TLS (paramètres côté client + côté serveur).

Pour attribuer le mode TLS à utiliser pour les connexions des clients, nous devons définir client_tls_sslmode paramètre. Les connexions TLS sont désactivées par défaut. Lorsqu'il est activé, client_tls_key_file et client_tls_cert_file doit également être configuré pour configurer la clé et le certificat que PgBouncer utilise pour accepter les connexions client.

Nous pouvons attribuer un certificat racine pour valider les certificats clients en définissant client_tls_ca_file paramètre, la valeur par défaut n'est pas définie.

Nous pouvons spécifier les versions de protocole TLS autorisées en définissant client_tls_protocols paramètre, la valeur par défaut est tout.

Pour des paramètres côté client plus détaillés, vous pouvez vérifier client_tls_ciphers , client_tls_ecdhcurve et client_tls_dheparams paramètres.

Parlons maintenant des paramètres de configuration côté serveur TLS. Tout d'abord, nous devons déclarer le mode TLS à utiliser pour les connexions aux serveurs PostgreSQL avec server_tls_sslmode paramètre. Les connexions TLS sont désactivées par défaut. Nous pouvons attribuer un serveur CA avec server_tls_ca_file paramètre. Si nous souhaitons attribuer une clé privée à PgBouncer pour s'authentifier auprès du serveur PostgreSQL, nous pouvons utiliser server_tls_key_file paramètre, nous pouvons même attribuer un certificat pour la clé privée que le serveur PostgreSQL peut valider avec server_tls_cert_file paramètre. Comme nous l'avons fait dans les paramètres de connexion TLS côté client, nous pouvons déclarer quelles versions de protocole TLS sont autorisées avec server_tls_protocols paramètre.

• Après la prise en charge de TLS, une autre nouvelle fonctionnalité importante est la prise en charge de l'authentification "pair" sur les sockets Unix.

• En tant que dernière fonctionnalité majeure de cette version, je voudrais mentionner la prise en charge du fichier de contrôle d'accès basé sur l'hôte, comme pg_hba.conf dans Postgres. Cela permet de configurer TLS pour les connexions réseau et l'authentification "pair" pour les connexions locales.

Nous pouvons configurer comment authentifier les utilisateurs avec auth_type paramètre de PgBouncer. Tous les paramètres de configuration sont définis dans le fichier de configuration pgbouncer.ini. Examinons les détails de auth_type paramètre.

auth_type paramètre peut être affecté à l'une des 6 valeurs listées ci-dessous. Voyons les explications et l'utilisation de ces valeurs.

• hba : Si nous définissons le paramètre auth_type avec la valeur hba , nous devrions définir auth_hba_file également pour montrer quel pg_hba.conf fichier sera utilisé comme configuration. En faisant cela, nous permettons au type d'authentification réel d'être chargé à partir de auth_hba_file. Cela signifie que nous pouvons utiliser différentes méthodes d'authentification pour différents chemins d'accès. Par exemple, avec la connexion de la version 1.7 sur le socket Unix, utilisez la méthode d'authentification par les pairs, en même temps, la connexion sur TCP doit utiliser TLS. Jusqu'à présent, le format de fichier HBA ne prend pas en charge toutes les méthodes d'authentification de pg_hba.conf. Les méthodes prises en charge sont les suivantes :confiance, rejet, md5, mot de passe, pair et cert.
• certification : Le client doit se connecter via TLS connexion avec un certificat client valide. Le nom d'utilisateur est alors extrait de CommonName champ du certificat.
• md5 : Utilisez la vérification de mot de passe basée sur MD5. auth_file (le nom du fichier à partir duquel charger les noms d'utilisateur et les mots de passe ) peut contenir à la fois des mots de passe cryptés MD5 ou en texte brut. Il s'agit de la méthode d'authentification par défaut.
• uni : Le mot de passe en texte clair est envoyé par câble. Obsolète.
• confiance : Aucune authentification n'est effectuée. Le nom d'utilisateur doit toujours exister dans auth_file .
• tout : Comme la méthode de confiance, mais le nom d'utilisateur donné est ignoré. Nécessite que toutes les bases de données soient configurées pour se connecter en tant qu'utilisateur spécifique. De plus, la base de données de la console permet à tout utilisateur de se connecter en tant qu'administrateur.

Autres fonctionnalités brillantes

Il y a plus de fonctionnalités publiées dans cette version. Vous pouvez visiter la page du journal des modifications de PgBouncer ou consulter la liste ci-dessous pour les autres améliorations :

• Définir query_wait_timeout à 120s par défaut. Ce paramètre définit le temps maximum que les requêtes sont autorisées à passer en attente d'exécution. Si la requête n'est pas affectée à un serveur pendant ce temps, le client est déconnecté. Ceci est utilisé pour empêcher les serveurs qui ne répondent pas de saisir les connexions. Cela aide également lorsque le serveur est en panne ou que la base de données rejette les connexions pour une raison quelconque. Si cette option est désactivée, les clients seront mis en file d'attente à l'infini. La valeur par défaut actuelle (0) provoque une file d'attente infinie, ce qui n'est pas utile. Avec la version 1.7, si le client a une requête en attente et n'a pas été affecté à la connexion au serveur, la connexion client sera interrompue après 120 secondes par défaut.
• Désactiver server_reset_query_always par défaut. Désormais, la requête de réinitialisation n'est utilisée que dans les pools en mode session.
• Augmenter pkt_buf à 4096 octets. Améliore les performances avec TLS . Le comportement est probablement spécifique à la charge, mais il devrait être prudent de le faire car depuis la v1.2, les tampons de paquets sont séparés des connexions et utilisés paresseusement à partir du pool.
• Prise en charge du nombre de pipelines attendu ReadyForQuery paquets. Cela évite de libérer le serveur trop tôt. Correctifs #52.
• Amélioration de sbuf_loopcnt logique - socket est garanti d'être retraité même s'il n'y a aucun événement de socket. Obligatoire pour TLS car il a sa propre mémoire tampon.
• Adapter les tests système pour qu'ils fonctionnent avec les BSD modernes et MacOS . (Eric Radman )
• Supprimer crypte auth. Il est obsolète et non pris en charge par PostgreSQL depuis 8.4 .
• Corrigez le simple "–with-cares" configure l'option - sans argument, elle était cassée.

Qu'est-ce que PgBouncer ?

PgBouncer est un utilitaire de gestion des connexions client à la base de données PostgreSQL. En un mot, il maintient un pool de connexions au serveur PostgreSQL et réutilise ces connexions existantes. Bien que cela puisse être utile pour réduire la charge de connexion client, cela permet également de limiter le nombre maximal de connexions ouvertes au serveur de base de données. Il peut également être utilisé pour la mise en forme du trafic, comme la redirection des connexions vers une ou plusieurs bases de données vers différents serveurs de base de données. En plus de cela, PgBouncer peut être utilisé pour gérer la sécurité au niveau de l'utilisateur et même au niveau de la base de données.

Vous pouvez télécharger PgBouncer via leur page de téléchargement et commencer à l'utiliser dès maintenant !

Pour plus d'informations sur PgBouncer, vous pouvez consulter mon article de blog précédent sur PgBouncer.

Bonnes lectures !