Changeset 1110

Show
Ignore:
Timestamp:
07/27/08 13:33:44 (4 months ago)
Author:
daamien
Message:

Slony : slon.xml / 1ere trad à relire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/slon.xml

    r937 r1110  
    1414  <refname><application>slon</application></refname> 
    1515  <refpurpose> 
    16    &slony1; daemon 
     16   Le démon &slony1; 
    1717  </refpurpose> 
    1818 </refnamediv> 
    …… 
    3434  <title>Description</title> 
    3535  <para> 
    36    <application>slon</application> is the daemon application that 
    37    <quote>runs</quote> &slony1; replication.  A 
    38    <application>slon</application> instance must be run for each node 
    39    in a &slony1; cluster. 
     36   <application>slon</application> est un démon applicatif qui  
     37   <quote>contrÃŽle</quote> la réplication &slony1;. Une 
     38   instance <application>slon</application> doit être lancée pour 
     39   chaque noeud du cluster &slony1;. 
    4040  </para> 
    4141 </refsect1> 
    …… 
    4949    <listitem> 
    5050     <para> 
    51       The <envar>log_level</envar> specifies which levels of debugging messages 
    52       <application>slon</application> should display when logging its 
    53       activity. 
     51      Le paramÚtre <envar>log_level</envar> spécifie quel niveau de messages de debug 
     52      <application>slon</application> doit afficher dans son journal d'activité. 
    5453     </para> 
    5554     <para id="nineloglevels"> 
    56       The nine levels of logging are: 
     55      Il y a neuf niveaux de log : 
    5756      <itemizedlist> 
    5857       <listitem><para>Fatal</para></listitem> 
    …… 
    6867     </para> 
    6968 
    70      <para> The first five non-debugging log levels (from Fatal to 
    71      Info) are <emphasis>always</emphasis> displayed in the logs.  In 
    72      early versions of &slony1;, the <quote>suggested</quote> 
    73      <envar>log_level</envar> value was 2, which would list output at 
    74      all levels down to debugging level 2.  In &slony1; version 2, it 
    75      is recommended to set <envar>log_level</envar> to 0; most of the 
    76      consistently interesting log information is generated at levels 
    77      higher than that. </para> 
    78     
    79     </listitem> 
    80    </varlistentry> 
    81     
    82    <varlistentry> 
    83     <term><option>-s</option><replaceable class="parameter"> SYNC check interval</replaceable></term> 
    84     <listitem> 
    85  
    86      <para> 
    87       The <envar>sync_interval</envar>, measured in milliseconds, 
    88       indicates how often <application>slon</application> should check 
    89       to see if a <command>SYNC</command> should be introduced. 
    90       Default is 2000 ms.  The main loop in 
    91       <function>sync_Thread_main()</function> sleeps for intervals of 
    92       <envar>sync_interval</envar> milliseconds between iterations. 
     69     <para> Les cinq premiers niveau de log ( de Fatal à 
     70     Info) sont <emphasis>toujours</emphasis> affichés dans les logs. 
     71     Dans les premiÚres versions de &slony1;, le niveau de log  
     72     <quote>suggéré</quote> était 2, ce qui affichait tous les messages 
     73     jusqu'au niveau Debug2.  Avec &slony1; version 2, il est  
     74     recommandé de positionner <envar>log_level</envar> à 0; la  
     75     pluspart des informations intéressantes sont produites à  
     76     des niveaux supérieurs à celui-là. 
     77     </para> 
     78    
     79    </listitem> 
     80   </varlistentry> 
     81    
     82   <varlistentry> 
     83    <term><option>-s</option><replaceable class="parameter"> Interval entre les vérifications SYNC</replaceable></term> 
     84    <listitem> 
     85 
     86     <para> 
     87      Le paramÚtre <envar>sync_interval</envar>, exprimé en millisecondes, 
     88      indique à quelle fréquence <application>slon</application> doit  
     89      vérifier si un événement <command>SYNC</command> doit  
     90      être produit. La valeur par défaut est 2000 ms.  La boucle principale 
     91      dans <function>sync_Thread_main()</function> est endormie pendant  
     92      des intervalles de <envar>sync_interval</envar> millisecondes  
     93      entre chaque itérations. 
    9394     </para> 
    9495      
    9596     <para> 
    96       Short sync check intervals keep the origin on a <quote>short 
    97       leash</quote>, updating its subscribers more frequently.  If you 
    98       have replicated sequences that are frequently updated 
    99       <emphasis>without</emphasis> there being tables that are 
    100       affected, this keeps there from being times when only sequences 
    101       are updated, and therefore <emphasis>no</emphasis> syncs take 
    102       place 
    103      </para> 
    104  
    105      <para> 
    106       If the node is not an origin for any replication set, so no 
    107       updates are coming in, it is somewhat wasteful for this value to 
    108       be much less the <envar>sync_interval_timeout</envar> value. 
    109      </para> 
    110  
    111     </listitem> 
    112    </varlistentry> 
    113     
    114    <varlistentry> 
    115     <term><option>-t</option><replaceable class="parameter"> SYNC 
    116     interval timeout</replaceable></term> 
    117     <listitem> 
    118  
    119      <para> 
    120       At the end of each <envar>sync_interval_timeout</envar> timeout 
    121       period, a <command>SYNC</command> will be generated on the 
    122       <quote>local</quote> node even if there has been no replicable 
    123       data updated that would have caused a 
    124       <command>SYNC</command> to be generated. </para> 
    125  
    126      <para> If application activity ceases, whether because the 
    127      application is shut down, or because human users have gone home 
    128      and stopped introducing updates, the &lslon; will iterate away, 
    129      waking up every <envar>sync_interval</envar> milliseconds, and, 
    130      as no updates are being made, no <command>SYNC</command> events 
    131      would be generated.  Without this timeout parameter, 
    132      <emphasis>no</emphasis> <command>SYNC</command> events would be 
    133      generated, and it would appear that replication was falling 
    134      behind. </para> 
    135  
    136      <para> The <envar>sync_interval_timeout</envar> value will lead 
    137      to eventually generating a <command>SYNC</command>, even though 
    138      there was no real replication work to be done.  The lower that 
    139      this parameter is set, the more frequently &lslon; will generate 
    140      <command>SYNC</command> events when the application is not 
    141      generating replicable activity; this will have two effects:</para> 
     97      Un intervalle de vérifications trÚs court garantit que le noeud 
     98      origine soit <quote>trÚs suivi</quote>, car il met à jour les abonnés 
     99      plus fréquemment. Si vous avez des séquences répliquées qui sont  
     100      souvent mises à jour <emphasis>sans</emphasis> que certaines tables 
     101      ne soient affectées, cela évite que des opérations qui mettent  
     102      à jour uniquement ces séquences soient effectuées, et ainsi  
     103      évite la génération d'événements de synchronisations. 
     104     </para> 
     105 
     106     <para> 
     107      Si un noeud n'est pas l'origine d'un set de réplication, et donc qu'il 
     108      ne reçoit aucune mise à jour des données répliquées, alors il est  
     109      un peu inutile de mettre une valeur inférieure à celle du paramÚtre  
     110      <envar>sync_interval_timeout</envar>. 
     111     </para> 
     112 
     113    </listitem> 
     114   </varlistentry> 
     115    
     116   <varlistentry> 
     117    <term><option>-t</option><replaceable class="parameter">intervalle maximal entre deux SYNC 
     118    </replaceable></term> 
     119    <listitem> 
     120 
     121     <para> 
     122      A la fin de chaque période  <envar>sync_interval_timeout</envar> 
     123      , un événement <command>SYNC</command> est produit sur le noeud  
     124      <quote>local</quote> même si il n'y eu aucune mise à jour des  
     125      données répliquées et qu'aucun <command>SYNC</command> n'a été  
     126      généré. </para> 
     127 
     128     <para> Si l'activité de l'application s'arrête, soit parce que 
     129     l'application a été éteinte, soit parce que les utilisateurs humains 
     130     sont rentrés chez eux et arrêtés les mises à jour, alors le 
     131     démon  &lslon; continue de tourner et se réveille toutes les  
     132     <envar>sync_interval</envar> millisecondes, et si aucune mise 
     133     Ã  jour ne s'est produite, alors aucun événement  <command>SYNC</command> 
     134     n'est généré. Sans ce paramÚtre <quote>timeout</quote>, 
     135     <emphasis>aucun</emphasis> événement <command>SYNC</command>  
     136     ne pourrait être produit, et cela entraînerait le chute du  
     137     systÚme de réplication. </para> 
     138 
     139     <para> Le paramÚtre <envar>sync_interval_timeout</envar> provoque 
     140     la génération de <command>SYNC</command>, même si il n'y a pas  
     141     réellement de travail de réplication a faire. Plus la valeur de  
     142     cette paramÚtre est basse, plus les évÚnements  <command>SYNC</command> 
     143     lorsque l'application n'est pas active. Ceci a deux 2 effets 
     144     :</para> 
    142145      <itemizedlist> 
    143146 
    144       <listitem><para> The system will do more replication work.</para>  
    145  
    146       <para> (Of course, since there is no application load on the 
    147       database, and no data to replicate, this load will be very easy 
    148       to handle.  </para></listitem> 
    149  
    150       <listitem><para> Replication will appear to be kept more 
    151       <quote>up to date.</quote></para> 
    152  
    153       <para> (Of course, since there is no replicable activity going 
    154       on, being <quote>more up to date</quote> is something of a 
    155       mirage.) </para></listitem> 
     147      <listitem><para> Le systÚme aura plus de travail.</para>  
     148 
     149      <para> ( Cependant puisque l'application n'utilise pas  
     150        la base de données et qu'il n'y a pas de données à répliquer, 
     151        la charge de travail supplémentaire sera assez simple à gérer.) 
     152        </para></listitem> 
     153 
     154      <listitem><para> La réplication sera tenue un peu plus <quote>à jour</quote>.</para> 
     155 
     156      <para> ( Cependant puisqu'il n'y a pas de données à répliquer, être 
     157        plus souvent <quote>mis à jour</quote> est un mirage.) </para></listitem> 
    156158 
    157159      </itemizedlist> 
    158160 
    159161     <para> 
    160       Default is 10000 ms and maximum is 120000 ms. By default, you 
    161       can expect each node to <quote>report in</quote> with a 
    162       <command>SYNC</command> every 10 seconds. 
    163      </para> 
    164      <para> 
    165       Note that <command>SYNC</command> events are also generated on 
    166       subscriber nodes.  Since they are not actually generating any 
    167       data to replicate to other nodes, these <command>SYNC</command> 
    168       events are of not terribly much value. 
    169      </para> 
    170     </listitem> 
    171    </varlistentry> 
    172     
    173    <varlistentry> 
    174     <term><option>-g</option><replaceable class="parameter"> group size</replaceable></term> 
    175     <listitem> 
    176      <para> 
    177       This controls the maximum <command>SYNC</command> group size, 
    178       <envar>sync_group_maxsize</envar>; defaults to 6.  Thus, if a 
    179       particular node is behind by 200 <command>SYNC</command>s, it 
    180       will try to group them together into groups of a maximum size of 
    181       <envar>sync_group_maxsize</envar>.  This can be expected to 
    182       reduce transaction overhead due to having fewer transactions to 
    183       <command>COMMIT</command>. 
    184      </para> 
    185      <para> 
    186       The default of 6 is probably suitable for small systems that can 
    187       devote only very limited bits of memory to 
    188       <application>slon</application>.  If you have plenty of memory, 
    189       it would be reasonable to increase this, as it will increase the 
    190       amount of work done in each transaction, and will allow a 
    191       subscriber that is behind by a lot to catch up more quickly. 
    192      </para> 
    193      <para> 
    194       Slon processes usually stay pretty small; even with large value 
    195       for this option, <application>slon</application> would be 
    196       expected to only grow to a few MB in size. 
    197      </para> 
    198      <para> 
    199       The big advantage in increasing this parameter comes from 
    200       cutting down on the number of transaction 
    201       <command>COMMIT</command>s; moving from 1 to 2 will provide 
    202       considerable benefit, but the benefits will progressively fall 
    203       off once the transactions being processed get to be reasonably 
    204       large.  There isn't likely to be a material difference in 
    205       performance between 80 and 90; at that point, whether 
    206       <quote>bigger is better</quote> will depend on whether the 
    207       bigger set of <command>SYNC</command>s makes the 
    208       <envar>LOG</envar> cursor behave badly due to consuming more 
    209       memory and requiring more time to sortt. 
    210      </para> 
    211      <para> 
    212       In &slony1; version 1.0, <application>slon</application> will 
    213       always attempt to group <command>SYNC</command>s together to 
    214       this maximum, which <emphasis>won't</emphasis> be ideal if 
    215       replication has been somewhat destabilized by there being very 
    216       large updates (<emphasis>e.g.</emphasis> - a single transaction 
    217       that updates hundreds of thousands of rows) or by 
    218       <command>SYNC</command>s being disrupted on an origin node with 
    219       the result that there are a few <command>SYNC</command>s that 
    220       are very large.  You might run into the problem that grouping 
    221       together some very large <command>SYNC</command>s knocks over a 
    222       <application>slon</application> process.  When it picks up 
    223       again, it will try to process the same large grouped set of 
    224       <command>SYNC</command>s, and run into the same problem over and 
    225       over until an administrator interrupts this and changes the 
    226       <option>-g</option> value to break this <quote>deadlock.</quote> 
     162      La valeur par défaut est 10000 ms et la valeur maximale est 120000 ms.  
     163      Par défaut, vous pouvez prévoir que chaque noeud soit   
     164       <quote>synchronisé</quote> par un <command>SYNC</command> toutes les 10 secondes. 
     165     </para> 
     166     <para> 
     167      Notez que des événements <command>SYNC</command> sont aussi générés  
     168       sur chaque noeud abonné. Cependant puisqu'ils ne contiennent  
     169      de données à répliquer par les autres noeuds, les évÚnements  
     170      <command>SYNC</command> des noeuds abonnés ne sont pas terriblement intéressant. 
     171     </para> 
     172    </listitem> 
     173   </varlistentry> 
     174    
     175   <varlistentry> 
     176    <term><option>-g</option><replaceable class="parameter"> taille du groupe</replaceable></term> 
     177    <listitem> 
     178     <para> 
     179      L'option <envar>sync_group_maxsize</envar> contrÃŽle la taille maximumale d'un groupe <command>SYNC</command>, 
     180      . La valeur par défaut est 6.  Ainsi, si un noeud particulier a  
     181      200 événements <command>SYNC</command>s de retard, il essaiera de les regrouper  
     182      par groupes dont la taille maximale sera <envar>sync_group_maxsize</envar>. 
     183      Ceci doit permettre de réduire le temps de lantence au démarrage (NdT : "overhead") 
     184      en réduisant le nombre de transactions à <quote>comitter</quoter>. 
     185     </para> 
     186     <para> 
     187      La valeur par défaut est 6 est probablement adéquate pour les petits systÚmes 
     188      qui ne peuvent allouer que des quantités limitées de mémoire à 
     189      <application>slon</application>.  Si vous avez beaucoup de mémoire 
     190      il est raisonnable d'augmenter cette valeur, car cela augmentera  
     191      la quantité de travail réalisée à chaque transaction, et cela 
     192      permettra a un noeud abonné de rattraper plus vite son retard. 
     193     </para> 
     194     <para> 
     195      Les processus Slon sont souvent trÚs petits; même en cas 
     196      de valeur trÚs forte pour cette option, <application>slon</application> 
     197      devrait simplement grossir de quelques MB. 
     198     </para> 
     199     <para> 
     200      Le gros avantage d'augmenter ce paramÚtre est que  
     201      cela divise le nombre de transaction 
     202      <command>COMMIT</command>s; passer de 1 to 2 aura probablement 
     203      un impact considérable, mais le bénéfice se réduit progressivement 
     204      lorsque la taille des groupes est suffisamment large. 
     205      Il n'y aura probablement pas de différence notable entre 80 et 90. 
     206      Rendu à ce niveau, l'augmentation de cette 
     207      valeur dépend du fait que les grands ensembles de <command>SYNC</command>s 
     208      perturbent les curseurs de <envar>LOG</envar> en consommant 
     209      de plus en plus de mémoire et nécessitant plus d'efforts lors  
     210      des tris. 
     211     </para> 
     212     <para> 
     213      Dans &slony1; version 1.0, <application>slon</application> essaie 
     214      toujours de regrouper un maximum de <command>SYNC</command>s ensemble 
     215      , ce qui <emphasis>n'est pas</emphasis> idéal si la réplication 
     216      a été déstabilisée par de grosses mises à jour ( <emphasis>par exemple 
     217      </emphasis> : une transaction unique qui met à jour des centaines  
     218      de milliers de lignes) ou lorsque les <command>SYNC</command>s  
     219      ont été interrompus sur un noeud origine, ce qui fait  
     220      que les suivants sont volumineux. Vous rencontrerez 
     221      ce problÚme : en regroupant des <command>SYNC</command>s trÚs 
     222      larges, le processus <application>slon</application> peut échouer. 
     223      Au redémarrage, il essaie a nouveau de traiter ce large ensemble  
     224      de <command>SYNC</command>s, et il retombe sur le même problÚme 
     225      encore et encore jusqu'à ce qu'un administrateur interrompe tout cela 
     226      et change la valeur de l'option <option>-g</option> pour 
     227      sortir de cette situation d'<quote>inter-blocage</quote>. 
    227228     </para>  
    228229     <para> 
    229       In &slony1; version 1.0, the <application>slon</application> 
    230       instead adaptively <quote>ramps up</quote> from doing 1 
    231       <command>SYNC</command> at a time towards the maximum group 
    232       size.  As a result, if there are a couple of 
    233       <command>SYNC</command>s that cause problems, the 
    234       <application>slon</application> will (with any relevant watchdog 
    235       assistance) always be able to get to the point where it 
    236       processes the troublesome <command>SYNC</command>s one by one, 
    237       hopefully making operator assistance unnecessary. 
    238      </para> 
    239     </listitem> 
    240    </varlistentry> 
    241  
    242    <varlistentry> 
    243     <term><option>-o</option><replaceable class="parameter"> desired sync time</replaceable></term> 
    244     <listitem><para> A <quote>maximum</quote> time planned for grouped <command>SYNC</command>s.</para> 
    245  
    246      <para> If replication is running behind, slon will gradually 
    247      increase the numbers of <command>SYNC</command>s grouped 
    248      together, targetting that (based on the time taken for the 
    249      <emphasis>last</emphasis> group of <command>SYNC</command>s) they 
    250      shouldn't take more than the specified 
    251      <envar>desired_sync_time</envar> value.</para> 
    252  
    253      <para> The default value for <envar>desired_sync_time</envar> is 
    254      60000ms, equal to one minute. </para> 
    255  
    256      <para> That way, you can expect (or at least hope!) that you'll 
    257       get a <command>COMMIT</command> roughly once per minute. </para> 
    258  
    259      <para> It isn't <emphasis>totally</emphasis> predictable, as it 
    260      is entirely possible for someone to request a <emphasis>very 
    261      large update,</emphasis> all as one transaction, that can 
    262      <quote>blow up</quote> the length of the resulting 
    263      <command>SYNC</command> to be nearly arbitrarily long.  In such a 
    264      case, the heuristic will back off for the 
    265      <emphasis>next</emphasis> group.</para> 
    266  
    267      <para> The overall effect is to improve 
    268       <productname>Slony-I</productname>'s ability to cope with 
    269       variations in traffic.  By starting with 1 <command>SYNC</command>, and gradually 
    270       moving to more, even if there turn out to be variations large 
    271       enough to cause <productname>PostgreSQL</productname> backends to 
    272       crash, <productname>Slony-I</productname> will back off down to 
    273       start with one sync at a time, if need be, so that if it is at 
    274       all possible for replication to progress, it will.</para> 
     230      Au contraire Avec &slony1; version 1.0, le démon <application>slon</application> 
     231      'adapte en augmentant <quote>progressivement</quote> le nombre de  
     232      <command>SYNC</command> par groupe, de 1 jusqu'à la valeur maximale. 
     233      Ainsi, si quelques <command>SYNC</command>s pausent problÚme, le démon 
     234      <application>slon</application> pourra (avec s'il est surveillé par 
     235      un processus chien de garde) traiter un par un ces évÚnements 
     236      <command>SYNC</command>s problématique, et ainsi éviter l'intervention 
     237      d'un administrateur. 
     238     </para> 
     239    </listitem> 
     240   </varlistentry> 
     241 
     242   <varlistentry> 
     243    <term><option>-o</option><replaceable class="parameter"> temps de synchronisation souhaité</replaceable></term> 
     244    <listitem><para> La période <quote>maximale</quote> pour un groupe de <command>SYNC</command>s.</para> 
     245 
     246     <para> Si la réplication est en retard, le démon slon va progressivement augmenter le 
     247       nombre de <command>SYNC</command>s groupés ensemble, dans le but de  
     248       ne pas dépasser le temps spécifié par <envar>desired_sync_time</envar>. 
     249       (pour cela, Slon se base sur le temps pris par le  
     250     <emphasis>dernier</emphasis> group de <command>SYNC</command>s) 
     251     .</para> 
     252 
     253     <para> La valeur par défaut est 60000ms,  
     254       c'est à dire une minute. </para> 
     255 
     256     <para> Ainsi vous pouvez prévoir (en tout cas espérer ! ) 
     257       que vous aurez un <command>COMMIT</command> environ 
     258       toutes les minutes.</para> 
     259 
     260     <para> Cela n'est pas <emphasis>complÚtement</emphasis> prévisible, 
     261       car il est possible de demander une <emphasis>trÚs grosse mise à jour 
     262     </emphasis>,qui fera <quote>exploser</quote> la taille du  
     263     <command>SYNC</command>. Dans ce cas là, l'heuristique sera  
     264     rétablie pour le <emphasis>prochain</emphasis> groupe.</para> 
     265 
     266     <para> L'effet final est d'améliorer la façon dont  
     267      <productname>Slony-I</productname> gÚre les variations  
     268      du trafic.  En commençant avec 1 événement <command>SYNC</command>, puis 
     269      en augmentant progressivement, même si certaines variations seront  
     270      assez grandes pour provoquer un crash du processus <productname>PostgreSQL</productname>, 
     271       <productname>Slony-I</productname> redémarrera en traitant un seul <command>SYNC</command> 
     272       Ã  la fois, afin que poursuivre le processus de réplication autant que possible. 
     273       </para> 
    275274    </listitem> 
    276275   </varlistentry>       
    277276 
    278277   <varlistentry> 
    279     <term><option>-c</option><replaceable class="parameter"> cleanup cycles</replaceable></term> 
    280     <listitem> 
    281      <para> 
    282       The value <envar>vac_frequency</envar> indicates how often to 
    283       <command>VACUUM</command> in cleanup cycles. 
    284      </para> 
    285      <para> 
    286       Set this to zero to disable 
    287       <application>slon</application>-initiated vacuuming. If you are 
    288       using something like <application>pg_autovacuum</application> to 
    289       initiate vacuums, you may not need for slon to initiate vacuums 
    290       itself.  If you are not, there are some tables 
    291       <productname>Slony-I</productname> uses that collect a 
    292       <emphasis>lot</emphasis> of dead tuples that should be vacuumed 
    293       frequently, notably &pglistener;. 
    294      </para> 
    295  
    296      <para> In &slony1; version 1.1, this changes a little; the 
    297      cleanup thread tracks, from iteration to iteration, the earliest 
    298      transaction ID still active in the system.  If this doesn't 
    299      change, from one iteration to the next, then an old transaction 
    300      is still active, and therefore a <command>VACUUM</command> will 
    301      do no good.  The cleanup thread instead merely does an 
    302      <command>ANALYZE</command> on these tables to update the 
    303      statistics in <envar>pg_statistics</envar>. 
    304      </para> 
    305     </listitem> 
    306    </varlistentry> 
    307     
    308    <varlistentry> 
    309     <term><option>-p</option><replaceable class="parameter"> PID filename</replaceable></term> 
    310     <listitem> 
    311      <para> 
    312       <envar>pid_file</envar> contains the filename in which the PID 
    313       (process ID) of the <application>slon</application> is stored. 
    314      </para> 
    315  
    316      <para> 
    317       This may make it easier to construct scripts to monitor multiple 
    318       <application>slon</application> processes running on a single 
    319       host. 
    320      </para> 
    321     </listitem> 
    322    </varlistentry> 
    323     
    324    <varlistentry> 
    325     <term><option>-f</option><replaceable class="parameter"> config file</replaceable></term> 
    326     <listitem> 
    327      <para> 
    328       File from which to read <application>slon</application> configuration. 
    329      </para> 
    330  
    331      <para> This configuration is  discussed  further  in <link  
    332      linkend="runtime-config">Slon  Run-time Configuration</link>. If there are to be a complex set of 
    333      configuration parameters, or if there are parameters you do not 
    334      wish to be visible in the process environment variables (such as 
    335      passwords), it may be convenient to draw many or all parameters 
    336      from a configuration file.  You might either put common 
    337      parameters for all slon processes in a commonly-used 
    338      configuration file, allowing the command line to specify little 
    339      other than the connection info.  Alternatively, you might create 
    340      a configuration file for each node.</para> 
    341  
    342     </listitem> 
    343    </varlistentry> 
    344    <varlistentry> 
    345     <term><option>-a</option><replaceable class="parameter"> archive directory</replaceable></term> 
    346     <listitem> 
    347      <para> 
    348       <envar>archive_dir</envar> indicates a directory in which to 
    349       place a sequence of <command>SYNC</command> archive files for 
    350       use in &logshiplink; mode. 
    351      </para> 
    352     </listitem> 
    353    </varlistentry> 
    354  
    355  
    356    <varlistentry> 
    357     <term><option>-x</option><replaceable class="parameter"> command to run on log archive</replaceable></term> 
    358     <listitem> 
    359      <para> 
    360       <envar>command_on_logarchive</envar> indicates a command to be run  
    361       each time a SYNC file is successfully generated. 
    362      </para> 
    363  
    364      <para> See more details on <xref linkend="slon-config-command-on-logarchive"/>.</para> 
    365     </listitem> 
    366    </varlistentry> 
    367  
    368  
    369    <varlistentry> 
    370     <term><option>-q</option><replaceable class="parameter"> quit based on SYNC provider </replaceable></term> 
    371     <listitem> 
    372      <para> 
    373       <envar>quit_sync_provider</envar> indicates which provider's 
    374       worker thread should be watched in order to terminate after a 
    375       certain event.  This must be used in conjunction with the 
    376       <option>-r</option> option below... 
    377      </para> 
    378  
    379      <para> This allows you to have a <application>slon</application> 
    380      stop replicating after a certain point. </para> 
    381     </listitem> 
    382    </varlistentry> 
    383  
    384    <varlistentry> 
    385     <term><option>-r</option><replaceable class="parameter"> quit at event number </replaceable></term> 
    386     <listitem> 
    387      <para> 
    388       <envar>quit_sync_finalsync</envar> indicates the event number 
    389       after which the remote worker thread for the provider above 
    390       should terminate.  This must be used in conjunction with the 
    391       <option>-q</option> option above... 
    392      </para> 
    393     </listitem> 
    394    </varlistentry> 
    395  
    396    <varlistentry> 
    397     <term><option>-l</option><replaceable class="parameter"> lag interval </replaceable></term> 
    398     <listitem> 
    399      <para> 
    400       <envar>lag_interval</envar> indicates an interval value such as 
    401       <command> 3 minutes </command> or <command> 4 hours </command> 
    402       or <command> 2 days </command> that indicates that this node is 
    403       to lag its providers by the specified interval of time.  This 
    404       causes events to be ignored until they reach the age 
    405       corresponding to the interval. 
    406      </para> 
    407  
    408      <warning><para> There is a concommittant downside to this lag; 
    409      events that require all nodes to synchronize, as typically 
    410      happens with <xref linkend="stmtfailover"/> and <xref 
    411      linkend="stmtmoveset"/>, will have to wait for this lagging 
    412      node. </para> 
    413  
    414      <para> That might not be ideal behaviour at failover time, or at 
    415      the time when you want to run <xref 
    416      linkend="stmtddlscript"/>. </para></warning> 
     278    <term><option>-c</option><replaceable class="parameter"> cycles de nettoyage</replaceable></term> 
     279    <listitem> 
     280     <para> 
     281      La valeur <envar>vac_frequency</envar> indique la fréquence des opérations 
     282      <command>VACUUM</command> lors des cycles de nettoyage. 
     283     </para> 
     284     <para> 
     285      Positionner cette valeur à zéro pour désactiver les nettoyages  
     286      initiés par <application>slon</application>. Si vous utilisés un  
     287      mécanisme tel que <application>pg_autovacuum</application> pour 
     288      lancer les vacuums, vous n'aurez probablement pas besoin que 
     289      slon initie des vacuums de lui-même. Sinon, il existe des tables 
     290      utilisées par <productname>Slony-I</productname> qui collectent  
     291      <emphasis>beaucoup</emphasis> de tuples morts, et qui doivent 
     292      être nettoyées fréquemment, en particulier &pglistener;. 
     293     </para> 
     294 
     295     <para> A partir de &slony1; version 1.1, cela change un peu; le processus 
     296       de nettoyage cherche, d'itération en itération, l'identifiant 
     297       de la plus ancienne transaction encore active dans le systÚme. 
     298       Si l'identifiant ne change pas entre deux itérations, alors  
     299       il existe une vieille transaction en activité, et donc un 
     300       <command>VACUUM</command> n'apportera rien de bon. A la place,  
     301       le processus de nettoyage déclenche simplement une opération <command>ANALYZE</command> 
     302       sur ces tables afin de mettre à jours les statistiques dans <envar>pg_statistics</envar>. 
     303     </para> 
     304    </listitem> 
     305   </varlistentry> 
     306    
     307   <varlistentry> 
     308    <term><option>-p</option><replaceable class="parameter"> fichier du PID </replaceable></term> 
     309    <listitem> 
     310     <para> 
     311      La variable <envar>pid_file</envar> contient le nom du fichier dans lequel le PID 
     312      (identifiant du processus) du démon <application>slon</application> est stocké. 
     313     </para> 
     314 
     315     <para> 
     316      Cela simplifie la création de scripts de surveillance des processus  
     317      <application>slon</application> qui s'exécute sur un hÃŽte. 
     318     </para> 
     319    </listitem> 
     320   </varlistentry> 
     321    
     322   <varlistentry> 
     323    <term><option>-f</option><replaceable class="parameter"> fichier de configuration</replaceable></term> 
     324    <listitem> 
     325     <para> 
     326      Fichier qui contient la configuration <application>slon</application>. 
     327     </para> 
     328 
     329     <para> La configuration configuration est  détaillée plus loin dans le chapitre <link  
     330     linkend="runtime-config">Configuration de Slon</link>. Si  
     331     vous avez défini un ensemble complexe de paramÚtre, ou si vous ne voulez 
     332     pas que les paramÚtres soient visibles dans les variable d'environnement  
     333     ( notamment les mots de passe ), il est plus pratique de placer une partie, 
     334     voire l'ensemble des paramÚtres dans un fichier de configuration.  
     335     Vous pouvez pouvez également placer les paramÚtres communs à tous les 
     336     processus slon dans un fichier de configuration partagé et définir 
     337     en ligne de commande d'autres paramÚtres que les informations de connexions. 
     338     Vous pouvez aussi créer un fichier de configuration pour chaque noeud. 
     339     </para> 
     340 
     341    </listitem> 
     342   </varlistentry> 
     343   <varlistentry> 
     344    <term><option>-a</option><replaceable class="parameter"> répertoire des archives</replaceable></term> 
     345    <listitem> 
     346     <para> 
     347      L'option <envar>archive_dir</envar> indique le dossier dans lequel on  
     348      place la séquence de fichiers archives contenant les événements <command>SYNC</command> 
     349      utilisés en mode &logshiplink;. 
     350     </para> 
     351    </listitem> 
     352   </varlistentry> 
     353 
     354 
     355   <varlistentry> 
     356    <term><option>-x</option><replaceable class="parameter"> commande à appliquer pour l'archivage des journaux</replaceable></term> 
     357    <listitem> 
     358     <para> 
     359      Le paramÚtre <envar>command_on_logarchive</envar> indique la commande qui doit 
     360      être exécutée à chaque fois qu'un fichier SYNC est correctement généré. 
     361     </para> 
     362 
     363     <para> Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/> pour plus de détails.</para> 
     364    </listitem> 
     365   </varlistentry> 
     366 
     367 
     368   <varlistentry> 
     369    <term><option>-q</option><replaceable class="parameter"> quitter en fonction d'un fournisseur </replaceable></term> 
     370    <listitem> 
     371     <para> 
     372      L'option <envar>quit_sync_provider</envar> indique quel processus fournisseur  
     373      doit être surveiller afin d'arrêter la réplication aprÚs un événement donné. 
     374      Ceci doit être utilisé conjointement avec l'option  
     375      <option>-r</option> ci-dessous... 
     376     </para> 
     377 
     378     <para> Cela permet de stopper la réplication sur un processus <application>slon</application> 
     379     aprÚs un certain point. </para> 
     380    </listitem> 
     381   </varlistentry> 
     382 
     383   <varlistentry> 
     384    <term><option>-r</option><replaceable class="parameter"> quitte aprÚs un numéro d'événement </replaceable></term> 
     385    <listitem> 
     386     <para> 
     387      Le paramÚtre <envar>quit_sync_finalsync</envar> indique le numéro de l'événement 
     388      aprÚs lequel un processus de réplication doit se terminer.   
     389      Ceci doit être utilisé conjointement avec l'option  
     390      <option>-q</option> ci-dessus... 
     391     </para> 
     392    </listitem> 
     393   </varlistentry> 
     394 
     395   <varlistentry> 
     396    <term><option>-l</option><replaceable class="parameter">  interval de retard </replaceable></term> 
     397    <listitem> 
     398     <para> 
     399      L'option <envar>lag_interval</envar> spécifie une valeur temporelle  
     400      ( en anglais ) telle que <command> 3 minutes </command>, <command> 4 hours </command> 
     401      ou <command> 2 days </command> qui indique que le temps de retard qu'un noeud doit avoir 
     402      par rapport à son fournisseur. Cela implique que les événements seront 
     403      ignorés tant que leur age sera inférieur à cet intervalle. 
     404     </para> 
     405 
     406     <warning><para> Il y a un effet secondaire à ce retard; 
     407     Les événements qui demande que tous les noeuds se synchronisent,  
     408     notamment ceux qui sont produits lors d'une opération <xref linkend="stmtfailover"/>  
     409     et d'un <xref linkend="stmtmoveset"/>, devront attendre pendant cet interval 
     410     de temps.</para> 
     411 
     412     <para> C'est un comportement qui n'est pas idéal dans le cas d'une bascule 
     413       aprÚs une panne, ou lorsque l'on veut exécuter des scripts DDL ( <xref 
     414     linkend="stmtddlscript"/> ). </para></warning> 
    417415    </listitem> 
    418416   </varlistentry> 
    …… 
    421419 </refsect1> 
    422420 <refsect1> 
    423   <title>Exit Status</title> 
     421  <title>Valeur de retour ( "Exit Status" ) </title> 
    424422  <para> 
    425    <application>slon</application> returns 0 to the shell if it 
    426    finished normally.  It returns via <function>exit(-1)</function> 
    427    (which will likely provide a return value of either 127 or 255, 
    428    depending on your system) if it encounters any fatal error. 
     423   <application>slon</application> renvoie 0 dans le shell si il s'est terminé 
     424   normalement. En cas d'erreur fatale, il exécute la fonction <function>exit(-1)</function> 
     425   ( qui envoie en général un valeur de retour de 127 ou 255, suivant votre systÚme d'exploitation ) 
     426   . 
    429427  </para> 
    430428 </refsect1>