Postgres avec architecture pgpool

Voici un exemple d'architecture pgpool:

Cela implique que vous n'avez besoin que de pgpool sur un seul serveur; Est-ce vrai? Quand je regarde la configuration, je vois aussi que vous configurez des backends à l'intérieur pgpool.conf; donc cela implique encore cela. Mais cela n'explique pas pourquoi je vois aussi pgpool sur les serveurs backend.

Lorsque je regarde la documentation, je vois aussi:

Si vous utilisez PostgreSQL 8.0 ou version ultérieure, l'installation de la fonction pgpool_regclass sur tous les PostgreSQL accessibles par pgpool-II est fortement recommandée, car elle est utilisée en interne par pgpool-II.

Je ne sais donc pas quoi penser; si c'est la meilleure pratique d'avoir pgpool sur tous les backends ou juste un serveur dédié?

En règle générale, vous n'installez pas Pgpool sur les serveurs principaux. Ce que vous voyez sur votre photo est la configuration la plus courante. Pgpool est un serveur autonome qui se trouve essentiellement devant les bases de données. Les deux serveurs Postgres sont souvent configurés avec une réplication en streaming; l'un étant le maître et l'autre l'esclave.

Cela permet à Pgpool d'équilibrer la charge de toutes les requêtes de lecture entre les deux (ou plus) bases de données. Toutes les requêtes impliquant des écritures seront acheminées vers le serveur maître qui à son tour se répliquera sur l'esclave.

Comme l'a dit @Neil McGuigan , vous pouvez également disposer de plusieurs serveurs Pgpool pour obtenir une meilleure haute disponibilité. Techniquement, vous pouvez installer Pgpool sur les serveurs de base de données dans cette configuration, mais ce serait une mauvaise pratique. L'exécution de plusieurs serveurs Pgpool est une configuration beaucoup plus complexe. Si c'est votre première fois avec Pgpool, je commencerais par un serveur Pgpool avant d'en faire fonctionner deux.

Dans l'une ou l'autre configuration, votre serveur d'applications pense qu'il se connecte simplement à une seule base de données Postgres.

À propos pgpool_regclass, qui devrait vraiment être une question distincte, cela provient de la FAQ Pgpool :

Si vous utilisez PostgreSQL 8.0 ou version ultérieure, l'installation de la fonction pgpool_regclass sur tous les PostgreSQL accessibles par pgpool-II est fortement recommandée, car elle est utilisée en interne par pgpool-II. Sans cela, la gestion des noms de table en double dans un schéma différent peut causer des problèmes (les tables temporaires ne sont pas un problème).

Si vous utilisez PostgreSQL 9.4.0 ou version ultérieure et pgpool-II 3.3.4 ou version ultérieure, 3.4.0 ou version ultérieure, vous n'avez pas besoin d'installer pgpool_regclass car PostgreSQL 9.4 possède une fonction intégrée de pgpool_regclass comme la fonction "to_regclass".

Si vous en avez besoin, il suffit d'utiliser du code SQL exécuté sur votre serveur maître Postgres pour ajouter une fonction utilisée par Pgpool.

Avec regclass, il y a une étape supplémentaire que vous devez faire (je pensais à insert_lock). Si vous compilez à partir des sources (généralement la plupart des distributions ont des versions vraiment obsolètes de Pgpool), vous devrez également compiler une bibliothèque Postgres.

Si vous avez compilé à partir des sources, vous devrez aller dans le .../pgpool-II-3.X.X/src/sql/pgpool-regclassdossier et faire a ./configure; make.

Copiez le fichier pgpool-regclass.so dans le répertoire d'extension Postgres. Sur mon serveur Ubuntu 14.04 (juste en utilisant le paquet Postgres 9.3 installation), il est situé à: /usr/lib/postgresql/9.3/lib. N'oubliez pas de le faire pour tous les serveurs Postgres.

Une fois cela terminé, vous pouvez alors exécuter pgpool-regclass.sqlsur le maître. Cela mappe simplement la pgpool_regclassfonction à la bibliothèque que vous avez copiée.

Comme pour tout le reste, il existe de nombreuses façons de réaliser votre déploiement haute disponibilité. Ici, je vais suggérer quelque chose de mon expérience (ma propre implémentation HA):

1. Il est toujours préférable d'avoir plusieurs instances de pgpool2 au lieu d'une seule. La raison est évidente: pgpool2 unique est un point de défaillance unique. Étant donné que pgpool a introduit la fonction de surveillance, il est facile à réaliser.
2. En général, il est légèrement préférable d'avoir des instances de pgpool2 sur des machines distinctes que de partager la même machine entre le backend PostgreSQL et pgpool2. Mais il n'y a pas d'inconvénient significatif même si vous les exécutez sur le même serveur que PostgreSQL. (Dans mon implémentation HA, chaque machine exécute une instance PostgreSQL et une instance pgpool2.)

Enfin, je recommanderai ce tutoriel étape par étape qui vous guidera à partir de zéro (installation du serveur PostgreSQL ...) pour terminer l'implémentation haute disponibilité. Le tutoriel mentionné décrit la mise en œuvre que j'utilise.

J'espère que cela a aidé.

MISE À JOUR: Merci @Moshe Katz - le lien a changé. Maintenant mis à jour ici, dans le message d'origine également.