[Trad] [svn:pgfr] r1386 - traduc/branches/slony_1_2
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 7 Sep 19:05:26 CEST 2009
Author: gleu
Date: 2009-09-07 19:05:25 +0200 (Mon, 07 Sep 2009)
New Revision: 1386
Modified:
traduc/branches/slony_1_2/faq.xml
Log:
Fin de la relecture de faq.xml \o/
Modified: traduc/branches/slony_1_2/faq.xml
===================================================================
--- traduc/branches/slony_1_2/faq.xml 2009-09-04 21:20:06 UTC (rev 1385)
+++ traduc/branches/slony_1_2/faq.xml 2009-09-07 17:05:25 UTC (rev 1386)
@@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
-<!-- Dernière modifications
+<!-- Dernière modifications
le $Date$
par $Author$
- révision $Revision$ -->
+ révision $Revision$ -->
<qandaset>
<indexterm><primary>Foire aux questions de &slony1;</primary></indexterm>
@@ -14,31 +14,31 @@
<question>
<para>
J'utilise <productname>Frotznik Freenix 4.5</productname> avec son
- système de gestion de paquetages <acronym>FFPM</acronym> (Frotznik
+ système de gestion de paquetages <acronym>FFPM</acronym> (Frotznik
Freenix Package Manager). Il existe des paquets <acronym>FFPM</acronym>
- pour &postgres; 7.4.7, que j'utilise actuellement comme base de données,
+ pour &postgres; 7.4.7, que j'utilise actuellement comme base de données,
mais il n'y a pas encore de paquetages &slony1;. Comment puis-je rajouter
- &slony1; à cette distribution ?
+ &slony1; Ã cette distribution ?
</para>
</question>
<answer>
<para>
<productname>Frotznik Freenix</productname> est nouveau pour moi, alors
- il est un peu dangereux de donner une réponse définitive, concise et
+ il est un peu dangereux de donner une réponse définitive, concise et
rapide.
</para>
<para>
- Les réponses différent légèrement selon les diverses combinaisons de
- versions entre &postgres; et &slony1; Il est légèrement plus facile,
- avec les versions récentes, de faire face à ce genre de questions
- qu'avec des versions plus anciennes. En général, vous devez presque
+ Les réponses différent légèrement selon les diverses combinaisons de
+ versions entre &postgres; et &slony1; Il est légèrement plus facile,
+ avec les versions récentes, de faire face à ce genre de questions
+ qu'avec des 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. (Savoir si vous devez <emphasis>utiliser</emphasis> la version
- compilée de &postgres; est un autre problème mais en général ce n'est
+ <emphasis>devez</emphasis> également recompiler &postgres; à partir de
+ zéro. (Savoir si vous devez <emphasis>utiliser</emphasis> la version
+ compilée de &postgres; est un autre problème mais en général ce n'est
pas le cas...)
</para>
@@ -46,42 +46,42 @@
<listitem>
<para>
- Les versions 1.0.5 et ultérieures de &slony1; nécessitent d'avoir
- une version complètement configurée des sources de &postgres; afin de
+ Les versions 1.0.5 et ultérieures de &slony1; nécessitent d'avoir
+ une version complètement configurée des sources de &postgres; afin de
recompiler &slony1;.
</para>
<para>
<emphasis>Heureusement</emphasis>, vous pouvez adapter la configuration
- pour qu'elle corresponde à la configuration utilisée nativement par le
- paquet d'origine, en vérifiant la version de &postgres; avec la
+ pour qu'elle corresponde à la configuration utilisée nativement par le
+ paquet d'origine, en vérifiant la version de &postgres; avec la
commande <command>pg_config --configure</command>.
</para>
</listitem>
<listitem>
<para>
- La version 1.1 de &slony1; simplifie considérablement les choses ;
- dans la mesure où vous êtes dispensé d'avoir la version complète des
- sources de &postgres;, au lieu de cela, elle se réfère aux emplacements
- des bibliothèques, des binaires, de la configuration et des
+ La version 1.1 de &slony1; simplifie considérablement les choses ;
+ dans la mesure où vous êtes dispensé d'avoir la version complète des
+ sources de &postgres;, au lieu de cela, elle se réfère aux emplacements
+ des bibliothèques, des binaires, de la configuration et des
<command>fichiers #include</command>.
</para>
</listitem>
<listitem>
<para>
- &postgres; 8.0 et supérieur est généralement plus facile car
- l'<quote>installation par défaut</quote> contient la totalité des
+ &postgres; 8.0 et supérieur est généralement plus facile car
+ l'<quote>installation par défaut</quote> contient la totalité des
fichiers d'inclusion <command>#include</command>.
</para>
<para>
- Si vous utilisez une version antérieure de &postgres;, il est
- préférable d'utiliser une version installée à partir des sources, en
- particulier si la version packagée ne contient pas les <quote>fichiers
+ Si vous utilisez une version antérieure de &postgres;, il est
+ préférable d'utiliser une version installée à partir des sources, en
+ particulier si la version packagée ne contient pas les <quote>fichiers
d'inclusions <command>#include</command></quote> du serveur. Ces
- fichiers peuvent être installés par la commande <command>make
+ fichiers peuvent être installés par la commande <command>make
install-all-headers</command>.
</para>
</listitem>
@@ -89,20 +89,20 @@
</itemizedlist>
<para>
- En pratique, la <quote>pire situation</quote> est un scénario où vous
- utilisez une version de &slony1; antérieure à 1.1 avec une
+ En pratique, la <quote>pire situation</quote> est un scénario où vous
+ utilisez une version de &slony1; antérieure à 1.1 avec une
<quote>vieille</quote> version de &postgres;. Dans ce cas, vous devez
- compiler &postgres; à partir de zéro afin d'avoir tous les pré-requis
- de compilation de &slony1; même si vous utilisez une version
- <quote>packagée</quote> de &postgres;.
+ compiler &postgres; à partir de zéro afin d'avoir tous les pré-requis
+ de compilation de &slony1; même si vous utilisez une version
+ <quote>packagée</quote> de &postgres;.
</para>
<para>
- Si vous utilisez une version récente de &postgres; et une version récente
- de &slony1;, alors les dépendences peuvent être assez faibles, et vous
- n'avez pas besoin de fichiers sources complémentaires.Ces améliorations
+ Si vous utilisez une version récente de &postgres; et une version récente
+ de &slony1;, alors les dépendences peuvent être assez faibles, et vous
+ n'avez pas besoin de fichiers sources complémentaires.Ces améliorations
devraient soulager la mise en production des paquets de &slony1; de sorte
- que vous pourriez même pouvoir espérer éviter la compilation de &slony1;.
+ que vous pourriez même pouvoir espérer éviter la compilation de &slony1;.
</para>
</answer>
@@ -123,14 +123,14 @@
<answer>
<para>
- Vous exécutez certainement une version 7.4 de &postgres; ou une version
- antérieure. Une version où les en-têtes de serveur ne sont pas installés
- par défaut. Dans ce cas, il vous suffit de lancer la commande
+ Vous exécutez certainement une version 7.4 de &postgres; ou une version
+ antérieure. Une version où les en-têtes de serveur ne sont pas installés
+ par défaut. Dans ce cas, il vous suffit de lancer la commande
<command>make install</command> de &postgres;.
</para>
<para>
- Vous devez installer les en-têtes du serveur lors d'installation de
+ Vous devez installer les en-têtes du serveur lors d'installation de
&postgres; via la commande <command>make install-all-headers</command>.
</para>
</answer>
@@ -140,12 +140,12 @@
<question>
<para>
&slony1; semble se compiler correctement ; maintenant, lorsque
- j'exécute un &lslon;, certains évènements se déclenchent, mais la
- réplication ne se met pas route.
+ j'exécute un &lslon;, certains évènements se déclenchent, mais la
+ réplication ne se met pas route.
</para>
<para>
- Les journaux applicatifs de Slony ressemblent à ça :
+ Les journaux applicatifs de Slony ressemblent à ça :
<screen>DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep user=postgres port=5432'
ERROR remoteListenThread_1: "select ev_origin, ev_seqno, ev_timestamp,
@@ -173,46 +173,46 @@
<answer>
<para>
Sur AIX et Solaris (et probablement sur d'autres OS), &slony1;
- <emphasis>et &postgres;</emphasis> doivent être compilés avec l'option
+ <emphasis>et &postgres;</emphasis> doivent être compilés avec l'option
<option>--enable-thread-safety</option>. Le message ci-dessus arrive
- lorsque la compilation de &postgres; n'a pas fait appel à cette option.
+ lorsque la compilation de &postgres; n'a pas fait appel à cette option.
</para>
<para>
- Le disfonctionnement ici vient du fait que la bibliothèque C (indépendante
- des threads) et la bibliothèque de &postgres;, libpq, (basée sur les
- threads) utilisent des emplacements de mémoire différents pour les codes
- d'erreur. Cela fait échouer les requêtes.
+ Le disfonctionnement ici vient du fait que la bibliothèque C (indépendante
+ des threads) et la bibliothèque de &postgres;, libpq, (basée sur les
+ threads) utilisent des emplacements de mémoire différents pour les codes
+ d'erreur. Cela fait échouer les requêtes.
</para>
<para>
- Des problèmes de ce genre surviennent avec des régularités surprenantes
- sur AIX et sur Solaris. Il sera probablement nécessaire de réaliser un
+ Des problèmes de ce genre surviennent avec des régularités surprenantes
+ sur AIX et sur Solaris. Il sera probablement nécessaire de réaliser un
<quote>audit du code objet</quote> pour s'assurer que
- <emphasis>tous</emphasis> les composants nécessaires ont été compilés
- et liés avec l'option <option>--enable-thread-safety</option>.
+ <emphasis>tous</emphasis> les composants nécessaires ont été compilés
+ et liés avec l'option <option>--enable-thread-safety</option>.
</para>
<para>
- Par exemple, on peut rencontrer un problème sur Solaris lorsque
- <envar>LD_LIBRARY_PATH</envar> est défini et pointe sur les bibliothèques
- depuis une ancienne version compilée de &postgres;. Cela signifie que
- même si la base de donnée <emphasis>avait été</emphasis> compilée avec
- l'option <option>--enable-thread-safety</option>, et même si
- <application>slon</application> a été recompilé pour cette version,
- lors de l'édition de liens dynamique, <application>slon</application>
- pointait sur une <quote>ancienne et mauvaise version compilée sans l'option
+ Par exemple, on peut rencontrer un problème sur Solaris lorsque
+ <envar>LD_LIBRARY_PATH</envar> est défini et pointe sur les bibliothèques
+ depuis une ancienne version compilée de &postgres;. Cela signifie que
+ même si la base de donnée <emphasis>avait été</emphasis> compilée avec
+ l'option <option>--enable-thread-safety</option>, et même si
+ <application>slon</application> a été recompilé pour cette version,
+ lors de l'édition de liens dynamique, <application>slon</application>
+ pointait sur une <quote>ancienne et mauvaise version compilée sans l'option
thread-safe,</quote>, slon ne fonctionne pas. On ne peut s'apercevoir de
- cela qu'en exécutant <command>ldd</command> sur
+ cela qu'en exécutant <command>ldd</command> sur
<application>slon</application>.
</para>
</answer>
<answer>
<para>
- À noter que la version 7.4.2 de libpq sur Solaris nécessite <link
- linkend="threadpatch">un patch supplémentaire pour les threads</link>.
- Ce pré-requis est également demandé pour &postgres; version 8.0.
+ À noter que la version 7.4.2 de libpq sur Solaris nécessite <link
+ linkend="threadpatch">un patch supplémentaire pour les threads</link>.
+ Ce pré-requis est également demandé pour &postgres; version 8.0.
</para>
</answer>
</qandaentry>
@@ -222,16 +222,16 @@
<question>
<para>
Je suis en train de migrer sur une nouvelle version de &slony1; et je me
- débat avec un problème sur <xref linkend="stmtupdatefunctions"/>. Lors
- de l'exécution de <xref linkend="stmtupdatefunctions"/>, mon
- <application>postmaster</application> s'arrête brutalement avec le signal
- 11. Le journal applicatif ne contient aucune erreur, exceptées celles
- relatives à &postgres;. Les journaux applicatifs indiquent simplement que
- le postmaster est bel bien arrêté.
+ débat avec un problème sur <xref linkend="stmtupdatefunctions"/>. Lors
+ de l'exécution de <xref linkend="stmtupdatefunctions"/>, mon
+ <application>postmaster</application> s'arrête brutalement avec le signal
+ 11. Le journal applicatif ne contient aucune erreur, exceptées celles
+ relatives à &postgres;. Les journaux applicatifs indiquent simplement que
+ le postmaster est bel bien arrêté.
</para>
<para>
- En scrutant le fichier core avec un déboggueur, on constate que l'incident
+ En scrutant le fichier core avec un déboggueur, on constate que l'incident
survient lors de la validation d'une transaction.
</para>
@@ -243,16 +243,16 @@
<answer>
<para>
Malheureusement, les anciennes versions de &postgres; 8.1 avaient un
- problème lors de la re-définition d'une fonction (par exemple
+ problème lors de la re-définition d'une fonction (par exemple
<function>upgradeSchema(text)</function>), lorsque la fonction est
- appellée juste après, au sein de la même transaction, le
+ appellée juste après, au sein de la même transaction, le
<application>postmaster</application> plante et la transaction est
- annulée.
+ annulée.
</para>
<para>
La commande &lslonik; <xref linkend="stmtupdatefunctions"/> fonctionne de
- cette manière ; dans une même transaction, elle effectue ceci :
+ cette manière ; dans une même transaction, elle effectue ceci :
<itemizedlist>
<listitem>
@@ -265,7 +265,7 @@
<listitem>
<para>
Lancer <function>upgradeSchema(text)</function> pour effectuer la
- migration nécessaire des schémas de la base.
+ migration nécessaire des schémas de la base.
</para>
</listitem>
<listitem>
@@ -278,8 +278,8 @@
<para>
Malheureusement, avec &postgres; 8.1.0, 8.1.1, 8.1.2, et 8.1.3, ceci est
- conflictuel avec un bogue où l'utilisation et la modification d'une
- fonction plpgsql au sein de la même transaction provoque un arrêt brutal.
+ conflictuel avec un bogue où l'utilisation et la modification d'une
+ fonction plpgsql au sein de la même transaction provoque un arrêt brutal.
</para>
<para>
@@ -289,19 +289,19 @@
<answer>
<para>
- La meilleure solution consiste à migrer &postgres; vers une version 8.1.4
- ou supérieure. Les changements entre deux versions mineures ne nécessitent
+ La meilleure solution consiste à migrer &postgres; vers une version 8.1.4
+ ou supérieure. Les changements entre deux versions mineures ne nécessitent
pas la reconstruction de la base, il suffit simplement d'installer la
- nouvelle version, puis de redémarrer le <application>postmaster</application>
+ nouvelle version, puis de redémarrer le <application>postmaster</application>
avec cette nouvelle version.
</para>
</answer>
<answer>
<para>
- Si cette solution ne convient pas, il est possible d'effectuer la mise à
- jour via une série de transactions <quote>à la main</quote>, qui
- correspondent à ce que &lslonik; aurait fait pour cette migration.
+ Si cette solution ne convient pas, il est possible d'effectuer la mise Ã
+ jour via une série de transactions <quote>à la main</quote>, qui
+ correspondent à ce que &lslonik; aurait fait pour cette migration.
</para>
<itemizedlist>
@@ -335,23 +335,23 @@
<listitem>
<para>
- Recharger dans la base cet ensemble de fonctions <quote>mises à
+ Recharger dans la base cet ensemble de fonctions <quote>mises Ã
jour</quote>.
</para>
</listitem>
<listitem>
<para>
- Exécuter la procédure stockée via <command>select
+ Exécuter la procédure 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 la 1.2.7.
+ que la précédente version de &slony1; en cours était la 1.2.7.
</para>
</listitem>
<listitem>
<para>
- Le redémarrage de tous les processus &lslon; est probablement une
- sage décision après ce genre de <quote>chirurgie.</quote>
+ Le redémarrage de tous les processus &lslon; est probablement une
+ sage décision après ce genre de <quote>chirurgie.</quote>
</para>
</listitem>
</itemizedlist>
@@ -360,11 +360,11 @@
<qandaentry>
<question>
- <para>Problème d'installation sur Fedora/x86-64</para>
+ <para>Problème d'installation sur Fedora/x86-64</para>
<para>
- Lorsqu'on essaie de configurer &slony1; sur un système Fedora x86-64,
- où <application>yum</application> a été utilisé pour une installation
+ Lorsqu'on essaie de configurer &slony1; sur un 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 :
@@ -373,51 +373,51 @@
and thus not supported by Slony-I.</screen></para>
<para>
- Ceci arrive avec &postgres; 8.2.5, qui est nettement plus récent que la
+ Ceci arrive avec &postgres; 8.2.5, qui est nettement plus récent que la
version 7.3.
</para>
</question>
<answer>
<para>
- La fonction <application>configure</application> est à la recherche du
- symbole PQunescapeBytea. Elle compile un petit programme qu'il exécute
- et vérifie que la compilation se passe bien. Dans la ligne de commande
+ La fonction <application>configure</application> est à la recherche du
+ symbole PQunescapeBytea. Elle compile un petit programme qu'il exécute
+ et vérifie que la compilation se passe bien. Dans la ligne de commande
<command>gcc</command>, elle utilise <command>-lpq</command> pour
- ajouter la bibliothèque.
+ ajouter la bibliothèque.
</para>
<para>
Malheureusement, ce paquetage n'a pas de lien symbolique, reliant
- <filename>/usr/lib64/libpq.so</filename> à
+ <filename>/usr/lib64/libpq.so</filename> Ã
<filename>libpq.so.5.0</filename> ; c'est pourquoi la fonction
- configure n'arrive pas à trouver libpq. Le <emphasis>vrai</emphasis>
- problème, c'est que le compilateur n'arrive pas à trouver une
- bibliothèque pour l'édition des liens, et non pas que libpq ait manqué
- à l'appel.
+ configure n'arrive pas à trouver libpq. Le <emphasis>vrai</emphasis>
+ problème, c'est que le compilateur n'arrive pas à trouver une
+ bibliothèque pour l'édition des liens, et non pas que libpq ait manqué
+ Ã l'appel.
</para>
<para>
- Au final, ces informations doivent être envoyée vers ceux qui gèrent
+ Au final, ces informations doivent être envoyée vers ceux qui gèrent
le paquet <filename>postgresql-libs.x86_64</filename>.
</para>
</answer>
<answer>
<para>
- Notez que ce même symptôme peut être révélateur d'autres problèmes de
- ce genre au niveau de la configuration système. Les mauvais liens
+ Notez que ce même symptôme peut être révélateur d'autres problèmes de
+ ce genre au niveau de la configuration système. Les mauvais liens
symboliques, les mauvais droits, le mauvais comportement de la part de
- votre compilateur C, tous peuvent potentiellement mener à ce même
+ votre compilateur C, tous peuvent potentiellement mener à ce même
message d'erreur.
</para>
<para>
Ainsi, si vous rencontrez cette erreur, vous aurez besoin de regarder
- le fichier de traces nommé <filename>config.log</filename>. Cherchez à
- partir du bas, et regardez quel souci est <emphasis>réellement</emphasis>
- rencontré. Ceci sera utile pour trouver la vraie racine de cet épineux
- problème.
+ le fichier de traces nommé <filename>config.log</filename>. Cherchez Ã
+ partir du bas, et regardez quel souci est <emphasis>réellement</emphasis>
+ rencontré. Ceci sera utile pour trouver la vraie racine de cet épineux
+ problème.
</para>
</answer>
</qandaentry>
@@ -706,7 +706,7 @@
</qandadiv>
<qandadiv id="faqconnections">
- <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
+ <title> &slony1; FAQ: Problèmes relatifs aux connections</title>
<qandaentry>
<question>
@@ -718,19 +718,19 @@
<answer>
<para>
- Si les DNS sont erronés, alors l'instance &lslon; ne pourra pas se
+ Si les DNS sont erronés, alors l'instance &lslon; ne pourra pas se
connecter aux nœuds.
</para>
<para>
- Ceci mène au fait que les nœuds seront introuvables.
+ Ceci mène au fait que les nœuds seront introuvables.
</para>
<para>
- Vérifier de nouveau la configuration des connexions. D'ailleurs,
- puisque <xref linkend="slon"/> est lié à libpq, vous pouvez stocker le
- mot de passe dans <filename>$HOME/.pgpass</filename>, le problème vient
- peut-être d'une erreur dans ce fichier.
+ Vérifier de nouveau la configuration des connexions. D'ailleurs,
+ puisque <xref linkend="slon"/> est lié à libpq, vous pouvez stocker le
+ mot de passe dans <filename>$HOME/.pgpass</filename>, le problème vient
+ peut-être d'une erreur dans ce fichier.
</para>
</answer>
</qandaentry>
@@ -738,21 +738,21 @@
<qandaentry id="morethansuper">
<question>
<para>
- J'ai créé un compte <quote>super-utilisateur</quote>,
- <command>slony</command>, pour exécuter les activités de réplication.
- Comme suggéré, je l'ai configuré comme super-utilisateur, avec la
- requête suivante :
+ J'ai créé un compte <quote>super-utilisateur</quote>,
+ <command>slony</command>, pour exécuter les activités de réplication.
+ Comme suggéré, je l'ai configuré comme super-utilisateur, avec la
+ requête suivante :
<command>UPDATE pg_shadow SET usesuper = 't'
WHERE usename IN ('slony', 'molly', 'dumpy');</command>
- (Cette même commande permet d'autoriser autres utilisateurs à exécuter
+ (Cette même commande permet d'autoriser autres utilisateurs à exécuter
VACUUM et sauvegardes).
</para>
<para>
- Malheureusement, j'ai eu une erreur à chaque fois où je voulais
- souscrire à un nouveau ensemble.
+ Malheureusement, j'ai eu une erreur à chaque fois où je voulais
+ souscrire à un nouveau ensemble.
</para>
<programlisting>DEBUG1 copy_set 28661
@@ -765,16 +765,16 @@
WARN remoteWorkerThread_1: data copy for set 28661 failed - sleep 60 seconds</programlisting>
<para>
- Cela continue de s'arrêter avec une erreur, encore et toujours, jusqu'à
- ce que je redémarre <application>slon</application> pour qu'il se
+ Cela continue de s'arrêter avec une erreur, encore et toujours, jusqu'Ã
+ ce que je redémarre <application>slon</application> pour qu'il se
connecte avec le compte <command>postgres</command>.
</para>
</question>
<answer>
<para>
- Le problème est assez évident en soi ; le droit sur la table
- système <envar>pg_class</envar> est ignoré.
+ Le problème est assez évident en soi ; le droit sur la table
+ système <envar>pg_class</envar> est ignoré.
</para>
</answer>
@@ -789,7 +789,7 @@
<answer>
<para>
- En version 8.1 et supérieure, vous avez aussi besoin de :
+ En version 8.1 et supérieure, vous avez aussi besoin de :
</para>
<programlisting>UPDATE pg_authid SET rolcatupdate = 't', rolsuper='t'
@@ -812,9 +812,9 @@
<answer>
<para>
- Il y a évidemment un certain nombre de vieilles transactions qui
- empêchent &slony1; de traiter des synchronisations. Vous devriez
- jeter un coup d'œil à pg_locks pour voir ce qu'il en est :
+ Il y a évidemment un certain nombre de vieilles transactions qui
+ empêchent &slony1; de traiter des synchronisations. Vous devriez
+ jeter un coup d'œil à pg_locks pour voir ce qu'il en est :
</para>
<screen>sampledb=# select * from pg_locks where transaction is not null order by transaction;
@@ -826,15 +826,15 @@
<para>
Vous voyez ? la transaction 127314921 est en effet plus vieille
- que la transaction 127314958, et elle est toujours en cours d'exécution.
+ que la transaction 127314958, et elle est toujours en cours d'exécution.
</para>
<para>
- Un long traitement de publi-postage, une requête
+ Un long traitement de publi-postage, une requête
<application>RT3</application> qui s'emballe, un
- <application>pg_dump</application>, toutes ces opérations ouvrent des
- transactions pour une période importante. Jusqu'à ce qu'elles soient
- complétées ou bien interrompues, on verra alors le message d'erreur
+ <application>pg_dump</application>, toutes ces opérations ouvrent des
+ transactions pour une période importante. Jusqu'à ce qu'elles soient
+ complétées ou bien interrompues, on verra alors le message d'erreur
suivant :
<quote>data copy
@@ -842,12 +842,12 @@
</para>
<para>
- Quoiqu'il en soit, s'il y a plus d'une base de données sur le cluster
+ Quoiqu'il en soit, s'il y a plus d'une base de données sur le cluster
&postgres; et que la charge se situe sur une autre base, vous verrez
- apparaître des <quote>transactions en cours avec un XID
- antérieur</quote> à celle de &slony1;. Le fait que la transaction se
- déroule sur une base de donnée dissociée ne change rien ; &slony1;
- attendra jusqu'à ce que ces vieilles transactions se terminent.
+ apparaître des <quote>transactions en cours avec un XID
+ antérieur</quote> à celle de &slony1;. Le fait que la transaction se
+ déroule sur une base de donnée dissociée ne change rien ; &slony1;
+ attendra jusqu'Ã ce que ces vieilles transactions se terminent.
</para>
</answer>
</qandaentry>
@@ -855,15 +855,15 @@
<qandaentry>
<question>
<para>
- Même question que précèdemment. J'ai oublié de mentionner que
- j'essayais d'ajouter <emphasis>DEUX</emphasis> abonnés simultanément.
+ Même question que précèdemment. J'ai oublié de mentionner que
+ j'essayais d'ajouter <emphasis>DEUX</emphasis> abonnés simultanément.
</para>
</question>
<answer>
<para>
Cela ne peut pas fonctionner : &slony1; ne peut employer pas la
- commande <command>COPY</command> de manière concurrente. Voir la
+ commande <command>COPY</command> de manière concurrente. Voir la
fonction <function>copy_set()</function> dans le fichier
<filename>src/slon/remote_worker.c</filename>.
</para>
@@ -873,18 +873,18 @@
<para>
Une transaction <command>COPY</command> essaie d'installer l'abonnement
- pour un des nœuds. Tout a l'air bien ; le système s'occupe
- de configurer le premier abonné ; il ne va pas démarrer sur le
+ pour un des nœuds. Tout a l'air bien ; le système s'occupe
+ de configurer le premier abonné ; il ne va pas démarrer sur le
second tant que le premier n'a pas fini son enregistrement. Cela
- représente une cause possible.
+ représente une cause possible.
</para>
<para>
- Ceci a comme (fâcheuse) conséquence que vous ne pouvez pas peupler deux
- esclaves simultanément à partir d'un même fournisseur. Vous devez
- souscrire un et un seul abonné à la fois. Une fois qu'il a accompli
+ Ceci a comme (fâcheuse) conséquence que vous ne pouvez pas peupler deux
+ esclaves simultanément à partir d'un même fournisseur. Vous devez
+ souscrire un et un seul abonné à la fois. Une fois qu'il a accompli
l'abonnement (en copiant le contenu des table, etc.), on peut s'occuper
- de débuter l'enregistrement du deuxième.
+ de débuter l'enregistrement du deuxième.
</para>
</answer>
</qandaentry>
@@ -892,8 +892,8 @@
<qandaentry id="missingoids">
<question>
<para>
- Nous avons rencontré un message inattendu en désinstallant entièrement
- un cluster de réplication slony sur le maître et l'esclave.
+ Nous avons rencontré un message inattendu en désinstallant entièrement
+ un cluster de réplication slony sur le maître et l'esclave.
</para>
<warning>
@@ -913,13 +913,13 @@
<answer>
<para>
- Il y a deux mécanismes de &postgres; qui mettent en cache les plans
+ Il y a deux mécanismes de &postgres; qui mettent en cache les plans
d'interrogation et les OIDs :
</para>
<itemizedlist>
<listitem>
- <para>les requêtes préparées (« prepared statements ») ;</para>
+ <para>les requêtes préparées (« prepared statements ») ;</para>
</listitem>
<listitem>
<para>les fonctions PL/pgsql.</para>
@@ -927,36 +927,36 @@
</itemizedlist>
<para>
- Ce problème n'est pas particulier à &slony1;; il se produit à chaque
- fois que des modifications importantes sont apportées aux schémas de
- la base de données. Cela n'entraîne pas de perte des données mais cela
+ Ce problème n'est pas particulier à &slony1;; il se produit à chaque
+ fois que des modifications importantes sont apportées aux schémas de
+ la base de données. Cela n'entraîne pas de perte des données mais cela
provoque des vagues d'erreurs relatives aux OID.
</para>
</answer>
<answer>
<para>
- Le problème survient lorsque vous utilisez une sorte de <quote>pool de
+ Le problème survient lorsque vous utilisez une sorte de <quote>pool de
connexion</quote> qui recycle les vieilles connexions. Si vous relancez
- l'application après ceci, les nouvelles connexions vont produire de
- <emphasis>nouveaux</emphasis> plans d'exécution et les erreurs
- disparaîtront. Si votre pool de connexion tue les sessions et en
- recrée de nouvelles, alors ces nouvelles sessions auront de
- <emphasis>nouveaux</emphasis> plans d'exécution et les erreurs disparaîtront.
+ l'application après ceci, les nouvelles connexions vont produire de
+ <emphasis>nouveaux</emphasis> plans d'exécution et les erreurs
+ disparaîtront. Si votre pool de connexion tue les sessions et en
+ recrée de nouvelles, alors ces nouvelles sessions auront de
+ <emphasis>nouveaux</emphasis> plans d'exécution et les erreurs disparaîtront.
</para>
</answer>
<answer>
<para>
- Dans notre code, nous éliminons toutes connexions ayant des erreurs
+ Dans notre code, nous éliminons toutes connexions ayant des erreurs
inattendues dans le contexte. Ainsi, toutes les connexions devraient
- être renouvelées dès l'apparition d'une erreur inattendue.
+ être renouvelées dès l'apparition d'une erreur inattendue.
Naturellement, si l'erreur remonte une violation de contrainte, qui est
une condition reconnue, cela va provoquer un renouvellement de connexion.
- Si le problème persiste, les connexions sont recyclées en permanence,
+ Si le problème persiste, les connexions sont recyclées en permanence,
ce qui annulera l'effet du pool. Dans ce cas, le pooler de connexion
- proposera probablement à l'administrateur de jeter un coup d'œil
- à la situation.
+ proposera probablement à l'administrateur de jeter un coup d'œil
+ Ã la situation.
</para>
</answer>
</qandaentry>
@@ -964,7 +964,7 @@
<qandaentry>
<question>
<para>
- J'ai migré mon &slony1; en version 1.2. J'ai maintenant cet
+ J'ai migré mon &slony1; en version 1.2. J'ai maintenant cet
avertissement dans les journaux applicatifs :
</para>
@@ -973,31 +973,31 @@
<para>
Les tables <envar>sl_log_1</envar> et <envar>sl_log_2</envar>
continuent de prendre du volume, et <envar>sl_log_1</envar> n'est
- jamais vidée. Quel est le souci ?
+ jamais vidée. Quel est le souci ?
</para>
</question>
<answer>
<para>
- Ceci est un cas symptomatique du problème précèdent, relatif à la
- suppression de la réplication : s'il y a des vieilles connexions
- établies, qui continuent à utiliser des plan d'exécutions basés sur
- des vieilles procédures stockées, cela provoque des écritures dans
+ Ceci est un cas symptomatique du problème précèdent, relatif à la
+ suppression de la réplication : s'il y a des vieilles connexions
+ établies, qui continuent à utiliser des plan d'exécutions basés sur
+ des vieilles procédures stockées, cela provoque des écritures dans
<envar>sl_log_1</envar>.
</para>
<para>
La fermeture des vieilles connexions et l'ouverture de nouvelles
- connexions résoudra ce problème.
+ connexions résoudra ce problème.
</para>
</answer>
<answer>
<para>
- À plus long terme, un élément de la liste des choses à faire pour
- &postgres; est l'implantation d'une vérification des dépendances, qui
- pourra supprimer un plan d'exécution caché lorsqu'un objet lié à ce
- plan est modifié.
+ À plus long terme, un élément de la liste des choses à faire pour
+ &postgres; est l'implantation d'une vérification des dépendances, qui
+ pourra supprimer un plan d'exécution caché lorsqu'un objet lié à ce
+ plan est modifié.
</para>
</answer>
</qandaentry>
@@ -1005,14 +1005,14 @@
<qandaentry>
<question>
<para>
- J'ai pointé un nœud abonné vers un nœud fournisseur différent,
- et il a cessé la réplication.
+ J'ai pointé un nœud abonné vers un nœud fournisseur différent,
+ et il a cessé la réplication.
</para>
</question>
<answer>
<para>
- Nous avons constaté que ceci arrive lorsque on réinitialise un
+ Nous avons constaté que ceci arrive lorsque on réinitialise un
nœud dans la configuration suivante :
<itemizedlist>
@@ -1021,44 +1021,44 @@
</listitem>
<listitem>
<para>
- Nœud 2 - abonné au nœud 1 - le nœud que l'on
- réinitialise
+ Nœud 2 - abonné au nœud 1 - le nœud que l'on
+ réinitialise
</para>
</listitem>
<listitem>
<para>
- Nœud 3 - abonné au nœud 3 - le nœud qui doit
- continuer à répliquer
+ Nœud 3 - abonné au nœud 3 - le nœud qui doit
+ continuer à répliquer
</para>
</listitem>
</itemizedlist>
</para>
<para>
- L'abonnement du nœud 3 est changé pour que le nœud 1 soit
- son fournisseur et on exécute <xref linkend="stmtdropset"/> / <xref
+ L'abonnement du nœud 3 est changé pour que le nœud 1 soit
+ son fournisseur et on exécute <xref linkend="stmtdropset"/> / <xref
linkend="stmtsubscribeset"/> sur le nœud 2 pour qu'il soit
- repeuplé.
+ repeuplé.
</para>
<para>
- Malheureusement, la réplication s'arrête soudainement sur le nœud
+ Malheureusement, la réplication s'arrête soudainement sur le nœud
3.
</para>
<para>
- Le problème vient du fait qu'il n'y a pas d'ensemble approprié de
- <quote>voies d'écoute</quote> dans la table <xref
- linkend="table.sl-listen"/> pour propager les évènements depuis le
- nœud 1 vers le nœud 3. Les événements sont transportés vers
- le nœud 2 et sont bloqués par l'événement <xref
+ Le problème vient du fait qu'il n'y a pas d'ensemble approprié de
+ <quote>voies d'écoute</quote> dans la table <xref
+ linkend="table.sl-listen"/> pour propager les évènements depuis le
+ nœud 1 vers le nœud 3. Les événements sont transportés vers
+ le nœud 2 et sont bloqués par l'événement <xref
linkend="stmtsubscribeset"/> que le nœud 2 est en train de
traiter.
</para>
<para>
- Le script suivant supprime les voies d'écoute qui font transiter les
- événements par le nœud 2 et ajoute une voie d'écoute directe
+ Le script suivant supprime les voies d'écoute qui font transiter les
+ événements par le nœud 2 et ajoute une voie d'écoute directe
entre les nœuds 1 et 3.
<programlisting>cluster name = oxrslive;
@@ -1074,31 +1074,31 @@
}</programlisting></para>
<para>
- Juste après l'exécution de ce script, les événements
- <command>SYNC</command> se propagent à nouveau vers le nœud 3.
+ Juste après l'exécution de ce script, les événements
+ <command>SYNC</command> se propagent à nouveau vers le nœud 3.
Ceci souligne deux principes :
<itemizedlist>
<listitem>
<para>
- Si vous avez plusieurs nœuds et des abonnés en cascade,
- vous devez faire attention en repeuplant les entrées <xref
+ Si vous avez plusieurs nœuds et des abonnés en cascade,
+ vous devez faire attention en repeuplant les entrées <xref
linkend="stmtstorelisten"/> et en les modifiant si la structure
- de l'<quote>arbre</quote> de réplication a changé.
+ de l'<quote>arbre</quote> de réplication a changé.
</para>
</listitem>
<listitem>
<para>
- La version 1.1 fourni des meilleurs outils pour gérer ce cas.
+ La version 1.1 fourni des meilleurs outils pour gérer ce cas.
</para>
</listitem>
</itemizedlist>
</para>
<para>
- Les problèmes relatifs aux <quote>voies d'écoute</quote> sont discutés
- avec plus de précisions dans la section <xref linkend="listenpaths"/>.
+ Les problèmes relatifs aux <quote>voies d'écoute</quote> sont discutés
+ avec plus de précisions dans la section <xref linkend="listenpaths"/>.
</para>
</answer>
</qandaentry>
@@ -1106,7 +1106,7 @@
<qandaentry id="multipleslonconnections">
<question>
<para>
- En redémarrant &lslon;, j'obtiens les messages <quote>FATAL</quote>
+ En redémarrant &lslon;, j'obtiens les messages <quote>FATAL</quote>
suivants dans les journaux applicatifs. Que se passe-t-il ?
</para>
@@ -1132,51 +1132,51 @@
<answer>
<para>
- La table <envar>sl_nodelock</envar> est utilisée comme un <quote>verrou
- partagé</quote> pour empêcher que deux processus &lslon; essaient de
- prendre le controle du même nœud en même temps. Le &lslon; essaie
- d'insérer un enregistrement dans la table ; il ne peut réussir que
- s'il est le seul à gérer le nœud.
+ La table <envar>sl_nodelock</envar> est utilisée comme un <quote>verrou
+ partagé</quote> pour empêcher que deux processus &lslon; essaient de
+ prendre le controle du même nœud en même temps. Le &lslon; essaie
+ d'insérer un enregistrement dans la table ; il ne peut réussir que
+ s'il est le seul à gérer le nœud.
</para>
</answer>
<answer>
<para>
- Ce message d'erreur est typiquement un signe que vous avez démarrez un
- second processus &lslon; pour un nœud donné. Le &lslon; pose la
- question évidente suivante : <quote>avez-vous déjà un slon démarré
- pour gérer ce nœud ?</quote>
+ Ce message d'erreur est typiquement un signe que vous avez démarrez un
+ second processus &lslon; pour un nœud donné. Le &lslon; pose la
+ question évidente suivante : <quote>avez-vous déjà un slon démarré
+ pour gérer ce nœud ?</quote>
</para>
</answer>
<answer>
<para>
- En supposant que vous subissez une panne réseau, les connections entre
- &lslon; et la base de données peuvent échouer et &lslon; peut s'en
+ En supposant que vous subissez une panne réseau, les connections entre
+ &lslon; et la base de données peuvent échouer et &lslon; peut s'en
apercevoir bien avant l'instance de &postgres; sur laquelle il est
- connecté. La conséquence en est qu'un certain nombre de connexions
- pré-établies vont rester ouvertes sur la base de données jusqu'à ce
- que le timeout TCP/IP arrive à échéance, chose qui normalement arrive
- au bout de deux heures. Durant cette période de deux heures, le &lslon;
+ connecté. La conséquence en est qu'un certain nombre de connexions
+ pré-établies vont rester ouvertes sur la base de données jusqu'à ce
+ que le timeout TCP/IP arrive à échéance, chose qui normalement arrive
+ au bout de deux heures. Durant cette période de deux heures, le &lslon;
va essayer de se reconnecter, encore et encore, et fait que vous
obtenez le message d'erreur ci-dessous, encore et encore.
</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 bloquantes. Malheureusement, puisque le problème a eu lieu
- au niveau de la couche réseau, &postgres; et &slony1; n'ont aucun
- moyen direct de détecter ceci.
+ 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 bloquantes. Malheureusement, puisque le problème a eu lieu
+ au niveau de la couche réseau, &postgres; et &slony1; n'ont aucun
+ moyen direct de détecter ceci.
</para>
<para>
- Vous pouvez éviter ceci dans la <emphasis>plupart</emphasis> des cas
- en vous assurant que le processus &lslon; est hébergé à proximité des
- serveurs qu'il gère. Si le &lslon; est hébergé sur le même serveur que
- la base de donnée qu'il gère, alors toute <quote>panne réseau</quote>
- qui peut interrompre les connexions serait susceptible d'être assez
- sérieus pour menacer le serveur entier.
+ Vous pouvez éviter ceci dans la <emphasis>plupart</emphasis> des cas
+ en vous assurant que le processus &lslon; est hébergé à proximité des
+ serveurs qu'il gère. Si le &lslon; est hébergé sur le même serveur que
+ la base de donnée qu'il gère, alors toute <quote>panne réseau</quote>
+ qui peut interrompre les connexions serait susceptible d'être assez
+ sérieus pour menacer le serveur entier.
</para>
</answer>
</qandaentry>
@@ -1184,67 +1184,67 @@
<qandaentry>
<question>
<para>
- Quand puis-je arrêter les processus &lslon; ?
+ Quand puis-je arrêter les processus &lslon; ?
</para>
</question>
<answer>
<para>
- Généralement, il n'y a aucun risque à arrêter un processus &lslon;.
+ Généralement, il n'y a aucun risque à arrêter un processus &lslon;.
Chacun d'eux est <quote>simplement</quote> un client de &postgres;,
- gérant un nœud, qui déploie des threads pour gérer et recevoir
- des évènements depuis d'autres nœuds.
+ gérant un nœud, qui déploie des threads pour gérer et recevoir
+ des évènements depuis d'autres nœuds.
</para>
<para>
- Les threads des <quote>évènements d'écoute</quote> ne sont pas très
- importants ; ils ne font que vérifier de temps en temps les
- nœuds distants pour déterminer s'il y a des taches à faire sur
+ Les threads des <quote>évènements d'écoute</quote> ne sont pas très
+ importants ; ils ne font que vérifier de temps en temps les
+ nœuds distants pour déterminer s'il y a des taches à faire sur
le nœud local. Si vous tuez le processus &lslon; ces threads de
- surveillance seront fermés, ce qui aura peu ou pas du tout d'impact.
- Les événements produits pendant que &lslon; est arrêté seront récupérés
- lors de son redémarrage.
+ surveillance seront fermés, ce qui aura peu ou pas du tout d'impact.
+ Les événements produits pendant que &lslon; est arrêté seront récupérés
+ lors de son redémarrage.
</para>
<para>
Le thread de <quote>gestion des nœuds</quote> est un peu plus
- intéressant ; la plupart du temps, sur un abonné, on peut
- s'attendre à ce que le thread traite des événements
- <command>SYNC</command>. Si vous arrêtez le &lslon; durant un évènement,
- la transaction va échouer et s'annuler. Lorsque &lslon; redémarre, il
- reprendra l'évènement pour l'exécuter.
+ intéressant ; la plupart du temps, sur un abonné, on peut
+ s'attendre à ce que le thread traite des événements
+ <command>SYNC</command>. Si vous arrêtez le &lslon; durant un évènement,
+ la transaction va échouer et s'annuler. Lorsque &lslon; redémarre, il
+ reprendra l'évènement pour l'exécuter.
</para>
<para>
- L'unique situation où cela peut provoquer des problèmes
- <emphasis>particulièrs</emphasis> est lorsque l'évènement en cours est
- un traitement de longue durée comme un <command>COPY_SET</command> pour
- un large ensemble de réplication.
+ L'unique situation où cela peut provoquer des problèmes
+ <emphasis>particulièrs</emphasis> est lorsque l'évènement en cours est
+ un traitement de longue durée comme un <command>COPY_SET</command> pour
+ un large ensemble de réplication.
</para>
<para>
- L'autre chose qui <emphasis>pourrait</emphasis> poser problème
+ L'autre chose qui <emphasis>pourrait</emphasis> poser problème
est s'il est relativement distant du nœud auxquel il est
- connecté ; vous pouvez découvrir que les connexions de la base
- de données sont laissées <command>disponibles en transaction</command>
- (« idle in transaction »). Ceci peut survenir si les
- connexions réseaux sont supprimées sans que ni &lslon; ni la base en
- aient pris connaissance. Dans ce cas, vous pouvez découvrir que des
- connexions <quote>zombies</quote> traînent encore durant deux longues
- heures si vous n'allez pas tuer à la main les processus &postgres;.
+ connecté ; vous pouvez découvrir que les connexions de la base
+ de données sont laissées <command>disponibles en transaction</command>
+ (« idle in transaction »). Ceci peut survenir si les
+ connexions réseaux sont supprimées sans que ni &lslon; ni la base en
+ aient pris connaissance. Dans ce cas, vous pouvez découvrir que des
+ connexions <quote>zombies</quote> traînent encore durant deux longues
+ heures si vous n'allez pas tuer à la main les processus &postgres;.
</para>
<para>
- Il y existe un autre cas qui peut poser problème : quand le
+ Il y existe un autre cas qui peut poser problème : quand le
processus &lslon; qui administre le nœud origine ne fonctionne
- pas, aucun évènement <command>SYNC</command> ne s'exécute sur ce
- nœud. Si le &lslon; reste arrêté pendant une longue durée et
+ pas, aucun évènement <command>SYNC</command> ne s'exécute sur ce
+ nœud. Si le &lslon; reste arrêté pendant une longue durée et
qu'aucun processus de type <xref linkend="gensync"/> n'est en cours,
- alors vous pouvez vous retrouver avec <emphasis>un énorme
- <command>SYNC</command></emphasis> à effectuer lorsque le processus
- &lslon; du nœud origine sera relancé. Toutefois, ceci est vrai
- seulement si &lslon; est en arrêt pendant une période assez
- longue ; un arrêt de quelques secondes ne génère pas de problèmes.
+ alors vous pouvez vous retrouver avec <emphasis>un énorme
+ <command>SYNC</command></emphasis> Ã effectuer lorsque le processus
+ &lslon; du nœud origine sera relancé. Toutefois, ceci est vrai
+ seulement si &lslon; est en arrêt pendant une période assez
+ longue ; un arrêt de quelques secondes ne génère pas de problèmes.
</para>
</answer>
</qandaentry>
@@ -1252,7 +1252,7 @@
<qandaentry>
<question>
<para>
- Y a-t-il des risques lorsqu'on arrête &lslon; ? Quels sont les
+ Y a-t-il des risques lorsqu'on arrête &lslon; ? Quels sont les
avantages ?
</para>
</question>
@@ -1260,8 +1260,8 @@
<answer>
<para>
En bref, si un <command>COPY_SET</command> qui dure 18h n'est pas en
- cours d'exécution, alors ce n'est pas un grand sacrifice d'arrêter un
- &lslon; pendant quelques instants, ni même de relancer
+ cours d'exécution, alors ce n'est pas un grand sacrifice d'arrêter un
+ &lslon; pendant quelques instants, ni même de relancer
<emphasis>tous</emphasis> les &lslon;.
</para>
</answer>
@@ -1269,18 +1269,18 @@
</qandadiv>
<qandadiv id="faqconfiguration">
- <title>FAQ &slony1; : Problèmes de configuration</title>
+ <title>FAQ &slony1; : Problèmes de configuration</title>
<qandaentry>
<question>
<para>
- Slonik échoue lors du chargement des bibliothèques &postgres; :
+ Slonik échoue lors du chargement des bibliothèques &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 à :
+ 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>
@@ -1289,38 +1289,38 @@
<answer>
<para>
- Évidemment, vous n'avez pas accès à la bibliothèque
- <filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
+ Évidemment, vous n'avez pas accès à la bibliothèque
+ <filename>xxid.so</filename> dans le répertoire <envar>$libdir</envar>
que l'instance &postgres; utilise. Notez que les composants &slony1;
- doivent être installés avec le noyau &postgres; sur <emphasis>chacun
+ doivent être installés avec le noyau &postgres; sur <emphasis>chacun
des nœuds</emphasis> et pas seulement sur le nœud d'origine.
</para>
<para>
- Cela peut également venir du fait d'une disparité entre les binaires
+ Cela peut également venir du fait d'une disparité entre les binaires
du noyau &postgres; et celui du noyau de &slony1;. Si vous avez
- manuellement compilé &slony1; par vous-même, sur une machine où il y
+ manuellement compilé &slony1; par vous-même, sur une machine où il y
a plusieurs versions de &postgres;, il est possible que les binaires
- slon ou slonik demande de charger une bibliothèque qui n'est pas
- accessible dans les répertoires des bibliothèques de la version de
- &postgres; utilisée.
+ slon ou slonik demande de charger une bibliothèque qui n'est pas
+ accessible dans les répertoires des bibliothèques de la version de
+ &postgres; utilisée.
</para>
<para>
En deux mots : ceci indique que vous devez <quote>auditer</quote>
l'installation des instances &postgres; et &slony1; qui sont en place
- sur la machine. Malheureusement, n'importe quelle incompatibilité peut
+ sur la machine. Malheureusement, n'importe quelle incompatibilité peut
faire remonter ce genre d'erreur. Voir aussi la <link
- linkend="threadsafety">sécurité des threads</link> à propos de la
+ linkend="threadsafety">sécurité des threads</link> à propos de la
gestion des threads sur Solaris.
</para>
<para>
La situation est plus simple si vous avez une seule version de
- &postgres; installée par serveur ; dans ce cas, il n'y aura pas
- d'<quote>incompatibilité de chemins</quote> là où les composants de
- &slony1; sont installés. Si vous avez une installation multiple, vous
- devrez vous assurer que la bonne version de &slony1; est associée à la
+ &postgres; installée par serveur ; dans ce cas, il n'y aura pas
+ d'<quote>incompatibilité de chemins</quote> là où les composants de
+ &slony1; sont installés. Si vous avez une installation multiple, vous
+ devrez vous assurer que la bonne version de &slony1; est associée à la
bonne version du noyau de &postgres;.
</para>
</answer>
@@ -1329,21 +1329,21 @@
<qandaentry>
<question>
<para>
- J'essaie de créer un cluster dont le nom contient un tiret. Cela ne
+ J'essaie de créer un cluster dont le nom contient un tiret. Cela ne
fonctionne pas.
</para>
</question>
<answer>
<para>
- &slony1; utilise les mêmes règles de nommage que &postgres;, donc vous
+ &slony1; utilise les mêmes règles de nommage que &postgres;, donc vous
ne devriez pas utiliser un tiret dans les identifiants.
</para>
<para>
Vous pouvez tenter de mettre des simples <quote>guillemets</quote> pour
- l'identifiant, mais vous allez vous exposer à des soucis qui pourront
- surgir à tout moment.
+ l'identifiant, mais vous allez vous exposer à des soucis qui pourront
+ surgir à tout moment.
</para>
</answer>
</qandaentry>
@@ -1356,7 +1356,7 @@
<para>
Avec la commande <command>ps</command>, tout le monde peut voir le mot
- de passe qui a été fourni sur la ligne de commande.
+ de passe qui a été fourni sur la ligne de commande.
</para>
</question>
@@ -1383,7 +1383,7 @@
<answer>
<para>
Si vous avez <command> key = 'nspace.clef_sur_une_colonne'</command>,
- la requête <emphasis>échouera</emphasis>.
+ la requête <emphasis>échouera</emphasis>.
</para>
</answer>
</qandaentry>
@@ -1391,21 +1391,21 @@
<qandaentry>
<question>
<para>
- La réplication est retardée, et il semble que les requêtes sur les
+ La réplication est retardée, et il semble que les requêtes sur les
tables &sllog1;/&sllog2; prennent beaucoup de temps alors qu'il n'y a
- que quelques événements <command>SYNC</command>.
+ que quelques événements <command>SYNC</command>.
</para>
</question>
<answer>
<para>
- Jusqu'à la version 1.1.1, les tables &sllog1;/&sllog2; possédaient
+ Jusqu'à la version 1.1.1, les tables &sllog1;/&sllog2; possédaient
seulement un index, et lorsqu'il y avait plusieurs ensembles de
- réplication, quelques colonnes dans l'index n'étaient pas assez
+ réplication, quelques colonnes dans l'index n'étaient pas assez
discriminantes. Si l'index ne contient pas la colonne
- <function>log_xid</function>, il est conseillé de l'ajouter. Voir le
- script <filename>slony1_base.sql</filename> pour regarder la manière
- de créer cet index.
+ <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 cet index.
</para>
</answer>
</qandaentry>
@@ -1414,48 +1414,48 @@
<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 est un peu dangereuse,
- n'est-ce pas ? Je dois retirer la table de la réplication puis la
- replacer, c'est bien ça ?
+ pour l'une de mes tables répliquées. L'opération est un peu dangereuse,
+ n'est-ce pas ? Je dois retirer la table de la réplication puis la
+ replacer, c'est bien ça ?
</para>
</question>
<answer>
<para>
- En fait, cette opération fonctionne proprement. &slony1; fait un usage
- intensif des clefs primaires mais, en pratique, ce type d'opération
- peut se faire de manière transparente.
+ En fait, cette opération fonctionne proprement. &slony1; fait un usage
+ intensif des clefs primaires mais, en pratique, ce type d'opération
+ peut se faire de manière transparente.
</para>
<para>
Supposons que vous souhaitez renommer une colonne, avec la commande DDL
suivante <command>ALTER TABLE accounts ALTER COLUMN aid RENAME TO
cid;</command>. Ceci permet de renommer la colonne dans la table ;
- elle permet de mettre à jour <emphasis>simultanément</emphasis> l'index
- de la clef primaire. Le résultat est que ce genre de changement
- s'effectue simultanément sur un nœud donné.
+ elle permet de mettre à jour <emphasis>simultanément</emphasis> l'index
+ de la clef primaire. Le résultat est que ce genre de changement
+ s'effectue simultanément sur un nœud donné.
</para>
<para>
Dans l'<emphasis>ideal</emphasis> et pour bien faire les choses, il
- aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer
+ aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer
la modification au bon moment sur chaque nœud.
</para>
<para>
- Toutefois, ce n'est pas forcément nécessaire. Tant que la modification
- est appliquée sur le nœud origine avant d'être effectuée sur les
- abonnés, il n'y aura pas de cassure irrémédiable. Certains évènements
+ Toutefois, ce n'est pas forcément nécessaire. Tant que la modification
+ est appliquée sur le nœud origine avant d'être effectuée sur les
+ abonnés, il n'y aura pas de cassure irrémédiable. Certains évènements
<command>SYNC</command> qui n'incluent pas la table sur laquelle il y
- a la modification, pourront fonctionner sans problème... Par contre,
- lorsqu'une mise à jour de la table est effectuée sur un abonné, alors
- les événements <command>SYNC</command> vont échouer puisque le
+ a la modification, pourront fonctionner sans problème... Par contre,
+ lorsqu'une mise à jour de la table est effectuée sur un abonné, alors
+ les événements <command>SYNC</command> vont échouer puisque le
fournisseur indiquera une <quote>nouvelle</quote> colonne alors que
- l'abonné connait toujours les <quote>anciennes</quote>. Dès que l'on
- appliquera la modification de la clef chez l'abonné, les événements
- <command>SYNC</command> seront traités de nouveau et le
- <quote>nouveau</quote> nom de colonne sera présent. Tout fonctionnera
- sans problème.
+ l'abonné connait toujours les <quote>anciennes</quote>. Dès que l'on
+ appliquera la modification de la clef chez l'abonné, les événements
+ <command>SYNC</command> seront traités de nouveau et le
+ <quote>nouveau</quote> nom de colonne sera présent. Tout fonctionnera
+ sans problème.
</para>
</answer>
</qandaentry>
@@ -1471,7 +1471,7 @@
<answer>
<para>
- Voici Rod Taylor écrit sur le sujet...
+ Voici Rod Taylor écrit sur le sujet...
</para>
<para>
@@ -1481,83 +1481,83 @@
<itemizedlist>
<listitem>
<para>
- Prendre les templates 7.3 et les copier en 7.2 -- ou bien écrire
+ Prendre les templates 7.3 et les copier en 7.2 -- ou bien écrire
en dur la version de vos templates
</para>
</listitem>
<listitem>
<para>
- Supprimer toute trace de schémas dans le code SQL de vos templates.
- Concrètement, j'ai remplacé les points par des tirets.
+ Supprimer toute trace de schémas dans le code SQL de vos templates.
+ Concrètement, j'ai remplacé les points par des tirets.
</para>
</listitem>
<listitem>
<para>
Pas mal de travaux sur les types et fonctions XID. Par exemple,
- Slony crée des conversions pour la conversion xid vers xxid et
- vice versa -- mais la 7.2 ne peut pas créer de nouvelles conversions
- et dans ce cas vous êtes obligé de le modifier à la main. Je me
- rappelle avoir créé une classe d'opérateur et modifié certaines
+ Slony crée des conversions pour la conversion xid vers xxid et
+ vice versa -- mais la 7.2 ne peut pas créer de nouvelles conversions
+ et dans ce cas vous êtes obligé de le modifier à la main. Je me
+ rappelle avoir créé une classe d'opérateur et modifié certaines
fonctions.
</para>
</listitem>
<listitem>
<para>
- sl_log_1 aura de graves problèmes de performance quelque soit le
- volume des données. Ceci exige qu'un certain nombre d'index soient
- positionnés pour optimiser les interrogations en 7.2, 7.3 et
- supérieur.
+ sl_log_1 aura de graves problèmes de performance quelque soit le
+ volume des données. Ceci exige qu'un certain nombre d'index soient
+ positionnés pour optimiser les interrogations en 7.2, 7.3 et
+ supérieur.
</para>
</listitem>
<listitem>
<para>
- Ne pas s'embêter à essayer de faire fonctionner les séquences.
- Faites-les à la main en utilisant pg_dump et grep.
+ Ne pas s'embêter à essayer de faire fonctionner les séquences.
+ Faites-les à la main en utilisant pg_dump et grep.
</para>
</listitem>
</itemizedlist>
<para>
- Bien sûr, une fois ces pre-requis terminés, on n'est pas encore
+ Bien sûr, une fois ces pre-requis terminés, on n'est pas encore
compatible avec le Slony standard. Ainsi soit vous devez au moins
- modifier la version 7.2 de manière moins artisanale soit vous devez
- modifier slony pour qu'il fonctionne sans les schémas avec les
+ modifier la version 7.2 de manière moins artisanale soit vous devez
+ modifier slony pour qu'il fonctionne sans les schémas avec les
nouvelles versions de &postgres; afin qu'ils puissent dialoguer.
</para>
<para>
- Juste après le déroulement de la procédure de migration de 7.2 vers
- 7.4, on peut désinstaller la version bidouillée de Slony (à la main
- encore pour la majeure partie), et démarrer la migration de 7.2 à
- 7.4 sur les différentes machines en utilisant un Slony standard.
- Ceci afin de s'assurer qu'on ne conserve pas les catalogues systèmes
+ 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 majeure partie), et démarrer la migration de 7.2 Ã
+ 7.4 sur les différentes machines en utilisant un Slony standard.
+ Ceci afin de s'assurer qu'on ne conserve pas les catalogues systèmes
qui ont subi des changements manuels.
</para>
<para>
- Ceci étant dit, nous avons migré quelques centaines de Go de données,
- de 7.2 à 7.4 avec une coupure de service de 30 minutes (contre 48
- heures de sauvegarde/restauration) et sans pertes de données.
+ Ceci étant dit, nous avons migré quelques centaines de Go de données,
+ de 7.2 Ã 7.4 avec une coupure de service de 30 minutes (contre 48
+ heures de sauvegarde/restauration) et sans pertes de données.
</para>
</answer>
<answer>
<para>
- Ceci vous dresse un éventail assez laid des <quote>bidouilles</quote>
- qu'il faut faire entrer dans le périmètre de production. Si quelqu'un
- est intéressé pour <quote>industrialiser</quote> cette tache, il vaut
- mieux s'appuyer sur &slony1; en version 1.0, avec un maître mot de ne
- <emphasis>pas</emphasis> essayer de le rendre pérenne, étant donnée sa
- durée de vie limitée.
+ Ceci vous dresse un éventail assez laid des <quote>bidouilles</quote>
+ qu'il faut faire entrer dans le périmètre de production. Si quelqu'un
+ est intéressé pour <quote>industrialiser</quote> cette tache, il vaut
+ mieux s'appuyer sur &slony1; en version 1.0, avec un maître mot de ne
+ <emphasis>pas</emphasis> essayer de le rendre pérenne, étant donnée sa
+ durée de vie limitée.
</para>
<para>
- Vous devriez seulement adapter cette solution que si vous êtes à l'aise
+ Vous devriez seulement adapter cette solution que si vous êtes à l'aise
avec &postgres; et &slony1; et si mettre la main dans le code ne vous
fait pas peur.
</para>
@@ -1567,50 +1567,63 @@
<qandaentry>
<question>
<para>
- J'ai subit une <quote>avarie réseau</quote> qui m'a obligé à utiliser
+ J'ai subit une <quote>avarie réseau</quote> qui m'a obligé à utiliser
<xref linkend="stmtfailover"/> pour basculer sur un nœud
- secondaire. Le plantage n'était pas causé par un problème de corruption
- de données venant du disque. Pourquoi serais-je obligé de reconstruire
- le nœud qui s'est arrêté brutalement&nbsop;?
+ secondaire. Le plantage n'était pas causé par un problème de corruption
+ de données venant du disque. Pourquoi serais-je obligé de reconstruire
+ le nœud qui s'est arrêté brutalement ?
</para>
</question>
<answer>
<para>
- Le rôle de <xref linkend="stmtfailover"/> est
- d'<emphasis>abandonner</emphasis> le nœud arrêté brutalement 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 arrêté brutalement se
- désynchronise.
+ Le rôle de <xref linkend="stmtfailover"/> est
+ d'<emphasis>abandonner</emphasis> le nœud arrêté brutalement 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 arrêté brutalement se
+ désynchronise.
</para>
</answer>
-<answer><para> L'<emphasis>énorme</emphasis> problème pour restaurer le serveur planté,
-est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de se propager en dehors.
-Vous ne pouvez pas non plus les rejouer, car elles vont être conflictuelles, car à moitié en place.
-En tout cas vous avez une sorte de corruption <quote>logique</quote>de donnée, qui n'est jamais causée par une erreur disque.
-dite <quote>physique.</quote>
-</para></answer>
+ <answer>
+ <para>
+ L'<emphasis>énorme</emphasis> problème pour restaurer le serveur planté
+ est qu'il peut contenir des mises à jours qui n'ont pas eu le temps de
+ se propager en dehors. Vous ne pouvez pas non plus les rejouer car
+ elles vont être conflictuelles, car à moitié en place. En tout cas,
+ vous avez une sorte de corruption <quote>logique</quote> de données,
+ qui n'est jamais causée par une erreur disque dite
+ <quote>physique</quote>.
+ </para>
+ </answer>
-<answer><para> Comme cela a été abordé dans la section <xref linkend="failover"/>, <xref
-linkend="stmtfailover"/> doit être utilisé en <emphasis>dernier
-recourt</emphasis> car cela implique d'abandonner le nœud d'origine pour cette corruption.</para></answer>
-</qandaentry>
+ <answer>
+ <para>
+ Comme cela a été abordé dans la section <xref linkend="failover"/>, <xref
+ linkend="stmtfailover"/> doit être utilisé en <emphasis>dernier
+ recourt</emphasis> car cela implique d'abandonner le nœud
+ d'origine pour cette corruption.
+ </para>
+ </answer>
+ </qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ Après notification d'un abonnement sur un <emphasis>autre</emphasis>
+ nœud, la réplication échoue sur l'un des abonnés avec le message
+ d'erreur suivant :
+ </para>
-<qandaentry> <question><para> Après notification d'un abonnement sur un
-<emphasis>autre</emphasis> nœud, 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>
-<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 de SYNC en échec
+ tandis que <xref linkend="slon"/> s'arrête :
+ </para>
-<para> Par la suite l'erreur est suivie par un ensemble de SYNCs en échec
-tandis que <xref linkend="slon"/> s'arrête :</para>
-
-<screen>
-DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
+ <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
@@ -1619,60 +1632,80 @@
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>
+DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC</screen>
-</question>
+ </question>
-<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
-des événements ont été ignorés, vous devez remonter dans le journal
-<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
-sur l'origine du problème.</para></answer>
+ <answer>
+ <para>
+ Si vous constatez qu'un &lslon; s'arrête et que le jounal des traces
+ indique que des événements ont été ignorés, vous devez remonter dans le
+ journal <emphasis>avant</emphasis> que ces erreurs n'apparaissent, pour
+ trouver des indications sur l'origine du problème.
+ </para>
+ </answer>
-<answer><para> Dans ce cas particulier, l'erreur est due à la commande
-<xref linkend="stmtstorepath"/> qui n'est pas encore répercutée sur le nœud 4 en attendant la propagation
-de <xref linkend="stmtsubscribeset"/> command</para>
+ <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
+ nœud 4 en attendant la propagation de la commande <xref
+ linkend="stmtsubscribeset"/>.
+ </para>
-<para>Cet exemple démontre à nouveau qu'il ne faut pas se précipiter;
-vous devez vous assurer que tout fonctionne correctement
-<emphasis>avant</emphasis> de poursuivre les changements de configuration.
-</para></answer>
+ <para>
+ Cet exemple démontre à nouveau qu'il ne faut pas se précipiter ;
+ vous devez vous assurer que tout fonctionne correctement
+ <emphasis>avant</emphasis> de poursuivre les changements de configuration.
+ </para>
+ </answer>
+ </qandaentry>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai juste utilisé <xref linkend="stmtmoveset"/> afin de déporter le
+ nœud d'origine sur un nouveau serveur. Malheureusement, certains
+ abonnés sont toujours attachés à l'ancien nœud que je viens de
+ migrer or je ne peux les mettre hors service tant qu'ils n'ont pas reçu
+ le signalement de ce changement. Que puis-je faire ?
+ </para>
+ </question>
-<qandaentry>
+ <answer>
+ <para>
+ Vous avez besoin d'utiliser <xref linkend="stmtsubscribeset"/> afin de
+ modifier les abonnements de ces serveurs abonnés et les réorienter vers
+ un fournisseur qui <emphasis>sera</emphasis> disponible durant la
+ période de maintenance.
+ </para>
-<question><para>J'ai juste utilisé <xref linkend="stmtmoveset"/> afin de déporter le nœud d'origine sur
-un nouveau serveur. Malheureusement certains abonnés sont toujours attachés à l'ancien nœud 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>
+ <warning>
+ <para>
+ Il <emphasis>ne faut pas</emphasis> faire <xref
+ linkend="stmtunsubscribeset"/> car vous seriez obligé de recharger
+ toutes les données à partir de zéro.
+ </para>
+ </warning>
+ </answer>
+ </qandaentry>
-<answer><para> Vous avez besoin d'utiliser <xref linkend="stmtsubscribeset"/> afin de modifier les abonnements
- de ces serveurs abonnés et les réorienter vers un fournisseur qui <emphasis>sera</emphasis> disponible durant la période de maintenance.</para>
+ <qandaentry>
+ <question>
+ <para>
+ Après la notification d'un abonnement auprès <emphasis>d'un
+ autre</emphasis> serveur fournisseur, la réplication tombe en panne, et
+ affiche des messages d'erreurs du type :
+ </para>
-<warning> <para> Il <emphasis>ne faut pas</emphasis> faire <xref
-linkend="stmtunsubscribeset"/>; car vous seriez obligé de
-recharger toutes les données à partir de zéro.
+ <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></warning>
-</answer>
-</qandaentry>
+ <para>
+ Ceci est suivi plus tard par une série d'erreur de syncs tandis que le
+ démon <xref linkend="slon"/> s'arrête :
-<qandaentry>
-<question><para> Après la notification d'un abonnement auprès
-<emphasis>d'un autre</emphasis> serveur fournisseur, la réplication tombe en panne, et affiche des messages d'erreurs
-du type :</para>
-
-<screen>
-ERROR remoteWorkerThread_1: "begin transaction; set transaction isolation level serializable; lock table "_livesystem".sl_config_lock; select "_livesystem".enableSubscription(25506, 1, 501); notify "_livesystem_Event"; notify "_livesystem_Confirm"; insert into "_livesystem".sl_event (ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type , ev_data1, ev_data2, ev_data3, ev_data4 ) values ('1', '4896546', '2005-01-23 16:08:55.037395', '1745281261', '1745281262', '', 'ENABLE_SUBSCRIPTION', '25506', '1', '501', 't'); insert into "_livesystem".sl_confirm (con_origin, con_received, con_seqno, con_timestamp) values (1, 4, '4896546', CURRENT_TIMESTAMP); commit transaction;" PGRES_FATAL_ERROR ERROR: insert or update on table "sl_subscribe" violates foreign key constraint "sl_subscribe-sl_path-ref"
-DETAIL: Key (sub_provider,sub_receiver)=(1,501) is not present in table "sl_path".
-</screen>
-
-<para> Ceci est suivi plus tard par une série d'erreur de syncs tandis que le <xref
-linkend="slon"/> s'arrête :
-
-<screen>
-DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
+ <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
@@ -1681,69 +1714,93 @@
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>
+DEBUG2 remoteListenThread_1: queue event 1,4897523 SYNC</screen>
-</para></question>
+ </para>
+ </question>
-<answer><para> Si vous constatez qu'un &lslon; s'arrête et que le jounal de log indique que
-des événements ont été ignorés, vous devez remonter dans le journal
-<emphasis>avant</emphasis> que ces erreurs apparaissent, pour trouver des indications
-sur l'origine du problème.</para></answer>
+ <answer>
+ <para>
+ Si vous constatez qu'un démon &lslon; s'arrête et que le jounal des
+ traces indique que des événements ont été ignorés, vous devez remonter
+ dans le journal <emphasis>avant</emphasis> que ces erreurs
+ n'apparaissent, pour trouver des indications sur l'origine du problème.
+ </para>
+ </answer>
-<answer><para> Dans ce cas particulier, le problème était que certaines commandes
- <xref linkend="stmtstorepath"/> n'ont pas été transmises aux nœud 4 avant que
-le commande <xref linkend="stmtsubscribeset"/> ne soit propagée. </para>
+ <answer>
+ <para>
+ Dans ce cas particulier, le problème était que certaines commandes <xref
+ linkend="stmtstorepath"/> n'ont pas été transmises aux nœud 4
+ avant que la commande <xref linkend="stmtsubscribeset"/> ne soit
+ propagée.
+ </para>
-<para>C'est encore un exemple où il ne faut pas hâtivement modifier les choses
-; vous devez être sur que tout fonctionne bien
-<emphasis>avant</emphasis> de faire de nouveau changement de configuration.
-</para></answer>
+ <para>
+ C'est encore un exemple où il ne faut pas hâtivement modifier les
+ choses ; vous devez être sûr que tout fonctionne bien
+ <emphasis>avant</emphasis> de faire de nouveaux changements de
+ configuration.
+ </para>
+ </answer>
+ </qandaentry>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ Est-ce que l'ordre est important dans un ensemble de réplication ?
+ </para>
+ </question>
+
+ <answer>
+ <para>
+ La plupart de temps, il ne l'est pas. On pourrait imaginer qu'il faille
+ déclarer les tables <quote>mères</quote> avant leur <quote>filles</quote>
+ en fonction des relations de clefs étrangères qui les relient ;
+ mais ce n'est <emphasis>pas nécessaire</emphasis> si, sur le nœud
+ abonné, on a pris le soin de désactiver les déclencheurs.
+ </para>
+ </answer>
-<qandaentry>
-<question> <para> Est-ce que l'ordre dans une ensemble de réplication est important ?</para>
-</question>
-<answer> <para> La plupart de temps il ne l'est pas. On pourrait imaginer qu'il faille
-déclarer les tables <quote>mères</quote> avant leurs <quote>filles</quote>
-en fonction des relations de clefs étrangères qui les relient;
-mais ce n'est <emphasis>pas nécessaire</emphasis> si sur le nœud abonné,
-on a pris le soin, de désactiver les déclencheurs.
-</para>
-</answer>
+ <answer>
+ <para>
+ (Commentaires de Jan Wieck) L'ordre des identifiants 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 interbloqués
+ (« deadlock ») et par conséquent faire tomber l'application ou
+ bien <application>slon</application>.
+ </para>
+ </answer>
+ <answer>
+ <para>
+ (David Parker) J'ai renconté un autre cas où l'ordre des tables avait
+ une importance : avec l'héritage. Si une table fille se présente
+ avant la table mère, alors l'abonnement initial provoquera la suppression
+ du contenu de la table, alors qu'elle aura probablement reçue des
+ données. En effet, la logique de la commande <command>copy_set</command>
+ effectue un <command>delete</command>, et non pas un <command>delete
+ only</command>, ce qui implique que la suppression des données de la
+ table maître provoquera la suppression de celle de la table fille.
+ </para>
+ </answer>
+ </qandaentry>
-<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 interbloqués ("deadlock") et par conséquent faire tomber l'application ou bien
-<application>slon</application>.
-</para>
-<answer><para> (David Parker) J'ai renconté un autre cas où l'ordre des
-tables avait une importance : avec l'héritage.
-Si une table fille se présente avant le table mère, alors l'abonnement initial provoquera la suppression du
-contenu de la table, alors qu'elle aura probablement reçue des données.
-En effet la logique de la commande
-<command>copy_set</command> effectue un <command>delete</command>,
-et non pas un <command>delete only</command>, ce qui implique que la suppression des données de la table maître provoquera la suppression de celle
-de la table fille.
-</para>
-</answer></answer>
+ <qandaentry>
+ <question>
+ <para>
+ Si votre script <xref linkend="slonik"/> ressemble à quelque chose comme
+ celui ci-dessous, il peut tomber en erreur et ne jamais se terminer car
+ on ne peut pas utiliser <command>wait for event</command> à l'intérieur
+ d'un bloc <command>try</command>. Un bloc <command>try</command> est
+ exécuté comme une seule et même transaction, et l'évènement pour lequel
+ vous êtes en attente peut ne jamais avoir lieu dans le courant de la
+ transaction.
+ </para>
-</qandaentry>
-
-<qandaentry>
-
-<question><para> Si votre script <xref linkend="slonik"/> ressemble à quelque chose à celui ci-dessous,
-il peut tomber en erreur et ne jamais se terminer, car on ne peut pas utiliser
-<command>wait for event</command> à l'intérieur d'un bloc
-<command>try</command>. Un bloc de <command>try</command> est exécuté comme une seule et même transaction,
-et l'évènement pour lequel vous êtes en attente, peut ne jamais avoir lieu
-dans le scope de la transaction.</para>
-
-<programlisting>
-try {
+ <programlisting>try {
echo 'Moving set 1 to node 3';
lock set (id=1, origin=1);
echo 'Set locked';
@@ -1757,169 +1814,260 @@
echo 'Could not move set for cluster foo';
unlock set (id=1, origin=1);
exit -1;
-}
-</programlisting></question>
+}</programlisting>
+ </question>
-<answer><para> Vous ne devez pas invoquer<xref linkend="stmtwaitevent"/>
-à l'intérieur d'un bloc <quote>try</quote>.</para></answer>
+ <answer>
+ <para>
+ Vous ne devez pas invoquer <xref linkend="stmtwaitevent"/> à l'intérieur
+ d'un bloc <quote>try</quote>.
+ </para>
+ </answer>
+ </qandaentry>
-</qandaentry>
+ <qandaentry>
+ <question>
+ <para>Slony-I: cannot add table to currently subscribed set 1</para>
-<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 :
-<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>
-<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>
-<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> ensemble de
+ réplication, d'y rajouter les tables souhaitées, de brancher les
+ serveurs abonnés à l'ensemble de réplication 1 sur le nouveau qu'on vient
+ de créer, et enfin de fusionner les deux ensembles.
+ </para>
+ </answer>
+ </qandaentry>
-<para>Le contournement est de créer un <emphasis>AUTRE</emphasis>
-ensemble de réplication, d'y rajouter les tables souhaitées, brancher les serveurs abonnés l'ensemble de réplication 1 sur le nouveau qu'on vient de créer,et en suite de
-fusionner les 2 ensembles.</para>
-</answer></qandaentry>
+ <qandaentry>
+ <question>
+ <para>ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
-<qandaentry>
-<question><para>
-ERROR: duplicate key violates unique constraint "sl_table-pkey"</para>
+ <para>
+ En essayant de monter un deuxième ensemble de réplication, j'ai ce
+ message :
-<para>En essayant de monter un deuxième ensemble de réplication, j'ai ce message :
-
-<screen>
-stdin:9: Could not create subscription set 2 for oxrslive!
+ <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>
+CONTEXT: PL/pgSQL function "setaddtable_int" line 71 at SQL statement</screen>
+ </para>
+ </question>
-<answer><para> Les identifiants des tables utilisées dans <xref linkend="stmtsetaddtable"/>
-doivent être uniques <emphasis>A TRAVERS TOUT LES ENSEMBLES DE REPLICATION</emphasis>.
-En conséquence, vous en pouvez pas reprendre la numérotation à zéro à l'intérieur
-d'un deuxième ensemble de réplication; Si vous les numérotez de manière
-consécutive, le prochain ensemble de réplication doit commencer
-avec un identifiant supérieur à ceux de l'ensemble précédent.
-</para> </answer>
-</qandaentry>
+ <answer>
+ <para>
+ Les identifiants des tables utilisées dans <xref
+ linkend="stmtsetaddtable"/> doivent être uniques <emphasis>À TRAVERS
+ TOUS LES ENSEMBLES DE REPLICATION</emphasis>. En conséquence, vous ne
+ pouvez pas reprendre la numérotation à zéro à l'intérieur d'un deuxième
+ ensemble de réplication ; si vous les numérotez de manière
+ consécutive, le prochain ensemble de réplication doit commencer avec un
+ identifiant supérieur à ceux de l'ensemble précédent.
+ </para>
+ </answer>
+ </qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ L'un de mes nœudss est tombé (&lslon; ou le postmaster était
+ arrêté) et personne ne s'en est aperçu pendant plusieurs jours.
+ Maintenant, lorsque &lslon; démarre sur ce nœud, il tourne durant
+ cinq minutes, puis s'arrête avec l'erreur suivante :
+ <command>ERROR: remoteListenThread_%d: timeout for event selection</command>
+ Quel est le problème ? Que faire pour le résoudre ?
+ </para>
+ </question>
-<qandaentry>
-<question><para> L'un de mes nœudss est tombé (&lslon; ou le postmaster était arrêté) et personne ne s'en est aperçu pendant plusieurs jours.
-Maintenant lorsque &lslon; démarre sur ce nœud, il tourne durant cinq minutes, puis s'arrête,
-avec l'erreur suivante : <command>ERROR: remoteListenThread_%d: timeout
-for event selection</command> Quel est le problème ? Que faire ? </para>
-</question>
+ <answer>
+ <para>
+ Le problème est que le port d'écoute de ce processus
+ (dans <filename>src/slon/remote_listener.c</filename>) arrive à une
+ expiration de temps lorsqu'il tente de déterminer quel le prochain
+ évènement à reprendre sur ce nœud. Par défaut, le délai
+ d'expiration de cette interrogation est de cinq minutes ; si la
+ reprise contient les évènements pour une durée de plusieurs jours,
+ cela prendra beaucoup plus de temps.
+ </para>
+ </answer>
-<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, lorsqu'il tente
-de déterminer quel est l'évènement à reprendre sur ce nœud. Par défaut
-le délai d'expiration de cette interrogation est de 5 minutes; si la reprise contient les évènements pour une durée de plusieurs jours,
-cela prendra beaucoup plus de temp.
- </para> </answer>
+ <answer>
+ <para>
+ La réponse à cette question, pour les versions de &slony1; antérieures
+ aux versions 1.1.7, 1.2.7, et à 1.3, serait d'augmenter le délai
+ d'expiration dans <filename>src/slon/remote_listener.c</filename>, de
+ recompiler &lslon; et enfin de ré-essayer.
+ </para>
+ </answer>
-<answer><para> La réponse à cette question pour les versions de &slony1; antérieures à 1.1.7, 1.2.7, et à 1.3, serait de dire
-d'augmenter le délai d'expiration dans
-<filename>src/slon/remote_listener.c</filename>, de recompiler &lslon;, et enfin de ressayer. </para> </answer>
-
-<answer><para> Une autre réponse serait de conseiller de reconstruire entièrement le nœud 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>
+ Une autre réponse serait de conseiller de reconstruire entièrement le
+ nœud ayant échoué, à l'aide de la commande &lslonik;
+ <xref linkend="stmtdropnode"/> en le supprimant d'abord et en le
+ recréant après. Si les mises à jours sont volumineuses côté base de
+ données, il vaut mieux reconstruire 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 nœud, que d'essayer de rattraper les mises à jours. </para> </answer>
-
-</qandaentry>
-
+ <answer>
+ <para>
+ Dans les version récentes de &slony1;, il existe un 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 cela a été mentionné ci-dessus, il est plus efficace dans ce
+ cas de supprimer et de recréer le nœud, que d'essayer de rattraper
+ les mises à jours.
+ </para>
+ </answer>
+ </qandaentry>
</qandadiv>
+<qandadiv id="faqperformance">
+ <title>FAQ &slony1; : problèmes de performances</title>
+ <qandaentry id="longtxnsareevil">
+ <question>
+ <para>
+ La réplication ralentit. Je vois des requêtes <command>FETCH 100 FROM
+ LOG</command> très longues, la table &sllog1;/&sllog2; grossit et les
+ performances se dégradent de manière continue.
+ </para>
+ </question>
-<qandadiv id="faqperformance"> <title> &slony1; FAQ: Problèmes de Performances </title>
+ <answer>
+ <para>
+ Il y a beaucoup de causes possibles pour ce genre de choses. Il s'agit
+ du même genre de pathologies qui entrainent l'augmentation du volume
+ dans <link linkend="pglistenerfull">&pglistener; lorsque la purge via
+ vacuum n'est pas exécutée</link>.
+ </para>
-<qandaentry id="longtxnsareevil">
+ <para>
+ Par rapprochement, <quote>on peut avancer</quote> que cette augmentation
+ de volume est due à une session existante sur le serveur qui est en
+ <command>IDLE IN TRANSACTION</command> pour une durée très longue.
+ </para>
+ <para>
+ Cette transaction ouverte peut avoir de multiples effets négatifs,
+ chacun entrainant une dégradation de performances.
+ </para>
-<question><para> La réplication ralentit, je vois des requêtes <command> FETCH 100 FROM LOG </command> très longues , la table &sllog1;/&sllog2; grossit, et les performances se dégradent de manière continue. </para>
-</question>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Le fait de lancer un VACUUM sur la totalité des tables, &pglistener;
+ y compris, ne va pas nettoyer les lignes mortes après après le début
+ de la transaction en attente.
+ </para>
+ </listitem>
-<answer> <para> Il y a beaucoup de causes possibles pour ce genre de choses.
-Il s'agit de même genre de pathologies qui entrainent l'augmentation du volume dans
- <link linkend="pglistenerfull">
-&pglistener; lorsque la purge via vacuum n'est pas exécutée.</link>
-</para>
+ <listitem>
+ <para>
+ Le processus de nettoyage ne pourra pas se supprimer les entrées
+ dans &sllog1;, &sllog2; et &slseqlog;, ce qui entraîne par
+ conséquence une croissance de volume tant que la transaction
+ persiste.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </answer>
-<para> Par rapprochement <quote> on peut avancer </quote>, que cette augmentation de volume,
-est due à une session existante sur le serveur rend le nœud
- <command>
-IDLE IN TRANSACTION </command> pour une durée très longue. </para>
+ <answer>
+ <para>
+ Vous pouvez surveiller cette situation uniquement si, dans le fichier
+ de configuration de &postgres; <filename> postgresql.conf</filename>,
+ le paramètre <envar>stats_command_string</envar> est positionné à vrai.
+ Dans ce cas, vous pouvez lancer une interrogation SQL comme suit :
+ <command>SELECT * FROM pg_stat_activity WHERE current_query LIKE
+ '%IDLE% in transaction';</command> dont le résultat vous donne les
+ transactions en activités.
+ </para>
+ </answer>
-<para> Cette transaction ouverte peut avoir de multiples effets négatifs,
-chacun entrainant une dégradation de performances.</para>
+ <answer>
+ <para>
+ Vous pouvez également rechercher les <quote>idle in transaction</quote>
+ dans la table des processus pour trouver ceux qui détiennent encore des
+ transactions anciennes.
+ </para>
+ </answer>
-<itemizedlist>
+ <answer>
+ <para>
+ Il est aussi possible (quoique plus rare) que le problème soit causé
+ par une transaction qui, pour d'autres raisons, est conservée comme
+ ouverte et ceci pour une longue durée. La valeur
+ <envar>query_start</envar> dans la table <envar>pg_stat_activity</envar>
+ vous présentera les longues requêtes qui s'exécutent depuis longtemps.
+ </para>
+ </answer>
-<listitem><para> Le fait de lancer un Vacuum sur la totalité des tables,
-&pglistener; y compris, ne va pas nettoyer les tuples morts après après le début de la transaction en attente. </para> </listitem>
+ <answer>
+ <para>
+ Il est prévu que &postgres; ait un paramètre d'expiration de délai,
+ <envar>open_idle_transaction_timeout</envar>, qui permettrait de venir
+ à bout des transactions après une certaine période. Les pools de
+ connexions peuvent engendrer ce genre de situation d'erreurs. Il est
+ prévu des amélioration où <productname><link
+ linkend="pgpool">pgpool</link></productname> devrait présenter des
+ meilleures alternatives afin de mieux gérer les connexions partagées.
+ Il existe des pools de connexions plus ou moins bogués dans les
+ applications Java ou PHP ;si un nombre restreint de
+ <emphasis>vraies</emphasis> connexions sont conservées dans
+ <productname>pgpool</productname>, ceci va faire croire à la base qu'en
+ réalité les connexions de l'application restent dans un statut
+ disponible et en activité pendant des heures.
+ </para>
+ </answer>
+ </qandaentry>
-<listitem><para> Le processus de nettoyage ne pourra pas se supprimer les entrées dans &sllog1;, &sllog2;
-et &slseqlog;, qui entraîne par conséquence, une croissance
-de volume tant que la transaction persiste. </para>
-</listitem>
-</itemizedlist>
-</answer>
+ <qandaentry id="faq17">
+ <question>
+ <para>
+ Après une suppression de nœud, les tables &sllog1;/&sllog2; ne
+ sont plus purgées.
+ </para>
+ </question>
-<answer> <para> Vous pouvez surveiller cette situation, uniquement si
-dans le fichier de configuration de &postgres; <filename> postgresql.conf </filename>
-le paramètre <envar>stats_command_string</envar> est positionner à vrai.
-Dans ce cas, vous pouvez lancer une intérrogation sql comme suit :
-<command> select * from pg_stat_activity where current_query like '%IDLE% in transaction';
-</command> dont le résultat vous donnent les transactions en activités. </para> </answer>
+ <answer>
+ <para>
+ Ceci est un scénario commun dans les versions d'avant 1.0.5. En effet,
+ le <quote>nettoyage</quote> du nœud oublie les vieilles entrées
+ de la table <xref linkend="table.sl-confirm"/> pour le serveur qui
+ vient de disparaître.
+ </para>
-<answer> <para> Vous pouvez également rechercher
-les <quote> idle in transaction </quote> dans la table des processes
-ceux qui détiennent encore des transactions anciennes.
- </para> </answer>
+ <para>
+ Le nœud n'est plus présent et n'envoie plus les confirmations
+ annonçant les synchronisations qui viennent de s'effectuer sur ce
+ serveur, et le processus de nettoyage estime qu'il ne peut supprimer
+ sans risque les entrées plus récentes que la dernière entrée de la
+ <xref linkend="table.sl-confirm"/> , ce qui limite nettement la
+ capacité de purge des anciens journaux.
+ </para>
-<answer> <para> Il est aussi possible (quoique plus rare) que le problème soit causé par
-une transaction, qui pour d'autres raisons, est conservée comme ouverte et ceci pour une longue durée.
-La valeur <envar> query_start </envar> dans la table <envar>
-pg_stat_activity </envar> vous présentra les longues requêtes qui s'exécutent depuis longtemps. </para> </answer>
+ <para>
+ Diagnostiques : Exécuter les requêtes suivantes pour voir s'il y a
+ un résidus d'entrées en état <quote>fantôme/obsolète/bloqué</quote> dans
+ la table <xref linkend="table.sl-confirm"/>:
-<answer> <para> Il est prévu que &postgres; ait un paramètre d'expiration de
-délai, <envar> open_idle_transaction_timeout </envar>, qui permettrait de venir à bout des transactions après une certaine période.
-
-Les pool de connexions peuvent engendrer ce genre de situation d'erreurs. Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
-</link> </productname> devrait présenter des meilleurs alternatives afin de mieux gérer les connexions partagées.
-Il existe des pools de connexions plus ou moins buggués dans les applications
-Java ou PHP;si un nombre restreint de <emphasis> vrai </emphasis>
-connections sont conservées dans<productname>pgpool</productname>, ceci va faire croire à la base,
-qu'en réalité les connexions de l'application reste dans un statut disponible et en activité, pendant des heures.
-</para> </answer>
-
-</qandaentry>
-
-<qandaentry id="faq17">
-<question><para>Après une suppression de nœud, les tables &sllog1;/&sllog2;
-ne sont plus purgées.</para></question>
-
-<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, en effet
-le <quote>nettoyage</quote> du nœud oublie les vieilles entrées de la table <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
-
-<para> Le nœud n'est plus présent et n'envoie plus les confirmations annonçant les syncs qui viennent de s'effectuer sur ce serveur,
-et le processus de nettoyage estime qu'il ne peut supprimer sans risque les entrées plus récentes
-que la dernière entrée de la <xref linkend="table.sl-confirm"/> , ce qui limite nettement la capacité de purge des anciens journaux.</para>
-
-<para>Diagnostics: Exécuter les requêtes suivantes pour voir si il y a
-un résidus d'entrées en état <quote>fantôme/obsolète/bloqué</quote> dans la table <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);
+ <screen>oxrsbar=# SELECT * FROM _oxrsbar.sl_confirm
+oxrsbar-# WHERE con_origin NOT IN (SELECT no_id FROM _oxrsbar.sl_node)
+oxrsbar-# 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
@@ -1928,162 +2076,267 @@
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>
+(6 rows)</screen>
+ </para>
-<para>Dans la version 1.0.5, la fonction <xref linkend="stmtdropnode"/>
-purges les données dans <xref linkend="table.sl-confirm"/> pour le nœud qui quitte la configuration.
-Dans les versions plus anciennes, il faut faire cela à la main. Supposons que l'identifiant du nœud soit 3, alors la requête serait la suivante :
+ <para>
+ Dans la version 1.0.5, la fonction <xref linkend="stmtdropnode"/> purge
+ les données dans <xref linkend="table.sl-confirm"/> pour le nœud
+ qui quitte la configuration. Dans les versions plus anciennes, il faut
+ faire cela à la main. Supposons que l'identifiant du nœud soit 3,
+ alors la requête serait la suivante :
+ <screen>DELETE FROM _namespace.sl_confirm WHERE con_origin = 3 OR con_received = 3;</screen>
+ </para>
-<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 :
-<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>
+ <screen>oxrsbar=# DELETE FROM _oxrsbar.sl_confirm
+oxrsbar-# WHERE con_origin NOT IN (SELECT no_id FROM _oxrsbar.sl_node)
+oxrsbar-# 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> et vérifier le contenu des <command>SYNC</command> dans la table <xref linkend="table.sl-confirm"/> avant de les purger, puis de valider l'opération par un <command>COMMIT</command>. Si
-vous supprimer par erreur les données d'un autre nœud, votre journée est perdue le temps de rattraper l'erreur commise.</para>
+ <para>
+ Une <quote>raisonnable diligence</quote> dicterait de commencer par
+ <command>BEGIN</command> et vérifier le contenu des
+ <command>SYNC</command> dans la table <xref linkend="table.sl-confirm"/>
+ avant de les purger, puis de valider l'opération par un
+ <command>COMMIT</command>. Si vous supprimez par erreur les données
+ d'un autre nœud, votre journée est perdue le temps de rattraper
+ l'erreur commise.
+ </para>
-<para>Vous aurez besoin d'exécuter cette opération, sur chaque nœud qui reste...</para>
+ <para>
+ Vous aurez besoin d'exécuter cette opération sur chaque nœud
+ qui reste...
+ </para>
-<para>A noter qu'à partir de la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
-de <xref linkend="table.sl-confirm"/> à deux instants :
+ <para>
+ À noter qu'à partir de la version 1.0.5, ce n'est plus un problème car
+ il purge les entrées inutiles de <xref linkend="table.sl-confirm"/> Ã
+ deux instants :
-<itemizedlist>
-<listitem><para> Lorsque un nœud est supprimé</para></listitem>
+ <itemizedlist>
+ <listitem>
+ <para>
+ lorsqu'un nœud est supprimé ;
+ </para>
+ </listitem>
-<listitem><para> Au démarrage de chaque
-<function>cleanupEvent</function>, qui est l'évènement qui purge les vieilles données de
-&sllog1;/&sllog2; et de &slseqlog;</para></listitem> </itemizedlist></para>
-</answer>
-</qandaentry>
+ <listitem>
+ <para>
+ au démarrage de chaque fonction <function>cleanupEvent</function>,
+ qui est l'évènement qui purge les vieilles données de
+ &sllog1;/&sllog2; et de &slseqlog;.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ Le démon <application>slon</application> était éteint ce week-end.
+ Désormais, il lui faut énormément de temps pour exécuter un sync.
+ </para>
+ </question>
-<question><para>Le <application>slon</application> était éteint ce week-end , et désormais il lui faut énormément de temps pour exécuter un
-sync.</para></question>
+ <answer>
+ <para>
+ Jetez un coup d'œil sur les tables &sllog1;/&sllog2; pour voir
+ brièvement s'il y a une énorme transaction en cours d'exécution. Jusqu'Ã
+ la version 1.0.2, il faut qu'il y ait un &lslon; connecté au nœud
+ origine pour que les événements <command>SYNC</command> soient générés.
+ </para>
-<answer><para> Jetez un coup d'oeil, sur les tables &sllog1;/&sllog2;,
- pour voir brièvement si il y a une énorme transaction
-en cours d'exécution. Jusqu'à la version 1.0.2, il faut qu'il y ait un
-&lslon; connecté au nœud origine pour que les événements <command>SYNC</command> soient générés.</para>
+ <note>
+ <para>
+ À partir de la version 1.0.2, la fonction
+ <function>generate_sync_event()</function> fournit une alternative Ã
+ la sauvegarde...
+ </para>
+ </note>
-<note><para>À partir de la version 1.0.2, la fonction
-<function>generate_sync_event()</function> fournit une alternative à la sauvegarde...</para> </note>
+ <para>
+ Si aucun évènement n'est généré, alors toute les mises à jour jusqu'au
+ prochain évènement seront aggrégées dans une énorme transaction
+ &slony1;.
+ </para>
-<para>Si aucun évènement n'est généré, alors toute les mises à jour jusqu'au prochain évènement seront aggrégées dans une énorme transaction &slony1;.</para>
+ <para>
+ Conclusion : même s'il n'y a pas d'abonné dans votre réplication,
+ vous devez <emphasis>vraiment</emphasis> mettre en place un démon
+ <application>slon</application> pour qu'il se connecte au
+ nœud origine.
+ </para>
-<para>Conclusion: Même si il n'y a pas d'abonné dans votre réplication,
-vous avez <emphasis>vraiment</emphasis> mettre en place un
-<application>slon</application> pour qu'il se connecte au nœud origine.</para>
+ <para>
+ &slony1; 1.1 fournit une procédure stockée qui permet aux SYNC 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>
-<para>&slony1; 1.1 fournit une procédure stockée qui permet aux SYNCs d'être
-mis à jour par le planificateur <application>cron</application>même si <xref
-linkend="slon"/> ne tourne pas en tâche de fond.</para> </answer></qandaentry>
+ <qandaentry id="pglistenerfull">
+ <question>
+ <para>
+ Quelques nœuds commencent à se ralentir constamment.
+ </para>
-<qandaentry id="pglistenerfull">
-<question><para>Quelques nœuds commencent à se ralentir constamment. </para>
+ <para>
+ J'avais lancé, depuis un moment, &slony1; sur un nœud, et je vois
+ que la machine est à genoux.
+ </para>
-<para>J'avais lancé, depuis un moment, &slony1; sur un nœud, 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>
-<para>Je vois des instructions en cours comme :
-<screen>
- fetch 100 from LOG;
-</screen></para></question>
+ <answer>
+ <para>
+ Typiquement, ceci peut se produire lorsque &pglistener; (la table qui
+ contient les données de <command>NOTIFY</command>) est remplie de lignes
+ mortes. Ce qui fait que les évènements <command>NOTIFY</command>
+ prennent du temps, et causent le ralentissement de plus en plus fort du
+ nœud affecté.
+ </para>
-<answer><para> Typiquement ceci peut se produire lorsque &pglistener; (la table qui contient les données de
-<command>NOTIFY</command>) est rempplie de tuple morts.
+ <para>
+ Vous avez probablement besoin d'effectuer un <command>VACUUM
+ FULL</command> sur &pglistener; pour le nettoyer vigoureusement, puis
+ d'effectuer un VACUUM simple sur &pglistener; vraiment fréquemment. Une
+ planification tous les cinq minutes fera l'affaire.
+ </para>
+ <para>
+ Les démons Slon font déjà un VACUUM sur beaucoup de tables et
+ <filename>cleanup_thread.c</filename> contient une liste de tables Ã
+ nettoyer fréquemment de manière automatique. Dans &slony1; 1.0.2,
+ &pglistener; n'est pas inclus. Dans la version 1.0.5 et supérieure, il
+ est purgé régulièrement. Du coup, ce problème n'a plus lieu d'être.
+ Dans la version 1.2, &pglistener; est seulement utilisé quand le
+ nœud reçoit périodiquement l'évènement, ce qui signifie que ce
+ problème la plupart du temps disparaît même en présence de transactions
+ longues et lentes...
+ </para>
-Ce qui fait que les évènements <command>NOTIFY</command> prend du temps,
-et cause le ralentissement de plus en plus fort du nœud affecté.</para>
+ <para>
+ Il y a, cependant, toujours un scénario où ceci peut
+ <quote>surgir</quote>. Pour respecter le MVCC, les VACUUM ne peuvent pas
+ supprimer des lignes qui sont rendues <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 les nœuds
+ abonnés.
+ </para>
+ </answer>
+ </qandaentry>
-<para>Vous avez probablement besoin d'effectuer un <command>VACUUM FULL</command> sur
-&pglistener;, pour le nettoyer vigoureusement, puis d'effectuer un vacuum simple sur
-&pglistener; vraiment fréquemment. Une planification tous les cinq minutes fera l'affaire.</para>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai soumis une requête <xref linkend="stmtmoveset"/> / <xref
+ linkend="stmtddlscript"/>, et elle semble être coincée sur mon serveur.
+ Les journaux de &slony1; ne montrent aucun avertissement et aucune
+ erreur.
+ </para>
+ </question>
-<para> Les démons Slon font déjà un vacuum sur beaucoup de tables ,et
-<filename>cleanup_thread.c</filename> contient une liste de tables à nettoyer fréquemment de manière automatique.
-Dans &slony1; 1.0.2,&pglistener; n'est pas inclus. Dans la version 1.0.5 et supérieure, il est purgé régulièrement,
-du coup ce problème n'a plus le lieu d'être. Dans la version 1.2,
-&pglistener; est seulement utilisé quand le nœud 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>
+ <answer>
+ <para>
+ Peut-être que <application>pg_autovacuum</application> est en cours
+ d'exécution, et qu'il a posé des verrous sur des tables dans l'ensemble
+ de réplication ? Ceci entraine de manière silencieuse le blocage
+ de &slony1; en l'empêchant d'effectuer les opérations qui exigent
+ l'acquisition des <link linkend="locking">verrous exclusifs</link>.
+ </para>
-<para>Il y a, cependant, toujours un scénario où ceci peut
-<quote>surgir</quote>. Pour respecter le MVCC, les vacuums ne peuvent pas supprimer des tuples qui sont rendus
-<quote>obsolètes</quote> à n'importe quel moment après le démarrage de la transaction la plus ancienne
-qui reste encore ouverte. Les transactions longues, devront être évitées, car elles sont sources de soucis,
-même sur les nœuds abonnés.</para> </answer></qandaentry>
+ <para>
+ Vous pourriez vérifier la présence de ce genre de verrous à l'aide de
+ cette requête :
+
+ <command>SELECT l.*, c.relname FROM pg_locks l, pg_class c
+WHERE c.oid = l.relation;</command>
-<qandaentry> <question> <para> J'ai soumis une requête <xref
-linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/>, et
-elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne montre aucun avertissement et aucune erreur.
- </para> </question>
+ Un verrou <envar>ShareUpdateExclusiveLock</envar> peut bloquer les
+ opérations de &slony1; qui nécessitent leurs propres verrous exclusifs,
+ et les mettre en attente et marquées comme non-validées.
+ </para>
+ </answer>
+ </qandaentry>
-<answer> <para> Peut-être que
-<application>pg_autovacuum</application> est en cours d'exécution, et qu'il a posé
-des verrous sur des tables dans l'ensemble de réplication ? Ceci entraine manière silencieuse le blocage de &slony1;
-en l'empêchant d'effectuer les opérations qui exigent l'acquisition des <link
-linkend="locking"> exclusifs. </link> </para>
+ <qandaentry>
+ <question>
+ <para>
+ Je remarque que, dans les journaux, un démon &lslon; change d'état
+ fréquemment : <quote>LISTEN - switch from polling mode to use
+ LISTEN</quote> et <quote>UNLISTEN - switch into polling mode</quote>.
+ </para>
+ </question>
+ <answer>
+ <para>
+ Les seuils pour commuter entre ces modes sont commandés par les
+ paramètres de configuration <xref linkend="slon-config-sync-interval"/>
+ et <xref linkend="slon-config-sync-interval-timeout"/> ; si la
+ valeur du temps d'expiration (par défaut étant à 10000, impliquant 10s)
+ est maintenu bas, cela encourage le démon &lslon; à retourner dans
+ l'état <quote>d'écoute</quote>. Vous devriez augmenter cette valeur
+ d'expiration de temps.
+ </para>
+ </answer>
+ </qandaentry>
+</qandadiv>
-<para> Vous pourriez vérifier la présence de ce genre de verrous à l'aide de cette requête :
-<command> select l.*, c.relname from pg_locks l, pg_class c
-where c.oid = l.relation ; </command> Un verrou
-<envar>ShareUpdateExclusiveLock</envar> peut bloquer les opérations de &slony1;
-qui nécessitent leurs propres verrous exclusifs, et les mettre en en attentes et marquées comme non-validées. </para>
-</answer> </qandaentry>
+<qandadiv id="faqbugs">
+ <title>FAQ &slony1; : Bugs dans les versions anciennes</title>
+
+ <qandaentry>
+ <question>
+ <para>
+ Les processus &lslon; gérant mes abonnés deviennent énormes, mettant en
+ danger la ressource du système en terme de swap ainsi que le risque
+ d'atteindre la taille limite de 2 Go par processus.
+ </para>
-<qandaentry>
+ <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 mégaoctets. Peut-être que c'est lié ?
+ </para>
+ </question>
-<question><para> Je remarque que dans les journaux, qu'un &lslon; change d'état fréquemment : <quote>LISTEN - switch from polling mode to use
-LISTEN</quote> et <quote>UNLISTEN - switch into polling
-mode</quote>. </para> </question>
+ <answer>
+ <para>
+ Oui, ces enregistrements volumineux sont à la racine du problème. Le
+ problème vient du fait que &lslon; procède normalement par paquet de
+ cent enregistrements à la fois, lorsqu'un abonné charge des données
+ depuis le fournisseur. Ainsi, si la taille moyenne des enregistrements
+ est de 10 Mo, cela entraîne des paquets de données atteignant
+ 1000 Mo qui sont ensuite transformés en <command>INSERT</command>
+ ou en <command>UPDATE</command> dans la mémoire du processus &lslon;.
+ </para>
-<answer><para> Les seuils pour commuter entre ces modes sont commandés par
-les paramètres de configuration <xref
-linkend="slon-config-sync-interval"/> et <xref
-linkend="slon-config-sync-interval-timeout"/>; si la valeur du temps d'expiration
-(par défaut étant à 10000, impliquant 10s) est maintenu bas, cela encourage le &lslon; à retourner dans l'état <quote>d'écoute</quote>.
-Vous devriez augmenter cette valeur d'expiration de temps. </para>
-</answer>
-</qandaentry>
+ <para>
+ Cela mène évidemment &lslon; à des tailles gigantesques.
+ </para>
-
-</qandadiv>
-<qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs dans les versions anciennes</title>
-<qandaentry>
-<question><para>Les processus &lslon; gérant mes abonnés devient énorme, mettant en danger la ressource du système en terme de swap ainsi que le risque d'atteindre la taille limite
-de 2GB par processus . </para>
-
-<para> D'ailleurs, les données que je suis en train de répliquer,
-ont une taille assez grande. Il y a des enregistrements dont la taille
-dépasse des dizaine de megaoctets. Peut-être que c'est lié ? </para> </question>
-
-<answer> <para> Oui, ces enregistrements volumineux sont à la racine du problème.
-Le problème vient du fait que &lslon; normalement procède par paquet de
- 100 enregistrements à la fois, lorsqu'un abonné charge des données depuis le fournisseur.
-Ainsi si la taille moyenne des enregistrements est de
-is 10MB, ceci entraîne des paquets de données atteignant 1000MB qui sont ensuite transformés en
- <command>INSERT</command> ou en <command>UPDATE</command>
-dans la mémoire du processus &lslon;.</para>
-
-<para> Cela mène évidemment &lslon; à des tailles gigantesques. </para>
-
-<para> Le nombre d'enregistrement regroupés est controllé par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
-définie dans le fichier <filename>src/slon/slon.h</filename>. Voici un extrait de ce fichier contenant ce paramètre :
-</para>
+ <para>
+ Le nombre d'enregistrements regroupés est contrôlé par la valeur
+ <envar>SLON_DTA_FETCH_SIZE</envar>, définie dans le fichier
+ <filename>src/slon/slon.h</filename>. Voici un extrait de ce fichier
+ contenant ce paramètre :
+ </para>
-<programlisting>
-#ifdef SLON_CHECK_CMDTUPLES
+ <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)
@@ -2091,269 +2344,445 @@
#define SLON_COMMANDS_PER_LINE 10
#define SLON_DATA_FETCH_SIZE 10
#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 50)
-#endif
-</programlisting>
+#endif</programlisting>
-<para> Si vous rencontrez ce problème, vous devriez définir
- <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être le réduire par un facteur de 10, et recompiler ensuite &lslon;.
-L'activation de <envar> SLON_CHECK_CMDTUPLES</envar> permet de faire une surveillance
-supplémentaire pour s'assurer que les abonnés ne sont pas désynchronisés par
-rapport au fournisseur. Par défaut, cette option est désactivée, donc la modification par défaut consiste réduire la seconde définition de
-<envar> SLON_DATA_FETCH_SIZE </envar> en remplaçant 10 par 1. </para> </answer>
+ <para>
+ Si vous rencontrez ce problème, vous devriez définir
+ <envar>SLON_DATA_FETCH_SIZE</envar>, peut-être le réduire par un facteur
+ de 10, et recompiler ensuite &lslon;. L'activation de
+ <envar>SLON_CHECK_CMDTUPLES</envar> permet de faire une surveillance
+ supplémentaire pour s'assurer que les abonnés ne sont pas désynchronisés
+ par rapport au fournisseur. Par défaut, cette option est désactivée,
+ donc la modification par défaut consiste réduire la seconde définition
+ de <envar>SLON_DATA_FETCH_SIZE</envar> en remplaçant 10 par 1.
+ </para>
+ </answer>
-<answer><para> Dans la version 1.2, la configuration des valeurs de<xref
-linkend="slon-config-max-rowsize"/> et de <xref
-linkend="slon-config-max-largemem"/> sont associées avec un nouvel algorithme
-qui change la logique des choses. Plutôt que de restituer 100
-enregistrements à la fois :</para>
+ <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"/> est associée avec un nouvel
+ algorithme qui change la logique des choses. Plutôt que de restituer
+ cent 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 les valeurs par
+ défaut, ceci limitera ce phénomène de consommation de mémoire à un
+ plafond de 8 Mo.
+ </para>
+ </listitem>
-<itemizedlist>
+ <listitem>
+ <para>
+ Les lignes sont lus jusqu'à ce que la taille n'excède pas le
+ paramètre <xref linkend="slon-config-max-largemem"/>. Par défaut,
+ cette restriction ne consommera pas plus de 5 Mo. Cette valeur
+ n'est pas un seuil de limitation stricte ; si vous avez des
+ lignes dont la taille est de 50 Mo, elles
+ <emphasis>seront</emphasis> forcément chargées en mémoire. Il n'est
+ pas possible d'éviter cela. Mais &lslon;, au moins, n'essayera pas
+ de charger à la fois cent enregistrements coûte que coûte, dépassant
+ les 10 Mo de mémoire consommée à cet effet.
+ </para>
+ </listitem>
+ </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 les valeurs par défaut, ceci limitera
-ce phénomène de consommation de mémoire à un plafond de 8MB. </para>
-</listitem>
+ <para>
+ Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand
+ ils ont chargés sporadiquement des séries de lignes très volumineuses.
+ </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 je rencontre
+ des problèmes.
+ </para>
+ </question>
-<listitem><para> Les tuples sont lus jusqu'à ce que la taille n'excède pas
-le paramètre <xref linkend="slon-config-max-largemem"/>. Par défaut, cette restriction
-ne consommera pas plus de 5MB. Cette valeur n'est pas un seil de limitation stricte;
-si vous avez des tuples dont la taille est de 50MB, il <emphasis>seront</emphasis> forcément chargé en mémoire. Il n'est pas possible d'éviter cela.
-Mais &lslon; au moins, n'essayera pas de charger, à la fois 100 enregistrements coûte que coûte, dépassant les 10GB de
-mémoire consommée à cet effet.</para> </listitem>
-</itemizedlist>
+ <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> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont chargés sporadiquement,
-des séries de tuples très volumineux. </para>
-</answer>
-</qandaentry>
+ <para>
+ Si vous êtes amené à utiliser &slony1; pour migrer depuis une plus
+ vieille version vers la version 8.1 et que vous avez des valeurs UTF-8
+ invalides, vous aurez une surprise déplaisante.
+ </para>
-<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 je rencontre des problèmes. </para>
-</question>
+ <para>
+ Supposons que votre version de base est la version 8.0, avec l'encodage
+ en UTF-8. La base va accepter des séquences <command>'\060\242'</command>
+ comme une valeur UTF-8 conforme, même si ce n'est pas le cas.
+ </para>
-<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 répliquez ceci dans des instances de &postgres; en version 8.1,
+ il va se plaindre, soit lors de l'enregistrement d'un abonné car
+ &slony1; va râler à propos des codes caractères invalides qu'il vient
+ de rencontrer durant la COPY des données, ce qui empêchera que
+ l'enregistrement se fasse, soit lors de l'ajout de données, plus tard,
+ ce qui brisera irrémédiablement la réplication. (Vous pouvez tricher
+ sur le contenu de sl_log_1, mais rapidement cela deviendra
+ <emphasis>vraiment</emphasis> intéressant...)
+ </para>
-<para> Si vous êtes amené à utiliser &slony1; pour migrer depuis une plus vieille version vers la version 8.1,
-et que avez de valeur UTF-8 invalide, vous aurez une surprise déplaisante.</para>
+ <para>
+ Il y a déjà eu des discussions sur ce sujet pour savoir ce qu'il faudra
+ faire. Pour le moment, une stratégie attractive ne se dégage pas sur le
+ sujet.
+ </para>
-<para> Supposons que votre version de base est 8.0, avec l'encodage en UTF-8.
-La base va accepter des séquences <command>'\060\242'</command> comme un valeur UTF-8 conforme, même si ce n'est pas le cas. </para>
+ <para>
+ Si vous utilisez Unicode avec la version 8.0 de &postgres;, vous courrez
+ un risque considérable de corrompre vos données.
+ </para>
-<para> Si vous répliquez ceci dans des instances de &postgres; en version 8.1, il va se plaindre,
-, soit lors de l'enregistrement d'un abonné, car &slony1; va râler
-à propos des codes caractères invalides qu'il vient de rencontrer durant la COPY des données,
-ce qui empêchera que l'enregistrement se fasse, soit lors de l'ajout de données, plus tard, ce qui brisera irrémédiablement la réplication.
-(Vous pouvez tricher sur le contenu de sl_log_1, mais rapidement
-cela deviendra <emphasis>vraiment</emphasis> intéressant...)</para>
+ <para>
+ Si votre réplication a pour but de convertir une fois pour toutes vos
+ données, il y a le risque évoqué ci-dessus ; si cela vous arrive,
+ il vaudra mieux convertir vos données de la version 8.0 d'abord et de
+ re-essayer après.
+ </para>
-<para>Il y a déjà eu des discussions sur ce sujet pour savoir ce qu'il faudra faire.
-Pour le moment une stratégie attractive ne se dégage pas sur le sujet. </para>
+ <para>
+ Au regard des risques encourus, exécuter la réplication en mettant en
+ jeu des versions différentes semble être non pérenne à maintenir.
+ </para>
-<para>Si vous utilisez Unicode avec la version 8.0 de &postgres;, vous courrez un risque
-considérable de corrompre vos données. </para>
+ <para>
+ Pour plus d'information, voir la <ulink
+ url="http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
+ discussion sur le groupe de discussion postgresql-hackers</ulink>.
+ </para>
+ </answer>
+ </qandaentry>
-<para> Si votre réplication a pour but de convertir une fois pour toutes vos données,
-il y a le risque évoqué ci-dessus; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
-d'abord et de re-essayer après. </para>
+ <qandaentry>
+ <question>
+ <para>
+ J'utilise &slony1; 1.1 avec plus de 4 nœuds et deux ensembles
+ de réplication, 1 et 2, qui ne partagent aucun nœuds. Je découvre
+ que les confirmations pour l'ensemble 1 n'arrivent jamais aux
+ nœuds souscrivant à l'ensemble 2, et inversement (celles de
+ l'ensemble 2 n'arrivent pas non plus aux nœuds souscrivant Ã
+ l'ensemble 1). En conséquence, &sllog1;/&sllog2; grossissent et ne sont
+ jamais purgées. Ceci est mentionné dans le <ulink
+ url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">bug 1485</ulink>.
+ </para>
+ </question>
-<para> Au regard des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
-semble être non pérenne à maintenir. </para>
+ <answer>
+ <para>
+ Apparemment, le code de la fonction
+ <function>RebuildListenEntries()</function> ne suffit pas pour résoudre
+ ce cas.
+ </para>
-<para> Pour plus d'information, voir la discussion <ulink url=
-"http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
-sur le groupe de discussion postgresql-hackers. </ulink>. </para>
-</answer>
-</qandaentry>
+ <para>
+ La fonction <function>RebuildListenEntries()</function> sera rectifié
+ dans &slony1; version 1.2 avec un algorithme couvrant ce cas.
+ </para>
+
+ <para>
+ Dans l'intérim, vous devrez ajouter manuellement quelques entrées dans
+ <xref linkend="table.sl-listen"/> en utilisant <xref
+ linkend="stmtstorelisten"/> ou <function>storeListen()</function>, basé
+ sur les principes décrits dans <xref linkend="listenpaths"/>
+ (apparemment pas aussi désuet que nous avons pensé).
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry>
-<question> <para> J'utilise &slony1; 1.1 avec plus de 4 nœuds et deux ensemble de réplication, 1 et 2, qui ne partagent aucun nœuds. Je découvre que les confirmations pour l'ensemble 1
-n'arrivent jamais aux nœuds souscrivant à l'ensemble 2, et inversement, celles de l'ensemble 2 n'arrivent pas non plus
-aux nœuds souscrivant à l'ensemble 1. En conséquence, &sllog1;/&sllog2; grossissent et ne sont jamais
-purgées. Ceci est mentionné dans le bug 1485 :
- <ulink
-url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
-</ulink>.
-</para>
-</question>
+ <qandaentry>
+ <question>
+ <para>
+ Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont
+ tronqués un peu, il leur manque les derniers caractères. Pourquoi ?
+ </para>
+ </question>
-<answer><para> Apparemment le code de la fonction <function>RebuildListenEntries()</function> ne suffit pas pour résoudre ce cas.</para>
+ <answer>
+ <para>
+ C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ;
+ les colonnes étaient capturées par la fonction
+ <function>logtrigger()</function>, qui coupait les derniers octets d'une
+ colonne représentée dans un format de multibyte. que votre version de
+ <filename>src/backend/slony1_funcs.c</filename> est bien la 1.34 ou
+ supérieur ; le patch a été intégré dans la version CVS 1.34 de ce
+ fichier.
+ </para>
+ </answer>
+ </qandaentry>
-<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; version 1.2
-avec un algorithme couvrant ce cas. </para>
-<para>
-Dans l'intérim, vous drevez ajouter manuellement quelques entrées dans <xref linkend="table.sl-listen"/> en utilisant <xref
-linkend="stmtstorelisten"/> ou <function>storeListen()</function>,
-basé sur les principes décrits dans <xref linkend="listenpaths"/>.
-(apparemment pas aussi désuet que nous avons pensé)
-</para></answer>
-</qandaentry>
+ <qandaentry id="sequenceset">
+ <question>
+ <para>
+ Le <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éplication composée seulement de séquences.
+ </para>
+ </question>
-<qandaentry>
-<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, il leur manque les derniers caractères. Pourquoi?
-</para> </question>
+ <answer>
+ <para>
+ Une réponse courte consiste à dire qu'une réplication composée seulement
+ de séquences n'est pas une <link linkend="bestpractices">bonne
+ pratique</link>.
+ </para>
+ </answer>
-<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; les colonnes étaient capturées par la fonction <function>logtrigger()</function>, qui coupait les derniers byte d'une colonne représentée dans un format de multibyte. que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le patch a été intégré dans la version CVS de 1.34 de ce fichier. </para> </answer>
-</qandaentry>
+ <answer>
+ <para>
+ Le problème avec un ensemble de réplication contenant uniquement des
+ séquences, ce sont les cas où les seuls abonnements actifs sont composés
+ uniquement de séquences. Si un nœud entre dans cet état, la
+ réplication échouera puisque la requête qui collecte les données dans
+ &sllog1;/&sllog2; ne trouveront aucune table et par conséquent la
+ requête sera malformée et échouera. Si un ensemble de réplication
+ <emphasis>contenant</emphasis> des tables ré-apparaît, tout va
+ fonctionner correctement ; cela <emphasis>paraît</emphasis>
+ effrayant.
+ </para>
-<qandaentry id="sequenceset"><question><para> <ulink url=
-"http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
-Le bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
-vous faites placer une réplication composée seulement de séquences.
-</para>
-</question>
+ <para>
+ Ce problème devrait être résolu après &slony1; 1.1.0.
+ </para>
+ </answer>
+ </qandaentry>
-<answer> <para> Une réponse courte consiste à dire qu'une réplication composée seulement de séquences, n'est pas une <link linkend="bestpractices">
-bonne pratique.</link> </para>
-</answer>
+ <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, cela signifie
+ reproduire un tas de données, et interrompt la réplication des
+ autres éléments de l'ensemble pendant toute la durée de l'opération.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Si vous êtes en version 1.0.5 ou supérieur, il y a une commande
+ SET DROP TABLE, qui le fera très bien.
+ </para>
+ </listitem>
-<answer>
-<para> Le problème avec un ensemble de réplication contenant uniquement des séquences, ce sont les cas ou les seuls abonnements actifs sont composés uniquement de séquences. Si un nœud entre dans cet état,
-la réplication échouera, puisque la requête qui collecte les données dans &sllog1;/&sllog2; ne trouveront aucune table et par conséquent la requête sera malformée et échouera. Si un ensemble de réplication <emphasis>contenant</emphasis> des tables reapparaît, tout va fonctionner correctement; cela <emphasis>parait</emphasis> effrayant.
-</para>
+ <listitem>
+ <para>
+ Si vous utilisez toujours une version 1.0.1 ou 1.0.2, <emphasis>la
+ fonctionnalité essentielle de <xref linkend="stmtsetdroptable"/>
+ se trouve dans la fonction <function>droptable_int()</function>.
+ Vous pouvez l'utiliser à la main en trouvant l'identifiant de la
+ table à supprimer, qui se trouve dans la table <xref
+ linkend="table.sl-table"/>, puis lancer les trois requêtes
+ suivantes sur chaque nœud :
+ </emphasis>
-<para> Ce problème devrait être résolu après &slony1;
-1.1.0.</para>
-</answer>
-</qandaentry>
+ <programlisting>SELECT _slonyschema.alterTableRestore(40);
+SELECT _slonyschema.tableDropKey(40);
+DELETE FROM _slonyschema.sl_table where tab_id = 40;</programlisting></para>
-<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 ;-).
+ <para>
+ Évidement, le nom du schéma dépend de la façon dont vous avez
+ défini le cluster &slony1;. L'identifiant de la table, dans cet
+ exemple 40, doit être remplacé par celui de la table dont voulez
+ vous débarrasser.
+ </para>
-<itemizedlist>
+ <para>
+ Vous devrez lancer ces trois interrogations sur tous les
+ nœuds, de préférence premièrement sur le nœud
+ d'origine, de sorte que la suppression se propage correctement.
+ On peut également implémenter ceci à travers une commande <xref
+ linkend="slonik"/> et un nouvel évenement &slony1;. Soumettre les
+ trois requêtes en utilisant <xref linkend="stmtddlscript"/>
+ permet de le faire. Il est égalementt possible de se connecter Ã
+ chaque base de données et de lancer les requêtes à la main.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </answer>
+ </qandaentry>
-<listitem><para> Vous pourriez supprimer tout le jeu de réplication, et les recréer avec juste les tables dont vous avez besoin. Hélas, ce signifie reproduire un tas de données, et interromp la réplicationdes autres éléments de l'ensemble pendant toute la duréel'opération</para></listitem>
+ <qandaentry>
+ <question>
+ <para>
+ Je dois supprimer une séquence dans une séquence pour un ensemble de
+ réplication.
+ </para>
+ </question>
-<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>
+ <answer>
+ <para>
+ Si vous êtes en version 1.0.5 ou supérieure, il existe une commande
+ <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de
+ le faire en parallèle <xref linkend="stmtsetdroptable"/>.
+ </para>
-<listitem><para> Si vous utilisez toujours une version 1.0.1 ou 1.0.2,
-<emphasis>la fonctionnalité essentielle de <xref linkend="stmtsetdroptable"/> se trouve dans la fonction <function>droptable_int()</function> .
-Vous pouvez l'utilisez à la main en trouvant l'identifiant de la table à supprimer, qui se trouve dans la table <xref
-linkend="table.sl-table"/>, puis lancer les trois requêtes suivantes sur chaque nœud :</emphasis>
+ <para>
+ Si vous êtes en version 1.0.2 ou antérieure, l'opération sera un peu
+ plus manuelle.
+ </para>
-<programlisting>
- select _slonyschema.alterTableRestore(40);
- select _slonyschema.tableDropKey(40);
- delete from _slonyschema.sl_table where tab_id = 40;
-</programlisting></para>
+ <para>
+ À supposer que je veux me débarrasser des deux séquences suivante :
+ <envar>whois_cachemgmt_seq</envar> et <envar>epp_whoi_cach_seq_</envar>.
+ Tout d'abord, il nous faut les valeurs de <envar>seq_id</envar> :
-<para>Évidement le nom du schéma dépend de la façon dont vous avez défini le cluster &slony1;. L'identifiant de la table, dans cet exemple: 40, doit être remplacé par celui de la table dont voulez vous débarrasser.</para>
-
-<para> Vous devrez lancer ces trois interrogations sur tous les nœuds, de préférence premièrement sur le nœud d'origine, de sorte que la suppressions se propage correctement.
-On peut également Implémenter ceci à travers un commande <xref linkend="slonik"/> et
-un nouvel évenement &slony1;. Soumettre les trois requêtes en utilisant <xref linkend="stmtddlscript"/> permet de le faire.
-Il est égalementt possible de se connecter à chaque base de données et de lancer les requêtes à la main.</para></listitem> </itemizedlist></para>
-</answer>
-</qandaentry>
-
-<qandaentry>
-<question><para>Je dois supprimer une séquence dans une séquence pour un ensemble de réplication</para></question>
-
-<answer><para></para><para>Si vous êtes en version 1.0.5 ou supérieure, il existe une commande <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de le faire en paralelle <xref linkend="stmtsetdroptable"/>.</para>
-
-<para>Si vous êtes en version 1.0.2 ou antérieure, l'opération sera un peu plus manuelle.</para>
-
-<para>À supposer que je veux me débarrasser des deux séquences suivante : ,<envar>whois_cachemgmt_seq</envar> et
-<envar>epp_whoi_cach_seq_</envar>, tout d'abord il nous faut les valeurs de <envar>seq_id</envar>.
-
-<screen>
-oxrsorg=# select * from _oxrsorg.sl_sequence where seq_id in (93,59);
+ <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>
+(2 rows)</screen>
+ </para>
-<para>Les données à supprimer pour empêcher Slony de continuer la réplication sont :
+ <para>
+ Les données à supprimer pour empêcher Slony de continuer la réplication
+ sont :
-<programlisting>
-delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
-delete from _oxrsorg.sl_sequence where seq_id in (93,59);
-</programlisting></para>
+ <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 nœud via la fonction &funddlscript; / <xref
-linkend="stmtddlscript"/>, éliminant la séquence partout
-<quote>en même temps.</quote> Ou bien on peut les appliquer à la main à chacun des nœuds.</para>
+ <para>
+ Ces deux interrogations peuvent être soumises à l'ensemble des
+ nœuds via la fonction &funddlscript; / <xref
+ linkend="stmtddlscript"/>, éliminant la séquence partout <quote>en
+ même temps</quote>. Ou bien on peut les appliquer à la main à chacun
+ des nœuds.
+ </para>
-<para>De la même manière que <xref linkend="stmtsetdroptable"/>,
-cette fonction est implementée dans &slony1; version 1.0.5 sous
-le nom <xref
-linkend="stmtsetdropsequence"/>.</para></answer></qandaentry>
+ <para>
+ De la même manière que <xref linkend="stmtsetdroptable"/>, cette
+ fonction est implémentée dans &slony1; version 1.0.5 sous le nom
+ <xref linkend="stmtsetdropsequence"/>.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry>
-<question><para> I set up my cluster using pgAdminIII, with cluster
-name <quote>MY-CLUSTER</quote>. Time has passed, and I tried using
-Slonik to make a configuration change, and this is failing with the
-following error message:</para>
+ <qandaentry>
+ <question>
+ <para>
+ I set up my cluster using pgAdminIII, with cluster name
+ <quote>MY-CLUSTER</quote>. Time has passed, and I tried using Slonik
+ to make a configuration change, and this is failing with the following
+ error message:
+ </para>
-<programlisting>
-ERROR: syntax error at or near -
-</programlisting>
-</question>
+ <programlisting>ERROR: syntax error at or near -</programlisting>
+ </question>
-<answer><para> The problem here is that &slony1; expects cluster names
-to be valid <ulink url=
-"http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html">
-SQL Identifiers</ulink>, and &lslonik; enforces this. Unfortunately,
-<application>pgAdminIII</application> did not do so, and allowed using
-a cluster name that now causes <emphasis>a problem.</emphasis> </para> </answer>
+ <answer>
+ <para>
+ The problem here is that &slony1; expects cluster names to be valid
+ <ulink url="http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html">
+ SQL Identifiers</ulink>, and &lslonik; enforces this. Unfortunately,
+ <application>pgAdminIII</application> did not do so, and allowed using
+ a cluster name that now causes <emphasis>a problem</emphasis>.
+ </para>
+ </answer>
-<answer> <para> If you have gotten into this spot, it's a problem that
-we mayn't be help resolve, terribly much. </para>
+ <answer>
+ <para>
+ If you have gotten into this spot, it's a problem that we mayn't be
+ help resolve, terribly much.
+ </para>
-<para> It's <emphasis>conceivably possible</emphasis> that running the
-SQL command <command>alter namespace "_My-Bad-Clustername" rename to
-"_BetterClusterName";</command> against each database may work. That
-shouldn't particularly <emphasis>damage</emphasis> things!</para>
+ <para>
+ It's <emphasis>conceivably possible</emphasis> that running the
+ SQL command <command>alter namespace "_My-Bad-Clustername" rename to
+ "_BetterClusterName";</command> against each database may work. That
+ shouldn't particularly <emphasis>damage</emphasis> things!
+ </para>
-<para> On the other hand, when the problem has been experienced, users
-have found they needed to drop replication and rebuild the
-cluster.</para> </answer>
+ <para>
+ On the other hand, when the problem has been experienced, users have
+ found they needed to drop replication and rebuild the cluster.
+ </para>
+ </answer>
-<answer><para> A change in version 2.0.2 is that a function runs as
-part of loading functions into the database which checks the validity
-of the cluster name. If you try to use an invalid cluster name,
-loading the functions will fail, with a suitable error message, which
-should prevent things from going wrong even if you're using tools
-other than &lslonik; to manage setting up the cluster. </para></answer>
-</qandaentry>
-
+ <answer>
+ <para>
+ A change in version 2.0.2 is that a function runs as
+ part of loading functions into the database which checks the validity
+ of the cluster name. If you try to use an invalid cluster name,
+ loading the functions will fail, with a suitable error message, which
+ should prevent things from going wrong even if you're using tools
+ other than &lslonik; to manage setting up the cluster.
+ </para>
+ </answer>
+ </qandaentry>
</qandadiv>
-<qandadiv id="faqobsolete"> <title> &slony1; FAQ: Problèmes devenus obsolètes</title>
+<qandadiv id="faqobsolete">
+ <title>FAQ &slony1; : problèmes devenus obsolètes</title>
-<qandaentry>
-<question><para> &lslon; ne se remet pas en marche après un incident</para>
+ <qandaentry>
+ <question>
+ <para>&lslon; ne se remet pas en marche après un incident</para>
-<para> Après un arrêt immédiat de &postgres; (équivalent à un crash du système),
-dans la table &pglistener; on trouve un tuple contenant <command>
-relname='_${cluster_name}_Restart'</command>. slon ne démarre pas car
-il considère qu'un autre processus gère le cluster sur ce nœud. Que puis-je faire?
-Le tuple ne peuventt pas être supprimés dans cette relation.</para>
+ <para>
+ Après un arrêt immédiat de &postgres; (équivalent à un crash du système),
+ dans la table &pglistener; on trouve une ligne contenant
+ <command>relname='_${cluster_name}_Restart'</command>. slon ne démarre
+ pas car il considère qu'un autre processus gère le cluster sur ce
+ nœud. Que puis-je faire ? la ligne ne peut pas être supprimée
+ dans cette relation.
+ </para>
-<para> Les journaux de traces indique qu' <blockquote><para>un autre slon en tâche de fond gère déjà ce nœud.</para></blockquote></para></question>
+ <para>
+ Les journaux de traces indiquent qu'<blockquote><para>un autre slon en
+ tâche de fond gère déjà ce nœud.</para></blockquote>.
+ </para>
+ </question>
-<answer><para> Le problème est que la table système &pglistener;, utilisée par
-&postgres; pour gérer les notification d'évènements, contient quelques entrées pointant vers des processus qui n'existent plus.
-La nouvelle instance de <xref
-linkend="slon"/> se connecte à la base, et elle est convaincue, à cause de la
-présence de ces entrées qu'un ancien
-<application>slon</application> est toujours en activité pour s'occuper de ce nœud de &slony1;.</para>
+ <answer>
+ <para>
+ Le problème est que la table système &pglistener;, utilisée par
+ &postgres; pour gérer les notification d'évènements, contient quelques
+ entrées pointant vers des processus qui n'existent plus. La nouvelle
+ instance de <xref linkend="slon"/> se connecte à la base, et elle est
+ convaincue, à cause de la présence de ces entrées qu'un ancien
+ <application>slon</application> est toujours en activité pour s'occuper
+ de ce nœud de &slony1;.
+ </para>
-<para> Les <quote>détritus</quote> dans cette table doivent être nettoyés.</para>
+ <para>
+ Les <quote>détritus</quote> dans cette table doivent être nettoyés.
+ </para>
-<para>Il est utile de maintenir un script manuel pour ce genre de situation:
+ <para>
+ Il est utile de maintenir un script manuel pour ce genre de
+ situation :
-<programlisting>
-twcsds004[/opt/twcsds004/OXRS/slony-scripts]$ cat restart_org.slonik
+ <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';
@@ -2362,68 +2791,96 @@
restart node 1;
restart node 2;
restart node 3;
-restart node 4;
-</programlisting></para>
+restart node 4;</programlisting>
+ </para>
-<para> <xref linkend="stmtrestartnode"/> nettoie les notifications mortes
-pour qu'on puisse ensuite redémarrer le nœud.</para>
+ <para>
+ <xref linkend="stmtrestartnode"/> nettoie les notifications mortes pour
+ qu'on puisse ensuite redémarrer le nœud.
+ </para>
-<para>A partir de la version 1.0.5, le processus de démarrage de sloncherche ce genre de données obsolètes et les nettoient
-le cas échéant.</para>
+ <para>
+ À partir de la version 1.0.5, le processus de démarrage de slon
+ cherche ce genre de données obsolètes et les nettoie le cas échéant.
+ </para>
-<para> A partir de la version 8.1 de &postgres;, la fonction manipulant
-&pglistener; ne supporte pas cet usage, alors pour les versions de &slony1; postérieurs à la
-1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5), ce risque d'
-<quote>inter-blocage</quote> est géré vias une nouvelle table,
-et le problème disparait de manière transparente. <quote>.</quote> </para>
+ <para>
+ À partir de la version 8.1 de &postgres;, la fonction manipulant
+ &pglistener; ne supporte pas cet usage, alors, pour les versions de
+ &slony1; postérieures à la 1.1.2 (<emphasis>e.g. - </emphasis> 1.1.5),
+ ce risque d'<quote>inter-blocage</quote> est géré via une nouvelle
+ table, et le problème disparaît de manière transparente.
+ </para>
+ </answer>
+ </qandaentry>
-</answer></qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai essayé la requête suivante qui ne fonctionne pas :
+ </para>
-<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
+sdb-# JOIN pg_stat_activity ON pid = procpid
+sdb-# WHERE granted = true
+sdb-# AND transaction IN (SELECT transaction FROM pg_locks WHERE granted = false);
-<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>
-ERROR: could not find hash function for hash operator 716373
-</programlisting>
+ <para>
+ Il semble que les fonctions <function>xxid</function> de &slony1;
+ prétendent pouvoir faire du hachage, mais qu'elles n'y arrivent pas.
+ </para>
-<para> Il semble que les fonctions <function>xxid</function> de &slony1; prétendent pouvoir faire du hashing, mais qu'elles n'y arrivent pas.</para>
+ <para>
+ Que se passe-t-il ?
+ </para>
+ </question>
+ <answer>
+ <para>
+ &slony1; a défini un nouveau type de données et d'opérateurs XXID afin
+ de permettre la manipulation des identifiants de transaction qui sont
+ employés pour grouper ensemble les mises à jour qui sont associées
+ dans une même transaction.
+ </para>
-<para> Que se passe-t-il ? </para>
+ <para>
+ Ces opérateurs n'étaient pas disponible pour &postgres; version 7.3 et
+ inférieure ; afin de rendre &slony1; opérationnel avec la version
+ 7.3, des fonctions spécifiques doivent être ajoutées. L'opérateur
+ <function>=</function> a été marqué comme supportant le hachage, mais
+ pour que cela fonctionne, l'opérateur de jointure doit apparaître dans
+ une classe d'opérateurs d'index haché. Cela n'a pas été défini ainsi
+ et, en conséquence, les requêtes (comme celle ci-dessus) qui décident
+ d'employer des jointures par hachage échoueront.
+ </para>
+ </answer>
-</question>
+ <answer>
+ <para>
+ Ceci <emphasis>n'a pas</emphasis> été considéré comme bugs
+ <quote>critiques</quote>, car &slony1; ne produit pas de requêtes
+ employant des jointures de hachage. Ce problème ne devrait pas perturber
+ la réplication.
+ </para>
+ </answer>
-<answer><para> &slony1; a défini un nouveau type de données et d'opérateurs XXID
-afin de permettre la manipulation des IDs de transaction qui sont employés
-pour grouper ensemble, les mises à jour qui sont associées dans une même transaction.
-</para>
+ <answer>
+ <para>
+ Les versions suivantes de &slony1; (<emphasis>par exemple :</emphasis>
+ 1.0.6, 1.1) omettent l'indicateur <command>HASHES</command>.
+ </para>
+ </answer>
-<para> Ces opérateurs n'étaient pas disponible pour &postgres; version
-7.3 et inférieur; afin de rendre &slony1; opérationnel avec la version 7.3, des fonctions spécifiques
-doivent être ajoutées. L'opérateur <function>=</function>
-a été marqué comme supportant
-le hachage, mais pour que cela fonctionne, l'opérateur de jointure doit
-apparaître dans une classe d'opérateur d'index haché. Cela n'a pas été défini ainsi,
-et en conséquence, les requêtes (comme celle ci-dessus) qui décident d'employer
-des hash-joins échoueront. </para> </answer>
+ <answer>
+ <para>
+ Supposons que vous souhaitiez réparer une instance existante, et vous
+ constatez que vos propres scripts ne fonctionnent pas bien, vous pouvez
+ suivre la démarche suivante :
+ </para>
-<answer> <para> Ceci <emphasis> n'a pas </emphasis>
-été considéré comme bug <quote>critiques</quote>, car &slony1;
-ne produit pas de requêtes employant des hash-join. Ce problème ne devrait
-pas perturber la réplication. </para> </answer>
-
-<answer> <para> Les versions suivantes de &slony1; (<emphasis>par exemple :</emphasis>
-1.0.6, 1.1) omettent l'indicateur <command>HASHES</command>
-</para> </answer>
-
-<answer> <para> Supposons que vous souhaitiez réparer une instance existante, et vous constatez
-que vos propres scripts ne fonctionneront pas bien, vous pouvez suivre la démarche suivante : </para>
-
-<programlisting>
-/* cbbrowne@[local]/dba2 slony_test1=*/ \x
+ <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');
@@ -2448,39 +2905,74 @@
/* cbbrowne@[local]/dba2 slony_test1=*/ update pg_operator set oprcanhash = 'f' where
oprname = '=' and oprnamespace = 2200 ;
-UPDATE 1
-</programlisting>
-</answer>
+UPDATE 1</programlisting>
+ </answer>
+ </qandaentry>
-</qandaentry>
-<qandaentry> <question><para> Je peux faire un <command>pg_dump</command>
-et rechargez les données beaucoup plus rapidement qu'avec <command>SUBSCRIBE
-SET</command>. Comment est-ce possible ? </para></question>
+ <qandaentry>
+ <question>
+ <para>
+ Je peux faire un <command>pg_dump</command> et recharger les données
+ beaucoup plus rapidement qu'avec <command>SUBSCRIBE SET</command>.
+ Comment est-ce possible ?
+ </para>
+ </question>
-<answer><para> &slony1; dépend de l'existance d'un index sur la clef primaire
-et ne touche pas aux autres index pendant l'opération &postgres; <command>COPY</command> qui charge les données.
-Par ailleur il peut y avoir une dégradation de performance, provoquée par l'évènement <command>COPY SET</command> (un
-évènement généré lors d'un abonnement) dans la mesure où l'opération commence par une suppression des contenus des tables, ce qui laisse la tables remplie de tuples morts.</para>
+ <answer>
+ <para>
+ &slony1; dépend de l'existance d'un index sur la clef primaire et ne
+ touche pas aux autres index pendant l'opération &postgres;
+ <command>COPY</command> qui charge les données. Par ailleurs, il peut
+ y avoir une dégradation de performance, provoquée par l'événement
+ <command>COPY SET</command> (un événement généré lors d'un abonnement)
+ dans la mesure où l'opération commence par une suppression des contenus
+ des tables, ce qui laisse la table remplie de lignes mortes.
+ </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.
-Il est <emphasis>beaucoup</emphasis> plus performant de reconstruire les indexes sur une table entièrement re-importée, plutôt que de refaire les indexes à la volée lorsque les enregistrements sont rajoutés un à un à la table.</para></answer>
+ <para>
+ Lorsque vous utilisez <command>pg_dump</command> pour exporter le
+ contenu de la base, et que vous les re-importez après, les index ne sont
+ crées qu'à la fin. Il est <emphasis>beaucoup</emphasis> plus performant
+ de reconstruire les index sur une table entièrement re-importée, plutôt
+ que de refaire les index à la volée lorsque les enregistrements sont
+ rajoutés un à un à la table.
+ </para>
+ </answer>
-<answer><para> Si vous pouvez supprimer des indexes inutiles, lorsque <command>COPY</command> se met en marche, les performances sont sensiblement améliorée.
-Encore mieux, si vous pouvez faire un <command>TRUNCATE</command> sur les tables dont le contenu devra disparaître, les performances vont augmenter <emphasis>énormément</emphasis>. </para></answer>
+ <answer>
+ <para>
+ Si vous pouvez supprimer des index inutiles, lorsque
+ <command>COPY</command> se met en marche, les performances sont
+ sensiblement améliorée. Encore mieux, si vous pouvez faire un
+ <command>TRUNCATE</command> sur les tables dont le contenu devra
+ disparaître, les performances vont augmenter
+ <emphasis>énormément</emphasis>.
+ </para>
+ </answer>
-<answer><para> &slony1; en version 1.1.5 et supérieures, fait cela automatiquement;
-il <quote>dégage</quote> sur les indexes dans le catalogue de &postgres; afin de les cacher, de la même façon qu'il cache les triggers,
-puis il <quote>répare</quote> les pointeurs d'index et effectue une
-reindexationd de la table. </para> </answer>
-</qandaentry>
+ <answer>
+ <para>
+ &slony1;, en version 1.1.5 et supérieures, fait cela automatiquement ;
+ il <quote>dégage</quote> les index dans le catalogue de &postgres; afin
+ de les cacher, de la même façon qu'il cache les triggers, puis il
+ <quote>répare</quote> les pointeurs d'index et effectue une reindexation
+ de la table.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry id="dupkey">
-<question><para>La réplication échoue - Violation de Constrainte Unique</para>
+ <qandaentry id="dupkey">
+ <question>
+ <para>
+ La réplication échoue à cause d'une violation de contrainte unique.
+ </para>
-<para>Alors que la Réplication se déroule correctement depuis un bout de temps, lorsque que tout a coup 'un nœud rencontre un <quote>soucis</quote> et les erreurs suivantes envoyées dans le journal:
+ <para>
+ Alors que la réplication se déroule correctement depuis un bout de
+ temps, un nœud rencontre un <quote>soucis</quote> et les erreurs
+ suivantes sont envoyées dans le journal :
-<screen>
-DEBUG2 remoteWorkerThread_1: syncing set 2 with 5 table(s) from provider 1
+ <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
@@ -2498,266 +2990,405 @@
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>
+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ères</emphasis> requêtes SQL, celle qui contenait <command>log_cmdtype = 'I'</command>.
-Ce n'est pas évident du tout;e &slony1; regroupe 10 opérations de mise à jour ensemble, afin de diminuer les allers-retours réseau.</para></question>
+ <para>
+ La transaction s'annule, et &slony1; essaie à nouveau sans cesse. Le
+ problème est dû à une des <emphasis>dernières</emphasis> requêtes SQL,
+ celle qui contenait <command>log_cmdtype = 'I'</command>. Ce n'est pas
+ évident du tout ; &slony1; regroupe dix opérations de mise à jour
+ ensemble, afin de diminuer les allers-retours réseau.
+ </para>
+ </question>
-<answer><para> Il est difficile de déterminer avec <emphasis>exactitude</emphasis> l'origine de tout ceci.</para>
+ <answer>
+ <para>
+ Il est difficile de déterminer avec <emphasis>exactitude</emphasis>
+ l'origine de tout ceci.
+ </para>
-<para>En même temps, nous notons qu'il y a un problème : les transactions annulées ont été supprimées dans &sllog1;,
-et on constate qu'il est impossible de les récupérer.
-A ce stade, il parait nécessaire de supprimer l'ensemble de réplication (ou même le nœud), et de redémarrer la réplication à partir de zéro pour ce nœud.</para>
+ <para>
+ En même temps, nous notons qu'il y a un problème : les transactions
+ annulées ont été supprimées dans &sllog1;, et on constate qu'il est
+ impossible de les récupérer. À ce stade, il parait nécessaire de
+ supprimer l'ensemble de réplication (ou même le nœud), et de
+ redémarrer la réplication à partir de zéro pour ce nœud.
+ </para>
-<para>Dans &slony1; 1.0.5, l'opération de purge de &sllog1; devient plus prudente, en refusant
-de purger des entrées qui n'ont pas encore été synchronisées, pendanttr au moins 10 minutes sur l'ensemble des nœuds. Il n'est pas certain que ceci empêche que
-<quote>le problème</quote> ait lieu, mais il paraît plausible que cela laisse assez de données dans &sllog1; 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 &sllog1; était brutalement purgée, donc cette solution permet de résoudre complètement ce genre d'incident.</para>
+ <para>
+ Dans &slony1; 1.0.5, l'opération de purge de &sllog1; devient plus
+ prudente, en refusant de purger des entrées qui n'ont pas encore été
+ synchronisées, pendant au moins dix minutes sur l'ensemble des
+ nœuds. Il n'est pas certain que ceci empêche que le
+ <quote>problème</quote> ait lieu, mais il paraît plausible que cela
+ laisse assez de données dans &sllog1; 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 &sllog1;
+ était brutalement purgée, donc cette solution permet de résoudre
+ complètement ce genre d'incident.
+ </para>
-<para> C'est une honte de devoir reconstruire une réplication volumineuse sur un nœud à cause de cela.
-Si vous découvrez que le problème persiste,
-La bonne idée serait de diviser la réplication
-en plusieurs ensemble de réplication afin de dimininuer
-la charge de travail lors de la reconstruction de la réplication.
-Si un seul ensemble est cassé, vous n'auriez qu'à désabonner et supprimer celui-ci.
-</para>
+ <para>
+ C'est une honte de devoir reconstruire une réplication volumineuse sur
+ un nœud à cause de cela. Si vous découvrez que le problème
+ persiste, la bonne idée serait de diviser la réplication en plusieurs
+ ensembles de réplication afin de dimininuer la charge de travail lors
+ de la reconstruction de la réplication. Si un seul ensemble est cassé,
+ vous n'auriez qu'à désabonner et supprimer celui-ci.
+ </para>
-<para> Dans un cas, nous avons trouvé dans le journal de trace deux lignes <emphasis> identiques </emphasis> concernant l'insertion dans &sllog1;.
-Ceci <emphasis> devrait
-</emphasis> être impossible d'autant plus qu'il s'agit d'une clef primaire sur &sllog1;. La dernière théorie sur le sujet laisserait à penser que cette situation
-viendrait du fait que l'index de <emphasis>cette</emphasis>
-clé était peut-être corrompu (à cause d'un bug de &postgres;),
-et qu'il serait possible d'éviter ce problème en exécutant la
-commande suivante:</para>
+ <para>
+ Dans un cas, nous avons trouvé dans le journal de trace deux lignes
+ <emphasis>identiques</emphasis> concernant l'insertion dans &sllog1;.
+ Ceci <emphasis>devrait</emphasis> être impossible d'autant plus qu'il
+ s'agit d'une clef primaire sur &sllog1;. La dernière théorie sur le
+ sujet laisserait à penser que cette situation viendrait du fait que
+ l'index de <emphasis>cette</emphasis> clé était peut-être corrompu
+ (à cause d'un bug de &postgres;), et qu'il serait possible d'éviter ce
+ problème en exécutant la commande suivante :
+ </para>
-<programlisting>
-# reindex table _slonyschema.sl_log_1;
-</programlisting>
+ <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>
+ <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é être un bug dans &postgres; plutot qu'un bug dans &slony1;. La version 7.4.8 a intégré deux solutions qui permettent de résoudre ce cas. Donc si vous avez un noyau de &postgres; antérieur à 7.4.8,
-vous devriez migrer pour éviter l'erreur.
-</para>
-</answer>
-</qandaentry>
-<qandaentry> <question><para>J'ai commencé à faire une sauvegarde via
-<application>pg_dump</application>, et Slony
-s'arrête soudainement</para></question>
+ <answer>
+ <para>
+ Ce problème s'est avéré être un bug dans &postgres; plutôt qu'un bug
+ dans &slony1;. La version 7.4.8 a intégré deux solutions qui permettent
+ de résoudre ce cas. Donc, si vous avez un noyau de &postgres; antérieur
+ à 7.4.8, vous devriez migrer pour éviter l'erreur.
+ </para>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question>
+ <para>
+ J'ai commencé à faire une sauvegarde via
+ <application>pg_dump</application>, et Slony s'arrête soudainement.
+ </para>
+ </question>
-<answer><para>Aïe. Ce qui se passe ici est un conflit entre:
-<itemizedlist>
+ <answer>
+ <para>
+ Aïe. Ce qui se passe ici est un conflit entre :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <application>pg_dump</application>, qui pose un verrou
+ <command>AccessShareLock</command> sur toutes les tables de la
+ base, y compris celle de &slony1; et
+ </para>
+ </listitem>
-<listitem><para> <application>pg_dump</application>, qui pose un verrou <command>AccessShareLock</command> sur toutes les tables de la base, y compris celle de &slony1; et</para></listitem>
+ <listitem>
+ <para>
+ Un événement SYNC de &slony1; qui veut poser un verrou
+ <command>AccessExclusiveLock</command> sur la table <xref
+ linkend="table.sl-event"/>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ La requête initiale qui est bloquée est :
-<listitem><para> Un événement SYNC de &slony1; qui veut poser un verrou
-<command>AccessExclusiveLock</command> sur la table <xref
-linkend="table.sl-event"/>.</para></listitem> </itemizedlist></para>
+ <screen>SELECT "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);</screen>
+ </para>
-<para>La requête initiale qui est bloquée est :
+ <para>
+ (vous pouvez voir ceci dans la vue <envar>pg_stat_activity</envar>, si
+ l'affichage des requête est activé dans
+ <filename>postgresql.conf</filename>)
+ </para>
-<screen>
-select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);
-</screen></para>
+ <para>
+ La requête qui demande ce verrou vient de la fonction
+ <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
+ <filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui
+ est :
-<para>(vous pouvez voir ceci dans la vue <envar>pg_stat_activity</envar>, si l'affichage des requête est activé dans
-<filename>postgresql.conf</filename>)</para>
+ <programlisting>LOCK TABLE %s.sl_event;
+INSERT INTO %s.sl_event (...stuff...)
+SELECT currval('%s.sl_event_seq');</programlisting>
+ </para>
-<para>La requête qui demandece verrou vient de la fonction <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
-<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui est :
+ <para>
+ La demande de <command>VERROU</command> va donc attendre et durer
+ jusqu'Ã ce que <command>pg_dump</command> (ou un autre programme ayant
+ un verrou d'accès sur <xref linkend="table.sl-event"/>) se termine.
+ </para>
-<programlisting>
- LOCK TABLE %s.sl_event;
- INSERT INTO %s.sl_event (...stuff...)
- SELECT currval('%s.sl_event_seq');
-</programlisting></para>
+ <para>
+ Chaque lecture touchant <xref linkend="table.sl-event"/> sera bloqué
+ derrière les appels à <function>createEvent</function>.
+ </para>
-<para>La demande de <command>VERROU</command> va donc attendre et
-durer jusqu'à ce que <command>pg_dump</command> (un autre programme ayant un verrou d'accès sur <xref linkend="table.sl-event"/>)
-se termine.</para>
+ <para>
+ Les réponses à cette question sont multiples :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Indiquer explicitement à <application>pg_dump</application> les
+ schémas qu'il doit exporter en utilisant l'option
+ <option>--schema=quoiquecesoit</option>, et ne pas essayer
+ d'exporter le schéma du cluster.
+ </para>
+ </listitem>
-<para>Chaque lecture touchant
-<xref linkend="table.sl-event"/> sera bloqué derrière les appels à
-<function>createEvent</function>.</para>
+ <listitem>
+ <para>
+ Il sera utile aussi d'avoir une option
+ <option>--exclude-schema</option> dans
+ <application>pg_dump</application> afin d'exclure le schéma du
+ cluster de &slony1;. Pourquoi pas dans la 8.2...
+ </para>
+ </listitem>
-<para>Les réponses à cette question sont multiples:
-<itemizedlist>
-
-<listitem><para> Indiquer explicitement à <application>pg_dump</application>
-les schémas qu'il doit exporter en utilisant l'option <option>--schema=whatever</option>, et ne pas essayer d'exporter le schéma du cluster.</para></listitem>
-
-<listitem><para> Il sera utile aussi d'avoir une option
-<option>--exclude-schema</option> dans
-<application>pg_dump</application> afin d'exclure le schéma du cluster de &slony1;. Pourquoi pas dans 8.2...</para></listitem>
-
-<listitem><para>Notez que la version 1.0.5 utilise des verrous plus précis et moins exclusifs qui évitent ce problème.</para></listitem>
-</itemizedlist></para>
-</answer></qandaentry>
-
+ <listitem>
+ <para>
+ Notez que la version 1.0.5 utilise des verrous plus précis et
+ moins exclusifs qui évitent ce problème.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </answer>
+ </qandaentry>
</qandadiv>
-<qandadiv id="faqoddities"> <title> &slony1; FAQ: Bizareries et modifications dans Slony-I </title>
-<qandaentry><question><para> Que se produit-il avec les règles et les déclencheurs pour ls tables répliquées par
-&slony1;?</para>
-</question>
+<qandadiv id="faqoddities">
+ <title>FAQ &slony1; : Bizzareries et modifications dans Slony-I</title>
-<answer><para> Premièrement regardons comment ceci est géré
-<emphasis>en dehors</emphasis> du cas spécifique de la commande Slonik<xref
-linkend="stmtstoretrigger"/>. </para>
+ <qandaentry>
+ <question>
+ <para>
+ Que se produit-il avec les règles et les déclencheurs pour les tables
+ répliquées par &slony1; ?
+ </para>
+ </question>
-<para> La fonction <xref
-linkend="function.altertableforreplication-integer"/> prépare chacune des tables
-pour la réplication.</para>
+ <answer>
+ <para>
+ Tout d'abord, regardons comment ceci est géré <emphasis>en
+ dehors</emphasis> du cas spécifique de la commande Slonik <xref
+ linkend="stmtstoretrigger"/>.
+ </para>
-<itemizedlist>
+ <para>
+ La fonction <xref linkend="function.altertableforreplication-integer"/>
+ prépare chacune des tables pour la réplication.
+ </para>
-<listitem><para> Sur le nœud maître, ceci implique l'ajout sur la table d'un déclencheur
-qui utilise la fonction <xref linkend="function.logtrigger"/>.</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Sur le nœud maître, ceci implique l'ajout sur la table d'un
+ déclencheur qui utilise la fonction <xref
+ linkend="function.logtrigger"/>.
+ </para>
-<para> Le déclencheur a pour action d'enregistrer, toutes les mises à jours dans
-la table &sllog1; de &slony1;.
-</para></listitem>
+ <para>
+ Le déclencheur a pour action d'enregistrer toutes les mises à jours
+ dans la table &sllog1; de &slony1;.
+ </para>
+ </listitem>
-<listitem><para> Sur un nœud d'abonné, ceci revient à désactiver les déclencheurs et les règles,
-puis, via un déclencheur, de refuser le droit d'accès en écriture sur celle-ci en
-utilisant la fonction <function>denyAccess()</function>.</para>
+ <listitem>
+ <para>
+ Sur un nœud d'abonné, ceci revient à désactiver les
+ déclencheurs et les règles, puis, via un déclencheur, de refuser
+ le droit d'accès en écriture sur celle-ci en utilisant la fonction
+ <function>denyAccess()</function>.
+ </para>
-<para> Jusqu'à la version 1.1 (et peut-être après), la
-<quote>désactivation</quote> est faite en modifiant
-la valeur de <envar>tgrelid</envar> dans les tables
-<envar>pg_trigger</envar> ou <envar>pg_rewrite</envar>
- en pointant l'identifiant OID sur
-la <quote>clé primaire</quote> de l'index du catalogue, plutôt que
-sur la table elle-même.</para></listitem>
+ <para>
+ Jusqu'à la version 1.1 (et peut-être après), la
+ <quote>désactivation</quote> est faite en modifiant la valeur de
+ <envar>tgrelid</envar> dans les tables <envar>pg_trigger</envar>
+ ou <envar>pg_rewrite</envar> en pointant l'identifiant OID sur la
+ <quote>clé primaire</quote> de l'index du catalogue, plutôt que sur
+ la table elle-même.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ Un effet secondaire malheureux est que cette gestion des règles et des
+ déclencheurs a pour effet de les <quote>piétiner</quote>. Les règles
+ et les déclencheurs sont toujours là , mais ne sont plus correctement
+ attachés à leurs tables. Si vous faites un <command>pg_dump</command>
+ sur un <quote>nœud abonné</quote>, il ne trouvera ni les règles
+ ni les déclencheurs, et du coup il ne s'attend pas à les voir associés
+ Ã un index.
+ </para>
+ </answer>
-</itemizedlist>
+ <answer>
+ <para>
+ Maintenant, observez comment <xref linkend="stmtstoretrigger"/> entre
+ en jeu.
+ </para>
-<para> Un effet secondaire malheureux est que cette gestion des règles et des déclencheurs a pour effet de les <quote>piétiner</quote>.
-Les règles et les déclencheurs sont toujours là,
-mais ne plus correctement attachés à leurs tables. Si vous faite un <command>pg_dump</command> sur
-<quote>le nœud d'abonné</quote>, il ne trouvera pas les règles ni les déclencheurs, et puisqu' il ne s'attend pas
-à les voir associés à un index.</para>
+ <para>
+ Pour simplifier, cette commande permet de restaurer les déclencheurs
+ avec la fonction <function>alterTableRestore(table id)</function>, qui
+ restaure l'identifiant OID de la table dans la colonne
+ <envar>tgrelid</envar> de <envar>pg_trigger</envar> ou
+ <envar>pg_rewrite</envar> sur le nœud affecté.
+ </para>
+ </answer>
-</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
+ nœud d'origine. Clairement, il faudra faire :
+ </para>
-<answer> <para> Maintenant observer comment <xref linkend="stmtstoretrigger"/>
-entre en jeu.</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>
-<para> Pour simplifier, cette commande permet de restaurer les déclencheurs
-avec la fonction <function>alterTableRestore(table id)</function>,
- qui restaure l'identifiant OID
-de la table dans la colonne <envar>tgrelid</envar> de <envar>pg_trigger</envar> ou
-<envar>pg_rewrite</envar> sur le nœud affecté.</para></answer>
+ </answer>
+ </qandaentry>
-<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 nœud 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>
-
<!-- todo -->
-<qandaentry> <question> <para> J'ai essayé les commandes <xref
-linkend="stmtddlscript"/> ou <xref linkend="stmtmoveset"/>, et trouvé
-les messages suivants sur l'un des abonnés :</para>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai essayé les commandes <xref linkend="stmtddlscript"/> ou <xref
+ linkend="stmtmoveset"/>, et trouvé les messages suivants sur l'un des
+ abonnés :
+ </para>
-<screen>
-NOTICE: Slony-I: multiple instances of trigger defrazzle on table frobozz
+ <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>
+ERROR: Slony-I: Unable to disable triggers</screen>
+ </question>
-<answer> <para> La difficulté semble venir du fait que
-vous avez ajouté des déclencheurs sur des tables dont le nom rentre en conflit,
-avec les déclencheurs que &slony1; a caché. </para>
+ <answer>
+ <para>
+ La difficulté semble venir du fait que vous avez ajouté des
+ déclencheurs sur des tables dont le nom rentre en conflit, avec les
+ déclencheurs que &slony1; a caché.
+ </para>
-<para> &slony1; cache des déclencheurs (sauf ceux marqués comme <quote>visibles</quote>
-via <xref linkend="stmtstoretrigger"/>) en les attachant à la clé primaire de leur table.
-Dans le cas d'un déclencheur pour clef étrangère, ou d'autres déclencheurs de cohérence des données,
-il est complètement inutile de les placer sur un abonnné,
-au contraire ces déclencheurs doivent être mis en place
-sur le nœud d'origine. En revanche, les déclencheurs de type
-<quote>invalidation de cache</quote> peuvent être placés sur l'abonné.</para>
+ <para>
+ &slony1; cache des déclencheurs (sauf ceux marqués comme
+ <quote>visibles</quote> via <xref linkend="stmtstoretrigger"/>) en les
+ attachant à la clé primaire de leur table. Dans le cas d'un déclencheur
+ pour clef étrangère ou d'autres déclencheurs de cohérence des données,
+ il est complètement inutile de les placer sur un abonnné. Au contraire,
+ ces déclencheurs doivent être mis en place sur le nœud d'origine.
+ En revanche, les déclencheurs de type <quote>invalidation de cache</quote>
+ peuvent être placés sur l'abonné.
+ </para>
-<para> La <emphasis>bonne manière</emphasis> de manipuler ce genre de déclencheurs est d'utiliser
- <xref linkend="stmtstoretrigger"/>, qui indique à
-&slony1; de ne pas désactiver le déclencheur. </para> </answer>
+ <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 le déclencheur.
+ </para>
+ </answer>
-<answer> <para> Mais il peut y avoir quelques DBAs intrépides, qui vont assumer individuellement ce travail en
-installant les déclencheur à la main sur l'abonné, et cela mène généralement créer ce genre de situation. Que faire ? Que faire ?
-</para>
+ <answer>
+ <para>
+ Mais il peut y avoir quelques DBA intrépides qui vont assumer
+ individuellement ce travail en installant les déclencheurs à la main
+ sur l'abonné, et cela mène généralement à 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 que slony tente de les
-restaurer.
-Dans le meilleur des cas, si le DBA est intrépide et réactif, il aurait fait cela
-<emphasis>avant</emphasis> que le message ait le temps d'arriver. </para>
+ <para>
+ La réponse est assez simple : retirez le déclencheur
+ <quote>spécifique</quote> sur l'abonné avant que slony tente de les
+ restaurer. Dans le meilleur des cas, si le DBA est intrépide et réactif,
+ il aurait fait cela <emphasis>avant</emphasis> que le message ait le
+ temps d'arriver.
+ </para>
-<para> Si le DBA n'est pas intrépide, il faut se connecter au nœud
-qui pose problème, et de supprimer la version <quote>visible</quote> du déclencheur utilisant l'ordre
- <acronym>SQL</acronym> <command>DROP
-TRIGGER</command>. Ceci permet à l'évènement de se dérouler.
-Si l'évènement était <xref linkend="stmtddlscript"/>, alors notre
-<quote>pas-tellement-intrépide </quote> DBA devra remettre en place le déclencheur à la main, ou, s'il a plus de sagesse, il les réactivera avec
-<xref linkend="stmtstoretrigger"/>.</para>
-</answer>
-</qandaentry>
+ <para>
+ Si le DBA n'est pas intrépide, il faut se connecter au nœud qui
+ pose problème, et de supprimer la version <quote>visible</quote> du
+ déclencheur utilisant l'ordre <acronym>SQL</acronym> <command>DROP
+ TRIGGER</command>. Ceci permet à l'évènement de se dérouler. Si
+ l'évènement était <xref linkend="stmtddlscript"/>, alors notre
+ <quote>pas-tellement-intrépide </quote> DBA devra remettre en place
+ le déclencheur à la main, ou, s'il a plus de sagesse, il les réactivera
+ avec <xref linkend="stmtstoretrigger"/>.
+ </para>
+ </answer>
+ </qandaentry>
-<qandaentry id="neededexecddl">
+ <qandaentry id="neededexecddl">
+ <question>
+ <para>
+ Le comportement : tous les nœuds abonnés commencent à tomber
+ et ont le message d'erreur suivant dans le journal.
+ (lorsque j'ai rencontré ce problème, il y avait une longue requête SQL
+ devant chaque message)
+ </para>
-<question> <para> Le comportement : tous les nœuds abonné commencent
- à tomber et ont le message d'erreur suivant dans le journal,
-(lorsque j'ai rencontré ce problème, il y avait une longue requête SQL devant chaque message ):</para>
+ <screen>ERROR remoteWorkerThread_1: helper 1 finished with error
+ERROR remoteWorkerThread_1: SYNC aborted</screen>
+ </question>
-<screen>
-ERROR remoteWorkerThread_1: helper 1 finished with error
-ERROR remoteWorkerThread_1: SYNC aborted
-</screen>
-</question>
+ <answer>
+ <para>
+ La cause : vous avez probablement effectué un <command>ALTER
+ TABLE</command> directement sur la base au lieu de l'utilisation de la
+ commande slonik <xref linkend="stmtddlscript"/>.
+ </para>
-<answer> <para> La cause : vous avez probablement effectué
-un <command>alter table</command> directement sur la
-base au lieu d'utiliser la commande slonik
-<xref linkend="stmtddlscript"/>.</para>
+ <para>
+ La solution consiste à remettre le trigger sur la table affectée, et de
+ corriger à la main les données afférentes dans &sllog1;/&sllog2;.
+ </para>
-<para>La solution consiste à remettre le trigger sur la table affectée,
-et de corriger à la main les données afférentes dans &sllog1;/&sllog2;.</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ À partir des journaux de slon ou de &postgres;, vous devrez
+ identifier la requête SQL exacte qui a causé l'anomalie.
+ </para>
+ </listitem>
-<itemizedlist>
+ <listitem>
+ <para>
+ Vous avez besoin de réparer les déclencheurs définis par Slony
+ dans la table en question. Ceci peut se faire à l'aide de la
+ procédure suivante :
+ </para>
-<listitem><para> A partir des journaux de slon ou de &postgres;,
-vous devrez identifier la requête sql exacte qui a causé l'anomalie.</para></listitem>
-
-<listitem><para> Vous avez besoin de réparer les déclencheurs
-définis par Slony dans la table en question.
-Ceci peut se faire à l'aide de la procédure suivante :</para>
-
-<screen>
-BEGIN;
+ <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>
+COMMIT;</screen>
-<para>Ensuite vous devez trouver les enregistrements dans &sllog1;/&sllog2; qui sont incohérents et les corriger.
-Il sera préférable d'arrêter les démons Slon
-pour l'ensemble des nœuds excepté celui du maître;
-de cette manière, si vous faites une erreur,elle ne se propagera
-pas immédiatement sur tous les nœuds abonnés.</para>
+ <para>
+ Ensuite, vous devez trouver les enregistrements dans
+ &sllog1;/&sllog2; qui sont incohérents et les corriger. Il sera
+ préférable d'arrêter les démons Slon pour l'ensemble des nœuds
+ excepté celui du maître ; de cette manière, si vous faites une
+ erreur, elle ne se propagera pas immédiatement sur tous les
+ nœuds abonnés.
+ </para>
-<para> Voici un exemple:</para>
+ <para>
+ Voici un exemple :
+ </para>
-<screen>
-BEGIN;
+ <screen>BEGIN;
LOCK TABLE customer_account;
@@ -2785,25 +3416,21 @@
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';
+update _app1.sl_log_1 SET log_cmddata = 'balance=''125192.00'' where pkey=''60''' where log_actionseq = '68387029';</screen>
+ </listitem>
+ </itemizedlist>
+ </answer>
+ </qandaentry>
-</screen>
-</listitem>
+ <qandaentry>
+ <question>
+ <para>
+ Le nœud numéro 1 a été supprimé via <xref
+ linkend="stmtdropnode"/>, et le &lslon; d'un autre nœud plante
+ systématiquement avec le message d'erreurs suivant :
+ </para>
-</itemizedlist>
-</answer>
-
-</qandaentry>
-
-<qandaentry>
-
-<question><para> Le nœud numéro 1 a été supprimé via <xref
-linkend="stmtdropnode"/>, et le &lslon; d'un autre nœud
-plante systématiquement avec le message
-d'erreurs suivant:</para>
-
-<screen>
-ERROR remoteWorkerThread_3: "begin transaction; set transaction isolation level
+ <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
@@ -2814,92 +3441,111 @@
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>
+DEBUG1 syncThread: thread done</screen>
-<para> Il semble évident qu'un appel à <xref linkend="stmtstorelisten"/> n'avait pas encore été propagé avant que le nœud 1
-soit éliminé.</para></question>
+ <para>
+ Il semble évident qu'un appel à <xref linkend="stmtstorelisten"/>
+ n'avait pas encore été propagé avant que le nœud 1 soit éliminé.
+ </para>
+ </question>
-<answer id="eventsurgery"><para> Ceci illustre le cas où vous avez besoin de
-réaliser <quote>opération chirurgicale</quote> sur un ou plusieurs nœuds.
-Un évènement<command>STORE_LISTEN</command> demeure sans réponse
-alors qu'il veut
-ajouter une voie d'écoute qui <emphasis>ne peut pas</emphasis>
-être crée car le nœud 1 ainsi que toutes les voies vers le
-nœud 1 ont disparus.</para>
+ <answer id="eventsurgery">
+ <para>
+ Ceci illustre le cas où vous avez besoin de réaliser une
+ <quote>opération chirurgicale</quote> sur un ou plusieurs nœuds.
+ Un évènement <command>STORE_LISTEN</command> demeure sans réponse alors
+ qu'il veut ajouter une voie d'écoute qui <emphasis>ne peut pas</emphasis>
+ être créé car le nœud 1 ainsi que toutes les voies vers le
+ nœud 1 ont disparu.
+ </para>
-<para> Supposons, pour la démonstration, que les nœuds encore en place soient le 2 et le 3, ainsi le rapport d'erreur est remonté au nœud 3.</para>
+ <para>
+ Supposons, pour la démonstration, que les nœuds encore en place
+ soient le 2 et le 3, ainsi le rapport d'erreur est remonté au
+ nœud 3.
+ </para>
-<para> cela implique que l'évènement est stocké sur le nœud 2,
-puisqu'il ne peut pas être sur le nœud 3, vu qu'il n'a pas été
-traité avec succès. La manière la plus facile à faire face à
-cette situation,
-est, de supprimer sur la ligne erronées dans
- <xref linkend="table.sl-event"/> sur lenœud 2.
-Vous vous connectez à la base du nœud 2, et vous recherchez
- l'évènement <command>STORE_LISTEN</command>:</para>
+ <para>
+ Cela implique que l'évènement soit stocké sur le nœud 2,
+ puisqu'il ne peut pas être sur le nœud 3, vu qu'il n'a pas été
+ traité avec succès. La manière la plus facile pour faire face à cette
+ situation est de supprimer la ligne erronée dans <xref
+ linkend="table.sl-event"/> sur le nœud 2. Vous vous connectez Ã
+ la base du nœud 2, et vous recherchez l'évènement
+ <command>STORE_LISTEN</command> :
+ </para>
-<para> <command> select * from sl_event where ev_type =
-'STORE_LISTEN';</command></para>
+ <para>
+ <command>SELECT * FROM sl_event WHERE ev_type='STORE_LISTEN';</command>
+ </para>
-<para> La requête peut ramener plusieurs lignes, mais ne supprimez que la partie nécessaire.</para>
+ <para>
+ La requête peut ramener plusieurs lignes, mais ne supprimez que la
+ partie nécessaire.
+ </para>
-<screen>
--# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
+ <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>
+COMMIT</screen>
-<para> La prochaine fois que le <application>slon</application> du nœud 3 va démarrer, il ne trouvera plus l' évènement
-<command>STORE_LISTEN</command> <quote>erroné</quote>, et la réplication pourra se poursuivre.
+ <para>
+ La prochaine fois que le démon <application>slon</application> du
+ nœud 3 va démarrer, il ne trouvera plus l'évènement
+ <command>STORE_LISTEN</command> <quote>erroné</quote>, et la
+ réplication pourra se poursuivre.
+ (cependant, vous pourrez ensuite voir surgir un vieil évènement
+ enregistré qui fait référence à une configuration qui n'existe plus...)
+ </para>
+ </answer>
+ </qandaentry>
-( Cependnat vous pourrez ensuite voir surgir un vieil évènement
-enregistré qui fait référence à une configuration qui n'existe plus...) </para></answer>
+ <qandaentry>
+ <question>
+ <para>
+ I have a database where we have been encountering the following error
+ message in our application:
+ </para>
-</qandaentry>
+ <screen>permission denied for sequence sl_action_seq</screen>
-<qandaentry>
+ <para>
+ When we traced it back, it was due to the application calling
+ <function>lastval()</function> to capture the most recent sequence
+ update, which happened to catch the last update to a &slony1; internal
+ sequence.
+ </para>
+ </question>
-<question> <para> I have a database where we have been encountering
-the following error message in our application: </para>
+ <answer>
+ <para>
+ &slony1; uses sequences to provide primary key values for log
+ entries, and therefore this kind of behaviour may (perhaps
+ regrettably!) be expected.
+ </para>
-<screen> permission denied for sequence sl_action_seq </screen>
+ <para>
+ Calling <function>lastval()</function>, to <quote>anonymously</quote>
+ get <quote>the most recently updated sequence value</quote>, rather
+ than using <function>currval('sequence_name')</function> is an unsafe
+ thing to do in general, as anything you might add in that uses DBMS
+ features for logging, archiving, or replication can throw in an extra
+ sequence update that you weren't expecting.
+ </para>
-<para> When we traced it back, it was due to the application calling
-<function> lastval() </function> to capture the most recent sequence
-update, which happened to catch the last update to a &slony1; internal
-sequence. </para>
-
-</question>
-
-<answer>
-<para> &slony1; uses sequences to provide primary key values for log
-entries, and therefore this kind of behaviour may (perhaps
-regrettably!) be expected. </para>
-
-<para> Calling <function>lastval()</function>, to
-<quote>anonymously</quote> get <quote>the most recently updated
-sequence value</quote>, rather than using
-<function>currval('sequence_name')</function> is an unsafe thing to do
-in general, as anything you might add in that uses DBMS features for
-logging, archiving, or replication can throw in an extra sequence
-update that you weren't expecting. </para>
-
-<para> In general, use of <function>lastval()</function> doesn't seem
-terribly safe; using it when &slony1; (or any similar trigger-based
-replication system such as <application>Londiste</application> or
-<application>Bucardo</application>) can lead to capturing unexpected
-sequence updates. </para>
-
-</answer>
-
-</qandaentry>
-
+ <para>
+ In general, use of <function>lastval()</function> doesn't seem terribly
+ safe; using it when &slony1; (or any similar trigger-based replication
+ system such as <application>Londiste</application> or
+ <application>Bucardo</application>) can lead to capturing unexpected
+ sequence updates.
+ </para>
+ </answer>
+ </qandaentry>
</qandadiv>
</qandaset>
Plus d'informations sur la liste de diffusion Trad