[Trad] [svn:pgfr] r1072 - traduc/trunk/slony
svncommit at kryskool.org
svncommit at kryskool.org
Mer 11 Juin 11:04:25 CEST 2008
Auteur: daamien
Date: 2008-06-11 11:04:23 +0200 (mer, 11 jun 2008)
Nouvelle Révision: 1072
Modification:
traduc/trunk/slony/maintenance.xml
Log:
1ere traduction à relire
Modified: traduc/trunk/slony/maintenance.xml
===================================================================
--- traduc/trunk/slony/maintenance.xml 2008-06-09 08:08:19 UTC (rev 1071)
+++ traduc/trunk/slony/maintenance.xml 2008-06-11 09:04:23 UTC (rev 1072)
@@ -4,92 +4,127 @@
par $Author$
révision $Revision$ -->
-<sect1 id="maintenance"> <title>&slony1; Maintenance</title>
+<sect1 id="maintenance"> <title>Maintenance</title>
-<indexterm><primary>maintaining &slony1;</primary></indexterm>
+<indexterm><primary>maintenir &slony1;</primary></indexterm>
-<para>&slony1; actually does a lot of its necessary maintenance
-itself, in a <quote>cleanup</quote> thread:
+<para>&slony1; effectue une grande partie de sa maintenance
+de lui-même, dans un processus de <quote>
+nettoyage</quote> qui :
<itemizedlist>
-<listitem><para> Deletes old data from various tables in the
-<productname>Slony-I</productname> cluster's namespace, notably
-entries in <xref linkend="table.sl-log-1"/>, <xref
+<listitem><para>supprime les anciennes donnéessur
+les différentes tables d'espace de nom de
+du cluster <productname>Slony-I</productname>,
+notamment <xref linkend="table.sl-log-1"/>, <xref
linkend="table.sl-log-2"/>, and <xref
-linkend="table.sl-seqlog"/>.</para></listitem>
+linkend="table.sl-seqlog"/>;</para></listitem>
-<listitem><para> Vacuum certain tables used by &slony1;. As of 1.0.5,
-this includes &pglistener;; in earlier versions, you must vacuum that
-table heavily, otherwise you'll find replication slowing down because
-&slony1; raises plenty of events, which leads to that table having
-plenty of dead tuples.</para>
+<listitem><para>effectue un vacuum sur certaines
+tables utilisées par &slony1;.
+A partir de la version 1.0.5, ceci inclut &pglistener;;
+dans les versions antérieures, vous devez lancer
+souvent des vacuums sur cette table, sinon
+vous verrez votre réplication ralentir
+car &slony1; lève beaucoup d'événets,
+qui mènent à table à contenir de nombreux
+tuples morts.
+</para>
-<para> In some versions (1.1, for sure; possibly 1.0.5) there is the
-option of not bothering to vacuum any of these tables if you are using
-something like <application>pg_autovacuum</application> to handle
-vacuuming of these tables. Unfortunately, it has been quite possible
-for <application>pg_autovacuum</application> to not vacuum quite
-frequently enough, so you may prefer to use the internal vacuums.
-Vacuuming &pglistener; <quote>too often</quote> isn't nearly as
-hazardous as not vacuuming it frequently enough.</para>
+<para>Avec certaines versions (la 1.1; peut-être la 1.0.5)
+il est possible de ne plus s'embarrasser avec les vacuums
+sur ces tables si vous utiliser quelque chose comme
+<application>pg_autovacuum</application>
+pour gérer le nettoyage de ces tables.
+Malheureusement, il est possible que
+<application>pg_autovacuum</application>
+ne nettoie pas assez fréquemment, vous pourrez donc préférer utiliser les vacuums internes.
-<para>Unfortunately, if you have long-running transactions, vacuums
-cannot clear out dead tuples that are newer than the eldest
-transaction that is still running. This will most notably lead to
-&pglistener; growing large and will slow
-replication.</para></listitem>
+Nettoyer la table &pglistener; <quote>trop
+souvent</quote>
+est moins risqué que de ne pas la nettoyer assez.
+</para>
-<listitem> <para> The <link linkend="dupkey"> Duplicate Key Violation
-</link> bug has helped track down some &postgres; race conditions.
-One remaining issue is that it appears that is a case where
-<command>VACUUM</command> is not reclaiming space correctly, leading
-to corruption of B-trees. </para>
+<para>Malheureusement, si vous avez de longues transactions,
+les vacuums ne peuvent pas nettoyer les tuples morts
+qui sont plus récents que les anciennes transactions
+toujours en cours. Ceci conduira en particulier à une
+forte croissance de &pglistener;
+et ralentira la réplication.
+</para></listitem>
-<para> It may be helpful to run the command <command> REINDEX TABLE
-sl_log_1;</command> periodically to avoid the problem
-occurring. </para> </listitem>
-<listitem><para> As of version 1.2, <quote>log switching</quote>
-functionality is in place; every so often, it seeks to switch between
-storing data in &sllog1; and &sllog2; so that it may seek
-to <command>TRUNCATE</command> the <quote>elder</quote> data.</para>
+<listitem> <para> Le bug <link linkend="dupkey"> Violation par
+clef dupliqué</link> a permis d'isoler des situations de
+concurrence dans &postgres;
+Des problèms subsiste notamment
+lorsque <command>VACUUM</command> ne
+réclame pas correctement l'espace
+menant à une corruption des arbres B. </para>
-<para> That means that on a regular basis, these tables are completely
-cleared out, so that you will not suffer from them having grown to
-some significant size, due to heavy load, after which they are
-incapable of shrinking back down </para> </listitem>
+<para>Il peut être utile de lancer la commande
+<command> REINDEX TABLE sl_log_1;</command>
+périodiquement pour éviter ce problèm
+</para> </listitem>
+<listitem><para> A partir de la version 1.2,
+ la fonctionnalité <quote>log switching</quote>
+est arrivée;de temps en temps, elle tente d'interchanger
+les données entre &sllog1; and &sllog2;
+afin de réaliser un
+<command>TRUNCATE</command> sur les <quote>plus vielles</quote>
+données.</para>
+
+<para> Cela signifie que de manière régulière,
+ces tables sont complètement nettoyées ce qui
+évitequ'elle ne grossisse trop
+lors d'une charge importante
+et qu'elles deviennent
+impossible à nettoyer.
+
+</para> </listitem>
+
</itemizedlist>
</para>
-<sect2 id="maintenance-autovac"> <title> Interaction with &postgres;
-autovacuum </title>
+<sect2 id="maintenance-autovac">
+<title> Intéraction avec l'autovaccum de &postgres;
+</title>
-<indexterm><primary>autovacuum interaction</primary></indexterm>
+<indexterm><primary>interaction avec autovacuum</primary></indexterm>
-<para> Recent versions of &postgres; support an
-<quote>autovacuum</quote> process which notices when tables are
-modified, thereby creating dead tuples, and vacuums those tables,
-<quote>on demand.</quote> It has been observed that this can interact
-somewhat negatively with &slony1;'s own vacuuming policies on its own
-tables. </para>
+<para>Les versions récentes de&postgres; propose
+un processus <quote>autovacuum</quote>
+qui détecte les modifications sur les tables et la
+création
+de tuples mort, puis nettoie de ces tables,
+<quote>à la demande.</quote>.
+On a constaté que cela peut interagir de manière
+négative avec la politique de vacuum de &slony1;
+sur ces propres tables. </para>
-<para> &slony1; requests vacuums on its tables immediately after
-completing transactions that are expected to clean out old data, which
-may be expected to be the ideal time to do so. It appears as though
-autovacuum may notice the changes a bit earlier, and attempts
-vacuuming when transactions are not complete, rendering the work
-pretty useless. It seems preferable to configure autovacuum to avoid
-vacuum &slony1;-managed configuration tables. </para>
+<para> &slony1; demande des vacuums sur ses tables
+immédiatement après avoir complété les
+transactions
+qui sont sensées supprimer de vieilles données,
+ce qui est considéré comme le meilleur moment
+pour le faire. Il semble que l'autovacuum détecte
+les changements un peu trop tôt, et lance un vacuum
+alors que les transactions ne sont pas complétées,
+ce qui est relativement inutile.
+Il apparait préférable de configurer l'autovacuum
+pour éviter les tables de configuration
+gérées par &slony1;. </para>
-<para> The following query (change the cluster name to match your
-local configuration) will identify the tables that autovacuum should
-be configured not to process: </para>
+<para> La requête suivante identifie les tables que
+l'autovacuum ne doit pas traiter (remplacez le nom du
+cluster par celui de votre configuration locale) :
+</para>
<programlisting>
-mycluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'MyCluster') and relhasindex;
+moncluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'monCluster') and relhasindex;
oid | relname
-------+--------------
17946 | sl_nodelock
@@ -110,125 +145,130 @@
(15 rows)
</programlisting>
-<para> The following query will populate
-<envar>pg_catalog.pg_autovacuum</envar> with suitable configuration
-information: <command> insert into pg_catalog.pg_autovacuum (vacrelid,
+<para>La requête suivante remplira la table
+<envar>pg_catalog.pg_autovacuum</envar>
+avec les informations de configuration adéquates :
+<command> insert into pg_catalog.pg_autovacuum (vacrelid,
enabled) select oid, 'f' from pg_catalog.pg_class where relnamespace =
-(select oid from pg_namespace where nspname = '_' || 'MyCluster') and
+(select oid from pg_namespace where nspname = '_' || 'monCluster') and
relhasindex; </command> </para>
</sect2>
-<sect2><title> Watchdogs: Keeping Slons Running</title>
+<sect2><title> Chiens de garde : garder les Slons en vie</title>
-<indexterm><primary>watchdogs to keep slon daemons running</primary></indexterm>
+<indexterm><primary>Chiens de garde pour garder en vie les démons slon
+</primary></indexterm>
-<para>There are a couple of <quote>watchdog</quote> scripts available
-that monitor things, and restart the <application>slon</application>
-processes should they happen to die for some reason, such as a network
-<quote>glitch</quote> that causes loss of connectivity.</para>
+<para>Il y a deux scripts <quote>chiens de garde</quote> disponibles pour surveiller
+ la réplication et relancer les processus <application>slon</application>
+ lorsqu'il meurent pour telle ou telle raison, par exemple une
+<quote>coupure</quote> réseau qui provoque une perte de connectivité.</para>
-<para>You might want to run them...</para>
+<para>Ils pourraient vous être utiles...</para>
-<para> The <quote>best new way</quote> of managing <xref
-linkend="slon"/> processes is via the combination of <xref
-linkend="mkslonconf"/>, which creates a configuration file for each
-node in a cluster, and <xref linkend="launchclusters"/>, which uses
-those configuration files.</para>
+<para> La <quote>meilleur et nouvelle</quote> façon de gérer les processus <xref
+linkend="slon"/> se fait via une combinaison de <xref
+linkend="mkslonconf"/>, qui crée un fichier de configuration pour chaque noeud
+ d'un cluster, et <xref linkend="launchclusters"/> qui utilise ces fichiers
+ de configuration.</para>
-<para> This approach is preferable to elder <quote>watchdog</quote>
-systems in that you can very precisely <quote>nail down,</quote> in
-each config file, the exact desired configuration for each node, and
-not need to be concerned with what options the watchdog script may or
-may not give you. This is particularly important if you are using
-<link linkend="logshipping"> log shipping </link>, where forgetting
-the <command>-a</command> option could ruin your log shipped node, and
-thereby your whole day.</para>
+<para> Cette approche est préférable aux anciens systèmes de
+ <quote>chiens de garde</quote> car vous pouvez <quote>pointer</quote>
+ précisément, dans chaque fichier de configurationn, le paramètrage
+ désiré pour chaque noeud, sans avoir à vous préoccuper des options
+ que le script chien de garde vous proposer ( ou pas ). Ceci est particulièrement
+ important si vous utilisez le <link linkend="logshipping"> log shipping </link>,
+ auquel cas oublier l'option <command>-a</command> peut ruiner le noeud
+ destinataire du log shipping et ruiner par là-même votre journée.</para>
</sect2>
-<sect2 id="gensync"><title>Parallel to Watchdog: generate_syncs.sh</title>
+<sect2 id="gensync"><title>En parallèle aux chiens de garde : generate_syncs.sh</title>
-<indexterm><primary>generate SYNCs</primary></indexterm>
+<indexterm><primary>Génére des SYNCs</primary></indexterm>
-<para>A new script for &slony1; 1.1 is
-<application>generate_syncs.sh</application>, which addresses the following kind of
-situation.</para>
+<para>Un nouveau script est apparu dans &slony1; 1.1, il s'agit de
+<application>generate_syncs.sh</application>, qui est utilise dans les situations
+suivantes.</para>
-<para>Supposing you have some possibly-flakey server where the
-<application>slon</application> daemon that might not run all the time, you might
-return from a weekend away only to discover the following situation.</para>
+<para>Supposons que vous avez un serveur non fiable sur lequel le démon
+<application>slon</application> daemon ne fonctionne pas en continu,
+en rentrant de week-end vous vous trouverez peut-êtrÚs la situation suivante :
+</para>
-<para>On Friday night, something went <quote>bump</quote> and while the
-database came back up, none of the <application>slon</application> daemons
-survived. Your online application then saw nearly three days worth of
-reasonably heavy transaction load.</para>
+<para>Le vendredi soir, quelque chose s'est <quote>cassé</quote> et le temps
+ que la base de donnée redémarre, aucun des démons <application>slon</application>
+ n'a survécu. Votre application en ligne a ensuite connu trois jours
+ de charge transactionnelle relativement forte.
+ </para>
-<para>When you restart <application>slon</application> on Monday, it
-hasn't done a SYNC on the master since Friday, so that the next
-<quote>SYNC set</quote> comprises all of the updates between Friday
-and Monday. Yuck.</para>
+<para>Lorsque vous redémarrez <application>slon</application> le lundi, il n'y a pas eu
+ de synchronisation sur le maître depuis Vendredi, ce qui fait que le prochain
+<quote>ensemble de SYNC</quote> comprendra toutes les modifications entre vendredi
+et lundi. Aïe !</para>
-<para>If you run <application>generate_syncs.sh</application> as a cron job every
-20 minutes, it will force in a periodic <command>SYNC</command> on the origin, which
-means that between Friday and Monday, the numerous updates are split
-into more than 100 syncs, which can be applied incrementally, making
-the cleanup a lot less unpleasant.</para>
+<para>Si vous lancez <application>generate_syncs.sh</application> via une tache cron
+ toute les 20 minutes, cela créera de force des événements <command>SYNC</command>
+ sur l'origine, ce qui implique qu'entre vendredi et lundi, les nombreuses mises à jour
+ seront découpées en plus de 100 ensemble de SYNCs, qui pourront être appliqués de
+ manière incrémentale, rendant la restauration mois déplaisante.
+</para>
-<para>Note that if <command>SYNC</command>s <emphasis>are</emphasis> running
-regularly, this script won't bother doing anything.</para>
+<para>Notez que si les <command>SYNC</command>s <emphasis>sont</emphasis> exécutés
+ régulièrement, ce scripts ne fera rien de particulier.</para>
</sect2>
-<sect2><title>Testing &slony1; State </title>
+<sect2><title>Tester l'état &slony1; </title>
-<indexterm><primary>testing cluster status</primary></indexterm>
+<indexterm><primary>tester le statut du cluster</primary></indexterm>
-<para> In the <filename>tools</filename> directory, you may find
-scripts called <filename>test_slony_state.pl</filename> and
-<filename>test_slony_state-dbi.pl</filename>. One uses the Perl/DBI
-interface; the other uses the Pg interface.
+<para> Dans le répertoire <filename>tools</filename>, vous trouverez
+ des scripts nommés <filename>test_slony_state.pl</filename> et
+<filename>test_slony_state-dbi.pl</filename>. Le premier utilise l'interface Perl/DBI
+; l'autre utilise l'interface Pg.
</para>
-<para> Both do essentially the same thing, namely to connect to a
-&slony1; node (you can pick any one), and from that, determine all the
-nodes in the cluster. They then run a series of queries (read only,
-so this should be quite safe to run) which look at the various
-&slony1; tables, looking for a variety of sorts of conditions
-suggestive of problems, including:
+<para> Les deux font essentiellement la même chose, c'est à dire
+ se connecter à un noeud &slony1; (celui de votre choix) et à partir de là
+ détermine la liste des noeuds du cluster. Ensuite ils lancent une
+ série de requêtes ( en lecture seule, et donc sans danger ) afin
+ de parcourir différentes tables à la recherche de différentes conditions
+ susceptibles de rélever des problèmes, telles que :
</para>
<itemizedlist>
-<listitem><para> Bloating of tables like pg_listener, sl_log_1, sl_log_2, sl_seqlog </para></listitem>
-<listitem><para> Listen paths </para></listitem>
-<listitem><para> Analysis of Event propagation </para></listitem>
-<listitem><para> Analysis of Event confirmation propagation </para>
+<listitem><para> Gonflement des tables comme pg_listener, sl_log_1, sl_log_2, sl_seqlog; </para></listitem>
+<listitem><para> Voies d'écoute;</para></listitem>
+<listitem><para> Analyse de la propagation des événéments; </para></listitem>
+<listitem><para> Analyse de la propagation des confirmations. </para>
-<para> If communications is a <emphasis>little</emphasis> broken,
-replication may happen, but confirmations may not get back, which
-prevents nodes from clearing out old events and old replication
-data. </para> </listitem>
+<para> Si la communication est <emphasis>légèrement</emphasis> perturbée,
+la réplication peut fonctionner, mais les confirmations peuvent ne pas être retournées,
+ce qui empêche les noeuds de nettoyer les vieux événements et les anciennes données de réplication
+. </para> </listitem>
</itemizedlist>
-<para> Running this once an hour or once a day can help you detect
-symptoms of problems early, before they lead to performance
-degradation. </para>
+<para> Lancer ce script une par heure ou une fois par jour peut vous aider
+ à détecter les symptomes précurseurs de certains problèmes, avant même
+ que cela conduise à une dégradation des performances. </para>
</sect2>
-<sect2><title>Replication Test Scripts </title>
+<sect2><title>Scripts de test de la réplication</title>
-<para> In the directory <filename>tools</filename> may be found four
-scripts that may be used to do monitoring of &slony1; instances:
+<para>Dans le répertoire <filename>tools</filename> on peut trouver 4
+ scripts qui peuvent être utilisés pour surveiller des instances &slony1; :
<itemizedlist>
-<listitem><para> <command>test_slony_replication</command> is a
-Perl script to which you can pass connection information to get to a
-&slony1; node. It then queries <xref linkend="table.sl-path"/> and
-other information on that node in order to determine the shape of the
-requested replication set.</para>
+<listitem><para> <command>test_slony_replication</command> est un script
+ Perl auquel vous pouvez passer les informations de connexion
+ d'un noeud &slony1;. Il test alors la table <xref linkend="table.sl-path"/>
+ et d'autres informations sur ce noeud afin de déterminer la forme de
+ l'ensemble de réplication choisi.</para>
-<para> It then injects some test queries to a test table called
-<envar>slony_test</envar> which is defined as follows, and which needs to be
-added to the set of tables being replicated:
+<para> Ensuite il injecte des requêtes de test dans la table nommée
+<envar>slony_test</envar> qui est définie comme ci-dessous, et
+qui doit être ajoutée à l'ensemble des tables répliquées :
<programlisting>
CREATE TABLE slony_test (
@@ -238,68 +278,69 @@
);
</programlisting></para>
-<para> The last column in that table was defined by &slony1; as one
-lacking a primary key...</para>
+<para> La dernière colonne de la table est définie par &slony1; comme
+ une une clé primaire manquante...</para>
-<para> This script generates a line of output for each &slony1; node
-that is active for the requested replication set in a file called
-<filename>cluster.fact.log</filename>.</para>
+<para> Ce script génère une ligne de sortie pour chaque noeud &slony1; actif
+ pour l'ensemble de réplication défini dans un fichier nommé
+ <filename>cluster.fact.log</filename>.</para>
-<para> There is an additional <option>finalquery</option> option that allows
-you to pass in an application-specific SQL query that can determine
-something about the state of your application.</para></listitem>
+<para> Il y a une option additionelle, <option>finalquery</option>, qui vous permet de
+ passer une requête SQL spécifique à votre application pour déterminer
+ l'état de votre application.</para></listitem>
-<listitem><para><command>log.pm</command> is a Perl module that manages logging
-for the Perl scripts.</para></listitem>
+<listitem><para><command>log.pm</command> est un module Perl module qui gère les logs des
+ scripts Perl.</para></listitem>
-<listitem><para><command>run_rep_tests.sh</command> is a <quote>wrapper</quote> script
-that runs <command>test_slony_replication</command>.</para>
+<listitem><para><command>run_rep_tests.sh</command> est un script <quote>wrapper</quote>
+ qui lance <command>test_slony_replication</command>.</para>
-<para> If you have several &slony1; clusters, you might set up
-configuration in this file to connect to all those
+<para> Si vous avez plusieurs clusters &slony1;, vous pouvez placer dans
+ ce fichier le configuration pour se connecter à tous ces
clusters.</para></listitem>
-<listitem><para><command>nagios_slony_test</command> is a script that
-was constructed to query the log files so that you might run the
-replication tests every so often (we run them every 6 minutes), and
-then a system monitoring tool such as <ulink
+<listitem><para><command>nagios_slony_test</command> est un script qui
+ a été construit pour interroger les fichiers logs afin de pouvoir
+ lancer le test de réplication régulièrement ( nous le laissons
+ toutes les 6 minutes) et qu'un outil de supervision tel que
+ <ulink
url="http://www.nagios.org/"> <productname>Nagios</productname>
-</ulink> can be set up to use this script to query the state indicated
-in those logs.</para>
+</ulink> puisse utiliser le script to surveiller l'état indiqué
+dans ces logs.</para>
-<para> It seemed rather more efficient to have a
-<application>cron</application> job run the tests and have
-<productname>Nagios</productname> check the results rather than having
-<productname>Nagios</productname> run the tests directly. The tests
-can exercise the whole &slony1; cluster at once rather than
-<productname>Nagios</productname> invoking updates over and over
-again.</para></listitem>
+<para> Il semble plus efficace qu'une tache
+<application>cron</application> lance les tests et que
+<productname>Nagios</productname> vérifie le résultat plutôt que
+de voir <productname>Nagios</productname> lancer directement
+les tests. Ces tests peuvent vérifier l'ensemble du cluster &slony1;
+d'un seul coup, plutot que de voir <productname>Nagios</productname>
+provoque des mises à jour en permanence.</para></listitem>
</itemizedlist></para>
</sect2>
-<sect2><title> Other Replication Tests </title>
+<sect2><title> Autres tests de réplication</title>
-<indexterm><primary>testing replication</primary></indexterm>
+<indexterm><primary>tester la réplication</primary></indexterm>
-<para> The methodology of the previous section is designed with a view
-to minimizing the cost of submitting replication test queries; on a
-busy cluster, supporting hundreds of users, the cost associated with
-running a few queries is likely to be pretty irrelevant, and the setup
-cost to configure the tables and data injectors is pretty high.</para>
+<para> La méthodologie de la section précédente est conçu avec un vue
+ pour minimiser le coût des requêtes de test; sur un cluster très chargé,
+ supportant des centaines d'utilisateurs, le coût associé aux quelques
+ requêtes de test n'est un point important et le temps de configuration
+ des tables et des injecteurs de données est très élevé.</para>
-<para> Three other methods for analyzing the state of replication have
-stood out:</para>
+<para> 3 autres méthodes pour analyser l'état de la réplication sont
+apparus :</para>
<itemizedlist>
-<listitem><para> For an application-oriented test, it has been useful
-to set up a view on some frequently updated table that pulls
-application-specific information. </para>
+<listitem><para> Pour un test orienté sur l'application, il est utile
+ de créer une vue sur une table fréquemment mise à jour pour remonter
+ des informations spécifique à l'application.</para>
-<para> For instance, one might look either at some statistics about a
-most recently created application object, or an application
-transaction. For instance:</para>
+<para> Par exemple, on peut chercher soit des statistiques
+ sur les objets applicatif les plus récents, soit les transactions
+ de l'applicatio. Par exemple :</para>
<para> <command> create view replication_test as select now() -
txn_time as age, object_name from transaction_table order by txn_time
@@ -309,140 +350,143 @@
created_on as age, object_name from object_table order by id desc
limit 1; </command> </para>
-<para> There is a downside: This approach requires that you have
-regular activity going through the system that will lead to there
-being new transactions on a regular basis. If something breaks down
-with your application, you may start getting spurious warnings about
-replication being behind, despite the fact that replication is working
-fine.</para>
+<para> Il y a un inconvénient : Cette approche nécessite que vous
+ ayez une activité constante sur le système impliquant la création
+ de nouvelles transactions de manière régulière.
+ Si quelque chose ne fonctionne pas dans votre application. vous obtiendrez
+ des fausses alertes en provenance de la réplication, alors même que la réplication
+ fonctionne correctement.</para>
</listitem>
-<listitem><para> The &slony1;-defined view, <envar>sl_status</envar>
-provides information as to how up to date different nodes are. Its
-contents are only really interesting on origin nodes, as the events
-generated on other nodes are generally ignorable. </para>
+<listitem><para> La vue &slony1; nommée <envar>sl_status</envar>
+ fournit des informations sur la synchronisation des différents noeuds.
+ Son contenu n'est intéressant que sur les noeuds origine, car les
+ événements générés sur les autres noeuds peuvent généralement
+ être ignorés. </para>
</listitem>
-<listitem><para> See also the <xref linkend="slonymrtg"/>
-discussion. </para></listitem>
+<listitem><para> Voir également la discussion sur <xref linkend="slonymrtg"/>. </para></listitem>
</itemizedlist>
</sect2>
-<sect2><title> Log Files</title>
+<sect2><title> Fichiers de log</title>
-<indexterm><primary>log files</primary></indexterm>
+<indexterm><primary>fichiers de log</primary></indexterm>
-<para><xref linkend="slon"/> daemons generate some more-or-less verbose
-log files, depending on what debugging level is turned on. You might
-assortedly wish to:
+<para>Les démons <xref linkend="slon"/> génère des fichiers de logs plus
+ ou moins verbeux, selon le niveau de debug activé. Dans ce cas vous pouvez :
<itemizedlist>
-<listitem><para> Use a log rotator like
-<productname>Apache</productname>
-<application>rotatelogs</application> to have a sequence of log files
-so that no one of them gets too big;</para></listitem>
+<listitem><para> Utiliser un programme de rotations de logs comme
+<application>rotatelogs</application> d'<productname>Apache</productname>
+ pour avoir une sécancer de fichiers de logs et évite d'avoir des fichiers
+trop gros;</para></listitem>
-<listitem><para> Purge out old log files,
-periodically.</para></listitem>
+<listitem><para> Purgez régulièrement les vieux fichiers de log.</para></listitem>
</itemizedlist>
</para>
</sect2>
-<sect2><title>mkservice </title>
-<indexterm><primary>mkservice for BSD </primary></indexterm>
+<sect2><title>service </title>
+<indexterm><primary>service pour BSD </primary></indexterm>
-<sect3><title>slon-mkservice.sh</title>
+<sect3><title>slon</title>
-<para> Create a slon service directory for use with svscan from
-daemontools. This uses multilog in a pretty basic way, which seems to
-be standard for daemontools / multilog setups. If you want clever
-logging, see logrep below. Currently this script has very limited
-error handling capabilities.</para>
+<para> Ce script crée un répertoire pour le service slon qui pourra être
+ utilisé avec la commande svscan de daemontools. Ce script utilise multilog
+ de manière très basique, ce qui semble être standard pour les installations
+ daemontools / multilog. Si vous souhaitez une gestion intelligente des logs,
+ consultez la section logrep ci-dessous. Actuellement ce script à des possibilités
+ de gestion d'erreurs très limitées.
+ </para>
-<para> For non-interactive use, set the following environment
-variables. <envar>BASEDIR</envar> <envar>SYSUSR</envar>
+<para> Pour les usages non-interactifs, configurer les variables d'environnement
+ suivantes : <envar>BASEDIR</envar> <envar>SYSUSR</envar>
<envar>PASSFILE</envar> <envar>DBUSER</envar> <envar>HOST</envar>
<envar>PORT</envar> <envar>DATABASE</envar> <envar>CLUSTER</envar>
-<envar>SLON_BINARY</envar> If any of the above are not set, the script
-asks for configuration information interactively.</para>
+<envar>SLON_BINARY</envar> Si un seul de ces valeurs n'est pas définie,
+le script demande les informations de manière interactive.</para>
<itemizedlist>
<listitem><para>
-<envar>BASEDIR</envar> where you want the service directory structure for the slon
-to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem>
+<envar>BASEDIR</envar> l'emplacement où la structure du répertoire du service slon sera créée.
+Il ne faut <emphasis>pas</emphasis> que ce soit le répertoire <filename>/var/service</filename>;</para></listitem>
<listitem><para>
-<envar>SYSUSR</envar> the unix user under which the slon (and multilog) process should run.</para></listitem>
+<envar>SYSUSR</envar> l'utilisateur unix qui lancera le processus slon (et multilog);</para></listitem>
<listitem><para>
-<envar>PASSFILE</envar> location of the <filename>.pgpass</filename> file to be used. (default <filename>~sysusr/.pgpass</filename>)</para></listitem>
+<envar>PASSFILE</envar> l'emplacement du fichier <filename>.pgpass</filename>. (par défaut <filename>~sysusr/.pgpass</filename>);</para></listitem>
<listitem><para>
-<envar>DBUSER</envar> the postgres user the slon should connect as (default slony)</para></listitem>
+<envar>DBUSER</envar> L'utilisateur postgres que slon doit utiliser ( par défaut slony);</para></listitem>
<listitem><para>
-<envar>HOST</envar> what database server to connect to (default localhost)</para></listitem>
+<envar>HOST</envar> l'adresse du serveur ou le slon doit se connecter (par défaut localhost)</para></listitem>
<listitem><para>
-<envar>PORT</envar> what port to connect to (default 5432)</para></listitem>
+<envar>PORT</envar> le port de connexion (par défaut 5432)</para></listitem>
<listitem><para>
-<envar>DATABASE</envar> which database to connect to (default dbuser)</para></listitem>
+<envar>DATABASE</envar> la base de données sur laquelle slon se connecte (par défaut dbuser)</para></listitem>
<listitem><para>
-<envar>CLUSTER</envar> the name of your Slony1 cluster? (default database)</para></listitem>
+<envar>CLUSTER</envar> le nom du cluster Slony1 (par défaut database)</para></listitem>
<listitem><para>
-<envar>SLON_BINARY</envar> the full path name of the slon binary (default <command>which slon</command>)</para></listitem>
+<envar>SLON_BINARY</envar> le chemin complet vers le binaire slon (par défaut <command>which slon</command>)</para></listitem>
</itemizedlist>
</sect3>
<sect3><title>logrep-mkservice.sh</title>
-<para>This uses <command>tail -F</command> to pull data from log files allowing
-you to use multilog filters (by setting the CRITERIA) to create
-special purpose log files. The goal is to provide a way to monitor log
-files in near realtime for <quote>interesting</quote> data without either
-hacking up the initial log file or wasting CPU/IO by re-scanning the
-same log repeatedly.
+<para>Ce script utilise <command>tail -F</command> pour extraire des données des fichiers
+ de logs en vous permettant d'utiliser des filtres multilog (via l'option CRITERIA) afin
+ de créer des fichiers de logs spécifiques. Le but est de fournir un moyen de surveiller
+ les fichiers de logs en temps réel en quête de données <quote>intéressante</quote>
+ sans devoir modifier le fichier de log initial ou gacher des ressources CPU/IO
+ en re-scannant les logs régulièrement.
</para>
-<para>For non-interactive use, set the following environment
-variables. <envar>BASEDIR</envar> <envar>SYSUSR</envar> <envar>SOURCE</envar>
-<envar>EXTENSION</envar> <envar>CRITERIA</envar> If any of the above are not set,
-the script asks for configuration information interactively.
+<para>Pour une utilisation non interactive, il faut configurer les variable:
+ <envar>BASEDIR</envar> <envar>SYSUSR</envar> <envar>SOURCE</envar>
+<envar>EXTENSION</envar> <envar>CRITERIA</envar>. Si une seul de ces options n'est
+pas définie le script demande interactivement les informations de configuration.
</para>
<itemizedlist>
<listitem><para>
-<envar>BASEDIR</envar> where you want the service directory structure for the logrep
-to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem>
-<listitem><para><envar>SYSUSR</envar> unix user under which the service should run.</para></listitem>
-<listitem><para><envar>SOURCE</envar> name of the service with the log you want to follow.</para></listitem>
-<listitem><para><envar>EXTENSION</envar> a tag to differentiate this logrep from others using the same source.</para></listitem>
-<listitem><para><envar>CRITERIA</envar> the multilog filter you want to use.</para></listitem>
+<envar>BASEDIR</envar> : l'emplacement où sera créée la structure du répertoire du service de logrep.
+Il ne faut <emphasis>pas</emphasis> que ce soit le répertoire <filename>/var/service</filename>.
+</para></listitem>
+<listitem><para><envar>SYSUSR</envar> : l'utilisateur unix qui lancera le service.</para></listitem>
+<listitem><para><envar>SOURCE</envar> : nom du service de log que vous voulez suivre.</para></listitem>
+<listitem><para><envar>EXTENSION</envar> : un tag pour différencier ce logrep de ceux qui utilisent la même source.</para></listitem>
+<listitem><para><envar>CRITERIA</envar> : le filtre multilog que vous voulez utiliser.</para></listitem>
</itemizedlist>
-<para> A trivial example of this would be to provide a log file of all slon
-ERROR messages which could be used to trigger a nagios alarm.
-<command>EXTENSION='ERRORS'</command>
+<para> Un exemple trivial consiste à produire un fichier de log de tous les messages d'erreur
+ slon qui pourrait être utilisé pour déclencher une alerte nagios :
+ <command>EXTENSION='ERRORS'</command>
<command>CRITERIA="'-*' '+* * ERROR*'"</command>
-(Reset the monitor by rotating the log using <command>svc -a $svc_dir</command>)
+(On relance la surveillance en déclenchant une rotation des logs avec <command>svc -a $svc_dir</command>)
</para>
-<para> A more interesting application is a subscription progress log.
+<para> Une application plus intéressante est la surveillance de la progression d'une souscription d'un noeud :
<command>EXTENSION='COPY'</command>
<command>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</command>
</para>
-<para>If you have a subscription log then it's easy to determine if a given
-slon is in the process of handling copies or other subscription activity.
-If the log isn't empty, and doesn't end with a
+<para>Si vous avez un log de suscription, alors il est facile
+ de déterminer si un noeud donné est en train de réaliser une copie
+ ou une autre activité de souscription. Si les log ne sont pas vide et
+ ne se termine pas par
<command>"CONFIG enableSubscription: sub_set:1"</command>
-(or whatever set number you've subscribed) then the slon is currently in
-the middle of initial copies.</para>
+(ou 1 est le numéro d'ensemble de réplication que vous avez abonné)
+alors le slon est au milieu d'une copie initiale.</para>
-<para> If you happen to be monitoring the mtime of your primary slony logs to
-determine if your slon has gone brain-dead, checking this is a good way
-to avoid mistakenly clobbering it in the middle of a subscribe. As a bonus,
-recall that since the the slons are running under svscan, you only need to
-kill it (via the svc interface) and let svscan start it up again laster.
-I've also found the COPY logs handy for following subscribe activity
-interactively.</para>
+<para> Si vous surveiller le mtime du fichier de log de votre noeud primaire
+ pour déterminer si le slon est tombé dans le coma, vérifier ce log de souscription
+ est un bon moyen d'éviter de stopper le noeud alors qu'un souscription est en cours.
+ En bonus, puisque les slons utilise svscan, vous pouvez simplement détruire le fichier
+ ( via l'interface svc ) et laisser svscan le recommencer plus tard. J'ai également
+ découvert que les logs de COPY sont pratiques pour suivre de manière interactive
+ l'activité des souscritpions.
+ </para>
</sect3>
</sect2>
More information about the Trad
mailing list