Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

160 lines (134 sloc) 6.076 kb
<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="subscribenodes">
<title>Enregistrement des serveurs</title>
<indexterm><primary>Enregistrement des serveurs</primary></indexterm>
<para>
Avant d'enregistrer un serveur à un ensemble, assurez-vous d'avoir un
processus <xref linkend="slon"/> pour chacune des deux parties à savoir le
fournisseur et pour le nouveau n&oelig;ud de souscription. Si les démons slon
respectifs ne sont pas en cours d'exécution, alors il ne se passera rien et
vous vous éverturez à comprendre pourquoi cela ne fonctionne pas.
</para>
<para>
Ajouter un serveur à un ensemble de serveurs est fait en exécutant la commande
<xref linkend="stmtsubscribeset"/> de <xref linkend="slonik"/> . Il peut
sembler tentant d'essayer de souscrire plusieurs n&oelig;uds à un ensemble
dans un bloc d'essai simple comme celui-ci&nbsp;:
<programlisting>
try {
echo 'Subscribing sets';
subscrifbe set (id = 1, provider=1, receiver=2, forward=yes);
subscribe set (id = 1, provider=1, receiver=3, forward=yes);
subscribe set (id = 1, provider=1, receiver=4, forward=yes);
} on error {
echo 'Enregistrement du jeu des serveurs : impossible!';
exit -1;
}
</programlisting>
</para>
<para>
Mais vous êtes juste en train de vous demander quel est le souci en
enregistrant les ensembles de serveurs de cette façon. La méthode
appropriée exige de procéder à l'enregistrement des serveurs, à raison
d'un seul à la fois, tout en examinant le journal de l'instance de la
base de donnée, avant de vous occuper du prochain enregistrement. Il est
également intéressant de noter que le <quote>succès</quote> dans l'essai
<xref linkend="slonik"/> ci-dessus, n'implique pas que les n&oelig;uds 2,
3, et 4 soient tous enregistrés avec succès. Il indique simplement que les
commandes de slonik ont été reçues avec succès le démon
<application>slon</application> fonctionnant sur le n&oelig;ud d'origine.
</para>
<para>
Un cas typique de problème pouvant surgir est qu'un abonné en cascade,
recherche un fournisseur qui n'est pas encore prêt. Dans ce cas d'échec, le
n&oelig;ud souscripteur ne deviendra <emphasis>jamais</emphasis> l'abonné.
Il sera <quote>bloquée</quote> en attente d'un évènement déjà survenu.
Les autres n&oelig;uds seront persuadés que, ce n&oelig;ud bloqué s'est
enregistré correctement (parce qu'aucune erreur ne leur est parvenu)&nbsp;;
la demande pour désabonner le n&oelig;ud sera <quote>bloqué</quote> car le
n&oelig;ud en question est coincé en attente d'enregistrement.
</para>
<para>
Lorsque vous enregistrez un n&oelig;ud à un ensemble de n&oelig;uds, vous
devez voir quelque chose de ce genre dans les traces du démon
<application>slon</application> pour le n&oelig;ud fournisseur&nbsp;:
<screen>
DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET
</screen>
</para>
<para>
Vous devriez également commencer à voir des messages de ce genre dans les
traces du démon <application>slon</application> pour le n&oelig;ud de
souscription&nbsp;:
<screen>
DEBUG2 remoteWorkerThread_1: copy table public.my_table
</screen>
</para>
<para>
La copie de grandes tables entre le n&oelig;ud de fournisseur et le nouvel
abonné peut prendre un certain temps. Si vous vérifiez la table
pg_stat_activity sur le n&oelig;ud du fournisseur, vous devriez voir une
requête qui copie la table vers stdout.
</para>
<para>
La table <envar>sl_subscribe</envar> pour le fournisseur comme pour le
nouveau souscripteur, doit contenir un enregistrement pour le nouveau
abonnement&nbsp;:
<screen>
sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
1 | 1 | 2 | t | t
</screen>
</para>
<para>
Un ultime test est d'insérer un enregistrement dans une des tables répliquées
depuis le n&oelig;ud d'origine, et de vérifier que cet enregistrement est bien
répliqué chez le souscripteur.
</para>
<warning>
<para>
Si vous créez et souscrivez à un ensemble de n&oelig;ud qui ne contient
aucune table, cela peut mener à une situation qui empêchera la réplication
de se faire.
</para>
<para>
Notez que ce bug est corrigé depuis la version 1.1.5.
</para>
<para>
Si un abonné particulier est seulement alimenté par une séquence d'ordre
d'un de ces fournisseurs, la requête qui collecte l'évènement
<command>SYNC</command> ne sera pas correctement créée, et vous pouvez
voir une erreur similaire celle-ci&nbsp;:
</para>
<screen>2007-04-13 07:11:28 PDT ERROR remoteWorkerThread_11: "declare LOG
cursor for select log_origin, log_xid, log_tableid, log_actionseq,
log_cmdtype, log_cmddata from "_T1".sl_log_1 where log_origin = 11 and
( order by log_actionseq; " PGRES_FATAL_ERROR ERROR: syntax error at
or near "order" at character 162</screen>
<para>
La fonction <xref
linkend="function.subscribeset-integer-integer-integer-boolean"/> va
générer un avertissement si un ensemble de réplication donné ne contient
aucune table à répliquer, comme l'exemple suivant le montre&nbsp;:
</para>
<screen>cbbrowne@dba2:/tmp> cat create_empty_set.slonik
cluster name = T1;
node 11 admin conninfo = 'dbname=slony_test1';
node 22 admin conninfo = 'dbname=slony_test2';
create set (id = 255, origin = 11, comment='blank empty set');
subscribe set (id=255, provider = 11, receiver = 22, forward = false);</screen>
<para>
Ceci mène au message d'avertissement suivant&nbsp;:
</para>
<screen>bbrowne@dba2:/tmp> slonik create_empty_set.slonik
create_empty_set.slonik:6: NOTICE: subscribeSet:: set 255 has no tables
- risk of problems - see bug 1226
create_empty_set.slonik:6: NOTICE:
http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226
cbbrowne@dba2:/tmp></screen>
</warning>
</sect1>
Jump to Line
Something went wrong with that request. Please try again.