Changeset 1128

Show
Ignore:
Timestamp:
09/05/08 13:37:44 (3 months ago)
Author:
daamien
Message:

slony : log analysis (2/5)

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/loganalysis.xml

    r937 r1128  
    66 
    77<sect1 id="loganalysis"> 
    8 <title>Log Analysis</title> 
    9  
    10 <indexterm><primary>Log analysis</primary></indexterm> 
    11  
    12 <para>Here are some of things that you may find in your &slony1; logs, 
    13 and explanations of what they mean.</para> 
    14  
    15 <sect2><title>CONFIG notices</title> 
    16  
    17 <para>These entries are pretty straightforward. They are informative 
    18 messages about your configuration.</para> 
    19  
    20 <para>Here are some typical entries that you will probably run into in 
    21 your logs: 
     8<title>Analyses des logs</title> 
     9 
     10<indexterm><primary>Analyse des logs</primary></indexterm> 
     11 
     12<para>Voici un tour d'horizon des informations que vous trouverez dans les logs de &slony1;, 
     13ainsi que des explications sur leur signification.</para> 
     14 
     15<sect2><title>Notification CONFIG</title> 
     16 
     17<para>Ces lignes sont assez triviales. Ce sont des messages d'information  
     18à propos de la configuration.</para> 
     19 
     20<para>Voici quelques lignes typiques que vous pouvez rencontrer : 
    2221 
    2322<screen> 
    …… 
    3130</screen></para></sect2> 
    3231 
    33 <sect2><title>INFO notices</title> 
    34  
    35 <para> Events that take place that seem like they will generally be of 
    36 interest are recorded at the INFO level, and, just as with CONFIG 
    37 notices, are always listed. </para> 
     32<sect2><title>Notifications INFO</title> 
     33 
     34<para> Les événements qui semble avoir un intérêt au niveau INFO, 
     35et qui sont toujours listés , tout comme les notifications CONFIG.  
     36</para> 
    3837 
    3938</sect2> 
    4039 
    41 <sect2><title>DEBUG Notices</title> 
    42  
    43 <para>Debug notices are of less interest, and will quite likely only 
    44 need to be shown if you are running into some problem with &slony1;.</para> 
     40<sect2><title>Notifications DEBUG</title> 
     41 
     42<para>Les notifications DEBUG sont moins intéressantes, et ne vous seront 
     43utile que lorsque vous rencontrez une problÚme avec &slony1;.</para> 
    4544 
    4645</sect2> 
    4746 
    48 <sect2><title>Thread name </title> 
    49  
    50 <para> Notices are always prefaced by the name of the thread from 
    51 which the notice originates. You will see messages from the following 
    52 threads:   
     47<sect2><title>Nom du processus </title> 
     48 
     49<para> Les notifications sont toujours précédées par le nom du processus  
     50qui produit cette nottification. Vous verez des messages en provenance 
     51des processus suivants :   
    5352 
    5453<variablelist> 
    5554<varlistentry><term>localListenThread</term>  
    5655 
    57 <listitem><para> This is the local thread that listens for events on 
    58 the local node.</para></listitem></varlistentry> 
     56<listitem><para> Le processus local qui écoute les événements sur le noeud local.</para></listitem></varlistentry> 
    5957 
    6058<varlistentry><term>remoteWorkerThread-X</term>  
    6159 
    62 <listitem><para> The thread processing remote events.  You can expect 
    63 to see one of these for each node that this node communicates 
    64 with.</para></listitem></varlistentry> 
     60<listitem><para> Les processus qui traitent les événments distants. Vous verrez un de  
     61ces processus pour chaque noeud qui est en communication avec le noeud local. 
     62</para></listitem></varlistentry> 
    6563 
    6664<varlistentry><term>remoteListenThread-X</term> 
    6765 
    68 <listitem><para>Listens for events on a remote node database.  You may 
    69 expect to see one of these for each node in the 
    70 cluster.</para></listitem></varlistentry> 
    71  
    72 <varlistentry><term>cleanupThread</term> <listitem><para> Takes care 
    73 of things like vacuuming, cleaning out the confirm and event tables, 
    74 and deleting old data.</para></listitem></varlistentry> 
    75  
    76 <varlistentry><term>syncThread</term> <listitem><para> Generates SYNC 
    77 events.</para></listitem></varlistentry> 
     66<listitem><para>Les processus qui écoutent les événements distants. 
     67Vous verrez un de  
     68ces processus pour chaque noeud du cluster.</para></listitem></varlistentry> 
     69 
     70<varlistentry><term>cleanupThread</term>  
     71<listitem><para> Le processus qui prend en charge les opérations telles que  
     72les VACUUM, le nettoyage des tables confirm and event, 
     73et la suppression des données périmées.</para></listitem></varlistentry> 
     74 
     75<varlistentry><term>syncThread</term> <listitem> 
     76<para> Le processus qui produit les événements SYNC.</para> 
     77</listitem></varlistentry> 
    7878 
    7979</variablelist> 
    8080</para> 
    8181 
    82 <para> How much information they display is controlled by 
    83 the <envar>log_level</envar> &lslon; parameter; 
    84 ERROR/WARN/CONFIG/INFO messages will always be displayed, while 
    85 choosing increasing values from 1 to 4 will lead to additional DEBUG 
    86 level messages being displayed. </para> 
     82<para> La quantité d'information que ces processus affichent est controlée par 
     83le paramÚtre <envar>log_level</envar> de &lslon;; 
     84Les messages de type ERROR/WARN/CONFIG/INFO seront toujours affichés, 
     85augmenter la valeur de 1 à 4 affichera des plus en plus de messages de DEBUG.  
     86</para> 
    8787</sect2> 
    8888 
    89 <sect2> <title> How to read &slony1; logs </title> 
    90  
    91 <indexterm><primary>reading and understanding &slony1; logs</primary></indexterm> 
    92  
    93 <para> Note that as far as slon is concerned, there is no 
    94 <quote>master</quote> or <quote>slave.</quote> They are just 
    95 nodes. </para> 
    96  
    97 <para>What you can expect, initially, is to see, on both nodes, some 
    98 events propagating back and forth.  Firstly, there should be some 
    99 events published to indicate creation of the nodes and paths.  If you 
    100 don't see those, then the nodes aren't properly communicating with one 
    101 another, and nothing else will happen... </para> 
    102  
    103 <itemizedlist> 
    104  
    105 <listitem><para>Create the two nodes.</para>  
    106  
    107 <para> No slons are running yet, so there are no logs to look 
    108 at.</para> 
    109  
    110 </listitem> 
    111  
    112 <listitem><para> Start the two slons</para> 
    113  
    114 <para> The logs for each will start out very quiet, as neither node 
    115 has much to say, and neither node knows how to talk to another node. 
    116 Each node will periodically generate a <command>SYNC</command> event, 
    117 but recognize <emphasis>nothing</emphasis> about what is going on on 
    118 other nodes.</para> 
    119  
    120 </listitem> 
    121  
    122 <listitem><para> Do the <xref linkend="stmtstorepath"/> to set up 
    123 communications paths.  That will allow the nodes to start to become 
    124 aware of one another.</para> 
    125  
    126 <para> The slon logs should now start to receive events from 
    127 <quote>foreign</quote> nodes.</para> 
    128  
    129 <para> In version 1.0, <xref linkend="table.sl-listen"/> is not set up 
    130 automatically, so things still remain quiet until you explicitly 
    131 submit <command>STORE LISTEN</command> requests. In version 1.1, the 
    132 <quote>listen paths</quote> are set up automatically, which will much 
    133 more quickly get the communications network up and running.  </para> 
    134  
    135 <para> If you look at the contents of the tables <xref 
    136 linkend="table.sl-node"/> and <xref linkend="table.sl-path"/> and <xref 
    137 linkend="table.sl-listen"/>, on each node, that should give a good idea 
    138 as to where things stand.  Until the <xref linkend="slon"/> starts, 
    139 each node may only be partly configured.  If there are two nodes, 
    140 there should be two entries in all three of these tables once the 
    141 communications configuration is set up properly.  If there are fewer 
    142 entries than that, well, that should give you some idea of what is 
    143 missing.</para> 
    144 </listitem> 
    145  
    146 <listitem><para> If needed (<emphasis>e.g.</emphasis> - before version 
    147 1.1), submit <xref linkend="stmtstorelisten"/> requests to indicate how 
    148 the nodes will use the communications paths. </para> 
    149  
    150 <para> Once this has been done, the nodes' logs should show a greater 
    151 level of activity, with events periodically being initiated on one 
    152 node or the other, and propagating to the other. </para> 
    153 </listitem> 
    154  
    155 <listitem> <para> You'll set up the set 
    156 (<xref linkend="stmtcreateset"/>), add tables 
    157 (<xref linkend="stmtsetaddtable"/>), and sequences 
    158 (<xref linkend="stmtsetaddsequence"/>), and will see relevant 
    159 events <xref linkend="logaddobjects"/> only in the logs for the origin 
    160 node for the set. </para></listitem> 
    161  
    162 <listitem><para> Then, when you submit the <xref 
    163 linkend="stmtsubscribeset"/> request, the event should go to both 
    164 nodes. </para> 
    165  
    166 <para> The origin node has little more to do, after that...  The 
    167 subscriber will then have a <command>COPY_SET</command> event, which 
    168 will lead to logging information about adding each table and copying 
    169 its data.  See <xref linkend="logsubtime"/> for more 
    170 details.</para></listitem> 
    171  
    172 </itemizedlist> 
    173  
    174 <para>After that, you'll mainly see two sorts of behaviour:</para> 
    175  
    176 <itemizedlist> 
    177  
    178 <listitem><para> On the origin, there won't be too terribly much 
    179 logged, just indication that some <command>SYNC</command> events are 
    180 being generated and confirmed by other nodes. 
    181 See <xref linkend="lognormalsync"/> to see the sorts of log entries to 
    182 expect.</para></listitem> 
    183  
    184 <listitem><para> On the subscriber, there will be reports of 
    185 <command>SYNC</command> events, and that the subscriber pulls data 
    186 from the provider for the relevant set(s).  This will happen 
    187 infrequently if there are no updates going to the origin node; it will 
    188 happen frequently when the origin sees heavy updates. </para> 
     89<sect2> <title> Comment lire les logs &slony1; </title> 
     90 
     91<indexterm><primary>lire et comprendre les logs &slony1;</primary></indexterm> 
     92 
     93<para> Notons que du point de vue d'un processus slon, il n'y a pas de 
     94<quote>maître</quote> ni d'<quote>esclave</quote>. Il y a juste des noeuds. 
     95</para> 
     96 
     97<para>On s'attend, de prime abord, à voir sur chaque noeuds des événements 
     98se propager dans les deux sens. Dans un premier temps, il doit y avoir  
     99des événements publiés qui témoignent de la création des noeuds et des  
     100voies de communications. Si vous ne les voyez pas, alors les noeuds 
     101ne communiquent pas correctement entre eux et rien ne va se passer... 
     102 </para> 
     103 
     104<itemizedlist> 
     105 
     106<listitem><para>Créer les deux noeuds.</para>  
     107 
     108<para> Aucun slons ne fonctionne à ce stade, donc il n'y a aucun logs à consulter.</para> 
     109 
     110</listitem> 
     111 
     112<listitem><para>Lancer les deux noeuds</para> 
     113 
     114<para> Les logs de chaque noeuds n'auront pas une activité débordante, car aucun  
     115les noeuds n'ont pas grand'chose à dire et qu'ils ne savent pas  
     116comment communiquer entre eux. Chaque noeud génÚre périodiquement  
     117un événement <command>SYNC</command>, mais ne perçoit <emphasis>rien</emphasis> 
     118de ce qui se passe sur les autres noeuds.</para> 
     119  
     120</listitem> 
     121 
     122<listitem><para> Lancer <xref linkend="stmtstorepath"/> pour configuration les  
     123voies de communications. Ceci devrait permettre aux noeuds de prendre conscience 
     124de l'existance de leurs voisins.</para> 
     125 
     126<para> Les logs de slon doivent maintenant recevoir les événéments en provenance 
     127des noeuds <quote>étrangers</quote>.</para> 
     128 
     129<para> Dans la 1.0, <xref linkend="table.sl-listen"/> n'est pas configuré 
     130automatiquement, donc les logs vont rester calmes tant que vous n'aurez 
     131pas soumit explicitement les requêtes <command>STORE LISTEN</command>. 
     132Dans la  version 1.1, les <quote>voies d'écoute</quote> cont configurées automatiquement, 
     133ce qui nous donne un réseau de communication opérationnel plus rapidement. 
     134</para> 
     135 
     136<para> Si vous consultez le contenu des tables <xref 
     137linkend="table.sl-node"/>, <xref linkend="table.sl-path"/> et  <xref 
     138linkend="table.sl-listen"/>, sur chaque noeud, cela vous donnera une bonne 
     139idée de l'état du réseau de communication.  
     140Jusqu'à ce que les <xref linkend="slon"/> démarrent, chaque noeud 
     141est partiellement configuré. Si le cluster contient deux noeuds, 
     142alors il doit y avoir deux entrées dans chacune des trois tables 
     143une fois que les commnications sont correctement configurées. 
     144Si il y a moins d'entrées, vous devriez pouvoir deviner ce qui manque. 
     145</para> 
     146</listitem> 
     147 
     148<listitem><para> Si nécessaire (<emphasis>c'est à dire</emphasis> - si votre version est  
     149antérieurs à la version 1.1), lancer des requêtes <xref linkend="stmtstorelisten"/>  
     150pour indiquer comment les noeuds utiliseront les voies de communications. 
     151</para> 
     152 
     153<para> Une fois que c'est fait, les logs des noeuds afficheront un niveau  
     154d'activité supérieur, notamment les événements produits périodiquement sur  
     155les différents noeuds, ainsi que leur propagation. </para> 
     156</listitem> 
     157 
     158<listitem> <para> Configurer l'ensemble de réplication avec 
     159(<xref linkend="stmtcreateset"/>), ajouter les tables avec 
     160(<xref linkend="stmtsetaddtable"/>), les sequences avec 
     161(<xref linkend="stmtsetaddsequence"/>), puis vérifier que vous 
     162retrouvez des logs adéquats avec <xref linkend="logaddobjects"/>  
     163uniquement dans les logs du noeud d'origine de l'ensemble de  
     164réplication. </para></listitem> 
     165 
     166<listitem><para> Soumettre une requête <xref 
     167linkend="stmtsubscribeset"/>, l'événement devrait être visible 
     168sur les deux noeuds. </para> 
     169 
     170<para> Il reste quelques actions à mener sur le noeud origine... L'abonné  
     171doit ensuite recevoir un événement <command>COPY_SET</command>, 
     172ce qui doit afficher des informations dans les logs à propos de  
     173l'ajout de chaque table et de la copie de leurs données. 
     174Consulter la section <xref linkend="logsubtime"/> pour pus de détails. 
     175</para></listitem> 
     176 
     177</itemizedlist> 
     178 
     179<para>A partir de là, vous constaterez deux types de comportements :</para> 
     180 
     181<itemizedlist> 
     182 
     183<listitem><para> Sur le noeud origine, peu d'informations seront enregistrés 
     184dans les logs, juste des indications sur les événéments <command>SYNC</command> 
     185générés et confirmés par les autres noeuds. Consultez la section  
     186<xref linkend="lognormalsync"/> pour plus d'informations sur les différents  
     187types de lignes de logs que vous pouvez rencontrer.</para></listitem> 
     188 
     189<listitem><para> Sur le noeud abonné, vous trouverez des rapports sur les 
     190événements <command>SYNC</command>, et sur les données que l'abonné  
     191obtient du fournisseur. Ceci se produit peu fréquemment si le noeud origine 
     192ne reçoit pas de mises à jour; c'est au contraire trÚs fréquent si le noeud 
     193origine reçoit beaucoup de modifications.</para> 
    189194</listitem> 
    190195 
    …… 
    193198</sect2> 
    194199 
    195 <sect2> <title> Log Messages and Implications </title> 
    196  
    197 <para> This section lists numerous of the error messages found in 
    198 &slony1;, along with a brief explanation of implications.  It is a 
    199 fairly comprehensive list, only eaving out mostly some of 
    200 the <command>DEBUG4</command> messages that are almost always 
    201 uninteresting.</para> 
    202  
    203 <sect3 id="logshiplog"><title> Log Messages Associated with Log Shipping </title> 
    204  
    205 <para> Most of these represent errors that come up if 
    206 the <xref linkend="logshipping"/> functionality breaks.  You may expect 
    207 things to break if the filesystem being used for log shipping fills, 
    208 or if permissions on that directory are wrongly set. </para> 
     200<sect2> <title> Les messages de log et leurs implications </title> 
     201 
     202<para> Cette section énumÚre les nombreux messages d'erreurs que l'on peut  
     203trouver dans les logs de &slony1;, ainsi qu'une brÚve explication de leur implication. 
     204Il s'agit d'une liste relativement compréhensible, qui omet simplement 
     205certain messages de niveau <command>DEBUG4</command> qui sont presque toujours 
     206inintéressant.</para> 
     207 
     208<sect3 id="logshiplog"><title> Les messages de log associaté au Log Shipping </title> 
     209 
     210<para> La pluspart de ces messages concernent des erreurs qui se produisent  
     211lorsque le mécanisme de <xref linkend="logshipping"/> échoue.  En général,  
     212cela se produit si le systÚme de fichier utilisé pour le log shipping est plein, 
     213ou si les permissions d'un répertoire sont mal définies. </para> 
    209214 
    210215<itemizedlist> 
    211216<listitem><para><command>ERROR: remoteWorkerThread_%d: log archive failed %s - %s\n</command> </para>  
    212217 
    213 <para> This indicates that an error was encountered trying to write a 
    214 log shipping file.  Normally the &lslon; will retry, and hopefully 
    215 succeed. </para> </listitem> 
     218<para> Ce message indique qu'une erreur a été rencontrée en essayent d'écrire un  
     219fichier de log shipping. Normalement le démon &lslon; essaie à nouveau, jusqu'à ce qu'il réussisse 
     220. </para> </listitem> 
    216221 
    217222<listitem><para><command>DEBUG2: remoteWorkerThread_%d: writing archive log...</command></para>  
    218223 
    219 <para> This indicates that a log shipping archive log is being written for a particular <command>SYNC</command> set. </para></listitem> 
     224<para> Ce message indique qu'un fichier archive log est écrit pour un ensemble de <command>SYNC</command> particulier. </para></listitem> 
    220225 
    221226<listitem><para><command>INFO: remoteWorkerThread_%d: Run Archive Command %s</command></para>  
    222227 
    223 <para> If &lslon; has been configured (<option>-x</option> 
    224 aka <envar>command_on_logarchive</envar>) to run a command after 
    225 generating each log shipping archive log, this reports when that 
    226 process is spawned using <function>system()</function>. </para> </listitem> 
     228<para> Si &lslon; est configuré ( avec l'option <option>-x</option> 
     229c'est à dire <envar>command_on_logarchive</envar>) pour lancer une commande 
     230aprÚs chaque génération de ficheir archive log, ce message indique quand cette commande 
     231est effectuée via la fonction <function>system()</function>. </para> </listitem> 
    227232 
    228233<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not open 
    229234COPY SET archive file %s - %s</command></para> 
    230235 
    231 <para> Seems pretty self-explanatory... </para></listitem> 
     236<para> Ce message semble assez explicite... </para></listitem> 
     237 
    232238<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate COPY SET archive header %s - %s</command></para>  
    233239 
    234 <para> Probably means that we just filled up a filesystem... </para></listitem> 
     240<para> Ce message signifie probablement que vous avez saturé le systÚme de fichier... </para></listitem> 
    235241 
    236242<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> 
    237243 
    238 <para> This may occasionally occur when using logshipping; this will 
    239 typically happen if there are 3 or more nodes, and there is an attempt 
    240 to concurrently process events sourced from different nodes.  This 
    241 does not represent any serious problem; &slony1; will retry the event 
    242 which failed without the need for administrative intervention. </para> 
    243 </listitem> 
    244  
    245 </itemizedlist> 
    246 </sect3> 
    247  
    248 <sect3 id="ddllogs"><title> Log Messages -  DDL scripts </title>  
    249  
    250 <para> The handling of DDL is somewhat fragile, as described 
    251 in <xref linkend="ddlchanges"/>; here are both informational and error 
    252 messages that may occur in the progress of 
    253 an <xref linkend="stmtddlscript"/> request.</para> 
     244<para> Ce message se produit occasionnelement lorsqu'on utilise le log shipping; 
     245il se produit généralement lorsque que le cluster contient 3 noeuds ou plus, 
     246et que le démon tente d'exécuter simultanément des événements en provenance de 
     247différents noeuds. Ceci ne réprésente pas un problÚme sérieux;  &slony1;  
     248tentera à nouveau de traiter l'événement qui a échoué, sans que l'intervention 
     249d'un administrateur soit nécessaire. </para> 
     250</listitem> 
     251 
     252</itemizedlist> 
     253</sect3> 
     254 
     255<sect3 id="ddllogs"><title> Messages de logs à propose des DDL scripts </title>  
     256 
     257<para> La gestion des ordres DDL est un peu fragile, comme indiqué 
     258dans la section <xref linkend="ddlchanges"/>; voici des messages à  
     259caractÚre informatif et des messages d'erreur qui se produisent lors de l'exécution d'une requête  
     260<xref linkend="stmtddlscript"/>.</para> 
    254261 
    255262<itemizedlist> 
    …… 
    258265failed - set %d - only on node %</command></para> 
    259266 
    260 <para> Something broke when applying a DDL script on one of the nodes. 
    261 This is quite likely indicates that the node's schema differed from 
    262 that on the origin; you may need to apply a change manually to the 
    263 node to allow the event to proceed.  The scary, scary alternative 
    264 might be to delete the offending event, assuming it can't possibly 
    265 work...</para> </listitem> 
     267<para> Quelque chose s'est cassé lors du traitement d'un script DDL sur un des noeuds. 
     268Ceci indique probablement que le schéma du noeud était différent de celui du  
     269noeud origine; vous devez probablement effectuer une modification à la main  
     270sur ce noeud pour l'événement puisse être traité.  
     271Une alternative trÚs regrettable consiste à supprimer l'événement bloquant,  
     272sachant qu'il est possible que cette suppression ne fonctionne pas...</para> </listitem> 
     273 
    266274<listitem><para><command>SLON_CONFIG: remoteWorkerThread_%d: DDL request with %d statements</command></para>  
    267 <para> This is informational, indicating how many SQL statements were processed. </para></listitem> 
     275<para> Ce message est informatif, il indique combien de commandes SQL ont été traitées. </para></listitem> 
     276 
    268277<listitem><para><command>SLON_ERROR: remoteWorkerThread_%d: DDL had invalid number of statements - %d</command></para>  
    269278 
    270 <para> Occurs if there were &lt; 0 statements (which should be impossible) or > MAXSTATEMENTS statements.  Probably the script was bad...</para></listitem> 
     279<para> Ce message se produit lorsque le nombre de commandes traitées est &lt; 0 (ce qui est théoriquement impossible)  
     280ou > MAXSTATEMENTS.  Ceci indique que le scripts DDL est probablement mal écrit...</para></listitem> 
    271281 
    272282<listitem><para><command>ERROR: remoteWorkerThread_%d: malloc() 
    …… 
    274284memory</command></para> 
    275285 
    276 <para> This should only occur if you submit some extraordinarily large 
    277 DDL script that makes a &lslon; run out of memory </para></listitem> 
     286<para> Ceci se produit uniquement si vous soumettez un script DDL extraordinairement long,  
     287qui sature la mémoire allouée à &lslon; ("out of memory") </para></listitem> 
    278288 
    279289<listitem><para><command>CONFIG: remoteWorkerThread_%d: DDL Statement %d: [%s]</command></para>  
    280290 
    281 <para> This lists each DDL statement as it is submitted. </para></listitem> 
     291<para> Ce message fait la liste de tous les ordres DDL au fur et à mesure qu'ils sont soumis. 
     292 </para></listitem> 
     293 
    282294<listitem><para><command>ERROR: DDL Statement failed - %s</command></para>  
    283295 
    284 <para> Oh, dear, one of the DDL statements that worked on the origin 
    285 failed on this remote node... </para></listitem> 
     296<para> Oh mon dieu ! un des ordres DDL  a fonctionné sur le noeud origine mais il a échoués 
     297sur le noeud local... </para></listitem> 
    286298 
    287299<listitem><para><command>CONFIG: DDL Statement success - %s</command></para>  
    288300 
    289 <para> All's well...  </para></listitem> 
     301<para> Tout va bien...  </para></listitem> 
    290302 
    291303<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate DDL archive tracker %s - %s</command></para>  
    292304 
    293 <para> Apparently the DDL script couldn't be written to a log shipping file... </para></listitem> 
     305<para> Apparemment le script DDL ne peut pas être écrit dans le fichier de log shipping... </para></listitem> 
    294306 
    295307<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not submit DDL script %s - %s</command></para>  
    296308 
    297 <para>Couldn't write the script to a log shipping file.</para> </listitem> 
     309<para>Le script ne peut pas être écrit dans un ficheir de log shipping.</para> </listitem> 
    298310 
    299311<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not close DDL script %s - %s</command></para>  
    300312 
    301 <para>Couldn't close a log shipping file for a DDL script.</para> </listitem> 
     313<para>Impossible de fermer un fichier de log shipping contenant un script DDL.</para> </listitem> 
     314 
    302315<listitem><para><command>ERROR: Slony-I ddlScript_prepare(): set % not found</command></para>  
    303316 
    304 <para> Set wasn't found on this node; you probably gave the wrong ID number... </para></listitem> 
     317<para> L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un 
     318mauvais identifiant de noeud... </para></listitem> 
    305319 
    306320<listitem><para><command>ERROR: Slony-I ddlScript_prepare_int(): set % not found</command></para>  
    307321 
    308 <para> Set wasn't found on this node; you probably gave the wrong ID number... </para></listitem> 
     322<para>L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un 
     323mauvais identifiant de noeud... </para></listitem> 
    309324 
    310325<listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table with id % not found</command></para>  
    311 <para> Apparently the table wasn't found; could the schema be messed up? </para> </listitem> 
     326 
     327<para> Apparemment la table n'a pas été trouvée; Le schéma est peut-être erroné ? </para> </listitem> 
    312328 
    313329<listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table % is already in altered state</command></para>  
    314330 
    315 <para> Curious...  We're trying to set a table up for replication 
    316 a <emphasis>second</emphasis> time?  </para> </listitem> 
     331<para> Curieux...  Le script tente de répliquer une table une <emphasis>seconde</emphasis> fois ?  </para> </listitem> 
    317332 
    318333<listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table with id % not found</command></para>  
    319334 
    320 <para> This runs when a table is being restored to <quote>non-replicated</quote> state; apparently the replicated table wasn't found.</para></listitem> 
     335<para> Ce message se produit lorsqu'une table est en cours de restauration vers un état <quote>non-repliqué</quote>; 
     336apparemment la table répliquée n'a pas été trouvée.</para></listitem> 
    321337 
    322338<listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table % is not in altered state</command></para>  
    323339 
    324 <para> Hmm.  The table isn't in altered replicated state.  That shouldn't be, if replication had been working properly...</para> </listitem> 
     340<para> Hmm.  La table n'est pas dans un état réliqué. Cela ne devrait pas se produire si la réplication  
     341fonctionne correctement...</para> </listitem> 
     342 
    325343<listitem><para><command>NOTICE: Slony-I: alterTableForReplication(): multiple instances of trigger % on table %'',</command></para>  
    326344 
    327 <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> 
    328  
    329 <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> 
    330 </listitem> 
     345<para> Ceci se produit en général lorsque vous avez une table avec des triggers que la rélication a du cacher 
     346lors de l'abonnement du noeud et que vous avez ajouter un tiggrer portant le même nom. Maintenant, lorsque l'on tente de 
     347réactiver le trigger caché, les deux triggers entre en conflit. 
     348 </para> 
     349 
     350<para> Le script DDL continuera a tourner, encore et encore, ou la commande UNINSTALL NODE échoura, 
     351jusqu'à ce que vous supprimiez le trigger <quote>visible</quote> à la main, puisque vous l'avez probablement 
     352ajouté à la main un peu plus tÃŽt. </para> 
     353</listitem> 
     354 
    331355<listitem><para><command>ERROR: Slony-I: Unable to disable triggers</command></para>  
    332 <para> This is the error that follows the <quote>multiple triggers</quote> problem. </para></listitem> 
    333 </itemizedlist> 
    334 </sect3> 
    335  
    336 <sect3><title> Threading Issues </title> 
    337  
    338 <para> There should not be any <quote>user-serviceable</quote> aspects 
    339 to the &slony1; threading model; each &lslon; creates a quite 
    340 well-specified set of helper threads to manage the various database 
    341 connections that it requires.  The only way that anything should break 
    342 on the threading side is if you have not compiled &postgres; libraries 
    343 to <quote>play well</quote> with threading, in which case you will be 
    344 unable to compile &slony1; in the first place. </para> 
     356<para> Cette erreur se produit à la suite du problÚme de <quote>triggers multiples</quote>. </para></listitem> 
     357</itemizedlist> 
     358</sect3> 
     359 
     360<sect3><title> ProblÚmes avec les processus</title> 
     361 
     362<para> Le modÚle de gestion des processus ("threading") de &slony1; n'est pas  
     363directement <quote>paramÚtrable par les utilisateurs</quote>; 
     364Chaque démon &lslon; crée un ensemble pré-défini de processus pour gérer  
     365les différentes connexions nécessaires. La seule occasion où la gestion  
     366des processus peut poser problÚme est lorsque les librairies de &postgres; 
     367n'ont pas été compilées <quote>correctement</quote>, auquel cas  
     368il sera de toute façon impossible de compiler &slony1;. </para> 
    345369 
    346370<itemizedlist> 
    347371<listitem><para><command>FATAL: remoteWorkerThread_%d: pthread_create() - %s</command></para>  
    348372 
    349 <para> Couldn't create a new remote worker thread. </para> 
     373<para> Impossible de créer un nouveau processus de traitement des événements distants. </para> 
    350374</listitem> 
    351375<listitem><para><command>DEBUG1 remoteWorkerThread_%d: helper thread for provider %d created</command></para>  
    352376 
    353 <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> 
     377<para> Ceci se produit en général lorsque le démon &lslon; démarre : un processus est créé pour  
     378chaque noeud que le le noeud local doit écouter.</para></listitem> 
    354379 
    355380<listitem><para><command>DEBUG1: remoteWorkerThread_%d: helper thread for provider %d terminated </command></para>  
    356381 
    357 <para> If subscriptions reshape such that a node no longer provides a 
    358 subscription, then the thread that works on that node can be 
    359 dropped. </para></listitem> 
     382<para> Si un abonnement est modifié et qu'un noeud n'est plus un noeud fournisseur, 
     383alors le processus qui traite les événements sur ce noeud peut être arrêté. </para></listitem> 
    360384 
    361385<listitem><para><command>DEBUG1: remoteWorkerThread_%d: disconnecting 
    362386from data provider %d </command></para> 
    363387 
    364 <para> A no-longer-used data provider may be dropped; if connection 
    365 information is changed, the &lslon; needs to disconnect and 
    366 reconnect. </para></listitem> 
     388<para> Un noeuf fournisseur qui n'est plus utilisé  peut être supprimé; 
     389si les informations de  connexion sont changées, le démon &lslon; doit se déconnecter et  
     390se reconnecter. </para></listitem> 
    367391 
    368392<listitem><para><command>DEBUG2: remoteWorkerThread_%d: ignore new events due to shutdown</command></para>  
    369393 
    370 <para> If the &lslon; is shutting down, it is futile to process more events</para></listitem> 
     394<para> Si le démon &lslon; est en cours d'arrêt, il est futile de traiter d'autres événéments.</para></listitem> 
     395 
    371396<listitem><para><command>DEBUG1: remoteWorkerThread_%d: node %d - no worker thread</command></para>  
    372397 
    373 <para> Curious: we can't wake up the worker thread; there probably 
    374 should already be one... </para></listitem> 
    375  
    376 </itemizedlist> 
    377 </sect3> 
    378  
    379 <sect3 id="logsubtime"><title> Log Entries At Subscription Time </title> 
    380  
    381 <para> Subscription time is quite a special time in &slony1;.  If you 
     398<para> Curieux : il est impossibe de réveiller le processus de traitement; pourtant il devrait déjà 
     399y en avoir un... </para></listitem> 
     400 
     401</itemizedlist> 
     402</sect3> 
     403 
     404<sect3 id="logsubtime"><title> Messages de log au moment d'un abonnement </title> 
     405 
     406<para> Un abonnement est Subscription time is quite a special time in &slony1;.  If you 
    382407have a large amount of data to be copied to subscribers, this may take 
    383408a considerable period of time.  &slony1; logs a fairly considerable