[Trad] [svn:pgfr] r1082 - traduc/trunk/slony
svncommit at kryskool.org
svncommit at kryskool.org
Mer 2 Juil 17:34:20 CEST 2008
Auteur: david.tokmatchi at gmail.com
Date: 2008-07-02 17:34:18 +0200 (mer, 02 jui 2008)
Nouvelle Révision: 1082
Ajout:
traduc/trunk/slony/faql.xml
Log:
Added: traduc/trunk/slony/faql.xml
===================================================================
--- traduc/trunk/slony/faql.xml 2008-06-27 17:32:52 UTC (rev 1081)
+++ traduc/trunk/slony/faql.xml 2008-07-02 15:34:18 UTC (rev 1082)
@@ -0,0 +1,2128 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Dernière modifications
+ le $Date$
+ par $Author$
+ révision $Revision$ -->
+
+<qandaset>
+<indexterm><primary>Questions Fréquemment Posées à propos de &slony1;</primary></indexterm>
+
+<qandadiv id="faqcompiling"><title> &slony1; FAQ: Monter et Installer &slony1; </title>
+
+<qandaentry>
+
+<question><para> J'utilise <productname> Frotznik Freenix
+4.5</productname>, avec son <acronym>FFPM</acronym> (Frotznik Freenix
+Package Manager) gestionnaire des paquetage système. L'arrivée de
+<acronym>FFPM</acronym> c'est l'introduction des paquetages pour &postgres; 7.4.7, lequel je suis actuellement
+entrain d'utiliser pour ma base de données, mais qui n'inclut pas encore les paquetages &slony1.
+Comment puis-je rajouter &slony1; à cette configuration? </para>
+</question>
+
+
+<answer><para> <productname>Frotznik Freenix</productname> c'est nouveau pour moi,
+alors il est un peu dangereux, pour donner des réponses définitives vraiment concise et rapides. </para>
+
+<para> Les réponses différent légèrement t entre les diverses combinaisons de versions entre
+&postgres; et &slony1; Il est légérement plus faciles, dans les versions récentes, de faire face à ce genre de question
+que dans les versions plus anciennes. En général, vous devez presque certainement recompiler &slony1; depuis les sources; selon les versions
+des deux composants &slony1; et &postgres;, vous
+<emphasis>devez</emphasis> également recompiler &postgres; à partir de zéro.
+(Si vous devez d' <emphasis> utilisez </emphasis> le &postgres; compiler
+est un autre problème; vous n'avez probablement pas besoin...) </para>
+
+<itemizedlist>
+
+<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite avoir complètement
+configuré &postgres; ayant les sources installées, afin de recompiler
+&slony1;.</para>
+
+<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
+<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.
+</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>
+
+<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>
+</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> 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
+de &slony1;.</para>
+
+</answer>
+
+<answer><para> </para> </answer>
+
+</qandaentry>
+
+<qandaentry id="missingheaders">
+<question><para> J'essaie d'installer &slony1; 1.1 et j'obtiens le message d'erreur suivant:
+<screen>
+configure: error: Headers for libpqserver are not found in the includeserverdir.
+ This is the path to postgres.h. Please specify the includeserverdir with
+ --with-pgincludeserverdir=<dir>
+</screen>
+</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>
+
+<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> </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
+route.</para>
+
+<para> Slony logs might look like the following:
+
+<screen>
+DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep user=postgres port=5432'
+ERROR remoteListenThread_1: "select ev_origin, ev_seqno, ev_timestamp,
+ ev_minxid, ev_maxxid, ev_xip,
+ ev_type,
+ ev_data1, ev_data2,
+ ev_data3, ev_data4,
+ ev_data5, ev_data6,
+ ev_data7, ev_data8 from "_pgbenchtest".sl_event e
+where (e.ev_origin = '1' and e.ev_seqno > '1') order by e.ev_origin, e.ev_seqno" - could not receive data from server: Operation now in progress
+</screen>
+</para>
+
+<para> Parfois il peut se manifester de manières suivante ...
+
+<screen>
+ERROR remoteListenThread_2: "select ev_origin, ev_seqno, ev_timestamp,
+ev_minxid, ev_maxxid, ev_xip, ev_type, ev_data1, ev_data2,
+ev_data3, ev_data4, ev_data5, ev_data6, ev_data7, ev_data8
+from "_sl_p2t2".sl_event e where (e.ev_origin = '2' and e.ev_seqno >
+'0') order by e.ev_origin, e.ev_seqno" - could not receive data from
+server: Error 0
+</screen>
+</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
+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>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>Pour le moment, je me concentre sur le problème de
+<envar>LD_LIBRARY_PATH</envar> si c'est défini, sur Solaris, pour pointer sur les
+librairies depuis une version ancienne de &postgres; afin de recompiler. Cela signifie que même si
+la base <emphasis>a été</emphasis> compilée avec l'
+<option>--enable-thread-safety</option>, et que
+<application>slon</application> a été recompilé à nouveau, avec l'édition de lien dynamique de
+<application>slon</application> pointant sur un
+<quote>ancienne mauvaise version de thread-unsafe,</quote> et alors slon n'a pas fonctionné. Ceci n'était pas clair
+que c'était le cas, jusqu'à ce que je rexécute <command>ldd</command>
+à nouveau <application>slon</application>.</para> </answer>
+
+<answer><para> A noter que la version 7.4.2 de libpq, sur Solaris exige, un nouveau patch
+de <link linkend="threadpatch"> </link> ; Le requis est également demandé pour &postgres; version 8.0.
+</para>
+</answer>
+</qandaentry>
+
+<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
+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>
+
+<para> En scrutant le fichier core avec un débuguer, 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>
+
+<para> La commande &lslonik; <xref linkend="stmtupdatefunctions"/>
+fonctionne de cette manière; dans la même transaction, essayez 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>
+</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>
+
+<para> Plusieurs contournements sont à envisager. </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>
+
+<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>
+
+<itemizedlist>
+<listitem><para> Prendre <filename>slony1_funcs.sql</filename> et faire trois remplacement 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>
+</itemizedlist>
+</listitem>
+<listitem><para> Recharger cet<quote>remis à niveau</quote> de jeux de fonctions dans la base.</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>
+</itemizedlist>
+</answer>
+</qandaentry>
+
+<qandaentry>
+<question> <para> Problème d'installation sur Fedora/x86-64 </para>
+
+<para> Lorsqu'on essaie de configurer &slony1; sur système Fedora x86-64,
+où <application>yum</application> a été utilisé pour une installation du paquetage
+<filename>postgresql-libs.x86_64</filename>, le message suivant se manifeste :
+
+<screen>
+configure: error: Your version of libpq doesn't have PQunescapeBytea
+ this means that your version of PostgreSQL is lower than 7.3
+ 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>
+</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>
+
+
+<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>
+
+<para> Eventuellement il faudra remonter ces informations vers ceux qui gèrent le paquetage
+<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>
+
+<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>
+</answer>
+
+</qandaentry>
+
+</qandadiv>
+
+<qandadiv id="faqconnections"> <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
+<qandaentry>
+
+<question><para>Je cherche le nom de<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>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>
+</answer>
+</qandaentry>
+
+<qandaentry id="morethansuper">
+<question> <para> J'ai crée 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 :
+<command>
+update pg_shadow set usesuper = 't' where usename in ('slony',
+'molly', 'dumpy');
+</command>
+(Cette même commande permet d'autoriser autres utilisateurs d'exécuter vacuums et
+sauvegarde).</para>
+
+<para> Malheureusement, je suis tombé en erreur, à chaque fois où je voulais souscrire à un nouveau ensemble.</para>
+
+<programlisting>
+DEBUG1 copy_set 28661
+DEBUG1 remoteWorkerThread_1: connected to provider DB
+DEBUG2 remoteWorkerThread_78: forward confirm 1,594436 received by 78
+DEBUG2 remoteWorkerThread_1: copy table public.billing_discount
+ERROR remoteWorkerThread_1: "select "_mycluster".setAddTable_int(28661, 51, 'public.billing_discount', 'billing_discount_pkey', 'Table public.billing_discount with candidate primary key billing_discount_pkey'); " PGRES_FATAL_ERROR ERROR: permission denied for relation pg_class
+CONTEXT: PL/pgSQL function "altertableforreplication" line 23 at select into variables
+PL/pgSQL function "setaddtable_int" line 76 at perform
+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>
+</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> La <quote>solution</quote> est la suivante:</para>
+<programlisting>
+update pg_shadow set usesuper = 't', usecatupd='t' where usename = 'slony';
+</programlisting>
+</answer>
+
+<answer><para> En version 8.1 et supérieur, vous avez aussi besoin de:</para>
+<programlisting>
+update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony';
+</programlisting>
+</answer>
+</qandaentry>
+
+<qandaentry>
+<question><para> Au moment d'enregistrer un esclave,dans le log, j'obtiens le message
+suivant :
+
+<screen>
+DEBUG1 copy_set 1
+DEBUG1 remoteWorkerThread_1: connected to provider DB
+WARN remoteWorkerThread_1: transactions earlier than XID 127314958 are still in progress
+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>
+
+<screen>
+sampledb=# select * from pg_locks where transaction is not null order by transaction;
+ relation | database | transaction | pid | mode | granted
+----------+----------+-------------+---------+---------------+---------
+ | | 127314921 | 2605100 | ExclusiveLock | t
+ | | 127326504 | 5660904 | ExclusiveLock | t
+(2 rows)
+</screen>
+
+<para>See? 127314921 est en effet plus vieux que 127314958, et il 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:
+<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>
+</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>
+
+<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>
+
+<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>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
+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>
+
+<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
+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>
+
+</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>
+<itemizedlist>
+<listitem><para> Préparer la requête</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></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> 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>
+
+</qandaentry>
+
+<qandaentry><question><para> J'ai migré mon &slony1; en version
+1.2. J'ai maintenant cet avertissement dans les logs:</para>
+
+<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.
+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>
+
+<para> La fermeture des vieilles et l'ouverture des nouvelles connexions, résous 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>
+</qandaentry>
+
+<qandaentry>
+<question><para>J'ai pointé un noeud de souscription à un 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:
+
+<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>
+</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>Malencontreusement, la réplication a été arrêtée 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 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.
+
+<programlisting>
+cluster name = oxrslive;
+ node 1 admin conninfo='host=32.85.68.220 dbname=oxrslive user=postgres port=5432';
+ node 2 admin conninfo='host=32.85.68.216 dbname=oxrslive user=postgres port=5432';
+ node 3 admin conninfo='host=32.85.68.244 dbname=oxrslive user=postgres port=5432';
+ node 4 admin conninfo='host=10.28.103.132 dbname=oxrslive user=postgres port=5432';
+try {
+ store listen (origin = 1, receiver = 3, provider = 1);
+ store listen (origin = 3, receiver = 1, provider = 3);
+ drop listen (origin = 1, receiver = 3, provider = 2);
+ drop listen (origin = 3, receiver = 1, provider = 2);
+}
+</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.
+
+Ceci précise deux principes:
+<itemizedlist>
+
+Si vous avez des noeuds multiples, 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>
+
+<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>
+</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>
+<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
+2006-03-29 16:01:34 UTC DEBUG2 slon: watchdog ready - pid = 28326
+2006-03-29 16:01:34 UTC DEBUG2 slon: worker process created - pid = 28327
+2006-03-29 16:01:34 UTC CONFIG main: local node id = 1
+2006-03-29 16:01:34 UTC DEBUG2 main: main process started
+2006-03-29 16:01:34 UTC CONFIG main: launching sched_start_mainloop
+2006-03-29 16:01:34 UTC CONFIG main: loading current cluster configuration
+2006-03-29 16:01:34 UTC CONFIG storeSet: set_id=1 set_origin=1 set_comment='test set'
+2006-03-29 16:01:34 UTC DEBUG2 sched_wakeup_node(): no_id=1 (0 threads + worker signaled)
+2006-03-29 16:01:34 UTC DEBUG2 main: last local event sequence = 7
+2006-03-29 16:01:34 UTC CONFIG main: configuration complete - starting threads
+2006-03-29 16:01:34 UTC DEBUG1 localListenThread: thread starts
+2006-03-29 16:01:34 UTC FATAL localListenThread: "select "_test1538".cleanupNodelock(); insert into "_test1538".sl_nodelock values ( 1, 0, "pg_catalog".pg_backend_pid()); " - ERROR: duplicate key violates unique constraint "sl_nodelock-pkey"
+
+2006-03-29 16:01:34 UTC FATAL Do you already have a slon running against this node?
+2006-03-29 16:01:34 UTC FATAL Or perhaps a residual idle backend connection from a dead slon?
+</screen>
+
+</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>
+
+<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>
+
+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> 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>
+
+<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;
+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>
+</qandaentry>
+
+
+<qandaentry>
+<question><para> Quand est-ce que je peux arrêter les process &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>
+
+<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
+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> 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'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
+.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>
+
+ 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 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>
+</qandaentry>
+
+<qandaentry>
+<question><para> Y a-t-il des risques pour ce faire ? Quels en 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>
+</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; -
+<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
+
+<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:
+could not open file '$libdir/xxid': No such file or directory
+</command></para></question>
+
+<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>
+
+<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>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> 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;. </para> </answer></qandaentry>
+
+<qandaentry>
+<question> <para>J'essai 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>
+
+<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>
+
+<para> Si je lance une 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></qandaentry>
+
+<qandaentry>
+<question><para>Sommaire de questions posées sur 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');
+</programlisting></para></question>
+
+<answer><para> Si vous avez <command> key =
+'nspace.key_on_whatever'</command> la demande
+<emphasis>echoura</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>
+
+<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.
+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.
+</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>
+</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>.
+
+<para> Supposez que vous souhaiter renommer une colonne, comme dans uns script sql, on utiliserais 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>
+
+<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> 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> </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>
+
+<answer> <para> Voici l'écrit d'un certain Rod Taylor 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>
+</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>
+<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.
+</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>
+</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
+&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>
+</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.
+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>
+
+<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.
+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>
+</qandaentry>
+
+
+<qandaentry> <question><para> Après notification d'un abonnement sur un
+<emphasis>autre</emphasis> noeud, la réplication échoue sur l'un des abonnés, avec le message d'erreur suivant:</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> Par la suite l'erreur est suivie par un ensemble d'<xref
+linkend="slon"/> arrêt: de syncs:</para>
+
+<screen>
+DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897518 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897519 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897520 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897521 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897522 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC
+</screen>
+
+</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> 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>
+
+</qandaentry>
+
+<qandaentry>
+
+<question><para>J'ai juste utilisé <xref linkend="stmtmoveset"/> afin de déporter le noeud d'origine sur
+un nouveau serveur. Malheureusement certains abonnés sont toujours attachés à l'ancien noeud que je viens de migrer,
+or je ne peux les mettre hors service tant qu'il n'ont pas reçu le signalement de ce changement.
+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>
+
+<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.
+
+</para></warning>
+</answer>
+</qandaentry>
+
+<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>
+
+<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:
+
+<screen>
+DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897518 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897519 SYNC
+DEBUG2 remoteListenThread_1: queue event 1,4897520 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897521 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897522 SYNC
+DEBUG2 remoteWorker_event: ignore new events due to shutdown
+DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC
+</screen>
+
+</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> 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>
+
+<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
+;vous devrez avec certitude, constater le disfonctionnement
+<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>
+<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é,
+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
+<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.
+</para>
+</answer></answer>
+
+</qandaentry>
+
+<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
+<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
+dans le scope de la transaction.</para>
+
+<programlisting>
+try {
+ echo 'Moving set 1 to node 3';
+ lock set (id=1, origin=1);
+ echo 'Set locked';
+ wait for event (origin = 1, confirmed = 3);
+ echo 'Moving set';
+ move set (id=1, old origin=1, new origin=3);
+ echo 'Set moved - waiting for event to be confirmed by node 3';
+ wait for event (origin = 1, confirmed = 3);
+ echo 'Confirmed';
+} on error {
+ echo 'Could not move set for cluster foo';
+ unlock set (id=1, origin=1);
+ exit -1;
+}
+</programlisting></question>
+
+<answer><para> Vous ne devez pas invoquer<xref linkend="stmtwaitevent"/>
+à l'intérieur d'un bloc de<quote>try</quote>.</para></answer>
+
+</qandaentry>
+
+<qandaentry>
+<question><para>Slony-I: cannot add table to currently subscribed set 1</para>
+
+<para> J'ai essayé de rajouter une table à un jeu d'ensemble et j'ai le message
+d'erreur suivant :
+
+<screen>
+ Slony-I: cannot add table to currently subscribed set 1
+</screen></para></question>
+
+<answer><para> Vous ne pouvez pas rajouter des tables à un ensemble pour lequel il y a des abonnées.
+</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>
+</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:
+
+<screen>
+stdin:9: Could not create subscription set 2 for oxrslive!
+stdin:11: PGRES_FATAL_ERROR select "_oxrslive".setAddTable(2, 1, 'public.replic_test', 'replic_test__Slony-I_oxrslive_rowID_key', 'Table public.replic_test without primary key'); - ERROR: duplicate key violates unique constraint "sl_table-pkey"
+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>
+</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,
+avec l'erreur suivante : <command>ERROR: remoteListenThread_%d: timeout
+for event selection</command> What's wrong, and what do I do? </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,
+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
+d'augmenter le délai d'expiration dans
+<filename>src/slon/remote_listener.c</filename>, de recompiler &lslon;, et enfin de ressayer. </para> </answer>
+
+<answer><para> Une autre réponse serait de conseiller de reconstruire entièrement le noeud ayant échoué,
+à l'aide de la commande &lslonik; <xref linkend="stmtdropnode"/> en le supprimant d'abord et le recréer après.
+Si les mises à jours sont volumineuses côté base de données, il vaut mieux reconstruir plutôt que d'essayer de rattraper.
+</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
+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>
+
+<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>
+
+<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
+ <link linkend="pglistenerfull">
+&pglistener; est dû au fait que la purge via vaccume 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
+ <command>
+IDLE IN TRANSACTION </command> pour une durée infinie. </para>
+
+<para> La session ouverte peut avoir des effets négatifs,
+entraînant 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>
+
+<listitem><para> Le nettoyage des processus ne pourra pas se faire
+sur 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>
+</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>
+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>
+
+<answer> <para> Vous devrez également être capable de rechercher
+les <quote> idle in transaction </quote> dans la table des processes
+ceux qui détiennent encore des transactions actives.
+ </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 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.
+
+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
+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<para>J'avis lancé I have been running &slony1; on a node for a while, and am
+s heures durant.
+</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>
+
+<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>
+
+<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>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
+linkend="table.sl-confirm"/>:
+
+<screen>
+oxrsbar=# select * from _oxrsbar.sl_confirm where con_origin not in (select no_id from _oxrsbar.sl_node) or con_received not in (select no_id from _oxrsbar.sl_node);
+ con_origin | con_received | con_seqno | con_timestamp
+------------+--------------+-----------+----------------------------
+ 4 | 501 | 83999 | 2004-11-09 19:57:08.195969
+ 1 | 2 | 3345790 | 2004-11-14 10:33:43.850265
+ 2 | 501 | 102718 | 2004-11-14 10:33:47.702086
+ 501 | 2 | 6577 | 2004-11-14 10:34:45.717003
+ 4 | 5 | 83999 | 2004-11-14 21:11:11.111686
+ 4 | 3 | 83999 | 2004-11-24 16:32:39.020194
+(6 rows)
+</screen></para>
+
+<para>En 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 :
+
+
+<screen>
+delete from _namespace.sl_confirm where con_origin = 3 or con_received = 3;
+</screen></para>
+
+<para>Sinon, pour chasser <quote>tous les fantômes,</quote> vous pouvez utiliser
+<screen>
+oxrsbar=# delete from _oxrsbar.sl_confirm where con_origin not in (select no_id from _oxrsbar.sl_node) or con_received not in (select no_id from _oxrsbar.sl_node);
+DELETE 6
+</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, <question><para>Quelque noeud commencent à prendre du retard Some nodes start consistently falling behind</para>
+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 :
+
+<itemizedlist>
+<listitem><para> Lorsque un noeud est supprimé</para></listitem>
+
+<listitem><para> Au démarrage de chaque lancement de
+<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>
+</answer>
+</qandaentry>
+
+<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
+sync.</para></question>
+
+<answer><para> Vous pourriez jeter 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>
+
+<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>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>&slony1; 1.1 fournit une procédure stockée qui permet aux comptes Synchros 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>
+
+<qandaentry id="PGLISTENERFULL">
+<question><para>Quelques noeuds commencent à se ralentir constamment. </para>
+
+<para>J'avais lancé, depuis un moment, &slony1; sur un noeud, et je vois que la machine est à
+genoux.</para>
+
+<para>Je vois des instructions en cours comme :
+<screen>
+ 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.
+
+
+Ce qui fait que l'évènement <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; 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
+<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,
+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,
+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>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>
+
+<qandaentry> <question> <para> J'ai soumis un requête <xref
+linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/>, et
+elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne mon<listitem><para> 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
+linkend="locking"> exclusifs. </link> </para>
+
+
+<para> Vous pourriez vérifier 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>
+</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
+LISTEN</quote> et <quote>UNLISTEN - switch into polling
+mode</quote>. </para> </question>
+
+Les seuils pour commuter entre ces modes sont commandés par le linkend= le " slon-config-synchro-intervalle "/>
+de <xref de paramètres de configuration et le linkend= le " slon-config-synchro-intervalle-temps mort "/>
+de <xref ; si la valeur du dépassement de durée (qui se transfère sur 10000, impliquant 10s) est le bas gardé,
+qui le rend facile pour le &lslon ; pour décider de retourner au mode de <quote>listening</quote>.
+Vous pouvez vouloir augmenter la valeur du paramètre de temps imparti
+
+<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
+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>.
+Vous devriez augmenter cette valeur d'expiration de temps. </para>
+</answer>
+</qandaentry>
+
+
+</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>
+
+<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>
+
+<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.
+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>
+
+<para> Cela mène évidemment à &lslon; d'atteindre 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>
+
+<programlisting>
+#ifdef SLON_CHECK_CMDTUPLES
+#define SLON_COMMANDS_PER_LINE 1
+#define SLON_DATA_FETCH_SIZE 100
+#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 4)
+#else
+#define SLON_COMMANDS_PER_LINE 10
+#define SLON_DATA_FETCH_SIZE 10
+#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 50)
+#endif
+</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>
+
+<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>
+
+<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>
+</listitem>
+
+
+<listitem><para> Les tuplets sont lus jusqu'à ce que la taille n'excède pas
+le paramètre <xreflinkend="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.
+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>
+</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>
+</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> 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> 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
+à 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>
+
+<para>Il y a déjà eu une discutions 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
+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> Pour plus d'information, voir la discutions<ulink url=
+"http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
+sur le groupe de discutions 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
+url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
+bug 1485 </ulink>.
+</para>
+</question>
+
+<answer><para> Apparemment le code pour
+<function>RebuildListenEntries()</function> ne suffit pas pour ce cas.</para>
+
+<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; en 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
+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"/>.
+
+</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?
+</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>
+</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.
+</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>
+
+<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>
+
+<para> Ce problème devrait être résolu un certaine temps après &slony1;
+1.1.0.</para>
+</answer>
+</qandaentry>
+
+<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;-).
+
+<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> 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>
+
+<programlisting>
+ select _slonyschema.alterTableRestore(40);
+ select _slonyschema.tableDropKey(40);
+ 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> 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>
+</answer>
+</qandaentry>
+
+<qandaentry>
+<question><para>Je dois supprimer un ordre 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>
+
+<para>Si vous êtes en version 1.0.2 ou antérieur, l'opération sera un peu plus manuel.</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.
+
+<screen>
+oxrsorg=# select * from _oxrsorg.sl_sequence where seq_id in (93,59);
+ seq_id | seq_reloid | seq_set | seq_comment
+--------+------------+---------+-------------------------------------
+ 93 | 107451516 | 1 | Sequence public.whois_cachemgmt_seq
+ 59 | 107451860 | 1 | Sequence public.epp_whoi_cach_seq_
+(2 rows)
+</screen></para>
+
+<para>Les données à supprimer, afin d'éviter que soit propager, nécessite l'arrêt de Slony :
+
+<programlisting>
+delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
+delete from _oxrsorg.sl_sequence where seq_id in (93,59);
+</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>
+
+<para>Similarly to <xref linkend="stmtsetdroptable"/>, this is
+implemented &slony1; version 1.0.5 as <xref
+linkend="stmtsetdropsequence"/>.</para></answer></qandaentry>
+
+</qandadiv>
+
+<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Hopefully Obsolete Issues </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>
+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>
+
+<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>
+
+<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
+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>Il sera utile de maintenir un script manuel pour ce genre de situation:
+
+<programlisting>
+twcsds004[/opt/twcsds004/OXRS/slony-scripts]$ cat restart_org.slonik
+cluster name = oxrsorg ;
+node 1 admin conninfo = 'host=32.85.68.220 dbname=oxrsorg user=postgres port=5532';
+node 2 admin conninfo = 'host=32.85.68.216 dbname=oxrsorg user=postgres port=5532';
+node 3 admin conninfo = 'host=32.85.68.244 dbname=oxrsorg user=postgres port=5532';
+node 4 admin conninfo = 'host=10.28.103.132 dbname=oxrsorg user=postgres port=5532';
+restart node 1;
+restart node 2;
+restart node 3;
+restart node 4;
+</programlisting></para>
+
+<para> <xref linkend="stmtrestartnode"/> nettoie les notifications mortes
+pour en suite 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
+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>
+
+</answer></qandaentry>
+
+<qandaentry><question><para> J'ai essayé la requête suivante qui ne marche pas:</para>
+
+<programlisting>
+sdb=# explain select query_start, current_query from pg_locks join
+pg_stat_activity on pid = procpid where granted = true and transaction
+in (select transaction from pg_locks where granted = false);
+
+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> Que se passe-t-il ? </para>
+
+</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.
+</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
+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,
+et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer
+le 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>
+
+<answer> <para> La nouvelle version de &slony1; (<emphasis>e.g.</emphasis>
+1.0.6, 1.1) omettra l'indicateur <command>HASHES</command>, donc ceci
+</para> </answer>
+
+<answer> <para> Supposons que vous souhaitez 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>
+/* cbbrowne@[local]/dba2 slony_test1=*/ \x
+Expanded display is on.
+/* cbbrowne@[local]/dba2 slony_test1=*/ select * from pg_operator where oprname = '='
+and oprnamespace = (select oid from pg_namespace where nspname = 'public');
+-[ RECORD 1 ]+-------------
+oprname | =
+oprnamespace | 2200
+oprowner | 1
+oprkind | b
+oprcanhash | t
+oprleft | 82122344
+oprright | 82122344
+oprresult | 16
+oprcom | 82122365
+oprnegate | 82122363
+oprlsortop | 82122362
+oprrsortop | 82122362
+oprltcmpop | 82122362
+oprgtcmpop | 82122360
+oprcode | "_T1".xxideq
+oprrest | eqsel
+oprjoin | eqjoinsel
+
+/* cbbrowne@[local]/dba2 slony_test1=*/ update pg_operator set oprcanhash = 'f' where
+oprname = '=' and oprnamespace = 2200 ;
+UPDATE 1
+</programlisting>
+</answer>
+
+</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>
+
+<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>
+
+<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>
+
+<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> &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>
+</qandaentry>
+
+<qandaentry id="dupkey">
+<question><para>La réplication échoue - Violation des Constraintes 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:
+
+<screen>
+DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
+DEBUG2 remoteWorkerThread_1: syncing set 1 with 41 table(s) from provider 1
+DEBUG2 remoteWorkerThread_1: syncing set 5 with 1 table(s) from provider 1
+DEBUG2 remoteWorkerThread_1: syncing set 3 with 1 table(s) from provider 1
+DEBUG2 remoteHelperThread_1_1: 0.135 seconds delay for first row
+DEBUG2 remoteHelperThread_1_1: 0.343 seconds until close cursor
+ERROR remoteWorkerThread_1: "insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090538', 'D', '_rserv_ts=''9275244''');
+delete from only public.epp_domain_host where _rserv_ts='9275244';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090539', 'D', '_rserv_ts=''9275245''');
+delete from only public.epp_domain_host where _rserv_ts='9275245';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090540', 'D', '_rserv_ts=''24240590''');
+delete from only public.epp_domain_contact where _rserv_ts='24240590';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090541', 'D', '_rserv_ts=''24240591''');
+delete from only public.epp_domain_contact where _rserv_ts='24240591';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090542', 'D', '_rserv_ts=''24240589''');
+delete from only public.epp_domain_contact where _rserv_ts='24240589';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090543', 'D', '_rserv_ts=''36968002''');
+delete from only public.epp_domain_status where _rserv_ts='36968002';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090544', 'D', '_rserv_ts=''36968003''');
+delete from only public.epp_domain_status where _rserv_ts='36968003';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090549', 'I', '(contact_id,status,reason,_rserv_ts) values (''6972897'',''64'','''',''31044208'')');
+insert into public.contact_status (contact_id,status,reason,_rserv_ts) values ('6972897','64','','31044208');insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090550', 'D', '_rserv_ts=''18139332''');
+delete from only public.contact_status where _rserv_ts='18139332';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090551', 'D', '_rserv_ts=''18139333''');
+delete from only public.contact_status where _rserv_ts='18139333';" ERROR: duplicate key violates unique constraint "contact_status_pkey"
+ - qualification was:
+ERROR remoteWorkerThread_1: SYNC aborted
+</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>
+
+<answer><para> Une origine <emphasis>certaine</emphasis> pour ceci est difficile à déterminer.</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>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>
+
+<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>
+
+<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
+</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>
+
+<programlisting>
+# reindex table _slonyschema.sl_log_1;
+</programlisting>
+
+<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.
+</para>
+</answer>
+</qandaentry>
+<qandaentry> <question><para>J'ai commencé à faire une sauvegarde via
+<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:
+<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> Une synchronisation de &slony1; qui veut saisir
+<command>AccessExclusiveLock</command> sur la table <xref
+linkend="table.sl-event"/>.</para></listitem> </itemizedlist></para>
+
+<para>La requête initiale qui est bloquée est :
+
+<screen>
+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
+<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
+<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui est :
+
+<programlisting>
+ LOCK TABLE %s.sl_event;
+ INSERT INTO %s.sl_event (...stuff...)
+ 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>Chaque lecture touchant
+<xref linkend="table.sl-event"/> sera bloqué derrière les appels à
+<function>createEvent</function>.</para>
+
+<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> 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>Notez que 1.0.5 utilise des verrous plus précis et moins exclusifs qui soulage 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
+&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
+linkend="stmtstoretrigger"/>. </para>
+
+<para> La fonction <xref
+linkend="function.altertableforreplication-integer"/> prépare chacune des tables
+pour la réplication.</para>
+
+<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>
+
+<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
+utilisant la fonction <function>denyAccess()</function>.</para>
+
+<para> Jusqu'à la version 1.1 (et peut-être avant), le
+<quote>désactivation</quote> est faite en modifiant
+<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>
+
+</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à,
+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>
+
+</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>
+
+<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>
+
+<screen>
+% pg_dump -h originnode.example.info -p 5432 --schema-only --schema=public ourdb > schema_backup.sql
+% pg_dump -h subscribernode.example.info -p 5432 --data-only --schema=public ourdb > data_backup.sql
+</screen>
+
+</answer>
+</qandaentry>
+
+<qandaentry> <question> <para> J'essaie de demander <xref
+linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouves
+les messages suivants sur l'un des abonnés :</para>
+
+<screen>
+NOTICE: Slony-I: multiple instances of trigger defrazzle on table frobozz
+NOTICE: Slony-I: multiple instances of trigger derez on table tron
+ERROR: Slony-I: Unable to disable triggers
+</screen>
+</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>
+
+<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>unhidden</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>
+
+<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>
+
+<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?
+</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.
+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
+ <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
+<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,
+(lorsque j'ai rencontré ce problème, il y avait une longue requête SQL devant chaque message ):</para>
+
+<screen>
+ERROR remoteWorkerThread_1: helper 1 finished with error
+ERROR remoteWorkerThread_1: SYNC aborted
+</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>
+
+<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>
+
+<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> 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>
+
+<screen>
+BEGIN;
+LOCK TABLE table_name;
+SELECT _oxrsorg.altertablerestore(tab_id);--tab_id is _slony_schema.sl_table.tab_id
+SELECT _oxrsorg.altertableforreplication(tab_id);--tab_id is _slony_schema.sl_table.tab_id
+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> Voici un exemple:</para>
+
+<screen>
+BEGIN;
+
+LOCK TABLE customer_account;
+
+SELECT _app1.altertablerestore(31);
+SELECT _app1.altertableforreplication(31);
+COMMIT;
+
+BEGIN;
+LOCK TABLE txn_log;
+
+SELECT _app1.altertablerestore(41);
+SELECT _app1.altertableforreplication(41);
+
+COMMIT;
+
+--fixing customer_account, which had an attempt to insert a "" into a timestamp with timezone.
+BEGIN;
+
+update _app1.sl_log_1 SET log_cmddata = 'balance=''60684.00'' where pkey=''49''' where log_actionseq = '67796036';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''60690.00'' where pkey=''49''' where log_actionseq = '67796194';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''60684.00'' where pkey=''49''' where log_actionseq = '67795881';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''1852.00'' where pkey=''57''' where log_actionseq = '67796403';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''87906.00'' where pkey=''8''' where log_actionseq = '68352967';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125180.00'' where pkey=''60''' where log_actionseq = '68386951';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125198.00'' where pkey=''60''' where log_actionseq = '68387055';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125174.00'' where pkey=''60''' where log_actionseq = '68386682';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125186.00'' where pkey=''60''' where log_actionseq = '68386992';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125192.00'' where pkey=''60''' where log_actionseq = '68387029';
+
+</screen>
+</listitem>
+
+</itemizedlist>
+</answer>
+
+</qandaentry>
+
+<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
+d'erreurs suivant:</para>
+
+<screen>
+ERROR remoteWorkerThread_3: "begin transaction; set transaction isolation level
+ serializable; lock table "_mailermailer".sl_config_lock; select "_mailermailer"
+.storeListen_int(2, 1, 3); notify "_mailermailer_Event"; notify "_mailermailer_C
+onfirm"; insert into "_mailermailer".sl_event (ev_origin, ev_seqno, ev_times
+tamp, ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3
+ ) values ('3', '2215', '2005-02-18 10:30:42.529048', '3286814', '3286815', ''
+, 'STORE_LISTEN', '2', '1', '3'); insert into "_mailermailer".sl_confirm
+(con_origin, con_received, con_seqno, con_timestamp) values (3, 2, '2215', CU
+RRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR: insert or updat
+e on table "sl_listen" violates foreign key constraint "sl_listen-sl_path-ref"
+DETAIL: Key (li_provider,li_receiver)=(1,3) is not present in table "sl_path".
+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>
+
+<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>
+
+<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> 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> <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>
+
+<screen>
+-# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
+BEGIN;
+-# delete from sl_event where ev_type = 'STORE_LISTEN' and
+-# (ev_data1 = '1' or ev_data2 = '1' or ev_data3 = '1');
+DELETE 3
+-# -- Seems OK...
+-# commit;
+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>
+
+</qandaentry>
+</qandadiv>
+
+</qandaset>
More information about the Trad
mailing list