[Trad] [svn:pgfr] r1308 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Dim 26 Avr 13:58:08 CEST 2009
Author: daamien
Date: 2009-04-26 13:58:08 +0200 (Sun, 26 Apr 2009)
New Revision: 1308
Modified:
traduc/trunk/slony/faq.xml
Log:
relecture FAQ (25%)
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2009-04-23 22:00:07 UTC (rev 1307)
+++ traduc/trunk/slony/faq.xml 2009-04-26 11:58:08 UTC (rev 1308)
@@ -36,39 +36,32 @@
<!-- TODO -->
-<para> <emphasis>Si tout va bien </emphasis> vous pouvez refaire la configuration,
-ceci contre la configuration utilisée nativement par la paquetage d'origine, en utilisant la
-version de &postgres; en utilisant la commande
+<para> <emphasis>Heureusement </emphasis> vous pouvez adapter la configuration pour qu'elle corresponde à la configuration utilisée nativement par la paquet d'origine, en vérifiant la
+version de &postgres; avec la commande
<command> pg_config --configure</command>. </para> </listitem>
<listitem> <para> &slony1; La version 1.1 simplifie considérablement les choses;
-dans la mesure où vous êtes dispensé d'avoir la version totale de &postgres; en sources, mais qui,
-au lieu de cela, se réfère à l'endroit où &postgres; ses librairies,
-les binaires, la configuration, ainsi que <command> les fichiers #include </command> sont déjà installés.
+dans la mesure où vous êtes dispensé d'avoir la version complète de de sources de &postgres;, au lieu de cela, elle se réfère aux emplacements des librairies,
+des binaires, de la configuration, et <command> des fichiers #include </command>.
</para> </listitem>
-<listitem><para> &postgres; 8.0 et supérieur est généralement plus facile voire idéal
-car comprenant déjà une <quote>installation par défaut</quote> incluant la totalité des fichiers d'inclusion
-<command> #include </command>. </para>
+<listitem><para> &postgres; 8.0 et supérieur est généralement plus facile car l'<quote>installation par défaut</quote> contient la totalité des fichiers d'inclusion <command> #include </command>. </para>
-<para> Si vous utilisez les versions antérieur de&postgres;, vous êtes sensé avoir trouvé
-toutes les sources et de les installer, si le paquetage d'installation ne l'a pas fait pour vous <quote> sur le serveur,
-les fichiers d'inclusions<command>#include</command></quote>, peuvent être réinstaller via la commande
-<command> make install-all-headers </command>.</para>
+<para> Si vous utilisez une version antérieure de &postgres;, il est préférable d'utiliser une version installée à partir des sources,
+en particulier si la version packagée ne contient <quote> les fichiers d'inclusions<command>#include</command></quote> du serveur. Ces fichiers peuvent être installés par la commande <command> make install-all-headers </command>.</para>
</listitem>
</itemizedlist>
-<para> En effet, le <quote>cas dérangeant </quote> est un scénario où
-vous utilisez une version de &slony1; antérieur à 1.1 avec une
-<quote>vieille</quote> version de &postgres;, dans ce cas vous pouvez comptez devoir compiler &postgres;
-à partir de zéro afin d'avoir tout les pré requis de &slony1; Recompile sera un passage obligé même si
-vous utilisez un version<quote>paquetée</quote> de &postgres;.</para>
+<para> En pratique, la <quote>pire situation</quote> est un scénario où
+vous utilisez une version de &slony1; antérieure à 1.1 avec une
+<quote>vieille</quote> version de &postgres;, dans ce cas vous devez compiler &postgres;
+à partir de zéro afin d'avoir tout les pré-requis de compilation de &slony1; même si
+vous utilisez une version<quote>packagée</quote> de &postgres;.</para>
-<para> Si vous employez une version récente de &postgres; et une version récente de &slony1;,
-alors les dependences peuvent être assez petits, et vous ne pouvez pas avoir besoin
-complémentaire des sources &postgres;. Ces dispositions devraient soulager la mise en production de
-paquetage de &slony1; de sorte que vous pourriez même pouvoir espérer éviter la compilations
+<para> Si vous utilisez une version récente de &postgres; et une version récente de &slony1;,
+alors les dependences peuvent être assez faibles, et vous n'avez pas besoin de fichiers sources complémentaires. Ces améliorations devraient soulager la mise en production des
+paquets de &slony1; de sorte que vous pourriez même pouvoir espérer éviter la compilation
de &slony1;.</para>
</answer>
@@ -87,22 +80,18 @@
</para></question>
<answer><para> Vous exécutez certainement une version &postgres; 7.4
-ou ultérieur, où les en-têtes de serveur ne sont pas installé par défaut,
-il vous suffi dans ce cas de lancer juste
-une commande <command>make install</command> de &postgres;.</para>
+ou antérieure, où les en-têtes de serveur ne sont pas installés par défaut, il vous suffit dans ce cas de lancer la commande <command>make install</command> de &postgres;.</para>
-<para> Vous avez besoin d'installer les en-têtes de serveur lors d'installation de &postgres;
-via la commande <command>make install-all-headers</command>.
+<para> Vous devez installer les en-têtes du serveur lors d'installation de &postgres; via la commande <command>make install-all-headers</command>.
</para> </answer> </qandaentry>
<qandaentry id="threadsafety">
-<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exécute un
-&lslon;, certain évènement démarrent autour, mais la réplication ne se met pas
+<question><para> &slony1; semble se compiler correctement; maintenant, lorsque j'exécute un &lslon;, certain évènements se déclenchent, mais la réplication ne se met pas
route.</para>
-<para> Slony logs might look like the following:
+<para> Les logs de Slony ressemble à ça :
<screen>
DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep user=postgres port=5432'
@@ -117,7 +106,7 @@
</screen>
</para>
-<para> Parfois il peut se manifester de manières suivante ...
+<para> Parfois ils contiennent les lignes suivantes ...
<screen>
ERROR remoteListenThread_2: "select ev_origin, ev_seqno, ev_timestamp,
@@ -130,33 +119,27 @@
</para>
</question>
-<answer><para>Sur AIX et Solaris (et probablement sur d'autre OS), les deux
-&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l'
-<option>--enable-thread-safety</option> option. Le message ci-dessus arrive lorsque la compilation
+<answer><para>Sur AIX et Solaris (et probablement sur d'autre OS),
+&slony1; <emphasis>et &postgres;</emphasis> doivent être compilés avec l'option <option>--enable-thread-safety</option> . Le message ci-dessus arrive lorsque la compilation
de &postgres; n'a pas fait appel à cette option.</para>
+<TODO>
+<para>Le disfonctionnement ici vient du fait que le libc (indépendant des threads) et libpq
+(basés sur les threads) utilisent des emplacements de mémoire différente pour les codes d'erreur, c'est qui fait échouer les requêtes.</para>
-<para>Le disfonctionnement ici vient du fait que le libc (threadsafe) et libpq
-(non-threadsafe) utilisent des emplacement de mémoire différente pour le code erreur, ainsi en
-laissant la requête échouer.</para>
+<para>Des problèmes de ce genre surviennent avec des régularités surprenantes sur AIX et sur Solaris. Il sera probablement nécessaire
+de réaliser un <quote>audit du code objet</quote> pour s'assurer que <emphasis>tous</emphasis> les composants nécessaire ont été compilés et linkés avec l'option <option>--enable-thread-safety</option>.</para>
-<para>Des problèmes de ce genre sur AIX et sur Solaris, surviennent avec des régularités surprenantes.
-; l'erreur devrais prendre quelque choses ressemblant à un code <quote>objet ou à un code d'audit</quote> qui sont compilé
-make sure that <emphasis>ALL</emphasis> of the necessary components have been
-et linké avec l'option <option>--enable-thread-safety</option>.</para>
+<para>Par exemple, on peut rencontrer un problème sur Solaris lorsque
+<envar>LD_LIBRARY_PATH</envar> est défini et pointe sur les
+librairies depuis d'une ancienne version compilée de &postgres;. Cela signifie que même si
+la base de donnée <emphasis>avait été</emphasis> compilée avec l'option
+<option>--enable-thread-safety</option>, et même si
+<application>slon</application> a été recompilé pour cette version, lors de l'édition de lien dynamique de
+<application>slon</application> pointait sur un
+<quote>ancienne mauvaise version compilée sans l'option thread-safe,</quote>, et donc slon ne fonctionne pas. On ne peut s'apercevoir de cela qu'en exécutant <command>ldd</command>
+sur <application>slon</application>.</para> </answer>
-<para>Pour le moment, je me concentre sur le problème de
-<envar>LD_LIBRARY_PATH</envar> si c'est défini, sur Solaris, pour pointer sur les
-librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que même si
-la base <emphasis>a été</emphasis> compilée avec l'
-<option>--enable-thread-safety</option>, et que
-<application>slon</application> a été recompilé à nouveau, avec l'édition de lien dynamique de
-<application>slon</application> pointant sur un
-<quote>ancienne mauvaise version de thread-unsafe,</quote> et alors slon n'a pas fonctionné. Ceci n'était pas clair
-que c'était le cas, jusqu'à ce que je rexécute <command>ldd</command>
-à nouveau <application>slon</application>.</para> </answer>
-
-<answer><para> A noter que la version 7.4.2 de libpq, sur Solaris exige, un nouveau patch
-de <link linkend="threadpatch"> </link> ; Le requis est également demandé pour &postgres; version 8.0.
+<answer><para> A noter que la version 7.4.2 de libpq sur Solaris nécessite <link linkend="threadpatch"> un patch supplémentaire pour les threads </link> ; Ce pré-requis est également demandé pour &postgres; version 8.0.
</para>
</answer>
</qandaentry>
@@ -164,68 +147,61 @@
<qandaentry id="pg81funs">
<question> <para> Je suis en train de migrer sur une nouvelle version de &slony1;
-et je me débat avec un problème de<xref
-linkend="stmtupdatefunctions"/>. Lors d'exécution de<xref
+et je me débat avec un problème avec <xref
+linkend="stmtupdatefunctions"/>. Lors d'exécution de <xref
linkend="stmtupdatefunctions"/>, mon
-<application>postmaster</application> plante dessus avec un Signal 11.
-Le fichier log ne contient aucune erreur, relatives à
-&postgres; les logs indiquent que, yes indeed, the postmaster fell
-over.</para>
+<application>postmaster</application> plante avec le signal 11.
+Le fichier log ne contient aucune erreur, exceptées celles relatives à
+&postgres; les logs indiquent simplement que le postmaster est bel bien tombé.</para>
-<para> En scrutant le fichier core avec un débuguer, on constate que
+<para> En scrutant le fichier core avec un déboggueur, on constate que
l'incident survient lors de la validation d'une transaction. </para>
<para> Pour infos je suis sur &postgres; 8.1.[0-3]. </para>
</question>
-<answer> <para> Désagréablement l'ancienne versions de &postgres; 8.1 avait un problème
-où lorsque vous aviez besoin de redéfinir une fonction (comme , say,
-<function>upgradeSchema(text)</function>), et que après, dans la même session de transaction
-, vous exécutiez la même fonction, le
-<application>postmaster</application> tombait en erreur, et que la
-transaction ne pouvait se valider. </para>
+<answer> <para> Malheureusement les anciennes versions de &postgres; 8.1 avait un problème lors de la re-définition d'une fonction ( par exemple <function>upgradeSchema(text)</function>), lorsque la fonction est appellée juste après, au sein de la même transaction,
+, le
+<application>postmaster</application> plante et la
+transaction est annulée. </para>
<para> La commande &lslonik; <xref linkend="stmtupdatefunctions"/>
-fonctionne de cette manière; dans la même transaction, essayez ceci:
+fonctionne de cette manière; dans une même transaction elle effectue ceci :
<itemizedlist>
<listitem><para> Charger les nouvelles fonctions (depuis <filename>slony1_funcs.sql</filename>), notamment comprenant <function>upgradeSchema(text)</function>.
</para> </listitem>
<listitem><para> Lancer <function>upgradeSchema(text)</function> pour effectuer la migration nécessaire des schémas de la base. </para> </listitem>
-<listitem><para> Notifier au pro cesses &lslon; le fait de changement de la configuration.</para> </listitem>
+<listitem><para> Avertir les processus &lslon; du changement de configuration.</para> </listitem>
</itemizedlist>
</para>
<para> Malheureusement, en &postgres; 8.1.0, 8.1.1, 8.1.2, et 8.1.3,
ceci est conflictuel avec un bug où l'utilisation et la modification d'une fonction plpgsql au sein de la même transaction
-lié à un plantage. </para>
+provoque un plantage. </para>
-<para> Plusieurs contournements sont à envisager. </para>
+<para> Plusieurs contournements sont envisageables. </para>
</answer>
-<answer> <para> La réponse privilégiée serais de dire migrer &postgres; en
-version 8.1.4 ou supérieur. Les changements mineurs du noyau n'entraîne pas de
-reconstruction de la base; ceci devrait simplement exiger d'installer un noyau 8.1.x
-en redémarrant les <application>postmaster</application> avec cette nouvelle version. </para>
+<answer> <para> La meilleur solution consiste à migrer &postgres; vers une version 8.1.4 ou supérieure. Les changements entre deux versions mineures ne nécessite pas la reconstruction de la base, il suffit simplement d'installer la nouvelle version puis de redémarrer le <application>postmaster</application> avec cette nouvelle version. </para>
</answer>
-<answer><para> Si cette solution ne convient pas, il est possible d'effectuer une série de transaction <quote>à la main</quote>,
-l'équivalent de ce que &lslonik; aurait fait pour cette migration. </para>
+<answer><para> Si cette solution ne convient pas, il est possible d'effectuer la mise à jour via une série de transaction <quote>à la main</quote>, qui correspondent à ce que &lslonik; aurait fait pour cette migration. </para>
<itemizedlist>
-<listitem><para> Prendre <filename>slony1_funcs.sql</filename> et faire trois remplacement dans ce fichier: </para>
+<listitem><para> Prendre <filename>slony1_funcs.sql</filename> et faire trois remplacements dans ce fichier: </para>
<itemizedlist>
<listitem><para> Remplacer <quote>@CLUSTERNAME@</quote>avec le nom du cluster</para> </listitem>
-<listitem><para> Remplacer <quote>@MODULEVERSION@</quote> avec la version littérale de &slony1; comme <quote>1.2.10</quote> </para> </listitem>
-<listitem><para> Remplacer <quote>@NAMESPACE@</quote> avec <quote>double-quoted</quote> nom du cluster, comme "_MyCluster" </para> </listitem>
+<listitem><para> Remplacer <quote>@MODULEVERSION@</quote> avec la version de &slony1; par exemple <quote>1.2.10</quote> </para> </listitem>
+<listitem><para> Remplacer <quote>@NAMESPACE@</quote> avec le nom du namespace du cluster <quote>entre doubles quotes</quote> , par exemple "_monCluster" </para> </listitem>
</itemizedlist>
</listitem>
-<listitem><para> Recharger cet<quote>remis à niveau</quote> de jeux de fonctions dans la base.</para> </listitem>
+<listitem><para> Recharger dans la base cet ensemble de fonctions <quote>mise à jour</quote>.</para> </listitem>
<listitem><para> Exécuter la fonction stockée via <command>select <function>upgradeSchema('1.2.7')</function>; </command>,
-en supposant que la précédente version de &slony1; en cours était celle de 1.2.7. </para> </listitem>
-<listitem><para> Rechargement total des processes &lslon; sera probablement une sage décision après ce genre de <quote>chirurgie.</quote> </para> </listitem>
+en supposant que la précédente version de &slony1; en cours était la 1.2.7. </para> </listitem>
+<listitem><para> Le redémarrage de tous les processus &lslon; est probablement une sage décision après ce genre de <quote>chirurgie.</quote> </para> </listitem>
</itemizedlist>
</answer>
</qandaentry>
@@ -243,34 +219,27 @@
and thus not supported by Slony-I.
</screen></para>
-<para> Ceci arrive avec &postgres; 8.2.5, ce qui est certainement un peu plus récent que
-7.3. </para>
+<para> Ceci arrive avec &postgres; 8.2.5, ce qui est nettement plus récent que la version 7.3. </para>
</question>
-<answer> <para> <application>configure</application> est à la recherche de ce directif
-en compilant un petit programme requis, pour lequel il est appelé, et
-vérifie la compilation se passe bien. Avec la ligne de commande <command>gcc</command>
-il utilise <command>-lpq</command> pour chercher la librairie. </para>
+<answer> <para> La fonction <application>configure</application> est à la recherche du symbole PQunescapeBytea, elle compile un petit programme qu'il l'appele et
+vérifie la compilation se passe bien. Dans la ligne de commande <command>gcc</command>,
+elle utilise <command>-lpq</command> pour chercher la librairie. </para>
-<para> Malheureusement, ce paquetage fait défaut depuis le lien symbolique, de
-<filename>/usr/lib64/libpq.so</filename> à
-<filename>libpq.so.5.0</filename>; c'est pourquoi il plante sur libpq.
-Le <emphasis>vrai</emphasis> problème c'est que le compilateur n'arrive pas à trouver une
-librairie pour l'édition de lien, et non pas que libpq est absent et qui a manqué à l'appel.
+<para> Malheureusement, ce paquetage n'a pas de lien symbolique, reliant <filename>/usr/lib64/libpq.so</filename> à
+<filename>libpq.so.5.0</filename>; c'est pourquoi la fonction configure n'arrive pas à trouber libpq.
+Le <emphasis>vrai</emphasis> problème c'est que le compilateur n'arrive pas à trouver une librairie pour l'édition de lien, et non pas que libpq ait manqué à l'appel.
</para>
-<para> Eventuellement il faudra remonter ces informations vers ceux qui gèrent le paquetage
-<filename>postgresql-libs.x86_64</filename>. </para>
+<para> Au final, ces informations doivent être envoyée vers ceux qui gèrent le paquet <filename>postgresql-libs.x86_64</filename>. </para>
</answer>
-<answer> <para> Notez que ce même symptôme peut être révélateur des problèmes semblables de ce genre
-de configuration système. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement
-de la part de votre compilateur C, tout peuvent potentiellement mener à ce même message d'erreur. </para>
+<answer> <para> Notez que ce même symptôme peut être révélateur d'autres problèmes de ce genre au niveau de la configuration système. Les mauvais liens symboliques, les mauvaises permissions, le mauvais comportement de la part de votre compilateur C, tout peuvent potentiellement mener à ce même message d'erreur. </para>
-<para> Ainsi si vous rencontrez cette erreur, vous aurez besoin de regarder le fichier log généré,
- <filename>config.log</filename>. Cherchez par la bas, et regarder quel est le souci <emphasis>récemment</emphasis> rencontré.
-Ceci sera bénéfique, pour trouver la racine de l'épineux problème.</para>
+<para> Ainsi si vous rencontrez cette erreur, vous aurez besoin de regarder le fichier log
+<filename>config.log</filename>. Cherchez à partir du bas, et regardez quel est le souci <emphasis>réellement</emphasis> rencontré.
+Ceci sera utile pour trouver la vrai racine de cet épineux problème.</para>
</answer>
</qandaentry>
@@ -280,24 +249,22 @@
<qandadiv id="faqconnections"> <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
<qandaentry>
-<question><para>Je cherche le nom de<envar>_clustername</envar>, et
+<question><para>Je cherche le namespace<envar>_clustername</envar>, et
il est introuvable.</para></question>
<answer><para> Si le DNS sont erronés, alors l'instance &lslon;
ne pourra pas se connecter aux noeuds.</para>
-<para>Ceci mène aux fait que les noeuds seront introuvables.</para>
+<para>Ceci mène au fait que les noeuds seront introuvables.</para>
-<para>Revérifier la configuration des connexions. D'ailleurs depuis <xref
-linkend="slon"/> le linkage avec libpq, vous devrez avoir le mot de passe généré
- dans <filename> $HOME/.pgpass</filename>, partiellement reporté dans bonne/mauvais authentification ici.</para>
+<para>Revérifier la configuration des connexions. D'ailleurs, puisque <xref linkend="slon"/> est lié à libpq, vous pouvez stocker le mot de passe dans <filename> $HOME/.pgpass</filename>, le problème vient peut-être d'une erreur dans ce fichier.</para>
</answer>
</qandaentry>
<qandaentry id="morethansuper">
-<question> <para> J'ai crée un compte <quote>super utilisateur</quote>,
+<question> <para> J'ai créé un compte <quote>super-utilisateur</quote>,
<command>slony</command>, pour exécuter les activités de réplications. Comme suggéré,
-je l'ai configuré comme super user, avec l'interrogation suivante :
+je l'ai configuré comme super-user, avec la requête suivante :
<command>
update pg_shadow set usesuper = 't' where usename in ('slony',
'molly', 'dumpy');
@@ -318,12 +285,10 @@
WARN remoteWorkerThread_1: data copy for set 28661 failed - sleep 60 seconds
</programlisting>
-<para> Celà a continué de se planter, à plusieurs reprise, juqsqu'à ce que
-<application>slon</application> se connecte comme
-<command>postgres</command> le faisait.</para>
+<para> Cela continue de planter, encore et toujours, jusqu'à ce que je redémarre <application>slon</application> pour qu'il se connecte avec le compte <command>postgres</command>.</para>
</question>
-<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>
+<answer><para> Le problème est assez évident en soi; la permission sur la table de système <envar>pg_class</envar> est ignorée.</para></answer>
<answer><para> La <quote>solution</quote> est la suivante:</para>
<programlisting>
@@ -331,7 +296,7 @@
</programlisting>
</answer>
-<answer><para> En version 8.1 et supérieur, vous avez aussi besoin de:</para>
+<answer><para> En version 8.1 et supérieure, vous avez aussi besoin de:</para>
<programlisting>
update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony';
</programlisting>
@@ -339,8 +304,7 @@
</qandaentry>
<qandaentry>
-<question><para> Au moment d'enregistrer un esclave,dans le log, j'obtiens le message
-suivant :
+<question><para> Au moment d'enregistrer un esclave, j'obtiens le message suivant dans les logs :
<screen>
DEBUG1 copy_set 1
@@ -349,9 +313,7 @@
WARN remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds
</screen></para></question>
-<answer> <para> Il y a évidemment un certain nombre de vieilles transactions bloquantes,
-de &slony1; restant depuis le traitement des synchros. Vous devriez jeter un coup d'oeil
-à pg_locks to see what's up:</para>
+<answer> <para> Il y a évidemment un certain nombre de vieilles transactions qui empêche &slony1; de traiter des synchronisations. Vous devriez jeter un coup d'oeil à pg_locks pour ce qu'il en est :</para>
<screen>
sampledb=# select * from pg_locks where transaction is not null order by transaction;
@@ -362,105 +324,78 @@
(2 rows)
</screen>
-<para>See? 127314921 est en effet plus vieux que 127314958, et il est toujours en cours d'exécution.</para>
+<para>Vous voyez ? la transaction 127314921 est en effet plus vieilles que la transaction 127314958, et elle est toujours en cours d'exécution.</para>
-<para> Un long traitement G/LA, s'emballe durant une interrogation
-<application>RT3</application>, avec
-<application>pg_dump</application>, toute les transaction semblent s'exécuter pour une période interminable.
-Jusqu'à ce que elles soient complétées ou bien interrompu, on verra alors le message d'erreur suivant:
+<para> Un long traitement de publi-postage, une requête <application>RT3</application> qui s'emballe, un
+<application>pg_dump</application>, toutes ces opérations ouvrent des transactions pour une période importante.
+Jusqu'à ce qu'elles soient complétées ou bien interrompues, on verra alors le message d'erreur suivant:
<quote> data copy
for set 1 failed - sleep 60 seconds </quote>.</para>
-<para>D'ailleurs, s'il y a plus d'une base de données sur le cluster du &postgres;
-, 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
-quoi que</quote> s'avérant encore en marche. Le fait est que la base de donnée dissociée
-sur le cluster n'est pas pertinente; &slony1; attendra
-jusqu'à ce que ces vieilles transactions se terminent.</para>
+<para>Quoiqu'il en soit, s'il y a plus d'une base de données sur le cluster du &postgres; , et que la charge se situe sur une autre base, vous verrez apparaitre des <quote>transactions en cours avec un XID
+antérieur</quote> à celle de &slony1;. Le fait que la transaction se déroule sur une base de donnée dissociée ne change rien ; &slony1; attendra jusqu'à ce que ces vieilles transactions se terminent.</para>
</answer>
</qandaentry>
<qandaentry>
-<question><para>Même chose que ce qui précède. Ce que j'ai oublié de mentionner, aussi bien,
-était que j'essayais d'ajouter
-<emphasis>DEUX</emphasis> abonnés, concurremment.</para></question>
+<question><para>Même question que précèdemment. J'ai oublié de mentionner que j'essayais d'ajouter
+<emphasis>DEUX</emphasis> abonnés, simultanément.</para></question>
-<answer><para> Cela ne peut marcher: &slony1; ne peut employer la commande
-<command>COPY</command> de manière concurrente. voir
-<filename>src/slon/remote_worker.c</filename>, la fonction
-<function>copy_set()</function></para>
+<answer><para> Cela ne peut pas marcher: &slony1; ne peut employer la commande
+<command>COPY</command> de manière concurrente. Voir la fonction
+<function>copy_set()</function> dans le fichier <filename>src/slon/remote_worker.c</filename></para>
<screen>
$ ps -aef | egrep '[2]605100'
postgres 2605100 205018 0 18:53:43 pts/3 3:13 postgres: postgres sampledb localhost COPY
</screen>
-<para>Ceci s'avère justement être une transaction de <command>COPY</command>
-impliqué en installant l'abonnement pour un des noeuds. Tout a l'air bien;
-le système s'occupe de configurer le premier abonné; il ne veut pas démarrer sur le second
-tant que le premier n'a pas fini son enregistrement.
-Cela représente une cause possible.</para>
+<para>Une transaction <command>COPY</command>
+essaie d'installer l'abonnement pour un des noeuds. Tout a l'air bien;
+le système s'occupe de configurer le premier abonné; il ne vapas démarrer sur le second tant que le premier n'a pas fini son enregistrement. Cela représente une cause possible.</para>
-<para>Ceci a (peut-être malheureusement)comme conséquence que vous ne pouvez pas peupler
-deux esclaves concurremment pour un simple fournisseur. Vous devez souscrire un et un seul abonné à la fois,
-une fois qu'il a accompli l'abonnement,(copyant le contenu des table et autre) peut s'occuper de débuter l'enregistrement
+<para>Ceci a comme (facheuse) conséquence que vous ne pouvez pas peupler deux esclaves simultanément à partir d'un même fournisseur. Vous devez souscrire un et un seul abonné à la fois,
+une fois qu'il a accompli l'abonnement,( en copiant le contenu des table, etc.), on peut s'occuper de débuter l'enregistrement
du deuxième.</para></answer>
</qandaentry>
-<qandaentry id="missingoids"> <question> <para> Nous somme souciés par quelques choses
-car ne pouvant envisager de désinstaller entièrement une réplication du cluster slony
-entre un maître et un esclave.</para>
+<qandaentry id="missingoids"> <question> <para> Nous avons rencontré un message inattendu en désinstallant entièrement un cluster de réplication slony sur le maître et l'esclave.</para>
-<warning> <para><emphasis>ASSUREZ-VOUS QUE VOUS ARRÊTEZ L'EXECUTION DE VOS APPLICATIONS
-SUR VOTRE BASE DE DONNEES MAITRE, LORS DE L'ELIMINATION D'UN MEMBRE DU
+<warning> <para><emphasis>MAKE SURE YOU STOP YOUR APPLICATION RUNNING
+AGAINST YOUR MASTER DATABASE WHEN REMOVING THE WHOLE SLONY
CLUSTER</emphasis>, or at least re-cycle all your open connections
after the event! </para></warning>
-<para> Les connexions <quote>se renouvellent</quote> ou se rapportent à OIDs qui sont
-tuées lors du lancement du script de désinstallation. Et vous obtiendrez
-un bon nombre d'erreurs en conséquence
+<para> The connections <quote>remember</quote> or refer to OIDs which
+are removed by the uninstall node script. And you will get lots of
+errors as a result...
</para>
+
</question>
-<answer><para> Il y a deux sections notables de
-&postgres; qui sont la mise en cache des plans d'interrogation et les OIDs:</para>
+<answer><para> Il y a deux mécanismes de
+&postgres; qui mettent en cache les plans d'interrogation et les OIDs:</para>
<itemizedlist>
-<listitem><para> Préparer la requête</para></listitem>
+<listitem><para> Les requêtes préparées ("prepared statements")</para></listitem>
<listitem><para> Les fonctions pl/pgSQL </para></listitem>
</itemizedlist>
-<para> En particulier le problème n'est pas que sous &slony1; en un;
-se produirait quand de telles modifications importantes sont apportées aux fondements de base
-de données. Il n'est pas imaginable que cela mène à perdre des données, mais de se voir confronté
-à une vague d'erreur relatives à OID.
+<para>Ce problème n'est pas pas particulier à &slony1;;
+il se produit à chaque fois quand des modifications importantes sont apportées aux schémas de la base
+de données. Cela n'entaine pas de perte des données, mais cela provoque des vagues d'erreurs relatives aux OID.
</para></answer>
-<answer><para> Le problème arrive lorsque vous utilisez une sorte de
-<quote>pool de connexion</quote> qui essaie de les reconnecter à la fin.
-Si vous remettez l'application en route après ceci, des nouvelles connexions
-sont générées avec un <emphasis>nouveau</emphasis>plan d'interrogation, et qui
-font disparaître les erreurs. Si votre pool de connexion tue les sessions, et en recrée de nouvelle,
-alors ces nouvelles session auront de <emphasis>nouveau</emphasis> plan d'exécution, et
-que les erreurs vont disparaître. </para></answer>
-
-En notre code nous laissons tomber le raccordement sur n'importe quelle
-erreur nous ne peut pas tracer à un état prévu. Ceci réutiliserait par la
-suite tous les raccordements sur de tels problèmes inattendus après juste une
-erreur par raccordement. Naturellement si l'erreur apprête car une violation de
-contrainte qui est un état identifié, ce won' ; l'aide de t l'un ou l'autre, et
-si le problème est persistant, les raccordements maintiendra réutiliser qui
- laisseront tomber l'effet de la mise en commun, dans le dernier cas que
- le code de mise en commun pourrait également annoncer un Admin. pour jeter
- un coup d'oeil
+<answer><para> Le problème survient lorsque vous utilisez une sorte de
+<quote>pool de connexion</quote> qui recycle les vieilles connexions.
+Si vous relancez l'application après ceci, les nouvelles connexions
+vont produire de <emphasis>nouveau</emphasis>plan d'exécution et les erreurs disparaitront. Si votre pool de connexion tue les sessions, et en recrée de nouvelles, alors ces nouvelles sessions auront de <emphasis>nouveaux</emphasis> plans d'exécution, et que les erreurs disparaîtront. </para></answer>
<answer> <para> Dans notre code nous éliminons toutes connexions ayant des erreurs inattendues dans
-le contexte. Ceci dit, les convexions devront être rétablis à la fin de chaque telle erreur
-inattendues, à raison d'une erreur par connexion. Naturellement si l'erreur remonte une violation de contrainte,
-qui est une condition reconnue, ne peut aider la situation, et si le problème persiste, les connexions sont restaurées,
-qui aura pour effet de casser l'effet de pool, dans ce dernier cas, l'administrateur aura à jeter
-un coup d'oeil sur le code. </para> </answer>
+le contexte. Ainsi, toutes les connexions devraient être renouvelées dès l'apparition d'une erreur
+inattendue. Naturellement si l'erreur remonte une violation de contrainte, qui est une condition reconnue, ce va provoquer une renouvellement de connexion, et si le problème persiste, les connexions sont recyclées en permanence, ce qui annulera l'effet du pool, dans ce cas, le pooler de connexion proposera probablement à l'administrateur de jeter un coup d'oeil à la situation. </para> </answer>
</qandaentry>
@@ -469,50 +404,43 @@
<screen>NOTICE: Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated</screen>
-<para> Les deux <envar>sl_log_1</envar> et <envar>sl_log_2</envar> continue de prendre du volume,
-et <envar>sl_log_1</envar> n'est jamais remis à zéro.
+<para> Les tables <envar>sl_log_1</envar> et <envar>sl_log_2</envar> continue de prendre du volume,
+et <envar>sl_log_1</envar> n'est jamais vidée.
Quel est le souci?
</para> </question>
-<answer><para> Ceci est un cas symptomatique et similaire au précèdent,
-relatif à la suppression de réplication : s'il y a des connexions établies, s'attardant à utiliser des plan d'exécutions
-basés sur des vieilles fonctions stockées, donne par conséquence une écriture dans
- <envar>sl_log_1</envar> </para>
+<answer><para> Ceci est un cas symptomatique du problème précèdent,
+relatif à la suppression de réplication : s'il y a des vieilles connexions établies, qui continuent à utiliser des plan d'exécutions
+basés sur des vieilles fonctions stockées, ce qui provoque des écritures dans <envar>sl_log_1</envar> </para>
-<para> La fermeture des vieilles et l'ouverture des nouvelles connexions, résous ce problème.</para> </answer>
+<para> La fermeture des vieilles connexions et l'ouverture des nouvelles connexions, résoudra ce problème.</para> </answer>
-<answer> <para> En d'autre terme, la présence d'un ordre dans la liste d'attente de &postgres;
-pour implémenter des dépendances, aura pour effet de descendre les plans d'exécution, lorsque cette dépendance
-joue sur l'objet qui change. </para> </answer>
+<answer> <para> A plus long terme, il y a un item dans la TODO liste de &postgres; pour implémenter une vérification des dépendances, qui pourra supprimer un plan d'exécution caché, lorsque un objet lié à ce plan est modifié. </para> </answer>
</qandaentry>
<qandaentry>
-<question><para>J'ai pointé un noeud de souscription à un fournisseur différent, et il a cessé
-la réplication.</para></question>
+<question><para>J'ai pointé un noeud abonné vers un noeud fournisseur différent, et il a cessé la réplication.</para></question>
<answer><para>
-Nous rappelons que ceci arrive lorsque nous souhaitons initialiser un noeud où
-nous avons la configuration suivante:
+Nous avons constaté que ceci arrive lorsque on réinitialise un noeud dans la configuration suivante:
<itemizedlist>
-<listitem><para> Node 1 - fournisseur</para></listitem>
-<listitem><para> Node 2 - s'enregistrer au noeud 1 - le noeud que nous avons réinitialisé</para></listitem>
-<listitem><para> Node 3 - s'enregistrer au noeud 3 - le noeud qui doit répliquer</para></listitem>
+<listitem><para> Noeud 1 - fournisseur</para></listitem>
+<listitem><para> Noeud 2 - abonné au noeud 1 - le noeud que l'on réinitialise</para></listitem>
+<listitem><para> Noeud 3 - abonné au noeud 3 - le noeud qui doit continuer à répliquer</para></listitem>
</itemizedlist></para>
-<para>L'abonnement pour le noeud 3 a changé dans le sens d'avoir
-le noeud 3 comme fournisseur, et on a fait<xref linkend="stmtdropset"/> /<xref
-linkend="stmtsubscribeset"/> pour le noeud 2 pour qu'il soit rechargé.</para>
+<para>L'abonnement du noeud 3 est changé pour que le noeud 1 soit
+son fournisseur et on exécute <xref linkend="stmtdropset"/> /<xref
+linkend="stmtsubscribeset"/> sur le noeud 2 pour qu'il soit repeuplé.</para>
-<para>Malencontreusement, la réplication a été arrêtée soudainement sur le noeud 3.</para>
+<para>Malheureusement, la réplication s'arrête soudainement sur le noeud 3.</para>
-<para>Le problème était qu'il n'y avait pas un ensemble approprié de
-<quote>ports d'écoute</quote> dans <xref linkend="table.sl-listen"/> pour permettre aux évènements
-depuis le noeud 1 de se propager sur le 3. Les événements vont se reporter aux noeuds 2 et bloquent ainsi
-derrière l'évènement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para>
+<para>Le problème vient du fait qu'il n'y a pas d'ensemble approprié de
+<quote>voies d'écoute</quote> dans la table <xref linkend="table.sl-listen"/> pour propager les évènements
+depuis le noeud 1 vers sur le noeud 3. Les événements sont transportés vers le noeud 2 et sont bloqués par l'événement <xref linkend="stmtsubscribeset"/> que le noeud 2 est en train de traiter.</para>
-<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
-de l'ajouter directement en ports d'écoute entre les deux noeuds 1 et 3.
+<para>Le script suivant supprime les voies d'écoute qui font transiter les events par le noeud 2 et ajouter une voie d'écoute directe entre les noeuds 1 et 3.
<programlisting>
cluster name = oxrslive;
@@ -528,30 +456,27 @@
}
</programlisting></para>
-<para>Juste après que ce script a été terminé, les événements de <command>SYNC</command> ont commencé à
-propager encore sur le noeud 3.
+<para>Juste après l'éxécution de ce script, les événements <command>SYNC</command> se propagent à nouveau vers le noeud 3.
-Ceci précise deux principes:
+Ceci souligne deux principes:
<itemizedlist>
<listitem><para>
-Si vous avez des noeuds multiples, et des abonnés en cascade,
+Si vous avez plusieurs noeuds, et des abonnés en cascade,
vous devez faire attention en repeuplant les entrés <xref
-linkend="stmtstorelisten"/>, et en modifiant leur structures de l'<quote>arbre</quote>de changement
-de réplication.</para></listitem>
+linkend="stmtstorelisten"/>, et en modifiant si la structure de l'<quote>arbre</quote> de réplication a changé.</para></listitem>
<listitem><para> La version 1.1 fourni des meilleurs outils pour gérer ce cas.</para>
</listitem>
</itemizedlist></para>
-<para>Les problèmes relatifs aux <quote>chemins d'écoute</quote> sont discutés
-plus bas au <xref linkend="listenpaths"/> </para></answer>
+<para>Les problèmes relatifs aux <quote>voies d'écoute</quote> sont discutés plus précisions dans la section <xref linkend="listenpaths"/> </para></answer>
</qandaentry>
<qandaentry id="multipleslonconnections">
<question><para> En redémarrant &lslon;, j'obtiens
-le message suivant <quote>FATAL</quote> dans le log. Que se passe-t-il??? </para>
+les messages <quote>FATAL</quote> suivants dans le log. Que se passe-t-il??? </para>
<screen>
2006-03-29 16:01:34 UTC CONFIG main: slon version 1.2.0 starting up
2006-03-29 16:01:34 UTC DEBUG2 slon: watchdog process started
@@ -575,87 +500,52 @@
</question>
<answer><para> La table <envar>sl_nodelock</envar> est utilisée comme un
-<quote>enclencheur</quote>pour prévenir que les deux process &lslon; essaient de prendre
-la gestion du même noeud en même temps. Le &lslon; essais d'insérer
-un enregistrement dans la table; seulement il peut le faire avec succès que
-si il est le seul à gérer le noeud. </para></answer>
+<quote>verrou partagé</quote>pour empêcher que deux processus &lslon; essaient de prendre le controle du même noeud en même temps. Le &lslon; essaie d'insérer un enregistrement dans la table; il ne peut réussier que si il est le seul à gérer le noeud. </para></answer>
-<answer><para> Ce message d'erreur est typiquement un signe que vous avez démarrez
-un second process &lslon; pour un noeud donné. Le &lslon;pose la question évidente qui est :
- <quote>Avez vous déjà un a slon démarré pour gérer ce noeud?</quote> </para></answer>
+<answer><para> Ce message d'erreur est typiquement un signe que vous avez démarrez un second processus &lslon; pour un noeud donné. Le &lslon; pose la question évidente qui est : <quote>Avez vous déjà un slon démarré pour gérer ce noeud?</quote> </para></answer>
-Vous supposant éprouver une certaine sorte de panne de réseau, le raccordement
-entre le &lslon; et la base de données peut échouer, et le &lslon; peut
-figurer ceci dehors longtemps avant le &postgres; exemple il était relié fait.
-Le résultat est qu'il y aura un certain nombre de les raccordements à vide sont partis sur
-le serveur de base de données, qui won' ; t soit fermé jusqu'aux temps morts de TCP/IP complets,
-qui semble prendre normalement environ deux heures. Pour cette période de deux heures, le &lslon;
-essayera de se relier, à plusieurs reprises, et recevra le message mortel ci-dessus, plus d'et au-dessus de.
+<answer><para> En supposant que vous subissez une panne de réseau,
+les connections entre &lslon; et la base de données peuvent échouer, et &lslon; peut s'en apercevoir bien avant l'instance de &postgres; sur laquelle il est connecté.
+La conséquence en est qu'un certain nombre de connexion pré-établie vont rester ouvertes sur la base de données jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui nomallement arrive au bout de
+deux heures. Durant cette période de deux heures, le &lslon; va essayer de se reconnecter, encore et encore, et obtient le message d'erreur ci-dessous, encore et encore. </para>
-<answer><para> Vous supposant éprouver une certaine sorte de panne de réseau,
-les connections entre &lslon; et la base de données peuvent échouer, et &lslon;
-peut avertir cela bien avant l'instance de &postgres; il était connecté pour ce faire.
-La conséquence en est qu'un certain nombre de connexion pré-établie vont s'ouvrir su la base de données
-et qui ne vont pas se terminer jusqu'à ce que le timeout de TCP/IP arrive à échéance, chose qui n'arrive que
-tous les deux heures. Durant cette période de deux heures, le &lslon; va essayer de se reconnecter,
-encore et encore, et obtient le message d'erreur ci-dessous réputé Fatl. </para>
-
<para> Un administrateur peut mettre fin à cette situation en se connectant sur
-le serveur et en lançant <command>kill -2</command> pour terminer les connexions mourantes.
-Malheureusement , puisque le problème a eu lieu dans couche de gestion de réseau,ni &postgres; ni &slony1;
-a le moyen direct de détecter ceci. </para>
+le serveur et en lançant <command>kill -2</command> pour terminer les connexions bloquantes.
+Malheureusement , puisque le problème a eu lieu au niveau de la couche réseau, &postgres; et &slony1;
+n'ont aucun moyen direct de détecter ceci. </para>
-<para> Vous pouvez <emphasis>la plupart</emphasis> des cas éviter ceci en s'assurant
-que le process &lslon; est hébergé quelque part près des serveurs qu'il gère. Si le &lslon;
+<para> Vous pouvez éviter ceci dans <emphasis>la plupart</emphasis> des cas en vous assurant que le processus &lslon; est hébergé à proximité des serveurs qu'il gère. Si le &lslon;
est hébergé sur le même serveur que la base de donnée qu'il gère, alors
toute <quote>panne de réseau</quote> qui peut interrompre les connexions
-seraient susceptibles d'être assez sérieux pour menacer le serveur entier. </para></answer>
+serait susceptible d'être assez sérieuse pour menacer le serveur entier. </para></answer>
</qandaentry>
<qandaentry>
-<question><para> Quand est-ce que je peux arrêter les process &lslon;?</para></question>
+<question><para> Quand est-ce que je peux arrêter les processus &lslon;?</para></question>
-<answer><para> Généralement ce n'est pas un grand compromis pour arrêter les processes &lslon;
-Chacun d'eux est un <quote>simplement</quote> un client de &postgres;,
-gérant chacun un noeud, qui engendre des fils pour gérer et recevoir des évènements
-depuis d'autre noeud. </para>
+<answer><para> Généralement, il n'y a aucun risque à arrêter un processus &lslon;. Chacun d'eux est un <quote>simplement</quote> un client de &postgres;, gérant un noeud, qui déploie des threads pour gérer et recevoir des évènements
+depuis d'autres noeuds. </para>
-<para>L'<quote>évènement d'écoute</quote> des serveurs n'est pas un travail sorcier; ils n'ont
-rien à faire que de temps en temps de tester le noeud distant pour déterminer si sur le noeud en question,
-il y a des tâches à faire. Si vous tuer le process &lslon; sa surveillance sera fermée, qui doit avoir peu
-ou pas du tout d'impact sur rien peut-être. Les éventements générés pour un &lslon; en arrêt reprendront
+<para>Les threads des<quote>évènements d'écoute</quote> ne sont pas
+très importants; ils ne font que vérifier de temps en temps les noeuds distants pour déterminer si il y a des taches à faire sur le noeud local. Si vous tuez le processus &lslon; ces threads de surveillance seront fermés, qui aura peu ou pas du tout d'impact. Les éventements produits pendant que &lslon; est arrêté seront récupérés
lors de son redémarrage.</para>
-<para> La<quote>gestion des noeuds</quote> est un peu plus intéressant;
- la plupart du temps , vous pouvez prévoir, sur un abonné, pour son fil
- d'exécuter l'évènement<command>SYNC</command>. Si vous arrêtez
-le &lslon; durant un évènement, la transaction va échouer, et s'annuler, alors lorsque the &lslon;
-redémarre, il aura de reprendre l'évènement pour l'exécuter.</para>
+<para> Le thread de <quote>gestion des noeuds</quote> est un peu plus intéressant; la plupart du temps sur un abonné, on peut s'attendre à ce que le ce thread traite des évènements <command>SYNC</command>. Si vous arrêtez le &lslon; durant un évènement, la transaction va échouer, et s'annuler, et lorsque &lslon;
+redémarre, il reprendra l'évènement pour l'exécuter.</para>
-<para> L'unique situation où cela peut arriver est
- <emphasis>particulièrement</emphasis> <quote>l'arrêt de coeur</quote> si
-l'évènement qui vient de s'achever était un traitement de longue durée comme,
-<command>COPY_SET</command> pour une large réplication.</para>
+<para> L'unique situation où cela peut provoquer des problèmes <emphasis>particulièrs</emphasis> est lorsque l'évènement en cours est un traitement de longue durée comme,
+un <command>COPY_SET</command> pour une large ensemble de réplication.</para>
-<para>L'autre chose qui <emphasis>pourrait</emphasis> causer l'ennui est
-si &lslon; travaille sur un noeud distant auxquels il est connecté;
-vous pouvez découvrir que les sessions de la base de données sont laissées <command>disponible en transaction</command>.
-Ceci peut normalement arriver si les connexions réseaux sont supprimées sans que &lslon; ni la base en ait pris connaissance
+<para>L'autre chose qui <emphasis>pourrait</emphasis> poser problème relativement distant du noeud auxquel il est connecté;
+vous pouvez découvrir que les connexions de la base de données sont laissées <command>disponible en transaction</command> ("idle in transaction").
+Ceci peut peut arriver si les connexions réseaux sont supprimées sans que &lslon; ni la base en ait pris connaissance
.Dans ce cas vous pouvez découvrir que des connexions <quote>zombies</quote> traînent encore durant deux long heures
-si vous n'y aller pas à la main pour leur mettre fin dans &postgres;
-backends.</para>
+si vous n'y aller pas tuer à la main les processus &postgres;
+.</para>
- Il y a un autre cas qui pourrait causer l'ennui ; quand &lslon;
- la gestion du noeud d'origine ne fonctionne pas, événement de synchro
- ne fonctionne pas contre ce noeud. Si &lslon; les séjours vers le bas
- pendant une période prolongée, et quelque chose aiment isn' ; fonctionnement
- de t, vous pourriez être laissé avec une grande synchro au processus quand il
- vient support. Mais c'est seulement un souci si ce &lslon; est vers le bas
- pendant une période prolongée ; le fermant pour uns seconde shouldn' ; cause
- de t tout grand problème.
+<TODO>
-
<para> Il y a un autre cas qui pourrait causer l'ennui; quand
&lslon; administrant son noeud d'attachement n'est pas en cours d'exécution
,aucun évènement <command>SYNC</command> s'exécute sur ce même serveur. Si le &lslon;
Plus d'informations sur la liste de diffusion Trad