root/traduc/trunk/slony/faql.xml

<?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=&lt;dir&gt;
</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,