root/traduc/trunk/slony/listenpaths.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- DerniÚre modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

<sect1 id="listenpaths"><title>Voies d'écoute</title>

<indexterm><primary>voies 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'un méthode de gestion automatique de cette partie 
    de sa 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 noeuds et un niveau d'abonnement 
  en cascade ( <emphasis>c'est à dire</emphasis> des noeuds qui s'abonne 
  à des noeuds abonnés ), vous devez être trÚs prudent avec la configuration 
  des <quote>voies d'écoute</quote> par les commandes Slonik 
  <xref linkend="stmtstorelisten"/> et  <xref linkend="stmtdroplisten"/> qui
  contrÃŽle le contenu de la table <xref linkend="table.sl-listen"/>.</para>

<para>Les entrées de cette table contrÎlent où chaque noeuds doit écouter afin
  d'obtenir les événements propagés par les autres noeuds.  Vous vous dites
  peut-être que chaque noeud doit simplement écouter le noeud
  <quote>parent</quote> qui leur transmet les mise à jours, mais en réalité, ils doivent
  pouvoir recevoir des messages de ma part de <emphasis>tous</emphasis> les noeuds
  afin de pouvoir déterminer si les <command>SYNC</command>s ont été reçus 
  partout et que les entrées de <xref linkend="table.sl-log-1"/> et <xref
  linkend="table.sl-log-2"/> 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 
  noeuds.</para>

<sect2><title>Comment l'écoute peut être rompue</title>

<indexterm><primary> rupture d'écoute </primary></indexterm>

<para>A une occasion, j'ai eu besoin de supprimer un noeud abonné (#2) et 
  de la recréer. Ce noeud était le fournisseur d'un autre abonné (#3) qui 
  était, de facto, un <quote>esclave en cascade</quote>.
  La suppression du noeud abonné ne fonctionna, en effet 
  <xref linkend="slonik"/> m'informa qu'il existait un noeud dépendant.
  Je fit pointer le noeud dépendant vers le noeud <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>node 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>noeud 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 noeud #3 attendait de recevoir des événements de la part 
  du noeud #2, qui était occupé par le traitement de l'événement <command>set_subscription</command>
  et ne transmettait aucune autre information.</para>

<para>Nous supprimames les rÚgles qui ordonnait au noeud #3 d'écouter le noeud #2,
  en les remplaçant par des rÚgles qui lui indiquait d'attendre les événements en provenance
  du noeud #1 ( le noeud origine de la réplication ). À ce moment, 
  <quote>comme par magie</quote>, le noeud #3 recommença à répliquer, car 
  il avait découvert une source ou é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 
  Ã  un configuration plus complexe.</para>

<para>Considérons un ensemble de noeuds, 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 noeud doit 
  écouter les messages en provenance des autres noeuds :

<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 noeud 2; 
  il obtient les événements des noeuds 1, 3 et 4 chez le noeud 1 et il 
  écoute sur le noeud 5 les événements des noeuds 5 et 6. 
  </para>

<para>La derniÚre ligne composée de 5, celle du noeud 6, indique que le noeud 6
écoute le noeud 5 pour obtenir les événements des noeuds 1 à 5.</para>

<para>Les commandes slonik <command>set listen</command> qui exprime
  ce <quote>réseau d'écoute</quote> sont les suivantes :

<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 noeud <quote>récepteur</quote>, cherche un noeud <quote>fournisseur</quote>
pour obtenir les événements en provenance du noeud 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 :

<itemizedlist>

<listitem><para> Si vous changez la structure du l'ensemble de noeuds, alors
    les noeuds 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 noeuds. 
    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 
<xref linkend="table.sl-listen"/>, les événements se propageront 
tant que les noeuds fonctionnerait correctement. Le problÚme se 
déclenchera lorsqu'un noeud sera retiré,,rendant <quote>orphelin</quote> 
les noeuds 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 réseau <quote>connecté</quote>
    de noeuds, alors certains noeuds ne seront pas accessibles. Typiquement cela
    peut se produire, lorsque vous avez deux ensembles de noeuds, placés sur deux 
    sous-réseaux séparés, avec simplement deux noeuds <quote>pare-feu</quote> 
    qui communiquent d'un sous-réseau à l'autre. Couper un de ces noeuds 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 3 types d'informations : 

<itemizedlist>

<listitem><para>Les entrées <xref linkend="table.sl-subscribe"/> sont
    les informations primordiales et vitales sur qui doit écouter quoi;
    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; si a table <xref linkend="table.sl-subscribe"/>
    n'indique pas <quote>comment écouter</quote>, alors un noeud 
    peut écouter directement l'origine si 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 noeuds peuvent écouter indirectement
    via un noeud 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>