Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
286 lines (249 sloc) 10.8 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="listenpaths">
<title>Voix d'écoute</title>
<indexterm><primary>voix d'écoute</primary></indexterm>
<note>
<para>
Si vous utilisez une version &slony1; 1.2 ou ultérieure, il est
<emphasis>complètement inutile</emphasis> de lire cette section car cette
version dispose d'une méthode de gestion automatique de cette partie de la
configuration. Pour les versions antérieures, cependant, ce qui va suivre
est nécessaire.
</para>
</note>
<para>
Si vous avez plus de deux ou trois n&oelig;uds et un niveau d'abonnement
en cascade (<emphasis>c'est-à-dire</emphasis> des n&oelig;uds qui s'abonnent
à des n&oelig;uds abonnés), vous devez être très prudent avec la configuration
des <quote>voix d'écoute</quote> par les commandes Slonik <xref
linkend="stmtstorelisten"/> et <xref linkend="stmtdroplisten"/> qui
contrôlent le contenu de la table <xref linkend="table.sl-listen"/>.
</para>
<para>
Les entrées de cette table contrôlent où chaque n&oelig;uds doit écouter afin
d'obtenir les événements propagés par les autres n&oelig;uds. Vous vous dîtes
peut-être que chaque n&oelig;ud doit simplement écouter le n&oelig;ud
<quote>parent</quote> qui leur transmet les mise à jours mais, en réalité,
ils doivent pouvoir recevoir des messages de la part de
<emphasis>tous</emphasis> les n&oelig;uds afin de pouvoir déterminer si les
<command>SYNC</command>s ont été reçues partout et que les entrées de
&sllog1; et &sllog2; ont été appliquées partout et qu'elles peuvent être
purgées. Ces communications supplémentaires permettent à
<productname>Slony-I</productname> de déplacer les origines vers d'autres
n&oelig;uds.
</para>
<sect2>
<title>Comment l'écoute peut être rompue</title>
<indexterm><primary>rupture d'écoute</primary></indexterm>
<para>
À une occasion, j'ai eu besoin de supprimer un n&oelig;ud abonné (#2) et de
la recréer. Ce n&oelig;ud était le fournisseur d'un autre abonné (#3) qui
était, de facto, un <quote>esclave en cascade</quote>. La suppression du
n&oelig;ud abonné ne fonctionna pas, en effet <xref linkend="slonik"/>
m'informa qu'il existait un n&oelig;ud dépendant. Je fis pointer le
n&oelig;ud dépendant vers le n&oelig;ud <quote>maître</quote> de
l'ensemble de réplication, ce qui se déroula, pour un temps, sans
difficultés.
</para>
<para>
Je supprimais alors l'abonnement du <quote>n&oelig;ud 2</quote>, et tentais
de l'abonner de nouveau. Cela déclencha un événement &slony1;
<command>set_subscription</command>, qui commença à copier les tables.
À ce moment, les événements ne furent plus propagés au <quote>n&oelig;ud
3</quote>, et tandis qu'il était en parfait état de fonctionnement, plus
aucun événement ne lui parvenait.
</para>
<para>
Le problème était que le n&oelig;ud #3 attendait de recevoir des événements
de la part du n&oelig;ud #2, qui était occupé par le traitement de
l'événement <command>set_subscription</command> et ne transmettait aucune
autre information.
</para>
<para>
Nous avons supprimé les règles qui ordonnaient au n&oelig;ud #3 d'écouter le
n&oelig;ud #2, en les remplaçant par des règles qui lui indiquaient d'attendre
les événements en provenance du n&oelig;ud #1 (le n&oelig;ud origine de la
réplication). À ce moment, <quote>comme par magie</quote>, le n&oelig;ud #3
recommença à répliquer car il avait découvert une source où écouter les
évènements <command>SYNC</command>.
</para>
</sect2>
<sect2>
<title>Comment configurer les écoutes</title>
<para>
Les cas simples sont facile à gérer. Intéressons-nous plutôt à une
configuration plus complexe.
</para>
<para>
Considérons un ensemble de n&oelig;uds, de 1 à 6, où 1 est l'origine, 2-4
sont abonnés directement à l'origine, 5 est abonné à 2, et 6 est abonné à
5.
</para>
<para>
Voici un <quote>réseau d'écoute</quote> qui montre où chaque n&oelig;ud doit
écouter les messages en provenance des autres n&oelig;uds&nbsp;:
<screen>
1| 2| 3| 4| 5| 6|
--------------------------------------------
1 0 2 3 4 2 2
2 1 0 1 1 5 5
3 1 1 0 1 1 1
4 1 1 1 0 1 1
5 2 2 2 2 0 6
6 5 5 5 5 5 0
</screen>
</para>
<para>
La ligne 2 indique toutes les règles d'écoute pour le n&oelig;ud 2&nbsp;;
il obtient les événements des n&oelig;uds 1, 3 et 4 chez le n&oelig;ud 1 et
il écoute sur le n&oelig;ud 5 les événements des n&oelig;uds 5 et 6.
</para>
<para>
La dernière ligne composée de 5, celle du n&oelig;ud 6, indique que le
n&oelig;ud 6 écoute le n&oelig;ud 5 pour obtenir les événements des
n&oelig;uds 1 à 5.
</para>
<para>
Les commandes slonik <command>set listen</command> qui expriment ce
<quote>réseau d'écoute</quote> sont les suivantes&nbsp;:
<programlisting>
store listen (origin = 1, receiver = 2, provider = 1);
store listen (origin = 1, receiver = 3, provider = 1);
store listen (origin = 1, receiver = 4, provider = 1);
store listen (origin = 1, receiver = 5, provider = 2);
store listen (origin = 1, receiver = 6, provider = 5);
store listen (origin = 2, receiver = 1, provider = 2);
store listen (origin = 2, receiver = 3, provider = 1);
store listen (origin = 2, receiver = 4, provider = 1);
store listen (origin = 2, receiver = 5, provider = 2);
store listen (origin = 2, receiver = 6, provider = 5);
store listen (origin = 3, receiver = 1, provider = 3);
store listen (origin = 3, receiver = 2, provider = 1);
store listen (origin = 3, receiver = 4, provider = 1);
store listen (origin = 3, receiver = 5, provider = 2);
store listen (origin = 3, receiver = 6, provider = 5);
store listen (origin = 4, receiver = 1, provider = 4);
store listen (origin = 4, receiver = 2, provider = 1);
store listen (origin = 4, receiver = 3, provider = 1);
store listen (origin = 4, receiver = 5, provider = 2);
store listen (origin = 4, receiver = 6, provider = 5);
store listen (origin = 5, receiver = 1, provider = 2);
store listen (origin = 5, receiver = 2, provider = 5);
store listen (origin = 5, receiver = 3, provider = 1);
store listen (origin = 5, receiver = 4, provider = 1);
store listen (origin = 5, receiver = 6, provider = 5);
store listen (origin = 6, receiver = 1, provider = 2);
store listen (origin = 6, receiver = 2, provider = 5);
store listen (origin = 6, receiver = 3, provider = 1);
store listen (origin = 6, receiver = 4, provider = 1);
store listen (origin = 6, receiver = 5, provider = 6);
</programlisting>
</para>
<para>
Ces lignes de commandes d'écoute sont lues lorsque...
</para>
<para>
... le n&oelig;ud <quote>récepteur</quote> cherche un n&oelig;ud
<quote>fournisseur</quote> pour obtenir les événements en provenance du
n&oelig;ud d'<quote>origine</quote>.
</para>
<para>
L'outil <filename>init_cluster</filename> parmi les scripts
<filename>altperl</filename> produit un réseau d'écoute optimisé sous forme
de tableau et ainsi qu'une liste de commandes <xref linkend="slonik"/>.
</para>
<para>
Il y a trois <quote>épines</quote> dans ce bouquet de roses&nbsp;:
<itemizedlist>
<listitem>
<para>
Si vous changez la structure de l'ensemble de n&oelig;uds, alors les
n&oelig;uds sont abonnés différemment et vous devez supprimer les
entrées de la table <xref linkend="table.sl-listen"/> et en créez de
nouvelles pour décrire les nouvelles voies d'écoute entre les
n&oelig;uds. Jusqu'à &slony1; 1.2, il n'y a aucune manière automatique
de réaliser cette <quote>restructuration</quote>.
</para>
</listitem>
<listitem>
<para>
Si vous <emphasis>ne changez pas</emphasis> les entrées de <xref
linkend="table.sl-listen"/>, les événements se propageront tant que les
n&oelig;uds fonctionnent correctement. Le problème se déclenchera
lorsqu'un n&oelig;ud sera retiré, rendant <quote>orphelin</quote> les
n&oelig;uds qui l'écoutaient.
</para>
</listitem>
<listitem>
<para>
Vous pouvez essayer de multiples ensembles de réplication qui ont des
structures <emphasis>différentes</emphasis> pour leur arborescence
d'abonnés. Il n'y aucune configuration d'écoute qui convienne
parfaitement dans ce cas.
</para>
</listitem>
<listitem>
<para>
Afin de créer une voie <xref linkend="table.sl-listen"/>, il
<emphasis>doit</emphasis> exister une série d'entrées <xref
linkend="table.sl-path"/> qui connectent l'origine au récepteur. Cela
implique que si le contenu de <xref linkend="table.sl-path"/> ne
définit pas que le réseau est <quote>connecté</quote> de n&oelig;uds,
alors certains n&oelig;uds ne seront pas accessibles. Typiquement, cela
peut se produire, lorsque vous avez deux ensembles de n&oelig;uds,
placés sur deux sous-réseaux séparés, avec simplement deux n&oelig;uds
<quote>pare-feu</quote> qui communiquent d'un sous-réseau à l'autre.
Couper un de ces n&oelig;uds et les sous-ensembles de réplication
s'arrêtent.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2 id="autolisten">
<title>Génération automatique de voie d'écoute</title>
<indexterm><primary>génération automatique de voie d'écoute </primary></indexterm>
<para>
Dans &slony1; version 1.1, une règle heuristique est introduite pour
générer automatiquement les entrées <envar>sl_listen</envar>.
Cela se fait en fonction de trois types d'informations&nbsp;:
<itemizedlist>
<listitem>
<para>
Les entrées de <xref linkend="table.sl-subscribe"/> sont des
informations primordiales et vitales sur qui doit écouter quoi&nbsp;;
nous <emphasis>savons</emphasis> qu'il doit y avoir une voie directe
entre chaque abonné et son fournisseur.
</para>
</listitem>
<listitem>
<para>
Les entrées <xref linkend="table.sl-path"/> sont le second
indicateur&nbsp;; si la table <xref linkend="table.sl-subscribe"/>
n'indique pas <quote>comment écouter</quote>, alors un n&oelig;ud
peut écouter directement l'origine s'il existe une voie praticable
dans <xref linkend="table.sl-path"/>.
</para>
</listitem>
<listitem>
<para>
Enfin, si aucune indication n'a été obtenue à partir des informations
précédentes. alors les n&oelig;uds peuvent écouter indirectement via
un n&oelig;ud qui est fournisseur de l'abonné, ou qui utilise l'abonné comme
fournisseur.
</para>
</listitem>
</itemizedlist>
</para>
<para>
À chaque fois que les tables <xref linkend="table.sl-subscribe"/> ou <xref
linkend="table.sl-path"/> sont modifiées, la fonction
<function>RebuildListenEntries()</function> est appelée pour mettre à jour
les voies d'écoute.
</para>
</sect2>
</sect1>