[Trad] [svn:pgfr] r1128 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Ven 5 Sep 13:37:44 CEST 2008
Author: daamien
Date: 2008-09-05 13:37:44 +0200 (Fri, 05 Sep 2008)
New Revision: 1128
Modified:
traduc/trunk/slony/loganalysis.xml
Log:
slony : log analysis (2/5)
Modified: traduc/trunk/slony/loganalysis.xml
===================================================================
--- traduc/trunk/slony/loganalysis.xml 2008-08-24 20:54:14 UTC (rev 1127)
+++ traduc/trunk/slony/loganalysis.xml 2008-09-05 11:37:44 UTC (rev 1128)
@@ -5,20 +5,19 @@
révision $Revision$ -->
<sect1 id="loganalysis">
-<title>Log Analysis</title>
+<title>Analyses des logs</title>
-<indexterm><primary>Log analysis</primary></indexterm>
+<indexterm><primary>Analyse des logs</primary></indexterm>
-<para>Here are some of things that you may find in your &slony1; logs,
-and explanations of what they mean.</para>
+<para>Voici un tour d'horizon des informations que vous trouverez dans les logs de &slony1;,
+ainsi que des explications sur leur signification.</para>
-<sect2><title>CONFIG notices</title>
+<sect2><title>Notification CONFIG</title>
-<para>These entries are pretty straightforward. They are informative
-messages about your configuration.</para>
+<para>Ces lignes sont assez triviales. Ce sont des messages d'information
+à propos de la configuration.</para>
-<para>Here are some typical entries that you will probably run into in
-your logs:
+<para>Voici quelques lignes typiques que vous pouvez rencontrer :
<screen>
CONFIG main: local node id = 1
@@ -30,355 +29,381 @@
CONFIG main: configuration complete - starting threads
</screen></para></sect2>
-<sect2><title>INFO notices</title>
+<sect2><title>Notifications INFO</title>
-<para> Events that take place that seem like they will generally be of
-interest are recorded at the INFO level, and, just as with CONFIG
-notices, are always listed. </para>
+<para> Les événements qui semble avoir un intérêt au niveau INFO,
+et qui sont toujours listés , tout comme les notifications CONFIG.
+</para>
</sect2>
-<sect2><title>DEBUG Notices</title>
+<sect2><title>Notifications DEBUG</title>
-<para>Debug notices are of less interest, and will quite likely only
-need to be shown if you are running into some problem with &slony1;.</para>
+<para>Les notifications DEBUG sont moins intéressantes, et ne vous seront
+utile que lorsque vous rencontrez une problème avec &slony1;.</para>
</sect2>
-<sect2><title>Thread name </title>
+<sect2><title>Nom du processus </title>
-<para> Notices are always prefaced by the name of the thread from
-which the notice originates. You will see messages from the following
-threads:
+<para> Les notifications sont toujours précédées par le nom du processus
+qui produit cette nottification. Vous verez des messages en provenance
+des processus suivants :
<variablelist>
<varlistentry><term>localListenThread</term>
-<listitem><para> This is the local thread that listens for events on
-the local node.</para></listitem></varlistentry>
+<listitem><para> Le processus local qui écoute les événements sur le noeud local.</para></listitem></varlistentry>
<varlistentry><term>remoteWorkerThread-X</term>
-<listitem><para> The thread processing remote events. You can expect
-to see one of these for each node that this node communicates
-with.</para></listitem></varlistentry>
+<listitem><para> Les processus qui traitent les événments distants. Vous verrez un de
+ces processus pour chaque noeud qui est en communication avec le noeud local.
+</para></listitem></varlistentry>
<varlistentry><term>remoteListenThread-X</term>
-<listitem><para>Listens for events on a remote node database. You may
-expect to see one of these for each node in the
-cluster.</para></listitem></varlistentry>
+<listitem><para>Les processus qui écoutent les événements distants.
+Vous verrez un de
+ces processus pour chaque noeud du cluster.</para></listitem></varlistentry>
-<varlistentry><term>cleanupThread</term> <listitem><para> Takes care
-of things like vacuuming, cleaning out the confirm and event tables,
-and deleting old data.</para></listitem></varlistentry>
+<varlistentry><term>cleanupThread</term>
+<listitem><para> Le processus qui prend en charge les opérations telles que
+les VACUUM, le nettoyage des tables confirm and event,
+et la suppression des données périmées.</para></listitem></varlistentry>
-<varlistentry><term>syncThread</term> <listitem><para> Generates SYNC
-events.</para></listitem></varlistentry>
+<varlistentry><term>syncThread</term> <listitem>
+<para> Le processus qui produit les événements SYNC.</para>
+</listitem></varlistentry>
</variablelist>
</para>
-<para> How much information they display is controlled by
-the <envar>log_level</envar> &lslon; parameter;
-ERROR/WARN/CONFIG/INFO messages will always be displayed, while
-choosing increasing values from 1 to 4 will lead to additional DEBUG
-level messages being displayed. </para>
+<para> La quantité d'information que ces processus affichent est controlée par
+le paramètre <envar>log_level</envar> de &lslon;;
+Les messages de type ERROR/WARN/CONFIG/INFO seront toujours affichés,
+augmenter la valeur de 1 à 4 affichera des plus en plus de messages de DEBUG.
+</para>
</sect2>
-<sect2> <title> How to read &slony1; logs </title>
+<sect2> <title> Comment lire les logs &slony1; </title>
-<indexterm><primary>reading and understanding &slony1; logs</primary></indexterm>
+<indexterm><primary>lire et comprendre les logs &slony1;</primary></indexterm>
-<para> Note that as far as slon is concerned, there is no
-<quote>master</quote> or <quote>slave.</quote> They are just
-nodes. </para>
+<para> Notons que du point de vue d'un processus slon, il n'y a pas de
+<quote>maître</quote> ni d'<quote>esclave</quote>. Il y a juste des noeuds.
+</para>
-<para>What you can expect, initially, is to see, on both nodes, some
-events propagating back and forth. Firstly, there should be some
-events published to indicate creation of the nodes and paths. If you
-don't see those, then the nodes aren't properly communicating with one
-another, and nothing else will happen... </para>
+<para>On s'attend, de prime abord, à voir sur chaque noeuds des événements
+se propager dans les deux sens. Dans un premier temps, il doit y avoir
+des événements publiés qui témoignent de la création des noeuds et des
+voies de communications. Si vous ne les voyez pas, alors les noeuds
+ne communiquent pas correctement entre eux et rien ne va se passer...
+ </para>
<itemizedlist>
-<listitem><para>Create the two nodes.</para>
+<listitem><para>Créer les deux noeuds.</para>
-<para> No slons are running yet, so there are no logs to look
-at.</para>
+<para> Aucun slons ne fonctionne à ce stade, donc il n'y a aucun logs à consulter.</para>
</listitem>
-<listitem><para> Start the two slons</para>
+<listitem><para>Lancer les deux noeuds</para>
-<para> The logs for each will start out very quiet, as neither node
-has much to say, and neither node knows how to talk to another node.
-Each node will periodically generate a <command>SYNC</command> event,
-but recognize <emphasis>nothing</emphasis> about what is going on on
-other nodes.</para>
-
+<para> Les logs de chaque noeuds n'auront pas une activité débordante, car aucun
+les noeuds n'ont pas grand'chose à dire et qu'ils ne savent pas
+comment communiquer entre eux. Chaque noeud génère périodiquement
+un événement <command>SYNC</command>, mais ne perçoit <emphasis>rien</emphasis>
+de ce qui se passe sur les autres noeuds.</para>
+
</listitem>
-<listitem><para> Do the <xref linkend="stmtstorepath"/> to set up
-communications paths. That will allow the nodes to start to become
-aware of one another.</para>
+<listitem><para> Lancer <xref linkend="stmtstorepath"/> pour configuration les
+voies de communications. Ceci devrait permettre aux noeuds de prendre conscience
+de l'existance de leurs voisins.</para>
-<para> The slon logs should now start to receive events from
-<quote>foreign</quote> nodes.</para>
+<para> Les logs de slon doivent maintenant recevoir les événéments en provenance
+des noeuds <quote>étrangers</quote>.</para>
-<para> In version 1.0, <xref linkend="table.sl-listen"/> is not set up
-automatically, so things still remain quiet until you explicitly
-submit <command>STORE LISTEN</command> requests. In version 1.1, the
-<quote>listen paths</quote> are set up automatically, which will much
-more quickly get the communications network up and running. </para>
+<para> Dans la 1.0, <xref linkend="table.sl-listen"/> n'est pas configuré
+automatiquement, donc les logs vont rester calmes tant que vous n'aurez
+pas soumit explicitement les requêtes <command>STORE LISTEN</command>.
+Dans la version 1.1, les <quote>voies d'écoute</quote> cont configurées automatiquement,
+ce qui nous donne un réseau de communication opérationnel plus rapidement.
+</para>
-<para> If you look at the contents of the tables <xref
-linkend="table.sl-node"/> and <xref linkend="table.sl-path"/> and <xref
-linkend="table.sl-listen"/>, on each node, that should give a good idea
-as to where things stand. Until the <xref linkend="slon"/> starts,
-each node may only be partly configured. If there are two nodes,
-there should be two entries in all three of these tables once the
-communications configuration is set up properly. If there are fewer
-entries than that, well, that should give you some idea of what is
-missing.</para>
+<para> Si vous consultez le contenu des tables <xref
+linkend="table.sl-node"/>, <xref linkend="table.sl-path"/> et <xref
+linkend="table.sl-listen"/>, sur chaque noeud, cela vous donnera une bonne
+idée de l'état du réseau de communication.
+Jusqu'à ce que les <xref linkend="slon"/> démarrent, chaque noeud
+est partiellement configuré. Si le cluster contient deux noeuds,
+alors il doit y avoir deux entrées dans chacune des trois tables
+une fois que les commnications sont correctement configurées.
+Si il y a moins d'entrées, vous devriez pouvoir deviner ce qui manque.
+</para>
</listitem>
-<listitem><para> If needed (<emphasis>e.g.</emphasis> - before version
-1.1), submit <xref linkend="stmtstorelisten"/> requests to indicate how
-the nodes will use the communications paths. </para>
+<listitem><para> Si nécessaire (<emphasis>c'est à dire</emphasis> - si votre version est
+antérieurs à la version 1.1), lancer des requêtes <xref linkend="stmtstorelisten"/>
+pour indiquer comment les noeuds utiliseront les voies de communications.
+</para>
-<para> Once this has been done, the nodes' logs should show a greater
-level of activity, with events periodically being initiated on one
-node or the other, and propagating to the other. </para>
+<para> Une fois que c'est fait, les logs des noeuds afficheront un niveau
+d'activité supérieur, notamment les événements produits périodiquement sur
+les différents noeuds, ainsi que leur propagation. </para>
</listitem>
-<listitem> <para> You'll set up the set
-(<xref linkend="stmtcreateset"/>), add tables
-(<xref linkend="stmtsetaddtable"/>), and sequences
-(<xref linkend="stmtsetaddsequence"/>), and will see relevant
-events <xref linkend="logaddobjects"/> only in the logs for the origin
-node for the set. </para></listitem>
+<listitem> <para> Configurer l'ensemble de réplication avec
+(<xref linkend="stmtcreateset"/>), ajouter les tables avec
+(<xref linkend="stmtsetaddtable"/>), les sequences avec
+(<xref linkend="stmtsetaddsequence"/>), puis vérifier que vous
+retrouvez des logs adéquats avec <xref linkend="logaddobjects"/>
+uniquement dans les logs du noeud d'origine de l'ensemble de
+réplication. </para></listitem>
-<listitem><para> Then, when you submit the <xref
-linkend="stmtsubscribeset"/> request, the event should go to both
-nodes. </para>
+<listitem><para> Soumettre une requête <xref
+linkend="stmtsubscribeset"/>, l'événement devrait être visible
+sur les deux noeuds. </para>
-<para> The origin node has little more to do, after that... The
-subscriber will then have a <command>COPY_SET</command> event, which
-will lead to logging information about adding each table and copying
-its data. See <xref linkend="logsubtime"/> for more
-details.</para></listitem>
+<para> Il reste quelques actions à mener sur le noeud origine... L'abonné
+doit ensuite recevoir un événement <command>COPY_SET</command>,
+ce qui doit afficher des informations dans les logs à propos de
+l'ajout de chaque table et de la copie de leurs données.
+Consulter la section <xref linkend="logsubtime"/> pour pus de détails.
+</para></listitem>
</itemizedlist>
-<para>After that, you'll mainly see two sorts of behaviour:</para>
+<para>A partir de là, vous constaterez deux types de comportements :</para>
<itemizedlist>
-<listitem><para> On the origin, there won't be too terribly much
-logged, just indication that some <command>SYNC</command> events are
-being generated and confirmed by other nodes.
-See <xref linkend="lognormalsync"/> to see the sorts of log entries to
-expect.</para></listitem>
+<listitem><para> Sur le noeud origine, peu d'informations seront enregistrés
+dans les logs, juste des indications sur les événéments <command>SYNC</command>
+générés et confirmés par les autres noeuds. Consultez la section
+<xref linkend="lognormalsync"/> pour plus d'informations sur les différents
+types de lignes de logs que vous pouvez rencontrer.</para></listitem>
-<listitem><para> On the subscriber, there will be reports of
-<command>SYNC</command> events, and that the subscriber pulls data
-from the provider for the relevant set(s). This will happen
-infrequently if there are no updates going to the origin node; it will
-happen frequently when the origin sees heavy updates. </para>
+<listitem><para> Sur le noeud abonné, vous trouverez des rapports sur les
+événements <command>SYNC</command>, et sur les données que l'abonné
+obtient du fournisseur. Ceci se produit peu fréquemment si le noeud origine
+ne reçoit pas de mises à jour; c'est au contraire très fréquent si le noeud
+origine reçoit beaucoup de modifications.</para>
</listitem>
</itemizedlist>
</sect2>
-<sect2> <title> Log Messages and Implications </title>
+<sect2> <title> Les messages de log et leurs implications </title>
-<para> This section lists numerous of the error messages found in
-&slony1;, along with a brief explanation of implications. It is a
-fairly comprehensive list, only eaving out mostly some of
-the <command>DEBUG4</command> messages that are almost always
-uninteresting.</para>
+<para> Cette section énumère les nombreux messages d'erreurs que l'on peut
+trouver dans les logs de &slony1;, ainsi qu'une brève explication de leur implication.
+Il s'agit d'une liste relativement compréhensible, qui omet simplement
+certain messages de niveau <command>DEBUG4</command> qui sont presque toujours
+inintéressant.</para>
-<sect3 id="logshiplog"><title> Log Messages Associated with Log Shipping </title>
+<sect3 id="logshiplog"><title> Les messages de log associaté au Log Shipping </title>
-<para> Most of these represent errors that come up if
-the <xref linkend="logshipping"/> functionality breaks. You may expect
-things to break if the filesystem being used for log shipping fills,
-or if permissions on that directory are wrongly set. </para>
+<para> La pluspart de ces messages concernent des erreurs qui se produisent
+lorsque le mécanisme de <xref linkend="logshipping"/> échoue. En général,
+cela se produit si le système de fichier utilisé pour le log shipping est plein,
+ou si les permissions d'un répertoire sont mal définies. </para>
<itemizedlist>
<listitem><para><command>ERROR: remoteWorkerThread_%d: log archive failed %s - %s\n</command> </para>
-<para> This indicates that an error was encountered trying to write a
-log shipping file. Normally the &lslon; will retry, and hopefully
-succeed. </para> </listitem>
+<para> Ce message indique qu'une erreur a été rencontrée en essayent d'écrire un
+fichier de log shipping. Normalement le démon &lslon; essaie à nouveau, jusqu'à ce qu'il réussisse
+. </para> </listitem>
<listitem><para><command>DEBUG2: remoteWorkerThread_%d: writing archive log...</command></para>
-<para> This indicates that a log shipping archive log is being written for a particular <command>SYNC</command> set. </para></listitem>
+<para> Ce message indique qu'un fichier archive log est écrit pour un ensemble de <command>SYNC</command> particulier. </para></listitem>
<listitem><para><command>INFO: remoteWorkerThread_%d: Run Archive Command %s</command></para>
-<para> If &lslon; has been configured (<option>-x</option>
-aka <envar>command_on_logarchive</envar>) to run a command after
-generating each log shipping archive log, this reports when that
-process is spawned using <function>system()</function>. </para> </listitem>
+<para> Si &lslon; est configuré ( avec l'option <option>-x</option>
+c'est à dire <envar>command_on_logarchive</envar>) pour lancer une commande
+après chaque génération de ficheir archive log, ce message indique quand cette commande
+est effectuée via la fonction <function>system()</function>. </para> </listitem>
<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not open
COPY SET archive file %s - %s</command></para>
-<para> Seems pretty self-explanatory... </para></listitem>
+<para> Ce message semble assez explicite... </para></listitem>
+
<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate COPY SET archive header %s - %s</command></para>
-<para> Probably means that we just filled up a filesystem... </para></listitem>
+<para> Ce message signifie probablement que vous avez saturé le système de fichier... </para></listitem>
<listitem><para> <command>ERROR remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter set ac_num = ac_num + 1, ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR: could not serialize access due to concurrent update</command> </para>
-<para> This may occasionally occur when using logshipping; this will
-typically happen if there are 3 or more nodes, and there is an attempt
-to concurrently process events sourced from different nodes. This
-does not represent any serious problem; &slony1; will retry the event
-which failed without the need for administrative intervention. </para>
+<para> Ce message se produit occasionnelement lorsqu'on utilise le log shipping;
+il se produit généralement lorsque que le cluster contient 3 noeuds ou plus,
+et que le démon tente d'exécuter simultanément des événements en provenance de
+différents noeuds. Ceci ne réprésente pas un problème sérieux; &slony1;
+tentera à nouveau de traiter l'événement qui a échoué, sans que l'intervention
+d'un administrateur soit nécessaire. </para>
</listitem>
</itemizedlist>
</sect3>
-<sect3 id="ddllogs"><title> Log Messages - DDL scripts </title>
+<sect3 id="ddllogs"><title> Messages de logs à propose des DDL scripts </title>
-<para> The handling of DDL is somewhat fragile, as described
-in <xref linkend="ddlchanges"/>; here are both informational and error
-messages that may occur in the progress of
-an <xref linkend="stmtddlscript"/> request.</para>
+<para> La gestion des ordres DDL est un peu fragile, comme indiqué
+dans la section <xref linkend="ddlchanges"/>; voici des messages à
+caractère informatif et des messages d'erreur qui se produisent lors de l'exécution d'une requête
+<xref linkend="stmtddlscript"/>.</para>
<itemizedlist>
<listitem><para><command>ERROR: remoteWorkerThread_%d: DDL preparation
failed - set %d - only on node %</command></para>
-<para> Something broke when applying a DDL script on one of the nodes.
-This is quite likely indicates that the node's schema differed from
-that on the origin; you may need to apply a change manually to the
-node to allow the event to proceed. The scary, scary alternative
-might be to delete the offending event, assuming it can't possibly
-work...</para> </listitem>
+<para> Quelque chose s'est cassé lors du traitement d'un script DDL sur un des noeuds.
+Ceci indique probablement que le schéma du noeud était différent de celui du
+noeud origine; vous devez probablement effectuer une modification à la main
+sur ce noeud pour l'événement puisse être traité.
+Une alternative très regrettable consiste à supprimer l'événement bloquant,
+sachant qu'il est possible que cette suppression ne fonctionne pas...</para> </listitem>
+
<listitem><para><command>SLON_CONFIG: remoteWorkerThread_%d: DDL request with %d statements</command></para>
-<para> This is informational, indicating how many SQL statements were processed. </para></listitem>
+<para> Ce message est informatif, il indique combien de commandes SQL ont été traitées. </para></listitem>
+
<listitem><para><command>SLON_ERROR: remoteWorkerThread_%d: DDL had invalid number of statements - %d</command></para>
-<para> Occurs if there were < 0 statements (which should be impossible) or > MAXSTATEMENTS statements. Probably the script was bad...</para></listitem>
+<para> Ce message se produit lorsque le nombre de commandes traitées est < 0 (ce qui est théoriquement impossible)
+ou > MAXSTATEMENTS. Ceci indique que le scripts DDL est probablement mal écrit...</para></listitem>
<listitem><para><command>ERROR: remoteWorkerThread_%d: malloc()
failure in DDL_SCRIPT - could not allocate %d bytes of
memory</command></para>
-<para> This should only occur if you submit some extraordinarily large
-DDL script that makes a &lslon; run out of memory </para></listitem>
+<para> Ceci se produit uniquement si vous soumettez un script DDL extraordinairement long,
+qui sature la mémoire allouée à &lslon; ("out of memory") </para></listitem>
<listitem><para><command>CONFIG: remoteWorkerThread_%d: DDL Statement %d: [%s]</command></para>
-<para> This lists each DDL statement as it is submitted. </para></listitem>
+<para> Ce message fait la liste de tous les ordres DDL au fur et à mesure qu'ils sont soumis.
+ </para></listitem>
+
<listitem><para><command>ERROR: DDL Statement failed - %s</command></para>
-<para> Oh, dear, one of the DDL statements that worked on the origin
-failed on this remote node... </para></listitem>
+<para> Oh mon dieu ! un des ordres DDL a fonctionné sur le noeud origine mais il a échoués
+sur le noeud local... </para></listitem>
<listitem><para><command>CONFIG: DDL Statement success - %s</command></para>
-<para> All's well... </para></listitem>
+<para> Tout va bien... </para></listitem>
<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate DDL archive tracker %s - %s</command></para>
-<para> Apparently the DDL script couldn't be written to a log shipping file... </para></listitem>
+<para> Apparemment le script DDL ne peut pas être écrit dans le fichier de log shipping... </para></listitem>
<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not submit DDL script %s - %s</command></para>
-<para>Couldn't write the script to a log shipping file.</para> </listitem>
+<para>Le script ne peut pas être écrit dans un ficheir de log shipping.</para> </listitem>
<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not close DDL script %s - %s</command></para>
-<para>Couldn't close a log shipping file for a DDL script.</para> </listitem>
+<para>Impossible de fermer un fichier de log shipping contenant un script DDL.</para> </listitem>
+
<listitem><para><command>ERROR: Slony-I ddlScript_prepare(): set % not found</command></para>
-<para> Set wasn't found on this node; you probably gave the wrong ID number... </para></listitem>
+<para> L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un
+mauvais identifiant de noeud... </para></listitem>
<listitem><para><command>ERROR: Slony-I ddlScript_prepare_int(): set % not found</command></para>
-<para> Set wasn't found on this node; you probably gave the wrong ID number... </para></listitem>
+<para>L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un
+mauvais identifiant de noeud... </para></listitem>
<listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table with id % not found</command></para>
-<para> Apparently the table wasn't found; could the schema be messed up? </para> </listitem>
+<para> Apparemment la table n'a pas été trouvée; Le schéma est peut-être erroné ? </para> </listitem>
+
<listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table % is already in altered state</command></para>
-<para> Curious... We're trying to set a table up for replication
-a <emphasis>second</emphasis> time? </para> </listitem>
+<para> Curieux... Le script tente de répliquer une table une <emphasis>seconde</emphasis> fois ? </para> </listitem>
<listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table with id % not found</command></para>
-<para> This runs when a table is being restored to <quote>non-replicated</quote> state; apparently the replicated table wasn't found.</para></listitem>
+<para> Ce message se produit lorsqu'une table est en cours de restauration vers un état <quote>non-repliqué</quote>;
+apparemment la table répliquée n'a pas été trouvée.</para></listitem>
<listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table % is not in altered state</command></para>
-<para> Hmm. The table isn't in altered replicated state. That shouldn't be, if replication had been working properly...</para> </listitem>
+<para> Hmm. La table n'est pas dans un état réliqué. Cela ne devrait pas se produire si la réplication
+fonctionne correctement...</para> </listitem>
+
<listitem><para><command>NOTICE: Slony-I: alterTableForReplication(): multiple instances of trigger % on table %'',</command></para>
-<para> This normally happens if you have a table that had a trigger attached to it that replication hid due to this being a subscriber node, and then you added a trigger by the same name back to replication. Now, when trying to "fix up" triggers, those two triggers conflict. </para>
+<para> Ceci se produit en général lorsque vous avez une table avec des triggers que la rélication a du cacher
+lors de l'abonnement du noeud et que vous avez ajouter un tiggrer portant le même nom. Maintenant, lorsque l'on tente de
+réactiver le trigger caché, les deux triggers entre en conflit.
+ </para>
-<para> The DDL script will keep running and rerunning, or the UNINSTALL NODE will keep failing, until you drop the <quote>visible</quote> trigger, by hand, much as you must have added it, by hand, earlier. </para>
+<para> Le script DDL continuera a tourner, encore et encore, ou la commande UNINSTALL NODE échoura,
+jusqu'à ce que vous supprimiez le trigger <quote>visible</quote> à la main, puisque vous l'avez probablement
+ajouté à la main un peu plus tôt. </para>
</listitem>
+
<listitem><para><command>ERROR: Slony-I: Unable to disable triggers</command></para>
-<para> This is the error that follows the <quote>multiple triggers</quote> problem. </para></listitem>
+<para> Cette erreur se produit à la suite du problème de <quote>triggers multiples</quote>. </para></listitem>
</itemizedlist>
</sect3>
-<sect3><title> Threading Issues </title>
+<sect3><title> Problèmes avec les processus</title>
-<para> There should not be any <quote>user-serviceable</quote> aspects
-to the &slony1; threading model; each &lslon; creates a quite
-well-specified set of helper threads to manage the various database
-connections that it requires. The only way that anything should break
-on the threading side is if you have not compiled &postgres; libraries
-to <quote>play well</quote> with threading, in which case you will be
-unable to compile &slony1; in the first place. </para>
+<para> Le modèle de gestion des processus ("threading") de &slony1; n'est pas
+directement <quote>paramètrable par les utilisateurs</quote>;
+Chaque démon &lslon; crée un ensemble pré-défini de processus pour gérer
+les différentes connexions nécessaires. La seule occasion où la gestion
+des processus peut poser problème est lorsque les librairies de &postgres;
+n'ont pas été compilées <quote>correctement</quote>, auquel cas
+il sera de toute façon impossible de compiler &slony1;. </para>
<itemizedlist>
<listitem><para><command>FATAL: remoteWorkerThread_%d: pthread_create() - %s</command></para>
-<para> Couldn't create a new remote worker thread. </para>
+<para> Impossible de créer un nouveau processus de traitement des événements distants. </para>
</listitem>
<listitem><para><command>DEBUG1 remoteWorkerThread_%d: helper thread for provider %d created</command></para>
-<para> This normally happens when the &lslon; starts: a thread is created for each node to which the local node should be listening for events.</para></listitem>
+<para> Ceci se produit en général lorsque le démon &lslon; démarre : un processus est créé pour
+chaque noeud que le le noeud local doit écouter.</para></listitem>
<listitem><para><command>DEBUG1: remoteWorkerThread_%d: helper thread for provider %d terminated </command></para>
-<para> If subscriptions reshape such that a node no longer provides a
-subscription, then the thread that works on that node can be
-dropped. </para></listitem>
+<para> Si un abonnement est modifié et qu'un noeud n'est plus un noeud fournisseur,
+alors le processus qui traite les événements sur ce noeud peut être arrêté. </para></listitem>
<listitem><para><command>DEBUG1: remoteWorkerThread_%d: disconnecting
from data provider %d </command></para>
-<para> A no-longer-used data provider may be dropped; if connection
-information is changed, the &lslon; needs to disconnect and
-reconnect. </para></listitem>
+<para> Un noeuf fournisseur qui n'est plus utilisé peut être supprimé;
+si les informations de connexion sont changées, le démon &lslon; doit se déconnecter et
+se reconnecter. </para></listitem>
<listitem><para><command>DEBUG2: remoteWorkerThread_%d: ignore new events due to shutdown</command></para>
-<para> If the &lslon; is shutting down, it is futile to process more events</para></listitem>
+<para> Si le démon &lslon; est en cours d'arrêt, il est futile de traiter d'autres événéments.</para></listitem>
+
<listitem><para><command>DEBUG1: remoteWorkerThread_%d: node %d - no worker thread</command></para>
-<para> Curious: we can't wake up the worker thread; there probably
-should already be one... </para></listitem>
+<para> Curieux : il est impossibe de réveiller le processus de traitement; pourtant il devrait déjà
+y en avoir un... </para></listitem>
</itemizedlist>
</sect3>
-<sect3 id="logsubtime"><title> Log Entries At Subscription Time </title>
+<sect3 id="logsubtime"><title> Messages de log au moment d'un abonnement </title>
-<para> Subscription time is quite a special time in &slony1;. If you
+<para> Un abonnement est Subscription time is quite a special time in &slony1;. If you
have a large amount of data to be copied to subscribers, this may take
a considerable period of time. &slony1; logs a fairly considerable
amount of information about its progress, which is sure to be useful
More information about the Trad
mailing list