Dans nos articles précédents de cette série, nous avons discuté du cas de la mise en commun des connexions et introduit PgBouncer. Dans cet article, nous discuterons de son alternative la plus populaire - Pgpool-II.
Pgpool-II est le couteau suisse du middleware PostgreSQL. Il prend en charge la haute disponibilité, fournit un équilibrage de charge automatisé et possède l'intelligence nécessaire pour équilibrer la charge entre les maîtres et les esclaves afin que les charges d'écriture soient toujours dirigées vers les maîtres, tandis que les charges de lecture sont dirigées vers les esclaves. Pgpool-II fournit également une réplication logique. Bien que son utilisation et son importance aient diminué à mesure que les options de réplication intégrées se sont améliorées côté serveur PostgreSQL, cela reste une option précieuse pour les anciennes versions de PostgreSQL. En plus de tout cela, il fournit également un regroupement de connexions !
En bref | ||||||
|---|---|---|---|---|---|---|
|
Configuration de Pgpool-II
Les binaires Pgpool-II sont distribués via les référentiels de Pgpool-II - vous pouvez en savoir plus sur l'installation dans ce document d'aide. Une fois installé, nous devons configurer Pgpool-II pour activer les services que nous voulons et nous connecter au serveur PostgreSQL. Vous pouvez en savoir plus ici.
Pour obtenir une configuration de pool minimale, vous devez fournir les éléments suivants :
- Le nom d'utilisateur et le mot de passe crypté md5 du ou des utilisateurs qui se connecteront à Pgpool-II ; ils doivent être définis dans un fichier séparé, qui peut être facilement généré à l'aide de l'utilitaire pg_md5.
- Interfaces/adresses IP et numéro de port à écouter pour les connexions entrantes - cela doit être défini dans le fichier de configuration.
- Le nom d'hôte du ou des serveurs principaux [plusieurs serveurs sont spécifiés uniquement si nous souhaitons utiliser la réplication et/ou l'équilibrage de charge].
- Les services que vous souhaitez activer. Par défaut, le regroupement de connexions est activé et les autres services sont désactivés dans le fichier de configuration installé avec les binaires.
Et c'est tout :nous sommes prêts ! Bien que les configurations disponibles avec Pgpool-II puissent être plus intimidantes à première vue, les gens derrière Pgpool-II nous ont vraiment facilité la tâche !
Comment ça marche
Pgpool-II a une architecture plus complexe que PgBouncer afin de prendre en charge toutes les fonctionnalités qu'il propose. Cependant, dans cette section, nous nous limiterons à décrire le fonctionnement du regroupement de connexions.
Le processus parent Pgpool-II fork 32 processus enfants par défaut - ceux-ci sont disponibles pour la connexion. L'architecture est similaire au serveur PostgreSQL :un processus =une connexion. Il bifurque également le «processus pcp» qui est utilisé pour les tâches administratives, et au-delà de la portée de ce poste. Les 32 enfants sont maintenant prêts à accepter les connexions. Comme PgBouncer, ceux-ci émulent également un serveur PostgreSQL - les clients peuvent se connecter avec exactement la même chaîne de connexion qu'ils le feraient avec un serveur PostgreSQL normal.
Le noyau dirige les connexions entrantes vers l'un des processus enfants qui se sont enregistrés en tant qu'écouteurs. Ni le processus principal Pgpool-II ni les utilisateurs finaux n'ont le moindre contrôle sur le processus enfant qui répond à une requête entrante. Tout enfant inactif peut prendre la demande. Si aucun enfant inactif n'est trouvé, la demande de connexion sera mise en file d'attente côté noyau - cela peut entraîner le blocage d'applications comme pgbench, en attente de connexions client.
Une fois qu'un enfant Pgpool-II inactif reçoit une demande de connexion, il :
- Vérifie le nom d'utilisateur dans son fichier de mots de passe. S'il n'est pas trouvé, il rejette la connexion.
- Si le nom d'utilisateur est trouvé, il vérifie le mot de passe fourni par rapport au hachage md5 stocké dans ce fichier.
- Une fois l'authentification réussie, il vérifie s'il a déjà une connexion en cache pour cette combinaison base de données + utilisateur.
- Si c'est le cas, il renvoie la connexion au client. Si ce n'est pas le cas, il ouvre une nouvelle connexion.
- Toutes les requêtes et réponses passent par Pgpool-II en attendant que le client se déconnecte.
- Une fois que le client se déconnecte, Pgpool-II doit décider s'il faut mettre en cache la connexion :
- S'il a un emplacement vide, il le met en cache.
- S'il n'a pas d'emplacement vide (c'est-à-dire que la mise en cache de cette connexion dépasserait le max_pool_size autorisé), il décidera en fonction d'un algorithme interne.
- S'il décide de mettre en cache la connexion, il exécutera la requête de réinitialisation préconfigurée pour nettoyer tous les détails de la session et la rendre sûre pour une réutilisation par un autre client.
- Maintenant, le processus enfant est libre de capter plus de connexions.
|
Qu'est-ce que Pgpool-II ne fait pas ?
Malheureusement, pour ceux qui se concentrent uniquement sur la mise en commun des connexions, ce que Pgpool-II ne fait pas très bien, c'est la mise en commun des connexions, en particulier pour un petit nombre de clients. Étant donné que chaque processus enfant a son propre pool et qu'il n'y a aucun moyen de contrôler quel client se connecte à quel processus enfant, trop de chance est laissée à la chance lorsqu'il s'agit de réutiliser les connexions.
Comme vous pouvez le voir, Pgpool et PgBouncer ont des forces assez différentes - dans notre dernier article de la série, nous ferons un test en tête-à-tête , et comparaison des fonctionnalités ! Restez à l'écoute !
Série de regroupement de connexions PostgreSQL
|
|---|
