Vous n'êtes pas identifié(e).
Bonjour,
Dans l'application que je développe, j'ai une base de données qui contient la position de plusieurs utilisateurs .
Et j'ai aussi dans cette base de données, une table qui va etre souvent utilisé. C'est une table dédié aux traitement des événements.
Donc je voulais savoir si utiliser postgres9 + pgpool etait une solution sure ? Car je ne peux pas me permettre de perdre des données.
J'aimerais avoir votre avis sur le sujet.
Merci,
Hors ligne
Oui, c'est une solution sûre. J'avoue que je ne vois pas trop à quoi vous pouviez vous attendre d'autres comme réponse sur ce forum 
Peut-être que si vous détaillez votre soucis, on pourrait plus vous aider.
Guillaume.
Hors ligne
Effectivement. Dans ce contexte, on a deux facons de faire de la réplication :
- Via pgpool: c'est synchrone, il envoie les mêmes ordres SQL sur les deux bases, en convertissant ce qui peut l'être. Il faut donc bien lire la doc et éviter les quelques écueils, et accepter les pertes de performances (verrouillages plus importants, pour assurer de générer les mêmes identifiants sur les deux bases, par exemple).
- Via la réplication native postgres: c'est asynchrone. Il y a donc le risque de perdre des données. On parle d'une perte de l'ordre de la seconde, avec le paramétrage par défaut. Ça dépend donc de ce qui est acceptable.
Tout de même, pour être raisonnablement complet, ne pas perdre de vue qu'il existe aussi des systèmes au niveau de l'infrastructure : réplication entre baies disques (sur un SAN par exemple), drbd, ou autre solution similaire. Elles méritent d'être considérées aussi à mon avis.
Pour bien vous aiguiller, nous avons donc surtout besoin de la définition de 'ne pas se permettre de perdre des données'. On peut difficilement avoir à la fois synchrone, rapide, et pas cher
Marc.
Hors ligne
j'ai lu aussi que pgpool II, supporte le streaming replication utilisé par postgres9 .
http://pgpool.projects.postgresql.org/p … leshooting
" pgpool-II could work with Streaming Replication, which has been usable since PostgreSQL 9.0"
je voulais savoir si il est conseillé d'utiliser la version 9 ? ou vaut il mieux passer à la 8.4 ?
car je vois que la v9 a encore reçus des updates.
l'objectif, c'est qu'on est deux serveur, mais pas du tout situé au même endroit.
Je trouve que pgpool-II, répond bien a mes attentes, mais je n'ai pas l’expérience que certain ont ici, donc je voulais avoir votre avis.
N' y aurait-il pas des risques de conflit ? lecture/ecriture, ou autre ?
Merci pour vos réponses,
Hors ligne
La version 9 reçoit des correctifs, bien sûr. La 8.4 aussi, la 8.3 aussi. Etc. Toutes les versions stables reçoivent des correctifs, chacune pendant cinq ans environ. Heureusement. Il n'y a pas de programmes sans bugs. Donc tout ça pour dire, « Vous avez un nouveau projet avec PostgreSQL ? utiliser la 9.0. »
Pour les risques de conflit, entre quoi et quoi ?
Guillaume.
Hors ligne
merci,
Sinon je voulais vous poser une question d'architecture.
J'ai prévue dans mon architecture, 3 serveurs.
Le premier permet d'héberger les pages web ( php, html, etc ) ( serveur ubuntu 10.04 )
Le deuxième ( Maitre ), c'est un serveur qui a postgresql 9, et tomcat. Il est le serveur maitre. pgpool est installé dessus.
Le troisieme ( esclave ), c'est un serveur qui a postgresql 9, et tomcat. Il est le serveur esclave, pgpool est installé dessus ?
J'ai donc une application web, qui manipule la base de données.
Une application java qui traite ces données.
Je souhaite que la sécurité soit au maximum. donc pgpool duplique la base de données du serveur 1 vers le serveur 2( peut etre aussi du loadbalancing ).
le serveur 2 prend la main si le serveur 1 tombe en panne.
Je me demande déjà si le serveur d'administration peut se connecter au serveur ( maitre ) ? Est ce que je dois installer aussi pgpool dessus ?
C'est un peu flou pour moi,
Hors ligne
Il serait mieux d'installer le pgpool sur le premier serveur. Comme ça, lorsqu'un des deux serveurs PostgreSQL s'arrête (correctement ou pas), pgpool peut rediriger vers le bon serveur.
J'en profite pour vous dire qu'il y aura des conférences à Paris le 3 février sur la réplication interne de PostgreSQL. De plus, Tatsuo Ishii et un de ces collègues seront là. Ce sont les développeurs principaux de pgpool, ils pourront facilement répondre à vos questions. Il est même possible que Tatsuo donne une conférence. Vous trouverez plus d'informations sur http://www.postgresql-sessions.org/.
Guillaume.
Hors ligne
Oui ca serait bien, mais que faire si le serveur 1 tombe en panne ?
Sinon je vais grandement réfléchir à y aller à cette conférence.
Merci,
Hors ligne
D'après votre description, c'est le seul serveur à avoir le site web. Donc, de toute façon, s'il tombe, c'est tout le site web qui tombe.
Pour la conférence, oui, si vous êtes en région parisienne, c'est très intéressant. C'est complètement gratuit. Par contre, il faut s'enregistrer.
Guillaume.
Hors ligne
J'ai oublié de donner quelque informations supplémentaire.
Le serveur maitre ( et esclave ) héberge aussi un serveur TCP/IP, c'est cette partie qui est la plus importante.
Si le serveur maitre tombe en panne, le serveur "esclave" prend la main, et d'apres les informations qu'il a en base de données, continue le traitement.
J'avais donc pensé à installer pgpool sur le serveur Maitre.
Hors ligne
Vous voulez dire HTTP ? pas TCP/IP ?
Guillaume.
Hors ligne
Je voulais dire des sockets 
Dernière modification par mickaeL (24/01/2011 15:28:59)
Hors ligne
Ce qui ne veut rien dire de plus.
Guillaume.
Hors ligne
TCP/IP :S
J'ai un serveur qui doit dialoguer avec des appareils, via une connection TCP/IP. DOnc j'ai un serveur de socket.
Dernière modification par mickaeL (24/01/2011 15:54:22)
Hors ligne
Ce que le monsieur veut te dire, gleu, c'est que c'est un protocole qui n'est pas ton problème, genre un serveur de carte bancaire, par exemple
Marc.
Hors ligne
Donc on va dire qu'il s'agit d'un autre serveur que le serveur HTTP, soit. Bref, faut aussi pgpool sur le serveur 2 à moins de vouloir fonctionner en mode dégradé.
Guillaume.
Hors ligne
re,
Merci pour vos réponses,
Donc je peux avoir cette architecture ? :
Serveur Master: Serveur Slave :
- PostgreSQL 9 A - PostgreSQL 9 B
- PgPool A - Pgpool B
- TomCat Application A - TomCat Application B
Scenario de base:
Le serveur Master fonctionne bien, l'application A qui est sur ce serveur, fait des requetes ( insert/update/delete ) sur pgpool A.
Les bases de données A & B sont bien synchroniser.
La base de données B est bien utilisé pour faire du loadbalancing.
Scenario catastrophique :
Cas 1:
La bdd A, tombe en panne:
- la bdd B sera utilisé non ?
Cas 2:
L'application A tombe en panne, l'application B le détecte et prend la main. Donc elle utilise pgpool A non ?
Cas 3:
Le serveur Master tombe en panne, Qu'est ce qu'il se passe ?
C'est assez floue tous ca pour moi 
Dernière modification par mickaeL (08/02/2011 12:59:05)
Hors ligne
Je ne me suis peut etre pas assez bien exprimé :
Master Server : A Slave Server : B
- PostgreSQL 9 A - PostgreSQL 9 B
- PgPool A - Pgpool B
- TomCat Application A - TomCat Application B
cas normal :
l'Application A utilise Pgpool A pour les insert/update/detele.
La database B peut etre utilisé pour faire du loadbalancing.
Autre cas :
Le serveur maitre tombe en panne:
Comment je peux le détecter ? est il possible d'utiliser pgpoolB avec cette configuration : ( server B est le maitre et le serveur A est l'esclave ? ).
J'avais pensé à ca:
L’application B détecte que l'application A ne répond plus.
L'application B prend le contrôle, et utilise Pgpool B pour les insert/delete/update.
Quand le serveur A revient en ligne, il détecte que maintenant il est l'esclave.
PgPool B détecte que la base de donnée A est en ligne, et fait une synchronisation de la base de donnée B vers A.
C'est possible ?
Hors ligne
Les deux bases sont synchronisées comment ?
Cas 1: oui, si vous utilisez la streaming replication (le script de failover permet de basculer sur le deuxième serveur).
Cas 2: oui et non. Je veux dire par là que vous pouvez le faire, que rien ne l'oblige, que rien ne le conseille non plus.
Cas 3: il ne se passe rien.
Guillaume.
Hors ligne
