Vous n'êtes pas identifié(e).
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 ?
Hors ligne
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
Exact.
Normalement, il faut déclarer 3 noeuds, et deux sets. Chaque set doit contenir des tables et séquences différentes. Il faut bien faire attention aux id de départ des tables et séquences. L'id ne doit pas être 1 car l'id 1 est certainement déjà utilisé par le set 1. L'id de départ pour le set 2 en ce qui concerne les tables doit correspondre au minimum au nombre de tables du set 1 + 1. Si vous n'avez pas envie de vous embêter il peut être plsu simple de dire que le set 1 commence à l'id 1 et le set 2 commence à l'id 10000 (ce n'est qu'un exemple). Ça devrait corriger le problème du message d'erreur que vous indiquez. Le noeud maître des deux sets est le même. Par contre, vous devez abonner un des noeuds esclaves aux deux sets et l'autre qu'au set commun.
À priori, ça devrait fonctionner sans aucun problème.
Guillaume.
Hors ligne
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
Hors ligne
Je vous conseille très vivement de passer à la version 2.0.6, les anciennes versions 2.0 étaient suffisamment buggées pour que même l'équipe de développement de Slony indique de ne pas les utiliser en production.
Pouvez-vous nous donner les étapes exactes que vous réalisez ? ainsi que la config ?
Guillaume.
Hors ligne
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 ...
Hors ligne
Vous n'en mettez que des bouts, il est donc difficile de savoir vraiment d'où vient le problème. J'ai fait un test de mon côté. J'ai créé trois bases (isadb1, isadb2 et isadb3). J'ai le schéma suivant sur ses trois bases :
CREATE PROCEDURAL LANGUAGE plpgsql;
CREATE TABLE t1 (
c1 serial PRIMARY KEY,
c2 text
);
CREATE TABLE t2 (
c1 serial PRIMARY KEY,
c2 boolean,
c3 text
);
CREATE TABLE t3 (
c1 integer PRIMARY KEY,
c2 integer
);Trois tables, toutes avec des clés primaires, les deux premières ont des colonnes auto-incrémentés pour que des séquences soient associées.
Ensuite, j'ai écrit la configuration suivante pour Slony :
if ($ENV{"SLONYNODES"}) {
require $ENV{"SLONYNODES"};
} else {
# Parameters
$CLUSTER_NAME = 'replication';
$LOGDIR = '/opt/slony-2.0/var/log/slony1';
$MASTERNODE = 1;
$DEBUGLEVEL = 2;
# Nodes
add_node(node => 1,
host => 'localhost',
dbname => 'isadb1',
port => 5432,
user => 'guillaume',
password => '');
add_node(node => 2,
host => 'localhost',
dbname => 'isadb2',
port => 5432,
user => 'guillaume',
password => '');
add_node(node => 3,
host => 'localhost',
dbname => 'isadb3',
port => 5432,
user => 'guillaume',
password => '');
}
$SLONY_SETS = {
# Set commun
"set1" => {
"set_id" => 1,
"origin" => 1,
"table_id" => 1,
"sequence_id" => 1,
"pkeyedtables" => [
"public.t1",
"public.t2",
],
"sequences" => [
"t1_c1_seq",
"t2_c1_seq",
],
},
# Set supplementaire
"set2" => {
"set_id" => 2,
"origin" => 1,
"table_id" => 10,
"sequence_id" => 10,
"pkeyedtables" => [
"public.t3",
],
"sequences" => [
],
},
};
if ($ENV{"SLONYSET"}) {
require $ENV{"SLONYSET"};
}
# Please do not add or change anything below this point.
1;Je vais donc avoir mes trois noeuds (un noeud pour chaque base) et deux sets (le premier avec les tables t1 et t2, et le deuxième set avec la table t3. Avec les scripts altperl, ça me donne ceci :
[guillaume@laptop bin]$ ./slonik_init_cluster --config ../etc/slon_tools.isadb.conf | ./slonik
<stdin>:12: Set up replication nodes
<stdin>:15: Next: configure paths for each node/origin
<stdin>:22: Replication nodes prepared
<stdin>:23: Please start a slon replication daemon for each node
[guillaume@laptop bin]$ ./slonik_create_set --config ../etc/slon_tools.isadb.conf 1 | ./slonik
<stdin>:17: Subscription set 1 created
<stdin>:18: Adding tables to the subscription set
<stdin>:22: Add primary keyed table public.t1
<stdin>:26: Add primary keyed table public.t2
<stdin>:29: Adding sequences to the subscription set
<stdin>:33: Add sequence public.t1_c1_seq
<stdin>:37: Add sequence public.t2_c1_seq
<stdin>:38: All tables added
[guillaume@laptop bin]$ ./slonik_create_set --config ../etc/slon_tools.isadb.conf 2 | ./slonik
<stdin>:17: Subscription set 2 created
<stdin>:18: Adding tables to the subscription set
<stdin>:22: Add primary keyed table public.t3
<stdin>:25: Adding sequences to the subscription set
<stdin>:26: All tables added
[guillaume@laptop bin]$ ./slonik_subscribe_set --config ../etc/slon_tools.isadb.conf 1 2 | ./slonik
<stdin>:11: Subscribed nodes to set 1
[guillaume@laptop bin]$ ./slonik_subscribe_set --config ../etc/slon_tools.isadb.conf 2 2 | ./slonik
<stdin>:11: Subscribed nodes to set 2
[guillaume@laptop bin]$ ./slonik_subscribe_set --config ../etc/slon_tools.isadb.conf 1 3 | ./slonik
<stdin>:11: Subscribed nodes to set 1Autrement dit, tout se passe comme on pouvait s'y attendre. Je n'ai pas d'erreur dans mon cas. Il doit donc y avoir un soucis avec votre configuration.
Guillaume.
Hors ligne
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 !
Hors ligne
Bonjour,
Dans votre exemple, vous n'indiquez pas le moment où vous effectuez les souscriptions.
Petite précision, le store listen n'est plus nécessaire. Il est induit par le store path depuis la version 1.2 de slony.
Si vous nous donnez l'intégralité de votre script, nous pourrons éventuellement vous aider à comprendre à quel endroit se situe la difficultée que vous rencontrez.
Pour finir, je vous conseille de regarder les outils d'aide à l'administration de Slony, scripts perl ou slony1-ctl. Ils simplifient grandement la gestion des réplications Slony.
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne
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 ....
Hors ligne
Bonjour,
Il existe des paquets RPM de Slony pour RedHat.
Vous pouvez jeter un oeil sur le site http://yum.pgrpms.org.
Stéphane Schildknecht
Conseil, formations et support PostgreSQL
http://www.loxodata.com
Hors ligne