[Trad] [svn:pgfr] r1110 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Dim 27 Juil 13:33:44 CEST 2008
Author: daamien
Date: 2008-07-27 13:33:44 +0200 (Sun, 27 Jul 2008)
New Revision: 1110
Modified:
traduc/trunk/slony/slon.xml
Log:
Slony : slon.xml / 1ere trad ?\195?\160 relire
Modified: traduc/trunk/slony/slon.xml
===================================================================
--- traduc/trunk/slony/slon.xml 2008-07-24 08:25:32 UTC (rev 1109)
+++ traduc/trunk/slony/slon.xml 2008-07-27 11:33:44 UTC (rev 1110)
@@ -13,7 +13,7 @@
<refnamediv>
<refname><application>slon</application></refname>
<refpurpose>
- &slony1; daemon
+ Le démon &slony1;
</refpurpose>
</refnamediv>
@@ -33,10 +33,10 @@
<refsect1>
<title>Description</title>
<para>
- <application>slon</application> is the daemon application that
- <quote>runs</quote> &slony1; replication. A
- <application>slon</application> instance must be run for each node
- in a &slony1; cluster.
+ <application>slon</application> est un démon applicatif qui
+ <quote>contrôle</quote> la réplication &slony1;. Une
+ instance <application>slon</application> doit être lancée pour
+ chaque noeud du cluster &slony1;.
</para>
</refsect1>
@@ -48,12 +48,11 @@
<term><option>-d</option><replaceable class="parameter"> log_level</replaceable></term>
<listitem>
<para>
- The <envar>log_level</envar> specifies which levels of debugging messages
- <application>slon</application> should display when logging its
- activity.
+ Le paramètre <envar>log_level</envar> spécifie quel niveau de messages de debug
+ <application>slon</application> doit afficher dans son journal d'activité.
</para>
<para id="nineloglevels">
- The nine levels of logging are:
+ Il y a neuf niveaux de log :
<itemizedlist>
<listitem><para>Fatal</para></listitem>
<listitem><para>Error</para></listitem>
@@ -67,365 +66,364 @@
</itemizedlist>
</para>
- <para> The first five non-debugging log levels (from Fatal to
- Info) are <emphasis>always</emphasis> displayed in the logs. In
- early versions of &slony1;, the <quote>suggested</quote>
- <envar>log_level</envar> value was 2, which would list output at
- all levels down to debugging level 2. In &slony1; version 2, it
- is recommended to set <envar>log_level</envar> to 0; most of the
- consistently interesting log information is generated at levels
- higher than that. </para>
+ <para> Les cinq premiers niveau de log ( de Fatal à
+ Info) sont <emphasis>toujours</emphasis> affichés dans les logs.
+ Dans les premières versions de &slony1;, le niveau de log
+ <quote>suggéré</quote> était 2, ce qui affichait tous les messages
+ jusqu'au niveau Debug2. Avec &slony1; version 2, il est
+ recommandé de positionner <envar>log_level</envar> à 0; la
+ pluspart des informations intéressantes sont produites à
+ des niveaux supérieurs à celui-là.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-s</option><replaceable class="parameter"> SYNC check interval</replaceable></term>
+ <term><option>-s</option><replaceable class="parameter"> Interval entre les vérifications SYNC</replaceable></term>
<listitem>
<para>
- The <envar>sync_interval</envar>, measured in milliseconds,
- indicates how often <application>slon</application> should check
- to see if a <command>SYNC</command> should be introduced.
- Default is 2000 ms. The main loop in
- <function>sync_Thread_main()</function> sleeps for intervals of
- <envar>sync_interval</envar> milliseconds between iterations.
+ Le paramètre <envar>sync_interval</envar>, exprimé en millisecondes,
+ indique à quelle fréquence <application>slon</application> doit
+ vérifier si un événement <command>SYNC</command> doit
+ être produit. La valeur par défaut est 2000 ms. La boucle principale
+ dans <function>sync_Thread_main()</function> est endormie pendant
+ des intervalles de <envar>sync_interval</envar> millisecondes
+ entre chaque itérations.
</para>
<para>
- Short sync check intervals keep the origin on a <quote>short
- leash</quote>, updating its subscribers more frequently. If you
- have replicated sequences that are frequently updated
- <emphasis>without</emphasis> there being tables that are
- affected, this keeps there from being times when only sequences
- are updated, and therefore <emphasis>no</emphasis> syncs take
- place
+ Un intervalle de vérifications très court garantit que le noeud
+ origine soit <quote>très suivi</quote>, car il met à jour les abonnés
+ plus fréquemment. Si vous avez des séquences répliquées qui sont
+ souvent mises à jour <emphasis>sans</emphasis> que certaines tables
+ ne soient affectées, cela évite que des opérations qui mettent
+ à jour uniquement ces séquences soient effectuées, et ainsi
+ évite la génération d'événements de synchronisations.
</para>
<para>
- If the node is not an origin for any replication set, so no
- updates are coming in, it is somewhat wasteful for this value to
- be much less the <envar>sync_interval_timeout</envar> value.
+ Si un noeud n'est pas l'origine d'un set de réplication, et donc qu'il
+ ne reçoit aucune mise à jour des données répliquées, alors il est
+ un peu inutile de mettre une valeur inférieure à celle du paramètre
+ <envar>sync_interval_timeout</envar>.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-t</option><replaceable class="parameter"> SYNC
- interval timeout</replaceable></term>
+ <term><option>-t</option><replaceable class="parameter">intervalle maximal entre deux SYNC
+ </replaceable></term>
<listitem>
<para>
- At the end of each <envar>sync_interval_timeout</envar> timeout
- period, a <command>SYNC</command> will be generated on the
- <quote>local</quote> node even if there has been no replicable
- data updated that would have caused a
- <command>SYNC</command> to be generated. </para>
+ A la fin de chaque période <envar>sync_interval_timeout</envar>
+ , un événement <command>SYNC</command> est produit sur le noeud
+ <quote>local</quote> même si il n'y eu aucune mise à jour des
+ données répliquées et qu'aucun <command>SYNC</command> n'a été
+ généré. </para>
- <para> If application activity ceases, whether because the
- application is shut down, or because human users have gone home
- and stopped introducing updates, the &lslon; will iterate away,
- waking up every <envar>sync_interval</envar> milliseconds, and,
- as no updates are being made, no <command>SYNC</command> events
- would be generated. Without this timeout parameter,
- <emphasis>no</emphasis> <command>SYNC</command> events would be
- generated, and it would appear that replication was falling
- behind. </para>
+ <para> Si l'activité de l'application s'arrête, soit parce que
+ l'application a été éteinte, soit parce que les utilisateurs humains
+ sont rentrés chez eux et arrêtés les mises à jour, alors le
+ démon &lslon; continue de tourner et se réveille toutes les
+ <envar>sync_interval</envar> millisecondes, et si aucune mise
+ à jour ne s'est produite, alors aucun événement <command>SYNC</command>
+ n'est généré. Sans ce paramètre <quote>timeout</quote>,
+ <emphasis>aucun</emphasis> événement <command>SYNC</command>
+ ne pourrait être produit, et cela entraînerait le chute du
+ système de réplication. </para>
- <para> The <envar>sync_interval_timeout</envar> value will lead
- to eventually generating a <command>SYNC</command>, even though
- there was no real replication work to be done. The lower that
- this parameter is set, the more frequently &lslon; will generate
- <command>SYNC</command> events when the application is not
- generating replicable activity; this will have two effects:</para>
+ <para> Le paramètre <envar>sync_interval_timeout</envar> provoque
+ la génération de <command>SYNC</command>, même si il n'y a pas
+ réellement de travail de réplication a faire. Plus la valeur de
+ cette paramètre est basse, plus les évènements <command>SYNC</command>
+ lorsque l'application n'est pas active. Ceci a deux 2 effets
+ :</para>
<itemizedlist>
- <listitem><para> The system will do more replication work.</para>
+ <listitem><para> Le système aura plus de travail.</para>
- <para> (Of course, since there is no application load on the
- database, and no data to replicate, this load will be very easy
- to handle. </para></listitem>
+ <para> ( Cependant puisque l'application n'utilise pas
+ la base de données et qu'il n'y a pas de données à répliquer,
+ la charge de travail supplémentaire sera assez simple à gérer.)
+ </para></listitem>
- <listitem><para> Replication will appear to be kept more
- <quote>up to date.</quote></para>
+ <listitem><para> La réplication sera tenue un peu plus <quote>à jour</quote>.</para>
- <para> (Of course, since there is no replicable activity going
- on, being <quote>more up to date</quote> is something of a
- mirage.) </para></listitem>
+ <para> ( Cependant puisqu'il n'y a pas de données à répliquer, être
+ plus souvent <quote>mis à jour</quote> est un mirage.) </para></listitem>
</itemizedlist>
<para>
- Default is 10000 ms and maximum is 120000 ms. By default, you
- can expect each node to <quote>report in</quote> with a
- <command>SYNC</command> every 10 seconds.
+ La valeur par défaut est 10000 ms et la valeur maximale est 120000 ms.
+ Par défaut, vous pouvez prévoir que chaque noeud soit
+ <quote>synchronisé</quote> par un <command>SYNC</command> toutes les 10 secondes.
</para>
<para>
- Note that <command>SYNC</command> events are also generated on
- subscriber nodes. Since they are not actually generating any
- data to replicate to other nodes, these <command>SYNC</command>
- events are of not terribly much value.
+ Notez que des événements <command>SYNC</command> sont aussi générés
+ sur chaque noeud abonné. Cependant puisqu'ils ne contiennent
+ de données à répliquer par les autres noeuds, les évènements
+ <command>SYNC</command> des noeuds abonnés ne sont pas terriblement intéressant.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-g</option><replaceable class="parameter"> group size</replaceable></term>
+ <term><option>-g</option><replaceable class="parameter"> taille du groupe</replaceable></term>
<listitem>
<para>
- This controls the maximum <command>SYNC</command> group size,
- <envar>sync_group_maxsize</envar>; defaults to 6. Thus, if a
- particular node is behind by 200 <command>SYNC</command>s, it
- will try to group them together into groups of a maximum size of
- <envar>sync_group_maxsize</envar>. This can be expected to
- reduce transaction overhead due to having fewer transactions to
- <command>COMMIT</command>.
+ L'option <envar>sync_group_maxsize</envar> contrôle la taille maximumale d'un groupe <command>SYNC</command>,
+ . La valeur par défaut est 6. Ainsi, si un noeud particulier a
+ 200 événements <command>SYNC</command>s de retard, il essaiera de les regrouper
+ par groupes dont la taille maximale sera <envar>sync_group_maxsize</envar>.
+ Ceci doit permettre de réduire le temps de lantence au démarrage (NdT : "overhead")
+ en réduisant le nombre de transactions à <quote>comitter</quoter>.
</para>
<para>
- The default of 6 is probably suitable for small systems that can
- devote only very limited bits of memory to
- <application>slon</application>. If you have plenty of memory,
- it would be reasonable to increase this, as it will increase the
- amount of work done in each transaction, and will allow a
- subscriber that is behind by a lot to catch up more quickly.
+ La valeur par défaut est 6 est probablement adéquate pour les petits systèmes
+ qui ne peuvent allouer que des quantités limitées de mémoire à
+ <application>slon</application>. Si vous avez beaucoup de mémoire
+ il est raisonnable d'augmenter cette valeur, car cela augmentera
+ la quantité de travail réalisée à chaque transaction, et cela
+ permettra a un noeud abonné de rattraper plus vite son retard.
</para>
<para>
- Slon processes usually stay pretty small; even with large value
- for this option, <application>slon</application> would be
- expected to only grow to a few MB in size.
+ Les processus Slon sont souvent très petits; même en cas
+ de valeur très forte pour cette option, <application>slon</application>
+ devrait simplement grossir de quelques MB.
</para>
<para>
- The big advantage in increasing this parameter comes from
- cutting down on the number of transaction
- <command>COMMIT</command>s; moving from 1 to 2 will provide
- considerable benefit, but the benefits will progressively fall
- off once the transactions being processed get to be reasonably
- large. There isn't likely to be a material difference in
- performance between 80 and 90; at that point, whether
- <quote>bigger is better</quote> will depend on whether the
- bigger set of <command>SYNC</command>s makes the
- <envar>LOG</envar> cursor behave badly due to consuming more
- memory and requiring more time to sortt.
+ Le gros avantage d'augmenter ce paramètre est que
+ cela divise le nombre de transaction
+ <command>COMMIT</command>s; passer de 1 to 2 aura probablement
+ un impact considérable, mais le bénéfice se réduit progressivement
+ lorsque la taille des groupes est suffisamment large.
+ Il n'y aura probablement pas de différence notable entre 80 et 90.
+ Rendu à ce niveau, l'augmentation de cette
+ valeur dépend du fait que les grands ensembles de <command>SYNC</command>s
+ perturbent les curseurs de <envar>LOG</envar> en consommant
+ de plus en plus de mémoire et nécessitant plus d'efforts lors
+ des tris.
</para>
<para>
- In &slony1; version 1.0, <application>slon</application> will
- always attempt to group <command>SYNC</command>s together to
- this maximum, which <emphasis>won't</emphasis> be ideal if
- replication has been somewhat destabilized by there being very
- large updates (<emphasis>e.g.</emphasis> - a single transaction
- that updates hundreds of thousands of rows) or by
- <command>SYNC</command>s being disrupted on an origin node with
- the result that there are a few <command>SYNC</command>s that
- are very large. You might run into the problem that grouping
- together some very large <command>SYNC</command>s knocks over a
- <application>slon</application> process. When it picks up
- again, it will try to process the same large grouped set of
- <command>SYNC</command>s, and run into the same problem over and
- over until an administrator interrupts this and changes the
- <option>-g</option> value to break this <quote>deadlock.</quote>
+ Dans &slony1; version 1.0, <application>slon</application> essaie
+ toujours de regrouper un maximum de <command>SYNC</command>s ensemble
+ , ce qui <emphasis>n'est pas</emphasis> idéal si la réplication
+ a été déstabilisée par de grosses mises à jour ( <emphasis>par exemple
+ </emphasis> : une transaction unique qui met à jour des centaines
+ de milliers de lignes) ou lorsque les <command>SYNC</command>s
+ ont été interrompus sur un noeud origine, ce qui fait
+ que les suivants sont volumineux. Vous rencontrerez
+ ce problème : en regroupant des <command>SYNC</command>s très
+ larges, le processus <application>slon</application> peut échouer.
+ Au redémarrage, il essaie a nouveau de traiter ce large ensemble
+ de <command>SYNC</command>s, et il retombe sur le même problème
+ encore et encore jusqu'à ce qu'un administrateur interrompe tout cela
+ et change la valeur de l'option <option>-g</option> pour
+ sortir de cette situation d'<quote>inter-blocage</quote>.
</para>
<para>
- In &slony1; version 1.0, the <application>slon</application>
- instead adaptively <quote>ramps up</quote> from doing 1
- <command>SYNC</command> at a time towards the maximum group
- size. As a result, if there are a couple of
- <command>SYNC</command>s that cause problems, the
- <application>slon</application> will (with any relevant watchdog
- assistance) always be able to get to the point where it
- processes the troublesome <command>SYNC</command>s one by one,
- hopefully making operator assistance unnecessary.
+ Au contraire Avec &slony1; version 1.0, le démon <application>slon</application>
+ 'adapte en augmentant <quote>progressivement</quote> le nombre de
+ <command>SYNC</command> par groupe, de 1 jusqu'à la valeur maximale.
+ Ainsi, si quelques <command>SYNC</command>s pausent problème, le démon
+ <application>slon</application> pourra (avec s'il est surveillé par
+ un processus chien de garde) traiter un par un ces évènements
+ <command>SYNC</command>s problématique, et ainsi éviter l'intervention
+ d'un administrateur.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-o</option><replaceable class="parameter"> desired sync time</replaceable></term>
- <listitem><para> A <quote>maximum</quote> time planned for grouped <command>SYNC</command>s.</para>
+ <term><option>-o</option><replaceable class="parameter"> temps de synchronisation souhaité</replaceable></term>
+ <listitem><para> La période <quote>maximale</quote> pour un groupe de <command>SYNC</command>s.</para>
- <para> If replication is running behind, slon will gradually
- increase the numbers of <command>SYNC</command>s grouped
- together, targetting that (based on the time taken for the
- <emphasis>last</emphasis> group of <command>SYNC</command>s) they
- shouldn't take more than the specified
- <envar>desired_sync_time</envar> value.</para>
+ <para> Si la réplication est en retard, le démon slon va progressivement augmenter le
+ nombre de <command>SYNC</command>s groupés ensemble, dans le but de
+ ne pas dépasser le temps spécifié par <envar>desired_sync_time</envar>.
+ (pour cela, Slon se base sur le temps pris par le
+ <emphasis>dernier</emphasis> group de <command>SYNC</command>s)
+ .</para>
- <para> The default value for <envar>desired_sync_time</envar> is
- 60000ms, equal to one minute. </para>
+ <para> La valeur par défaut est 60000ms,
+ c'est à dire une minute. </para>
- <para> That way, you can expect (or at least hope!) that you'll
- get a <command>COMMIT</command> roughly once per minute. </para>
+ <para> Ainsi vous pouvez prévoir (en tout cas espérer ! )
+ que vous aurez un <command>COMMIT</command> environ
+ toutes les minutes.</para>
- <para> It isn't <emphasis>totally</emphasis> predictable, as it
- is entirely possible for someone to request a <emphasis>very
- large update,</emphasis> all as one transaction, that can
- <quote>blow up</quote> the length of the resulting
- <command>SYNC</command> to be nearly arbitrarily long. In such a
- case, the heuristic will back off for the
- <emphasis>next</emphasis> group.</para>
+ <para> Cela n'est pas <emphasis>complètement</emphasis> prévisible,
+ car il est possible de demander une <emphasis>très grosse mise à jour
+ </emphasis>,qui fera <quote>exploser</quote> la taille du
+ <command>SYNC</command>. Dans ce cas là, l'heuristique sera
+ rétablie pour le <emphasis>prochain</emphasis> groupe.</para>
- <para> The overall effect is to improve
- <productname>Slony-I</productname>'s ability to cope with
- variations in traffic. By starting with 1 <command>SYNC</command>, and gradually
- moving to more, even if there turn out to be variations large
- enough to cause <productname>PostgreSQL</productname> backends to
- crash, <productname>Slony-I</productname> will back off down to
- start with one sync at a time, if need be, so that if it is at
- all possible for replication to progress, it will.</para>
+ <para> L'effet final est d'améliorer la façon dont
+ <productname>Slony-I</productname> gère les variations
+ du trafic. En commençant avec 1 événement <command>SYNC</command>, puis
+ en augmentant progressivement, même si certaines variations seront
+ assez grandes pour provoquer un crash du processus <productname>PostgreSQL</productname>,
+ <productname>Slony-I</productname> redémarrera en traitant un seul <command>SYNC</command>
+ à la fois, afin que poursuivre le processus de réplication autant que possible.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-c</option><replaceable class="parameter"> cleanup cycles</replaceable></term>
+ <term><option>-c</option><replaceable class="parameter"> cycles de nettoyage</replaceable></term>
<listitem>
<para>
- The value <envar>vac_frequency</envar> indicates how often to
- <command>VACUUM</command> in cleanup cycles.
+ La valeur <envar>vac_frequency</envar> indique la fréquence des opérations
+ <command>VACUUM</command> lors des cycles de nettoyage.
</para>
<para>
- Set this to zero to disable
- <application>slon</application>-initiated vacuuming. If you are
- using something like <application>pg_autovacuum</application> to
- initiate vacuums, you may not need for slon to initiate vacuums
- itself. If you are not, there are some tables
- <productname>Slony-I</productname> uses that collect a
- <emphasis>lot</emphasis> of dead tuples that should be vacuumed
- frequently, notably &pglistener;.
+ Positionner cette valeur à zéro pour désactiver les nettoyages
+ initiés par <application>slon</application>. Si vous utilisés un
+ mécanisme tel que <application>pg_autovacuum</application> pour
+ lancer les vacuums, vous n'aurez probablement pas besoin que
+ slon initie des vacuums de lui-même. Sinon, il existe des tables
+ utilisées par <productname>Slony-I</productname> qui collectent
+ <emphasis>beaucoup</emphasis> de tuples morts, et qui doivent
+ être nettoyées fréquemment, en particulier &pglistener;.
</para>
- <para> In &slony1; version 1.1, this changes a little; the
- cleanup thread tracks, from iteration to iteration, the earliest
- transaction ID still active in the system. If this doesn't
- change, from one iteration to the next, then an old transaction
- is still active, and therefore a <command>VACUUM</command> will
- do no good. The cleanup thread instead merely does an
- <command>ANALYZE</command> on these tables to update the
- statistics in <envar>pg_statistics</envar>.
+ <para> A partir de &slony1; version 1.1, cela change un peu; le processus
+ de nettoyage cherche, d'itération en itération, l'identifiant
+ de la plus ancienne transaction encore active dans le système.
+ Si l'identifiant ne change pas entre deux itérations, alors
+ il existe une vieille transaction en activité, et donc un
+ <command>VACUUM</command> n'apportera rien de bon. A la place,
+ le processus de nettoyage déclenche simplement une opération <command>ANALYZE</command>
+ sur ces tables afin de mettre à jours les statistiques dans <envar>pg_statistics</envar>.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-p</option><replaceable class="parameter"> PID filename</replaceable></term>
+ <term><option>-p</option><replaceable class="parameter"> fichier du PID </replaceable></term>
<listitem>
<para>
- <envar>pid_file</envar> contains the filename in which the PID
- (process ID) of the <application>slon</application> is stored.
+ La variable <envar>pid_file</envar> contient le nom du fichier dans lequel le PID
+ (identifiant du processus) du démon <application>slon</application> est stocké.
</para>
<para>
- This may make it easier to construct scripts to monitor multiple
- <application>slon</application> processes running on a single
- host.
+ Cela simplifie la création de scripts de surveillance des processus
+ <application>slon</application> qui s'exécute sur un hôte.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-f</option><replaceable class="parameter"> config file</replaceable></term>
+ <term><option>-f</option><replaceable class="parameter"> fichier de configuration</replaceable></term>
<listitem>
<para>
- File from which to read <application>slon</application> configuration.
+ Fichier qui contient la configuration <application>slon</application>.
</para>
- <para> This configuration is discussed further in <link
- linkend="runtime-config">Slon Run-time Configuration</link>. If there are to be a complex set of
- configuration parameters, or if there are parameters you do not
- wish to be visible in the process environment variables (such as
- passwords), it may be convenient to draw many or all parameters
- from a configuration file. You might either put common
- parameters for all slon processes in a commonly-used
- configuration file, allowing the command line to specify little
- other than the connection info. Alternatively, you might create
- a configuration file for each node.</para>
+ <para> La configuration configuration est détaillée plus loin dans le chapitre <link
+ linkend="runtime-config">Configuration de Slon</link>. Si
+ vous avez défini un ensemble complexe de paramètre, ou si vous ne voulez
+ pas que les paramètres soient visibles dans les variable d'environnement
+ ( notamment les mots de passe ), il est plus pratique de placer une partie,
+ voire l'ensemble des paramètres dans un fichier de configuration.
+ Vous pouvez pouvez également placer les paramètres communs à tous les
+ processus slon dans un fichier de configuration partagé et définir
+ en ligne de commande d'autres paramètres que les informations de connexions.
+ Vous pouvez aussi créer un fichier de configuration pour chaque noeud.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-a</option><replaceable class="parameter"> archive directory</replaceable></term>
+ <term><option>-a</option><replaceable class="parameter"> répertoire des archives</replaceable></term>
<listitem>
<para>
- <envar>archive_dir</envar> indicates a directory in which to
- place a sequence of <command>SYNC</command> archive files for
- use in &logshiplink; mode.
+ L'option <envar>archive_dir</envar> indique le dossier dans lequel on
+ place la séquence de fichiers archives contenant les événements <command>SYNC</command>
+ utilisés en mode &logshiplink;.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-x</option><replaceable class="parameter"> command to run on log archive</replaceable></term>
+ <term><option>-x</option><replaceable class="parameter"> commande à appliquer pour l'archivage des journaux</replaceable></term>
<listitem>
<para>
- <envar>command_on_logarchive</envar> indicates a command to be run
- each time a SYNC file is successfully generated.
+ Le paramètre <envar>command_on_logarchive</envar> indique la commande qui doit
+ être exécutée à chaque fois qu'un fichier SYNC est correctement généré.
</para>
- <para> See more details on <xref linkend="slon-config-command-on-logarchive"/>.</para>
+ <para> Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/> pour plus de détails.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-q</option><replaceable class="parameter"> quit based on SYNC provider </replaceable></term>
+ <term><option>-q</option><replaceable class="parameter"> quitter en fonction d'un fournisseur </replaceable></term>
<listitem>
<para>
- <envar>quit_sync_provider</envar> indicates which provider's
- worker thread should be watched in order to terminate after a
- certain event. This must be used in conjunction with the
- <option>-r</option> option below...
+ L'option <envar>quit_sync_provider</envar> indique quel processus fournisseur
+ doit être surveiller afin d'arrêter la réplication après un événement donné.
+ Ceci doit être utilisé conjointement avec l'option
+ <option>-r</option> ci-dessous...
</para>
- <para> This allows you to have a <application>slon</application>
- stop replicating after a certain point. </para>
+ <para> Cela permet de stopper la réplication sur un processus <application>slon</application>
+ après un certain point. </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-r</option><replaceable class="parameter"> quit at event number </replaceable></term>
+ <term><option>-r</option><replaceable class="parameter"> quitte après un numéro d'événement </replaceable></term>
<listitem>
<para>
- <envar>quit_sync_finalsync</envar> indicates the event number
- after which the remote worker thread for the provider above
- should terminate. This must be used in conjunction with the
- <option>-q</option> option above...
+ Le paramètre <envar>quit_sync_finalsync</envar> indique le numéro de l'événement
+ après lequel un processus de réplication doit se terminer.
+ Ceci doit être utilisé conjointement avec l'option
+ <option>-q</option> ci-dessus...
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-l</option><replaceable class="parameter"> lag interval </replaceable></term>
+ <term><option>-l</option><replaceable class="parameter"> interval de retard </replaceable></term>
<listitem>
<para>
- <envar>lag_interval</envar> indicates an interval value such as
- <command> 3 minutes </command> or <command> 4 hours </command>
- or <command> 2 days </command> that indicates that this node is
- to lag its providers by the specified interval of time. This
- causes events to be ignored until they reach the age
- corresponding to the interval.
+ L'option <envar>lag_interval</envar> spécifie une valeur temporelle
+ ( en anglais ) telle que <command> 3 minutes </command>, <command> 4 hours </command>
+ ou <command> 2 days </command> qui indique que le temps de retard qu'un noeud doit avoir
+ par rapport à son fournisseur. Cela implique que les événements seront
+ ignorés tant que leur age sera inférieur à cet intervalle.
</para>
- <warning><para> There is a concommittant downside to this lag;
- events that require all nodes to synchronize, as typically
- happens with <xref linkend="stmtfailover"/> and <xref
- linkend="stmtmoveset"/>, will have to wait for this lagging
- node. </para>
+ <warning><para> Il y a un effet secondaire à ce retard;
+ Les événements qui demande que tous les noeuds se synchronisent,
+ notamment ceux qui sont produits lors d'une opération <xref linkend="stmtfailover"/>
+ et d'un <xref linkend="stmtmoveset"/>, devront attendre pendant cet interval
+ de temps.</para>
- <para> That might not be ideal behaviour at failover time, or at
- the time when you want to run <xref
- linkend="stmtddlscript"/>. </para></warning>
+ <para> C'est un comportement qui n'est pas idéal dans le cas d'une bascule
+ après une panne, ou lorsque l'on veut exécuter des scripts DDL ( <xref
+ linkend="stmtddlscript"/> ). </para></warning>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
- <title>Exit Status</title>
+ <title>Valeur de retour ( "Exit Status" ) </title>
<para>
- <application>slon</application> returns 0 to the shell if it
- finished normally. It returns via <function>exit(-1)</function>
- (which will likely provide a return value of either 127 or 255,
- depending on your system) if it encounters any fatal error.
+ <application>slon</application> renvoie 0 dans le shell si il s'est terminé
+ normalement. En cas d'erreur fatale, il exécute la fonction <function>exit(-1)</function>
+ ( qui envoie en général un valeur de retour de 127 ou 255, suivant votre système d'exploitation )
+ .
</para>
</refsect1>
</refentry>
More information about the Trad
mailing list