[Trad] [svn:pgfr] r1368 - traduc/branches/slony_1_2
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 3 Aou 12:44:12 CEST 2009
Author: gleu
Date: 2009-08-03 12:44:12 +0200 (Mon, 03 Aug 2009)
New Revision: 1368
Modified:
traduc/branches/slony_1_2/faq.xml
Log:
Version 1.2 de la FAQ.
Modified: traduc/branches/slony_1_2/faq.xml
===================================================================
--- traduc/branches/slony_1_2/faq.xml 2009-07-28 19:33:13 UTC (rev 1367)
+++ traduc/branches/slony_1_2/faq.xml 2009-08-03 10:44:12 UTC (rev 1368)
@@ -7,7 +7,7 @@
<qandaset>
<indexterm><primary>Foire Aux Questions de &slony1;</primary></indexterm>
-<qandadiv id="faqcompiling"><title> &slony1; FAQ: Monter et Installer &slony1; </title>
+<qandadiv id="faqcompiling"><title> &slony1; FAQ: Compiler et Installer &slony1; </title>
<qandaentry>
@@ -34,41 +34,32 @@
<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
&slony1;.</para>
-<!-- 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 +78,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 +104,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 +117,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>
-<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>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>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>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>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>
+<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>
-<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 +145,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 +217,25 @@
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 +245,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 +281,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 +292,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 +300,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 +309,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 +320,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 +400,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 +452,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,113 +496,78 @@
</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'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.
+<para> Il y existe un autre cas qui peut poser problème : quand
-
-<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;
- arrêté pour une longue durée, et que quelques chose du genre <xref linkend="gensync"/> n'est pas encours,
-vous pouvez vous retrouvez avec <emphasis>un énorme<command>SYNC</command></emphasis> à effectuer
-lorsque vous vous apprêtez à réaliser une sauvegarde. Ceci est vrai seulement si &lslon; est en arrêt pendant une période
-assez longue; alors que un arrêt de quelques seconds ne génère pas de problème.</para> </answer>
+le processus &lslon; qui administre le noeud origine ne fonctionne pas,
+aucun évènement <command>SYNC</command> ne s'exécute sur ce noeud.
+Si le &lslon; reste arrêté pendant une longue durée, et qu'aucun processus de type
+<xref linkend="gensync"/> n'est en cours, alors vous pouvez vous retrouvez avec
+<emphasis>un énorme <command>SYNC</command></emphasis> à effectuer
+lorsque le processus &lslon; du noeud origine sera relancé.
+Toutefois ceci est vrai seulement si &lslon; est en arrêt pendant une période
+assez longue; un arrêt de quelques secondes ne génère pas de problèmes.</para> </answer>
</qandaentry>
<qandaentry>
-<question><para> Y a-t-il des risques pour ce faire ? Quels en sont les avantages ?</para></question>
+<question><para> Y a-t-il des risques lorsque l'on arrête &lslon; ? Quels sont les avantages ?</para></question>
-<answer><para> En bref, si votre <command>COPY_SET</command> prend environ 18h pour s'exécuter
-finalement, ce n'est pas un grand sacrifice d'arrêter quelques moments un &lslon;
-ou peut-être même durant un cycle<emphasis>all</emphasis> de &lslon;s. </para> </answer>
+<answer><para> En bref, si un <command>COPY_SET</command> qui dure 18h n'est pas en cours d'exécution
+, alors ce n'est pas un grand sacrifice d'arrêter un &lslon; pendant quelques instants, ni même
+de relancer <emphasis>tous</emphasis> les &lslon;s. </para> </answer>
</qandaentry>
</qandadiv>
<qandadiv id="faqconfiguration"> <title> &slony1; FAQ: Problèmes de configuration </title>
<qandaentry>
-<question><para>Slonik tombe en erreur - ne peut pas charger les librairies &postgres; -
+<question><para>Slonik tombe échoue lors du chargement des librairies &postgres; :
<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
-<para> Lorsque j'exécute un simple script de configuration, j'obtiens un message similaire à
-:
+<para> Lorsque j'exécute un simple script de configuration, j'obtiens un message similaire à :
<command>
stdin:64: PGRES_FATAL_ERROR load '$libdir/xxid'; - ERROR: LOAD:
@@ -690,189 +576,148 @@
<answer><para> Evidemment, vous n'avez pas accès à la librairie
<filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
-où l'instance &postgres; est en usage. Notez que le composant &slony1;doit être installé sur le noyau du &postgres;
-pour <emphasis>chacun des noeud</emphasis> et pas seulement sur le noeud d'origine.</para>
+que l'instance &postgres; utilise. Notez que les composants &slony1; doivent être installés avec le noyau du &postgres;
+sur <emphasis>chacun des noeuds</emphasis> et pas seulement sur le noeud d'origine.</para>
-<para>Cela peut également venir du fait d'une disparité entre les binaires
-du noyau &postgres; et celui du noyau de &slony1;. Si vous avez manuellement compilé &slony1;
-vous même, sur une machine où il y a plusieurs noyau de
-&postgres; <quote>se trouvant autour,</quote> il est possible
-que les binaires slon ou lslonik demande de charger une librairie qui n'est pas accessible
-actuellement dans les répertoires du noyau de &postgres; gérant le cluster.</para>
+<para>Cela peut également venir du fait d'une disparité entre les binaires du noyau &postgres; et celui du noyau de &slony1;. Si vous avez manuellement compilé &slony1; par vous-même, sur une machine où il y a plusieurs versions de &postgres;, il est possible que les binaires slon ou lslonik demande de charger une librairie qui n'est pas accessible dans les répertoires des librairies de la version de &postgres; utilisée.</para>
-<para>Court et concis: Ceci indique un besoin de <quote>auditer</quote>
-quel mode d'installation de &postgres; et de &slony1; vous avez en place sur vos machines.
-Malheureusement,n'importe quelle incompatibilité peut faire remonter ce genre
-de soucis. Voir aussi<link linkend="threadsafety">
-sécurité des thread </link> à propos de la gestion des thread sur Solaris.
-...</para>
+<para>En deux mots : Ceci indique que vous devez <quote>auditer</quote>
+comment ont été installés les instances &postgres; et de &slony1; qui sont en place sur la machine. Malheureusement, n'importe quelle incompatibilité peut faire remonter ce genre d'erreur. Voir aussi <link linkend="threadsafety"> sécurité des threads </link> à propos de la gestion des threads sur Solaris.</para>
-<para> La situation sera plus simple si vous aviez un seul noyau de &postgres; installé par serveur
-dans ce cas il n'y aura pas d' <quote>incompatibilité
-de chemins</quote> dans lequel les composants de &slony1; sont installés.</para>
-Si vous avez une installation multiple,
-vous devrez vous assurez de la compatibilité de la bonne
-versions de &slony1; associé à la bonne version du noyau de
-&postgres;. </answer></qandaentry>
+<para> La situation est plus simple si vous avez une seule version de &postgres; installée par serveur; dans ce cas il n'y aura pas d' <quote>incompatibilité de chemins</quote> là ou les composants de &slony1; sont installés. Si vous avez une installation multiple,
+vous devrez vous assurez que la bonne version de &slony1; est associée
+à la bonne version du noyau de &postgres;. </para></answer></qandaentry>
<qandaentry>
-<question> <para>J'essai de créer un cluster dont le nom contient un "-".
-Cela ne marche pas!.</para></question>
+<question> <para>J'essaie de créer un cluster dont le nom contient un "-". Cela ne marche pas.</para></question>
-<answer><para> &slony1; Utilise les même règles de nommage que &postgres;
-alors confirmation, il ne faudra pas utiliser un "-"
-dans le nom.</para>
+<answer><para> &slony1; utilise les mêmes règles de nommage que &postgres;, donc vous ne devrize pas utiliser un "-"
+dans les identifiants.</para>
-<para> Vous pouvez tenter de mettre des simples <quote>quotes</quote> pour l'identifiant
-,mais vous allez vous exposer à des soucis, qui pourront surgir à tout moment.</para>
+<para> Vous pouvez tenter de mettre des simples <quote>quotes</quote> pour l'identifiant, mais vous allez vous exposer à des soucis, qui pourront surgir à tout moment.</para>
</answer>
</qandaentry>
<qandaentry>
-<question><para>La commande ps affiche le mot de passe en claire</para>
+<question><para>La commande ps affiche le mot de passe en clair</para>
-<para> Si je lance une commande <command>ps</command>, tout le monde,
+<para> Avec la commande <command>ps</command>, tout le monde,
peut voir le mot de passe qui a été fourni à la ligne de commande.</para></question>
-<answer> <para>Conservez vous mot de passe en dehors de la configuration Slony, en les mettant dans
-des fichiers <filename>$(HOME)/.pgpass.</filename></para>
+<answer> <para>Conservez le mot de passe en dehors de la configuration Slony, en les mettant dans le fichier <filename>$(HOME)/.pgpass.</filename></para>
</answer></qandaentry>
<qandaentry>
-<question><para>Sommaire de questions posées sur namespace
+<question><para>Indexes dont le nom contient le namespace
<programlisting>
set add table (set id = 1, origin = 1, id = 27,
- full qualified name = 'nspace.some_table',
- key = 'key_on_whatever',
- comment = 'Table some_table in namespace nspace with a candidate primary key');
+ full qualified name = 'nspace.ma_table',
+ key = 'clef_sur_une_colonne',
+ comment = 'une table ma_table dans le namespace nspace avec une clef primaire');
</programlisting></para></question>
<answer><para> Si vous avez <command> key =
-'nspace.key_on_whatever'</command> la demande
-<emphasis>echoura</emphasis>.</para>
+'nspace.clef_sur_une_colonne'</command> la requête
+<emphasis>échoura</emphasis>.</para>
</answer></qandaentry>
<qandaentry>
-<question> <para> La réplication a été retardée, et il semble que les interrogations pour restituer des données
-depuis <xref linkend="table.sl-log-1"/>/<xref
-linkend="table.sl-log-2"/> prennent beaucoup de temps en indiquant quelques demande de
-<command>SYNC</command>s. </para>
+<question> <para> La réplication est retardée, et il semble que les requêtes sur les tables
+<xref linkend="table.sl-log-1"/>/<xref
+linkend="table.sl-log-2"/> prennent beaucoup de temps alors qu'il n'y a que quelques événements <command>SYNC</command>s. </para>
</question>
-<answer> <para> Jusqu'à la version 1.1.1, la table <xref
-linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possédait seulement un index, et si plusieurs jeu de réplication
-se mettaient en route en même temps, quelques colonnes dans l'indexe n'était pas très discriminent pour la manière d'accès.
+<answer> <para> Jusqu'à la version 1.1.1, les tables <xref
+linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,possédaient seulement un index, et lorsque il y avait plusieurs ensembles de réplication, quelques colonnes dans l'index n'était pas assez très discriminantes.
Si l'index ne contient pas la colonne<function> log_xid</function>, il est conseillé de l'ajouter. Voir le script
-<filename>slony1_base.sql</filename> pour regarder la manière de créer un indexe.
+<filename>slony1_base.sql</filename> pour regarder la manière de créer cet index.
</para>
</answer>
</qandaentry>
<qandaentry><question> <para> J'ai besoin de renommer une colonne qui figure dans la clef
-primaire pour l'une de mes tables répliquées. L'opération s'avère un peu dangereuse, est-ce vrai ?
-Aurai-je à la recréer en dehors de la réplication ?</para>
+primaire pour l'une de mes tables répliquées. L'opération est un peu dangereuse, n'est-ce pas ?
+Je dois retirer la table de la réplication puis la replacer, c'est bien ça ?</para>
</question>
-<answer><para> Affirmatif, c'est un scénario qui fonctionne proprement. &slony1; fait un usage intensif de
-clef primaire, mais actuellement c'est ainsi et on espère une gestion intégrée et transparente prochainement</para>.
+<answer><para> En fait, cette opération fonctionne proprement. &slony1; fait un usage intensif des
+clefs primaires, mais en pratique ce type d'opération peut se faire de manière transparente.</para>.
-<para> Supposez que vous souhaiter renommer une colonne, comme dans uns script sql, on utiliserais la
+<para> Supposons que vous souhaiter renommez une colonne, avec la
commande DDL suivante<command> alter table accounts alter column aid rename to cid; </command> Ceci
-permet de renommer la colonne dans la table; elle permet de manière
-<emphasis>transparente</emphasis> de effectuer la mise à jour dans clef primaire qui contient la colonne en question.
-Le résultat est que ce genre de changement s'effectue simultanément sur les différents composants, du noeud.</para>
+permet de renommer la colonne dans la table; elle permet de mettre à jour <emphasis>simultanément</emphasis> l'index de la clef primaire. Le résultat est que ce genre de changement s'effectue simultanément sur un noeud donné.</para>
-<para> Dans l' <emphasis>ideal</emphasis> et pour bien faire les choses
-il aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer la modification
-en étant sur que le bon changement s'applique aux bons noeuds.</para>
+<para> Dans l' <emphasis>ideal</emphasis> et pour bien faire les choses il aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer la modification au moment sur chaque noeud.</para>
-<para> Pour la clarté des choses, tant que la modification commence par la partie répliquée et bien avant les abonnés,
-il n'y aura pas de cassure irrémédiable. Se retrouver avec quelques évènements de
-<command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, n'est pas un problème car ils vont se dérouler
-sans difficulté... Par contre si le changement est signalé d'abord par un abonné, alors
-point that the first update to the table is drawn in by a subscriber,
-<emphasis>ce</emphasis> sera le point de départ pour que
-<command>SYNC</command> tombe en erreur, puisque le fournisseur indiquera une
-<quote>nouvelle</quote> colonne alors que l'abonné connait toujours
-ses <quote>anciens</quote> formats. En appliquant la modification à postériori chez l'abonné, la commande
-<command>SYNC</command>, peut retrouver le
-<quote>nouveau</quote> nom de colonne et fonctionner sans plantage .
+<para> Toutefois ce n'est pas forcément nécessaire. Tant que la modification est appliquée sur le noeud origine avant d'être effectuée sur les abonnés, il n'y aura pas de cassure irrémédiable. Certains évènements <command>SYNC</command> qui n'incluent pas la table sur laquelle il y a la modification, pourront fonctionner sans problème... Par contre lorsqu'une mise à jour de la table est effectué sur un abonné, alors les événements <command>SYNC</command> vont échouer, puisque le fournisseur indiquera une <quote>nouvelle</quote> colonne alors que l'abonné connait toujours les <quote>anciennes</quote>. Dès que l'on appliquera la modification de la clef chez l'abonné, les évenements
+<command>SYNC</command> seront retraités et le <quote>nouveau</quote> nom de colonne sera présent et tout fonctionnera sans plantage .
</para> </answer></qandaentry>
<qandaentry id="v72upgrade">
-<question> <para> J'ai un &postgres; version 7.2 que je souhaite
-<emphasis>vraiment, vraiment</emphasis> employer avec &slony1; Que faut-il faire pour une migration en
-version 8.2 ? Quel est l'implication pour récupérer &slony1; afin de les exploiter ensemble?</para>
+<question> <para> J'ai un &postgres; version 7.2 et je souhaite
+<emphasis>vraiment</emphasis> utiliser &slony1; le migrer en
+version 8.0. Que faut-il faire pour que &slony1; fonctionne ?</para>
</question>
-<answer> <para> Voici l'écrit d'un certain Rod Taylor sur le sujet ...
+<answer> <para> Voici Rod Taylor écrit sur le sujet ...
</para>
<para> Voici ce dont approximativement vous avez besoin:</para>
<itemizedlist>
-<listitem><para>Prendre les formulaire 7.3 et de mes copier en 7.2 -- ou bien de
- mettre en dur 7.3 dans vos formulaire </para></listitem>
-<listitem><para>Supprimer toute trace de schémas dans le code sql de vos formulaires.
- Sommairement je remplace "." par "-". </para></listitem>
-<listitem><para> Le bloc de travail relatif aux models de données XID ainsi qu’aux fonctions.
- Par exemple, Slony crée des CASTs pour the xid en xxid et vice versa -- mais
- la 7.2 ne peut pas crée de nouveau casts et dans ce cas vous êtes obligé de le modifier à la main.
- Je rappelle la création d'une classe d'opérateur ainsi que l'édition de certaines fonctions. </para></listitem>
-<listitem><para>sl_log_1 aura de grave problème de performance quelque soit le volume de données.
- Ceci exige qu'un certain nombre d'indexe soient positionnés pour optimiser les interrogations en 7.2. 7.3
- et supérieur. </para></listitem>
-<listitem><para> Ne pas s' embeter à essayer de travailler en séquence. Faites les à la main
- en utilisant pg_dump et grep. </para></listitem>
+<listitem><para>Prendre les templates 7.3 et de les copier en 7.2 -- ou bien écrire en dur la version de vos templates </para></listitem>
+<listitem><para>Supprimer toute trace de schémas dans le code sql de vos templates. Concrètement j'ai remplacé les "." par "-". </para></listitem>
+<listitem><para> Pas mal de travaux sur les types et fonctins XID.
+Par exemple, Slony crée des CASTs pour la conversion xid vers xxid et vice versa -- mais la 7.2 ne peut pas créer de nouveaux casts et dans ce cas vous êtes obligé de le modifier à la main.
+Je me rappelle avoir créé une classe d'opérateur et modifié certaines fonctions. </para></listitem>
+<listitem><para>sl_log_1 aura de graves problèmes de performance quelque soit le volume de données. Ceci exige qu'un certain nombre d'index soient positionnés pour optimiser les interrogations en 7.2, 7.3 et supérieur. </para></listitem>
+<listitem><para> Ne pas s'embeter à essayer de faire fonctionner les séquences. Faites les à la main en utilisant pg_dump et grep. </para></listitem>
</itemizedlist>
-<para> Bien sûr, une fois que ces pre-requis terminés, on n'est pas encore compatible avec
-le Slony standard. Ainsi ou bien, vous devez au moins implémenter la 7.2 de manière artisanale
-du moins, forcer slony à travailler sans les schémas dans la nouvelle version versions de &postgres;
-ainsi le dialogue entre les deux peut être établi.
+<para> Bien sûr, une fois que ces pre-requis terminés, on n'est pas encore compatible avec le Slony standard. Ainsi ou bien, vous devez au moins modifier la version 7.2 de manière moins artisanale
+, ou vous modifiez slony pour qu'il fonctionne sans les schémas avec les nouvelles versions de &postgres; afin qu'ils puissent
+dialoguer.
</para>
<para> Juste après le déroulement de la procédure de migration de 7.2 vers 7.4,
-on peut désinstaller la version bidouillée de Slony (à la main encore pour la majeur partie), et démarrer la migration
-de 7.2 à 7.4 sur les différentes machines en utilisant un Slony standard.
-Ceci permettant de s'assurer sur la fiabilité d'un catalogue système qui avait subi des changement manuels.
+on peut désinstaller la version bidouillée de Slony (à la main encore pour la majeure partie), et démarrer la migration
+de 7.2 à 7.4 sur les différentes machines en utilisant un Slony standard. Ceci afin de s'assurer qu'on ne conserve pas les catalogues systèmes qui ont subi des changements manuels.
</para>
-<para> Tout cela pour dire, que nous migrons quelque centaine de GO de données,
-de 7.2 a 7.4 en espace de 30 minutes. (contre 48 heures auparavant annoncées myeneant un dump et
-restore) sans pertes de données.
+<para> Ceci étant dit, nous avons migré quelques centaines de Go de données,
+de 7.2 à 7.4 avec une coupure de service de 30 minutes. (contre 48 heures de dump/restore) et sans pertes de données.
</para>
</answer>
-<answer> <para> Ceci vous dresse un éventail assez laid qualifié de
-<quote>bidouille</quote> qu'il faut admettre entrer dans le périmètre de production.
-Si quelqu'un est intéressé pour le transformer en
-<quote>tâche de production</quote>, il y aura un sens dans ce cas de s'appuyer sur
+<answer> <para> Ceci vous dresse un éventail assez laid des
+<quote>bidouilles</quote> qu'il faut faire entrer dans le périmètre de production.
+Si quelqu'un est intéressé pour
+<quote>industrialiser</quote> cette tache, il vaut mieux s'appuyer sur
&slony1; en version 1.0, avec un maître mot de ne
<emphasis>pas</emphasis> essayer de le rendre pérenne, étant donnée sa durée de vie limitée.</para>
<para> Vous devriez seulement adapter cette solution que si vous êtes à l'aise avec
-&postgres; et &slony1; et que de mettre la main au code ne vous fait pas peur. </para> </answer>
+&postgres; et &slony1; et si mettre la main au code ne vous fait pas peur. </para> </answer>
</qandaentry>
<qandaentry>
-<question> <para> J'avais un réseau <quote>pas performant</quote> qui m'obligeais à utiliser
- <xref linkend="stmtfailover"/> un basculement sur un noeud secondaire.
+<question> <para> J'ai subit une <quote>avarie réseau</quote> qui m'a obligé à utiliser
+ <xref linkend="stmtfailover"/> pour basculer sur un noeud secondaire.
Le plantage n'était pas causé par un problème de corruption de donnée venant du disque,
-Pourquoi serais-je obligé de reconstruire depuis le début, le noeud planté ? </para></question>
+Pourquoi serais-je obligé de reconstruire le noeud planté ? </para></question>
<answer><para> Le rôle de <xref linkend="stmtfailover"/> est d'
<emphasis>abandonner</emphasis> le noeud planté, et par conséquence il n'a plus de
charge générée par l'activité de &slony1;. Plus le temps passe plus le serveur planté se désynchronise.</para></answer>
-<answer><para> L'<emphasis>énorme</emphasis> problème afin de restaurer le serveur planté,
-est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager endors.
+<answer><para> L'<emphasis>énorme</emphasis> problème pour restaurer le serveur planté,
+est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager en dehors.
Vous ne pouvez pas non plus les rejouer, car elles vont être conflictuelles, car à moitié en place.
En tout cas vous avez une sorte de corruption <quote>logique</quote>de donnée, qui n'est jamais causée par une erreur disque.
dite <quote>physique.</quote>
</para></answer>
-<answer><para> Comme cela a été abordé en <xref linkend="failover"/>, utiliser <xref
-linkend="stmtfailover"/> revient à accepter comme <emphasis>dernier
-ressort</emphasis> tant qu'il implique d'abandonner le noeud d'origine pour cette corruption.</para></answer>
+<answer><para> Comme cela a été abordé dans la section <xref linkend="failover"/>, <xref
+linkend="stmtfailover"/> doit être utilisé en <emphasis>dernier
+recourt</emphasis> car cela implique d'abandonner le noeud d'origine pour cette corruption.</para></answer>
</qandaentry>
@@ -884,8 +729,8 @@
DETAIL: Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
</screen>
-<para> Par la suite l'erreur est suivie par un ensemble d'<xref
-linkend="slon"/> arrêt: de syncs:</para>
+<para> Par la suite l'erreur est suivie par un ensemble de SYNCs en échec
+tandis que <xref linkend="slon"/> s'arrête :</para>
<screen>
DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -902,19 +747,19 @@
</question>
-<answer><para> Si vous regardez les journaux de &lslon; à l'arrêt avec des erreurs due à cet effet
-<emphasis>d'arrêt</emphasis>, vous auriez besoin de revenir en arrière en ignorant une partie de
-ces journalisation,
-<emphasis>en attendant</emphasis> après le redémarrage du serveur en erreur de trouver la cause d'origine.</para></answer>
+<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
+des événements ont été ignorés, vous devez remonter dans le journal
+<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
+sur l'origine du problème.</para></answer>
<answer><para> Dans ce cas particulier, l'erreur est due à la commande
<xref linkend="stmtstorepath"/> qui n'est pas encore répercutée sur le noeud 4 en attendant la propagation
de <xref linkend="stmtsubscribeset"/> command</para>
-<para>Ceci démontre encore un autre exemple où l'approximatif ne devra pas prendre le dessus,
-et que on doit avec assurance vérifier le bon fonctionnement des choses
-<emphasis>avant</emphasis> de suggérer un changement de la configuration.
-</para></answer>
+<para>Cet exemple démontre à nouveau qu'il ne faut pas se précipiter;
+vous devez vous assurer que tout fonctionne correctement
+<emphasis>avant</emphasis> de poursuivre les changements de configuration.
+</para></answer>
</qandaentry>
@@ -926,10 +771,11 @@
Que puis-je faire? </para></question>
<answer><para> Vous avez besoin d'utiliser <xref linkend="stmtsubscribeset"/> afin de modifier les abonnements
- de ces serveurs abonnés, que leurs fournisseur <emphasis>sera</emphasis> indisponible durant une période maintenance.</para>
+ de ces serveurs abonnés et les réorienter vers un fournisseur qui <emphasis>sera</emphasis> disponible durant la période de maintenance.</para>
-<warning> <para> Que vous avez <emphasis>omis</emphasis> de faire <xref
-linkend="stmtunsubscribeset"/>; pour que vous soyez obligé de recommencer à rafraîchir les noeuds depuis le début.
+<warning> <para> Il <emphasis>ne faut pas</emphasis> faire <xref
+linkend="stmtunsubscribeset"/>; car vous seriez obligé de
+recharger toutes les données à partir de zéro.
</para></warning>
</answer>
@@ -937,16 +783,16 @@
<qandaentry>
<question><para> Après la notification d'un abonnement auprès
-<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en erreur, et commençant des messages d'erreurs
-avec :</para>
+<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en panne, et affiche des messages d'erreurs
+du type :</para>
<screen>
ERROR remoteWorkerThread_1: "begin transaction; set transaction isolation level serializable; lock table "_livesystem".sl_config_lock; select "_livesystem".enableSubscription(25506, 1, 501); notify "_livesystem_Event"; notify "_livesystem_Confirm"; insert into "_livesystem".sl_event (ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3, ev_data4 ) values ('1', '4896546', '2005-01-23 16:08:55.037395', '1745281261', '1745281262', '', 'ENABLE_SUBSCRIPTION', '25506', '1', '501', 't'); insert into "_livesystem".sl_confirm (con_origin, con_received, con_seqno, con_timestamp) values (1, 4, '4896546', CURRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR: insert or update on table "sl_subscribe" violates foreign key constraint "sl_subscribe-sl_path-ref"
DETAIL: Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
</screen>
-<para> Ceci est suivi plus tard par une série d'erreur de syncs puisque le <xref
-linkend="slon"/> est à l'arrêt:
+<para> Ceci est suivi plus tard par une série d'erreur de syncs tandis que le <xref
+linkend="slon"/> s'arrête :
<screen>
DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -963,47 +809,48 @@
</para></question>
-<answer><para> Si lors d'un arrêt, vous voyez dans le journal d'un &lslon;
-<emphasis>des nouveaux évènements ignorés dus à l'arrêt</emphasis> ,
-c'est le cas parlant où il faut revenir une étape en arrière
-<emphasis>avant</emphasis> l'arrêt pour voir l'origine de l'erreur.
-</para></answer>
+<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
+des événements ont été ignorés, vous devez remonter dans le journal
+<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
+sur l'origine du problème.</para></answer>
-<answer><para> Dans ce cas particulier, le problème était que certain
- <xref linkend="stmtstorepath"/> commandes n'ont pas été transmises aux noeud 4 avant <xref linkend="stmtsubscribeset"/>
- la commande soit propagée. </para>
+<answer><para> Dans ce cas particulier, le problème était que certaines commandes
+ <xref linkend="stmtstorepath"/> n'ont pas été transmises aux noeud 4 avant que
+le commande <xref linkend="stmtsubscribeset"/> ne soit propagée. </para>
<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
-;vous devrez avec certitude, constater le disfonctionnement
+; vous devez être sur que tout fonctionne bien
<emphasis>avant</emphasis> de faire de nouveau changement de configuration.
</para></answer>
</qandaentry>
<qandaentry>
-<question> <para> Est-ce que dans une configuration globale, l'ordre dans lequel, on traite les tables
-est important ?</para>
+<question> <para> Est-ce que l'ordre dans une ensemble de réplication est important ?</para>
</question>
-<answer> <para> La plupart de temps il ne l'est pas. Vous devrez adapter un ordre selon lequel
-les tables <quote>maîtres</quote> sont mises à jour avant celles de <quote>détails</quote>
-en fonction de la relation de clef étrangère qui les relie; ceci ne sera <emphasis>pas exigé</emphasis> si sur le noeud abonné,
+<answer> <para> La plupart de temps il ne l'est pas. On pourrait imaginer qu'il faille
+déclarer les tables <quote>mères</quote> avant leurs <quote>filles</quote>
+en fonction des relations de clefs étrangères qui les relient;
+mais ce n'est <emphasis>pas nécessaire</emphasis> si sur le noeud abonné,
on a pris le soin, de désactiver les déclencheurs.
</para>
</answer>
+
<answer> <para>(Les commentaires de Jan Wieck:) L'ordre des ID des tables
a une importance uniquement lors d'une opération de <xref linkend="stmtlockset"/> en préparation de basculement.
Si l'ordre est différent de celui selon lequel les applications obtiennent des verrous,
-ces derniers peuvent se transformer en verrous mortels et par conséquent faire tomber l'application ou bien
+ces derniers peuvent se transformer en verrous interbloqués ("deadlock") et par conséquent faire tomber l'application ou bien
<application>slon</application>.
</para>
-<answer><para> (David Parker) Dans un autre cas, j'ai lancé l'opération où l'ordre des
-tables avait une importance : en présence des tables avec les contraintes d'intégrité référentielles.
-Si une table détail se présente avant celle de maître, alors le serveur abonné, supprime son
-contenu, avant qu'elle soit à nouveau rafraîchie, car la logique de la commande
-<command>copy_set</command> vaut que <command>delete</command>,
-ne soit pas un <command>delete only</command>, or la suppression des données de la table maître, impose bien la suppression de celle
-de détail.
+<answer><para> (David Parker) J'ai renconté un autre cas où l'ordre des
+tables avait une importance : avec l'héritage.
+Si une table fille se présente avant le table mère, alors l'abonnement initial provoquera la suppression du
+contenu de la table, alors qu'elle aura probablement reçue des données.
+En effet la logique de la commande
+<command>copy_set</command> effectue un <command>delete</command>,
+et non pas un <command>delete only</command>, ce qui implique que la suppression des données de la table maître provoquera la suppression de celle
+de la table fille.
</para>
</answer></answer>
@@ -1011,13 +858,11 @@
<qandaentry>
-<question><para> Si votre script <xref linkend="slonik"/> ressemble à quelque chose comme le suivant,
-il peut tomber en erreur et ne jamais se terminer, car vous n'avez pas
-<command>wait pour ev la mise à jour à nouveau. Bien sûr Of course, as mentioned
-above, it could be faster to drop the node and recreate it than to let
-ent</command> à l'intérieur d'un bloc de
+<question><para> Si votre script <xref linkend="slonik"/> ressemble à quelque chose à celui ci-dessous,
+il peut tomber en erreur et ne jamais se terminer, car on ne peut pas utiliser
+<command>wait for event</command> à l'intérieur d'un bloc
<command>try</command>. Un bloc de <command>try</command> est exécuté comme une seule et même transaction,
-et l'évènement pour lequel vous êtes en attente, peut jamais avoir lieu
+et l'évènement pour lequel vous êtes en attente, peut ne jamais avoir lieu
dans le scope de la transaction.</para>
<programlisting>
@@ -1039,7 +884,7 @@
</programlisting></question>
<answer><para> Vous ne devez pas invoquer<xref linkend="stmtwaitevent"/>
-à l'intérieur d'un bloc de<quote>try</quote>.</para></answer>
+à l'intérieur d'un bloc <quote>try</quote>.</para></answer>
</qandaentry>
@@ -1057,15 +902,15 @@
</para>
<para>Le contournement est de créer un <emphasis>AUTRE</emphasis>
-jeu de table, d'y rajouter la table souhaitée, brancher les serveurs abonnés au "jeu 1" sur le nouveau qu'on vient de créer,et en suite de
-fusionner les 2 jeux ensemble.</para>
+ensemble de réplication, d'y rajouter les tables souhaitées, brancher les serveurs abonnés l'ensemble de réplication 1 sur le nouveau qu'on vient de créer,et en suite de
+fusionner les 2 ensembles.</para>
</answer></qandaentry>
<qandaentry>
<question><para>
ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
-<para>En essayant de monter un deuxième jeu de réplication, j'ai ce message :I tried setting up a second replication set, and got the following error:
+<para>En essayant de monter un deuxième ensemble de réplication, j'ai ce message :
<screen>
stdin:9: Could not create subscription set 2 for oxrslive!
@@ -1073,29 +918,31 @@
CONTEXT: PL/pgSQL function "setaddtable_int" line 71 at SQL statement
</screen></para></question>
-<answer><para> Les identifaiants des tables utilisées dans <xref linkend="stmtsetaddtable"/>
-demande d'être unique <emphasis>A TRAVERS TOUT LE JEU</emphasis>. Thus,
-you can't restart numbering at 1 for a second set; if you are
-numbering them consecutively, a subsequent set has to start with IDs
-after where the previous set(s) left off.</para> </answer>
+<answer><para> Les identifiants des tables utilisées dans <xref linkend="stmtsetaddtable"/>
+doivent être uniques <emphasis>A TRAVERS TOUT LES ENSEMBLES DE REPLICATION</emphasis>.
+En conséquence, vous en pouvez pas reprendre la numérotation à zéro à l'intérieur
+d'un deuxième ensemble de réplication; Si vous les numérotez de manière
+consécutive, le prochain ensemble de réplication doit commencer
+avec un identifiant supérieur à ceux de l'ensemble précédent.
+</para> </answer>
</qandaentry>
+
<qandaentry>
-<question><para> L'un de mes serveurs tombe en erreur sur (&lslon; / postmaster was
-down) et dont aucune notification depuis plusieurs jours.Maintenant lorsque &lslon; sur ce noeud démarre,
-ll tourne durant cinq minutes, puis s'arrête,
+<question><para> L'un de mes noeudss est tombé (&lslon; ou le postmaster était arrêté) et personne ne s'en est aperçu pendant plusieurs jours.
+Maintenant lorsque &lslon; démarre sur ce noeud, il tourne durant cinq minutes, puis s'arrête,
avec l'erreur suivante : <command>ERROR: remoteListenThread_%d: timeout
-for event selection</command> What's wrong, and what do I do? </para>
+for event selection</command> Quel est le problème ? Que faire ? </para>
</question>
<answer><para> Le problème est que le port d'écoute de ce processus (dans
-<filename>src/slon/remote_listener.c</filename>) arrive à une expiration de temps, lors il tente
-de déterminer quels est l'évènement à reprendre sur ce noeud.Par défaut
-le délai d'expiration de cette interrogation est de 5 minutes; si la reprise contient plus d'évènement,
+<filename>src/slon/remote_listener.c</filename>) arrive à une expiration de temps, lorsqu'il tente
+de déterminer quel est l'évènement à reprendre sur ce noeud. Par défaut
+le délai d'expiration de cette interrogation est de 5 minutes; si la reprise contient les évènements pour une durée de plusieurs jours,
cela prendra beaucoup plus de temp.
</para> </answer>
-<answer><para> La réponse à cette question pour les versions de &slony1; antérieur à 1.1.7, 1.2.7, et à 1.3, serait de dire
+<answer><para> La réponse à cette question pour les versions de &slony1; antérieures à 1.1.7, 1.2.7, et à 1.3, serait de dire
d'augmenter le délai d'expiration dans
<filename>src/slon/remote_listener.c</filename>, de recompiler &lslon;, et enfin de ressayer. </para> </answer>
@@ -1105,104 +952,93 @@
</para> </answer>
<answer><para> Dans les version récentes de &slony1;, il y a une nouveau paramètre appelé :<xref
-linkend="slon-config-remote-listen-timeout"/>;qui permet de modifier le délai d'expiration
+linkend="slon-config-remote-listen-timeout"/>; qui permet de modifier le délai d'expiration
et de relancer les mises à jour. Bien sûr, comme il a été mentionné ci-dessus, il est plus efficace dans ce cas
de supprimer et de recréer le noeud, que d'essayer de rattraper les mises à jours. </para> </answer>
</qandaentry>
</qandadiv>
-<qandadiv id="faqperformance"> <title> &slony1; FAQ: Performance Issues </title>
+
+
+<qandadiv id="faqperformance"> <title> &slony1; FAQ: Problèmes de Performances </title>
+
<qandaentry id="longtxnsareevil">
-<question><para> Replication has been slowing down, I'm seeing
-<command> FETCH 100 FROM LOG </command> queries running for a long
-time, <xref linkend="table.sl-log-1"/> is growing, and performance is,
-well, generally getting steadily worse. </para>
+<question><para> La réplication ralentit, je vois des requêtes <command> FETCH 100 FROM LOG </command> très longues , la table <xref linkend="table.sl-log-1"/> grossit, et les performances se dégradent de manière continue. </para>
</question>
-<answer> <para> Les causes de ce genre de choses sont multiples.
-Il y a une question évoquée par ce genre de pathologie, où le problème d'augmentation du volume dans
+<answer> <para> Il y a beaucoup de causes possibles pour ce genre de choses.
+Il s'agit de même genre de pathologies qui entrainent l'augmentation du volume dans
<link linkend="pglistenerfull">
-&pglistener; est dû au fait que la purge via vaccume n'est pas exécutée.</link>
+&pglistener; lorsque la purge via vacuum n'est pas exécutée.</link>
</para>
-<para> Par rapprochement <quote> on peut avancer </quote>, pour cette augmentation de volume,
-est que une session existante sur le serveur rend le noeud
+<para> Par rapprochement <quote> on peut avancer </quote>, que cette augmentation de volume,
+est due à une session existante sur le serveur rend le noeud
<command>
-IDLE IN TRANSACTION </command> pour une durée infinie. </para>
+IDLE IN TRANSACTION </command> pour une durée très longue. </para>
-<para> La session ouverte peut avoir des effets négatifs,
-entraînant une dégradation de performances.</para>
+<para> Cette transaction ouverte peut avoir de multiples effets négatifs,
+chacun entrainant une dégradation de performances.</para>
<itemizedlist>
<listitem><para> Le fait de lancer un Vacuum sur la totalité des tables,
-&pglistener; y compris, ne va pas nettoyer les tuplets pour les transactions qui sont ouvertes et disponible, car elle
-viennent de démarrer. </para> </listitem>
+&pglistener; y compris, ne va pas nettoyer les tuples morts après après le début de la transaction en attente. </para> </listitem>
-<listitem><para> Le nettoyage des processus ne pourra pas se faire
-sur les entrées dans <xref linkend="table.sl-log-1"/> et <xref
+<listitem><para> Le processus de nettoyage ne pourra pas se supprimer les entrées dans <xref linkend="table.sl-log-1"/> et <xref
linkend="table.sl-seqlog"/>, qui entraîne par conséquence, une croissance
-de volume tant que les transactions persistent. </para>
+de volume tant que la transaction persiste. </para>
</listitem>
</itemizedlist>
</answer>
-<answer> <para> Vous pouvez surveiller, dans la base, ces conditions que si
-dans le fichier d'initialisation de &postgres; <filename> postgresql.conf </filename>
+<answer> <para> Vous pouvez surveiller cette situation, uniquement si
+dans le fichier de configuration de &postgres; <filename> postgresql.conf </filename>
le paramètre <envar>stats_command_string</envar> est positionner à vrai.
Dans ce cas, vous pouvez lancer une intérrogation sql comme suit :
<command> select * from pg_stat_activity where current_query like '%IDLE% in transaction';
-</command> dont le résultat vous donnent les activités relatives. </para> </answer>
+</command> dont le résultat vous donnent les transactions en activités. </para> </answer>
-<answer> <para> Vous devrez également être capable de rechercher
+<answer> <para> Vous pouvez également rechercher
les <quote> idle in transaction </quote> dans la table des processes
-ceux qui détiennent encore des transactions actives.
+ceux qui détiennent encore des transactions anciennes.
</para> </answer>
-<answer> <para> Il est aussi possible (quoique plus rare)que le problème soit causé par
-une transaction, qui pour d’autres raisons, est conservée comme ouverte et ceci pour une longue durée.
-La table <envar> query_start </envar> time in <envar>
-pg_stat_activity </envar> vous présentra les longues requêtes qui sont dans cet état. </para> </answer>
+<answer> <para> Il est aussi possible (quoique plus rare) que le problème soit causé par
+une transaction, qui pour d'autres raisons, est conservée comme ouverte et ceci pour une longue durée.
+La valeur <envar> query_start </envar> dans la table <envar>
+pg_stat_activity </envar> vous présentra les longues requêtes qui s'exécutent depuis longtemps. </para> </answer>
-<answer> <para> Il est prévue que &postgres; aie un paramètre d'expiration de
-délai, <envar> open_idle_transaction_timeout </envar>, qui permettrais
-de venir à bout des transactions dont le temps arrivent à échéance.
+<answer> <para> Il est prévu que &postgres; ait un paramètre d'expiration de
+délai, <envar> open_idle_transaction_timeout </envar>, qui permettrait de venir à bout des transactions après une certaine période.
-Le concept de connexion par pool, engendre ce genre de situation d'erreur.
-Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
-</link> </productname> devrait présenter des meilleurs alternatifs afin de mieux gérer les connexion partagée à
-travers la notion de 'pool'.
-Cela devrez faire diminuer les bugs rencontrés dans les applications
+Les pool de connexions peuvent engendrer ce genre de situation d'erreurs. Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
+</link> </productname> devrait présenter des meilleurs alternatives afin de mieux gérer les connexions partagées.
+Il existe des pools de connexions plus ou moins buggués dans les applications
Java ou PHP;si un nombre restreint de <emphasis> vrai </emphasis>
connections sont conservées dans<productname>pgpool</productname>, ceci va faire croire à la base,
-que en réalité les connexions de l'application reste dans un statut
-disponible et en activité, pour de
-
-J'avis lancé I have been running &slony1; on a node for a while, and am
-s heures durant.
+qu'en réalité les connexions de l'application reste dans un statut disponible et en activité, pendant des heures.
</para> </answer>
</qandaentry>
<qandaentry id="faq17">
-<question><para>Après une suppression de noeud, le fichier journal <xref linkend="table.sl-log-1"/>
-n'est plus purgé.</para></question>
+<question><para>Après une suppression de noeud, la table <xref linkend="table.sl-log-1"/>
+n'est plus purgée.</para></question>
-<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, comme
-le <quote>nettoyage</quote> du prend effet en oubliant les entrées des
- tables &slony1; <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
+<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, en effet
+le <quote>nettoyage</quote> du noeud oublie les vieilles entrées de la table <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
-<para> Le noeud ne s'occupe plus de mettre à jour des confirmations, comme quoi
-syncs vient de s'effectuer sur ce serveur, car il estime qu'il ne peut sans risque supprimer les entrées plus récentes
-que la dernière <xref linkend="table.sl-confirm"/> entrée, qui plutôt
-limite la capacité de purge des anciens fichiers journaux.</para>
+<para> Le noeud n'est plus présent et n'envoie plus les confirmations annonçant les syncs qui viennent de s'effectuer sur ce serveur,
+et le processus de nettoyage estime qu'il ne peut supprimer sans risque les entrées plus récentes
+que la dernière entrée de la <xref linkend="table.sl-confirm"/> , ce qui limite nettement la capacité de purge des anciens journaux.</para>
<para>Diagnostics: Exécuter les requêtes suivantes pour voir si il y a
-un résidus d'entrées en état de <quote>fantôme/obsolète/bloqué</quote> <xref
+un résidus d'entrées en état <quote>fantôme/obsolète/bloqué</quote> dans la table <xref
linkend="table.sl-confirm"/>:
<screen>
@@ -1218,11 +1054,9 @@
(6 rows)
</screen></para>
-<para>En version 1.0.5, la fonction <xref linkend="stmtdropnode"/>
+<para>Dans la version 1.0.5, la fonction <xref linkend="stmtdropnode"/>
purges les données dans <xref linkend="table.sl-confirm"/> pour le noeud qui quitte la configuration.
-Dans les versions plus anciennes, cposés par quelques tables du groupe de réplication ? Cela bloquerait invisiblement That would somewhat-invisibly
-eci demande une exécution manuelle.
-Supposons que l'identifiant du noeud soit 3, alors la requête sera la suivante :
+Dans les versions plus anciennes, il faut faire cela à la main. Supposons que l'identifiant du noeud soit 3, alors la requête serait la suivante :
<screen>
@@ -1236,24 +1070,18 @@
</screen></para>
<para>Une <quote>raisonnable diligence</quote> dicterait de commencer par
-<command>BEGIN</command>, voir le contenu de<command>SYNC</command> de se mettre à jour à l'origine, via le planificateur to be updated on the origin based on a
-
-<xref linkend="table.sl-confirm"/> avant,
+<command>BEGIN</command> et vérifier le contenu des <command>SYNC</command> dans la table <xref linkend="table.sl-confirm"/> avant de les purger, puis de valider l'opération par un <command>COMMIT</command>. Si
+vous supprimer par erreur les données d'un autre noeud, votre journée est perdue le temps de rattraper l'erreur commise.</para>
-Quelque noeud commencent à prendre du retard Some nodes start consistently falling behind
-en veillant à ce que seul les bons enregistrements
-sont purgés, et puis, seulement après avoir vérifier cette suppression, valider l'opération par une <command>COMMIT</command>. Si
-vous supprimer par erreur les données d'un autre noeud, votre journée est perdu le temps de rattraper l'erreur commise.</para>
-
<para>Vous aurez besoin d'exécuter cette opération, sur chaque noeud qui reste...</para>
-<para>A noter que dans la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
-de <xref linkend="table.sl-confirm"/> à deux endroits :
+<para>A noter qu'à partir de la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
+de <xref linkend="table.sl-confirm"/> à deux instants :
<itemizedlist>
<listitem><para> Lorsque un noeud est supprimé</para></listitem>
-<listitem><para> Au démarrage de chaque lancement de
+<listitem><para> Au démarrage de chaque
<function>cleanupEvent</function>, qui est l'évènement qui purge les vieilles données de
<xref linkend="table.sl-log-1"/> et de <xref
linkend="table.sl-seqlog"/></para></listitem> </itemizedlist></para>
@@ -1262,24 +1090,22 @@
<qandaentry>
-<question><para>Le <application>slon</application> se dépense un week-end entier hors de la
-commission [for some reason], et il prend énormément de temps pour exécuter un
+<question><para>Le <application>slon</application> était éteint ce week-end , et désormais il lui faut énormément de temps pour exécuter un
sync.</para></question>
-<answer><para> Vous pourriez jeter un coup d'oeil, sur les tables <xref
+<answer><para> Jetez un coup d'oeil, sur les tables <xref
linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,
-et voir brièvement si il y a réellement un énorme &slony1;
-encours d'exécution. Jusqu'au au moins la version 1.0.2, il faut qu'il y ait un
-&lslon; connecté pour que <command>SYNC</command> soit encours.</para>
+ pour voir brièvement si il y a une énorme transaction
+en cours d'exécution. Jusqu'à la version 1.0.2, il faut qu'il y ait un
+&lslon; connecté au noeud origine pour que les événements <command>SYNC</command> soient générés.</para>
-<para>Si cet évènement n'est pas généré, alors toute la mise à jour, et celle-ci jusqu'au prochain évènement va se faire
-à travers un énorme transaction &slony1;.</para>
+<para>Si aucun évènement n'est généré, alors toute les mises à jour jusqu'au prochain évènement seront aggrégées dans une énorme transaction &slony1;.</para>
-<para>Conclusion: Même si il n'y a pas d'abonné en cause,
-vous avez <emphasis>vraiment</emphasis> besoin d'un
-<application>slon</application> en fonctionnement pour entretenir le noeud source.</para>
+<para>Conclusion: Même si il n'y a pas d'abonné dans votre réplication,
+vous avez <emphasis>vraiment</emphasis> mettre en place un
+<application>slon</application> pour qu'il se connecte au noeud origine.</para>
-<para>&slony1; 1.1 fournit une procédure stockée qui permet aux comptes Synchros d'être
+<para>&slony1; 1.1 fournit une procédure stockée qui permet aux SYNCs d'être
mis à jour par le planificateur <application>cron</application>même si <xref
linkend="slon"/> ne tourne pas en tâche de fond.</para> </answer></qandaentry>
@@ -1294,69 +1120,61 @@
fetch 100 from LOG;
</screen></para></question>
-<answer><para> Ceci peut être un exemple type de &pglistener; (la table qui contient les données de
-<command>NOTIFY</command>)avec en abondance, des données obsolètes des tuplets mortes.
+<answer><para> Typiquement ceci peut se produire lorsque &pglistener; (la table qui contient les données de
+<command>NOTIFY</command>) est rempplie de tuple morts.
-Ce qui fait que l'évènement <command>NOTIFY</command> prend du temps,
+Ce qui fait que les évènements <command>NOTIFY</command> prend du temps,
et cause le ralentissement de plus en plus fort du noeud affecté.</para>
<para>Vous avez probablement besoin d'effectuer un <command>VACUUM FULL</command> sur
-&pglistener;, pour le nettoyer vigoureusement, et besoin de purger
+&pglistener;, pour le nettoyer vigoureusement, puis d'effectuer un vacuum simple sur
&pglistener; vraiment fréquemment. Une planification tous les cinq minutes fera l'affaire.</para>
-<para> Le démon Slon fait déjà une purge d'un groupe de table,et
+<para> Les démons Slon font déjà un vacuum sur beaucoup de tables ,et
<filename>cleanup_thread.c</filename> contient une liste de tables à nettoyer fréquemment de manière automatique.
-Dans &slony1; 1.0.2,&pglistener; ceci n'est pas inclus. Dans 1.0.5 et supérieur, il est purgé régulièrement,
+Dans &slony1; 1.0.2,&pglistener; n'est pas inclus. Dans la version 1.0.5 et supérieure, il est purgé régulièrement,
du coup ce problème n'a plus le lieu d'être. Dans la version 1.2,
-&pglistener; sera seulement utilisé quand le noeud reçoit périodiquement l'évènement,
+&pglistener; est seulement utilisé quand le noeud reçoit périodiquement l'évènement,
ce qui signifie que ce problème la plupart du temps disparaître même
en présence des transaction longues et lentes...</para>
<para>Il y a, cependant, toujours un scénario où ceci peut
-<quote>mordre toujours.</quote> Sous MVCC, vacuums ne peut pas supprimer des tuplets qui sont rendus
+<quote>surgir</quote>. Pour respecter le MVCC, les vacuums ne peuvent pas supprimer des tuples qui sont rendus
<quote>obsolètes</quote> à n'importe quel moment après le démarrage de la transaction la plus ancienne
qui reste encore ouverte. Les transactions longues, devront être évitées, car elles sont sources de soucis,
-même sur un serveur abonné.</para> </answer></qandaentry>
+même sur les noeuds abonnés.</para> </answer></qandaentry>
-<qandaentry> <question> <para> J'ai soumis un requête <xref
+<qandaentry> <question> <para> J'ai soumis une requête <xref
linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/>, et
-elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne mon
+elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne montre aucun avertissement et aucune erreur.
+ </para> </question>
-La <command>restitution depuis LOG</command> procède à lire query will draw
-trent
-pas d'qui est défini dans le fichier which is defined in the
-erreurs ni d'avertissement </para> </question>
-
-<answer> <para> Il est possible que vous soyez en train d'exécuter
-<application>pg_autovacuum</application>, et qu'l soit tombait sur des verrous
-posés par des tables dans le groupe de réplication ? Ceci voudra dire que de manière silencieuse
-ock &slony1; est bloqué d'effectuer des opérations qui exigent l'acquisition des <link
+<answer> <para> Peut-être que
+<application>pg_autovacuum</application> est en cours d'exécution, et qu'il a posé
+des verrous sur des tables dans l'ensemble de réplication ? Ceci entraine manière silencieuse le blocage de &slony1;
+en l'empêchant d'effectuer les opérations qui exigent l'acquisition des <link
linkend="locking"> exclusifs. </link> </para>
-<para> Vous pourriez vérifier ce genre de verrous à l'aide de cette requête :
+<para> Vous pourriez vérifier la présence de ce genre de verrous à l'aide de cette requête :
<command> select l.*, c.relname from pg_locks l, pg_class c
-where c.oid = l.relation ; </command> Un verrous
-<envar>ShareUpdateExclusiveLock</envar> va bloquer les opérations de &slony1;
-qui nécessitent leurs propres verrous exclusifs, qui sont probablement en attentes,
-marqués comme n'étant pas garantis. </para>
+where c.oid = l.relation ; </command> Un verrou
+<envar>ShareUpdateExclusiveLock</envar> peut bloquer les opérations de &slony1;
+qui nécessitent leurs propres verrous exclusifs, et les mettre en en attentes et marquées comme non-validées. </para>
</answer> </qandaentry>
<qandaentry>
-<question><para> Je remarque que dans les journaux d'un &lslon; l'état commute fréquent
-entre le <quote>vote</quote> démarré et arrêt.
-reporté fréquemment <quote>LISTEN - switch from polling mode to use
+<question><para> Je remarque que dans les journaux, qu'un &lslon; change d'état fréquemment : <quote>LISTEN - switch from polling mode to use
LISTEN</quote> et <quote>UNLISTEN - switch into polling
mode</quote>. </para> </question>
<answer><para> Les seuils pour commuter entre ces modes sont commandés par
-le paramètres de configuration <xref
-linkend="slon-config-sync-interval"/> et celui de <xref
+les paramètres de configuration <xref
+linkend="slon-config-sync-interval"/> et <xref
linkend="slon-config-sync-interval-timeout"/>; si la valeur du temps d'expiration
-(par défaut étant à 10000, impliquant 10s) est maintenu bas, facilite la situation pour que
-&lslon; décide de retourner à l'état <quote>listening</quote>.
+(par défaut étant à 10000, impliquant 10s) est maintenu bas, cela encourage le &lslon; à retourner dans l'état <quote>d'écoute</quote>.
Vous devriez augmenter cette valeur d'expiration de temps. </para>
</answer>
</qandaentry>
@@ -1365,26 +1183,25 @@
</qandadiv>
<qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs dans les versions anciennes</title>
<qandaentry>
-<question><para>Le process &lslon; processes entretenant mes abonnés devient énorme en taille
-, mettant en danger la ressource du système en terme de swap ainsi que le risque d'attendre la taille limite
-de 2GB par processe . </para>
+<question><para>Les processus &lslon; gérant mes abonnés devient énorme, mettant en danger la ressource du système en terme de swap ainsi que le risque d'atteindre la taille limite
+de 2GB par processus . </para>
<para> D'ailleurs, les données que je suis en train de répliquer,
ont une taille assez grande. Il y a des enregistrements dont la taille
-dépasse des dizaine de mega octets.Peut-être ceci n'est pas approprié ? </para> </question>
+dépasse des dizaine de megaoctets. Peut-être que c'est lié ? </para> </question>
<answer> <para> Oui, ces enregistrements volumineux sont à la racine du problème.
-L'explication vient du fait que &lslon; normalement procède par paquet de
- 100 enregistrement à la fois, lorsqu'un abonné fait des interrogation depuis le fournisseur.
+Le problème vient du fait que &lslon; normalement procède par paquet de
+ 100 enregistrements à la fois, lorsqu'un abonné charge des données depuis le fournisseur.
Ainsi si la taille moyenne des enregistrements est de
-is 10MB, ceci entraîne des données atteignant 1000MB qui sont en attente de
- <command>INSERT</command> ou de <command>UPDATE</command>
-à procéder par le processe &lslon;.</para>
+is 10MB, ceci entraîne des paquets de données atteignant 1000MB qui sont ensuite transformés en
+ <command>INSERT</command> ou en <command>UPDATE</command>
+dans la mémoire du processus &lslon;.</para>
-<para> Cela mène évidemment à &lslon; d'atteindre des tailles gigantesques. </para>
+<para> Cela mène évidemment &lslon; à des tailles gigantesques. </para>
-<para> Nombre d'enregistrement restitués par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
-défini par le fichier <filename>src/slon/slon.h</filename>. La partie extraite appropriée à ce paramètre est :
+<para> Le nombre d'enregistrement regroupés est controllé par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
+définie dans le fichier <filename>src/slon/slon.h</filename>. Voici un extrait de ce fichier contenant ce paramètre :
</para>
<programlisting>
@@ -1400,137 +1217,130 @@
</programlisting>
<para> Si vous rencontrez ce problème, vous devriez définir
- <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être réduit par un facteur de 10
- 10, et de recompiler ensuite &lslon;. Il y a deux
-définitions dont <envar> SLON_CHECK_CMDTUPLES</envar> qui laisse faire une certaine surveillance
-supplémentaire pour s'assurer que le abonnés ne sont pas tombé hors de la
-SYNC en regard du fournisseur. Par défaut, cette option est désactivée, ainsi il faudra prendre la deuxième option,
-afin de modifier la valeur par defeuillé, il faudra changer
-<envar> SLON_DATA_FETCH_SIZE </envar> pour remplacer 10 par 1. </para> </answer>
+ <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être le réduire par un facteur de 10, et recompiler ensuite &lslon;.
+L'activation de <envar> SLON_CHECK_CMDTUPLES</envar> permet de faire une surveillance
+supplémentaire pour s'assurer que les abonnés ne sont pas désynchronisés par
+rapport au fournisseur. Par défaut, cette option est désactivée, donc la modification par défaut consiste réduire la seconde définition de
+<envar> SLON_DATA_FETCH_SIZE </envar> en remplaçant 10 par 1. </para> </answer>
<answer><para> Dans la version 1.2, la configuration des valeurs de<xref
linkend="slon-config-max-rowsize"/> et de <xref
-linkend="slon-config-max-largemem"/> sont associées avec un nouveau algorithme
-qui change la logique des choses, plutôt que de restituer 100
-enregistrements à la fois.</para>
+linkend="slon-config-max-largemem"/> sont associées avec un nouvel algorithme
+qui change la logique des choses. Plutôt que de restituer 100
+enregistrements à la fois :</para>
<itemizedlist>
<listitem><para> La lecture de <command>fetch from LOG</command> se fera
par paquet de 500 enregistrements à la fois, tant que la taille n'excède pas
-<xref linkend="slon-config-max-rowsize"/>. Avec une valeur par défaut, ceci limitera
-ce phénomène de consommation de mémoire à la hauteur de 8MB. </para>
+<xref linkend="slon-config-max-rowsize"/>. Avec les valeurs par défaut, ceci limitera
+ce phénomène de consommation de mémoire à un plafond de 8MB. </para>
</listitem>
-<listitem><para> Les tuplets sont lus jusqu'à ce que la taille n'excède pas
+<listitem><para> Les tuples sont lus jusqu'à ce que la taille n'excède pas
le paramètre <xref linkend="slon-config-max-largemem"/>. Par défaut, cette restriction
-ne consommera pas environ 5MB. Cette valeur n'est pas un seil de limitation stricte;
-si vous avez des tuplets dont la taille est de 50MB, il <emphasis>doit</emphasis> de manière forcée,
-être charger en mémoire. Il n'est pas question de négliger cela.
+ne consommera pas plus de 5MB. Cette valeur n'est pas un seil de limitation stricte;
+si vous avez des tuples dont la taille est de 50MB, il <emphasis>seront</emphasis> forcément chargé en mémoire. Il n'est pas possible d'éviter cela.
Mais &lslon; au moins, n'essayera pas de charger, à la fois 100 enregistrements coûte que coûte, dépassant les 10GB de
mémoire consommée à cet effet.</para> </listitem>
</itemizedlist>
-<para> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont sporadiquement,
-des séries de tuplets très volumineux. </para>
+<para> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont chargés sporadiquement,
+des séries de tuples très volumineux. </para>
</answer>
</qandaentry>
<qandaentry id="faqunicode"> <question> <para> Je suis en train de répliquer
les données de type <envar>UNICODE</envar> depuis la version 8.0 de &postgres; à la version 8.1,
-et rencontre des problèmes. </para>
+et je rencontre des problèmes. </para>
</question>
<answer> <para> &postgres; 8.1 est un peu plus strict dans l'usage des codes caractères
UTF-8 et Unicode, comparé à la version 8.0.</para>
-<para> Si vous êtes emmener à utiliser &slony1; pour migrer depuis une plus vieille version à celle 8.1,
-et que au passage vous devrez faire une conversion depuis le format UTF-8, vous auriez une surprise déplaisante.</para>
+<para> Si vous êtes amené à utiliser &slony1; pour migrer depuis une plus vieille version vers la version 8.1,
+et que avez de valeur UTF-8 invalide, vous aurez une surprise déplaisante.</para>
-<para> Permettez de supposer que votre version de base est 8.0, avec l'encodage en UTF-8.
-La base va accepter des séquences <command>'\060\242'</command> en conformité avec UTF-8,
-même si il ne peut vraiment pas. </para>
+<para> Supposons que votre version de base est 8.0, avec l'encodage en UTF-8.
+La base va accepter des séquences <command>'\060\242'</command> comme un valeur UTF-8 conforme, même si ce n'est pas le cas. </para>
-<para> Si vous répliquez dans des instance de &postgres; en version 8.1, il va se plaindre de cela,
-, à la fois lors d'enregistrement d'un abonné, où &slony1; va râler
+<para> Si vous répliquez ceci dans des instances de &postgres; en version 8.1, il va se plaindre,
+, soit lors de l'enregistrement d'un abonné, car &slony1; va râler
à propos des codes caractères invalides qu'il vient de rencontrer durant la COPY des données,
-qui empêcherait que l'enregistrement se fasse, ou, empêchant de rajouter les données,plutard,
-lorsqu'il se reproduira, la réplication tombera en erreur sans possibilité de reprise.
-(Vous pouvez tricher sur le contenu de sl_log_1, mais assez rapidement
-cela deviendra <emphasis>vraiment</emphasis> inintéressante...)</para>
+ce qui empêchera que l'enregistrement se fasse, soit lors de l'ajout de données, plus tard, ce qui brisera irrémédiablement la réplication.
+(Vous pouvez tricher sur le contenu de sl_log_1, mais rapidement
+cela deviendra <emphasis>vraiment</emphasis> intéressant...)</para>
-<para>Il y a déjà eu une discutions sur ce sujet pour savoir ce qu'il faudra faire.
+<para>Il y a déjà eu des discussions sur ce sujet pour savoir ce qu'il faudra faire.
Pour le moment une stratégie attractive ne se dégage pas sur le sujet. </para>
<para>Si vous utilisez Unicode avec la version 8.0 de &postgres;, vous courrez un risque
considérable de corrompre vos données. </para>
<para> Si votre réplication a pour but de convertir une fois pour toutes vos données,
-il y a le risque évoqué; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
+il y a le risque évoqué ci-dessus; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
d'abord et de re-essayer après. </para>
-<para> A propos des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
-semble être non pérennene à maintenir et qu'une migration vers 8.1 s'imposera. </para>
+<para> Au regard des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
+semble être non pérenne à maintenir. </para>
-<para> Pour plus d'information, voir la discutions<ulink url=
+<para> Pour plus d'information, voir la discussion <ulink url=
"http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
-sur le groupe de discutions postgresql-hackers. </ulink>. </para>
+sur le groupe de discussion postgresql-hackers. </ulink>. </para>
</answer>
</qandaentry>
<qandaentry>
-<question> <para> J'utilise &slony1; 1.1 avec 4+ nouds dans le jeu où il y a deux jeux d'abonnements,
- 1 et 2, qui ne partagent pas d'autre noeuds. Je découvre que la confirmation pour le jeu 1
-n'arrivent jamais pour le noeud souscrivant au jeu 2, et inversement, celles du jeu 2 n'arrivent pas non plus
-au noeud souscrivant au jeu 1. En conséquence, <xref
-linkend="table.sl-log-1"/> crois et grossi et n'est jamais purgée. Ceci est mentionné
-comme &slony1; <ulink
+<question> <para> J'utilise &slony1; 1.1 avec plus de 4 noeuds et deux ensemble de réplication, 1 et 2, qui ne partagent aucun noeuds. Je découvre que les confirmations pour l'ensemble 1
+n'arrivent jamais aux noeuds souscrivant à l'ensemble 2, et inversement, celles de l'ensemble 2 n'arrivent pas non plus
+aux noeuds souscrivant à l'ensemble 1. En conséquence, <xref
+linkend="table.sl-log-1"/> grossit et n'est jamais purgée. Ceci est mentionné dans le bug 1485 :
+ <ulink
url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
-bug 1485 </ulink>.
+</ulink>.
</para>
</question>
-<answer><para> Apparemment le code pour
-<function>RebuildListenEntries()</function> ne suffit pas pour ce cas.</para>
+<answer><para> Apparemment le code de la fonction <function>RebuildListenEntries()</function> ne suffit pas pour résoudre ce cas.</para>
-<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; en version 1.2
+<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; version 1.2
avec un algorithme couvrant ce cas. </para>
<para>
-Dans l'intérim, vous voudrez ajouter manuellement quelques entrées <xref linkend="table.sl-listen"/> utilisant <xref
+Dans l'intérim, vous drevez ajouter manuellement quelques entrées dans <xref linkend="table.sl-listen"/> en utilisant <xref
linkend="stmtstorelisten"/> ou <function>storeListen()</function>,
-basé sur les (apparemment pas aussi désuet que nous avons pensé) principes décrits dans <xref linkend="listenpaths"/>.
-
+basé sur les principes décrits dans <xref linkend="listenpaths"/>.
+(apparemment pas aussi désuet que nous avons pensé)
</para></answer>
</qandaentry>
<qandaentry>
-<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, avec outre les derniers caractères truncés. Pourquoi?
+<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, il leur manque les derniers caractères. Pourquoi?
</para> </question>
-<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; la manière dont des colonnes étaient capturées par la fonction <function>logtrigger()</function> qui coupait outre les derniers byte d'une colonne représentée dans un format de multibyte. Vérifiez pour voir que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le e patch a été intégré dans la version CVS de 1.34 de ce fichier. </para> </answer>
+<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; les colonnes étaient capturées par la fonction <function>logtrigger()</function>, qui coupait les derniers byte d'une colonne représentée dans un format de multibyte. que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le patch a été intégré dans la version CVS de 1.34 de ce fichier. </para> </answer>
</qandaentry>
<qandaentry id="sequenceset"><question><para> <ulink url=
"http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
-Bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
-vous faites placer une réplique composée seulement d'ordres.
+Le bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
+vous faites placer une réplication composée seulement de séquences.
</para>
</question>
-<answer> <para> Une brève réponse serait de dire qu'une réplication composée seulement d'ordre, n'est pas une bonne pratique <link linkend="bestpractices">
-.</link> </para>
+<answer> <para> Une réponse courte consiste à dire qu'une réplication composée seulement de séquences, n'est pas une <link linkend="bestpractices">
+bonne pratique.</link> </para>
</answer>
+
+
<answer>
-<para> Le problème avec un ensemble d'ordre seulement si vous avez un cas pour lequel les seuls abonnements qui sont en activité pour un abonné particulier vis à vis d'un fournisseur particulier, sont pour les jeux <quote>sequence-only</quote>. Si un noeud entre dans cet état,
-la réplique échouera, étant donnée la requête qui collectera les données depuis <xref
-linkend="table.sl-log-1"/> n'aura plus de tables à trouver et par conséquence la requête tombera en erreur. S'un jeu de réplication de nouveau <emphasis>avec</emphasis>
-des tables reapparît, tout va fonctionner correctement; il
- <emphasis>paraîtra</emphasis> tout simplement effrayant.
+<para> Le problème avec un ensemble de réplication contenant uniquement des séquences, ce sont les cas ou les seuls abonnements actifs sont composés uniquement de séquences. Si un noeud entre dans cet état,
+la réplication échouera, puisque la requête qui collecte les données dans <xref
+linkend="table.sl-log-1"/> ne trouvera aucune table et par conséquent la requête sera malformée et échouera. Si un ensemble de réplication <emphasis>contenant</emphasis> des tables reapparaît, tout va fonctionner correctement; cela <emphasis>parait</emphasis> effrayant.
</para>
-<para> Ce problème devrait être résolu un certaine temps après &slony1;
+<para> Ce problème devrait être résolu après &slony1;
1.1.0.</para>
</answer>
</qandaentry>
@@ -1538,19 +1348,18 @@
<qandaentry>
<question><para>Je dois supprimer une table d'un ensemble de réplication</para></question>
<answer><para>
-Ceci peut être accompli de plusieurs manières, pas toutes également souhaitables;-).
+Ceci peut être accompli de plusieurs manières, pas toutes également souhaitables ;-).
<itemizedlist>
-<listitem><para> Vous pourriez supprimer tout le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin. Hélas, ce signifie reproduire un tas de données, et tue l'intérêt du cluster sur lequel cela se produit.</para></listitem>
+<listitem><para> Vous pourriez supprimer tout le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin. Hélas, ce signifie reproduire un tas de données, et interromp la réplicationdes autres éléments de l'ensemble pendant toute la duréel'opération</para></listitem>
-<listitem><para> Si vous êtes en version 1.0.5 ou supérieur, il y a une commande SET DROP TABLE, qui fera "l'affaire."</para></listitem>
+<listitem><para> Si vous êtes en version 1.0.5 ou supérieur, il y a une commande SET DROP TABLE, qui "fera l'affaire."</para></listitem>
-<listitem><para> Si vous employez toujours 1.0.1 ou 1.0.2, l'
-<emphasis>essentiel de la fonctionnalité de <xref linkend="stmtsetdroptable"/>
-impliquant <function>droptable_int()</function> est présent.
-Vous pouvez feuilleter cela à la main en trouvant l'identification de la table à supprimer, et que vous pouvez trouver dedans<xref
-linkend="table.sl-table"/>, et après lancer les trois requêtes suivantes sur chaque noeud :</emphasis>
+<listitem><para> Si vous utilisez toujours une version 1.0.1 ou 1.0.2,
+<emphasis>la fonctionnalité essentielle de <xref linkend="stmtsetdroptable"/> se trouve dans la fonction <function>droptable_int()</function> .
+Vous pouvez l'utilisez à la main en trouvant l'identifiant de la table à supprimer, qui se trouve dans la table <xref
+linkend="table.sl-table"/>, puis lancer les trois requêtes suivantes sur chaque noeud :</emphasis>
<programlisting>
select _slonyschema.alterTableRestore(40);
@@ -1558,25 +1367,24 @@
delete from _slonyschema.sl_table where tab_id = 40;
</programlisting></para>
-<para>Le schéma dépendra évidemment de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple, 40, sera à vous de remplacer par celui que vous voulez vous en débarrasser.</para>
+<para>Évidement le nom du schéma dépend de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple: 40, doit être remplacé par celui de la table dont voulez vous débarrasser.</para>
-<para> Vous devrez lancer ces trois interrogations sur tous les noeuds, de préférence premièrement sur le noeud d'origine, de sorte que la réplique de ses propagations soit correcte.
-Implémenter ceci à travers un ordre de <xref linkend="slonik"/>
-avec un nouveau &slony1; pourra se faire. La soumission des trois requêtes utilisant <xref linkend="stmtddlscript"/> peut le faire aussi.
-Également il sera possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
+<para> Vous devrez lancer ces trois interrogations sur tous les noeuds, de préférence premièrement sur le noeud d'origine, de sorte que la suppressions se propage correctement.
+On peut également Implémenter ceci à travers un commande <xref linkend="slonik"/> et
+un nouvel évenement &slony1;. Soumettre les trois requêtes en utilisant <xref linkend="stmtddlscript"/> permet de le faire.
+Il est égalementt possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
</answer>
</qandaentry>
<qandaentry>
-<question><para>Je dois supprimer un ordre dans une séquence pour un ensemble de réplication</para></question>
+<question><para>Je dois supprimer une séquence dans une séquence pour un ensemble de réplication</para></question>
-<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieur, il y a une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
+<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieure, il existe une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
-<para>Si vous êtes en version 1.0.2 ou antérieur, l'opération sera un peu plus manuel.</para>
+<para>Si vous êtes en version 1.0.2 ou antérieure, l'opération sera un peu plus manuelle.</para>
-<para>À supposer que je veux me débarrasser des deux ordres énumérés ci-dessous,<envar>whois_cachemgmt_seq</envar> and
-<envar>epp_whoi_cach_seq_</envar>, we start by needing the
-<envar>seq_id</envar> values.
+<para>À supposer que je veux me débarrasser des deux séquences suivante : ,<envar>whois_cachemgmt_seq</envar> et
+<envar>epp_whoi_cach_seq_</envar>, tout d'abord il nous faut les valeurs de <envar>seq_id</envar>.
<screen>
oxrsorg=# select * from _oxrsorg.sl_sequence where seq_id in (93,59);
@@ -1587,7 +1395,7 @@
(2 rows)
</screen></para>
-<para>Les données à supprimer, afin d'éviter que soit propager, nécessite l'arrêt de Slony :
+<para>Les données à supprimer pour empêcher Slony de continuer la réplication sont :
<programlisting>
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
@@ -1595,39 +1403,39 @@
</programlisting></para>
<para>Ces deux interrogations peuvent être soumises à l'ensemble des noeud via la fonction &funddlscript; / <xref
-linkend="stmtddlscript"/>, éliminant l'ordre partout en
-<quote>même temps.</quote> Ou bien appliquer à la main à chacun des noeuds.</para>
+linkend="stmtddlscript"/>, éliminant la séquence partout
+<quote>en même temps.</quote> Ou bien on peut les appliquer à la main à chacun des noeuds.</para>
-<para>Similarly to <xref linkend="stmtsetdroptable"/>, this is
-implemented &slony1; version 1.0.5 as <xref
+<para>De la même manière que <xref linkend="stmtsetdroptable"/>,
+cette fonction est implementée dans &slony1; version 1.0.5 sous
+le nom <xref
linkend="stmtsetdropsequence"/>.</para></answer></qandaentry>
</qandadiv>
-<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Hopefully Obsolete Issues </title>
+<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Problèmes devenus obsolètes</title>
<qandaentry>
<question><para> &lslon; ne se remet pas en marche après un incident</para>
-<para> Après un après brutal de &postgres; (en simulant une panne système)
-dans &pglistener; un tuplets existe avec <command>
+<para> Après un arrêt immédiat de &postgres; (équivalent à un crash du système),
+dans la table &pglistener; on trouve un tuple contenant <command>
relname='_${cluster_name}_Restart'</command>. slon ne démarre pas car
-il considère qu’une autre processe sert le cluster sur ce noeud. Que puis-je faire?
-Le tuplet ne peut pas être supprimé dans la relation.</para>
+il considère qu'un autre processus gère le cluster sur ce noeud. Que puis-je faire?
+Le tuple ne peuventt pas être supprimés dans cette relation.</para>
-<para> Le journal prétend que <blockquote><para>un autre slon en tâche de fond
-sert ce noeud déjà</para></blockquote></para></question>
+<para> Les journaux de traces indique qu' <blockquote><para>un autre slon en tâche de fond gère déjà ce noeud.</para></blockquote></para></question>
<answer><para> Le problème est que la table système &pglistener;, utilisée par
-&postgres; à gérer l'évènement de notification, contiens quelques entrées pointant vers le central,
-n'existent plus. La nouvelle instance de <xref
-linkend="slon"/> se connecte à la base, et elle est convaincue, par la
+&postgres; pour gérer les notification d'évènements, contient quelques entrées pointant vers des processus qui n'existent plus.
+La nouvelle instance de <xref
+linkend="slon"/> se connecte à la base, et elle est convaincue, à cause de la
présence de ces entrées qu'un ancien
<application>slon</application> est toujours en activité pour s'occuper de ce noeud de &slony1;.</para>
-<para> Le <quote>détritus</quote> dans cette table doit être nettoyer.</para>
+<para> Les <quote>détritus</quote> dans cette table doivent être nettoyés.</para>
-<para>Il sera utile de maintenir un script manuel pour ce genre de situation:
+<para>Il est utile de maintenir un script manuel pour ce genre de situation:
<programlisting>
twcsds004[/opt/twcsds004/OXRS/slony-scripts]$ cat restart_org.slonik
@@ -1643,16 +1451,16 @@
</programlisting></para>
<para> <xref linkend="stmtrestartnode"/> nettoie les notifications mortes
-pour en suite redémarrer le noeud.</para>
+pour qu'on puisse ensuite redémarrer le noeud.</para>
-<para>Comme en version 1.0.5, au démarrage de slon, les processes cherche ce genre de données obsolètes et les nettoient
+<para>A partir de la version 1.0.5, le processus de démarrage de sloncherche ce genre de données obsolètes et les nettoient
le cas échéant.</para>
-<para> Comme en version 8.1 de &postgres;, la fonction manipulant
-&pglistener; ne supporte pas cet usage, alors pour la version de &slony1; après
-1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce
-<quote>couplage</quote> est manipulé par l'intermédiaire d'une autre table, et l'issu de la situation est
-rendu un peu plus transparent. <quote>.</quote> </para>
+<para> A partir de la version 8.1 de &postgres;, la fonction manipulant
+&pglistener; ne supporte pas cet usage, alors pour les versions de &slony1; postérieurs à la
+1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce risque d'
+<quote>inter-blocage</quote> est géré vias une nouvelle table,
+et le problème disparait de manière transparente. <quote>.</quote> </para>
</answer></qandaentry>
@@ -1666,8 +1474,7 @@
ERROR: could not find hash function for hash operator 716373
</programlisting>
-<para> Il semble que &slony1; <function>xxid</function> les fonctions vont être
-dôtées de brouillage(hashing), qu'elles n'ont pas actuellement.</para>
+<para> Il semble que les fonctions <function>xxid</function> de &slony1; prétendent pouvoir faire du hashing, mais qu'elles n'y arrivent pas.</para>
<para> Que se passe-t-il ? </para>
@@ -1675,29 +1482,29 @@
</question>
<answer><para> &slony1; a défini un nouveau type de données et d'opérateurs XXID
-ce type afin de permettre la manipulation des IDs de transaction qui sont employés
-pour grouper ensemble, les mises à jour qui sont associées à la même transaction.
+afin de permettre la manipulation des IDs de transaction qui sont employés
+pour grouper ensemble, les mises à jour qui sont associées dans une même transaction.
</para>
-<para> Opérateurs qui n'étaient pas disponible pour &postgres; version
-7.3 et inférieur; afin de le rendre opérationnelle en 7.3, les fonctions spécifiques
+<para> Ces opérateurs n'étaient pas disponible pour &postgres; version
+7.3 et inférieur; afin de rendre &slony1; opérationnel avec la version 7.3, des fonctions spécifiques
doivent être ajoutées. L'opérateur <function>=</function>
-a été marqué comme soutenant
-le hachage, mais pour que celui-ci travaille correctement, l'opérateur de jointure doit
-apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini,
+a été marqué comme supportant
+le hachage, mais pour que cela fonctionne, l'opérateur de jointure doit
+apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini ainsi,
et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer
-le hash-joins échoueront. </para> </answer>
+des hash-joins échoueront. </para> </answer>
<answer> <para> Ceci <emphasis> n'a pas </emphasis>
-été considéré comme bug <quote>release-critical</quote>, comme &slony1;
-ne produit probablement pas des intérrogations intérnes employant des hash-join. Ce problème ne devrait
-pas entacher &slony1; devant la capacité qu'il a de gérer la réplication. </para> </answer>
+été considéré comme bug <quote>critiques</quote>, car &slony1;
+ne produit pas de requêtes employant des hash-join. Ce problème ne devrait
+pas perturber la réplication. </para> </answer>
-<answer> <para> La nouvelle version de &slony1; (<emphasis>e.g.</emphasis>
-1.0.6, 1.1) omettra l'indicateur <command>HASHES</command>, donc ceci
+<answer> <para> Les versions suivantes de &slony1; (<emphasis>par exemple :</emphasis>
+1.0.6, 1.1) omettent l'indicateur <command>HASHES</command>
</para> </answer>
-<answer> <para> Supposons que vous souhaitez réparer une instance existante, et vous constatez
+<answer> <para> Supposons que vous souhaitiez réparer une instance existante, et vous constatez
que vos propres scripts ne fonctionneront pas bien, vous pouvez suivre la démarche suivante : </para>
<programlisting>
@@ -1732,25 +1539,30 @@
</qandaentry>
<qandaentry> <question><para> Je peux faire un <command>pg_dump</command>
-et chargez les données en les sauvegardant, beaucoup plus rapidement que si <command>SUBSCRIBE
-SET</command> les exécutait lui-même. Pourquoi c'est ainsi? </para></question>
+et rechargez les données beaucoup plus rapidement qu'avec <command>SUBSCRIBE
+SET</command>. Comment est-ce possible ? </para></question>
-<answer><para> &slony1; dépend des index, supposons qu'il soit sur un clef primaire, dont les feuilles se trouvant isolées (sans branches), en utilisant la commande
- &postgres; <command>COPY</command> les données sont lues rapidement.
-Alors que il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un
-évènement généré par le souscripteur) dans la mesure où l'opération dans ce cas démarre par d'abord une suppression des contenus des tables, et rien que cela laisse des tuplets morts.</para>
+<answer><para> &slony1; dépend de l'existance d'un index sur la clef primaire
+et ne touche pas aux autres index pendant l'opération &postgres; <command>COPY</command> qui charge les données.
+Par ailleur il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un
+évènement généré lors d'un abonnement) dans la mesure où l'opération commence par une suppression des contenus des tables, ce qui laisse la tables remplie de tuples morts.</para>
-<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez après, les indexes ne sont crées qu'à la fin. Ceci est <emphasis>beaucoup</emphasis> plus performant des reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volet lorsque les enregistrement sont rajoutés un à un à la table.</para></answer>
+<para> Lorsque vous utilisez <command>pg_dump</command> pour exporter le contenus de la base, et que vous les re-importez après, les indexes ne sont crées qu'à la fin.
+Il est <emphasis>beaucoup</emphasis> plus performant de reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volée lorsque les enregistrements sont rajoutés un à un à la table.</para></answer>
-<answer><para> Si d'emblée, vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée. Encore mieux, si vous pouvez<command>TRUNCATER</command> les tables dont le contenu devra disparaître, les performance vont augmenter d'<emphasis>avantage.</emphasis> </para></answer>
+<answer><para> Si vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée.
+Encore mieux, si vous pouvez faire un <command>TRUNCATE</command> sur les tables dont le contenu devra disparaître, les performances vont augmenter <emphasis>énormément</emphasis>. </para></answer>
-<answer><para> &slony1; en version 1.1.5 et supérieur, fait cela automatiquement; il <quote>cogne</quote> sur les indexes dans le catalogue de &postgres; afin de les inhiber, de plus, de la même façon il désactive les déclencheurs, tout en les <quote>réactivant</quote> à la fin sans oublier de reconstruire les indexes des tables en question. </para> </answer>
+<answer><para> &slony1; en version 1.1.5 et supérieures, fait cela automatiquement;
+il <quote>dégage</quote> sur les indexes dans le catalogue de &postgres; afin de les cacher, de la même façon qu'il cache les triggers,
+puis il <quote>répare</quote> les pointeurs d'index et effectue une
+reindexationd de la table. </para> </answer>
</qandaentry>
<qandaentry id="dupkey">
-<question><para>La réplication échoue - Violation des Constraintes unique</para>
+<question><para>La réplication échoue - Violation de Constrainte Unique</para>
-<para>Alors que la Réplication se déroule correctement, depuis un bout de temps, lorsque le noeud rencontre <quote>intempestivement,</quote> des erreurs suivant envoyées dans le journal:
+<para>Alors que la Réplication se déroule correctement depuis un bout de temps, lorsque que tout a coup 'un noeud rencontre un <quote>soucis</quote> et les erreurs suivantes envoyées dans le journal:
<screen>
DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
@@ -1775,34 +1587,39 @@
</screen></para>
<para>La transaction s'annule, et &slony1; essaie à nouveau sans cesse.
-Le problème est dû à une des <emphasis>dernière</emphasis> requête SQL
-précisant <command>log_cmdtype = 'I'</command>. Ce n'est pat tout à fait évident; ce qui se passe est que &slony1; regroupe 10 opérations de mise à jour, ensemble, afin de diminuer les aller-retour réseau.</para></question>
+Le problème est dû à une des <emphasis>dernières</emphasis> requêtes SQL, celle qui contenait <command>log_cmdtype = 'I'</command>.
+Ce n'est pas évident du tout;e &slony1; regroupe 10 opérations de mise à jour ensemble, afin de diminuer les allers-retours réseau.</para></question>
-<answer><para> Une origine <emphasis>certaine</emphasis> pour ceci est difficile à déterminer.</para>
+<answer><para> Il est difficile de déterminer avec <emphasis>exactitude</emphasis> l'origine de tout ceci.</para>
-<para>En même temps, nous notons qu'il y a un problème de transactions manquées concernant les suppressions qui sont déjà nettoyées dans <xref
-linkend="table.sl-log-1"/>, et on constate qu'un recouvrement est impossible. A ce stade, ce qui semble nécessaire, est de supprimer le jeu de réplication (ou même carrément le noeud), est de redémarrer la réplication de début pour le noeud.</para>
+<para>En même temps, nous notons qu'il y a un problème : les transactions annulées ont été supprimées dans <xref
+linkend="table.sl-log-1"/>,
+et on constate qu'il est impossible de les récupérer.
+A ce stade, il parait nécessaire de supprimer l'ensemble de réplication (ou même le noeud), et de redémarrer la réplication à partir de zéro pour ce noeud.</para>
<para>Dans &slony1; 1.0.5, l'opération de purge de <xref
linkend="table.sl-log-1"/> devient plus prudente, en refusant
-de purger des entrées qui n'ont pas encore été synchronisées. pour au moins 10 minutes sur l'ensemble des noeuds. Il n'est pas certain que ceci empêche que
-<quote>le problème</quote> ait lieu, mais il paraît plausible que cela laisse assez de volume dans <xref linkend="table.sl-log-1"/> permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation. Et peut-être que le problème venait du fait que <xref linkend="table.sl-log-1"/> a été brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
+de purger des entrées qui n'ont pas encore été synchronisées, pendanttr au moins 10 minutes sur l'ensemble des noeuds. Il n'est pas certain que ceci empêche que
+<quote>le problème</quote> ait lieu, mais il paraît plausible que cela laisse assez de données dans <xref linkend="table.sl-log-1"/> permettant un recouvrement ou bien de permettre d'au moins de diagnostiquer plus exactement la situation.
+Et peut-être que le problème venait du fait que <xref linkend="table.sl-log-1"/> était brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
-<para> C'est une honte de reconstruire un réplication volumineuse sur un noeud,
-si vous découvrez que le problème pérciste. La bonne idée serai de diviser la réplication
-en plusieurs morceaux afin de dimin<envar>tgrelid</envar> en les pointant sur l'identifiant OID of the <quote>primary
-key</quote> index on the table rather than to the table
-uer la charge de travail lors de redémarrage de réplication.
-Si un seul jeu est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
+<para> C'est une honte de devoir reconstruire une réplication volumineuse sur un noeud à cause de cela.
+Si vous découvrez que le problème persiste,
+La bonne idée serait de diviser la réplication
+en plusieurs ensemble de réplication afin de dimininuer
+la charge de travail lors de la reconstruction de la réplication.
+Si un seul ensemble est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
</para>
-<para> Dans un cas, nous avons trouvé deux lignes dans le journal d'erreur des requêtes sql
-qui sont <emphasis> identique </emphasis> concernant l'insertion dans
- <xref linkend="table.sl-log-1"/>. Ceci <emphasis> doit
+<para> Dans un cas, nous avons trouvé dans le journal de trace deux lignes <emphasis> identiques </emphasis> concernant l'insertion dans
+ <xref linkend="table.sl-log-1"/>.
+Ceci <emphasis> devrait
</emphasis> être impossible d'autant plus qu'il s'agit d'une clef primaire sur <xref
-linkend="table.sl-log-1"/>. La dernière théorie, moins forte, laisserait à penser que cette situation
-viendrait que <emphasis>cette</emphasis> clé serait peut-être corrompue (présence d'un bug de &postgres;), et afin de soulever ce doute,
-on peut exécuter l'ordre suivant:</para>
+linkend="table.sl-log-1"/>. La dernière théorie sur le sujet laisserait à penser que cette situation
+viendrait du fait que l'index de <emphasis>cette</emphasis>
+clé était peut-être corrompu (à cause d'un bug de &postgres;),
+et qu'il serait possible d'éviter ce problème en exécutant la
+commande suivante:</para>
<programlisting>
# reindex table _slonyschema.sl_log_1;
@@ -1811,8 +1628,8 @@
<para> Au moins dans une occasion cette solution s'est révélée efficace, alors cela sera dommage de ne pas suivre l'exemple.</para>
</answer>
-<answer> <para> Ce problème s'est avéré comme un bug dans &postgres; par opposition à un autre dans &slony1;. La version 7.4.8 avait intégré deux solutions qui permettent de résoudre ce cas. Or si vous avez un noyau de &postgres; antérieur à 7.4.8,
-vous devriez migrer d'abord pour éviter l'erreur.
+<answer> <para> Ce problème s'est avéré être un bug dans &postgres; plutot qu'un bug dans &slony1;. La version 7.4.8 a intégré deux solutions qui permettent de résoudre ce cas. Donc si vous avez un noyau de &postgres; antérieur à 7.4.8,
+vous devriez migrer pour éviter l'erreur.
</para>
</answer>
</qandaentry>
@@ -1820,12 +1637,12 @@
<application>pg_dump</application>, et Slony
s'arrête soudainement</para></question>
-<answer><para>Ouf. Ce qui se passe dans ce cas est à cause d'un conflit entre:
+<answer><para>Aïe. Ce qui se passe ici est un conflit entre:
<itemizedlist>
-<listitem><para> <application>pg_dump</application>, qui sort un <command>AccessShareLock</command> pour toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
+<listitem><para> <application>pg_dump</application>, qui pose un verrou <command>AccessShareLock</command> sur toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
-<listitem><para> Une synchronisation de &slony1; qui veut saisir
+<listitem><para> Un événement SYNC de &slony1; qui veut poser un verrou
<command>AccessExclusiveLock</command> sur la table <xref
linkend="table.sl-event"/>.</para></listitem> </itemizedlist></para>
@@ -1835,10 +1652,10 @@
select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);
</screen></para>
-<para>(vous pouvez voir ceci dans<envar>pg_stat_activity</envar>, si votre paramètre d'affichage des requête est positionné à vrai dans
+<para>(vous pouvez voir ceci dans la vue <envar>pg_stat_activity</envar>, si l'affichage des requête est activé dans
<filename>postgresql.conf</filename>)</para>
-<para>L'interrogation encours qui cause ce verrous vient de la fonction <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
+<para>La requête qui demandece verrou vient de la fonction <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui est :
<programlisting>
@@ -1847,9 +1664,9 @@
SELECT currval('%s.sl_event_seq');
</programlisting></para>
-<para>Le <command>VERROUS</command> se poste à ce moment et dure jusqu'à ce que
-<command>pg_dump</command> (ou le temps que les verrous bloquent les accès à <xref linkend="table.sl-event"/>)
-se términe.</para>
+<para>La demande de <command>VERROU</command> va donc attendre et
+durer jusqu'à ce que <command>pg_dump</command> (un autre programme ayant un verrou d'accès sur <xref linkend="table.sl-event"/>)
+se termine.</para>
<para>Chaque lecture touchant
<xref linkend="table.sl-event"/> sera bloqué derrière les appels à
@@ -1858,25 +1675,26 @@
<para>Les réponses à cette question sont multiples:
<itemizedlist>
-<listitem><para> Faire spécifier à <application>pg_dump</application> d'exporter le schéma en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster entièrement.</para></listitem>
+<listitem><para> Indiquer explicitement à <application>pg_dump</application>
+les schémas qu'il doit exporter en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster.</para></listitem>
-<listitem><para> Il sera utile aussi d'ajouter une option
-<option>--exclude-schema</option> à
-<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. A rêver que dans 8.2...</para></listitem>
+<listitem><para> Il sera utile aussi d'avoir une option
+<option>--exclude-schema</option> dans
+<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. Pourquoi pas dans 8.2...</para></listitem>
-<listitem><para>Notez que 1.0.5 utilise des verrous plus précis et moins exclusifs qui soulage ce problème.</para></listitem>
+<listitem><para>Notez que la version 1.0.5 utilise des verrous plus précis et moins exclusifs qui évitent ce problème.</para></listitem>
</itemizedlist></para>
</answer></qandaentry>
</qandadiv>
-<qandadiv id="faqoddities"> <title> &slony1; FAQ: Singularité des vulnérabilité dans Slony-I </title>
-<qandaentry><question><para> Que se produit à propos des règles et des déclencheurs pour des tables répliquées par
+<qandadiv id="faqoddities"> <title> &slony1; FAQ: Bizareries et modifications dans Slony-I </title>
+<qandaentry><question><para> Que se produit-il avec les règles et les déclencheurs pour ls tables répliquées par
&slony1;?</para>
</question>
-<answer><para> Premièrement regardons comment elle est gérée
-<emphasis>l'absence</emphasis> de gestion spécifique de la commande Slonik<xref
+<answer><para> Premièrement regardons comment ceci est géré
+<emphasis>en dehors</emphasis> du cas spécifique de la commande Slonik<xref
linkend="stmtstoretrigger"/>. </para>
<para> La fonction <xref
@@ -1885,42 +1703,43 @@
<itemizedlist>
-<listitem><para> Sur le noeud maître, ceci implique l'ajout d'un déclencheur
-qui utilise la fonction <xref linkend="function.logtrigger"/> à la table.</para>
+<listitem><para> Sur le noeud maître, ceci implique l'ajout sur la table d'un déclencheur
+qui utilise la fonction <xref linkend="function.logtrigger"/>.</para>
<para> Le déclencheur a pour action d'enregistrer, toutes les mises à jours dans
la table <xref linkend="table.sl-log-1"/> de &slony1;.
</para></listitem>
-<listitem><para> Sur un noeud d'abonné, répliquer une table, revient à désactiver les déclencheurs,
-puis, via un déclencheur, de restreindre le droit d'accès en écriture sur celle-ci en
+<listitem><para> Sur un noeud d'abonné, ceci revient à désactiver les déclencheurs et les règles,
+puis, via un déclencheur, de refuser le droit d'accès en écriture sur celle-ci en
utilisant la fonction <function>denyAccess()</function>.</para>
-<para> Jusqu'à la version 1.1 (et peut-être avant), le
+<para> Jusqu'à la version 1.1 (et peut-être après), la
<quote>désactivation</quote> est faite en modifiant
+la valeur de <envar>tgrelid</envar> dans les tables
<envar>pg_trigger</envar> ou <envar>pg_rewrite</envar>
-<envar>tgrelid</envar> en pointant l'identifiant OID sur
-la <quote>clé primaire</quote> de l'index du catalogue, plutôt qu'une action directe sur la table
-elle-même.</para></listitem>
+ en pointant l'identifiant OID sur
+la <quote>clé primaire</quote> de l'index du catalogue, plutôt que
+sur la table elle-même.</para></listitem>
</itemizedlist>
-<para> Un effet secondaire quelque part malheureu de ces actions sur les règles et les déclencheurs
-donne un effet de les <quote>piétiner</quote>. Dans la mesure où les règles et les déclencheurs sont toujours là,
+<para> Un effet secondaire malheureux est que cette gestion des règles et des déclencheurs a pour effet de les <quote>piétiner</quote>.
+Les règles et les déclencheurs sont toujours là,
mais ne plus correctement attachés à leurs tables. Si vous faite un <command>pg_dump</command> sur
-<quote>le noeud d'abonné</quote>, il ne trouvera pas les contraintes ni les déclencheur, et surtout il ne s'attend pas
-à les voir associés à un indexe.</para>
+<quote>le noeud d'abonné</quote>, il ne trouvera pas les règles ni les déclencheurs, et puisqu' il ne s'attend pas
+à les voir associés à un index.</para>
</answer>
<answer> <para> Maintenant observer comment <xref linkend="stmtstoretrigger"/>
entre en jeu.</para>
-<para> Mettez simplement cette commande pour que
-&slony1; restore les déclencheurs :
-<function>alterTableRestore(table id)</function>, qui restaure l'identifiant OID
-de la table dans <envar>pg_trigger</envar> ou
-<envar>pg_rewrite</envar> <envar>tgrelid</envar> sur le noeud affecté.</para></answer>
+<para> Pour simplifier, cette commande permet de restaurer les déclencheurs
+avec la fonction <function>alterTableRestore(table id)</function>,
+ qui restaure l'identifiant OID
+de la table dans la colonne <envar>tgrelid</envar> de <envar>pg_trigger</envar> ou
+<envar>pg_rewrite</envar> sur le noeud affecté.</para></answer>
<answer><para> Ceci implique que le jour où vous souhaitez lancer une sauvegarde directement
sur un abonné, vous devrez reprendre le schéma depuis un noeud d'origine. Clairement il faudra faire : </para>
@@ -1933,8 +1752,9 @@
</answer>
</qandaentry>
-<qandaentry> <question> <para> J'essaie de demander <xref
-linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouves
+<!-- todo -->
+<qandaentry> <question> <para> J'ai essayé les commandes <xref
+linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouvé
les messages suivants sur l'un des abonnés :</para>
<screen>
@@ -1945,44 +1765,45 @@
</question>
<answer> <para> La difficulté semble venir du fait que
-vous ajouter un déclencheur à une table dont le nom rentre en conflit,
-avec le déclencheur que &slony1; cache. </para>
+vous avez ajouté des déclencheurs sur des tables dont le nom rentre en conflit,
+avec les déclencheurs que &slony1; a caché. </para>
-<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>unhidden</quote>
+<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>visibles</quote>
via <xref linkend="stmtstoretrigger"/>) en les attachant à la clé primaire de leur table.
-Dans le cas d'une clef étrangère, d'autre déclencheurs sont rajoutés afin de garantir la cohérence des données.
-Il est complètement inutile des les lancer depuis un abonné, ainsi ces déclencheurs doivent être provoquer
-depuis le noeud d'origine. En revanche, les déclencheurs de type
-<quote>cache invalidation</quote> sont ceux que vous devrez lancer depuis l'abonné.</para>
+Dans le cas d'un déclencheur pour clef étrangère, ou d'autres déclencheurs de cohérence des données,
+il est complètement inutile de les placer sur un abonnné,
+au contraire ces déclencheurs doivent être mis en place
+sur le noeud d'origine. En revanche, les déclencheurs de type
+<quote>invalidation de cache</quote> peuvent être placés sur l'abonné.</para>
<para> La <emphasis>bonne manière</emphasis> de manipuler ce genre de déclencheurs est d'utiliser
<xref linkend="stmtstoretrigger"/>, qui indique à
-&slony1; de ne pas désactiver des déclencheurs. </para> </answer>
+&slony1; de ne pas désactiver le déclencheur. </para> </answer>
-<answer> <para> Mais il peut y avoir quelques DBA intrépides, qui vont assumer individuellement ce travail on
-installant les déclencheur à la main sur l'abonné, et donc capable de créer ce genre de situation. Que faire?
+<answer> <para> Mais il peut y avoir quelques DBAs intrépides, qui vont assumer individuellement ce travail en
+installant les déclencheur à la main sur l'abonné, et cela mène généralement créer ce genre de situation. Que faire ? Que faire ?
</para>
<para> La réponse est assez simple : Retirez le déclencheur
-<quote>spécifique</quote> sur l'abonné avant de dérouler la restauration.
+<quote>spécifique</quote> sur l'abonné avant que slony tente de les
+restaurer.
Dans le meilleur des cas, si le DBA est intrépide et réactif, il aurait fait cela
<emphasis>avant</emphasis> que le message ait le temps d'arriver. </para>
-<para> Si le DBA n'est pas intrépide, la réponse serait de se connecter au noeud
-offensé, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre
+<para> Si le DBA n'est pas intrépide, il faut se connecter au noeud
+qui pose problème, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre
<acronym>SQL</acronym> <command>DROP
TRIGGER</command>. Ceci permet à l'évènement de se dérouler.
Si l'évènement était <xref linkend="stmtddlscript"/>, alors notre
-<quote>pas-tellement-intrépide </quote> DBA devra ajouter le trigger à la main,
-ou, s'il y a plus de sagesse, de les réactiver avec
+<quote>pas-tellement-intrépide </quote> DBA devra remettre en place le déclencheur à la main, ou, s'il a plus de sagesse, il les réactivera avec
<xref linkend="stmtstoretrigger"/>.</para>
</answer>
</qandaentry>
<qandaentry id="neededexecddl">
-<question> <para> Comportement - tous les noeuds d'abonné, ainsi que le noeud maître,
-commence à se planter, crachant le message d'erreur suivant dans le journal,
+<question> <para> Le comportement : tous les noeuds abonné commencent
+ à tomber et ont le message d'erreur suivant dans le journal,
(lorsque j'ai rencontré ce problème, il y avait une longue requête SQL devant chaque message ):</para>
<screen>
@@ -1991,20 +1812,22 @@
</screen>
</question>
-<answer> <para> Cause: you have likely issued <command>alter
-table</command> statements directly on the databases instead of using
-the slonik <xref linkend="stmtddlscript"/> command.</para>
+<answer> <para> La cause : vous avez probablement effectué
+un <command>alter table</command> directement sur la
+base au lieu d'utiliser la commande slonik
+<xref linkend="stmtddlscript"/>.</para>
<para>La solution consiste à remettre le trigger sur la table affectée,
-et de corriger les données afférentes dans <xref linkend="table.sl-log-1"/> by hand.</para>
+et de corriger à la main les données afférentes dans <xref linkend="table.sl-log-1"/>.</para>
<itemizedlist>
-<listitem><para> Vous avez besoin d'extraire du journal soit de slon, soit
-du &postgres; l'ordre sql exact qui a causé l'anomalie.</para></listitem>
+<listitem><para> A partir des journaux de slon ou de &postgres;,
+vous devrez identifier la requête sql exacte qui a causé l'anomalie.</para></listitem>
-<listitem><para> Vous avez besoin de corriger le déclencheur Slony-defined dans la table
-en question. Ceci peut se faire à l'aide de la procédure suivante :</para>
+<listitem><para> Vous avez besoin de réparer les déclencheurs
+définis par Slony dans la table en question.
+Ceci peut se faire à l'aide de la procédure suivante :</para>
<screen>
BEGIN;
@@ -2014,10 +1837,12 @@
COMMIT;
</screen>
-<para>Ensuite vous avez besoin de sélectionner les enregistrements dans <xref
-linkend="table.sl-log-1"/> qui sont incohérent pour les corriger. Il faudra ensuite arrêter
-les processes de Slon pour l'ensemble des noeuds excepté celui du maître;
-de cette manière vous évitez que l'erreur se propage immédiatement à travers tous les noeuds.</para>
+<para>Ensuite vous devez trouver les enregistrements dans <xref
+linkend="table.sl-log-1"/> qui sont incohérents et les corriger.
+Il sera préférable d'arrêter les démons Slon
+pour l'ensemble des noeuds excepté celui du maître;
+de cette manière, si vous faites une erreur,elle ne se propagera
+pas immédiatement sur tous les noeuds abonnés.</para>
<para> Voici un exemple:</para>
@@ -2063,7 +1888,8 @@
<qandaentry>
<question><para> Le noeud numéro 1 a été supprimé via <xref
-linkend="stmtdropnode"/>, et le &lslon; d'un des noeuds fait cracher le message
+linkend="stmtdropnode"/>, et le &lslon; d'un autre noeud
+plante systématiquement avec le message
d'erreurs suivant:</para>
<screen>
@@ -2081,28 +1907,32 @@
DEBUG1 syncThread: thread done
</screen>
-<para> Evidemment une demande de <xref linkend="stmtstorelisten"/> n'avait pas encore
-été propagé avant que le noeud 1 soit éliminé.</para></question>
+<para> Il semble évident qu'un appel à <xref linkend="stmtstorelisten"/> n'avait pas encore été propagé avant que le noeud 1
+soit éliminé.</para></question>
-<answer id="eventsurgery"><para> Ceci indique le cas où vous avez besoin de
-<quote>opération chirurgicale</quote> sur l'un ou plusieurs noeuds.
-Un évènement<command>STORE_LISTEN</command> demeure sans réponse lorsqu'il veut
-ajouter un port d'écoute qui <emphasis>ne peut pas</emphasis> être satisfait car
-le noeud 1 ainsi que tous les éléments indiquant ce noeud sont disparus.</para>
+<answer id="eventsurgery"><para> Ceci illustre le cas où vous avez besoin de
+réaliser <quote>opération chirurgicale</quote> sur un ou plusieurs noeuds.
+Un évènement<command>STORE_LISTEN</command> demeure sans réponse
+alors qu'il veut
+ajouter une voie d'écoute qui <emphasis>ne peut pas</emphasis>
+être crée car le noeud 1 ainsi que toutes les voies vers le
+noeud 1 ont disparus.</para>
-<para> Supposons que pour la démonstration, les noeuds encore en place
-soient le 2 et le 3, ainsi le rapport d'erreur est remonté au noeud 3.</para>
+<para> Supposons, pour la démonstration, que les noeuds encore en place soient le 2 et le 3, ainsi le rapport d'erreur est remonté au noeud 3.</para>
-<para> cela implique que l'évènement se généré sur le noeud 2, comme il ne peut être sur le
-noeud 3, si il n'a pas été traité avec succès. La manière la plus facile à faire face à cette situation,
-est, de supprimer sur le noeud offensé, les données dans <xref linkend="table.sl-event"/> relatives au noeud 2.
-Vous vous connectez à la base du noeud 2, et à l'aide de Sql suivant, de chercher l'évènement
-<command>STORE_LISTEN</command>:</para>
+<para> cela implique que l'évènement est stocké sur le noeud 2,
+puisqu'il ne peut pas être sur le noeud 3, vu qu'il n'a pas été
+traité avec succès. La manière la plus facile à faire face à
+cette situation,
+est, de supprimer sur la ligne erronées dans
+ <xref linkend="table.sl-event"/> sur lenoeud 2.
+Vous vous connectez à la base du noeud 2, et vous recherchez
+ l'évènement <command>STORE_LISTEN</command>:</para>
<para> <command> select * from sl_event where ev_type =
'STORE_LISTEN';</command></para>
-<para> L'ordre peut ramener plusieurs lignes, mais ne en supprimer que la partie nécessaire.</para>
+<para> La requête peut ramener plusieurs lignes, mais ne supprimez que la partie nécessaire.</para>
<screen>
-# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
@@ -2115,12 +1945,12 @@
COMMIT
</screen>
-<para> La prochaine fois que <application>slon</application> pour le noeud 3 redémarre,
-il ne trouvera plus le <quote>souffrant</quote> évènement
-<command>STORE_LISTEN</command>, et la réplication peur se poursuivre.
-(Vous pouvez par contre voir surgir un vieil évènement enregistré qui ne soit plus en phase
-avec la configuration existante...) </para></answer>
+<para> La prochaine fois que le <application>slon</application> du noeud 3 va démarrer, il ne trouvera plus l' évènement
+<command>STORE_LISTEN</command> <quote>erroné</quote>, et la réplication pourra se poursuivre.
+( Cependnat vous pourrez ensuite voir surgir un vieil évènement
+enregistré qui fait référence à une configuration qui n'existe plus...) </para></answer>
+
</qandaentry>
</qandadiv>
Plus d'informations sur la liste de diffusion Trad