Étant donné que je n'ai pas suffisamment d'informations sur l'architecture utilisée et qu'elle n'est basée que sur un exemple très descriptif - je télécharge les informations obtenues à partir de recherches permettant aux membres de la communauté de compléter/étendre cette réponse.
Sur la base de cette documentation PgBouncer n'a pas de configuration interne multi-hôtes. Pour équilibrer la charge des requêtes entre plusieurs serveurs, on peut utiliser des outils externes tels que :
-
DNS round-robin . Utiliser plusieurs IP derrière un seul nom DNS. PgBouncer ne recherche pas les DNS à chaque fois qu'une nouvelle connexion est lancée. Au lieu de cela, il met en cache toutes les IP et effectue un round-robin en interne. Remarque : s'il y a plus de 8 IP derrière un nom, le backend DNS doit supporter le protocole EDNS0. Voir README pour plus de détails.
-
Utilisez un Équilibreur de charge de connexions TCP . Soit LVS o HAProxy semblent être de bons choix. Du côté de PgBouncer, il serait peut-être bon de faire de server_lifetime plus petit et aussi tourner server_round_robin on : par défaut, les connexions inactives sont réutilisées par un algorithme LIFO, ce qui peut ne pas fonctionner aussi bien lorsqu'un équilibrage de charge est nécessaire.
Ce blog explique pourquoi utiliser un autre mécanisme d'équilibreur de charge avec pgBouncer. Selon celle-ci, vous ne devriez pas utiliser pgBouncer au lieu de HAProxy ou d'un autre équilibreur de charge. Il est évident que pgBouncer possède plusieurs fonctions configurables qui répondent aux besoins d'un équilibreur de charge, mais il est plus courant que les environnements de production utilisent HAProxy ou un autre équilibreur de charge pour la gestion des ressources humaines. La raison en est que HAProxy équilibre mieux les charges de travail sur les serveurs actifs que pgbouncer.
Bien que pgbouncer soit meilleur pour la mise en commun des connexions postgres, il peut être préférable d'utiliser un petit démon qui exécute parfaitement une tâche, plutôt qu'un plus gros qui exécute deux tâches, mais en pire.
Il est également judicieux d'utiliser PgPool. Voir aussi cette réponse .
Ici Il existe également un article qui compare PgBouncer et PgPool. Une petite partie de cet article : | | PGBOUNCER | PGPOOL-II | |--|--|--| | Haute disponibilité |Non pris en charge. | Haute disponibilité de PostgreSQL est supporté par les processus de surveillance intégrés de Pgpool-II. Gagnant ! | | Équilibrage des charges |PgBouncer recommande l'utilisation de HAProxy pour la haute disponibilité et l'équilibrage de la charge. Il prend en charge l'équilibrage automatique de la charge et est même suffisamment intelligent pour rediriger les demandes de lecture vers les serveurs secondaires et les demandes d'écriture vers les serveurs principaux. Gagnant ! |
