Vous n'êtes pas identifié(e).
Bonjour,
Je voulais savoir si la version 9 de PGsql savait faire de la réplication dans les 2 sens suivant les bases ?
Je m'explique par un petit schéma :
Nous avons 3 serveurs A,B, et C
A replique la base génarale sur B
B réplique la base générale sur C
C réplique sa base locale sur B
on se retrouve donc sur A avec une base BG, sur B avec BG et LO(réplique) et C avec BG(replique) et LO
en théorie c'est simple, mais mysql ne sait pas faire, donc je me tourne sur PGsql.
Si pgsql 9 ne sait pas faire est ce qu'en me tournant sur slony ça passera ?
Merci de votre aide.
ps : je suis un débutant PGsql...
Hors ligne
Non, la réplication se fait sur l'ensemble du cluster. Si vous voulez avoir des réplications dans plusieurs directions, il vous faut plusieurs clusters. Ça restera largement plus simple d'administration que de faire du slony, et moins gourmand en ressources, la réplication de la 9.0 étant beaucoup plus économique (pas de trigger?).
Marc.
Hors ligne
merci pour la réponse en tout cas.
Je vais déjà bien me pencher sur la doc du PGsql 9 et cette gestion de cluster.
Dernière modification par kenrio (09/11/2010 14:40:00)
Hors ligne
De ce que je lis la streaming replication ne sais faire que du master vers multi slaves! et on ne peut pas gérer à la base ou je me trompe ?
Ou faut il jouer avec les roles ?
Hors ligne
Oui, comme dit plus haut. La SR est pour l'ensemble du cluster, pas par base. Ceci parce qu'elle s'appuie sur les journaux de transactions, qui sont globaux au cluster. Mais rien ne vous empêche d'avoir 10 clusters sur une même machine, avec chacun son sens de réplication.
Marc.
Hors ligne
Ok merci, je vias mettre ça en route on verra ce que ça donne.
Hors ligne
Bonjour,
juste pour vous dire qu'en faites je laisse tomber la réplication par postgresql 9 car pour faire ce que je dois faire la multiplication des clusters sera à terme trop consommatrice de ressources.
Je me tourne donc vers slony.
Je testerais par quelque chose de ( j'espère) simple : A et B vers C ( une sorte d'entonoir que je compliquerais ds le futur).
Hors ligne
'Trop consommatrice de ressource' ?
L'avez vous vérifié avant de l'affirmer ?
Marc.
Hors ligne
Disons que j'aurais une vingtaine de serveurs qui remonterons leurs données aux masters, donc une vingtaine de clusters, n'ayant pas de machoine sur puissante je pense pas que ça soit bon.
De plus slony me permet de faire de la ganularité base bien d'une meilleure façon même si ça reste compliqué pour l'instant.
et un truc qui me chagrine énormément, j'ai lu que ds la réplication psql9 on ne peut pas ou plutot c'est énormément déconseillé d'avoir des versions de pgsql différentes, hors comment je mets à jour 20 serveurs en même temps ?
avec slony j'ai pas ce problème au moins je pense.
Hors ligne
Personne ne vous oblige à avoir autant de clusters que de bases. Il vous faut un cluster maître par serveur physique, c'est tout.
Pour ce qui est des mises à jour, c'est un choix à faire entre :
- être embêté quand on fait une mise à jour de moteur (un peu embêté, ce n'est pas vraiment la mort non plus, surtout sous Unix, où on peut mettre les binaires à jour, puis redémarrer l'ensemble, ce qui prend quelques secondes)
- être embêté dès qu'on fait la moindre modification de schéma
Après, libre à vous effectivement d'utiliser slony, mais je pense que sa complexité le réserve à des cas vraiment insolubles sans lui.
Marc.
Hors ligne
de toute façon je fais une archi taille réduite de ce que je veux avec des vms.
Je verrais bien si j'y arrive ou pas 
Hors ligne
Je continue ici mais en fait j'ai une question à propos de slony, comment je peux démarrer 2 slon en même temps sur la meme machine sans faire une erreur de duplication de clef ?
Hors ligne
J'avoue que je ne comprend pas la question. De quelle duplication parlez-vous ?
Guillaume.
Hors ligne
Bonjour,
J'ai du mal m'exprimer.
Mais en fait quand je lançais les commandes de démarrage de réplication : slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST"
je me retrouvais avec une erreur comme quoi j'avais une clef dupliquée.
Mais j'ai refait mon ma seconde répli et en relançant les démons je n'ai pas rencontré de nouveau cette erreur.
J4ai au final réussi à faire ce que je voulais mais ça me semble un peu "bordélique" 
Hors ligne
J4ai au final réussi à faire ce que je voulais mais ça me semble un peu "bordélique"
C'est le deuxième effet kisskool, avec slony
Dernière modification par Marc Cousin (16/11/2010 11:00:56)
Marc.
Hors ligne
disons que ce qui me gène c'est les différentes méthodes pour parvenir à ce que je veux faire.
J'ai suivis la doc de slony mais pour faire ce que je voulais j'ai pas capté si je devais utiliser les outils secondaires ou me faire un fichier de conf a chaque fois et lancé un slon différent tt le temps.
mais bon c'est un bon outils je vais pas le maitriser en 2 jours.... 
Hors ligne
Bonjour,
Concernant Slony, vous pouvez utiliser des outils tiers d'administration, comme slony-ctl (http://slony1-ctl.projects.postgresql.org/).
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
Merci, en fait j'ai pour l'instant utilisé la doc de slony et l'article de dalibo, en mélangeant le tout j'arrive a tout faire.
Mais je vais voir avec ces outils si j'arrive a rendre la gestion plus simple.
Le seul hic que j'ai pour l'instant c'est des baisses de performance mais je pense que mes vms mettent mon portable à genoux ^^
Ensuite pour la visualisation j'utilise pgadmin3 qui me permet d' avoir une vue plus concrete. .
Hors ligne
Bonjour,
je reviens vers vous car j'ai mis en place les scripts slony-ctl mais maintenant je comprend plus trop comment sont gérés les processus slon sur les machines slaves.
Car désormais si je fais une coupure réseau la machine slave ne rattrape plus son retard, sauf si je lance sur le master le script slony-ctl.sh avec restart.
ça m'intrigue ^^
Bon en fait après coupure réseau il reprend bien c'est quand je mets en pause mes vms...
Dernière modification par kenrio (25/11/2010 12:40:31)
Hors ligne
slony_ctl ne change rien au travail du slon. Il les démarre et/ou arrête avec son script de démarrage mais cela s'arrête là. Le gros avantage de slony_ctl est une plus grande facilité de gestion des noeuds.
Guillaume.
Hors ligne
slony_ctl ne change rien au travail du slon. Il les démarre et/ou arrête avec son script de démarrage mais cela s'arrête là. Le gros avantage de slony_ctl est une plus grande facilité de gestion des noeuds.
en gros le script qu'on lançait sur le slave, celui là ( slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSER host=$SLAVEHOST" ) c'est désormais le master qui le lance a distance exact ?
Hors ligne
Les démons slon peuvent être lancés sur le maître et les esclaves ou alors sur un seul serveur. Ça n'a pas d'importance. De mon souvenir des scripts slony_ctl, il faut le lancer sur les deux.
Guillaume.
Hors ligne
bah là j'ai fais sur un de mes esclaves la repli d' une base vers un master et juste avec les outils ctl et j'ai rien eu a toucher au niveau des processus slon sur le master ( devenu esclave pour cette base )...
je vais voir ça de plus pret quand meme ^^
Hors ligne
j'ai trouvé ça doit etre du à mon installation, car j'installe slony par yum sur chaque serveur, donc le slon est lancé par defaut.
Sinon j'ai un soucis j'ai beau changer le temps de synchro ds le fichier de conf de slony-ctl mais il ne le prend pas en compte....
y aurait un fichier a relancer ?
Hors ligne
rebonjour,
J'ai réussi à faire de la répli inter schema dans les 2 sens dans une seule bd, mais bizarrement je n'arrive pas à rajouter une table ensuite, l'erreur me dit que je ne peux pas car je duplique une clef...
Donc le set 99 ne se fait pas donc merge pas..... :s c'est parce que les table sont en lecture seule ?
Est ce que quelqu'un à déjà eu ce problème ?
Dernière modification par kenrio (03/12/2010 19:16:31)
Hors ligne
