[Trad] [svn:pgfr] r1505 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 17 Mai 22:16:49 CEST 2010
Author: gleu
Date: 2010-05-17 22:16:48 +0200 (Mon, 17 May 2010)
New Revision: 1505
Modified:
traduc/trunk/slony/faq.xml
Log:
Suite de la traduction de la FAQ de Slony.
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2010-05-15 20:17:43 UTC (rev 1504)
+++ traduc/trunk/slony/faq.xml 2010-05-17 20:16:48 UTC (rev 1505)
@@ -43,47 +43,46 @@
</para>
<itemizedlist>
-
<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
- recompiler &slony1;.
- </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
+ 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
- commande <command>pg_config --configure</command>.
- </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
+ commande <command>pg_config --configure</command>.
+ </para>
</listitem>
<listitem>
<para>
- La version 1.1 de &slony1; simplifie considérablement les choses ;
+ 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>.
+ 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
- fichiers d'inclusion <command>#include</command>.
- </para>
+ &postgres; 8.0 et supérieur est généralement plus facile car
+ l'<quote>installation par défaut</quote> contient la totalité des
+ fichiers d'inclusion <command>#include</command>.
+ </para>
<para>
- Si vous utilisez 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
- install-all-headers</command>.
- </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
+ d'inclusions <command>#include</command></quote> du serveur. Ces
+ fichiers peuvent être installés par la commande <command>make
+ install-all-headers</command>.
+ </para>
</listitem>
</itemizedlist>
@@ -149,12 +148,12 @@
<screen>DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep user=postgres port=5432'
ERROR remoteListenThread_1: "select ev_origin, ev_seqno, ev_timestamp,
- ev_minxid, ev_maxxid, ev_xip,
- ev_type,
+ ev_minxid, ev_maxxid, ev_xip,
+ ev_type,
ev_data1, ev_data2,
- ev_data3, ev_data4,
- ev_data5, ev_data6,
- ev_data7, ev_data8 from "_pgbenchtest".sl_event e
+ ev_data3, ev_data4,
+ ev_data5, ev_data6,
+ ev_data7, ev_data8 from "_pgbenchtest".sl_event e
where (e.ev_origin = '1' and e.ev_seqno > '1') order by e.ev_origin, e.ev_seqno" - could not receive data from server: Operation now in progress</screen>
</para>
@@ -256,23 +255,23 @@
<itemizedlist>
<listitem>
- <para>
- Charger les nouvelles fonctions (depuis
- <filename>slony1_funcs.sql</filename>), notamment comprenant
- <function>upgradeSchema(text)</function>.
+ <para>
+ Charger les nouvelles fonctions (depuis
+ <filename>slony1_funcs.sql</filename>), notamment comprenant
+ <function>upgradeSchema(text)</function>.
</para>
- </listitem>
+ </listitem>
<listitem>
- <para>
- Lancer <function>upgradeSchema(text)</function> pour effectuer la
- migration nécessaire des schémas de la base.
- </para>
- </listitem>
+ <para>
+ Lancer <function>upgradeSchema(text)</function> pour effectuer la
+ migration nécessaire des schémas de la base.
+ </para>
+ </listitem>
<listitem>
- <para>
- Avertir les processus &lslon; du changement de configuration.
- </para>
- </listitem>
+ <para>
+ Avertir les processus &lslon; du changement de configuration.
+ </para>
+ </listitem>
</itemizedlist>
</para>
@@ -307,51 +306,51 @@
<itemizedlist>
<listitem>
<para>
- Prendre <filename>slony1_funcs.sql</filename> et faire trois
- remplacements dans ce fichier :
- </para>
+ Prendre <filename>slony1_funcs.sql</filename> et faire trois
+ remplacements dans ce fichier :
+ </para>
<itemizedlist>
<listitem>
- <para>
- Remplacer <quote>@CLUSTERNAME@</quote> avec le nom du cluster.
- </para>
- </listitem>
+ <para>
+ Remplacer <quote>@CLUSTERNAME@</quote> avec le nom du cluster.
+ </para>
+ </listitem>
<listitem>
- <para>
- Remplacer <quote>@MODULEVERSION@</quote> avec la version de
- &slony1; ; par exemple <quote>1.2.10</quote>
- </para>
+ <para>
+ Remplacer <quote>@MODULEVERSION@</quote> avec la version de
+ &slony1; ; par exemple <quote>1.2.10</quote>
+ </para>
</listitem>
<listitem>
- <para>
- Remplacer <quote>@NAMESPACE@</quote> avec le nom du namespace
- du cluster <quote>entre guillemets doubles</quote>, par exemple
- "_monCluster"
- </para>
- </listitem>
+ <para>
+ Remplacer <quote>@NAMESPACE@</quote> avec le nom du namespace
+ du cluster <quote>entre guillemets doubles</quote>, par exemple
+ "_monCluster"
+ </para>
+ </listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
- Recharger dans la base cet ensemble de fonctions <quote>mises à
- jour</quote>.
- </para>
+ 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
- <function>upgradeSchema('1.2.7')</function>;</command>, en supposant
- que la précédente version de &slony1; en cours était la 1.2.7.
+ 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.
</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>
@@ -374,149 +373,174 @@
<para>
Ceci arrive avec &postgres; 8.2.5, qui est nettement plus récent que la
- version 7.3.
+ 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
- <command>gcc</command>, elle utilise <command>-lpq</command> pour
- ajouter la bibliothèque.
+ 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.
</para>
<para>
Malheureusement, ce paquetage n'a pas de lien symbolique, reliant
- <filename>/usr/lib64/libpq.so</filename> à
- <filename>libpq.so.5.0</filename> ; c'est pourquoi la fonction
- configure n'arrive pas à 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.
+ <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.
</para>
<para>
Au final, ces informations doivent être envoyée vers ceux qui gèrent
- le paquet <filename>postgresql-libs.x86_64</filename>.
+ 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
- symboliques, les mauvais droits, le mauvais comportement de la part de
- votre compilateur C, tous peuvent potentiellement mener à ce même
- message d'erreur.
+ 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
+ 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>
-<qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ J'ai trouvé des types en conflit pour <envar>yyleng</envar> entre
+ <filename>parser.c</filename> et <filename>scan.c</filename>. Dans un
+ cas, le type <type>int</type> était en conflit avec le type
+ <type>yy_size_t</type>. Que puis-je faire ?
+ </para>
+ </question>
-<question> <para> I found conflicting types for <envar>yyleng</envar>
-between <filename>parser.c</filename> and <filename>scan.c</filename>.
-In one case, it used type <type>int</type>, conflicting with
-<type>yy_size_t</type>. What shall I do?</para> </question>
+ <answer>
+ <para>
+ Ceci a déjà été observé sur <application>MacOS</application> où
+ <application>flex</application> (qui génère
+ <filename>scan.c</filename>) et <application>bison</application>
+ qui génère <filename>parser.c</filename>) divergent dans leur gestion
+ de cette variable.
+ </para>
-<answer><para> This has been observed on <application>MacOS</application>,
-where <application>flex</application> (which generates
-<filename>scan.c</filename>) and <application>bison</application>
-(which generates <filename>parser.c</filename>) diverged in their
-handling of this variable. </para>
-<itemizedlist>
-<listitem><para> You might might <quote>hack</quote> <filename>scan.c</filename> by hand to use the matching type. </para> </listitem>
-<listitem><para> You might select different versions of <application>bison</application> or <application>flex</application> so as to get versions whose data types match. </para> </listitem>
-<listitem><para> Note that you may have multiple versions of <application>bison</application> or <application>flex</application> around, and might need to modify <envar>PATH</envar> in order to select the appropriate one.</para></listitem>
-</answer>
-
-
-
-</qandaentry>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Vous pouvez <quote>modifier</quote> <filename>scan.c</filename>
+ manuellement pour utiliser le bon type.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Vous pouvez sélectionner différentes versions de
+ <application>bison</application> ou <application>flex</application>
+ pour obtenir les versions où les types de données correspondent.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Notez que vous pourriez avoir plusieurs versions de
+ <application>bison</application> ou <application>flex</application>
+ installés, et que vous pourriez avoir besoin de modifier la variable
+ <envar>PATH</envar> pour sélectionner la bonne.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </answer>
+ </qandaentry>
</qandadiv>
-<qandadiv id="faqhowto"> <title> &slony1; FAQ: How Do I? </title>
+<qandadiv id="faqhowto">
+<title>FAQ &slony1; : Comment puis-je ?</title>
<qandaentry>
<question>
<para>
- I need to dump a database <emphasis>without</emphasis> getting
- &slony1; configuration (<emphasis>e.g.</emphasis> - triggers, functions,
- and such).
+ J'ai besoin de sauvegarder une base de données <emphasis>sans</emphasis>
+ la configuration de &slony1; (<emphasis>autrement dit</emphasis> sans
+ triggers, fonctions, etc).
</para>
</question>
<answer>
<para>
- Up to version 1.2, this is fairly nontrivial, requiring careful choice
- of nodes, and some moderately heavy <quote>procedure</quote>. One
- methodology is as follows:
+ Jusqu'à la version 1.2, ce n'est pas trivial et demande un choix
+ attentif des nœuds et quelques <quote>procédures</quote>
+ modérément conséquente. Voici une méthode :
</para>
<itemizedlist>
<listitem>
- <para>
- First, dump the schema from the node that has the
- <quote>master</quote> role. That is the only place, pre-2.0, where
- you can readily dump the schema using
- <application>pg_dump</application> and have a consistent schema.
- You may use the &slony1; tool <xref linkend="extractschema"/> to do
- this.
- </para>
- </listitem>
+ <para>
+ Tout d'abord, sauvegardez le schéma à partir du nœud maître.
+ C'est le seul endroit où vous pouvez directement sauvegarder le
+ schéma avec <application>pg_dump</application> et avoir un schéma
+ cohérent. Vous pouvez utiliser l'outil &slony1; <xref
+ linkend="extractschema"/> pour cela.
+ </para>
+ </listitem>
<listitem>
- <para>
- Take the resulting schema, which will <emphasis>not</emphasis>
- include the &slony1;-specific bits, and split it into two pieces:
+ <para>
+ Prenez le schéma résultant qui n'incluera <emphasis>pas</emphasis>
+ les éléments de &slony1; et divisez-le en deux parties :
</para>
<itemizedlist>
<listitem>
- <para>
- Firstly, the portion comprising all of the creations of tables
- in the schema.
+ <para>
+ Tout d'abord la portion comprenant tous les ordres de création
+ de table dans les schémas.
</para>
- </listitem>
+ </listitem>
<listitem>
- <para>
- Secondly, the portion consisting of creations of indices, constraints, and triggers.
- </para>
- </listitem>
+ <para>
+ Ensuite la portion contenant les créations d'index, de
+ contraintes et de triggers.
+ </para>
+ </listitem>
</itemizedlist>
</listitem>
<listitem>
- <para>
- Pull a data dump, using <command>pg_dump --data-only</command>, of
- some node of your choice. It doesn't need to be for the
- <quote>master</quote> node. This dump will include the contents of
- the &slony1;-specific tables; you can discard that, or ignore it.
- Since the schema dump didn't contain table definitions for the
- &slony1; tables, they won't be loaded.
- </para>
- </listitem>
+ <para>
+ Récupérer une sauvegarde des données seules en utilisant
+ <command>pg_dump --data-only</command> du nœud de votre
+ choix. Il n'est pas nécessaire que ce soit le nœud
+ <quote>maître</quote>. Cette sauvegarde incluera le contenu des
+ tables systèmes de &slony1; ; vous pouvez les supprimer ou
+ les ignorer. Comme la sauvegarde du schéma ne contient pas les
+ définitions de ces tables, elles ne seront pas chargées.
+ </para>
+ </listitem>
<listitem>
- <para>
- Finally, load the three components in proper order:
- </para>
+ <para>
+ Enfin, chargez les trois composants dans le bon ordre :
+ </para>
<itemizedlist>
- <listitem><para>Schema (tables)</para></listitem>
- <listitem><para>Data dump</para></listitem>
- <listitem><para>Remainder of the schema</para></listitem>
+ <listitem><para>Schéma (tables)</para></listitem>
+ <listitem><para>Données</para></listitem>
+ <listitem><para>Reste du schéma</para></listitem>
</itemizedlist>
</listitem>
</itemizedlist>
@@ -524,11 +548,11 @@
<answer>
<para>
- In &slony1; 2.0, the answer becomes simpler: Just take a
- <command>pg_dump --exclude-schema=_Cluster</command> against
- <emphasis>any</emphasis> node. In 2.0, the schemas are no longer
- <quote>clobbered</quote> on subscribers, so a straight
- <application>pg_dump</application> will do what you want.
+ Avec &slony1; 2.0, la réponse est plus simple : prenez seulement
+ une sauvegarde de type <command>pg_dump
+ --exclude-schema=_Cluster</command> sur un nœud quelqu'il soit.
+ En 2.0, les schémas ne sont plus corrompus, donc une sauvegarde simple
+ avec <application>pg_dump</application> doit faire ce que vous voulez.
</para>
</answer>
</qandaentry>
@@ -536,37 +560,38 @@
<qandaentry id="cannotrenumbernodes">
<question>
<para>
- I'd like to renumber the node numbers in my cluster. How can I renumber
- nodes?
+ J'aimerais renuméroter les nœuds de mon cluster. Comment puis-je
+ le faire ?
</para>
</question>
<answer>
<para>
- The first answer is <quote>you can't do that</quote> - &slony1; node
- numbers are quite <quote>immutable.</quote> Node numbers are deeply
- woven into the fibres of the schema, by virtue of being written into
- virtually every table in the system, but much more importantly by
- virtue of being used as the basis for event propagation. The only time
- that it might be <quote>OK</quote> to modify a node number is at some
- time where we know that it is not in use, and we would need to do
- updates against each node in the cluster in an organized fashion.
+ Une première réponse est <quote>ne faites pas ça</quote> - les numéros
+ des nœuds &slony1; ne sont <quote>pas modifiables</quote>. Les
+ numéros de nœuds sont utilisés partout dans le schéma. Ils sont
+ indiqués dans pratiquement toutes les tables systèmes de Slony. Encore
+ plus important, ils sont utilisés comme base de tout événement de
+ propagation. La seule fois où il pourrait être <quote>convenable</quote>
+ de modifier un numéro de nœud est au moment où nous savons qu'il
+ n'est pas utiliser et nous aurons besoin de faire les mises à jour sur
+ chaque nœud dans le cluster d'une façon organisée.
</para>
<para>
- To do this in an automated fashion seems like a
- <emphasis>huge</emphasis> challenge, as it changes the structure of the
- very event propagation system that already needs to be working in order
- for such a change to propagate.
+ Automatiser cette manipulation est un <emphasis>énorme</emphasis>
+ challenge, car les changements se font sur la structure du système de
+ propagation des événements qui a déjà besoin de fonctionner pour qu'un
+ tel changement soit propagé.
</para>
</answer>
<answer>
<para>
- If it is <emphasis>enormously necessary</emphasis> to renumber nodes,
- this might be accomplished by dropping and re-adding nodes to get rid
- of the node formerly using the node ID that needs to be held by another
- node.
+ Si c'est <emphasis>absolument nécessaire</emphasis> de renuméroter
+ les nœuds, cela peut se faire en supprimant puis en rajoutant
+ les nœuds pour se débarrasser de l'identifiant de nœud
+ nécessaire.
</para>
</answer>
</qandaentry>
@@ -579,25 +604,25 @@
<question>
<para>
Can I use &slony1; to replicate changes back and forth on my database
- between my two offices?
+ between my two offices?
</para>
</question>
<answer>
<para>
At one level, it is <emphasis>theoretically possible</emphasis> to do
- something like that, if you design your application so that each office
- has its own distinct set of tables, and you then have some system for
- consolidating the data to give them some common view. However, this
- requires a great deal of design work to create an application that
- performs this consolidation.
+ something like that, if you design your application so that each office
+ has its own distinct set of tables, and you then have some system for
+ consolidating the data to give them some common view. However, this
+ requires a great deal of design work to create an application that
+ performs this consolidation.
</para>
</answer>
<answer>
<para>
In practice, the term for that is <quote>multimaster replication,</quote>
- and &slony1; does not support <quote>multimaster replication.</quote>.
+ and &slony1; does not support <quote>multimaster replication.</quote>.
</para>
</answer>
</qandaentry>
@@ -606,21 +631,21 @@
<question>
<para>
I want to replicate all of the databases for a shared-database system
- I am managing. There are multiple databases, being used by my
- customers.
+ I am managing. There are multiple databases, being used by my
+ customers.
</para>
</question>
<answer>
<para>
For this purpose, something like &postgres; PITR (Point In Time
- Recovery) is likely to be much more suitable. &slony1; requires a slon
- process (and multiple connections) for each identifiable database, and
- if you have a &postgres; cluster hosting 50 or 100 databases, this will
- require hundreds of database connections. Typically, in <quote>shared
- hosting</quote> situations, DML is being managed by customers, who can
- change anything they like whenever <emphasis>they</emphasis> want.
- &slony1; does not work out well when not used in a disciplined manner.
+ Recovery) is likely to be much more suitable. &slony1; requires a slon
+ process (and multiple connections) for each identifiable database, and
+ if you have a &postgres; cluster hosting 50 or 100 databases, this will
+ require hundreds of database connections. Typically, in <quote>shared
+ hosting</quote> situations, DML is being managed by customers, who can
+ change anything they like whenever <emphasis>they</emphasis> want.
+ &slony1; does not work out well when not used in a disciplined manner.
</para>
</answer>
</qandaentry>
@@ -629,25 +654,25 @@
<question>
<para>
I want to be able to make DDL changes, and have them replicated
- automatically.
+ automatically.
</para>
</question>
<answer>
<para>
&slony1; requires that <xref linkend="ddlchanges"/> be planned for
- explicitly and carefully. &slony1; captures changes using triggers,
- and &postgres; does not provide a way to use triggers to capture DDL
- changes.
+ explicitly and carefully. &slony1; captures changes using triggers,
+ and &postgres; does not provide a way to use triggers to capture DDL
+ changes.
</para>
<note>
<para>
- There has been quite a bit of discussion, off and on, about how
- &postgres; might capture DDL changes in a way that would make triggers
+ There has been quite a bit of discussion, off and on, about how
+ &postgres; might capture DDL changes in a way that would make triggers
useful; nothing concrete has emerged after several years of
discussion.
- </para>
+ </para>
</note>
</answer>
</qandaentry>
@@ -656,17 +681,17 @@
<question>
<para>
I want to split my cluster into disjoint partitions that are not aware
- of one another. &slony1; keeps generating <xref
- linkend="listenpaths"/> that link those partitions together.
+ of one another. &slony1; keeps generating <xref
+ linkend="listenpaths"/> that link those partitions together.
</para>
</question>
<answer>
<para>
The notion that all nodes are aware of one another is deeply imbedded
- in the design of &slony1;. For instance, its handling of cleanup of
- obsolete data depends on being aware of whether any of the nodes are
- behind, and thus might still depend on older data.
+ in the design of &slony1;. For instance, its handling of cleanup of
+ obsolete data depends on being aware of whether any of the nodes are
+ behind, and thus might still depend on older data.
</para>
</answer>
</qandaentry>
@@ -675,16 +700,16 @@
<question>
<para>
I want to change some of my node numbers. How do I
- <quote>rename</quote> a node to have a different node number?
+ <quote>rename</quote> a node to have a different node number?
</para>
</question>
<answer>
<para>
You don't. The node number is used to coordinate inter-node
- communications, and changing the node ID number <quote>on the fly</quote>
- would make it essentially impossible to keep node configuration
- coordinated.
+ communications, and changing the node ID number <quote>on the fly</quote>
+ would make it essentially impossible to keep node configuration
+ coordinated.
</para>
</answer>
</qandaentry>
@@ -693,35 +718,35 @@
<question>
<para>
My application uses OID attributes; is it possible to replicate tables
- like this?
+ like this?
</para>
</question>
<answer>
<para>
It is worth noting that oids, as a regular table attribute, have been
- deprecated since &postgres; version 8.1, back in 2005. &slony1; has
- <emphasis>never</emphasis> collected oids to replicate them, and, with
- that functionality being deprecated, the developers do not intend to
- add this functionality.
+ deprecated since &postgres; version 8.1, back in 2005. &slony1; has
+ <emphasis>never</emphasis> collected oids to replicate them, and, with
+ that functionality being deprecated, the developers do not intend to
+ add this functionality.
</para>
<para>
&postgres; implemented oids as a way to link its internal system tables
- together; to use them with application tables is considered
- <emphasis>poor practice</emphasis>, and it is recommended that you use
- sequences to populate your own ID column on application tables.
+ together; to use them with application tables is considered
+ <emphasis>poor practice</emphasis>, and it is recommended that you use
+ sequences to populate your own ID column on application tables.
</para>
</answer>
<answer>
<para>
Of course, nothing prevents you from creating a table
- <emphasis>without</emphasis> oids, and then add in your own application
- column called <envar>oid</envar>, preferably with type information
- <command>SERIAL NOT NULL UNIQUE</command>, which
- <emphasis>can</emphasis> be replicated, and which is likely to be
- suitable as a candidate primary key for the table.
+ <emphasis>without</emphasis> oids, and then add in your own application
+ column called <envar>oid</envar>, preferably with type information
+ <command>SERIAL NOT NULL UNIQUE</command>, which
+ <emphasis>can</emphasis> be replicated, and which is likely to be
+ suitable as a candidate primary key for the table.
</para>
</answer>
</qandaentry>
@@ -734,14 +759,14 @@
<question>
<para>
Je cherche le namespace <envar>_clustername</envar>, mais il est
- introuvable.
+ introuvable.
</para>
</question>
<answer>
<para>
Si les DNS sont erronés, alors l'instance &lslon; ne pourra pas se
- connecter aux nœuds.
+ connecter aux nœuds.
</para>
<para>
@@ -750,9 +775,9 @@
<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.
+ 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>
@@ -762,19 +787,19 @@
<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 :
-
+ 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
- VACUUM et sauvegardes).
+ VACUUM et sauvegardes).
</para>
<para>
Malheureusement, j'ai eu une erreur à chaque fois où je voulais
- souscrire à un nouveau ensemble.
+ souscrire à un nouveau ensemble.
</para>
<programlisting>DEBUG1 copy_set 28661
@@ -788,15 +813,15 @@
<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
- connecte avec le compte <command>postgres</command>.
+ 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é.
+ système <envar>pg_class</envar> est ignoré.
</para>
</answer>
@@ -823,20 +848,20 @@
<question>
<para>
Au moment d'enregistrer un esclave, j'obtiens le message suivant dans
- les journaux applicatifs :
+ les journaux applicatifs :
<screen>DEBUG1 copy_set 1
DEBUG1 remoteWorkerThread_1: connected to provider DB
-WARN remoteWorkerThread_1: transactions earlier than XID 127314958 are still in progress
-WARN remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds</screen>
+WARN remoteWorkerThread_1: transactions earlier than XID 127314958 are still in progress
+WARN remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds</screen>
</para>
</question>
<answer>
<para>
Il y a évidemment un certain nombre de vieilles transactions qui
- empêchent &slony1; de traiter des synchronisations. Vous devriez
- jeter un coup d'œil à pg_locks pour voir ce qu'il en est :
+ 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;
@@ -848,16 +873,16 @@
<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
- <application>RT3</application> qui s'emballe, un
- <application>pg_dump</application>, toutes ces opérations ouvrent des
- transactions pour une période importante. Jusqu'à ce qu'elles soient
- complétées ou bien interrompues, on verra alors le message d'erreur
- suivant :
+ <application>RT3</application> qui s'emballe, un
+ <application>pg_dump</application>, toutes ces opérations ouvrent des
+ transactions pour une période importante. Jusqu'à ce qu'elles soient
+ complétées ou bien interrompues, on verra alors le message d'erreur
+ suivant :
<quote>data copy
for set 1 failed - sleep 60 seconds </quote>
@@ -865,11 +890,11 @@
<para>
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.
+ &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.
</para>
</answer>
</qandaentry>
@@ -885,28 +910,28 @@
<answer>
<para>
Cela ne peut pas fonctionner : &slony1; ne peut employer pas 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>.
+ commande <command>COPY</command> de manière concurrente. Voir la
+ fonction <function>copy_set()</function> dans le fichier
+ <filename>src/slon/remote_worker.c</filename>.
</para>
<screen>$ ps -aef | egrep '[2]605100'
-postgres 2605100 205018 0 18:53:43 pts/3 3:13 postgres: postgres sampledb localhost COPY</screen>
+postgres 2605100 205018 0 18:53:43 pts/3 3:13 postgres: postgres sampledb localhost COPY</screen>
<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
- second tant que le premier n'a pas fini son enregistrement. Cela
- représente une cause possible.
+ 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.
</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
- l'abonnement (en copiant le contenu des table, etc.), on peut s'occuper
- de débuter l'enregistrement du deuxième.
+ esclaves simultanément à partir d'un même fournisseur. Vous devez
+ souscrire un et un seul abonné à la fois. Une fois qu'il a accompli
+ l'abonnement (en copiant le contenu des table, etc.), on peut s'occuper
+ de débuter l'enregistrement du deuxième.
</para>
</answer>
</qandaentry>
@@ -915,70 +940,70 @@
<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.
+ un cluster de réplication slony sur le maître et l'esclave.
</para>
<warning>
<para>
- <emphasis>MAKE SURE YOU STOP YOUR APPLICATION RUNNING AGAINST YOUR
- MASTER DATABASE WHEN REMOVING THE WHOLE SLONY CLUSTER</emphasis>,
- or at least re-cycle all your open connections after the event!
- </para>
+ <emphasis>MAKE SURE YOU STOP YOUR APPLICATION RUNNING AGAINST YOUR
+ MASTER DATABASE WHEN REMOVING THE WHOLE SLONY CLUSTER</emphasis>,
+ or at least re-cycle all your open connections after the event!
+ </para>
</warning>
<para>
- The connections <quote>remember</quote> or refer to OIDs which are
- removed by the uninstall node script. And you will get lots of errors
- as a result...
+ Les connexions <quote>se rappelent</quote> ou font référence aux
+ OID qui sont supprimés par le script de déinstallation du nœud.
+ C'est la cause d'un grand nombre d'erreurs...
</para>
</question>
<answer>
<para>
Il y a deux mécanismes de &postgres; qui mettent en cache les plans
- d'interrogation et les OIDs :
+ d'interrogation et les OIDs :
</para>
<itemizedlist>
<listitem>
- <para>les requêtes préparées (« prepared statements ») ;</para>
- </listitem>
+ <para>les requêtes préparées (« prepared statements ») ;</para>
+ </listitem>
<listitem>
- <para>les fonctions PL/pgsql.</para>
- </listitem>
+ <para>les fonctions PL/pgsql.</para>
+ </listitem>
</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
- provoque des vagues d'erreurs relatives aux OID.
+ 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
- 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.
+ 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.
</para>
</answer>
<answer>
<para>
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.
- 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,
- 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.
+ inattendues dans le contexte. Ainsi, toutes les connexions devraient
+ être renouvelées dès l'apparition d'une erreur inattendue.
+ Naturellement, si l'erreur remonte une violation de contrainte, qui est
+ une condition reconnue, cela va provoquer un renouvellement de connexion.
+ 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.
</para>
</answer>
</qandaentry>
@@ -987,39 +1012,39 @@
<question>
<para>
J'ai migré mon &slony1; en version 1.2. J'ai maintenant cet
- avertissement dans les journaux applicatifs :
+ avertissement dans les journaux applicatifs :
</para>
<screen>NOTICE: Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated</screen>
<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 ?
+ continuent de prendre du volume, et <envar>sl_log_1</envar> n'est
+ jamais vidée. Quel est le souci ?
</para>
</question>
<answer>
<para>
Ceci est un cas symptomatique 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>.
+ 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é.
+ &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>
@@ -1035,53 +1060,53 @@
<answer>
<para>
Nous avons constaté que ceci arrive lorsque on réinitialise un
- nœud dans la configuration suivante :
+ nœud dans la configuration suivante :
<itemizedlist>
<listitem>
- <para>Nœud 1 - fournisseur</para>
- </listitem>
+ <para>Nœud 1 - fournisseur</para>
+ </listitem>
<listitem>
- <para>
- Nœud 2 - abonné au nœud 1 - le nœud que l'on
- réinitialise
- </para>
- </listitem>
+ <para>
+ 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
- </para>
- </listitem>
+ <para>
+ 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
+ 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
- 3.
+ 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
- linkend="stmtsubscribeset"/> que le nœud 2 est en train de
- traiter.
+ <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
- entre les nœuds 1 et 3.
+ é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;
node 1 admin conninfo='host=32.85.68.220 dbname=oxrslive user=postgres port=5432';
@@ -1097,30 +1122,30 @@
<para>
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 :
+ <command>SYNC</command> se propagent à nouveau vers le nœud 3.
+ Ceci souligne deux principes :
<itemizedlist>
<listitem>
- <para>
+ <para>
Si vous avez plusieurs nœuds et des abonnés en cascade,
- vous devez faire attention en repeuplant les entrées <xref
+ 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é.
- </para>
- </listitem>
+ de l'<quote>arbre</quote> de réplication a changé.
+ </para>
+ </listitem>
<listitem>
- <para>
- La version 1.1 fourni des meilleurs outils pour gérer ce cas.
- </para>
+ <para>
+ La version 1.1 fourni des meilleurs outils pour gérer ce cas.
+ </para>
</listitem>
</itemizedlist>
</para>
<para>
Les problèmes relatifs aux <quote>voies d'écoute</quote> sont discutés
- avec plus de précisions dans la section <xref linkend="listenpaths"/>.
+ avec plus de précisions dans la section <xref linkend="listenpaths"/>.
</para>
</answer>
</qandaentry>
@@ -1129,7 +1154,7 @@
<question>
<para>
En redémarrant &lslon;, j'obtiens les messages <quote>FATAL</quote>
- suivants dans les journaux applicatifs. Que se passe-t-il ?
+ suivants dans les journaux applicatifs. Que se passe-t-il ?
</para>
<screen>2006-03-29 16:01:34 UTC CONFIG main: slon version 1.2.0 starting up
@@ -1155,50 +1180,50 @@
<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.
+ 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>
+ 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
- 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;
- va essayer de se reconnecter, encore et encore, et fait que vous
- obtenez le message d'erreur ci-dessous, encore et encore.
+ &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;
+ 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.
+ 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.
+ 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>
@@ -1213,60 +1238,60 @@
<answer>
<para>
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.
+ 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.
</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
- 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.
+ 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.
</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.
+ <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
- 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;.
+ 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;.
</para>
<para>
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
- 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.
+ 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
+ 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.
</para>
</answer>
</qandaentry>
@@ -1275,16 +1300,16 @@
<question>
<para>
Y a-t-il des risques lorsqu'on arrête &lslon; ? Quels sont les
- avantages ?
+ avantages ?
</para>
</question>
<answer>
<para>
En bref, si un <command>COPY_SET</command> qui dure 18h n'est pas en
- cours d'exécution, alors ce n'est pas un grand sacrifice d'arrêter un
- &lslon; pendant quelques instants, ni même de relancer
- <emphasis>tous</emphasis> les &lslon;.
+ 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>
</qandaentry>
@@ -1302,7 +1327,7 @@
<para>
Lorsque j'exécute un simple script de configuration, j'obtiens un
- message similaire à :
+ 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>
@@ -1312,38 +1337,38 @@
<answer>
<para>
É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
- des nœuds</emphasis> et pas seulement sur le nœud d'origine.
+ <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
+ 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
- du noyau &postgres; et celui du noyau de &slony1;. Si vous avez
- manuellement compilé &slony1; par vous-même, sur une machine où il y
- a plusieurs versions de &postgres;, il est possible que les binaires
- slon ou 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.
+ du noyau &postgres; et celui du noyau de &slony1;. Si vous avez
+ manuellement compilé &slony1; par vous-même, sur une machine où il y
+ a plusieurs versions de &postgres;, il est possible que les binaires
+ slon ou 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
- faire remonter ce genre d'erreur. Voir aussi la <link
- linkend="threadsafety">sécurité des threads</link> à propos de la
- gestion des threads sur Solaris.
+ 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
+ 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
- bonne version du noyau de &postgres;.
+ &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>
</qandaentry>
@@ -1352,20 +1377,20 @@
<question>
<para>
J'essaie de créer un cluster dont le nom contient un tiret. Cela ne
- fonctionne pas.
+ fonctionne pas.
</para>
</question>
<answer>
<para>
&slony1; utilise les mêmes règles de nommage que &postgres;, donc vous
- ne devriez pas utiliser un tiret dans les identifiants.
+ 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>
@@ -1378,14 +1403,14 @@
<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>
<answer>
<para>
Conservez le mot de passe en dehors de la configuration Slony, en les
- mettant dans le fichier <filename>$(HOME)/.pgpass.</filename>.
+ mettant dans le fichier <filename>$(HOME)/.pgpass.</filename>.
</para>
</answer>
</qandaentry>
@@ -1405,7 +1430,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>
@@ -1414,20 +1439,20 @@
<question>
<para>
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>.
+ tables &sllog1;/&sllog2; prennent beaucoup de temps alors qu'il n'y a
+ que quelques événements <command>SYNC</command>.
</para>
</question>
<answer>
<para>
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
- 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.
+ seulement un index, et lorsqu'il y avait plusieurs ensembles de
+ 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.
</para>
</answer>
</qandaentry>
@@ -1436,48 +1461,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.
+ 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é.
+ 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é.
</para>
<para>
Dans l'<emphasis>ideal</emphasis> et pour bien faire les choses, il
- aurait fallu utiliser <xref linkend="stmtddlscript"/> pour déployer
- la modification au bon moment sur chaque nœud.
+ 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
- <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
- 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.
+ 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
+ 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.
</para>
</answer>
</qandaentry>
@@ -1486,7 +1511,7 @@
<question>
<para>
J'ai un &postgres; version 7.2 et je souhaite
- <emphasis>vraiment</emphasis> utiliser &slony1; pour le migrer en
+ <emphasis>vraiment</emphasis> utiliser &slony1; pour le migrer en
version 8.0. Que faut-il faire pour que &slony1; fonctionne ?
</para>
</question>
@@ -1502,86 +1527,86 @@
<itemizedlist>
<listitem>
- <para>
- Prendre les templates 7.3 et les copier en 7.2 -- ou bien écrire
- en dur la version de vos templates
- </para>
- </listitem>
-
+ <para>
+ 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.
- </para>
- </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.
+ </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
- fonctions.
- </para>
- </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
+ 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.
- </para>
- </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.
+ </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.
- </para>
- </listitem>
-
+ <para>
+ 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
- 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
- nouvelles versions de &postgres; afin qu'ils puissent dialoguer.
+ 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
+ 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
- qui ont subi des changements manuels.
+ 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.
+ 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
+ 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.
+ durée de vie limitée.
</para>
<para>
Vous devriez seulement adapter cette solution que si vous êtes à l'aise
- avec &postgres; et &slony1; et si mettre la main dans le code ne vous
- fait pas peur.
+ avec &postgres; et &slony1; et si mettre la main dans le code ne vous
+ fait pas peur.
</para>
</answer>
</qandaentry>
@@ -1591,31 +1616,31 @@
<para>
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 ?
+ 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.
+ 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ées,
- qui n'est jamais causée par une erreur disque dite
- <quote>physique</quote>.
+ 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>
@@ -1623,8 +1648,8 @@
<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.
+ recourt</emphasis> car cela implique d'abandonner le nœud
+ d'origine pour cette corruption.
</para>
</answer>
</qandaentry>
@@ -1633,8 +1658,8 @@
<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 :
+ 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"
@@ -1642,7 +1667,7 @@
<para>
Par la suite, l'erreur est suivie par un ensemble de SYNC en échec
- tandis que <xref linkend="slon"/> s'arrête :
+ tandis que <xref linkend="slon"/> s'arrête :
</para>
<screen>DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
@@ -1661,24 +1686,24 @@
<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.
+ 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 la commande <xref
- linkend="stmtsubscribeset"/>.
+ 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.
+ vous devez vous assurer que tout fonctionne correctement
+ <emphasis>avant</emphasis> de poursuivre les changements de configuration.
</para>
</answer>
</qandaentry>
@@ -1687,26 +1712,26 @@
<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 ?
+ 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>
<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.
+ 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>
<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.
+ 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>
@@ -1725,7 +1750,7 @@
<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 :
+ démon <xref linkend="slon"/> s'arrête :
<screen>DEBUG2 remoteListenThread_1: queue event 1,4897517 SYNC
DEBUG2 remoteListenThread_1: queue event 1,4897518 SYNC
@@ -1744,25 +1769,25 @@
<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.
+ 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 la commande <xref linkend="stmtsubscribeset"/> ne soit
- propagée.
+ 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 sûr que tout fonctionne bien
- <emphasis>avant</emphasis> de faire de nouveaux changements de
- configuration.
+ choses ; vous devez être sûr que tout fonctionne bien
+ <emphasis>avant</emphasis> de faire de nouveaux changements de
+ configuration.
</para>
</answer>
</qandaentry>
@@ -1779,33 +1804,33 @@
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.
+ 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,
+ 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>.
+ (« 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.
+ 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>
@@ -1814,12 +1839,12 @@
<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.
+ 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>
<programlisting>try {
@@ -1842,7 +1867,7 @@
<answer>
<para>
Vous ne devez pas invoquer <xref linkend="stmtwaitevent"/> à l'intérieur
- d'un bloc <quote>try</quote>.
+ d'un bloc <quote>try</quote>.
</para>
</answer>
</qandaentry>
@@ -1862,14 +1887,14 @@
<answer>
<para>
Vous ne pouvez pas rajouter des tables à un ensemble pour lequel il y a
- des abonnées.
+ 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.
+ 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>
@@ -1880,7 +1905,7 @@
<para>
En essayant de monter un deuxième ensemble de réplication, j'ai ce
- message :
+ message :
<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"
@@ -1891,12 +1916,12 @@
<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.
+ 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>
@@ -1905,22 +1930,23 @@
<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 ?
+ 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>
<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,
+ (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>
@@ -1928,105 +1954,143 @@
<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.
+ 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>
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.
+ 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 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.
+ 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>
-<qandaentry>
+ <qandaentry>
+ <question>
+ <para>
+ À partir de la version 8.3, &postgres; propose le paramètre
+ <envar>synchronous_commit</envar> qui peut être configuré dans la
+ session et dans le fichier <filename>postgresql.conf</filename>. Elle
+ permet de gagner en performance en diluant les écritures dans les journaux
+ de transactions. Serait-il intéressant de désactiver ce paramètre sur
+ un nœud abonné ?
+ </para>
+ </question>
-<question> <para>As of version 8.3, &postgres; offers a
-<envar>synchronous_commit</envar> parameter which may be set either
-via GUC or <filename>postgresql.conf</filename> which can provide some
-performance gains by not logging results in WAL. Would it be sensible
-to turn off synchronous commit on a subscriber node? </para>
-</question>
+ <answer>
+ <para>
+ Malheureusement, le risque introduit est assez désagréable.
+ </para>
-<answer><para> Unfortunately, there is an unpleasant failure case
-which this would introduce. </para>
+ <para>En voici un exemple...</para>
-<para>Consider...</para>
+ <itemizedlist>
-<itemizedlist>
+ <listitem>
+ <para>
+ Le nœud 2 indique avoir enregistré jusqu'à la transaction
+ T5, mais les journaux de transactions ont les enregistrements
+ jusqu'à T3.
+ </para>
+ </listitem>
-<listitem><para> Node #2 claims to have committed up to transaction
-T5, but the WAL only really has records up to T3.</para></listitem>
+ <listitem>
+ <para>
+ Le nœud 1, le maître, récupère l'information comme quoi le
+ nœud 2 est à jour jusqu'à la transaction T5.
+ </para>
+ </listitem>
-<listitem><para> Node #1, the "master", got the report back that #2 is
-up to date to T5.</para></listitem>
+ <listitem>
+ <para>
+ Le nœud 2 a une coupure de courant (ou tout autre problème
+ grave).
+ </para>
+ </listitem>
+ </itemizedlist>
-<listitem><para> Node #2 experiences a failure (e.g. - power
-outage).</para></listitem>
+ <para>
+ Deux possibilités, une correcte, une très mauvaise....
+ </para>
-</itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>OK</para>
-<para>There are two possible outcomes, now, one OK, and one not so OK...</para>
+ <para>
+ Le n&orlig;ud 2 est relancé, et rejoue les journaux de transactions.
+ Il sait qu'il n'a les données que jusqu'à T3 et retourne auprès du
+ nœud 1 pour demander les transactions T4 et suivantes.
+ </para>
-<itemizedlist>
+ <para>Aucun problème.</para>
+ </listitem>
-<listitem><para> OK </para>
+ <listitem>
+ <para>Pas si bien.</para>
-<para> Node #2 gets restarted, replays WAL, knows it's only got data
-up to T3, and heads back to node #1, asking for transaction T4 and
-others.</para>
+ <para>
+ Avant que le nœud 2 ne revienne, le nœud 1 lance
+ une itération de processus de nettoyage, qui essaie de supprimer
+ les données jusqu'à T5 car les autres nœuds ont confirmé
+ avoir reçu jusqu'à ce point.
+ </para>
-<para> No problem.</para></listitem>
+ <para>
+ Le n&orlig;ud 2 est relancé, et rejoue les journaux de transactions.
+ Il sait qu'il n'a les données que jusqu'à T3 et retourne auprès du
+ nœud 1 pour demander les transactions T4 et suivantes.
+ </para>
-<listitem><para> Not so OK.</para>
+ <para>
+ Oups. Le nœud 1 a justement supprimé ces entrées.
+ </para>
+ </listitem>
+ </itemizedlist>
-<para> Before node #2 gets back up, node #1 has run an iteration of
-the cleanup thread, which trims out all the data up to T5, because the
-other nodes confirmed up to that point.</para>
+ <para>
+ Ce cas est assez facile à tester, vous devez simplement empêcher le
+ redémarrage du nœud pendant suffisament longtemps pour que le
+ nœud 1 ait le temps de lancer le processus de nettoyage.
+ </para>
-<para> Node #2 gets restarted, replays WAL, knows it's only got data
-up to T3, and heads back to node #1, asking for transaction T4 and
-T5.</para>
+ <para>
+ Vous pouvez éviter le problème en configurant le paramètre
+ <xref linkend="slon-config-cleanup-interval"/> avec une valeur très
+ grande.
+ </para>
-<para> Oops. Node #1 just trimmed those log entries
-out.</para></listitem>
-</itemizedlist>
+ <para>
+ Malheureusement, chaque fois que le nœud 2 est indisponible
+ pendant plus de temps que cet interval, vous risquez inexorablement
+ de perdre des données.
+ </para>
+ </answer>
-<para>The race condition here is quite easy to exercise - you just
-need to suppress the restart of node 2 for a while, long enough for
-node 1 to run the cleanup thread.</para>
-
-<para>You might evade the problem somewhat by setting the &lslon; parameter
-<xref linkend="slon-config-cleanup-interval"/> to a larger value.</para>
-
-<para>Unfortunately, any time the outage of node 2 could exceed that
-interval, the risk of losing log data inexorably emerges.</para>
-
-</answer>
-
-<answer><para> As a result, it cannot be recommended that users run
-&slony1; in a fashion where it suppresses WAL writing via
-<envar>synchronous_commit</envar>. </para> </answer>
-
-</qandaentry>
-
+ <answer>
+ <para>
+ Du coup, il n'est pas recommandé que les utilisateurs exécutent
+ &slony1; avec <envar>synchronous_commit</envar> activé.
+ </para>
+ </answer>
+ </qandaentry>
</qandadiv>
<qandadiv id="faqperformance">
@@ -2036,46 +2100,46 @@
<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.
+ LOG</command> très longues, la table &sllog1;/&sllog2; grossit et les
+ performances se dégradent de manière continue.
</para>
</question>
<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>.
+ 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>
<para>
Par rapprochement, <quote>on peut avancer</quote> que cette augmentation
- de volume est due à une session existante sur le serveur qui est en
+ 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.
+ chacun entrainant une dégradation de performances.
</para>
<itemizedlist>
<listitem>
- <para>
- Le fait de lancer un VACUUM sur la totalité des tables, &pglistener;
- y compris, ne va pas nettoyer les lignes mortes après après le début
- de la transaction en attente.
- </para>
- </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>
<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>
+ <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>
@@ -2083,48 +2147,48 @@
<answer>
<para>
Vous pouvez surveiller cette situation uniquement si, dans le fichier
- de configuration de &postgres; <filename> postgresql.conf</filename>,
+ 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.
+ '%IDLE% in transaction';</command> dont le résultat vous donne les
+ transactions en activités.
</para>
</answer>
<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.
+ dans la table des processus pour trouver ceux qui détiennent encore des
+ transactions anciennes.
</para>
</answer>
<answer>
<para>
Il est aussi possible (quoique plus rare) que le problème soit causé
- par une transaction qui, pour d'autres raisons, est conservée comme
- ouverte et ceci pour une longue durée. La 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.
+ 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>
<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.
+ <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>
@@ -2133,31 +2197,31 @@
<question>
<para>
Après une suppression de nœud, les tables &sllog1;/&sllog2; ne
- sont plus purgées.
+ 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.
+ 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 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.
+ 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>
<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"/>:
+ la table <xref linkend="table.sl-confirm"/>:
<screen>oxrsbar=# SELECT * FROM _oxrsbar.sl_confirm
oxrsbar-# WHERE con_origin NOT IN (SELECT no_id FROM _oxrsbar.sl_node)
@@ -2175,10 +2239,10 @@
<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 :
+ 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>
@@ -2195,38 +2259,38 @@
<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.
+ <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...
+ qui reste...
</para>
<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 :
+ il purge les entrées inutiles de <xref linkend="table.sl-confirm"/> à
+ deux instants :
<itemizedlist>
<listitem>
- <para>
- lorsqu'un nœud est supprimé ;
- </para>
- </listitem>
+ <para>
+ lorsqu'un nœud est supprimé ;
+ </para>
+ </listitem>
<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>
+ 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>
@@ -2235,43 +2299,43 @@
<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.
+ 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.
+ 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>
<note>
<para>
- À partir de la version 1.0.2, la fonction
- <function>generate_sync_event()</function> fournit une alternative à
- la sauvegarde...
- </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;.
+ 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.
+ <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.
+ <xref linkend="slon"/> ne tourne pas en tâche de fond.
</para>
</answer>
</qandaentry>
@@ -2284,12 +2348,12 @@
<para>
J'avais lancé, depuis un moment, &slony1; sur un nœud, et je vois
- que la machine est à genoux.
+ que la machine est à genoux.
</para>
<para>
Je vois des instructions en cours comme :
-
+
<screen>FETCH 100 FROM LOG;</screen>
</para>
</question>
@@ -2297,39 +2361,39 @@
<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é.
+ 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>
<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.
+ 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...
+ 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>
<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.
+ <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>
@@ -2338,31 +2402,31 @@
<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.
+ linkend="stmtddlscript"/>, et elle semble être coincée sur mon serveur.
+ Les journaux de &slony1; ne montrent aucun avertissement et aucune
+ erreur.
</para>
</question>
<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>.
+ 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>
Vous pourriez vérifier la présence de ce genre de verrous à l'aide de
- cette requête :
-
+ 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 attente et marquées comme non-validées.
+ 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>
@@ -2371,20 +2435,20 @@
<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>.
+ 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.
+ 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>
@@ -2397,26 +2461,26 @@
<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.
+ 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>
<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é ?
+ 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>
<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
+ 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;.
+ 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>
<para>
@@ -2425,71 +2489,71 @@
<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 :
+ <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
-#define SLON_COMMANDS_PER_LINE 1
-#define SLON_DATA_FETCH_SIZE 100
-#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 4)
+ <programlisting>#ifdef SLON_CHECK_CMDTUPLES
+#define SLON_COMMANDS_PER_LINE 1
+#define SLON_DATA_FETCH_SIZE 100
+#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 4)
#else
-#define SLON_COMMANDS_PER_LINE 10
-#define SLON_DATA_FETCH_SIZE 10
-#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 50)
+#define SLON_COMMANDS_PER_LINE 10
+#define SLON_DATA_FETCH_SIZE 10
+#define SLON_WORKLINES_PER_HELPER (SLON_DATA_FETCH_SIZE * 50)
#endif</programlisting>
<para>
Si vous rencontrez ce problème, vous devriez définir
- <envar>SLON_DATA_FETCH_SIZE</envar>, peut-être 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
+ <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.
+ 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"/> est associée avec un nouvel
- algorithme qui change la logique des choses. Plutôt que de restituer
- cent enregistrements à la fois :
+ 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
+ <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>
+ défaut, ceci limitera ce phénomène de consommation de mémoire à un
+ plafond de 8 Mo.
+ </para>
</listitem>
<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>
+ <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>
<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.
+ ils ont chargés sporadiquement des séries de lignes très volumineuses.
</para>
</answer>
</qandaentry>
@@ -2498,8 +2562,8 @@
<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.
+ depuis la version 8.0 de &postgres; à la version 8.1, et je rencontre
+ des problèmes.
</para>
</question>
@@ -2511,53 +2575,53 @@
<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.
+ vieille version vers la version 8.1 et que vous avez des valeurs UTF-8
+ invalides, vous aurez une surprise déplaisante.
</para>
<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.
+ 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>
<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...)
+ 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>
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.
+ faire. Pour le moment, une stratégie attractive ne se dégage pas sur le
+ sujet.
</para>
<para>
Si vous utilisez Unicode avec la version 8.0 de &postgres;, vous courrez
- un risque considérable de corrompre vos données.
+ un risque considérable de corrompre vos données.
</para>
<para>
Si votre réplication a pour but de convertir une fois pour toutes vos
- données, il y a le risque évoqué 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.
+ 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>
Au regard des risques encourus, exécuter la réplication en mettant en
- jeu des versions différentes semble être non pérenne à maintenir.
+ jeu des versions différentes semble être non pérenne à maintenir.
</para>
<para>
Pour plus d'information, voir la <ulink
- url="http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
+ url="http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
discussion sur le groupe de discussion postgresql-hackers</ulink>.
</para>
</answer>
@@ -2567,12 +2631,12 @@
<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
+ 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>
@@ -2580,21 +2644,21 @@
<answer>
<para>
Apparemment, le code de la fonction
- <function>RebuildListenEntries()</function> ne suffit pas pour résoudre
- ce cas.
+ <function>RebuildListenEntries()</function> ne suffit pas pour résoudre
+ ce cas.
</para>
<para>
La fonction <function>RebuildListenEntries()</function> sera rectifié
- dans &slony1; version 1.2 avec un algorithme couvrant ce cas.
+ 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é).
+ <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>
@@ -2603,19 +2667,19 @@
<question>
<para>
Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont
- tronqués un peu, il leur manque les derniers caractères. Pourquoi ?
+ tronqués un peu, il leur manque les derniers caractères. Pourquoi ?
</para>
</question>
<answer>
<para>
C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ;
- 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.
+ 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>
@@ -2624,31 +2688,31 @@
<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.
+ 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>
<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>.
+ de séquences n'est pas une <link linkend="bestpractices">bonne
+ pratique</link>.
</para>
</answer>
<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.
+ 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>
<para>
@@ -2667,59 +2731,59 @@
<answer>
<para>
Ceci peut être accompli de plusieurs manières, pas toutes également
- souhaitables ;-).
+ 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>
+ <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>
+ <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>
<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>.
+ <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>
+ 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>
<programlisting>SELECT _slonyschema.alterTableRestore(40);
SELECT _slonyschema.tableDropKey(40);
DELETE FROM _slonyschema.sl_table where tab_id = 40;</programlisting></para>
<para>
- Évidement, le nom du schéma dépend de la façon dont vous avez
- défini le cluster &slony1;. L'identifiant de la table, dans cet
- exemple 40, doit être remplacé par celui de la table dont voulez
- vous débarrasser.
- </para>
+ É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 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>
+ 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>
@@ -2728,29 +2792,29 @@
<question>
<para>
Je dois supprimer une séquence dans une séquence pour un ensemble de
- réplication.
+ réplication.
</para>
</question>
<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"/>.
+ <xref linkend="stmtsetdropsequence"/> dans Slonik vous permettant de
+ le faire en parallèle <xref linkend="stmtsetdroptable"/>.
</para>
<para>
Si vous êtes en version 1.0.2 ou antérieure, l'opération sera un peu
- plus manuelle.
+ 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> :
+ <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);
- seq_id | seq_reloid | seq_set | seq_comment
+ 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_
@@ -2759,7 +2823,7 @@
<para>
Les données à supprimer pour empêcher Slony de continuer la réplication
- sont :
+ 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>
@@ -2767,16 +2831,16 @@
<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.
+ 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 implémentée dans &slony1; version 1.0.5 sous le nom
- <xref linkend="stmtsetdropsequence"/>.
+ fonction est implémentée dans &slony1; version 1.0.5 sous le nom
+ <xref linkend="stmtsetdropsequence"/>.
</para>
</answer>
</qandaentry>
@@ -2785,9 +2849,9 @@
<question>
<para>
J'ai configuré mon cluster avec pgAdminIII, avec le nom
- <quote>MON-CLUSTER</quote>. Le temps a passé et j'ai tenté d'utiliser Slonik
- pour effectuer un changement de configuration, et j'obtiens le messages d'erreur
- suivant :
+ <quote>MON-CLUSTER</quote>. Le temps a passé et j'ai tenté d'utiliser Slonik
+ pour effectuer un changement de configuration, et j'obtiens le messages d'erreur
+ suivant :
</para>
<programlisting>ERROR: syntax error at or near -</programlisting>
@@ -2796,10 +2860,10 @@
<answer>
<para>
Le problème est que &slony1; s'attend à ce que les noms de cluster soient des
- <ulink url="http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html">
+ <ulink url="http://www.postgresql.org/docs/8.3/static/sql-syntax-lexical.html">
Identifiants SQL </ulink> valides, et &lslonik; garantit cela. Malheureusement,
- <application>pgAdminIII</application> ne vérifie pas cela et autorise
- des noms de cluster qui provoquent des <emphasis> problèmes</emphasis>.
+ <application>pgAdminIII</application> ne vérifie pas cela et autorise
+ des noms de cluster qui provoquent des <emphasis> problèmes</emphasis>.
</para>
</answer>
@@ -2812,22 +2876,22 @@
Il <emphasis>peut-être possible</emphasis> que l'execution de la commande
SQL <command>alter namespace "_My-Bad-Clustername" rename to
"_BetterClusterName";</command> sur chacune des bases fonctionne.
- Cela ne devrait pas particulièrement <emphasis>aggraver</emphasis>les choses !
+ Cela ne devrait pas particulièrement <emphasis>aggraver</emphasis>les choses !
</para>
<para>
D'un autre coté, à chaque fois que ce problème a été rencontré, il a fallu
- détruire la réplication et reconstruire le cluster.
+ détruire la réplication et reconstruire le cluster.
</para>
</answer>
<answer>
<para>
Dans la version 2.0.2, une fonction a été ajoutée pour vérifier la
- la validité du nom du cluster. Si vous tentez de définir un nom invalide,
- la chargement de la fonction échouera, avec un message d'erreur approprié, ce qui
- devrait empecher les choses d'empirer, meme si vous utiliser d'autres outils que
- &lslonik; pour gérer la configuration du cluster.
+ la validité du nom du cluster. Si vous tentez de définir un nom invalide,
+ la chargement de la fonction échouera, avec un message d'erreur approprié, ce qui
+ devrait empecher les choses d'empirer, meme si vous utiliser d'autres outils que
+ &lslonik; pour gérer la configuration du cluster.
</para>
</answer>
</qandaentry>
@@ -2843,27 +2907,27 @@
<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.
+ <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 indiquent qu'<blockquote><para>un autre slon en
- tâche de fond gère déjà ce nœud.</para></blockquote>.
+ 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;.
+ &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>
@@ -2872,7 +2936,7 @@
<para>
Il est utile de maintenir un script manuel pour ce genre de
- situation :
+ situation :
<programlisting>twcsds004[/opt/twcsds004/OXRS/slony-scripts]$ cat restart_org.slonik
cluster name = oxrsorg ;
@@ -2888,7 +2952,7 @@
<para>
<xref linkend="stmtrestartnode"/> nettoie les notifications mortes pour
- qu'on puisse ensuite redémarrer le nœud.
+ qu'on puisse ensuite redémarrer le nœud.
</para>
<para>
@@ -2899,9 +2963,9 @@
<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.
+ &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>
@@ -2921,7 +2985,7 @@
<para>
Il semble que les fonctions <function>xxid</function> de &slony1;
- prétendent pouvoir faire du hachage, mais qu'elles n'y arrivent pas.
+ prétendent pouvoir faire du hachage, mais qu'elles n'y arrivent pas.
</para>
<para>
@@ -2932,29 +2996,29 @@
<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.
+ 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>
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.
+ 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>
<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.
+ <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>
@@ -2968,8 +3032,8 @@
<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 :
+ constatez que vos propres scripts ne fonctionnent pas bien, vous pouvez
+ suivre la démarche suivante :
</para>
<programlisting>/* cbbrowne@[local]/dba2 slony_test1=*/ \x
@@ -3005,40 +3069,40 @@
<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 ?
+ 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 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.
+ 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
- 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.
+ 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 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>.
+ <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>
@@ -3046,9 +3110,9 @@
<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.
+ 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>
@@ -3061,8 +3125,8 @@
<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 :
+ 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
DEBUG2 remoteWorkerThread_1: syncing set 1 with 41 table(s) from provider 1
@@ -3070,16 +3134,16 @@
DEBUG2 remoteWorkerThread_1: syncing set 3 with 1 table(s) from provider 1
DEBUG2 remoteHelperThread_1_1: 0.135 seconds delay for first row
DEBUG2 remoteHelperThread_1_1: 0.343 seconds until close cursor
-ERROR remoteWorkerThread_1: "insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090538', 'D', '_rserv_ts=''9275244''');
-delete from only public.epp_domain_host where _rserv_ts='9275244';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090539', 'D', '_rserv_ts=''9275245''');
-delete from only public.epp_domain_host where _rserv_ts='9275245';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090540', 'D', '_rserv_ts=''24240590''');
-delete from only public.epp_domain_contact where _rserv_ts='24240590';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090541', 'D', '_rserv_ts=''24240591''');
-delete from only public.epp_domain_contact where _rserv_ts='24240591';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090542', 'D', '_rserv_ts=''24240589''');
-delete from only public.epp_domain_contact where _rserv_ts='24240589';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090543', 'D', '_rserv_ts=''36968002''');
-delete from only public.epp_domain_status where _rserv_ts='36968002';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090544', 'D', '_rserv_ts=''36968003''');
-delete from only public.epp_domain_status where _rserv_ts='36968003';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090549', 'I', '(contact_id,status,reason,_rserv_ts) values (''6972897'',''64'','''',''31044208'')');
-insert into public.contact_status (contact_id,status,reason,_rserv_ts) values ('6972897','64','','31044208');insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090550', 'D', '_rserv_ts=''18139332''');
-delete from only public.contact_status where _rserv_ts='18139332';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090551', 'D', '_rserv_ts=''18139333''');
+ERROR remoteWorkerThread_1: "insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090538', 'D', '_rserv_ts=''9275244''');
+delete from only public.epp_domain_host where _rserv_ts='9275244';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '34', '35090539', 'D', '_rserv_ts=''9275245''');
+delete from only public.epp_domain_host where _rserv_ts='9275245';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090540', 'D', '_rserv_ts=''24240590''');
+delete from only public.epp_domain_contact where _rserv_ts='24240590';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090541', 'D', '_rserv_ts=''24240591''');
+delete from only public.epp_domain_contact where _rserv_ts='24240591';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '26', '35090542', 'D', '_rserv_ts=''24240589''');
+delete from only public.epp_domain_contact where _rserv_ts='24240589';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090543', 'D', '_rserv_ts=''36968002''');
+delete from only public.epp_domain_status where _rserv_ts='36968002';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '11', '35090544', 'D', '_rserv_ts=''36968003''');
+delete from only public.epp_domain_status where _rserv_ts='36968003';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090549', 'I', '(contact_id,status,reason,_rserv_ts) values (''6972897'',''64'','''',''31044208'')');
+insert into public.contact_status (contact_id,status,reason,_rserv_ts) values ('6972897','64','','31044208');insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090550', 'D', '_rserv_ts=''18139332''');
+delete from only public.contact_status where _rserv_ts='18139332';insert into "_oxrsapp".sl_log_1 (log_origin, log_xid, log_tableid, log_actionseq, log_cmdtype, log_cmddata) values ('1', '919151224', '24', '35090551', 'D', '_rserv_ts=''18139333''');
delete from only public.contact_status where _rserv_ts='18139333';" ERROR: duplicate key violates unique constraint "contact_status_pkey"
- qualification was:
ERROR remoteWorkerThread_1: SYNC aborted</screen>
@@ -3087,74 +3151,74 @@
<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.
+ 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.
+ 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. À 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.
+ 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, 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.
+ 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
- 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.
+ 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 :
+ <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>
<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.
+ 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; 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.
+ 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>
@@ -3163,31 +3227,31 @@
<question>
<para>
J'ai commencé à faire une sauvegarde via
- <application>pg_dump</application>, et Slony s'arrête soudainement.
+ <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>
<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>
+ <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>
+ 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>
@@ -3198,15 +3262,15 @@
<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>)
+ l'affichage des requête est activé dans
+ <filename>postgresql.conf</filename>)
</para>
<para>
La requête qui demande ce verrou vient de la fonction
- <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
+ <function>Slony_I_ClusterStatus()</function>, que vous trouverez dans
<filename>slony1_funcs.c</filename>, localisé dans un bloc de code qui
- est :
+ est :
<programlisting>LOCK TABLE %s.sl_event;
INSERT INTO %s.sl_event (...stuff...)
@@ -3215,43 +3279,43 @@
<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.
+ 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>
<para>
Chaque lecture touchant <xref linkend="table.sl-event"/> sera bloqué
- derrière les appels à <function>createEvent</function>.
+ derrière les appels à <function>createEvent</function>.
</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>
+ 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>
<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>
+ 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>
<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>
+ <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>
@@ -3265,86 +3329,86 @@
<question>
<para>
Que se produit-il avec les règles et les déclencheurs pour les tables
- répliquées par &slony1; ?
+ répliquées par &slony1; ?
</para>
</question>
<answer>
<para>
Tout d'abord, regardons comment ceci est géré <emphasis>en
- dehors</emphasis> du cas spécifique de la commande Slonik <xref
+ dehors</emphasis> du cas spécifique de la commande Slonik <xref
linkend="stmtstoretrigger"/>.
</para>
<para>
La fonction <xref linkend="function.altertableforreplication-integer"/>
- prépare chacune des tables pour la réplication.
+ prépare chacune des tables pour la réplication.
</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>
+ 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;.
+ Le déclencheur a pour action d'enregistrer toutes les mises à jours
+ dans la table &sllog1; de &slony1;.
</para>
- </listitem>
+ </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>
+ <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>
+ 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.
+ 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>
<answer>
<para>
Maintenant, observez comment <xref linkend="stmtstoretrigger"/> entre
- en jeu.
+ en jeu.
</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é.
+ 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>
<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 :
+ 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
@@ -3358,8 +3422,8 @@
<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 :
+ 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
@@ -3370,53 +3434,53 @@
<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é.
+ 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é.
+ <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.
+ 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 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 ?
+ 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.
+ 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"/>.
+ 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>
@@ -3425,9 +3489,9 @@
<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)
+ 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
@@ -3437,29 +3501,29 @@
<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"/>.
+ TABLE</command> directement sur la base au lieu de l'utilisation de 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;.
+ 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>
+ <para>
+ À 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>
+ <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;
LOCK TABLE table_name;
@@ -3468,17 +3532,17 @@
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>
+ 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>
+ Voici un exemple :
+ </para>
<screen>BEGIN;
@@ -3518,8 +3582,8 @@
<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 :
+ 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
@@ -3537,34 +3601,34 @@
<para>
Il semble évident qu'un appel à <xref linkend="stmtstorelisten"/>
- n'avait pas encore été propagé avant que le nœud 1 soit éliminé.
+ 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 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>
+ <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.
+ 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.
+ 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 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> :
+ 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>
@@ -3573,7 +3637,7 @@
<para>
La requête peut ramener plusieurs lignes, mais ne supprimez que la
- partie nécessaire.
+ partie nécessaire.
</para>
<screen> -# begin; -- Don't straight delete them; open a transaction so you can respond to OOPS
@@ -3587,11 +3651,11 @@
<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.
+ 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...)
+ enregistré qui fait référence à une configuration qui n'existe plus...)
</para>
</answer>
</qandaentry>
@@ -3612,21 +3676,21 @@
<answer>
<para>
&slony1; utilise des séquences pour attribuer les valeurs des clefs primaires
- des lignes de logs, On pouvait donc s'attendre à ce genre de comportement.
+ des lignes de logs, On pouvait donc s'attendre à ce genre de comportement.
</para>
<para>
Appeler <function>lastval()</function>, pour obtenir <quote>anonymement</quote>
- <quote>la valeur de séquence la plus récemment modifiée</quote>, plutot que
- d'utiliser la <function>currval('sequence_name')</function> est une pratique
- risquée en général, car tout autre application qui utiliser le SGBD pour tracer l'arctivité, archiver ou répliquer peut déclencher une mise à jour de séquence
- au moment ou vous vous y attendez le moins.
+ <quote>la valeur de séquence la plus récemment modifiée</quote>, plutot que
+ d'utiliser la <function>currval('sequence_name')</function> est une pratique
+ risquée en général, car tout autre application qui utiliser le SGBD pour tracer l'arctivité, archiver ou répliquer peut déclencher une mise à jour de séquence
+ au moment ou vous vous y attendez le moins.
</para>
<para>
De manière générale, l'utilisation de <function>lastval()</function> n'est pas
- très sécurisante, l'utiliser lorsque &slony1; ( ou un système similaire de réplication basé sur les triggers comme <application>Londiste</application> ou
- <application>Bucardo</application>) peut vous conduite à des mises à jour de séquence inoppinées.
+ très sécurisante, l'utiliser lorsque &slony1; ( ou un système similaire de réplication basé sur les triggers comme <application>Londiste</application> ou
+ <application>Bucardo</application>) peut vous conduire à des mises à jour de séquence inopinées.
</para>
</answer>
</qandaentry>
Plus d'informations sur la liste de diffusion Trad