Changeset 1014

Show
Ignore:
Timestamp:
04/29/08 09:07:56 (7 months ago)
Author:
daamien
Message:

1ère traduction, à relire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/listenpaths.xml

    r901 r1014  
    55     révision $Revision$ --> 
    66 
    7 <sect1 id="listenpaths"><title>&slony1; listen paths</title> 
    8  
    9 <indexterm><primary>listen paths</primary></indexterm> 
    10  
    11 <note><para> If you are running version &slony1; 1.2 or later it 
    12 should be <emphasis>completely unnecessary</emphasis> to read this 
    13 section as it introduces a way to automatically manage this part of 
    14 its configuration.  For earlier versions, however, it is 
    15 needful.</para> 
     7<sect1 id="listenpaths"><title>Voies d'écoute</title> 
     8 
     9<indexterm><primary>voies d"écoute</primary></indexterm> 
     10 
     11<note><para> Si vous utilisez une version &slony1; 1.2 ou ultérieure, il  
     12    est <emphasis>complÚtement inutile</emphasis> de lire cette section car 
     13    cette version dispose d'un méthode de gestion automatique de cette partie  
     14    de sa configuration. Pour les versions antérieures, cependant, ce qui va  
     15    suivre est nécessaire.  
     16    </para> 
    1617</note> 
    1718 
    18 <para>If you have more than two or three nodes, and any degree of 
    19 usage of cascaded subscribers (<emphasis>e.g.</emphasis> - subscribers 
    20 that are subscribing through a subscriber node), you will have to be 
    21 fairly careful about the configuration of <quote>listen paths</quote> 
    22 via the Slonik <xref linkend="stmtstorelisten"/> and <xref 
    23 linkend="stmtdroplisten"/> statements that control the contents of the 
    24 table <xref linkend="table.sl-listen"/>.</para> 
    25  
    26 <para>The <quote>listener</quote> entries in this table control where 
    27 each node expects to listen in order to get events propagated from 
    28 other nodes.  You might think that nodes only need to listen to the 
    29 <quote>parent</quote> from whom they are getting updates, but in 
    30 reality, they need to be able to receive messages from 
    31 <emphasis>all</emphasis> nodes in order to be able to conclude that 
    32 <command>sync</command>s have been received everywhere, and that, 
    33 therefore, entries in <xref linkend="table.sl-log-1"/> and <xref 
    34 linkend="table.sl-log-2"/> have been applied everywhere, and can 
    35 therefore be purged.  this extra communication is needful so 
    36 <productname>Slony-I</productname> is able to shift origins to other 
    37 locations.</para> 
    38  
    39 <sect2><title>How listening can break</title> 
    40  
    41 <indexterm><primary> listening breakage </primary></indexterm> 
    42  
    43 <para>On one occasion, I had a need to drop a subscriber node (#2) and 
    44 recreate it.  That node was the data provider for another subscriber 
    45 (#3) that was, in effect, a <quote>cascaded slave.</quote> Dropping 
    46 the subscriber node initially didn't work, as <xref linkend="slonik"/> 
    47 informed me that there was a dependant node.  I repointed the 
    48 dependant node to the <quote>master</quote> node for the subscription 
    49 set, which, for a while, replicated without difficulties.</para> 
    50  
    51 <para>I then dropped the subscription on <quote>node 2</quote>, and 
    52 started resubscribing it.  that raised the &slony1; 
    53 <command>set_subscription</command> event, which started copying 
    54 tables.  at that point in time, events stopped propagating to 
    55 <quote>node 3</quote>, and while it was in perfectly ok shape, no 
    56 events were making it to it.</para> 
    57  
    58 <para>The problem was that node #3 was expecting to receive events 
    59 from node #2, which was busy processing the <command>set_subscription</command> 
    60 event, and was not passing anything else on.</para> 
    61  
    62 <para>We dropped the listener rules that caused node #3 to listen to 
    63 node 2, replacing them with rules where it expected its events to come 
    64 from node #1 (the origin node for the replication set).  At that 
    65 moment, <quote>as if by magic</quote>, node #3 started replicating again, as 
    66 it discovered a place to get <command>sync</command> events.</para> 
     19<para>Si vous avez plus de deux ou trois noeuds et un niveau d'abonnement  
     20  en cascade ( <emphasis>c'est à dire</emphasis> des noeuds qui s'abonne  
     21  à des noeuds abonnés ), vous devez être trÚs prudent avec la configuration  
     22  des <quote>voies d'écoute</quote> par les commandes Slonik  
     23  <xref linkend="stmtstorelisten"/> et  <xref linkend="stmtdroplisten"/> qui 
     24  contrÃŽle le contenu de la table <xref linkend="table.sl-listen"/>.</para> 
     25 
     26<para>Les entrées de cette table contrÃŽlent où chaque noeuds doit écouter afin 
     27  d'obtenir les événements propagés par les autres noeuds.  Vous vous dites 
     28  peut-être que chaque noeud doit simplement écouter le noeud 
     29  <quote>parent</quote> qui leur transmet les mise à jours, mais en réalité, ils doivent 
     30  pouvoir recevoir des messages de ma part de <emphasis>tous</emphasis> les noeuds 
     31  afin de pouvoir déterminer si les <command>SYNC</command>s ont été reçus  
     32  partout et que les entrées de <xref linkend="table.sl-log-1"/> et <xref 
     33  linkend="table.sl-log-2"/> ont été appliquées partout et qu'elles  
     34  peuvent être purgées. Ces communications supplémentaires permettent à 
     35  <productname>Slony-I</productname> de déplacer les origines vers d'autres  
     36  noeuds.</para> 
     37 
     38<sect2><title>Comment l'écoute peut être rompue</title> 
     39 
     40<indexterm><primary> rupture d'écoute </primary></indexterm> 
     41 
     42<para>A une occasion, j'ai eu besoin de supprimer un noeud abonné (#2) et  
     43  de la recréer. Ce noeud était le fournisseur d'un autre abonné (#3) qui  
     44  était, de facto, un <quote>esclave en cascade</quote>. 
     45  La suppression du noeud abonné ne fonctionna, en effet  
     46  <xref linkend="slonik"/> m'informa qu'il existait un noeud dépendant. 
     47  Je fit pointer le noeud dépendant vers le noeud <quote>maître</quote> 
     48  de l'ensemble de réplication, ce qui se déroula, pour un temps,  
     49  sans difficultés.</para> 
     50 
     51<para>Je supprimais alors l'abonnement du <quote>node 2</quote>, et tentais de 
     52  l'abonner de nouveau. Cela déclencha un événement &slony1; 
     53<command>set_subscription</command>, qui commença à copier les tables. 
     54À ce moment, les événements ne furent plus propagés au <quote>noeud 3</quote>, 
     55et tandis qu'il était en parfait état de fonctionnement, plus aucun  
     56événement ne lui parvenait.</para> 
     57 
     58<para>Le problÚme était que le noeud #3 attendait de recevoir des événements de la part  
     59  du noeud #2, qui était occupé par le traitement de l'événement <command>set_subscription</command> 
     60  et ne transmettait aucune autre information.</para> 
     61 
     62<para>Nous supprimames les rÚgles qui ordonnait au noeud #3 d'écouter le noeud #2, 
     63  en les remplaçant par des rÚgles qui lui indiquait d'attendre les événements en provenance 
     64  du noeud #1 ( le noeud origine de la réplication ). À ce moment,  
     65  <quote>comme par magie</quote>, le noeud #3 recommença à répliquer, car  
     66  il avait découvert une source ou écouter les évÚnements <command>SYNC</command>.</para> 
    6767</sect2> 
    68 <sect2><title>How the listen configuration should look</title> 
    69  
    70 <para>The simple cases tend to be simple to cope with.  We need to 
    71 instead look at a more complex node configuration.</para> 
    72  
    73 <para>Consider a set of nodes, 1 thru 6, where 1 is the origin,  
    74 where 2-4 subscribe directly to the origin, and where 5 subscribes to 
    75 2, and 6 subscribes to 5.</para> 
    76  
    77 <para>Here is a <quote>listener network</quote> that indicates where each 
    78 node should listen for messages coming from each other node: 
     68<sect2><title>Comment configurer les écoutes</title> 
     69 
     70<para>Les cas simples sont facile à gérer. Intéressons-nous plutÃŽt  
     71  à un configuration plus complexe.</para> 
     72 
     73<para>Considérons un ensemble de noeuds, de 1 à 6, où 1 est l'origine,  
     742-4 sont abonnés directement à l'origine, 5 est abonné à 2,  
     75et 6 est abonné à 5.</para> 
     76 
     77<para>Voici un <quote>réseau d'écoute</quote> qui montre où chaque noeud doit  
     78  écouter les messages en provenance des autres noeuds : 
    7979 
    8080<screen> 
    …… 
    8989</screen> 
    9090</para> 
    91 <para>Row 2 indicates all of the listen rules for node 2; it gets 
    92 events for nodes 1, 3, and 4 throw node 1, and gets events for nodes 5 
    93 and 6 from node 5.</para> 
    94  
    95 <para>The row of 5's at the bottom, for node 6, indicate that node 6 
    96 listens to node 5 to get events from nodes 1-5.</para> 
    97  
    98 <para>The set of slonik <command>set listen</command> statements to express 
    99 this <quote>listener network</quote> are as follows: 
     91<para>La ligne 2 indique toutes les rÚgles d'écoute pour le noeud 2;  
     92  il obtient les événements des noeuds 1, 3 et 4 chez le noeud 1 et il  
     93  écoute sur le noeud 5 les événements des noeuds 5 et 6.  
     94  </para> 
     95 
     96<para>La derniÚre ligne composée de 5, celle du noeud 6, indique que le noeud 6 
     97écoute le noeud 5 pour obtenir les événements des noeuds 1 à 5.</para> 
     98 
     99<para>Les commandes slonik <command>set listen</command> qui exprime 
     100  ce <quote>réseau d'écoute</quote> sont les suivantes : 
    100101 
    101102<programlisting> 
    …… 
    132133</programlisting> 
    133134</para> 
    134 <para>How we read these listen statements is thus...</para> 
    135  
    136 <para>When on the <quote>receiver</quote> node, look to the <quote>provider</quote> 
    137 node to provide events coming from the <quote>origin</quote> node.</para> 
    138  
    139 <para>The tool <filename>init_cluster</filename> in the 
    140 <filename>altperl</filename> scripts produces optimized listener 
    141 networks in both the tabular form shown above as well as in the form 
    142 of <xref linkend="slonik"/> statements.</para> 
    143  
    144 <para>There are three <quote>thorns</quote> in this set of roses: 
     135<para>Ces lignes de commandes d'écoute sont lues lorsque...</para> 
     136 
     137<para>... le noeud <quote>récepteur</quote>, cherche un noeud <quote>fournisseur</quote> 
     138pour obtenir les événements en provenance du noeud d'<quote>origine</quote>.</para> 
     139 
     140<para>L'outil <filename>init_cluster</filename> parmi les scripts 
     141<filename>altperl</filename> produit un réseau d'écoute optimisé  
     142sous forme de tableau et ainsi qu'une liste de commandes  
     143<xref linkend="slonik"/>.</para> 
     144 
     145<para>Il y a trois <quote>épines</quote> dans ce bouquet de roses : 
    145146 
    146147<itemizedlist> 
    147148 
    148 <listitem><para> If you change the shape of the node set, so that the 
    149 nodes subscribe differently to things, you need to drop <xref 
    150 linkend="table.sl-listen"/> entries and create new ones to indicate the 
    151 new preferred paths between nodes.  Until &slony1;, there is no 
    152 automated way at this point to do this 
    153 <quote>reshaping</quote>.</para></listitem> 
    154  
    155 <listitem><para> If you <emphasis>don't</emphasis> change the 
    156 <xref linkend="table.sl-listen"/> entries, events will likely continue to propagate so long as 
    157 all of the nodes continue to run well.  the problem will only be 
    158 noticed when a node is taken down, <quote>orphaning</quote> any nodes 
    159 that are listening through it.</para></listitem> 
    160  
    161 <listitem><para> you might have multiple replication sets that have 
    162 <emphasis>different</emphasis> shapes for their respective trees of 
    163 subscribers.  there won't be a single <quote>best</quote> listener 
    164 configuration in that case.</para></listitem> 
    165  
    166 <listitem><para> In order for there to be an <xref 
    167 linkend="table.sl-listen"/> path, there <emphasis>must</emphasis> be a 
    168 series of <xref linkend="table.sl-path"/> entries connecting the origin 
    169 to the receiver.  this means that if the contents of <xref 
    170 linkend="table.sl-path"/> do not express a <quote>connected</quote> 
    171 network of nodes, then some nodes will not be reachable.  this would 
    172 typically happen, in practice, when you have two sets of nodes, one in 
    173 one subnet, and another in another subnet, where there are only a 
    174 couple of <quote>firewall</quote> nodes that can talk between the 
    175 subnets.  cut out those nodes and the subnets stop 
    176 communicating.</para></listitem> 
     149<listitem><para> Si vous changez la structure du l'ensemble de noeuds, alors 
     150    les noeuds sont abonnés différemment et vous devez supprimer les entrées 
     151    de la table  <xref linkend="table.sl-listen"/> et en créez de nouvelles 
     152    pour décrire les nouvelles voies d'écoute entre les noeuds.  
     153    Jusqu'à &slony1; 1.2, il n'y a aucune maniÚre automatique de réaliser  
     154    cette <quote>restructuration</quote>.</para></listitem> 
     155 
     156<listitem><para> Si vous <emphasis>ne changez pas</emphasis> les entrées  
     157<xref linkend="table.sl-listen"/>, les événements se propageront  
     158tant que les noeuds fonctionnerait correctement. Le problÚme se  
     159déclenchera lorsqu'un noeud sera retiré,,rendant <quote>orphelin</quote>  
     160les noeuds qui l'écoutaient.</para></listitem> 
     161 
     162<listitem><para> Vous pouvez essayer de multiples ensembles de réplication 
     163    qui ont des structures <emphasis>différentes</emphasis> pour leur arborescence 
     164    d'abonnés. Il n'y aucune configuration d'écoute qui convienne parfaitement 
     165    dans ce cas.</para></listitem> 
     166 
     167<listitem><para> Afin de créer une voie <xref linkend="table.sl-listen"/>,  
     168    il <emphasis>doit</emphasis> exister une série d'entrées<xref linkend="table.sl-path"/>  
     169    qui connectent l'origine au récepteur.  Cela implique que si le contenu 
     170    de <xref linkend="table.sl-path"/> ne définit pas réseau <quote>connecté</quote> 
     171    de noeuds, alors certains noeuds ne seront pas accessibles. Typiquement cela 
     172    peut se produire, lorsque vous avez deux ensembles de noeuds, placés sur deux  
     173    sous-réseaux séparés, avec simplement deux noeuds <quote>pare-feu</quote>  
     174    qui communiquent d'un sous-réseau à l'autre. Couper un de ces noeuds et les  
     175    sous-ensembles de réplication s'arrêtent.</para></listitem> 
    177176 
    178177</itemizedlist></para> 
    …… 
    180179</sect2> 
    181180 
    182 <sect2 id="autolisten"><title>Automated Listen Path Generation</title> 
    183  
    184 <indexterm><primary> automated listen path generation </primary></indexterm> 
    185  
    186 <para> In &slony1; version 1.1, a heuristic scheme is introduced to 
    187 automatically generate <envar>sl_listen</envar> entries.  This 
    188 happens, in order, based on three data sources: 
     181<sect2 id="autolisten"><title>Génération automatique de voie d'écoute</title> 
     182 
     183<indexterm><primary>génération automatique de voie d'écoute </primary></indexterm> 
     184 
     185<para> Dans &slony1; version 1.1, une rÚgle heuristique est introduite pour  
     186  générer automatiquement les entrées <envar>sl_listen</envar>. 
     187  Cela se fait en fonction de 3 types d'informations :  
    189188 
    190189<itemizedlist> 
    191190 
    192 <listitem><para> <xref linkend="table.sl-subscribe"/> entries are the 
    193 first, most vital control as to what listens to what; we 
    194 <emphasis>know</emphasis> there must be a direct path between each 
    195 subscriber node and its provider.</para></listitem> 
    196  
    197 <listitem><para> <xref linkend="table.sl-path"/> entries are the second 
    198 indicator; if <xref linkend="table.sl-subscribe"/> has not already 
    199 indicated <quote>how to listen,</quote> then a node may listen 
    200 directly to the event's origin if there is a suitable <xref 
    201 linkend="table.sl-path"/> entry.</para></listitem> 
    202  
    203 <listitem><para> Lastly, if there has been no guidance thus far based 
    204 on the above data sources, then nodes can listen indirectly via every 
    205 node that is either a provider for the receiver, or that is using the 
    206 receiver as a provider.</para></listitem> 
     191<listitem><para>Les entrées <xref linkend="table.sl-subscribe"/> sont 
     192    les informations primordiales et vitales sur qui doit écouter quoi; 
     193    nous <emphasis>savons</emphasis> qu'il doit y avoir une voie 
     194    directe entre chaque abonné et son fournisseur. 
     195    </para></listitem> 
     196 
     197<listitem><para>Les entrées <xref linkend="table.sl-path"/> sont 
     198    le second indicateur; si a table <xref linkend="table.sl-subscribe"/> 
     199    n'indique pas <quote>comment écouter</quote>, alors un noeud  
     200    peut écouter directement l'origine si il existe une voie praticable 
     201    dans <xref linkend="table.sl-path"/>.</para></listitem> 
     202 
     203<listitem><para> Enfin, si aucune indication n'a été obtenue à partir des 
     204    informations précédentes. alors les noeuds peuvent écouter indirectement 
     205    via un noeud qui est fournisseur de l'abonné, ou qui utilise l'abonné comme 
     206    fournisseur.</para></listitem> 
    207207 
    208208</itemizedlist></para> 
    209209 
    210 <para> Any time <xref linkend="table.sl-subscribe"/> or <xref 
    211 linkend="table.sl-path"/> are modified, 
    212 <function>RebuildListenEntries()</function> will be called to revise 
    213 the listener paths.</para> 
     210<para> À chaque fois que les tables <xref linkend="table.sl-subscribe"/> ou <xref 
     211linkend="table.sl-path"/> sont modifiées, la fonction  
     212<function>RebuildListenEntries()</function> est appelée pour  
     213mettre à jour les voies d'écoute.</para> 
    214214 
    215215</sect2>