Vous n'êtes pas identifié(e).
Bonjour à tous...
ici nous commençons à parler de PGPOOL et j'ai commencé a voir tout ça sur internet...
Sur ce que j'en ai lu, pouvez-vous me confirmer (ou pas !) mes interrogations suivantes :
1°) C'est un produit qui optimise les temps de connexions
2°) Il répartit les connexions au mieux
3°) il les 'partage', dans le sens où il conserve une connexion existante pour la donner/l'associer à une nouvelle qui arrive...
4°) Est-ce vraiment un produit qui accélère les connexion (à peu près quel ratio ?)
5°) Existe t'il sur d'autre os que la Débian ?
Merci pour vos réponses...
Hors ligne
Bonjour à tous...
ici nous commençons à parler de PGPOOL et j'ai commencé a voir tout ça sur internet...
Sur ce que j'en ai lu, pouvez-vous me confirmer (ou pas !) mes interrogations suivantes :1°) C'est un produit qui optimise les temps de connexions
2°) Il répartit les connexions au mieux
3°) il les 'partage', dans le sens où il conserve une connexion existante pour la donner/l'associer à une nouvelle qui arrive...
4°) Est-ce vraiment un produit qui accélère les connexion (à peu près quel ratio ?)
5°) Existe t'il sur d'autre os que la Débian ?Merci pour vos réponses...
Bonjour
pgPool est un outil qui peut faire beaucoup de choses différentes, dont du pool du connexion et de la répartition de charges.
Il permet ainsi de gagner du temps en conservant une connexion ouverte, ce qui évite de passer du temps à en recréer une plus tard, ce qui est particulièrement efficace pour les bases de données qui ont beaucoup de connexions qui durent très peu de temps (frontal web par exemple).
Sinon, il peut tourner sur n'importe quel linux.
Pour le reste, je ne sais pas trop comment se passe la répartition de charge je ne m'avancerai donc pas.
Julien.
https://rjuju.github.io/
Hors ligne
À noter quand même qu'il examine chaque requête et que cet "examen" a un coût non négligeable. Il est donc nécessaire de le tester pour savoir si, par rapport à l'activité de la base, pgpool apporte un plus ou non.
À noter aussi que pgbouncer fera un meilleur job (plus performant surtout) que pgpool dans le cas du pooling seul. Par contre, si vous voulez de la répartition de charge, il n'y a que pgpool.
Guillaume.
Hors ligne
Merci pour vos réponses..
1°) Pourquoi PGPOOL examine-t'il les requêtes ? Est-ce un pré-explain pour anticiper le temps de connexion à la database ?
2°) Qu'appelez-vous Pooling seul ?
Merci Guillaume pour vos réponses...
Hors ligne
Non, il ne s'agit pas d'un pré-explain. Il s'agit d'une analyse du contenu de la requête, pas des résultats. Dans le cadre de la réplication de charge, cela permet de deviner si la requête est en écriture ou en lecture (et suivant la réponse, la requête est envoyé à un serveur ou à un autre).
Pour le pooling seul, c'est ne faire que du pooling, autrement dit pas d'activation du mode réplication et du mode de répartition de charge.
Guillaume.
Hors ligne
A noter également que pgBouncer permet du pool de connexion sur 3 niveaux : à la requête, à la transaction et à la session (pgPool lui ne fait que du pool à la session je crois).
Julien.
https://rjuju.github.io/
Hors ligne
Et avant que quelqu'un pose la question, pgpool analyse la requête en mode lecture seule aussi dans le but de récupérer les ordres du type "SHOW pool_config" que seul lui peut exécuter.
Guillaume.
Hors ligne
rjuju : oui, pgpool ne fonctionne qu'à la session.
Guillaume.
Hors ligne
Merci à vous deux...
Je suis en train de lire toutes les options sur la haute disponibilité : http://docs.postgresql.fr/8.3/high-availability.html ... Quelqu'un a t'il une quelconque expérience en haute disponibilité sur Postgrès... et aussi quel fut leur choix et pourquoi ?
Nous allons je pense, intégrer une appli en haute dispo via PGPOOL... mais, les autres solutions ont aussi leurs avantages... J'aimerai en fait, avoir un retour de ceux qui ont implémenté une telle architecture sur Postgrès... et aussi pourquoi ils ont choisit telle ou telle solution ...
Merci d'avance pour vos retours !
NB : Le log Shipping fait-il partie de la solution de réplication asynchrone des données : Chapitre 'Réplication asynchrone multi-maîtres' de la page ouèb citée plus haut ?
Hors ligne
La seule solution de réplication multi-maître réellement utilisable (à ma connaissance) est Bucardo. Pour l'instant avec un maximum de 2 noeuds maîtres. Et plus quand la version 5 sortira. En tout cas, non, pas de réplication multi-maître avec le logshipping.
Concernant les solutions de haute disponibilité, oui, c'est assez simple à mettre en place. Mais les solutions exactes dépendent vraiment de votre contexte, donc difficile d'être très précis. Généralement, on voit surtout du pgpool avec du Slony ou de la réplication interne. On utilisera la réplication interne (très simple et intégrée) si on n'a pas besoin des spécificités de Slony (comme la réplication en cascade, la possibilité de créer des objets sur les esclaves, et la granularité très fine de la réplication). De même, on utilisera pgBouncer au lieu de pgpool si on n'a pas besoin de répartition de charge.
Vous trouverez plein d'articles sur le sujet sur http://www.dalibo.org/publications ainsi que des slides et vidéos de conférentes sur http://www.dalibo.org/conferences .
Guillaume.
Hors ligne
Merci Guillaume, je vais lire tout ça à tête reposée ...
Hors ligne
Une autre : Nous penchons vers une structure avec 1 serveur maître et un esclave (avec répartition de charges), mais j'avoue être un peu embrouillé... ...
1°) Quand vous parlez de PGPOOL avec Slony, on est bien d'accord que c'est du triggering entre le maitre et l'esclave (Une modifications de données du maître envoie la même modification (via un trigger) vers l'esclave)... me trompe-je ?
2°) Est-ce ça que vous appelez le 'synchrone asymétrique' ou est-ce du 'wa
3°) Pour moi, d'après ce que j'avais lu, la solution du log shipping entre les deux serveurs me semblait simple, est-ce ça que vous appelez l''asynchrone asymétrique '
4°) J'ai vu qu'il y avait aussi la solution de passage par les WALLS... ok, mais mais je n'ai pas lu de post là dessus... est-ce ça que vous appelez le synchrone asymétrique '
Hors ligne
je reprends :
Une autre : Nous penchons vers une structure avec 1 serveur maître et un esclave (avec répartition de charges), mais j'avoue être un peu embrouillé... ...
1°) Quand vous parlez de PGPOOL avec Slony, on est bien d'accord que c'est du triggering entre le maitre et l'esclave (Une modifications de données du maître envoie la même modification (via un trigger) vers l'esclave)... me trompe-je ?
2°) Est-ce ça que vous appelez le 'synchrone asymétrique'
3°) Pour moi, d'après ce que j'avais lu, la solution du log shipping entre les deux serveurs me semblait simple, est-ce ça que vous appelez l''asynchrone asymétrique ' ou est-ce du 'warm standby'
4°) J'ai vu qu'il y avait aussi la solution de passage par les WALLS... ok, mais mais je n'ai pas lu de post là dessus... est-ce ça que vous appelez le synchrone asymétrique '
Hors ligne
1)Oui
2)Oui
3)Le log shipping ou la réplication par trigger sont toutes les deux asymétriques. C'est bien du warm standby, sauf en 9.0, où l'esclave peut-être rendu accessible en lecture, qu'on appelle hot standby par opposition. Et en 9.0, on peut faire du log-shipping beaucoup plus fin (pas par fichier de 16Mo mais au fil de l'eau), c'est ce qu'on appelle la streaming replication
4) C'est le Warm Standby, le passage par WAL. C'est asynchrone asymétrique.
Marc.
Hors ligne
Pour le 2, non, Slony, c'est du asymétrique asynchrone.
Guillaume.
Hors ligne
Oups, lu trop vite, désolé 
Marc.
Hors ligne
1°) Quand vous parlez de PGPOOL avec Slony, on est bien d'accord que c'est du triggering entre le maitre et l'esclave (Une modifications de données du maître envoie la même modification (via un trigger) vers l'esclave)... me trompe-je ?
pgpool et Slony sont deux outils indépendants. Pgpool peut s'appuyer sur Slony pour faire de l'équilibrage entre le maître et l'esclave, mais c'est Slony qui assure la réplication.
Slony est un outil de réplication asynchrone asymétrique. Il fonctionne effectivement à base de triggers.
Asynchrone : les données sont propagées sur l'esclave indépendamment de leur enregistrement sur le maître.
Asymétrique : la réplication ne s'effectue que dans le sens maître -> esclave.
2°) Est-ce ça que vous appelez le 'synchrone asymétrique'
Synchrone : l'écriture sur le maître s'effectue après la validation de l'écriture sur l'esclave. Principe existant sur PostgreSQL 9.1 en streaming replication.
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
Merci à tous...
Une autre question d'un novice :
En fait nous allons installer un Postgres 9 pour faire tout ça avec un serveur maître + un esclave (j'avais oublié de vous le dire !)...
Je me pose la question suivante : Pourquoi installer slony (donc je suppose créations de x triggers sur x tables... rajout de triggers à chaque création de nouvelle table etc... donc gestion plus lourde ) alors que la réplication par WALL par exemple, semble bien plus simple à gérer ...
Quelle est la solution la plus fiable ?
Hors ligne
Les deux sont fiables.
En règle général, j'utiliserais plutôt la réplication interne de PostgreSQL (streaming replication). Sauf dans un cas : si j'ai besoin de créer des objets sur l'esclave. Ce point est intéressant si le deuxième serveur sert pour la génération de rapports. Dans ce cas, il est important de pouvoir ajouter des index spécifiques pour la génération des rapports et de pouvoir créer des tables (temporaires ou non) de travail. Mais sinon, dans tous les autres cas, la réplication interne est préférable car plus rapide à mettre en place.
Guillaume.
Hors ligne
Slony permet également de la réplication sélective, sur un ou plusieurs serveurs ce qui peut parfois être intéressant.
Julien.
https://rjuju.github.io/
Hors ligne
Merci Gleu...
qu'appelez-vous 'génération de rapports' ? Sont-ce par exemple, des rapports genre BO qui donnent des références croisées sur des données... qui seraient lancées sur le serveur esclave afin de ne pas trop surcharger le serveur maître...
Hein ?
PS : Je n'ai toujours pas vu la mode d'emploi pour faire de la réplication par WALL... a contrario de la réplication 'log Shipping' qui est très bien documentée ...
Hors ligne
Rjuju...
Sur la réplication sélective : Est-ce une réplication des tablesA sur le serveur A et des tablesB sur le serveurB en sachant que TablesA et tablesB sont sur le serveur Maitre (Même database) et que la réplication se découpe sur deux serveurs esclaves avec deux moitié de databases ?
Si c'est cela, à quoi ça sert ?
Hors ligne
Oui c'est cela, à part que ce n'est pas forcément la même database. Ca permet d'avoir des serveurs esclaves avec moins d'espace disque et de ne répliquer qu'une partie des données par exemple, ou d'avoir un serveur avec des disques plus rapides pour une table très fortement sollicitée ou ce genre de choses.
Cela permet également de ne répliquer qu'une seule database, ce qui n'est pas possible via la réplication intégrée à postgresql.
Julien.
https://rjuju.github.io/
Hors ligne
Sont-ce par exemple, des rapports genre BO qui donnent des références croisées sur des données... qui seraient lancées sur le serveur esclave afin de ne pas trop surcharger le serveur maître...
Exact. BO utilise généralement des tables de travail pour générer des rapports. Il peut aussi avoir besoin d'index spécifique pour les générer rapidement. Dans ce cas, il faut que le serveur esclave accepte la création d'objets, ce que permet Slony mais pas la réplication interne de PostgreSQL.
Je n'ai toujours pas vu la mode d'emploi pour faire de la réplication par WALL... a contrario de la réplication 'log Shipping' qui est très bien documentée ...
Hmmmm, c'est la même chose Le log shipping, c'est l'envoi des WAL (journaux de transactions) du maître vers l'esclave. Le streaming replication, c'est l'envoi de partie de WAL plutôt que de WAL complet, ce qui permet un lag moindre entre les deux serveurs (je simplifie beaucoup, mais c'est ça).
Guillaume.
Hors ligne
Bonjour à tous...
Oui, les wall sont bien les journaux de transaction (comme les redo d'oracle !)... mais j'avais cru comprendre que le 'log shipping' était l'envoi des archives(log) entre deux serveurs (donc avant que les wall se ré-écrasent, archivage de ceux-ci dans fichier afin d'en conserver la trace et de les ré-appliquer en cas de catastrophe !)... mais j'ai du mal lire la chose...
Ok donc pour les walls qui se partagent entre deux serveurs...
Hors ligne
