[Trad] [svn:pgfr] r1254 - traduc/trunk/slony

admin at listes.postgresql.fr admin at listes.postgresql.fr
Mer 25 Fév 13:59:39 CET 2009


Author: gleu
Date: 2009-02-25 13:59:38 +0100 (Wed, 25 Feb 2009)
New Revision: 1254

Modified:
   traduc/trunk/slony/adminscripts.xml
   traduc/trunk/slony/bestpractices.xml
   traduc/trunk/slony/failover.xml
   traduc/trunk/slony/firstdb.xml
   traduc/trunk/slony/maintenance.xml
   traduc/trunk/slony/slonconf.xml
Log:
Derni?\195?\168res traductions de la version 2.0.0.


Modified: traduc/trunk/slony/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml	2009-02-24 19:22:04 UTC (rev 1253)
+++ traduc/trunk/slony/adminscripts.xml	2009-02-25 12:59:38 UTC (rev 1254)
@@ -226,16 +226,15 @@
 </para>
 
 <para>
-  This represents a pretty big potential <quote>foot gun</quote>
-  as this eliminates a replication set all at once.  A typo that points
-  it to the wrong set could be rather damaging.  Compare to <xref
-  linkend="slonik-unsubscribe-set"/> and <xref
-  linkend="slonik-drop-node"/>; with both of those, attempting to drop a
-  subscription or a node that is vital to your operations will be
-  blocked (via a foreign key constraint violation) if there exists a
-  downstream subscriber that would be adversely affected.  In contrast,
-  there will be no warnings or errors if you drop a set; the set will
-  simply disappear from replication.
+  Ceci représente un risque potentiellement très dangereux car cela élimine
+  un ensemble de réplication complet en une commande. Une erreur de saisie qui
+  indiquerait un mauvais ensemble serait dévastateur. À comparer avec <xref
+  linkend="slonik-unsubscribe-set"/> et <xref linkend="slonik-drop-node"/>&nbsp;; 
+  avec ces deux-là, tenter de supprimer un abonnement ou un n&oelig;ud vital à
+  vos opérations sera bloqué (via une constrainte de clé étrangère) s'il existe
+  un abonné qui pourrait être affecté. En contraste, il n'y aura pas de
+  messages d'avertissements ou d'erreurs si vous supprimez un ensemble&nbsp;;
+  l'ensemble disparaitra tout simplement de la réplication.
 </para>
 
 </sect3>
@@ -579,124 +578,130 @@
 <title>start_slon.sh</title>
 
 <para>
-  This <filename>rc.d</filename>-style script was introduced in
-  &slony1; version 2.0; it provides automatable ways of:
+  Ce script du style <filename>rc.d</filename> est disponible à partir de la
+  version 2.0 de &slony1;&nbsp;; il fournit un moyen automatique de&nbsp;:
 </para>
 
 <itemizedlist>
   <listitem>
     <para>
-      Starting the &lslon;, via <command> start_slon.sh start </command>
+      Démarrer &lslon;, via la commande <command>start_slon.sh start</command>
     </para>
   </listitem>
 </itemizedlist>
 
 <para>
-  Attempts to start the &lslon;, checking first to verify that it
-  is not already running, that configuration exists, and that the log
-  file location is writable.  Failure cases include:
+  Il essaie de démarrer &lslon;, en vérifiant au préalable qu'il n'est pas
+  déjà en cours d'exécution, que la configuration existe et qu'il dispose des
+  droits pour écrire sur le journal applicatif associé. Voici les échecs
+  possibles&nbsp;:
 </para>
 
 <itemizedlist>
   <listitem>
     <para>
-      No <link linkend="runtime-config"> slon runtime configuration file </link> exists,
+      Il n'y a pas de <link linkend="runtime-config">fichier de configuration
+      slon</link>.
     </para>
   </listitem>
   
   <listitem>
     <para>
-      A &lslon; is found with the PID indicated via the runtime configuration,
+      Un processus &lslon; est trouvé avec le PID indiqué via la configuration.
     </para>
   </listitem>
   
   <listitem>
     <para>
-      The specified <envar>SLON_LOG</envar> location is not writable.
+      L'emplacement spécifié via <envar>SLON_LOG</envar> n'est pas disponible en
+      écriture.
     </para>
   </listitem>
   
   <listitem>
     <para>
-      Stopping the &lslon;, via <command> start_slon.sh stop </command>
+      Arrêt du &lslon;, via <command>start_slon.sh stop</command>
     </para>
     
     <para>
-      This fails (doing nothing) if the PID (indicated via the runtime configuration file) does not exist;
+      Ceci échoue (ne fait rien) si le PID (indiqué via le fichier de
+      configuration) n'existe pas.
     </para>
   </listitem>
   
   <listitem>
     <para>
-      Monitoring the status of the &lslon;, via <command> start_slon.sh status </command>
+      Surveiller le statut de &lslon;, via <command>start_slon.sh status</command>
     </para>
     
     <para>
-      This indicates whether or not the &lslon; is running, and, if so, prints out the process ID.
+      Ceci indique si le processus &lslon; est en cours d'exécution et, dans ce
+      cas, affiche l'identifiant du processus.
     </para>
   </listitem>
 </itemizedlist>
 
 <para>
-  The following environment variables are used to control &lslon; configuration:
+  Les variables d'environnement suivantes sont utilisées pour contrôler la
+  configuration de &lslon;&nbsp;:
 </para>
 
 <glosslist>
   <glossentry>
     <glossterm>
-      <envar> SLON_BIN_PATH </envar>
+      <envar>SLON_BIN_PATH</envar>
     </glossterm>
     
     <glossdef>
       <para>
-        This indicates where the &lslon; binary program is found.
+        Ceci indique où trouver le programme &lslon;.
       </para>
     </glossdef>
   </glossentry>
   
   <glossentry>
     <glossterm>
-      <envar> SLON_CONF </envar>
+      <envar>SLON_CONF</envar>
     </glossterm>
     
     <glossdef>
       <para>
-        This indicates the location of the <link linkend="runtime-config"> slon
-	runtime configuration file </link> that controls how the &lslon; behaves.
+        Ceci indique l'emplacement du <link linkend="runtime-config">fichier
+	de configuration slon</link> contrôlant le comportement de &lslon;.
       </para>
       
       <para>
-        Note that this file is <emphasis>required</emphasis> to contain a value
-	for <link linkend="slon-config-logging-pid-file">log_pid_file</link>;
-	that is necessary to allow this script to detect whether the &lslon; is
-	running or not.
+        Notez que ce fichier <emphasis>doit</emphasis> contenir la valeur de
+	l'option <link linkend="slon-config-logging-pid-file">log_pid_file</link>&nbsp;;
+	c'est nécessaire pour permettre à ce script de détecter si &lslon; est
+	en cours d'exécution.
       </para>
     </glossdef>
   </glossentry>
   
   <glossentry>
     <glossterm>
-      <envar> SLON_LOG </envar>
+      <envar>SLON_LOG</envar>
     </glossterm>
     
     <glossdef>
       <para>
-        This file is the location where &lslon; log files are to be stored,
-	if need be.  There is an option <xref
-	linkend ="slon-config-logging-syslog"/> for &lslon; to use
-	<application>syslog</application> to manage logging; in that case,
-	you may prefer to set <envar>SLON_LOG</envar> to
-	<filename>/dev/null</filename>.
+        Cette option indique l'emplacement où les journaux applicatifs de &lslon;
+	sont stockés. Il existe une option <xref
+	linkend ="slon-config-logging-syslog"/> pour que &lslon; utilise
+	<application>syslog</application> pour gérer ses journaux
+	applicatifs&nbsp;; dans ce cas, vous pouvez configurer
+	<envar>SLON_LOG</envar> à <filename>/dev/null</filename>.
       </para>
     </glossdef>
   </glossentry>
 </glosslist>
 
 <para>
-  Note that these environment variables may either be set, in the
-  script, or overridden by values passed in from the environment.  The
-  latter usage makes it easy to use this script in conjunction with the
-  <xref linkend="testbed"/> so that it is regularly tested.
+  Notez que ces variables d'environnement peuvent être configurées soit dans le
+  script soit dans les valeurs passées dans l'environnement. Ce dernier rend
+  l'utilisation de ce script plus simple lorsqu'il combine <xref linkend="testbed"/>
+  pour être régulièrement testé.
 </para>
 
 </sect2>
@@ -707,10 +712,10 @@
 
 <para>
   Voici un autre script shell qui utilise la configuration produite par
-  <filename>mkslonconf.sh</filename> and is intended to support an approach
-  to running &slony1; involving regularly
-  (<emphasis>e.g.</emphasis> via a cron process) checking to ensure that
-  &lslon; processes are running
+  <filename>mkslonconf.sh</filename> et qui a pour but de supporter une
+  approche sur l'exécution de &slony1; consistant à vérifier régulièrement
+  (<emphasis>c'est-à-dire</emphasis> avec un cron) que les processus &lslon;
+  sont en cours d'exécution.
 </para>
 
 <para>

Modified: traduc/trunk/slony/bestpractices.xml
===================================================================
--- traduc/trunk/slony/bestpractices.xml	2009-02-24 19:22:04 UTC (rev 1253)
+++ traduc/trunk/slony/bestpractices.xml	2009-02-25 12:59:38 UTC (rev 1254)
@@ -163,10 +163,10 @@
     </para>
 
     <para>
-      Most pointedly, any node that is expected to be a failover
-      target must have its subscription(s) set up with the option
-      <command>FORWARD = YES</command>.  Otherwise, that node is not a
-      candidate for being promoted to origin node.
+      Plus précisément, tout n&oelig;ud qui a pour but d'être une cible dans
+      le cadre d'une bascule doit avoir ces abonnements configurés avec
+      l'option <command>FORWARD = YES</command>. Autrement, ce n&oelig;ud
+      ne peut pas être un candidat pour devenir n&oelig;ud origine.
     </para>
 
     <para>
@@ -255,9 +255,10 @@
       réseau</quote> que le n&oelig;ud d'origine, afin que la liaison entre
       eux soit une connexion <quote>locale</quote>. N'établissez
       <emphasis>pas</emphasis> ce genre de liaison à travers un réseau WAN.
-      Thus, if you have nodes in London and nodes in New
-      York, the &lslon;s managing London nodes should run in London, and the
-      &lslon;s managing New York nodes should run in New York.
+      Donc, si vous avez des n&oelig;uds à Londres et d'autres à New York,
+      les processus &lslon; gérant les n&oelig;uds de Londres devraient être
+      exécutés à Londres, et les processus &lslon; gérant les n&oelig;uds
+      de New York devraient être exécutés à New York.
     </para>
 
     <para>
@@ -419,10 +420,11 @@
       verrou exclusif sur ces objets&nbsp;; ainsi le <command>script
       d'exécution des modifications</command> entraîne un verrou exclusif sur
       <emphasis>toutes</emphasis> les tables répliquées. Cela peut s'avérer
-      très problématique si les applications fonctionnent when running DDL;
-      &slony1; is asking for those exclusive table locks, whilst,
-      simultaneously, some application connections are gradually relinquishing
-      locks, whilst others are backing up behind the &slony1; locks.
+      très problématique si les applications fonctionnent alors que des
+      instructions DDL sont en cours d'exécution&nbsp;; &slony1; demande pour
+      elles des verrous exclusifs sur les tables alors que, simultanément,
+      certaines connexions renoncent graduellement à des verrous et que d'autres
+      récupèrent les verrous &slony1;.
     </para>
 
     <para>
@@ -670,8 +672,8 @@
 
   <listitem>
     <para>
-      Run &lteststate; frequently to discover configuration
-      problems as early as possible.
+      Exécutez &lteststate; fréquemment pour découvrir les problèmes de
+      configuration aussi rapidement que possible.
     </para>
 
     <para>
@@ -692,11 +694,11 @@
     </para>
 
     <para>
-      It will also notice a number of sorts of situations where something
-      has broken.  Not only should it be run when problems have been noticed
-      - it should be run frequently (<emphasis>e.g.</emphasis> - hourly, or
-      thereabouts) as a general purpose <quote>health check</quote> for each
-      &slony1; cluster.
+      Il remarquera un ensemble de situations où quelque chose a cassé. Il doit
+      être utilisé quand des problèmes ont été remarqués, mais il devrait aussi
+      être utilisé fréquemment (<emphasis>c'est-à-dire</emphasis> environ toutes
+      les heures) comme un outil de vérification de la <quote>santé</quote>
+      pour chaque cluster &slony1;.
     </para>
   </listitem>
     
@@ -758,13 +760,13 @@
     </para>
       
     <para>
-      It is also a very good idea to change &lslon; configuration for
-      <xref linkend="slon-config-sync-interval"/> on the origin node to
-      reduce how many <command>SYNC</command> events are generated.  If the
-      subscription takes 8 hours, there is little sense in there being 28800
-      <command>SYNC</command>s waiting to be applied.  Running a
-      <command>SYNC</command> every minute or so is likely to make catching
-      up easier.
+      Une bonne idée est de modifier le paramètre <xref
+      linkend="slon-config-sync-interval"/> de &lslon; sur le n&oelig,ud origine
+      pour réduire le nombre d'événements <command>SYNC</command> générés. Si
+      l'abonnement prend huit heures, il n'y a aucunintérêt à avoir 28800
+      <command>SYNC</command> en attente d'être appliqué. Exécuter un
+      <command>SYNC</command> chaque minute rendre plus facile le rattrapage du
+      retard.
     </para>
   </listitem>
 </itemizedlist>

Modified: traduc/trunk/slony/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml	2009-02-24 19:22:04 UTC (rev 1253)
+++ traduc/trunk/slony/failover.xml	2009-02-25 12:59:38 UTC (rev 1254)
@@ -176,10 +176,9 @@
 </para>
 
 <para>
-  After performing the configuration change, you should, as <xref
-  linkend="bestpractices"/>, run the &lteststate; scripts in order to
-  validate that the cluster state remains in good order after this
-  change.
+  Après avoir réalisé les modifications dans la configuration, vous devriez,
+  comme <xref linkend="bestpractices"/>, exécuter les scripts &lteststate;
+  dans l'ordre pour valider que l'état du cluster reste bon.
 </para>
 
 </sect2>
@@ -240,13 +239,13 @@
     
     <note>
       <para>
-        Note that in order for node 2 to be considered as a
-        candidate for failover, it must have been set up with the <xref
-        linkend="stmtsubscribeset"/> option <command>forwarding =
-        yes</command>, which has the effect that replication log data is
-        collected in &sllog1;/&sllog2; on node 2.  If replication log data is
-        <emphasis>not</emphasis> being collected, then failover to that node
-        is not possible.
+        Notez que, pour que le n&oelig;ud 2 soit considéré comme un candidat
+	pour la bascule, il doit avoir été configuré avec l'option
+	<command>forwarding = yes</command> de <xref linkend="stmtsubscribeset"/>,
+	ce qui a pour effet que les données du log de réplication sont conservées
+	dans &sllog1;/&sllog2; du n&oelig;ud 2. Si ces données ne sont
+        <emphasis>pas</emphasis> conservées, alors la bascule vers ce n&oelig;ud
+	n'est pas possible.
       </para>
     </note>
   </listitem>
@@ -294,10 +293,9 @@
   
   <listitem>
     <para>
-      After performing the configuration change, you should, as <xref
-      linkend="bestpractices"/>, run the &lteststate; scripts in order
-      to validate that the cluster state remains in good order after
-      this change.
+      Après avoir réalisé les modifications dans la configuration, vous devriez,
+      comme <xref linkend="bestpractices"/>, exécuter les scripts &lteststate;
+      dans l'ordre pour valider que l'état du cluster reste bon.
     </para>
   </listitem>
 </itemizedlist>

Modified: traduc/trunk/slony/firstdb.xml
===================================================================
--- traduc/trunk/slony/firstdb.xml	2009-02-24 19:22:04 UTC (rev 1253)
+++ traduc/trunk/slony/firstdb.xml	2009-02-25 12:59:38 UTC (rev 1254)
@@ -208,28 +208,28 @@
 </para>
 
 <para>
-  The example that follows uses <xref linkend="slonik"/> directly
-  (or embedded directly into scripts).  This is not necessarily the most
-  pleasant way to get started; there exist tools for building <xref
-  linkend="slonik"/> scripts under the <filename>tools</filename>
-  directory, including:
+  L'exemple qui suit utilise <xref linkend="slonik"/> directement (ou l'mebarque
+  directement dans les scripts). Ce n'est pas forcément la façon la plus
+  plaisant pour débuter&nbsp;: il existe des outils pour construire les
+  scripts de <xref linkend="slonik"/> dans le répertoire
+  <filename>tools</filename>&nbsp;:
 </para>
 
 <itemizedlist>
   <listitem>
     <para>
-      <xref linkend="altperl"/> - a set of Perl scripts that build <xref
-      linkend="slonik"/> scripts based on a single
-      <filename>slon_tools.conf</filename> file.
+      <xref linkend="altperl"/> - un ensemble de scripts Perl qui construisent
+      des scripts <xref linkend="slonik"/> basés sur un seul fichier
+      <filename>slon_tools.conf</filename>.
     </para>
   </listitem>
   
   <listitem>
     <para>
-      <xref linkend="mkslonconf"/> - a shell script (<emphasis>e.g.</emphasis>
-      - works with Bash) which, based either on self-contained configuration
-      or on shell environment variables, generates a set of <xref
-      linkend="slonik"/> scripts to configure a whole cluster.
+      <xref linkend="mkslonconf"/> - un script shell (<emphasis>ec'est-à-dire</emphasis>
+      qu'il fonctionne avec Bash) qui, en se basant soit sur sa configuration
+      interne soit sur les variables d'environnement, génère un ensemble de
+      scripts <xref linkend="slonik"/> pour configurer un cluster complet.
     </para>
   </listitem>
 </itemizedlist>
@@ -389,11 +389,11 @@
 </para>
 
 <para>
-  If you encounter problems getting this working, check over the
-  logs for the &lslon; processes, as error messages are likely to be
-  suggestive of the nature of the problem.  The tool &lteststate; is
-  also useful for diagnosing problems with nearly-functioning
-  replication clusters.
+  Si vous rencontrez des problèmes pour faire fonctionner ceci, vérifiez les
+  journaux applicatifs des processus &lslon; car il y a de fortes chances que
+  des messages d'erreur intéressants décrivent la nature du problème. L'outil
+  &lteststate; peut aussi être utile pour diagnostiquer les problèmes avec
+  des clusters de réplication pratiquement fonctionnels.
 </para>
 
 <para>
@@ -455,49 +455,49 @@
 <para>
   Si ce script renvoie <command>FAILED</command>, merci de contacter les
   développeurs sur <ulink url="http://slony.info/">http://slony.info/</ulink>.
-  Be sure to be prepared with useful diagnostic information including the
-  logs generated by &lslon; processes and the output of &lteststate;.
+  Préparez-vous aussi à fournir des informations de diagnostique, comme les
+  journaux applicatifs créés par les processus &lslon; et les résultats de la
+  commande &lteststate;.
 </para>
 
 </sect3>
 
 <sect3>
-<title>Using the altperl scripts</title>
-<indexterm><primary> altperl script example </primary></indexterm>
+<title>Utiliser les scripts altperl</title>
+<indexterm><primary>exemple d'un script altperl</primary></indexterm>
 
 <para>
-  Using the <xref linkend="altperl"/> scripts is an alternative way to
-  get started; it allows you to avoid writing slonik scripts, at least
-  for some of the simple ways of configuring &slony1;.  The
-  <command>slonik_build_env</command> script will generate output
-  providing details you need to build a
-  <filename>slon_tools.conf</filename>, which is required by these
-  scripts.  An example <filename>slon_tools.conf</filename> is provided
-  in the distribution to get you started.  The altperl scripts all
-  reference this central configuration file centralize cluster
-  configuration information. Once slon_tools.conf has been created, you
-  can proceed as follows:
+  L'utilisation des scripts <xref linkend="altperl"/> est une autre façon de
+  débuter&nbsp;; cela vous évite d'avoir à écrire les scripts slonik, au moins
+  pour certaines des façons simples de configurer &slony1;. Le script
+  <command>slonik_build_env</command> génère une sortie fournissant les détails
+  dont vous avez besoin pour créer le fichier
+  <filename>slon_tools.conf</filename>, dont la présence est nécessaire pour
+  les scripts. Un exemple de fichier <filename>slon_tools.conf</filename> est
+  fourni dans la distribution pour vous aider à commencer. Les scripts altperl
+  font tous référence à ce fichier de configuration central. Une fois que
+  slon_tools.conf est créé, vous pouvez continuer ainsi&nbsp;:
 </para>
 
 <programlisting>
-# Initialize cluster:
+# Initialisation du cluster :
 $ slonik_init_cluster  | slonik 
 
-# Start slon  (here 1 and 2 are node numbers)
+# Lancement de slon  (ici 1 et 2 sont les numéros de noeuds)
 $ slon_start 1    
 $ slon_start 2
 
-# Create Sets (here 1 is a set number)
+# Créer les ensembles (ici 1 est le numéro de l'ensemble)
 $ slonik_create_set 1 | slonik             
 
-# subscribe set to second node (1= set ID, 2= node ID)
+# abonner le second noeud à l'ensemble (1= identifiant du set, 2= identifiant du noeud)
 $ slonik_subscribe_set 1 2 | slonik
 </programlisting>
 
 <para>
-  You have now replicated your first database.  You can skip the
-  following section of documentation if you'd like, which documents more
-  of a <quote>bare-metal</quote> approach.
+  Vous avez maintenant répliqué votre première base de données. Vous pouvez
+  ignorer la section suivante de la documentation si vous le souhaitez. Elle
+  documente une approche plus complexe.
 </para>
 
 </sect3>

Modified: traduc/trunk/slony/maintenance.xml
===================================================================
--- traduc/trunk/slony/maintenance.xml	2009-02-24 19:22:04 UTC (rev 1253)
+++ traduc/trunk/slony/maintenance.xml	2009-02-25 12:59:38 UTC (rev 1254)
@@ -53,18 +53,18 @@
     <listitem>
       <para>
         Le bogue <link linkend="dupkey">violation par clef dupliquée</link> a
-	permis d'isoler a number of rather obscure &postgres; race conditions,
-	so that in modern versions of &slony1; and &postgres;, there should be
-	little to worry about.
+	permis d'isoler un certain nombre de cas d'exceptions assez obscures au
+	niveau de &postgres;. Donc, dans les versions modernes de &slony1; et
+	&postgres;, il n'y a pas lieu de s'inquiéter.
       </para>
     </listitem>
 
     <listitem>
       <para>
         À partir de la version 1.2, la fonctionnalité <quote>log
-	switching</quote> est arrivée&nbsp;;de temps en temps (by default,
-	once per week, though you may induce it by calling the stored
-        function <function>logswitch_start()</function>), elle tente
+	switching</quote> est arrivée&nbsp;;de temps en temps (par défaut
+	une fois par semaine bien que vous pouvez modifier cela en appelant
+	la procédure stockée <function>logswitch_start()</function>), elle tente
 	d'interchanger les données entre &sllog1; et &sllog2; afin de réaliser
 	un <command>TRUNCATE</command> sur les <quote>plus vieilles</quote>
 	données.
@@ -77,12 +77,12 @@
       </para>
 
       <para>
-        In version 2.0, <command>DELETE</command> is no longer used to
-        clear out data in &sllog1; and &sllog2;; instead, the log switch logic
-        is induced frequently, every time the cleanup loop does not find a
-        switch in progress, and these tables are purely cleared out
-        via <command>TRUNCATE</command>.  This eliminates the need to vacuum
-        these tables.
+        En version 2.0, <command>DELETE</command> n'est plus utilisé pour
+	nettoyer les données dans &sllog1; et &sllog2;&nbsp;; à la place, la
+	logique de la bascule des logs est utilisée fréquemment, à chaque fois
+	que la boucle de nettoyage ne trouve pas une bascule en cours. Cela
+	permet de nettoyer proprement ces tables via <command>TRUNCATE</command>.
+	Ceci élimine le besoin d'un VACUUM pour ces tables.
       </para>
     </listitem>
   </itemizedlist>

Modified: traduc/trunk/slony/slonconf.xml
===================================================================
--- traduc/trunk/slony/slonconf.xml	2009-02-24 19:22:04 UTC (rev 1253)
+++ traduc/trunk/slony/slonconf.xml	2009-02-25 12:59:38 UTC (rev 1254)
@@ -299,12 +299,11 @@
         </para>
 
         <para>
-	  This parameter is primarily of concern on nodes that
-          originate replication sets.  On a non-origin node, there
-          will never be update activity that would induce a SYNC;
-          instead, the timeout value described below will induce a
-          SYNC every so often <emphasis>despite absence of changes to
-          replicate</emphasis>.
+	  Ce paramètre est principalement intéressant sur les n&oelig;uds origines
+	  des ensembles de réplication. Sur les autres n&oelig;uds, il n'y aura
+	  pas d'activité de mise à jour qui pourrait induire un SYNC&nbsp;; à
+	  la place, le délai décrit ci-dessous induit un SYNC à cette fréquence
+	  <emphasis>même en absence de modifications du réplicat</emphasis>.
 	</para>
       </listitem>
     </varlistentry>
@@ -338,47 +337,43 @@
         </para>
 
         <para>
-	  This parameter is likely to be primarily of concern on
-          nodes that originate replication sets, though it does affect
-          how often events are generated on other nodes.
+	  Ce paramètre peut rapidement devenir important pour les n&oelig;uds
+	  orgines bien qu'il affecte la faàon dont les événements sont générés
+	  sur les autes n&oelig;uds.
 	</para>
 
 	<para>
-          On a non-origin node, there never is activity to cause a
-          SYNC to get generated; as a result, there will be a SYNC
-          generated every <envar>sync_interval_timeout</envar>
-          milliseconds.  There are no subscribers looking for those
-          SYNCs, so these events do not lead to any replication
-          activity.  They will, however, clutter sl_event up a little,
-          so it would be undesirable for this timeout value to be set
-          too terribly low.  120000ms represents 2 minutes, which is
-          not a terrible value.
+          sur un n&oelig;ud qui n'est pas une origine, il n'y a aucune activité
+	  réclamant la génération d'un SYNC&nbsp;; du coup, il va y avoir un
+	  SYNC généré chaque <envar>sync_interval_timeout</envar> milli-secondes.
+	  Il n'y a pas d'abonnés cherchant ces SYNC, donc ces événements ne
+	  vont pas déclencher une activité de réplication. Par contre, ils
+	  vont occuper sl_event un moment, donc il est fortement indésirable
+	  que cette valeur soit basse. 120000ms représente 2 minutes, ce qui
+	  n'est pas une mauvaise valeur.
         </para>
 
 	<para>
-	  The two values function together in varying ways:
+	  Les deux valeurs fonctionnent ensemble de façon différente&nbsp;:
 	</para>
 
 	<para>
-	  On an origin node, <envar>sync_interval</envar> is
-	  the <emphasis>minimum</emphasis> time period that will be
-	  covered by a SYNC, and during periods of heavy application
-	  activity, it may be that a SYNC is being generated
-	  every <envar>sync_interval</envar> milliseconds.
+	  Sur un n&oelig;ud origine, <envar>sync_interval</envar> est la période
+	  de temps <emphasis>minimum</emphasis> qui sera couverte par un SYNC,
+	  et, durant les périodes de grosse activité, il se pourrait qu'un
+	  SYNC soit généré toutes les <envar>sync_interval</envar> millisecondes.
 	</para>
 
 	<para>
-	  On that same origin node, there may be quiet intervals,
-	  when no replicatable changes are being submitted.  A SYNC will
-	  be induced, anyways,
-	  every <envar>sync_interval_timeout</envar>
-	  milliseconds.
+	  Sur le meme n&oelig;ud origine, il peut y avoir des intervalles assez
+	  calmes, quand aucune modification réplicable de données n'est soumise.
+	  Un SYNC aura quand meme lieu, chaque <envar>sync_interval_timeout</envar>
+	  millisecondes.
 	</para>
 
 	<para>
-	  On a subscriber node that does not originate any sets,
-	  only the <quote>timeout-induced</quote> SYNCs will
-	  occur.
+	  Sur un n&oelig;ud abonné qui n'est l'origine d'aucun ensemble, seuls
+	  des SYNC <quote>de délai</quote> seront générés.
 	</para>
       </listitem>
     </varlistentry>
@@ -391,18 +386,16 @@
       </term>
       <listitem>
         <para>
-          Maximum number of <command>SYNC</command> events that a
-          subscriber node will group together when/if a subscriber
-          falls behind.  <command>SYNC</command>s are batched only if
-          there are that many available and if they are
-          contiguous.  Every other event type in between leads to a
-          smaller batch.  And if there is only
-          one <command>SYNC</command> available, even though you used
-          <option>-g600</option>, the &lslon; will apply just the one
-          that is available.  As soon as a subscriber catches up, it
-          will tend to apply each
-          <command>SYNC</command> by itself, as a singleton, unless
-          processing should fall behind for some reason.
+          Nombre maximum d'événements <command>SYNC</command> qu'un n&oelig;ud
+	  abonné groupera ensemble quand/si un abonné accuse trop de retard.
+          <command>SYNC</command> sont seulement groupés s'il sont trop nombreux
+	  et s'ils sont contigus. Tout autre type d'événement inséré entre
+	  entrainera la création d'un groupe plus petit. Et si un seul
+          <command>SYNC</command> est disponible, alors que vous avez utilisé
+	  l'option <option>-g600</option>, &lslon; n'appliquera que celui qui
+	  est disponible. Dès que l'abonné a rattrapé son retard, il cherchera
+	  à appliquer chaque <command>SYNC</command> séparément, en solo, sauf si
+	  le traitement entraîne à nouveau un retard.
 	  Valeurs possibles&nbsp;: [0,10000]. Valeur par défaut&nbsp;: 20.
         </para>
       </listitem>



More information about the Trad mailing list