Changeset 1083

Show
Ignore:
Timestamp:
07/02/08 17:45:22 (2 months ago)
Author:
david.tokmatchi@gmail.com
Message:

--

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/faq.xml

    r969 r1083  
    11<?xml version="1.0" encoding="UTF-8"?> 
    2 <!-- DerniÚre modification 
     2<!-- Dernière modifications 
    33     le       $Date$ 
    44     par      $Author$ 
    5      révision $Revision$ --> 
     5     révision $Revision$ --> 
    66 
    77<qandaset> 
    8 <indexterm><primary>Frequently Asked Questions about &slony1;</primary></indexterm> 
    9  
    10 <qandadiv id="faqcompiling"><title> &slony1; FAQ: Building and Installing &slony1; </title> 
    11  
    12 <qandaentry> 
    13  
    14 <question><para> I am using <productname> Frotznik Freenix 
    15 4.5</productname>, with its <acronym>FFPM</acronym> (Frotznik Freenix 
    16 Package Manager) package management system.  It comes with 
    17 <acronym>FFPM</acronym> packages for &postgres; 7.4.7, which are what 
    18 I am using for my databases, but they don't include &slony1; in the 
    19 packaging.  How do I add &slony1; to this?  </para> 
     8<indexterm><primary>Questions Fréquemment Posées à  propos de &slony1;</primary></indexterm> 
     9 
     10<qandadiv id="faqcompiling"><title> &slony1; FAQ: Monter et Installer &slony1; </title> 
     11 
     12<qandaentry> 
     13 
     14<question><para> J'utilise <productname> Frotznik Freenix 
     154.5</productname>, avec son <acronym>FFPM</acronym> (Frotznik Freenix 
     16Package Manager) gestionnaire des paquetage système.  L'arrivée de 
     17<acronym>FFPM</acronym> c'est l'introduction des paquetages pour &postgres; 7.4.7, lequel je suis actuellement 
     18entrain d'utiliser pour ma base de données, mais qui n'inclut pas encore les paquetages &slony1. 
     19Comment puis-je rajouter &slony1; à cette configuration?  </para> 
    2020</question> 
    2121 
    2222 
    23 <answer><para> <productname>Frotznik Freenix</productname> is new to 
    24 me, so it's a bit dangerous to give really hard-and-fast definitive 
    25 answers.  </para> 
    26  
    27 <para> The answers differ somewhat between the various combinations of 
    28 &postgres; and &slony1; versions; the newer versions generally 
    29 somewhat easier to cope with than are the older versions.  In general, 
    30 you almost certainly need to compile &slony1; from sources; depending 
    31 on versioning of both &slony1; and &postgres;, you 
    32 <emphasis>may</emphasis> need to compile &postgres; from scratch. 
    33 (Whether you need to <emphasis> use </emphasis> the &postgres; compile 
    34 is another matter; you probably don't...) </para> 
     23<answer><para> <productname>Frotznik Freenix</productname> c'est nouveau pour moi, 
     24alors il est un peu dangereux, pour donner des réponses définitives vraiment concise et rapides.  </para> 
     25 
     26<para> Les réponses différent légèrement t entre les diverses combinaisons de versions entre 
     27&postgres; et &slony1; Il est légérement plus faciles, dans les versions récentes, de faire face à ce genre de question  
     28que dans les versions plus anciennes. En général, vous devez presque certainement recompiler &slony1; depuis les sources; selon les versions 
     29des deux composants &slony1; et &postgres;, vous 
     30<emphasis>devez</emphasis> également recompiler &postgres; à partir de zéro. 
     31(Si vous devez d' <emphasis> utilisez </emphasis> le &postgres; compiler 
     32est un autre problème; vous n'avez probablement pas besoin...) </para> 
    3533 
    3634<itemizedlist> 
    3735 
    38 <listitem><para> &slony1; version 1.0.5 and earlier require having a 
    39 fully configured copy of &postgres; sources available when you compile 
     36<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite avoir complètement 
     37configuré &postgres; ayant les sources installées, afin de recompiler 
    4038&slony1;.</para> 
    4139 
    42 <para> <emphasis>Hopefully</emphasis> you can make the configuration 
    43 this closely match against the configuration in use by the packaged 
    44 version of &postgres; by checking the configuration using the command 
     40<para> <emphasis>Si tout va bien </emphasis> vous pouvez refaire la configuration,   
     41ceci contre la configuration utilisée nativement par la paquetage d'origine, en utilisant la  
     42version de &postgres; en utilisant la commande 
    4543<command> pg_config --configure</command>. </para> </listitem> 
    4644 
    47 <listitem> <para> &slony1; version 1.1 simplifies this considerably; 
    48 it does not require the full copy of &postgres; sources, but can, 
    49 instead, refer to the various locations where &postgres; libraries, 
    50 binaries, configuration, and <command> #include </command> files are 
    51 located.  </para> </listitem> 
    52  
    53 <listitem><para> &postgres; 8.0 and higher is generally easier to deal 
    54 with in that a <quote>default</quote> installation includes all of the 
    55 <command> #include </command> files.  </para> 
    56  
    57 <para> If you are using an earlier version of &postgres;, you may find 
    58 it necessary to resort to a source installation if the packaged 
    59 version did not install the <quote>server 
    60 <command>#include</command></quote> files, which are installed by the 
    61 command <command> make install-all-headers </command>.</para> 
     45<listitem> <para> &slony1; La version 1.1 simplifie considérablement les choses; 
     46dans la mesure où vous êtes dispensé d'avoir la version totale de &postgres; en sources, mais qui, 
     47au lieu de cela, se réfère à l'endroit où &postgres; ses librairies, 
     48les binaires, la configuration, ainsi que <command> les fichiers #include </command> sont déjà installés. 
     49</para> </listitem> 
     50 
     51<listitem><para> &postgres; 8.0 et supérieur est généralement plus facile voire idéal 
     52car comprenant déjà une <quote>installation par défaut</quote> incluant la totalité des fichiers d'inclusion 
     53<command> #include </command>.  </para> 
     54 
     55<para> Si vous utilisez les versions antérieur de&postgres;, vous êtes sensé avoir trouvé 
     56toutes les sources et de les installer, si le paquetage d'installation ne l'a pas fait pour vous <quote> sur le serveur, 
     57les fichiers d'inclusions<command>#include</command></quote>, peuvent être réinstaller via la commande 
     58<command> make install-all-headers </command>.</para> 
    6259</listitem> 
    6360 
    6461</itemizedlist> 
    6562 
    66 <para> In effect, the <quote>worst case</quote> scenario takes place 
    67 if you are using a version of &slony1; earlier than 1.1 with an 
    68 <quote>elderly</quote> version of &postgres;, in which case you can 
    69 expect to need to compile &postgres; from scratch in order to have 
    70 everything that the &slony1; compile needs even though you are using a 
    71 <quote>packaged</quote> version of &postgres;.</para> 
    72  
    73 <para> If you are running a recent &postgres; and a recent &slony1;, 
    74 then the codependencies can be fairly small, and you may not need 
    75 extra &postgres; sources.  These improvements should ease the 
    76 production of &slony1; packages so that you might soon even be able to 
    77 hope to avoid compiling &slony1;.</para> 
     63<para> En effet, le <quote>cas dérangeant </quote> est un scénario où  
     64vous utilisez une version de &slony1; antérieur à 1.1 avec une 
     65<quote>vieille</quote> version de &postgres;, dans ce cas vous pouvez comptez devoir compiler &postgres; 
     66à partir de zéro afin d'avoir tout les pré requis de &slony1; Recompile sera un passage obligé même si   
     67vous utilisez un version<quote>paquetée</quote> de &postgres;.</para> 
     68 
     69<para> Si vous employez une version récente de &postgres; et une version récente de &slony1;, 
     70alors les dependences peuvent être assez petits, et vous ne pouvez pas avoir besoin  
     71complémentaire des sources &postgres;.  Ces dispositions devraient soulager la mise en production de 
     72paquetage de &slony1;  de sorte que vous pourriez même pouvoir espérer éviter la compilations 
     73de &slony1;.</para> 
    7874 
    7975</answer> 
    …… 
    8480 
    8581<qandaentry id="missingheaders"> 
    86 <question><para> I tried building &slony1; 1.1 and got the following 
    87 error message: 
     82<question><para> J'essaie d'installer &slony1; 1.1 et j'obtiens le message d'erreur suivant: 
    8883<screen> 
    8984configure: error: Headers for libpqserver are not found in the includeserverdir. 
    …… 
    9388</para></question> 
    9489 
    95 <answer><para> You are almost certainly running version &postgres; 7.4 
    96 or earlier, where server headers are not installed by default if you 
    97 just do a <command>make install</command> of &postgres;.</para> 
    98  
    99 <para> You need to install server headers when you install &postgres; 
    100 via the command <command>make install-all-headers</command>. 
     90<answer><para> Vous exécutez certainement une version &postgres; 7.4 
     91ou ultérieur, où les en-têtes de serveur ne sont pas installé par défaut,  
     92il vous suffi dans ce cas de lancer juste  
     93une commande <command>make install</command> de &postgres;.</para> 
     94 
     95<para> Vous avez besoin d'installer les en-têtes de serveur lors d'installation de &postgres; 
     96via la commande <command>make install-all-headers</command>. 
    10197 
    10298</para> </answer> </qandaentry> 
    …… 
    104100<qandaentry id="threadsafety"> 
    105101 
    106 <question><para> &slony1; seemed to compile fine; now, when I run a 
    107 &lslon;, some events are moving around, but no 
    108 replication is taking place.</para> 
     102<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exécute un 
     103&lslon;, certain évènement démarrent autour, mais la réplication ne se met pas  
     104route.</para> 
    109105 
    110106<para> Slony logs might look like the following: 
    …… 
    123119</para> 
    124120 
    125 <para> Alternatively, it may appear like... 
     121<para> Parfois il peut se manifester de manières suivante ... 
    126122 
    127123<screen> 
    …… 
    136132</question> 
    137133 
    138 <answer><para>On AIX and Solaris (and possibly elsewhere), both 
    139 &slony1; <emphasis>and &postgres;</emphasis> must be compiled with the 
    140 <option>--enable-thread-safety</option> option.  The above results 
    141 when &postgres; isn't so compiled.</para> 
    142  
    143 <para>What breaks here is that the libc (threadsafe) and libpq 
    144 (non-threadsafe) use different memory locations for errno, thereby 
    145 leading to the request failing.</para> 
    146  
    147 <para>Problems like this crop up with disadmirable regularity on AIX 
    148 and Solaris; it may take something of an <quote>object code audit</quote> to 
     134<answer><para>Sur AIX et Solaris (et probablement sur d'autre OS), les deux 
     135&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l' 
     136<option>--enable-thread-safety</option> option.  Le message ci-dessus arrive lorsque la compilation 
     137de &postgres; n'a pas fait appel à cette option.</para> 
     138 
     139<para>Le disfonctionnement ici vient du fait que le libc (threadsafe) et libpq 
     140(non-threadsafe) utilisent des emplacement de mémoire différente pour le code erreur, ainsi en  
     141laissant la requête échouer.</para> 
     142 
     143<para>Des problèmes de ce genre sur AIX et sur Solaris, surviennent avec des régularités surprenantes. 
     144; l'erreur devrais prendre quelque choses ressemblant à un code <quote>objet ou à un code d'audit</quote> qui sont compilé 
    149145make sure that <emphasis>ALL</emphasis> of the necessary components have been 
    150 compiled and linked with <option>--enable-thread-safety</option>.</para> 
    151  
    152 <para>For instance, I ran into the problem one that 
    153 <envar>LD_LIBRARY_PATH</envar> had been set, on Solaris, to point to 
    154 libraries from an old &postgres; compile.  That meant that even though 
    155 the database <emphasis>had</emphasis> been compiled with 
    156 <option>--enable-thread-safety</option>, and 
    157 <application>slon</application> had been compiled against that, 
    158 <application>slon</application> was being dynamically linked to the 
    159 <quote>bad old thread-unsafe version,</quote> so slon didn't work.  It 
    160 wasn't clear that this was the case until I ran <command>ldd</command> 
    161 against <application>slon</application>.</para> </answer> 
    162  
    163 <answer><para> Note that with libpq version 7.4.2, on Solaris, a 
    164 further <link linkend="threadpatch"> thread patch </link> was 
    165 required; similar is also required for &postgres; version 8.0. 
     146et linké avec l'option <option>--enable-thread-safety</option>.</para> 
     147 
     148<para>Pour le moment, je me concentre sur le problème de 
     149<envar>LD_LIBRARY_PATH</envar> si c'est défini, sur Solaris, pour pointer sur les 
     150librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que même si 
     151la base <emphasis>a été</emphasis> compilée avec l' 
     152<option>--enable-thread-safety</option>, et que 
     153<application>slon</application> a été recompilé à nouveau, avec l'édition de lien dynamique de 
     154<application>slon</application> pointant sur un  
     155<quote>ancienne mauvaise version de thread-unsafe,</quote> et alors slon n'a pas fonctionné.  Ceci n'était pas clair 
     156que c'était le cas, jusqu'à ce que je rexécute <command>ldd</command> 
     157à nouveau <application>slon</application>.</para> </answer> 
     158 
     159<answer><para> A noter que la version   7.4.2 de libpq, sur Solaris exige, un nouveau patch 
     160de <link linkend="threadpatch">  </link> ; Le requis est également demandé pour &postgres; version 8.0. 
    166161</para> 
    167162</answer> 
    …… 
    170165<qandaentry id="pg81funs"> 
    171166 
    172 <question> <para> I'm trying to upgrade to a newer version of &slony1; 
    173 and am running into a problem with <xref 
    174 linkend="stmtupdatefunctions"/>.  When I run <xref 
    175 linkend="stmtupdatefunctions"/>, my 
    176 <application>postmaster</application> falls over with a Signal 11. 
    177 There aren't any seeming errors in the log files, aside from the 
    178 &postgres; logs indicating that, yes indeed, the postmaster fell 
     167<question> <para> Je suis en train de migrer sur une nouvelle version de &slony1; 
     168et je me débat avec un problème de<xref 
     169linkend="stmtupdatefunctions"/>.  Lors d'exécution de<xref 
     170linkend="stmtupdatefunctions"/>, mon 
     171<application>postmaster</application> plante dessus avec un Signal 11. 
     172Le fichier log ne contient aucune erreur, relatives à 
     173&postgres; les logs indiquent que, yes indeed, the postmaster fell 
    179174over.</para> 
    180175 
    181 <para> I connected a debugger to the core file, and it indicates that 
    182 it was trying to commit a transaction at the time of the 
    183 failure. </para> 
    184  
    185 <para> By the way I'm on &postgres; 8.1.[0-3]. </para> 
     176<para> En scrutant le fichier core avec un débuguer, on constate que 
     177l'incident survient lors de la validation d'une transaction. </para> 
     178 
     179<para> Pour infos je suis sur &postgres; 8.1.[0-3]. </para> 
    186180</question> 
    187181 
    188 <answer> <para> Unfortunately, early releases of &postgres; 8.1 had a 
    189 problem where if you redefined a function (such as, say, 
    190 <function>upgradeSchema(text)</function>), and then, in the same 
    191 transaction, ran that function, the 
    192 <application>postmaster</application> would fall over, and the 
    193 transaction would fail to commit.  </para> 
    194  
    195 <para> The &lslonik; command <xref linkend="stmtupdatefunctions"/> 
    196 functions like that; it, in one transaction, tries to: 
     182<answer> <para> Désagréablement l'ancienne versions de &postgres; 8.1 avait un problème 
     183où lorsque vous  aviez besoin de redéfinir une fonction (comme , say, 
     184<function>upgradeSchema(text)</function>), et que après, dans la même session de transaction 
     185, vous exécutiez la même fonction, le 
     186<application>postmaster</application> tombait en erreur, et que la 
     187transaction ne pouvait se valider.  </para> 
     188 
     189<para> La commande &lslonik; <xref linkend="stmtupdatefunctions"/> 
     190fonctionne de cette manière; dans la même transaction, essayez ceci: 
    197191 
    198192<itemizedlist> 
    199 <listitem><para> Load the new functions (from <filename>slony1_funcs.sql</filename>), notably including <function>upgradeSchema(text)</function>.  </para> </listitem> 
    200 <listitem><para> Run <function>upgradeSchema(text)</function> to do any necessary upgrades to the database schema. </para> </listitem> 
    201 <listitem><para> Notify &lslon; processes of a change of configuration.</para> </listitem> 
     193<listitem><para> Charger les nouvelles fonctions (depuis <filename>slony1_funcs.sql</filename>), notamment comprenant <function>upgradeSchema(text)</function>. 
     194</para> </listitem> 
     195<listitem><para> Lancer <function>upgradeSchema(text)</function> pour effectuer la migration nécessaire des schémas de la base. </para> </listitem> 
     196<listitem><para> Notifier au pro cesses &lslon; le fait de changement de la configuration.</para> </listitem> 
    202197</itemizedlist> 
    203198</para> 
    204199 
    205 <para> Unfortunately, on &postgres; 8.1.0, 8.1.1, 8.1.2, and 8.1.3, 
    206 this conflicts with a bug where using and modifying a plpgsql function 
    207 in the same transaction leads to a crash. </para> 
    208  
    209 <para> Several workarounds are available. </para> 
    210  
    211 </answer> 
    212  
    213 <answer> <para> The preferred answer would be to upgrade &postgres; to 
    214 8.1.4 or some later version.  Changes between minor versions do not 
    215 require rebuilding databases; it should merely require copying a 
    216 suitable 8.1.x build into place, and restarting the 
    217 <application>postmaster</application> with the new version.  </para> 
    218 </answer> 
    219  
    220 <answer><para> If that is unsuitable, it would be possible to perform 
    221 the upgrade via a series of transactions, performing the equivalent of 
    222 what &lslonik; does <quote>by hand</quote>: </para> 
     200<para> Malheureusement, en &postgres; 8.1.0, 8.1.1, 8.1.2, et 8.1.3, 
     201ceci est conflictuel avec un bug où l'utilisation et la modification d'une fonction plpgsql au sein de la même transaction 
     202lié à un plantage. </para> 
     203 
     204<para> Plusieurs contournements sont à envisager. </para> 
     205 
     206</answer> 
     207 
     208<answer> <para> La réponse privilégiée serais de dire migrer &postgres; en  
     209version 8.1.4 ou supérieur. Les changements mineurs du noyau n'entraîne pas de 
     210reconstruction de la base; ceci devrait simplement exiger d'installer un noyau 8.1.x  
     211en redémarrant les <application>postmaster</application> avec cette nouvelle version.  </para> 
     212</answer> 
     213 
     214<answer><para> Si cette solution ne convient pas, il est possible d'effectuer une série de transaction  <quote>à la main</quote>,  
     215l'équivalent de ce que &lslonik; aurait fait pour cette migration. </para> 
    223216 
    224217<itemizedlist> 
    225 <listitem><para> Take <filename>slony1_funcs.sql</filename> and do three replacements within it: </para>  
     218<listitem><para> Prendre <filename>slony1_funcs.sql</filename> et faire trois remplacement dans ce fichier: </para>  
    226219 
    227220<itemizedlist> 
    228 <listitem><para> Replace <quote>@CLUSTERNAME@</quote> with the name of the cluster </para> </listitem> 
    229 <listitem><para> Replace <quote>@MODULEVERSION@</quote> with the &slony1; version string, such as <quote>1.2.10</quote> </para> </listitem> 
    230 <listitem><para> Replace <quote>@NAMESPACE@</quote> with the <quote>double-quoted</quote> name of the cluster namespace, such as "_MyCluster" </para> </listitem> 
     221<listitem><para> Remplacer <quote>@CLUSTERNAME@</quote>avec le nom du cluster</para> </listitem> 
     222<listitem><para> Remplacer <quote>@MODULEVERSION@</quote> avec la version littérale de &slony1; comme <quote>1.2.10</quote> </para> </listitem> 
     223<listitem><para> Remplacer <quote>@NAMESPACE@</quote> avec <quote>double-quoted</quote> nom du cluster, comme "_MyCluster" </para> </listitem> 
    231224</itemizedlist> 
    232225</listitem> 
    233 <listitem><para> Load that <quote>remapped</quote> set of functions into the database.</para> </listitem> 
    234 <listitem><para> Run the stored function via <command>select <function>upgradeSchema('1.2.7')</function>; </command>, assuming that the previous version of &slony1; in use was version 1.2.7. </para> </listitem> 
    235 <listitem><para> Restarting all &lslon; processes would probably be a wise move with this sort of <quote>surgery.</quote> </para> </listitem> 
     226<listitem><para> Recharger cet<quote>remis à niveau</quote> de jeux de fonctions dans la base.</para> </listitem> 
     227<listitem><para> Exécuter la fonction stockée via <command>select <function>upgradeSchema('1.2.7')</function>; </command>,  
     228en supposant que la précédente version de &slony1; en cours était celle de 1.2.7. </para> </listitem> 
     229<listitem><para> Rechargement total des processes &lslon; sera probablement une sage  décision après ce genre de <quote>chirurgie.</quote> </para> </listitem> 
    236230</itemizedlist> 
    237231</answer> 
    …… 
    239233 
    240234<qandaentry> 
    241 <question> <para> Problem building on Fedora/x86-64 </para> 
    242  
    243 <para> When trying to configure &slony1; on a Fedora x86-64 system, 
    244 where <application>yum</application> was used to install the package 
    245 <filename>postgresql-libs.x86_64</filename>, the following complaint 
    246 comes up: 
     235<question> <para> Problème d'installation sur Fedora/x86-64 </para> 
     236 
     237<para> Lorsqu'on essaie de configurer &slony1; sur système Fedora x86-64, 
     238où <application>yum</application> a été utilisé pour une installation du paquetage 
     239<filename>postgresql-libs.x86_64</filename>, le message suivant se manifeste : 
    247240 
    248241<screen> 
    …… 
    252245</screen></para> 
    253246 
    254 <para> This happened with &postgres; 8.2.5, which is certainly rather 
    255 newer than 7.3. </para> 
     247<para> Ceci arrive avec &postgres; 8.2.5, ce qui est certainement un peu plus récent que 
     2487.3. </para> 
    256249</question> 
    257250 
    258 <answer> <para> <application>configure</application> is looking for 
    259 that symbol by compiling a little program that calls for it, and 
    260 checking if the compile succeeds.  On the <command>gcc</command> 
    261 command line it uses <command>-lpq</command> to search for the 
    262 library. </para> 
    263  
    264 <para> Unfortunately, that package is missing a symlink, from 
    265 <filename>/usr/lib64/libpq.so</filename> to 
    266 <filename>libpq.so.5.0</filename>; that is why it fails to link to 
    267 libpq.  The <emphasis>true</emphasis> problem is that the compiler failed to 
    268 find a library to link to, not that libpq lacked the function call. 
    269 </para> 
    270  
    271 <para> Eventually, this should be addressed by those that manage the 
    272 <filename>postgresql-libs.x86_64</filename> package. </para> 
    273 </answer> 
    274  
    275 <answer> <para> Note that this same symptom can be the indication of 
    276 similar classes of system configuration problems.  Bad symlinks, bad 
    277 permissions, bad behaviour on the part of your C compiler, all may 
    278 potentially lead to this same error message. </para>  
    279  
    280 <para> Thus, if you see this error, you need to look in the log file 
    281 that is generated, <filename>config.log</filename>.  Search down to 
    282 near the end, and see what the <emphasis>actual</emphasis> complaint 
    283 was.  That will be helpful in tracking down the true root cause of the 
    284 problem.</para> 
     251<answer> <para> <application>configure</application> est à la recherche de ce directif  
     252en compilant un petit programme requis, pour lequel il est appelé, et  
     253vérifie la compilation se passe bien. Avec la ligne de commande <command>gcc</command> 
     254il utilise <command>-lpq</command> pour chercher la librairie. </para> 
     255 
     256 
     257<para> Malheureusement, ce paquetage fait défaut depuis le lien symbolique, de 
     258<filename>/usr/lib64/libpq.so</filename> à 
     259<filename>libpq.so.5.0</filename>; c'est pourquoi il plante sur libpq.   
     260Le <emphasis>vrai</emphasis> problème c'est que le compilateur n'arrive pas à trouver une 
     261librairie pour l'édition de lien, et non pas que libpq est absent et qui a manqué à l'appel. 
     262</para> 
     263 
     264<para> Eventuellement il faudra remonter ces informations vers ceux qui gèrent le paquetage 
     265<filename>postgresql-libs.x86_64</filename>. </para> 
     266</answer> 
     267 
     268<answer> <para> Notez que ce même symptôme peut être révélateur des problèmes semblables de ce genre  
     269de configuration système. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement 
     270de la part de votre compilateur C, tout peuvent potentiellement mener à ce même message d'erreur. </para>  
     271 
     272<para> Ainsi si vous rencontrez cette erreur, vous aurez besoin de regarder le fichier log généré, 
     273 <filename>config.log</filename>.  Cherchez par la bas, et regarder quel est le souci <emphasis>récemment</emphasis> rencontré. 
     274Ceci sera bénéfique, pour trouver la racine de l'épineux problème.</para> 
    285275</answer> 
    286276 
    …… 
    289279</qandadiv> 
    290280 
    291 <qandadiv id="faqconnections"> <title> &slony1; FAQ: Connection Issues </title> 
    292 <qandaentry> 
    293  
    294 <question><para>I looked for the <envar>_clustername</envar> namespace, and 
    295 it wasn't there.</para></question> 
    296  
    297 <answer><para> If the DSNs are wrong, then &lslon; 
    298 instances can't connect to the nodes.</para> 
    299  
    300 <para>This will generally lead to nodes remaining entirely untouched.</para> 
    301  
    302 <para>Recheck the connection configuration.  By the way, since <xref 
    303 linkend="slon"/> links to libpq, you could have password information 
    304 stored in <filename> $HOME/.pgpass</filename>, partially filling in 
    305 right/wrong authentication information there.</para> 
     281<qandadiv id="faqconnections"> <title> &slony1; FAQ: Problèmes relatifs aux connections</title> 
     282<qandaentry> 
     283 
     284<question><para>Je cherche le nom de<envar>_clustername</envar>, et  
     285il est introuvable.</para></question> 
     286 
     287<answer><para> Si le DNS sont erronés, alors l'instance &lslon; 
     288ne pourra pas se connecter aux noeuds.</para> 
     289 
     290<para>Ceci mène aux fait que les noeuds seront introuvables.</para> 
     291 
     292<para>Revérifier la configuration des connexions. D'ailleurs depuis <xref 
     293linkend="slon"/> le linkage avec libpq, vous devrez avoir le mot de passe généré  
     294 dans <filename> $HOME/.pgpass</filename>, partiellement reporté dans bonne/mauvais authentification ici.</para> 
    306295</answer> 
    307296</qandaentry> 
    308297 
    309298<qandaentry id="morethansuper"> 
    310 <question> <para> I created a <quote>superuser</quote> account, 
    311 <command>slony</command>, to run replication activities.  As 
    312 suggested, I set it up as a superuser, via the following query:  
     299<question> <para> J'ai crée un compte <quote>super utilisateur</quote>, 
     300<command>slony</command>, pour exécuter les activités de réplications. Comme suggéré, 
     301je l'ai configuré comme super user, avec l'interrogation suivante :  
    313302<command> 
    314303update pg_shadow set usesuper = 't' where usename in ('slony', 
    315304'molly', 'dumpy'); 
    316305</command> 
    317 (that command also deals with other users I set up to run vacuums and 
    318 backups).</para> 
    319  
    320 <para> Unfortunately, I ran into a problem the next time I subscribed 
    321 to a new set.</para> 
     306(Cette même commande permet d'autoriser autres utilisateurs d'exécuter vacuums et 
     307sauvegarde).</para> 
     308 
     309<para> Malheureusement, je suis tombé en erreur, à chaque fois où je voulais souscrire à un nouveau ensemble.</para> 
    322310 
    323311<programlisting> 
    …… 
    332320</programlisting> 
    333321 
    334 <para> This continues to fail, over and over, until I restarted the 
    335 <application>slon</application> to connect as 
    336 <command>postgres</command> instead.</para> 
     322<para> Celà a continué de se planter, à plusieurs reprise, juqsqu'à ce que  
     323<application>slon</application> se connecte comme  
     324<command>postgres</command> le faisait.</para> 
    337325</question> 
    338326 
    339 <answer><para> The problem is fairly self-evident; permission is being 
    340 denied on the system table, <envar>pg_class</envar>.</para></answer> 
    341  
    342 <answer><para> The <quote>fix</quote> is thus:</para> 
     327<answer><para> Le problème est assez évident en soi; la permission sur la table de système est ignorée, <envar>pg_class</envar>.</para></answer> 
     328 
     329<answer><para> La <quote>solution</quote> est la suivante:</para> 
    343330<programlisting> 
    344331update pg_shadow set usesuper = 't', usecatupd='t' where usename = 'slony'; 
    …… 
    346333</answer> 
    347334 
    348 <answer><para> In version 8.1 and higher, you may also need the following:</para> 
     335<answer><para> En version 8.1 et supérieur, vous avez aussi besoin de:</para> 
    349336<programlisting> 
    350337update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony'; 
    …… 
    354341 
    355342<qandaentry> 
    356 <question><para> I'm trying to get a slave subscribed, and get the 
    357 following messages in the logs: 
     343<question><para> Au moment d'enregistrer un esclave,dans le log, j'obtiens le message 
     344suivant : 
    358345 
    359346<screen> 
    …… 
    364351</screen></para></question> 
    365352 
    366 <answer> <para> There is evidently some reasonably old outstanding 
    367 transaction blocking &slony1; from processing the sync.  You might 
    368 want to take a look at pg_locks to see what's up:</para> 
     353<answer> <para> Il y a évidemment un certain nombre de vieilles transactions bloquantes, 
     354de &slony1; restant depuis le traitement des synchros. Vous devriez jeter un coup d'oeil 
     355à pg_locks to see what's up:</para> 
    369356 
    370357<screen> 
    …… 
    377364</screen> 
    378365 
    379 <para>See?  127314921 is indeed older than 127314958, and it's still 
    380 running.</para> 
    381  
    382 <para> A long running G/L report, a runaway 
    383 <application>RT3</application> query, a 
    384 <application>pg_dump</application>, all will open up transactions that 
    385 may run for substantial periods of time.  Until they complete, or are 
    386 interrupted, you will continue to see the message <quote> data copy 
     366<para>See?  127314921 est en effet plus vieux que 127314958, et il est toujours en cours d'exécution.</para> 
     367 
     368<para> Un long traitement G/LA,  s'emballe durant une interrogation 
     369<application>RT3</application>, avec 
     370<application>pg_dump</application>, toute les transaction semblent s'exécuter pour une période interminable. 
     371Jusqu'à ce que elles soient complétées ou bien interrompu, on verra alors le message d'erreur suivant: 
     372<quote> data copy 
    387373for set 1 failed - sleep 60 seconds </quote>.</para> 
    388374 
    389 <para>By the way, if there is more than one database on the &postgres; 
    390 cluster, and activity is taking place on the OTHER database, that will 
    391 lead to there being <quote>transactions earlier than XID 
    392 whatever</quote> being found to be still in progress.  The fact that 
    393 it's a separate database on the cluster is irrelevant; &slony1; will 
    394 wait until those old transactions terminate.</para> 
    395 </answer> 
    396 </qandaentry> 
    397  
    398 <qandaentry> 
    399 <question><para>Same as the above.  What I forgot to mention, as well, 
    400 was that I was trying to add <emphasis>TWO</emphasis> subscribers, 
    401 concurrently.</para></question> 
    402  
    403 <answer><para> That doesn't work out: &slony1; can't work on the 
    404 <command>COPY</command> commands concurrently.  See 
    405 <filename>src/slon/remote_worker.c</filename>, function 
     375  
     376<para>D'ailleurs, s'il y a plus d'une base de données sur le cluster du &postgres; 
     377, et que la charge se déporte sur une autre base, ce qui mène à procéder aux<quote>transactions plus tôt que XID 
     378quoi que</quote> s'avérant encore en marche.  Le fait est que la base de donnée dissociée  
     379sur le cluster n'est pas pertinente; &slony1; attendra 
     380jusqu'à ce que ces vieilles transactions se terminent.</para> 
     381</answer> 
     382</qandaentry> 
     383 
     384 
     385<qandaentry> 
     386<question><para>Même chose que ce qui précède.  Ce que j'ai oublié de mentionner, aussi bien,  
     387était que j'essayais d'ajouter  
     388<emphasis>DEUX</emphasis> abonnés, concurremment.</para></question> 
     389 
     390<answer><para> Cela ne peut marcher: &slony1; ne peut employer la commande 
     391<command>COPY</command> de manière concurrente.  voir  
     392<filename>src/slon/remote_worker.c</filename>, la fonction 
    406393<function>copy_set()</function></para> 
    407394 
    …… 
    410397postgres 2605100  205018        0 18:53:43  pts/3  3:13 postgres: postgres sampledb localhost COPY  
    411398</screen> 
    412  
    413 <para>This happens to be a <command>COPY</command> transaction 
    414 involved in setting up the subscription for one of the nodes.  All is 
    415 well; the system is busy setting up the first subscriber; it won't 
    416 start on the second one until the first one has completed subscribing. 
    417 That represents one possible cause.</para> 
    418  
    419 <para>This has the (perhaps unfortunate) implication that you cannot 
    420 populate two slaves concurrently from a single provider.  You have to 
    421 subscribe one to the set, and only once it has completed setting up 
    422 the subscription (copying table contents and such) can the second 
    423 subscriber start setting up the subscription.</para></answer> 
    424 </qandaentry> 
    425  
    426 <qandaentry id="missingoids"> <question> <para> We got bitten by 
    427 something we didn't foresee when completely uninstalling a slony 
    428 replication cluster from the master and slave...</para> 
    429  
    430 <warning> <para><emphasis>MAKE SURE YOU STOP YOUR APPLICATION RUNNING 
    431 AGAINST YOUR MASTER DATABASE WHEN REMOVING THE WHOLE SLONY 
     399  
     400<para>Ceci s'avère justement être une transaction de <command>COPY</command>  
     401impliqué en installant l'abonnement pour un des noeuds. Tout a l'air bien;  
     402le système s'occupe de configurer le premier abonné; il ne veut pas démarrer sur le second  
     403tant que le premier n'a pas fini son enregistrement. 
     404Cela représente une cause possible.</para> 
     405 
     406<para>Ceci a (peut-être malheureusement)comme conséquence que vous ne pouvez pas peupler 
     407deux esclaves concurremment pour un simple fournisseur. Vous devez souscrire un et un seul abonné à la fois, 
     408une fois qu'il a accompli l'abonnement,(copyant le contenu des table et autre) peut s'occuper de débuter l'enregistrement 
     409du deuxième.</para></answer> 
     410</qandaentry> 
     411 
     412<qandaentry id="missingoids"> <question> <para> Nous somme souciés par quelques choses  
     413car ne pouvant envisager de désinstaller entièrement une réplication du cluster slony  
     414entre un maître et un esclave.</para> 
     415 
     416<warning> <para><emphasis>ASSUREZ-VOUS QUE VOUS ARRÊTEZ L'EXECUTION DE VOS APPLICATIONS 
     417SUR VOTRE BASE DE DONNEES MAITRE, LORS DE L'ELIMINATION D'UN MEMBRE DU 
    432418CLUSTER</emphasis>, or at least re-cycle all your open connections 
    433419after the event!  </para></warning> 
    434420 
    435 <para> The connections <quote>remember</quote> or refer to OIDs which 
    436 are removed by the uninstall node script. And you will get lots of 
    437 errors as a result... 
     421<para> Les connexions <quote>se renouvellent</quote> ou se rapportent à OIDs qui sont  
     422tuées lors du lancement du script de désinstallation. Et vous obtiendrez  
     423un bon nombre d'erreurs en conséquence 
     424 
    438425</para> 
    439426 
    440427</question> 
    441428 
    442 <answer><para> There are two notable areas of 
    443 &postgres; that cache query plans and OIDs:</para> 
     429<answer><para> Il y a deux sections notables de  
     430&postgres; qui sont la mise en cache des plans d'interrogation et les OIDs:</para> 
    444431<itemizedlist> 
    445 <listitem><para> Prepared statements</para></listitem> 
    446 <listitem><para> pl/pgSQL functions</para></listitem> 
     432<listitem><para> Préparer la requête</para></listitem> 
     433<listitem><para> Les fonctions pl/pgSQL </para></listitem> 
    447434</itemizedlist> 
    448435 
    449 <para> The problem isn't particularly a &slony1; one; it would occur 
    450 any time such significant changes are made to the database schema.  It 
    451 shouldn't be expected to lead to data loss, but you'll see a wide 
    452 range of OID-related errors. 
     436<para> En particulier le problème n'est pas que sous &slony1; en un;  
     437se produirait quand de telles modifications importantes sont apportées aux fondements de base  
     438de données. Il n'est pas imaginable que cela mène à perdre des données, mais de se voir confronté 
     439à une vague d'erreur relatives à OID. 
    453440</para></answer> 
    454441 
    455 <answer><para> The problem occurs when you are using some sort of 
    456 <quote>connection pool</quote> that keeps recycling old connections. 
    457 If you restart the application after this, the new connections will 
    458 create <emphasis>new</emphasis> query plans, and the errors will go 
    459 away.  If your connection pool drops the connections, and creates new 
    460 ones, the new ones will have <emphasis>new</emphasis> query plans, and 
    461 the errors will go away. </para></answer> 
    462  
    463 <answer> <para> In our code we drop the connection on any error we 
    464 cannot map to an expected condition. This would eventually recycle all 
    465 connections on such unexpected problems after just one error per 
    466 connection.  Of course if the error surfaces as a constraint violation 
    467 which is a recognized condition, this won't help either, and if the 
    468 problem is persistent, the connections will keep recycling which will 
    469 drop the effect of the pooling, in the latter case the pooling code 
    470 could also announce an admin to take a look...  </para> </answer> 
    471  
    472  
    473  
    474 </qandaentry> 
    475  
    476 <qandaentry><question><para> I upgraded my cluster to &slony1; version 
    477 1.2.  I'm now getting the following notice in the logs:</para> 
     442<answer><para> Le problème arrive lorsque vous utilisez une sorte de  
     443<quote>pool de connexion</quote> qui essaie de les reconnecter à la fin. 
     444Si vous remettez l'application en route après ceci, des nouvelles connexions 
     445sont générées avec un <emphasis>nouveau</emphasis>plan d'interrogation, et qui  
     446font disparaître les erreurs. Si votre pool de connexion tue les sessions, et en recrée de nouvelle, 
     447alors ces nouvelles session auront de <emphasis>nouveau</emphasis> plan d'exécution, et 
     448que les erreurs vont disparaître. </para></answer> 
     449 
     450En notre code nous laissons tomber le raccordement sur n'importe quelle  
     451erreur nous ne peut pas tracer à un état prévu. Ceci réutiliserait par la  
     452suite tous les raccordements sur de tels problèmes inattendus après juste une  
     453erreur par raccordement. Naturellement si l'erreur apprête car une violation de  
     454contrainte qui est un état identifié, ce won' ; l'aide de t l'un ou l'autre, et  
     455si le problème est persistant, les raccordements maintiendra réutiliser qui 
     456 laisseront tomber l'effet de la mise en commun, dans le dernier cas que  
     457 le code de mise en commun pourrait également annoncer un Admin. pour jeter  
     458 un coup d'oeil 
     459 
     460  
     461<answer> <para> Dans notre code nous éliminons toutes connexions ayant des erreurs inattendues dans 
     462le contexte. Ceci dit, les convexions devront être rétablis à la fin de chaque telle erreur 
     463inattendues, à raison d'une erreur par connexion. Naturellement si l'erreur remonte une violation de contrainte, 
     464qui est une condition reconnue, ne peut aider la situation,  et si le problème persiste, les connexions sont restaurées, 
     465qui aura pour effet de casser l'effet de pool, dans ce dernier cas, l'administrateur aura à jeter   
     466un coup d'oeil sur le code. </para> </answer> 
     467 
     468</qandaentry> 
     469 
     470<qandaentry><question><para> J'ai migré mon  &slony1; en version 
     4711.2.  J'ai maintenant cet avertissement dans les logs:</para> 
    478472 
    479473<screen>NOTICE:  Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated</screen> 
    480474 
    481 <para> Both <envar>sl_log_1</envar> and <envar>sl_log_2</envar> are 
    482 continuing to grow, and <envar>sl_log_1</envar> is never getting 
    483 truncated.  What's wrong? 
     475<para> Les deux <envar>sl_log_1</envar> et <envar>sl_log_2</envar> continue de prendre du volume,  
     476et <envar>sl_log_1</envar> n'est jamais remis à zéro. 
     477Quel est le souci? 
    484478</para> </question> 
    485479 
    486 <answer><para> This is symptomatic of the same issue as above with 
    487 dropping replication: if there are still old connections lingering 
    488 that are using old query plans that reference the old stored 
    489 functions, resulting in the inserts to <envar>sl_log_1</envar> </para> 
    490  
    491 <para> Closing those connections and opening new ones will resolve the 
    492 issue. </para> </answer>  
    493  
    494 <answer> <para> In the longer term, there is an item on the &postgres; 
    495 TODO list to implement dependancy checking that would flush cached 
    496 query plans when dependent objects change.  </para> </answer> 
    497 </qandaentry> 
    498  
    499 <qandaentry> 
    500 <question><para>I pointed a subscribing node to a different provider 
    501 and it stopped replicating</para></question> 
     480<answer><para> Ceci est un cas symptomatique et similaire au précèdent, 
     481relatif à la suppression de réplication : s'il y a des connexions établies, s'attardant à utiliser des plan d'exécutions 
     482basés sur des vieilles fonctions stockées, donne par conséquence une écriture dans  
     483 <envar>sl_log_1</envar> </para> 
     484 
     485<para> La fermeture des vieilles et l'ouverture des nouvelles connexions, résous ce problème.</para> </answer>  
     486 
     487<answer> <para> En d'autre terme, la présence d'un ordre dans la liste d'attente de &postgres; 
     488pour implémenter des dépendances, aura pour effet de descendre les plans d'exécution, lorsque cette dépendance  
     489joue sur l'objet qui change.  </para> </answer> 
     490</qandaentry> 
     491 
     492<qandaentry> 
     493<question><para>J'ai pointé un noeud de souscription à un fournisseur différent, et il a cessé  
     494la réplication.</para></question> 
    502495 
    503496<answer><para> 
    504 We noticed this happening when we wanted to re-initialize a node, 
    505 where we had configuration thus: 
     497Nous rappelons que ceci arrive lorsque nous souhaitons initialiser un noeud où 
     498nous avons la configuration suivante:  
    506499 
    507500<itemizedlist> 
    508 <listitem><para> Node 1 - provider</para></listitem> 
    509 <listitem><para> Node 2 - subscriber to node 1 - the node we're reinitializing</para></listitem> 
    510 <listitem><para> Node 3 - subscriber to node 3 - node that should keep replicating</para></listitem> 
     501<listitem><para> Node 1 - fournisseur</para></listitem> 
     502<listitem><para> Node 2 - s'enregistrer au noeud 1 - le noeud que nous avons réinitialisé</para></listitem> 
     503<listitem><para> Node 3 - s'enregistrer au noeud 3 - le noeud qui doit répliquer</para></listitem> 
    511504</itemizedlist></para> 
    512505 
    513 <para>The subscription for node 3 was changed to have node 1 as 
    514 provider, and we did <xref linkend="stmtdropset"/> /<xref 
    515 linkend="stmtsubscribeset"/> for node 2 to get it repopulating.</para> 
    516  
    517 <para>Unfortunately, replication suddenly stopped to node 3.</para> 
    518  
    519 <para>The problem was that there was not a suitable set of 
    520 <quote>listener paths</quote> in <xref linkend="table.sl-listen"/> to allow the events from 
    521 node 1 to propagate to node 3.  The events were going through node 2, 
    522 and blocking behind the <xref linkend="stmtsubscribeset"/> event that 
    523 node 2 was working on.</para> 
    524  
    525 <para>The following slonik script dropped out the listen paths where 
    526 node 3 had to go through node 2, and added in direct listens between 
    527 nodes 1 and 3. 
     506<para>L'abonnement pour le noeud 3 a changé dans le sens d'avoir  
     507le noeud 3 comme fournisseur, et on a fait<xref linkend="stmtdropset"/> /<xref 
     508linkend="stmtsubscribeset"/> pour le noeud 2 pour qu'il soit rechargé.</para> 
     509 
     510<para>Malencontreusement, la réplication a été arrêtée soudainement sur le noeud 3.</para> 
     511 
     512<para>Le problème était qu'il n'y avait pas un ensemble approprié de 
     513<quote>ports d'écoute</quote> dans <xref linkend="table.sl-listen"/> pour permettre aux évènements  
     514depuis le noeud 1 de se propager sur le 3. Les événements vont se reporter aux noeuds 2 et bloquent ainsi  
     515derrière l'évènement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para> 
     516 
     517<para>Le port d'écoute a lâché le script suivant de slonik où le noeud 3 aurait dû, en passant par le noeud 2 
     518de l'ajouter directement en ports d'écoute entre  les deux noeuds 1 et 3. 
    528519 
    529520<programlisting> 
    …… 
    541532</programlisting></para> 
    542533 
    543 <para>Immediately after this script was run, <command>SYNC</command> 
    544 events started propagating again to node 3. 
    545  
    546 This points out two principles: 
     534<para>Juste après que ce script a été terminé, les événements de  <command>SYNC</command> ont commencé à  
     535propager encore sur le noeud 3. 
     536 
     537Ceci précise deux principes: 
    547538<itemizedlist> 
    548539 
    549 <listitem><para> If you have multiple nodes, and cascaded subscribers, 
    550 you need to be quite careful in populating the <xref 
    551 linkend="stmtstorelisten"/> entries, and in modifying them if the 
    552 structure of the replication <quote>tree</quote> 
    553 changes.</para></listitem> 
    554  
    555 <listitem><para> Version 1.1 provides better tools to help manage 
    556 this.</para> 
     540Si vous avez des noeuds multiples, et des abonnés en cascade, 
     541vous devez faire attention en repeuplant les entrés <xref 
     542linkend="stmtstorelisten"/>, et en modifiant leur structures de l'<quote>arbre</quote>de changement  
     543de réplication.</para></listitem> 
     544 
     545<listitem><para> La version 1.1 fourni des meilleurs outils pour gérer ce cas.</para> 
    557546</listitem> 
    558547 
    559548</itemizedlist></para> 
    560549 
    561 <para>The issues of <quote>listener paths</quote> are discussed 
    562 further at <xref linkend="listenpaths"/> </para></answer> 
     550<para>Les problèmes relatifs aux <quote>chemins d'écoute</quote> sont discutés 
     551plus bas au <xref linkend="listenpaths"/> </para></answer> 
    563552</qandaentry> 
    564553 
    565554<qandaentry id="multipleslonconnections"> 
    566555 
    567 <question><para> I was starting a &lslon;, and got the 
    568 following <quote>FATAL</quote> messages in its logs.  What's up??? </para> 
     556<question><para> En redémarrant  &lslon;, j'obtiens 
     557le message suivant <quote>FATAL</quote> dans le log. Que se passe-t-il??? </para> 
    569558<screen> 
    5705592006-03-29 16:01:34 UTC CONFIG main: slon version 1.2.0 starting up 
    …… 
    589578</question> 
    590579 
    591 <answer><para> The table <envar>sl_nodelock</envar> is used as an 
    592 <quote>interlock</quote> to prevent two &lslon; processes from trying 
    593 to manage the same node at the same time.  The &lslon; tries inserting 
    594 a record into the table; it can only succeed if it is the only node 
    595 manager. </para></answer> 
    596  
    597 <answer><para> This error message is typically a sign that you have 
    598 started up a second &lslon; process for a given node.  The &lslon; asks 
    599 the obvious question: <quote>Do you already have a slon running 
    600 against this node?</quote> </para></answer> 
    601  
    602 <answer><para> Supposing you experience some sort of network outage, 
    603 the connection between &lslon; and database may fail, and the &lslon; 
    604 may figure this out long before the &postgres; instance it was 
    605 connected to does.  The result is that there will be some number of 
    606 idle connections left on the database server, which won't be closed 
    607 out until TCP/IP timeouts complete, which seems to normally take about 
    608 two hours.  For that two hour period, the &lslon; will try to connect, 
    609 over and over, and will get the above fatal message, over and 
    610 over. </para> 
    611  
    612 <para> An administrator may clean this out by logging onto the server 
    613 and issuing <command>kill -2</command> to any of the offending 
    614 connections.  Unfortunately, since the problem took place within the 
    615 networking layer, neither &postgres; nor &slony1; have a direct way of 
    616 detecting this. </para>  
    617  
    618 <para> You can <emphasis>mostly</emphasis> avoid this by making sure 
    619 that &lslon; processes always run somewhere nearby the server that 
    620 each one manages.  If the &lslon; runs on the same server as the 
    621 database it manages, any <quote>networking failure</quote> that could 
    622 interrupt local connections would be likely to be serious enough to 
    623 threaten the entire server.  </para></answer> 
    624 </qandaentry> 
    625  
    626 <qandaentry> 
    627 <question><para> When can I shut down &lslon; processes?</para></question> 
    628  
    629 <answer><para> Generally, it's no big deal to shut down a &lslon; 
    630 process.  Each one is <quote>merely</quote> a &postgres; client, 
    631 managing one node, which spawns threads to manage receiving events 
    632 from other nodes.  </para> 
    633  
    634 <para>The <quote>event listening</quote> threads are no big deal; they 
    635 are doing nothing fancier than periodically checking remote nodes to 
    636 see if they have work to be done on this node.  If you kill off the 
    637 &lslon; these threads will be closed, which should have little or no 
    638 impact on much of anything.  Events generated while the &lslon; is 
    639 down will be picked up when it is restarted.</para> 
    640  
    641 <para> The <quote>node managing</quote> thread is a bit more 
    642 interesting; most of the time, you can expect, on a subscriber, for 
    643 this thread to be processing <command>SYNC</command> events.  If you 
    644 shut off the &lslon; during an event, the transaction 
    645 will fail, and be rolled back, so that when the &lslon; restarts, it 
    646 will have to go back and reprocess the event.</para> 
    647  
    648 <para> The only situation where this will 
    649 cause <emphasis>particular</emphasis> <quote>heartburn</quote> is if 
    650 the event being processed was one which takes a long time to process, 
    651 such as <command>COPY_SET</command> for a large replication 
    652 set. </para> 
    653  
    654 <para> The other thing that <emphasis>might</emphasis> cause trouble 
    655 is if the &lslon; runs fairly distant from nodes that it connects to; 
    656 you could discover that database connections are left <command>idle in 
    657 transaction</command>.  This would normally only occur if the network 
    658 connection is destroyed without either &lslon; or database being made 
    659 aware of it.  In that case, you may discover 
    660 that <quote>zombied</quote> connections are left around for as long as 
    661 two hours if you don't go in by hand and kill off the &postgres; 
     580<answer><para> La table <envar>sl_nodelock</envar> est utilisée comme un  
     581<quote>enclencheur</quote>pour prévenir que les deux process &lslon; essaient de prendre  
     582la gestion du même noeud en même temps. Le &lslon; essais d'insérer  
     583un enregistrement dans la table; seulement il peut le faire avec succès que  
     584si il est le seul à gérer le noeud. </para></answer> 
     585 
     586<answer><para> Ce message d'erreur est typiquement un signe que vous avez démarrez  
     587un second process  &lslon;  pour un noeud donné.  Le &lslon;pose la question évidente qui est : 
     588 <quote>Avez vous déjà un a slon démarré pour gérer ce noeud?</quote> </para></answer> 
     589 
     590Vous supposant éprouver une certaine sorte de panne de réseau, le raccordement  
     591entre le & ; lslon ; et la base de données peut échouer, et le & ; lslon ; peut  
     592figurer ceci dehors longtemps avant le & ; postgres ; exemple il était relié fait.  
     593Le résultat est qu'il y aura un certain nombre de les raccordements à vide sont partis sur  
     594le serveur de base de données, qui won' ; t soit fermé jusqu'aux temps morts de TCP/IP complets,  
     595qui semble prendre normalement environ deux heures. Pour cette période de deux heures, le & ; lslon ;  
     596essayera de se relier, à plusieurs reprises, et recevra le message mortel ci-dessus, plus d'et au-dessus de. 
     597 
     598<answer><para> Vous supposant éprouver une certaine sorte de panne de réseau, 
     599les connections entre &lslon; et la base de données peuvent échouer, et  &lslon; 
     600peut avertir cela bien avant l'instance de &postgres;  il était connecté pour ce faire. 
     601La conséquence en est qu'un certain nombre de connexion pré-établie vont s'ouvrir su la base de données 
     602et qui ne vont pas se terminer jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui n'arrive que  
     603tous les deux heures. Durant cette période de deux heures, le &lslon; va essayer de se reconnecter, 
     604encore et encore, et obtient le message d'erreur ci-dessous réputé Fatl. </para> 
     605 
     606<para> Un administrateur peut mettre fin à cette situation en se connectant sur 
     607le serveur et en lançant <command>kill -2</command> pour terminer les connexions mourantes. 
     608Malheureusement , puisque le problème a eu lieu dans couche de gestion de réseau,ni &postgres; ni &slony1;  
     609a le moyen direct de détecter ceci. </para>  
     610 
     611<para> Vous pouvez <emphasis>la plupart</emphasis> des cas éviter ceci en s'assurant 
     612que le process &lslon; est hébergé quelque part près des serveurs qu'il gère. Si le &lslon; 
     613est hébergé sur le même serveur que la base de donnée qu'il gère, alors 
     614toute <quote>panne de réseau</quote> qui peut interrompre les connexions 
     615seraient susceptibles d'être assez sérieux pour menacer le serveur entier. </para></answer> 
     616</qandaentry> 
     617 
     618 
     619<qandaentry> 
     620<question><para> Quand est-ce que je peux arrêter les process &lslon;?</para></question> 
     621 
     622<answer><para> Généralement ce n'est pas un grand compromis pour arrêter les processes &lslon; 
     623Chacun d'eux est un <quote>simplement</quote> un client de &postgres;, 
     624gérant chacun un noeud, qui engendre des fils pour gérer et recevoir des évènements 
     625depuis d'autre noeud.  </para> 
     626 
     627<para>L'<quote>évènement d'écoute</quote> des serveurs n'est pas un travail sorcier; ils n'ont  
     628rien à faire que de temps en temps de tester le noeud distant pour déterminer si sur  le noeud en question, 
     629il y a des tâches à faire. Si vous tuer le process &lslon; sa surveillance sera fermée, qui doit avoir peu 
     630ou pas du tout d'impact sur rien peut-être. Les éventements générés pour un &lslon; en arrêt reprendront  
     631lors de son redémarrage.</para> 
     632 
     633<para> La<quote>gestion des noeuds</quote> est un peu plus intéressant; 
     634 la plupart du temps , vous pouvez prévoir, sur un abonné, pour son fil  
     635 d'exécuter l'évènement<command>SYNC</command>. Si vous arrêtez