Changeset 1118

Show
Ignore:
Timestamp:
08/08/08 09:47:39 (4 months ago)
Author:
daamien
Message:

Slony : corrections de qq coquilles

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/slony/ddlchanges.xml

    r1093 r1118  
    205205stockées. Et il est assez probable que cela vous posera problÚme de propager ces mises à jour 
    206206en association avec un jeu de réplication où <command>EXECUTE SCRIPT</command>  
    207 va vérouiller tout un jeu de tables qui n'ont pas réellement besoin de l'être. 
     207va vérouiller tout un jeu de tables qui n'ont pas réellement besoin de l'être.</para> 
    208208 
    209209<para> Si vous propagez une procédure stockée qui n'est pas utilisée tout le temps 
    210210(de telle sorte que vous acceptiez une petite desynchronisation entre les noeuds), alors vous pouvez 
    211211simplement la soumettre à chaque noeud par l'intermédiare d'une commande <application>psql</application>, 
    212 ne faisant pas d'utilisation particuliÚre de &slony1; 
     212ne faisant pas d'utilisation particuliÚre de &slony1;</para> 
    213213 
    214214<para>Si vous <emphasis>avez</emphasis> besoin d'une parfaite synchronisation sur l'ensemble des noeuds, 
    215215a ce moment là, vous devez utiliser <command>EXECUTE SCRIPT</command> 
    216  pour verouiller vos travaux.</para></listitem> 
     216 pour verrouiller vos travaux.</para></listitem> 
    217217 
    218218<listitem><para> Vous pouvez avoir besoin d'index suplémentaires sur quelques 
    …… 
    290290 <emphasis> s'exécute</emphasis>  sans erreur. 
    291291 
    292 Attention <para> Si le script contient un  <command> COMMIT; 
     292<warning>Attention <para> Si le script contient un  <command> COMMIT; 
    293293</command> n'importe ou avant le <command> ROLLBACK; </command>, cela va  
    294294effectuer des changements auxquels vous ne vous attendiez pas.  </para> 
    …… 
    296296</sect2> 
    297297</sect1> 
    298 <!-- Keep this comment at the end of the file 
    299 Local variables: 
    300 mode:sgml 
    301 sgml-omittag:nil 
    302 sgml-shorttag:t 
    303 sgml-minimize-attributes:nil 
    304 sgml-always-quote-attributes:t 
    305 sgml-indent-step:1 
    306 sgml-indent-data:t 
    307 sgml-parent-document:"slony.sgml" 
    308 sgml-exposed-tags:nil 
    309 sgml-local-catalogs:("/usr/lib/sgml/catalog") 
    310 sgml-local-ecat-files:nil 
    311 End: 
    312 --> 
     298 

  • traduc/trunk/slony/faq.xml

    r1083 r1118  
    11<?xml version="1.0" encoding="UTF-8"?> 
    2 <!-- Dernière modifications 
     2<!-- DerniÚre modifications 
    33     le       $Date$ 
    44     par      $Author$ 
    5      révision $Revision$ --> 
     5     révision $Revision$ --> 
    66 
    77<qandaset> 
    8 <indexterm><primary>Questions Fréquemment Posées à  propos de &slony1;</primary></indexterm> 
     8<indexterm><primary>Foire Aux Questions de &slony1;</primary></indexterm> 
    99 
    1010<qandadiv id="faqcompiling"><title> &slony1; FAQ: Monter et Installer &slony1; </title> 
    …… 
    1313 
    1414<question><para> J'utilise <productname> Frotznik Freenix 
    15 4.5</productname>, avec son <acronym>FFPM</acronym> (Frotznik Freenix 
    16 Package 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 
    18 entrain d'utiliser pour ma base de données, mais qui n'inclut pas encore les paquetages &slony1. 
    19 Comment puis-je rajouter &slony1; à cette configuration?  </para> 
     154.5</productname>, avec son systÚme de gestion de paquetages <acronym>FFPM</acronym> (Frotznik Freenix Package Manager).  Il existe des paquets 
     16<acronym>FFPM</acronym> pour &postgres; 7.4.7, que j'utilise actuellement 
     17comme base de données, mais il n'y a pas encore de paquetages &slony1;. 
     18Comment puis-je rajouter &slony1; à cette distribution ?  </para> 
    2019</question> 
    2120 
    2221 
    2322<answer><para> <productname>Frotznik Freenix</productname> c'est nouveau pour moi, 
    24 alors 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  
    28 que dans les versions plus anciennes. En général, vous devez presque certainement recompiler &slony1; depuis les sources; selon les versions 
     23alors il est un peu dangereux, de donner une réponse définitive, concise et rapide.  </para> 
     24 
     25<para> Les réponses différent légÚrement selon les diverses combinaisons de versions entre 
     26&postgres; et &slony1; Il est légérement plus facile, avec les versions récentes, de faire face à ce genre de questions qu'avec les versions plus anciennes. En général, vous devez presque certainement recompiler &slony1; depuis les sources; selon les versions 
    2927des 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 
    32 est un autre problème; vous n'avez probablement pas besoin...) </para> 
     28<emphasis>devez</emphasis> également recompiler &postgres; à partir de zéro. 
     29(Savoir si vous devez <emphasis> utilisez </emphasis> la version compilée de &postgres;  
     30est un autre problÚme; en général ce n'est pas le cas...) </para> 
    3331 
    3432<itemizedlist> 
    3533 
    36 <listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite avoir complètement 
    37 configuré &postgres; ayant les sources installées, afin de recompiler 
     34<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite d'avoir une version  complÚtement configurées des sources de &postgres;, afin de recompiler 
    3835&slony1;.</para> 
    3936 
     37TODO 
     38 
    4039<para> <emphasis>Si tout va bien </emphasis> vous pouvez refaire la configuration,   
    41 ceci contre la configuration utilisée nativement par la paquetage d'origine, en utilisant la  
     40ceci contre la configuration utilisée nativement par la paquetage d'origine, en utilisant la  
    4241version de &postgres; en utilisant la commande 
    4342<command> pg_config --configure</command>. </para> </listitem> 
    4443 
    45 <listitem> <para> &slony1; La version 1.1 simplifie considérablement les choses; 
    46 dans la mesure où vous êtes dispensé d'avoir la version totale de &postgres; en sources, mais qui, 
    47 au lieu de cela, se réfère à l'endroit où &postgres; ses librairies, 
    48 les binaires, la configuration, ainsi que <command> les fichiers #include </command> sont déjà installés. 
     44<listitem> <para> &slony1; La version 1.1 simplifie considérablement les choses; 
     45dans la mesure où vous êtes dispensé d'avoir la version totale de &postgres; en sources, mais qui, 
     46au lieu de cela, se réfÚre à l'endroit où &postgres; ses librairies, 
     47les binaires, la configuration, ainsi que <command> les fichiers #include </command> sont déjà installés. 
    4948</para> </listitem> 
    5049 
    51 <listitem><para> &postgres; 8.0 et supérieur est généralement plus facile voire idéal 
    52 car comprenant déjà une <quote>installation par défaut</quote> incluant la totalité des fichiers d'inclusion 
     50<listitem><para> &postgres; 8.0 et supérieur est généralement plus facile voire idéal 
     51car comprenant déjà une <quote>installation par défaut</quote> incluant la totalité des fichiers d'inclusion 
    5352<command> #include </command>.  </para> 
    5453 
    55 <para> Si vous utilisez les versions antérieur de&postgres;, vous êtes sensé avoir trouvé 
     54<para> Si vous utilisez les versions antérieur de&postgres;, vous êtes sensé avoir trouvé 
    5655toutes les sources et de les installer, si le paquetage d'installation ne l'a pas fait pour vous <quote> sur le serveur, 
    57 les fichiers d'inclusions<command>#include</command></quote>, peuvent être réinstaller via la commande 
     56les fichiers d'inclusions<command>#include</command></quote>, peuvent être réinstaller via la commande 
    5857<command> make install-all-headers </command>.</para> 
    5958</listitem> 
    …… 
    6160</itemizedlist> 
    6261 
    63 <para> En effet, le <quote>cas dérangeant </quote> est un scénario où  
    64 vous utilisez une version de &slony1; antérieur à 1.1 avec une 
     62<para> En effet, le <quote>cas dérangeant </quote> est un scénario où  
     63vous utilisez une version de &slony1; antérieur à 1.1 avec une 
    6564<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   
    67 vous 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;, 
    70 alors les dependences peuvent être assez petits, et vous ne pouvez pas avoir besoin  
    71 complémentaire des sources &postgres;.  Ces dispositions devraient soulager la mise en production de 
    72 paquetage de &slony1;  de sorte que vous pourriez même pouvoir espérer éviter la compilations 
     65à partir de zéro afin d'avoir tout les pré requis de &slony1; Recompile sera un passage obligé même si   
     66vous utilisez un version<quote>paquetée</quote> de &postgres;.</para> 
     67 
     68<para> Si vous employez une version récente de &postgres; et une version récente de &slony1;, 
     69alors les dependences peuvent être assez petits, et vous ne pouvez pas avoir besoin  
     70complémentaire des sources &postgres;.  Ces dispositions devraient soulager la mise en production de 
     71paquetage de &slony1;  de sorte que vous pourriez même pouvoir espérer éviter la compilations 
    7372de &slony1;.</para> 
    7473 
    …… 
    8887</para></question> 
    8988 
    90 <answer><para> Vous exécutez certainement une version &postgres; 7.4 
    91 ou ultérieur, où les en-têtes de serveur ne sont pas installé par défaut,  
     89<answer><para> Vous exécutez certainement une version &postgres; 7.4 
     90ou ultérieur, où les en-têtes de serveur ne sont pas installé par défaut,  
    9291il vous suffi dans ce cas de lancer juste  
    9392une commande <command>make install</command> de &postgres;.</para> 
    9493 
    95 <para> Vous avez besoin d'installer les en-têtes de serveur lors d'installation de &postgres; 
     94<para> Vous avez besoin d'installer les en-têtes de serveur lors d'installation de &postgres; 
    9695via la commande <command>make install-all-headers</command>. 
    9796 
    …… 
    10099<qandaentry id="threadsafety"> 
    101100 
    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  
     101<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exécute un 
     102&lslon;, certain évÚnement démarrent autour, mais la réplication ne se met pas  
    104103route.</para> 
    105104 
    …… 
    119118</para> 
    120119 
    121 <para> Parfois il peut se manifester de manières suivante ... 
     120<para> Parfois il peut se manifester de maniÚres suivante ... 
    122121 
    123122<screen> 
    …… 
    133132 
    134133<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' 
     134&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l' 
    136135<option>--enable-thread-safety</option> option.  Le message ci-dessus arrive lorsque la compilation 
    137 de &postgres; n'a pas fait appel à cette option.</para> 
     136de &postgres; n'a pas fait appel à cette option.</para> 
    138137 
    139138<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  
    141 laissant 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é 
     139(non-threadsafe) utilisent des emplacement de mémoire différente pour le code erreur, ainsi en  
     140laissant la requête échouer.</para> 
     141 
     142<para>Des problÚmes de ce genre sur AIX et sur Solaris, surviennent avec des régularités surprenantes. 
     143; l'erreur devrais prendre quelque choses ressemblant à un code <quote>objet ou à un code d'audit</quote> qui sont compilé 
    145144make sure that <emphasis>ALL</emphasis> of the necessary components have been 
    146 et 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 
    150 librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que même si 
    151 la base <emphasis>a été</emphasis> compilée avec l' 
     145et linké avec l'option <option>--enable-thread-safety</option>.</para> 
     146 
     147<para>Pour le moment, je me concentre sur le problÚme de 
     148<envar>LD_LIBRARY_PATH</envar> si c'est défini, sur Solaris, pour pointer sur les 
     149librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que même si 
     150la base <emphasis>a été</emphasis> compilée avec l' 
    152151<option>--enable-thread-safety</option>, et que 
    153 <application>slon</application> a été recompilé à nouveau, avec l'édition de lien dynamique de 
     152<application>slon</application> a été recompilé à nouveau, avec l'édition de lien dynamique de 
    154153<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 
    156 que c'était le cas, jusqu'à ce que je rexécute <command>ldd</command> 
    157 à nouveau <application>slon</application>.</para> </answer> 
     154<quote>ancienne mauvaise version de thread-unsafe,</quote> et alors slon n'a pas fonctionné.  Ceci n'était pas clair 
     155que c'était le cas, jusqu'à ce que je rexécute <command>ldd</command> 
     156à nouveau <application>slon</application>.</para> </answer> 
    158157 
    159158<answer><para> A noter que la version   7.4.2 de libpq, sur Solaris exige, un nouveau patch 
    160 de <link linkend="threadpatch">  </link> ; Le requis est également demandé pour &postgres; version 8.0. 
     159de <link linkend="threadpatch">  </link> ; Le requis est également demandé pour &postgres; version 8.0. 
    161160</para> 
    162161</answer> 
    …… 
    166165 
    167166<question> <para> Je suis en train de migrer sur une nouvelle version de &slony1; 
    168 et je me débat avec un problème de<xref 
    169 linkend="stmtupdatefunctions"/>.  Lors d'exécution de<xref 
     167et je me débat avec un problÚme de<xref 
     168linkend="stmtupdatefunctions"/>.  Lors d'exécution de<xref 
    170169linkend="stmtupdatefunctions"/>, mon 
    171170<application>postmaster</application> plante dessus avec un Signal 11. 
    172 Le fichier log ne contient aucune erreur, relatives à 
     171Le fichier log ne contient aucune erreur, relatives à 
    173172&postgres; les logs indiquent que, yes indeed, the postmaster fell 
    174173over.</para> 
    175174 
    176 <para> En scrutant le fichier core avec un débuguer, on constate que 
     175<para> En scrutant le fichier core avec un débuguer, on constate que 
    177176l'incident survient lors de la validation d'une transaction. </para> 
    178177 
    …… 
    180179</question> 
    181180 
    182 <answer> <para> Désagréablement l'ancienne versions de &postgres; 8.1 avait un problème 
    183 où 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 
     181<answer> <para> Désagréablement l'ancienne versions de &postgres; 8.1 avait un problÚme 
     182où lorsque vous  aviez besoin de redéfinir une fonction (comme , say, 
     183<function>upgradeSchema(text)</function>), et que aprÚs, dans la même session de transaction 
     184, vous exécutiez la même fonction, le 
    186185<application>postmaster</application> tombait en erreur, et que la 
    187186transaction ne pouvait se valider.  </para> 
    188187 
    189188<para> La commande &lslonik; <xref linkend="stmtupdatefunctions"/> 
    190 fonctionne de cette manière; dans la même transaction, essayez ceci: 
     189fonctionne de cette maniÚre; dans la même transaction, essayez ceci: 
    191190 
    192191<itemizedlist> 
    193192<listitem><para> Charger les nouvelles fonctions (depuis <filename>slony1_funcs.sql</filename>), notamment comprenant <function>upgradeSchema(text)</function>. 
    194193</para> </listitem> 
    195 <listitem><para> Lancer <function>upgradeSchema(text)</function> pour effectuer la migration nécessaire des schémas de la base. </para> </listitem> 
     194<listitem><para> Lancer <function>upgradeSchema(text)</function> pour effectuer la migration nécessaire des schémas de la base. </para> </listitem> 
    196195<listitem><para> Notifier au pro cesses &lslon; le fait de changement de la configuration.</para> </listitem> 
    197196</itemizedlist> 
    …… 
    199198 
    200199<para> Malheureusement, en &postgres; 8.1.0, 8.1.1, 8.1.2, et 8.1.3, 
    201 ceci est conflictuel avec un bug où l'utilisation et la modification d'une fonction plpgsql au sein de la même transaction 
    202 lié à 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  
    209 version 8.1.4 ou supérieur. Les changements mineurs du noyau n'entraîne pas de 
     200ceci est conflictuel avec un bug où l'utilisation et la modification d'une fonction plpgsql au sein de la même transaction 
     201lié à un plantage. </para> 
     202 
     203<para> Plusieurs contournements sont à envisager. </para> 
     204 
     205</answer> 
     206 
     207<answer> <para> La réponse privilégiée serais de dire migrer &postgres; en  
     208version 8.1.4 ou supérieur. Les changements mineurs du noyau n'entraîne pas de 
    210209reconstruction de la base; ceci devrait simplement exiger d'installer un noyau 8.1.x  
    211 en 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>,  
    215 l'équivalent de ce que &lslonik; aurait fait pour cette migration. </para> 
     210en redémarrant les <application>postmaster</application> avec cette nouvelle version.  </para> 
     211</answer> 
     212 
     213<answer><para> Si cette solution ne convient pas, il est possible d'effectuer une série de transaction  <quote>à la main</quote>,  
     214l'équivalent de ce que &lslonik; aurait fait pour cette migration. </para> 
    216215 
    217216<itemizedlist> 
    …… 
    220219<itemizedlist> 
    221220<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> 
     221<listitem><para> Remplacer <quote>@MODULEVERSION@</quote> avec la version littérale de &slony1; comme <quote>1.2.10</quote> </para> </listitem> 
    223222<listitem><para> Remplacer <quote>@NAMESPACE@</quote> avec <quote>double-quoted</quote> nom du cluster, comme "_MyCluster" </para> </listitem> 
    224223</itemizedlist> 
    225224</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>,  
    228 en 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> 
     225<listitem><para> Recharger cet<quote>remis à niveau</quote> de jeux de fonctions dans la base.</para> </listitem> 
     226<listitem><para> Exécuter la fonction stockée via <command>select <function>upgradeSchema('1.2.7')</function>; </command>,  
     227en supposant que la précédente version de &slony1; en cours était celle de 1.2.7. </para> </listitem> 
     228<listitem><para> Rechargement total des processes &lslon; sera probablement une sage  décision aprÚs ce genre de <quote>chirurgie.</quote> </para> </listitem> 
    230229</itemizedlist> 
    231230</answer> 
    …… 
    233232 
    234233<qandaentry> 
    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, 
    238 où <application>yum</application> a été utilisé pour une installation du paquetage 
     234<question> <para> ProblÚme d'installation sur Fedora/x86-64 </para> 
     235 
     236<para> Lorsqu'on essaie de configurer &slony1; sur systÚme Fedora x86-64, 
     237où <application>yum</application> a été utilisé pour une installation du paquetage 
    239238<filename>postgresql-libs.x86_64</filename>, le message suivant se manifeste : 
    240239 
    …… 
    245244</screen></para> 
    246245 
    247 <para> Ceci arrive avec &postgres; 8.2.5, ce qui est certainement un peu plus récent que 
     246<para> Ceci arrive avec &postgres; 8.2.5, ce qui est certainement un peu plus récent que 
    2482477.3. </para> 
    249248</question> 
    250249 
    251 <answer> <para> <application>configure</application> est à la recherche de ce directif  
    252 en compilant un petit programme requis, pour lequel il est appelé, et  
    253 vérifie la compilation se passe bien. Avec la ligne de commande <command>gcc</command> 
     250<answer> <para> <application>configure</application> est à la recherche de ce directif  
     251en compilant un petit programme requis, pour lequel il est appelé, et  
     252vérifie la compilation se passe bien. Avec la ligne de commande <command>gcc</command> 
    254253il utilise <command>-lpq</command> pour chercher la librairie. </para> 
    255254 
    256255 
    257 <para> Malheureusement, ce paquetage fait défaut depuis le lien symbolique, de 
    258 <filename>/usr/lib64/libpq.so</filename> à 
     256<para> Malheureusement, ce paquetage fait défaut depuis le lien symbolique, de 
     257<filename>/usr/lib64/libpq.so</filename> à 
    259258<filename>libpq.so.5.0</filename>; c'est pourquoi il plante sur libpq.   
    260 Le <emphasis>vrai</emphasis> problème c'est que le compilateur n'arrive pas à trouver une 
    261 librairie 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 
     259Le <emphasis>vrai</emphasis> problÚme c'est que le compilateur n'arrive pas à trouver une 
     260librairie pour l'édition de lien, et non pas que libpq est absent et qui a manqué à l'appel. 
     261</para> 
     262 
     263<para> Eventuellement il faudra remonter ces informations vers ceux qui gÚrent le paquetage 
    265264<filename>postgresql-libs.x86_64</filename>. </para> 
    266265</answer> 
    267266 
    268 <answer> <para> Notez que ce même symptôme peut être révélateur des problèmes semblables de ce genre  
    269 de configuration système. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement 
    270 de 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é. 
    274 Ceci sera bénéfique, pour trouver la racine de l'épineux problème.</para> 
     267<answer> <para> Notez que ce même symptÃŽme peut être révélateur des problÚmes semblables de ce genre  
     268de configuration systÚme. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement 
     269de la part de votre compilateur C, tout peuvent potentiellement mener à ce même message d'erreur. </para>  
     270 
     271<para> Ainsi si vous rencontrez cette erreur, vous aurez besoin de regarder le fichier log généré, 
     272 <filename>config.log</filename>.  Cherchez par la bas, et regarder quel est le souci <emphasis>récemment</emphasis> rencontré. 
     273Ceci sera bénéfique, pour trouver la racine de l'épineux problÚme.</para> 
    275274</answer> 
    276275 
    …… 
    279278</qandadiv> 
    280279 
    281 <qandadiv id="faqconnections"> <title> &slony1; FAQ: Problèmes relatifs aux connections</title> 
     280<qandadiv id="faqconnections"> <title> &slony1; FAQ: ProblÚmes relatifs aux connections</title> 
    282281<qandaentry> 
    283282 
    …… 
    285284il est introuvable.</para></question> 
    286285 
    287 <answer><para> Si le DNS sont erronés, alors l'instance &lslon; 
     286<answer><para> Si le DNS sont erronés, alors l'instance &lslon; 
    288287ne pourra pas se connecter aux noeuds.</para> 
    289288 
    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 
    293 linkend="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> 
     289<para>Ceci mÚne aux fait que les noeuds seront introuvables.</para> 
     290 
     291<para>Revérifier la configuration des connexions. D'ailleurs depuis <xref 
     292linkend="slon"/> le linkage avec libpq, vous devrez avoir le mot de passe généré  
     293 dans <filename> $HOME/.pgpass</filename>, partiellement reporté dans bonne/mauvais authentification ici.</para> 
    295294</answer> 
    296295</qandaentry> 
    297296 
    298297<qandaentry id="morethansuper"> 
    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é, 
    301 je l'ai configuré comme super user, avec l'interrogation suivante :  
     298<question> <para> J'ai crée un compte <quote>super utilisateur</quote>, 
     299<command>slony</command>, pour exécuter les activités de réplications. Comme suggéré, 
     300je l'ai configuré comme super user, avec l'interrogation suivante :  
    302301<command> 
    303302update pg_shadow set usesuper = 't' where usename in ('slony', 
    304303'molly', 'dumpy'); 
    305304</command> 
    306 (Cette même commande permet d'autoriser autres utilisateurs d'exécuter vacuums et 
     305(Cette même commande permet d'autoriser autres utilisateurs d'exécuter vacuums et 
    307306sauvegarde).</para> 
    308307 
    309 <para> Malheureusement, je suis tombé en erreur, à chaque fois où je voulais souscrire à un nouveau ensemble.</para> 
     308<para> Malheureusement, je suis tombé en erreur, à chaque fois où je voulais souscrire à un nouveau ensemble.</para> 
    310309 
    311310<programlisting> 
    …… 
    320319</programlisting> 
    321320 
    322 <para> Celà a continué de se planter, à plusieurs reprise, juqsqu'à ce que  
     321<para> Celà a continué de se planter, à plusieurs reprise, juqsqu'à ce que  
    323322<application>slon</application> se connecte comme  
    324323<command>postgres</command> le faisait.</para> 
    325324</question> 
    326325 
    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> 
     326<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> 
    328327 
    329328<answer><para> La <quote>solution</quote> est la suivante:</para> 
    …… 
    333332</answer> 
    334333 
    335 <answer><para> En version 8.1 et supérieur, vous avez aussi besoin de:</para> 
     334<answer><para> En version 8.1 et supérieur, vous avez aussi besoin de:</para> 
    336335<programlisting> 
    337336update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony'; 
    …… 
    351350</screen></para></question> 
    352351 
    353 <answer> <para> Il y a évidemment un certain nombre de vieilles transactions bloquantes, 
     352<answer> <para> Il y a évidemment un certain nombre de vieilles transactions bloquantes, 
    354353de &slony1; restant depuis le traitement des synchros. Vous devriez jeter un coup d'oeil 
    355 à pg_locks to see what's up:</para> 
     354à pg_locks to see what's up:</para> 
    356355 
    357356<screen> 
    …… 
    364363</screen> 
    365364 
    366 <para>See?  127314921 est en effet plus vieux que 127314958, et il est toujours en cours d'exécution.</para> 
     365<para>See?  127314921 est en effet plus vieux que 127314958, et il est toujours en cours d'exécution.</para> 
    367366 
    368367<para> Un long traitement G/LA,  s'emballe durant une interrogation 
    369368<application>RT3</application>, avec 
    370 <application>pg_dump</application>, toute les transaction semblent s'exécuter pour une période interminable. 
    371 Jusqu'à ce que elles soient complétées ou bien interrompu, on verra alors le message d'erreur suivant: 
     369<application>pg_dump</application>, toute les transaction semblent s'exécuter pour une période interminable. 
     370Jusqu'à ce que elles soient complétées ou bien interrompu, on verra alors le message d'erreur suivant: 
    372371<quote> data copy 
    373372for set 1 failed - sleep 60 seconds </quote>.</para> 
    374373 
    375374  
    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 
    378 quoi que</quote> s'avérant encore en marche.  Le fait est que la base de donnée dissociée  
     375<para>D'ailleurs, s'il y a plus d'une base de données sur le cluster du &postgres; 
     376, 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 
     377quoi que</quote> s'avérant encore en marche.  Le fait est que la base de donnée dissociée  
    379378sur le cluster n'est pas pertinente; &slony1; attendra 
    380 jusqu'à 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> 
     379jusqu'à ce que ces vieilles transactions se terminent.</para> 
     380</answer> 
     381</qandaentry> 
     382 
     383 
     384<qandaentry> 
     385<question><para>Même chose que ce qui précÚde.  Ce que j'ai oublié de mentionner, aussi bien,  
     386était que j'essayais d'ajouter  
     387<emphasis>DEUX</emphasis> abonnés, concurremment.</para></question> 
    389388 
    390389<answer><para> Cela ne peut marcher: &slony1; ne peut employer la commande 
    391 <command>COPY</command> de manière concurrente.  voir  
     390<command>COPY</command> de maniÚre concurrente.  voir  
    392391<filename>src/slon/remote_worker.c</filename>, la fonction 
    393392<function>copy_set()</function></para> 
    …… 
    398397</screen> 
    399398  
    400 <para>Ceci s'avère justement être une transaction de <command>COPY</command>  
    401 impliqué en installant l'abonnement pour un des noeuds. Tout a l'air bien;  
    402 le système s'occupe de configurer le premier abonné; il ne veut pas démarrer sur le second  
     399<para>Ceci s'avÚre justement être une transaction de <command>COPY</command>  
     400impliqué en installant l'abonnement pour un des noeuds. Tout a l'air bien;  
     401le systÚme s'occupe de configurer le premier abonné; il ne veut pas démarrer sur le second  
    403402tant que le premier n'a pas fini son enregistrement. 
    404 Cela représente une cause possible.</para> 
    405  
    406 <para>Ceci a (peut-être malheureusement)comme conséquence que vous ne pouvez pas peupler 
    407 deux esclaves concurremment pour un simple fournisseur. Vous devez souscrire un et un seul abonné à la fois, 
    408 une fois qu'il a accompli l'abonnement,(copyant le contenu des table et autre) peut s'occuper de débuter l'enregistrement 
    409 du deuxième.</para></answer> 
    410 </qandaentry> 
    411  
    412 <qandaentry id="missingoids"> <question> <para> Nous somme souciés par quelques choses  
    413 car ne pouvant envisager de désinstaller entièrement une réplication du cluster slony  
    414 entre un maître et un esclave.</para> 
    415  
    416 <warning> <para><emphasis>ASSUREZ-VOUS QUE VOUS ARRÊTEZ L'EXECUTION DE VOS APPLICATIONS 
     403Cela représente une cause possible.</para> 
     404 
     405<para>Ceci a (peut-être malheureusement)comme conséquence que vous ne pouvez pas peupler 
     406deux esclaves concurremment pour un simple fournisseur. Vous devez souscrire un et un seul abonné à la fois, 
     407une fois qu'il a accompli l'abonnement,(copyant le contenu des table et autre) peut s'occuper de débuter l'enregistrement 
     408du deuxiÚme.</para></answer> 
     409</qandaentry> 
     410 
     411<qandaentry id="missingoids"> <question> <para> Nous somme souciés par quelques choses  
     412car ne pouvant envisager de désinstaller entiÚrement une réplication du cluster slony  
     413entre un maître et un esclave.</para> 
     414 
     415<warning> <para><emphasis>ASSUREZ-VOUS QUE VOUS ARRÊTEZ L'EXECUTION DE VOS APPLICATIONS 
    417416SUR VOTRE BASE DE DONNEES MAITRE, LORS DE L'ELIMINATION D'UN MEMBRE DU 
    418417CLUSTER</emphasis>, or at least re-cycle all your open connections 
    419418after the event!  </para></warning> 
    420419 
    421 <para> Les connexions <quote>se renouvellent</quote> ou se rapportent à OIDs qui sont  
    422 tuées lors du lancement du script de désinstallation. Et vous obtiendrez  
    423 un bon nombre d'erreurs en conséquence 
     420<para> Les connexions <quote>se renouvellent</quote> ou se rapportent à OIDs qui sont  
     421tuées lors du lancement du script de désinstallation. Et vous obtiendrez  
     422un bon nombre d'erreurs en conséquence 
    424423 
    425424</para> 
    …… 
    430429&postgres; qui sont la mise en cache des plans d'interrogation et les OIDs:</para> 
    431430<itemizedlist> 
    432 <listitem><para> Préparer la requête</para></listitem> 
     431<listitem><para> Préparer la requête</para></listitem> 
    433432<listitem><para> Les fonctions pl/pgSQL </para></listitem> 
    434433</itemizedlist> 
    435434 
    436 <para> En particulier le problème n'est pas que sous &slony1; en un;  
    437 se produirait quand de telles modifications importantes sont apportées aux fondements de base  
    438 de 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. 
     435<para> En particulier le problÚme n'est pas que sous &slony1; en un;  
     436se produirait quand de telles modifications importantes sont apportées aux fondements de base  
     437de données. Il n'est pas imaginable que cela mÚne à perdre des données, mais de se voir confronté 
     438à une vague d'erreur relatives à OID. 
    440439</para></answer> 
    441440 
    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. 
    444 Si vous remettez l'application en route après ceci, des nouvelles connexions 
    445 sont générées avec un <emphasis>nouveau</emphasis>plan d'interrogation, et qui  
    446 font disparaître les erreurs. Si votre pool de connexion tue les sessions, et en recrée de nouvelle, 
    447 alors ces nouvelles session auront de <emphasis>nouveau</emphasis> plan d'exécution, et 
    448 que les erreurs vont disparaître. </para></answer> 
     441<answer><para> Le problÚme arrive lorsque vous utilisez une sorte de  
     442<quote>pool de connexion</quote> qui essaie de les reconnecter à la fin. 
     443Si vous remettez l'application en route aprÚs ceci, des nouvelles connexions 
     444sont générées avec un <emphasis>nouveau</emphasis>plan d'interrogation, et qui  
     445font disparaître les erreurs. Si votre pool de connexion tue les sessions, et en recrée de nouvelle, 
     446alors ces nouvelles session auront de <emphasis>nouveau</emphasis> plan d'exécution, et 
     447que les erreurs vont disparaître. </para></answer> 
    449448 
    450449En notre code nous laissons tomber le raccordement sur n'importe quelle  
    451 erreur nous ne peut pas tracer à un état prévu. Ceci réutiliserait par la  
    452 suite tous les raccordements sur de tels problèmes inattendus après juste une  
    453 erreur par raccordement. Naturellement si l'erreur apprête car une violation de  
    454 contrainte qui est un état identifié, ce won' ; l'aide de t l'un ou l'autre, et  
    455 si le problème est persistant, les raccordements maintiendra réutiliser qui 
     450erreur nous ne peut pas tracer à un état prévu. Ceci réutiliserait par la  
     451suite tous les raccordements sur de tels problÚmes inattendus aprÚs juste une  
     452erreur par raccordement. Naturellement si l'erreur apprête car une violation de  
     453contrainte qui est un état identifié, ce won' ; l'aide de t l'un ou l'autre, et  
     454si le problÚme est persistant, les raccordements maintiendra réutiliser qui 
    456455 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 
     456 le code de mise en commun pourrait également annoncer un Admin. pour jeter  
     457 un coup d'oeil 
    459458 
    460459  
    461 <answer> <para> Dans notre code nous éliminons toutes connexions ayant des erreurs inattendues dans 
    462 le contexte. Ceci dit, les convexions devront être rétablis à la fin de chaque telle erreur 
    463 inattendues, à raison d'une erreur par connexion. Naturellement si l'erreur remonte une violation de contrainte, 
    464 qui est une condition reconnue, ne peut aider la situation,  et si le problème persiste, les connexions sont restaurées, 
    465 qui aura pour effet de casser l'effet de pool, dans ce dernier cas, l'administrateur aura à jeter   
     460<answer> <para> Dans notre code nous éliminons toutes connexions ayant des erreurs inattendues dans 
     461le contexte. Ceci dit, les convexions devront être rétablis à la fin de chaque telle erreur 
     462inattendues, à raison d'une erreur par connexion. Naturellement si l'erreur remonte une violation de contrainte, 
     463qui est une condition reconnue, ne peut aider la situation,  et si le problÚme persiste, les connexions sont restaurées, 
     464qui aura pour effet de casser l'effet de pool, dans ce dernier cas, l'administrateur aura à jeter   
    466465un coup d'oeil sur le code. </para> </answer> 
    467466 
    468467</qandaentry> 
    469468 
    470 <qandaentry><question><para> J'ai migré mon  &slony1; en version 
     469<qandaentry><question><para> J'ai migré mon  &slony1; en version 
    4714701.2.  J'ai maintenant cet avertissement dans les logs:</para> 
    472471 
    …… 
    474473 
    475474<para> Les deux <envar>sl_log_1</envar> et <envar>sl_log_2</envar> continue de prendre du volume,  
    476 et <envar>sl_log_1</envar> n'est jamais remis à zéro. 
     475et <envar>sl_log_1</envar> n'est jamais remis à zéro. 
    477476Quel est le souci? 
    478477</para> </question> 
    479478 
    480 <answer><para> Ceci est un cas symptomatique et similaire au précèdent, 
    481 relatif à la suppression de réplication : s'il y a des connexions établies, s'attardant à utiliser des plan d'exécutions 
    482 basés sur des vieilles fonctions stockées, donne par conséquence une écriture dans  
     479<answer><para> Ceci est un cas symptomatique et similaire au précÚdent, 
     480relatif à la suppression de réplication : s'il y a des connexions établies, s'attardant à utiliser des plan d'exécutions 
     481basés sur des vieilles fonctions stockées, donne par conséquence une écriture dans  
    483482 <envar>sl_log_1</envar> </para> 
    484483 
    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; 
    488 pour implémenter des dépendances, aura pour effet de descendre les plans d'exécution, lorsque cette dépendance  
     484<para> La fermeture des vieilles et l'ouverture des nouvelles connexions, résous ce problÚme.</para> </answer>  
     485 
     486<answer> <para> En d'autre terme, la présence d'un ordre dans la liste d'attente de &postgres; 
     487pour implémenter des dépendances, aura pour effet de descendre les plans d'exécution, lorsque cette dépendance  
    489488joue sur l'objet qui change.  </para> </answer> 
    490489</qandaentry> 
    491490 
    492491<qandaentry> 
    493 <question><para>J'ai pointé un noeud de souscription à un fournisseur différent, et il a cessé  
    494 la réplication.</para></question> 
     492<question><para>J'ai pointé un noeud de souscription à un fournisseur différent, et il a cessé  
     493la réplication.</para></question> 
    495494 
    496495<answer><para> 
    497 Nous rappelons que ceci arrive lorsque nous souhaitons initialiser un noeud où 
     496Nous rappelons que ceci arrive lorsque nous souhaitons initialiser un noeud où 
    498497nous avons la configuration suivante:  
    499498 
    500499<itemizedlist> 
    501500<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> 
     501<listitem><para> Node 2 - s'enregistrer au noeud 1 - le noeud que nous avons réinitialisé</para></listitem> 
     502<listitem><para> Node 3 - s'enregistrer au noeud 3 - le noeud qui doit répliquer</para></listitem> 
    504503</itemizedlist></para> 
    505504 
    506 <para>L'abonnement pour le noeud 3 a changé dans le sens d'avoir  
     505<para>L'abonnement pour le noeud 3 a changé dans le sens d'avoir  
    507506le noeud 3 comme fournisseur, et on a fait<xref linkend="stmtdropset"/> /<xref 
    508 linkend="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  
    514 depuis le noeud 1 de se propager sur le 3. Les événements vont se reporter aux noeuds 2 et bloquent ainsi  
    515 derriè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 
    518 de l'ajouter directement en ports d'écoute entre  les deux noeuds 1 et 3. 
     507linkend="stmtsubscribeset"/> pour le noeud 2 pour qu'il soit rechargé.</para> 
     508 
     509<para>Malencontreusement, la réplication a été arrêtée soudainement sur le noeud 3.</para> 
     510 
     511<para>Le problÚme était qu'il n'y avait pas un ensemble approprié de 
     512<quote>ports d'écoute</quote> dans <xref linkend="table.sl-listen"/> pour permettre aux évÚnements  
     513depuis le noeud 1 de se propager sur le 3. Les événements vont se reporter aux noeuds 2 et bloquent ainsi  
     514derriÚre l'évÚnement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para> 
     515 
     516<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 
     517de l'ajouter directement en ports d'écoute entre  les deux noeuds 1 et 3. 
    519518 
    520519<programlisting> 
    …… 
    532531</programlisting></para> 
    533532 
    534 <para>Juste après que ce script a été terminé, les événements de  <command>SYNC</command> ont commencé à  
     533<para>Juste aprÚs que ce script a été terminé, les événements de  <command>SYNC</command> ont commencé à  
    535534propager encore sur le noeud 3. 
    536535 
    537 Ceci précise deux principes: 
     536Ceci précise deux principes: 
    538537<itemizedlist> 
    539  
    540 Si vous avez des noeuds multiples, et des abonnés en cascade, 
    541 vous devez faire attention en repeuplant les entrés <xref 
     538<listitem><para> 
     539Si vous avez des noeuds multiples, et des abonnés en cascade, 
     540vous devez faire attention en repeuplant les entrés <xref 
    542541linkend="stmtstorelisten"/>, et en modifiant leur structures de l'<quote>arbre</quote>de changement  
    543 de réplication.</para></listitem> 
    544  
    545 <listitem><para> La version 1.1 fourni des meilleurs outils pour gérer ce cas.</para> 
     542de réplication.</para></listitem> 
     543 
     544<listitem><para> La version 1.1 fourni des meilleurs outils pour gérer ce cas.</para> 
    546545</listitem> 
    547546 
    548547</itemizedlist></para> 
    549548 
    550 <para>Les problèmes relatifs aux <quote>chemins d'écoute</quote> sont discutés 
     549<para>Les problÚmes relatifs aux <quote>chemins d'écoute</quote> sont discutés 
    551550plus bas au <xref linkend="listenpaths"/> </para></answer> 
    552551</qandaentry> 
    …… 
    554553<qandaentry id="multipleslonconnections"> 
    555554 
    556 <question><para> En redémarrant  &lslon;, j'obtiens 
     555<question><para> En redémarrant  &lslon;, j'obtiens 
    557556le message suivant <quote>FATAL</quote> dans le log. Que se passe-t-il??? </para> 
    558557<screen> 
    …… 
    578577</question> 
    579578 
    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  
    582 la gestion du même noeud en même temps. Le &lslon; essais d'insérer  
    583 un enregistrement dans la table; seulement il peut le faire avec succès que  
    584 si 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  
    587 un 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  
    590 Vous supposant éprouver une certaine sorte de panne de réseau, le raccordement  
    591 entre le & ; lslon ; et la base de données peut échouer, et le & ; lslon ; peut  
    592 figurer ceci dehors longtemps avant le & ; postgres ; exemple il était relié fait.  
    593 Le résultat est qu'il y aura un certain nombre de les raccordements à vide sont partis sur  
    594 le serveur de base de données, qui won' ; t soit fermé jusqu'aux temps morts de TCP/IP complets,  
    595 qui semble prendre normalement environ deux heures. Pour cette période de deux heures, le & ; lslon ;  
    596 essayera 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, 
    599 les connections entre &lslon; et la base de données peuvent échouer, et  &lslon; 
    600 peut avertir cela bien avant l'instance de &postgres;  il était connecté pour ce faire. 
    601 La conséquence en est qu'un certain nombre de connexion pré-établie vont s'ouvrir su la base de données 
    602 et qui ne vont pas se terminer jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui n'arrive que  
    603 tous les deux heures. Durant cette période de deux heures, le &lslon; va essayer de se reconnecter, 
    604 encore 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 
    607 le serveur et en lançant <command>kill -2</command> pour terminer les connexions mourantes. 
    608 Malheureusement , puisque le problème a eu lieu dans couche de gestion de réseau,ni &postgres; ni &slony1;  
    609 a le moyen direct de détecter ceci. </para>  
    610  
    611 <para> Vous pouvez <emphasis>la plupart</emphasis> des cas éviter ceci en s'assurant 
    612 que le process &lslon; est hébergé quelque part près des serveurs qu'il gère. Si le &lslon; 
    613 est hébergé sur le même serveur que la base de donnée qu'il gère, alors 
    614 toute <quote>panne de réseau</quote> qui peut interrompre les connexions 
    615 seraient 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; 
     579<answer><para> La table <envar>sl_nodelock</envar> est utilisée comme un  
     580<quote>enclencheur</quote>pour prévenir que les deux process &lslon; essaient de prendre  
     581la gestion du même noeud en même temps. Le &lslon; essais d'insérer  
     582un enregistrement dans la table; seulement il peut le faire avec succÚs que  
     583si il est le seul à gérer le noeud. </para></answer> 
     584 
     585<answer><para> Ce message d'erreur est typiquement un signe que vous avez démarrez  
     586un second process  &lslon;  pour un noeud donné.  Le &lslon;pose la question évidente qui est : 
     587 <quote>Avez vous déjà un a slon démarré pour gérer ce noeud?</quote> </para></answer> 
     588 
     589Vous supposant éprouver une certaine sorte de panne de réseau, le raccordement  
     590entre le &lslon; et la base de données peut échouer, et le &lslon; peut  
     591figurer ceci dehors longtemps avant le &postgres; exemple il était relié fait.  
     592Le résultat est qu'il y aura un certain nombre de les raccordements à vide sont partis sur  
     593le serveur de base de données, qui won' ; t soit fermé jusqu'aux temps morts de TCP/IP complets,  
     594qui semble prendre normalement environ deux heures. Pour cette période de deux heures, le &lslon;  
     595essayera de se relier, à plusieurs reprises, et recevra le message mortel ci-dessus, plus d'et au-dessus de. 
     596 
     597<answer><para> Vous supposant éprouver une certaine sorte de panne de réseau, 
     598les connections entre &lslon; et la base de données peuvent échouer, et  &lslon; 
     599peut avertir cela bien avant l'instance de &postgres;  il était connecté pour ce faire. 
     600La conséquence en est qu'un certain nombre de connexion pré-établie vont s'ouvrir su la base de données 
     601et qui ne vont pas se terminer jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui n'arrive que  
     602tous les deux heures. Durant cette période de deux heures, le &lslon; va essayer de se reconnecter, 
     603encore et encore, et obtient le message d'erreur ci-dessous réputé Fatl. </para> 
     604 
     605<para> Un administrateur peut mettre fin à cette situation en se connectant sur 
     606le serveur et en lançant <command>kill -2</command> pour terminer les connexions mourantes. 
     607Malheureusement , puisque le problÚme a eu lieu dans couche de gestion de réseau,ni &postgres; ni &slony1;  
     608a le moyen direct de détecter ceci. </para>  
     609 
     610<para> Vous pouvez <emphasis>la plupart</emphasis> des cas éviter ceci en s'assurant 
     611que le process &lslon; est hébergé quelque part prÚs des serveurs qu'il gÚre. Si le &lslon; 
     612est hébergé sur le même serveur que la base de donnée qu'il gÚre, alors 
     613toute <quote>panne de réseau</quote> qui peut interrompre les connexions 
     614seraient susceptibles d'être assez sérieux pour menacer le serveur entier. </para></answer> 
     615</qandaentry> 
     616 
     617 
     618<qandaentry> 
     619<question><para> Quand est-ce que je peux arrêter les process &lslon;?</para></question> 
     620 
     621<answer><para> Généralement ce n'est pas un grand compromis pour arrêter les processes &lslon; 
    623622Chacun d'eux est un <quote>simplement</quote> un client de &postgres;, 
    624 gérant chacun un noeud, qui engendre des fils pour gérer et recevoir des évènements 
     623gérant chacun un noeud, qui engendre des fils pour gérer et recevoir des évÚnements 
    625624depuis d'autre noeud.  </para> 
    626625 
    627 <para>L'<quote>évènement d'écoute</quote> des serveurs n'est pas un travail sorcier; ils n'ont  
    628 rien à faire que de temps en temps de tester le noeud distant pour déterminer si sur  le noeud en question, 
    629 il y a des tâches à faire. Si vous tuer le process &lslon; sa surveillance sera fermée, qui doit avoir peu 
    630 ou pas du tout d'impact sur rien peut-être. Les éventements générés pour un &lslon; en arrêt reprendront  
    631 lors de son redémarrage.</para> 
    632  
    633 &l