Vous n'êtes pas identifié(e).
Pages : 1
Bonjour
Comme convenu j'ai installé une version slony 2.0.6
Et je me suis rendue compte aussi qu'une de mes bases esclave avait perdu toutes ses contraintes clés etc ... étonnant ....
Donc j'ai rétabli son schéma
et j'ai enfin pu mettre en place ma réplication à 3 ! Et ça marche ! Yes !!
J'ai eu un souci pour installer slony 2.0.6
En effet sur des environnements redhat le configure de slony demandait de compiler postgresql avec l'option enable-thread-safety mais ne prenait pas en compte cette nouvelle compilation donc impossible de réaliser uneconfigure de slony sur redhat , j'ai détourné le problème en faisant une compilation de postgresql avec enable-threéad-safety sur centos et en récupérant la librairie libpq.so ..
Je ne suis pas très fière de moi mais je n'ai pas trouvé autre chose pour faire aboutir mes installations de slony 2.0.6 sur redhat ...
Mon problème de réplication est résolu , c'est déjà ça !!
Maintenant il faudrait que je trouve une installation de slony 2.0.6 un peu plus académique pour la suite ....
A suivre ....
Bonjour,
Merci pour cet exemple que j'ai reporté sur mes environnements et qui fonctionne .. super !
Donc ce n'est peut être pas slony qui est en tort ..
Par contre, malgré tout je ne vois pas où je me suis trompée dans mon environnement réel ..
quelques 130 tables numérotées de 1 à 130 et 30 séquences numérotées de 1 à 30.
De toute façon ma configuration fonctionne déjà entre un maitre et un esclave donc ce ne devrait pas être la numérotation des séquences qui est en cause .
mais j'ai des tables partitionnées qui possèdent des séquences ....
Je vais écouter vos conseils et migrer en slony 2.0.6 et réflèchir éventuellement plus tard aux numérotations.
Encore merci !
Je vais suivre votre conseil car j'ai l'impression que ce fonctionnement n'est pas normal
- mes étapes
cluster name =replication;
node 1 admin conninfo = 'dbname=bdt host=machine1 user=postgres port=';
node 2 admin conninfo = 'dbname=bdt host=machine2 user=postgres port=';
node 3 admin conninfo = 'dbname=bdtr host=machine3 user=postgres port=';
init cluster ( id=1, comment = 'Master Node');
set add table (set id=1, origin=1, id=1, fully qualified name = 'bd.table1', comment='table table1');
....
create set (id=2, origin=1, comment='bdt');
set add table (set id=2, origin=1, id=10001
set add sequence (set id=1, origin=1, id=1,
.......
store node (id=2, comment = 'Slave node ', event node=1);
store node (id=3, comment = 'Slave node replication', event node=1);
store path (server = 1, client = 2, conninfo='dbname=bdtrprod host=machine1 user=postgres port=');
store path (server = 2, client = 1, conninfo='dbname=bdtrprod host=machine2 user=postgres port=');
store path (server = 1, client = 3, conninfo='dbname=bdtrprod host=machine1 user=postgres port=');
store path (server = 3, client = 1, conninfo='dbname=bdtrprod host=machine3 user=postgres port=');
store listen (origin=1, provider = 1, receiver =2);
store listen (origin=2, provider = 2, receiver =1);
store listen (origin=1, provider = 1, receiver =3);
store listen (origin=3, provider = 3, receiver =1);
conf spécifique du maitre , le reste est en commentaire
pid_file='/var/bd/run/pidreplicationNode1.pid'
cluster_name='replication'
conn_info='dbname=bdt host=machine1 .....
desired_sync_time=60000
conf des esclaves est la même aux chaines de connexion prés.
dans le fichier de démarrage :
CLUSTERS="replication"
prog="bd-slon-3"
CONFIGFILE=$SLHOME/${CLUSTERS}-node${NODENUM}.conf
LOGFILE=$LOGHOME/${CLUSTERS}-node${NODENUM}.log
rien d'exceptionnel ...
Merci pour votre réponse rapide et pour l'astuce !
En fait, les id dans mon deuxième set sont différents et donc corrects ; à vrai dire pour mon test , dans le 2 eme set je n'ai qu'une table sans séquence ..
les instructions 'set add sequence' qui font partie du set commun ne fonctionne que sur un esclave pas sur l'autre .
en effet sur le 2eme esclave, l'erreur de mon premier message est renvoyée.
"select "_replication2".setAddSequence_int(1, 1, '"article"."obs_kobs_seq"', 'table obs_kobs_seq')" PG
RES_FATAL_ERROR ERROR: Slony-I: setAddSequence_int(): sequence ID 1 has already been assigned
En regardant la doc effectivement les séquences ne doivent être déclarées qu'une fois ..
mais comment dois je faire ?
J'ai l'impression de passer à coté de quelque chose d'essentiel mais quoi ...?
(mes versions postgresql 8.3.8 slony 2.0.2
Bonjour
j'ai une réplication avec 1 maitre 1 esclave ( déclaration des tables et des séquences avec add séquence en particulier ) cela fonctionne trés bien
Je souhaite rajouter un autre esclave sur le maitre qui comprendra moins de tables répliquées .
Comment dois je faire ?
- 1 cluster ou 2 clusters sur le maitre (j'ai testé les2 mais j'ai le même problème)
- si j'ai bien compris pour le cas 1 cluster ; faire 2 sets 1 avec la partie commune aux 2 esclaves et l'autre avec le reste
Mon souci a lieu avec les séquences quand la synchronisation arrive , j'obtiens l'erreur
"select "_replication2".setAddSequence_int(1, 1, '"article"."obs_kobs_seq"', 'table obs_kobs_seq')" PG
RES_FATAL_ERROR ERROR: Slony-I: setAddSequence_int(): sequence ID 1 has already been assigned
En regardant la doc effectivement les séquences ne doivent être déclarées qu'une fois ..
mais comment dois je faire ?
J'ai l'impression de passer à coté de quelque chose d'essentiel mais quoi ...?
les différentes étapes que je suis
cas 1 cluster :
déclaration de 3 nœuds
création de 2 sets avec affectation des tables et séquences : set add table et sequence
enregistrement des nœuds 2 et 3 en esclave store node (id=2 ..) et store node (id=3 ..)
les store path
store path (server = 1, client = 2, conninfo=
store path (server = 2, client = 1,
store path (server = 1, client = 3,
store path (server = 3, client = 1,
les store listen
store listen (origin=1, provider = 1, receiver =2);
store listen (origin=2, provider = 2, receiver =1);
store listen (origin=1, provider = 1, receiver =3);
store listen (origin=3, provider = 3, receiver =1);
les souscriptions
subscribe set (id = 1, provider = 1, receiver = 2, forward = no);
subscribe set (id = 1, provider = 1, receiver = 3, forward = no);
subscribe set (id = 2, provider = 1, receiver = 2, forward = no);
Qu'en pensez vous ?
Pages : 1
