[Trad] [svn:pgfr] r1222 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 19 Jan 22:21:45 CET 2009
Author: gleu
Date: 2009-01-19 22:21:45 +0100 (Mon, 19 Jan 2009)
New Revision: 1222
Modified:
traduc/trunk/slony/defineset.xml
traduc/trunk/slony/listenpaths.xml
traduc/trunk/slony/monitoring.xml
traduc/trunk/slony/slonyupgrade.xml
traduc/trunk/slony/testbed.xml
traduc/trunk/slony/triggers.xml
traduc/trunk/slony/usingslonik.xml
Log:
Relecture, ?\195?\169tape 3.
Modified: traduc/trunk/slony/defineset.xml
===================================================================
--- traduc/trunk/slony/defineset.xml 2009-01-19 21:20:59 UTC (rev 1221)
+++ traduc/trunk/slony/defineset.xml 2009-01-19 21:21:45 UTC (rev 1222)
@@ -6,51 +6,72 @@
<sect1 id="definingsets">
<title>Définir les ensembles de réplication</title>
-
<indexterm><primary>définir les ensembles de réplication</primary></indexterm>
-<para>En définissant les noeuds on a conçu l'architecture du cluster
- de réplication; il est temps de déterminer quelles données doivent être
- copiées entre les noeuds. Les groupes de données qui sont copiés
- sont nommés <quote>ensembles de réplication</quote>.</para>
+<para>
+ En définissant les nœuds, on a conçu l'architecture du cluster de
+ réplication ; il est temps de déterminer quelles données doivent être
+ copiées entre les nœuds. Les groupes de données qui sont copiés sont
+ nommés <quote>ensembles de réplication</quote>.
+</para>
-<para>Un ensemble de réplication comprend :</para>
+<para>
+ Un ensemble de réplication comprend :
+</para>
+
<itemizedlist>
-<listitem><para>Les clefs des tables à répliquer qui n'ont pas de clef primaire possible ;</para></listitem>
+ <listitem>
+ <para>
+ Les clefs des tables à répliquer qui n'ont pas de clef primaire
+ possible ;
+ </para>
+ </listitem>
-<listitem><para>Les tables qui doivent être répliquées;</para></listitem>
+ <listitem>
+ <para>
+ Les tables qui doivent être répliquées ;
+ </para>
+ </listitem>
-<listitem><para>Les séquences qui doivent être répliquées.</para></listitem>
+ <listitem>
+ <para>
+ Les séquences qui doivent être répliquées.
+ </para>
+ </listitem>
</itemizedlist>
<sect2><title>Les clefs primaires</title>
-
<indexterm><primary>importance des clefs primaires</primary></indexterm>
-<para>&slony1; <emphasis>a besoin</emphasis> d'une clef primaire ou
- d'un ensemble de champ éligible au statut de clef primaire pour chacune
- des tables qui seront répliquées.
- Les valeurs de clefs primaires ( "PK" ) sont utilisées comme identifiant
- primaire pour chaque tuple qui est modifié sur le système source.
- Notons que les clefs primaires peuvent être des clefs composées de plusieurs
- colonnes NOT NULL; elles ne doivent pas obligatoirement être constituées
- de champs uniques.
- Il y a 3 façons de précise à &slony1; quelle clef primaire utiliser :</para>
+<para>
+ &slony1; <emphasis>a besoin</emphasis> d'une clef primaire ou d'un ensemble
+ de champ éligible au statut de clef primaire pour chacune des tables qui
+ seront répliquées. Les valeurs de clefs primaires (acronyme « PK »)
+ sont utilisées comme identifiant primaire pour chaque ligne qui est modifiée
+ sur le système source. Notons que les clefs primaires peuvent être des clefs
+ composées de plusieurs colonnes NOT NULL ; elles ne doivent pas
+ obligatoirement être constituées de champs uniques. Il y a trois façons de
+ préciser à &slony1; quelle clef primaire utiliser :
+</para>
<itemizedlist>
-<listitem><para> Si la table a déjà une clef primaire identifiée,
- <xref linkend="stmtsetaddtable"/> peut être utilisé sans qu'il
- soit nécessaire de préciser la clef primaire. &slony1; peut
- automatiquement comprendre qu'il existe une clef primaire et
- l'utiliser.</para></listitem>
+ <listitem>
+ <para>
+ Si la table a déjà une clef primaire identifiée, <xref
+ linkend="stmtsetaddtable"/> peut être utilisé sans qu'il soit nécessaire
+ de préciser la clef primaire. &slony1; peut automatiquement comprendre
+ qu'il existe une clef primaire et l'utiliser.
+ </para>
+ </listitem>
-<listitem><para> Si la table ne dispose pas d'une clef primaire,
- mais a une clef primaire <emphasis>candidate</emphasis>,
- c'est à dire, un index sur une combinaison de champs qui
- sont à la fois UNIQUE et NOT NULL ,
- alors vous pouvez spécifier cette clef, comme ceci :
+ <listitem>
+ <para>
+ Si la table ne dispose pas d'une clef primaire mais a une clef primaire
+ <emphasis>candidate</emphasis>, c'est-à-dire un index sur une combinaison
+ de champs qui sont à la fois UNIQUE et NOT NULL, alors vous pouvez
+ spécifier cette clef comme ceci :
</para>
<programlisting>
@@ -60,181 +81,234 @@
comment='ma_table_idx est une clef primaire candidate de ma_table');
</programlisting>
-<para> Cependant, une fois arrivé à cette étape, pourquoi ne pas déclarer
- l'index comme une clef primaire, ce qui nécessite que les colonnes
- impliquées soient NOT NULL, et ce qui constituera un index unique.
- Voici un exemple : </para>
+ <para>
+ Cependant, une fois arrivé à cette étape, pourquoi ne pas déclarer l'index
+ comme une clef primaire, ce qui nécessite que les colonnes impliquées soient
+ NOT NULL, et ce qui constituera un index unique. Voici un exemple :
+ </para>
<programlisting>
DROP INDEX ma_table_nom_col1_col2_uniq_idx;
ALTER TABLE ma_table_nom ADD PRIMARY KEY (col1, col2);
</programlisting>
-<para>Si votre application utilise l'index ma_table_nom, vous ne
- perdrez rien et cela vous donnera l'avantage d'avoir une clef primaire
- sur votre table. </para>
+ <para>
+ Si votre application utilise l'index ma_table_nom, vous ne perdrez rien et
+ cela vous donnera l'avantage d'avoir une clef primaire sur votre table.
+ </para>
-<para> Notons que si vous devez spécifier une espace de nom ("namespace")
- pour la table, vous <emphasis>ne devez pas</emphasis> préciser l'espace
- de nom de la clef, car cela peut interférer avec d'autres espaces de
- noms de la table.</para></listitem>
+ <para>
+ Notons que si vous devez spécifier un espace de nom (« namespace »)
+ pour la table, vous <emphasis>ne devez pas</emphasis> préciser l'espace de
+ nom de la clef car cela peut interférer avec d'autres espaces de noms de la
+ table.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Si la table n'a pas de clef primaire candidate, vous devez demander à
+ &slony1; d'en produire une en utilisant la commande <xref
+ linkend="stmttableaddkey"/>.
+ </para>
-<listitem><para> Si la table n'a pas de clef primaire candidate,
-vous devez demander à &slony1; de produire une en utilisant la commande
-<xref linkend="stmttableaddkey"/>.</para>
-
-<warning><para> La commande <xref linkend="stmttableaddkey"/> a toujours été
- considéré au mieux comme un <quote>bricolage</quote>, et à
- partir de la version 2.0, elle est considéré comme une mauvaise
- fonctionnalité qu'il faut supprimer. </para>
-</warning>
-</listitem>
-
-
+ <warning>
+ <para>
+ La commande <xref linkend="stmttableaddkey"/> a toujours été considérée
+ au mieux comme un <quote>bricolage</quote>, et à partir de la version
+ 2.0, elle est considérée comme une mauvaise fonctionnalité qu'il faut
+ supprimer.
+ </para>
+ </warning>
+ </listitem>
</itemizedlist>
-<para> Il n'est pas terriblement important de sélectionner
- une <quote>vraie</quote> clef primaire ou une simple <quote>clef primaire
-</quote>. Cependant il est fortement recommandé d'utiliser une de ces deux
-solution plutôt que de laisser &slony1; remplir la colonne de clef primaire
-à votre place. Si vous n'avez pas de clef primaire candidate, cela signifie
-que la table ne fournit aucun mécanisme à votre application pour garder
-les tuples uniques. Dans ce cadre &slony1; peut introduire des erreurs
-dans votre application, de plus cela implique que vous pouvez entrer des
-données erronées dans la base de données.
+<para>
+ Il n'est pas terriblement important de sélectionner une <quote>vraie</quote>
+ clef primaire ou une simple <quote>clef primaire</quote>. Cependant, il est
+ fortement recommandé d'utiliser une de ces deux solutions plutôt que de
+ laisser &slony1; remplir la colonne de clef primaire à votre place. Si vous
+ n'avez pas de clef primaire candidate, cela signifie que la table ne fournit
+ aucun mécanisme à votre application pour garder les lignes uniques. Dans ce
+ cadre, &slony1; peut introduire des erreurs dans votre application. De plus,
+ cela implique que vous pouvez entrer des données erronées dans la base de
+ données.
</para>
+
</sect2>
-<sect2 id="definesets"><title>Regrouper les tables en ensembles</title>
-
+<sect2 id="definesets">
+<title>Regrouper les tables en ensembles</title>
<indexterm><primary> grouper les tables dans des ensembles de réplication </primary></indexterm>
-<para> Il est vital de regrouper les tables dans un seul ensemble lorsque
- ces tables sont reliées par une clef étrangère.
- Si des tables reliées de cette manières ne sont <emphasis>pas</emphasis>
- répliquées ensembles. Vous rencontrerez des problèmes lors de la bascule
- du noeud <quote>fournisseur maître</quote> vers un autre noeud,
- et vous obtiendrez un nouveau <quote>maître</quote> qui ne peut pas
- être mis à jour correctement car le contenu de certaines tables n'est
- pas disponible.</para>
+<para>
+ Il est vital de regrouper les tables dans un seul ensemble lorsque ces tables
+ sont reliées par une clef étrangère. Si des tables reliées de cette manière
+ ne sont <emphasis>pas</emphasis> répliquées ensembles, vous rencontrerez des
+ problèmes lors de la bascule du nœud <quote>fournisseur maître</quote>
+ vers un autre nœud, et vous obtiendrez un nouveau <quote>maître</quote>
+ qui ne peut pas être mis à jour correctement car le contenu de certaines
+ tables n'est pas disponible.
+</para>
-<para> Il y a également plusieurs raisons pour ne <emphasis>pas</emphasis>
- placer toutes les tables dans un ensemble unique :
+<para>
+ Il y a également plusieurs raisons pour ne <emphasis>pas</emphasis> placer
+ toutes les tables dans un ensemble unique :
+</para>
<itemizedlist>
+ <listitem>
+ <para>
+ Sur un ensemble très large, l'événement initial
+ <command>COPY_SET</command> provoque de <link
+ linkend="longtxnsareevil">très longues transactions</link> sur le
+ nœud fournisseur. La <link linkend="faq">FAQ</link> décrit un
+ certain nombre de problèmes qui conduisent à des transactions qui
+ ralentissent les performances du système.
+ </para>
-<listitem><para>Sur un ensemble très large, l'événement initial <command>COPY_SET</command> provoquent de
- <link linkend="longtxnsareevil"> très longues transactions</link>
- sur le noeud fournisseur. La <link linkend="faq">
-FAQ </link> décrit un certain nombre de problèmes qui conduisent à
-des transactions qui ralentissent les performances du système.</para>
+ <para>
+ Si vous pouvez découper un grand ensemble en plusieurs plus petits
+ ensembles, cela réduira la longueur de chaque transactions et diminuera
+ leur impact négatif sur les performances.
+ </para>
-<para> Si vous pouvez découper un grand ensemble en plusieurs
- plus petits ensembles, cela réduira la longueur de chaque transactions et
- diminuera leur impact négatif sur les performances.</para>
+ <para>
+ Un autre problème survient fréquemment lorsque l'on réplique via un
+ WAN ; parfois la connexion réseau est un peu instable, si bien
+ qu'il y a des risques qu'une connexion reste ouverte pendant plusieurs
+ heures et entraîne un <command>CONNECTION TIMEOUT</command>. Si cela se
+ produit à 95% d'une copie d'un ensemble de réplication de 50 tables,
+ représentant 250GB de données, cela va gâcher votre journée. Au contraire
+ si les tables sont séparées en plusieurs ensembles de réplication, cette
+ panne réseau qui intervient à 95% n'interrompra que la copie
+ d'<emphasis>un seul</emphasis> ensemble.
+ </para>
-<para> Un autre problème survient fréquemment lorsque l'on
- réplique via un WAN; parfois la connexion réseau est un peu
- instable, si bien qu'il y a des risques qu'une connexion reste
- ouverte pendant plusieurs heures et entraîne un <command>CONNECTION TIMEOUT.</command> Si cela se produit à 95% d'une copie
- d'un ensemble de réplication de 50 tables, représentant 250GB de données,
- cela va gâcher votre journée. Au contraire si les tables sont séparées
- en plusieurs ensembles de réplication, cette panne réseau qui intervient à 95%
- n'interrompra que la copie d'<emphasis>un seul</emphasis> ensemble.
-</para>
+ <para>
+ Certains <quote>effets négatifs</quote> surviennent lorsque la base de
+ données répliquée contient plusieurs Go de données, et qu'il faut des
+ heures ou des jours pour qu'un nœud abonné réalise une copie
+ complète des données initiales. Pour les bases relativement petites,
+ cela n'est pas un facteur important.
+ </para>
+ </listitem>
-<para>Certains <quote>effets négatifs</quote> émergent lorsque la
- base de données est répliquée contient plusieurs gigabytes de données,
- et qu'il faut des heures ou des jours pour qu'un noeud abonné réalise
- une copie complète des données initiales. Pour les bases relativement
- petites, cela n'est pas un facteur important.
-</para>
-</listitem>
+ <listitem>
+ <para>
+ Chaque invocation de la commande <xref linkend="stmtddlscript"/>
+ nécessite un verrou sur <emphasis>chaque table de l'ensemble de
+ réplication, d'abord sur le nœud d'origine puis, avec la
+ propagation de l'événement, sur chacun des nœuds abonnés
+ </emphasis>.
+ </para>
-<listitem><para> Chaque invocation de la commande <xref linkend="stmtddlscript"/>
- nécessite un verrou sur <emphasis> chaque table de l'ensemble de réplication
- , d'abord sur le noeud d'origine, puis avec la propagation
- de l'événement sur chacun des noeuds abonnés. </emphasis></para>
+ <para>
+ Des retours d'expériences <quote>de terrain</quote> indiquent que cela
+ peut conduire à des inter-blocages de verrous ("deadlocks"), ce qui
+ nécessite d'appeler la requête <xref linkend="stmtddlscript"/> plusieurs
+ fois pour réussir à l'exécuter complètement.
+ </para>
-<para> De retours d'expériences <quote>de terrain</quote> indique que
- cela peut conduire à des inter-blocages de verrous ("deadlocks"), ce qui nécessite
- d'appeler la requête <xref linkend="stmtddlscript"/> plusieurs fois
- pour réussir à l'exécuter complètement.</para>
+ <para>
+ Plus vous avez de tables dans un ensemble de réplication, plus ces tables
+ doivent être verrouillées et plus les risques d'obtenir un inter-blocage
+ des verrous sont importants.
+ </para>
-<para> Plus vous avez de tables dans un ensemble de réplication, plus
- ces tables doivent être verrouiller et plus les chances d'obtenir un
- inter-blocage des verrous sont grandes. </para>
+ <para>
+ Dans le même ordre d'idées, si un script DDL particulier doit simplement
+ affecter deux tables, vous devez utiliser <xref
+ linkend="stmtsetmovetable"/> pour les déplacer temporairement dans un
+ nouvel ensemble de réplication. En diminuant le nombre de verrous
+ nécessaire, cela simplifiera la mise en place des changements DDL.
+ </para>
-<para> Dans le même ordre d'idées, si un script DDL particulier
- doit simplement affecter deux tables, vous devez utiliser
- <xref linkend="stmtsetmovetable"/> pour les déplacer temporairement
- dans un nouvel ensemble de réplication.
- En diminuant le nombre de verrous nécessaire, cela simplifiera
- la mise en place des changements DDL.</para>
+ <para>
+ Il y a de plus amples <link linkend="locking">discussions sur les
+ verrous</link> qui décrivent quand &slony1; a besoin de verrous et leur
+ impact sur vos applications.
+ </para>
+ </listitem>
+</itemizedlist>
-<para> Il y a de plus amples <link linkend="locking"> discussions sur les verrous </link>
- qui décrivent quand &slony1; a besoin de verrous et leur impact sur vos applications.</para>
-</listitem>
-
-</itemizedlist></para>
-
</sect2>
-<sect2> <title> La pathologie des séquences</title>
-
+<sect2> <title>Pathologie des séquences</title>
<indexterm><primary>Pathologie de séquence</primary></indexterm>
-<para> Chaque fois qu'un évènement SYNC est traité, les valeurs sont enregistrées
- pour <emphasis>toutes</emphasis> les séquences de l'ensemble de réplication. Si
- vous avez beaucoup de séquence, cela peut augmenter fortement la volumétrie de
- la table <xref linkend="table.sl-seqlog"/> .</para>
+<para>
+ Chaque fois qu'un évènement SYNC est traité, les valeurs sont enregistrées
+ pour <emphasis>toutes</emphasis> les séquences de l'ensemble de réplication.
+ Si vous avez beaucoup de séquences, cela peut augmenter fortement la
+ volumétrie de la table <xref linkend="table.sl-seqlog"/> .
+</para>
-<para> Cela illustre une différence importantes entre les tables et les séquences :
- si vous ajouter des tables supplémentaire qui peu voire aucune activité, cela n'ajoute
- pas de charge supplémentaire pour le système de réplication.
- Pour les séquences répliquées, les valeurs doivent être
-<emphasis>régulièrement</emphasis> propagées aux abonnés.
-Considérons les conséquences :
+<para>
+ Cela illustre une différence importante entre les tables et les
+ séquences : si vous ajoutez des tables supplémentaire qui ont peu
+ d'activité, voire aucune, cela n'ajoute pas de charge supplémentaire pour le
+ système de réplication. Pour les séquences répliquées, les valeurs doivent
+ être <emphasis>régulièrement</emphasis> propagées aux abonnés. Considérons
+ les conséquences :
-<itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Une table répliquée mais qui n'est jamais mise à jour n'entraîne pas
+ de travail supplémentaire.
+ </para>
-<listitem><para> Une table répliquée mais qui n'est jamais mise à jour
- n'entraîne pas de travail supplémentaire.
- </para>
+ <para>
+ Si elle n'est jamais mise à jour, le trigger de la table sur le
+ nœud origine n'est jamais déclenché, et aucune entrée n'est
+ ajoutée dans <xref linkend="table.sl-log-1"/>. La table n'apparaît
+ jamais dans aucune des requêtes de réplication (<emphasis>par
+ exemple :</emphasis> dans les requêtes <command>FETCH 100 FROM
+ LOG</command> utilisées pour trouver les données à répliquer) car elles
+ ne recherchent que les tables qui ont des entrées dans
+ <xref linkend="table.sl-log-1"/>.
+ </para>
+ </listitem>
-<para> Si elle n'est jamais mise à jour, le trigger sur la table sur le noeud
- origine n'est jamais déclenché, et aucune entrée n'est ajoutées dans <xref
- linkend="table.sl-log-1"/>. La table n'apparaît jamais dans aucune
- des requêtes de réplication (<emphasis>par exemple :</emphasis> dans les requêtes
- <command>FETCH 100 FROM LOG</command> utilisées pour trouver les données à répliquer)
- car elles ne recherchent que les tables qui ont des entrées dans
- <xref linkend="table.sl-log-1"/>.</para></listitem>
+ <listitem>
+ <para>
+ Au contraire, une certaine quantité de travail est ajoutée lors d'un
+ événement SYNC pour chaque séquence qui est répliquée.
+ </para>
-<listitem><para> Au contraire, une certaine quantité de travail est ajoutée
- lors d'un événement SYNC pour chaque séquence qui est répliquée.
-</para>
+ <para>
+ Pour répliquer 300 séquences, 300 lignes doivent être ajoutées dans la
+ <xref linkend="table.sl-seqlog"/> de manière régulière.
+ </para>
-<para> Pour répliquer 300 séquences, 300 lignes doivent être ajoutées dans la
- <xref linkend="table.sl-seqlog"/> de manière régulière.</para>
+ <para>
+ Il est probable que si une valeur d'une séquence particulière n'a pas
+ changé depuis la dernière vérification, alors il n'est peut-être pas
+ nécessaire de stocker cette valeur encore et encore. Certaines
+ reflexions sont en cours sur le moyen de réaliser cela de manière
+ sécurisée.
+ </para>
+ </listitem>
-<para> Il est probable que si une valeur d'une séquence particulière n'a pas changé
- depuis la dernière vérification, alors il n'est peut être pas nécessaire
- de stocker cette valeur encore et encore. Certaines reflexions sont en cours sur
- comment réaliser cela de manière sécurisée.
- </para></listitem>
+ <listitem>
+ <para>
+ Le <ulink
+ url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
+ bug #1226</ulink> indique une condition d'erreur qui peut se produire
+ si vous avez un ensemble de réplication composé uniquement de séquences.
+ </para>
-<listitem><para> <ulink url=
-"http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
-Le bug #1226 </ulink> indique une condition d'erreur qui peut se produire
-si vous avez un ensemble de réplication composé uniquement de séquence.
- </para>
+ <para>
+ Ceci est documenté plus précisément dans la <link
+ linkend="sequenceset">FAQ</link>. En résumé, avoir un ensemble de
+ réplication composé uniquement de séquences n'est pas particulièrement
+ une bonne idée.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-<para> Ceci est documenté plus précisément dans la <link linkend="sequenceset"> FAQ;</link>
- En résumé, avoir un ensemble de réplication composé uniquement de séquences n'est
- particulièrement une bonne idée.</para></listitem>
+</sect2>
-</itemizedlist></para></sect2>
-
</sect1>
-
Modified: traduc/trunk/slony/listenpaths.xml
===================================================================
--- traduc/trunk/slony/listenpaths.xml 2009-01-19 21:20:59 UTC (rev 1221)
+++ traduc/trunk/slony/listenpaths.xml 2009-01-19 21:21:45 UTC (rev 1222)
@@ -4,79 +4,103 @@
par $Author$
révision $Revision$ -->
-<sect1 id="listenpaths"><title>Voies d'écoute</title>
+<sect1 id="listenpaths">
+<title>Voix d'écoute</title>
+<indexterm><primary>voix d'écoute</primary></indexterm>
-<indexterm><primary>voies d"écoute</primary></indexterm>
-
-<note><para> Si vous utilisez une version &slony1; 1.2 ou ultérieure, il
- est <emphasis>complètement inutile</emphasis> de lire cette section car
- cette version dispose d'un méthode de gestion automatique de cette partie
- de sa configuration. Pour les versions antérieures, cependant, ce qui va
- suivre est nécessaire.
- </para>
+<note>
+ <para>
+ Si vous utilisez une version &slony1; 1.2 ou ultérieure, il est
+ <emphasis>complètement inutile</emphasis> de lire cette section car cette
+ version dispose d'une méthode de gestion automatique de cette partie de la
+ configuration. Pour les versions antérieures, cependant, ce qui va suivre
+ est nécessaire.
+ </para>
</note>
-<para>Si vous avez plus de deux ou trois noeuds et un niveau d'abonnement
- en cascade ( <emphasis>c'est à dire</emphasis> des noeuds qui s'abonne
- à des noeuds abonnés ), vous devez être très prudent avec la configuration
- des <quote>voies d'écoute</quote> par les commandes Slonik
- <xref linkend="stmtstorelisten"/> et <xref linkend="stmtdroplisten"/> qui
- contrôle le contenu de la table <xref linkend="table.sl-listen"/>.</para>
+<para>
+ Si vous avez plus de deux ou trois nœuds et un niveau d'abonnement
+ en cascade (<emphasis>c'est-à-dire</emphasis> des nœuds qui s'abonnent
+ à des nœuds abonnés), vous devez être très prudent avec la configuration
+ des <quote>voix d'écoute</quote> par les commandes Slonik <xref
+ linkend="stmtstorelisten"/> et <xref linkend="stmtdroplisten"/> qui
+ contrôlent le contenu de la table <xref linkend="table.sl-listen"/>.
+</para>
-<para>Les entrées de cette table contrôlent où chaque noeuds doit écouter afin
- d'obtenir les événements propagés par les autres noeuds. Vous vous dites
- peut-être que chaque noeud doit simplement écouter le noeud
- <quote>parent</quote> qui leur transmet les mise à jours, mais en réalité, ils doivent
- pouvoir recevoir des messages de ma part de <emphasis>tous</emphasis> les noeuds
- afin de pouvoir déterminer si les <command>SYNC</command>s ont été reçus
- partout et que les entrées de <xref linkend="table.sl-log-1"/> et <xref
- linkend="table.sl-log-2"/> ont été appliquées partout et qu'elles
- peuvent être purgées. Ces communications supplémentaires permettent à
- <productname>Slony-I</productname> de déplacer les origines vers d'autres
- noeuds.</para>
+<para>
+ Les entrées de cette table contrôlent où chaque nœuds doit écouter afin
+ d'obtenir les événements propagés par les autres nœuds. Vous vous dîtes
+ peut-être que chaque nœud doit simplement écouter le nœud
+ <quote>parent</quote> qui leur transmet les mise à jours mais, en réalité,
+ ils doivent pouvoir recevoir des messages de la part de
+ <emphasis>tous</emphasis> les nœuds afin de pouvoir déterminer si les
+ <command>SYNC</command>s ont été reçues partout et que les entrées de <xref
+ linkend="table.sl-log-1"/> et <xref linkend="table.sl-log-2"/> ont été
+ appliquées partout et qu'elles peuvent être purgées. Ces communications
+ supplémentaires permettent à <productname>Slony-I</productname> de déplacer
+ les origines vers d'autres nœuds.
+</para>
-<sect2><title>Comment l'écoute peut être rompue</title>
+<sect2>
+<title>Comment l'écoute peut être rompue</title>
+<indexterm><primary>rupture d'écoute</primary></indexterm>
-<indexterm><primary> rupture d'écoute </primary></indexterm>
+<para>
+ À une occasion, j'ai eu besoin de supprimer un nœud abonné (#2) et de
+ la recréer. Ce nœud était le fournisseur d'un autre abonné (#3) qui
+ était, de facto, un <quote>esclave en cascade</quote>. La suppression du
+ nœud abonné ne fonctionna pas, en effet <xref linkend="slonik"/>
+ m'informa qu'il existait un nœud dépendant. Je fis pointer le
+ nœud dépendant vers le nœud <quote>maître</quote> de
+ l'ensemble de réplication, ce qui se déroula, pour un temps, sans
+ difficultés.
+</para>
-<para>A une occasion, j'ai eu besoin de supprimer un noeud abonné (#2) et
- de la recréer. Ce noeud était le fournisseur d'un autre abonné (#3) qui
- était, de facto, un <quote>esclave en cascade</quote>.
- La suppression du noeud abonné ne fonctionna, en effet
- <xref linkend="slonik"/> m'informa qu'il existait un noeud dépendant.
- Je fit pointer le noeud dépendant vers le noeud <quote>maître</quote>
- de l'ensemble de réplication, ce qui se déroula, pour un temps,
- sans difficultés.</para>
+<para>
+ Je supprimais alors l'abonnement du <quote>nœud 2</quote>, et tentais
+ de l'abonner de nouveau. Cela déclencha un événement &slony1;
+ <command>set_subscription</command>, qui commença à copier les tables.
+ À ce moment, les événements ne furent plus propagés au <quote>nœud
+ 3</quote>, et tandis qu'il était en parfait état de fonctionnement, plus
+ aucun événement ne lui parvenait.
+</para>
-<para>Je supprimais alors l'abonnement du <quote>node 2</quote>, et tentais de
- l'abonner de nouveau. Cela déclencha un événement &slony1;
-<command>set_subscription</command>, qui commença à copier les tables.
-À ce moment, les événements ne furent plus propagés au <quote>noeud 3</quote>,
-et tandis qu'il était en parfait état de fonctionnement, plus aucun
-événement ne lui parvenait.</para>
+<para>
+ Le problème était que le nœud #3 attendait de recevoir des événements
+ de la part du nœud #2, qui était occupé par le traitement de
+ l'événement <command>set_subscription</command> et ne transmettait aucune
+ autre information.
+</para>
-<para>Le problème était que le noeud #3 attendait de recevoir des événements de la part
- du noeud #2, qui était occupé par le traitement de l'événement <command>set_subscription</command>
- et ne transmettait aucune autre information.</para>
+<para>
+ Nous avons supprimé les règles qui ordonnaient au nœud #3 d'écouter le
+ nœud #2, en les remplaçant par des règles qui lui indiquaient d'attendre
+ les événements en provenance du nœud #1 (le nœud origine de la
+ réplication). À ce moment, <quote>comme par magie</quote>, le nœud #3
+ recommença à répliquer car il avait découvert une source où écouter les
+ évènements <command>SYNC</command>.
+</para>
-<para>Nous supprimames les règles qui ordonnait au noeud #3 d'écouter le noeud #2,
- en les remplaçant par des règles qui lui indiquait d'attendre les événements en provenance
- du noeud #1 ( le noeud origine de la réplication ). À ce moment,
- <quote>comme par magie</quote>, le noeud #3 recommença à répliquer, car
- il avait découvert une source ou écouter les évènements <command>SYNC</command>.</para>
</sect2>
-<sect2><title>Comment configurer les écoutes</title>
-<para>Les cas simples sont facile à gérer. Intéressons-nous plutôt
- à un configuration plus complexe.</para>
+<sect2>
+<title>Comment configurer les écoutes</title>
-<para>Considérons un ensemble de noeuds, de 1 à 6, où 1 est l'origine,
-2-4 sont abonnés directement à l'origine, 5 est abonné à 2,
-et 6 est abonné à 5.</para>
+<para>
+ Les cas simples sont facile à gérer. Intéressons-nous plutôt à une
+ configuration plus complexe.
+</para>
-<para>Voici un <quote>réseau d'écoute</quote> qui montre où chaque noeud doit
- écouter les messages en provenance des autres noeuds :
+<para>
+ Considérons un ensemble de nœuds, de 1 à 6, où 1 est l'origine, 2-4
+ sont abonnés directement à l'origine, 5 est abonné à 2, et 6 est abonné à
+ 5.
+</para>
+<para>
+ Voici un <quote>réseau d'écoute</quote> qui montre où chaque nœud doit
+ écouter les messages en provenance des autres nœuds :
+
<screen>
1| 2| 3| 4| 5| 6|
--------------------------------------------
@@ -88,17 +112,23 @@
6 5 5 5 5 5 0
</screen>
</para>
-<para>La ligne 2 indique toutes les règles d'écoute pour le noeud 2;
- il obtient les événements des noeuds 1, 3 et 4 chez le noeud 1 et il
- écoute sur le noeud 5 les événements des noeuds 5 et 6.
- </para>
-<para>La dernière ligne composée de 5, celle du noeud 6, indique que le noeud 6
-écoute le noeud 5 pour obtenir les événements des noeuds 1 à 5.</para>
+<para>
+ La ligne 2 indique toutes les règles d'écoute pour le nœud 2 ;
+ il obtient les événements des nœuds 1, 3 et 4 chez le nœud 1 et
+ il écoute sur le nœud 5 les événements des nœuds 5 et 6.
+</para>
-<para>Les commandes slonik <command>set listen</command> qui exprime
- ce <quote>réseau d'écoute</quote> sont les suivantes :
+<para>
+ La dernière ligne composée de 5, celle du nœud 6, indique que le
+ nœud 6 écoute le nœud 5 pour obtenir les événements des
+ nœuds 1 à 5.
+</para>
+<para>
+ Les commandes slonik <command>set listen</command> qui expriment ce
+ <quote>réseau d'écoute</quote> sont les suivantes :
+
<programlisting>
store listen (origin = 1, receiver = 2, provider = 1);
store listen (origin = 1, receiver = 3, provider = 1);
@@ -132,85 +162,124 @@
store listen (origin = 6, receiver = 5, provider = 6);
</programlisting>
</para>
-<para>Ces lignes de commandes d'écoute sont lues lorsque...</para>
-<para>... le noeud <quote>récepteur</quote>, cherche un noeud <quote>fournisseur</quote>
-pour obtenir les événements en provenance du noeud d'<quote>origine</quote>.</para>
+<para>
+ Ces lignes de commandes d'écoute sont lues lorsque...
+</para>
-<para>L'outil <filename>init_cluster</filename> parmi les scripts
-<filename>altperl</filename> produit un réseau d'écoute optimisé
-sous forme de tableau et ainsi qu'une liste de commandes
-<xref linkend="slonik"/>.</para>
+<para>
+ ... le nœud <quote>récepteur</quote> cherche un nœud
+ <quote>fournisseur</quote> pour obtenir les événements en provenance du
+ nœud d'<quote>origine</quote>.
+</para>
-<para>Il y a trois <quote>épines</quote> dans ce bouquet de roses :
+<para>
+ L'outil <filename>init_cluster</filename> parmi les scripts
+ <filename>altperl</filename> produit un réseau d'écoute optimisé sous forme
+ de tableau et ainsi qu'une liste de commandes <xref linkend="slonik"/>.
+</para>
-<itemizedlist>
+<para>
+ Il y a trois <quote>épines</quote> dans ce bouquet de roses :
-<listitem><para> Si vous changez la structure du l'ensemble de noeuds, alors
- les noeuds sont abonnés différemment et vous devez supprimer les entrées
- de la table <xref linkend="table.sl-listen"/> et en créez de nouvelles
- pour décrire les nouvelles voies d'écoute entre les noeuds.
- Jusqu'à &slony1; 1.2, il n'y a aucune manière automatique de réaliser
- cette <quote>restructuration</quote>.</para></listitem>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Si vous changez la structure de l'ensemble de nœuds, alors les
+ nœuds sont abonnés différemment et vous devez supprimer les
+ entrées de la table <xref linkend="table.sl-listen"/> et en créez de
+ nouvelles pour décrire les nouvelles voies d'écoute entre les
+ nœuds. Jusqu'à &slony1; 1.2, il n'y a aucune manière automatique
+ de réaliser cette <quote>restructuration</quote>.
+ </para>
+ </listitem>
-<listitem><para> Si vous <emphasis>ne changez pas</emphasis> les entrées
-<xref linkend="table.sl-listen"/>, les événements se propageront
-tant que les noeuds fonctionnerait correctement. Le problème se
-déclenchera lorsqu'un noeud sera retiré,,rendant <quote>orphelin</quote>
-les noeuds qui l'écoutaient.</para></listitem>
+ <listitem>
+ <para>
+ Si vous <emphasis>ne changez pas</emphasis> les entrées de <xref
+ linkend="table.sl-listen"/>, les événements se propageront tant que les
+ nœuds fonctionnent correctement. Le problème se déclenchera
+ lorsqu'un nœud sera retiré, rendant <quote>orphelin</quote> les
+ nœuds qui l'écoutaient.
+ </para>
+ </listitem>
-<listitem><para> Vous pouvez essayer de multiples ensembles de réplication
- qui ont des structures <emphasis>différentes</emphasis> pour leur arborescence
- d'abonnés. Il n'y aucune configuration d'écoute qui convienne parfaitement
- dans ce cas.</para></listitem>
+ <listitem>
+ <para>
+ Vous pouvez essayer de multiples ensembles de réplication qui ont des
+ structures <emphasis>différentes</emphasis> pour leur arborescence
+ d'abonnés. Il n'y aucune configuration d'écoute qui convienne
+ parfaitement dans ce cas.
+ </para>
+ </listitem>
-<listitem><para> Afin de créer une voie <xref linkend="table.sl-listen"/>,
- il <emphasis>doit</emphasis> exister une série d'entrées<xref linkend="table.sl-path"/>
- qui connectent l'origine au récepteur. Cela implique que si le contenu
- de <xref linkend="table.sl-path"/> ne définit pas réseau <quote>connecté</quote>
- de noeuds, alors certains noeuds ne seront pas accessibles. Typiquement cela
- peut se produire, lorsque vous avez deux ensembles de noeuds, placés sur deux
- sous-réseaux séparés, avec simplement deux noeuds <quote>pare-feu</quote>
- qui communiquent d'un sous-réseau à l'autre. Couper un de ces noeuds et les
- sous-ensembles de réplication s'arrêtent.</para></listitem>
+ <listitem>
+ <para>
+ Afin de créer une voie <xref linkend="table.sl-listen"/>, il
+ <emphasis>doit</emphasis> exister une série d'entrées <xref
+ linkend="table.sl-path"/> qui connectent l'origine au récepteur. Cela
+ implique que si le contenu de <xref linkend="table.sl-path"/> ne
+ définit pas que le réseau est <quote>connecté</quote> de nœuds,
+ alors certains nœuds ne seront pas accessibles. Typiquement, cela
+ peut se produire, lorsque vous avez deux ensembles de nœuds,
+ placés sur deux sous-réseaux séparés, avec simplement deux nœuds
+ <quote>pare-feu</quote> qui communiquent d'un sous-réseau à l'autre.
+ Couper un de ces nœuds et les sous-ensembles de réplication
+ s'arrêtent.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-</itemizedlist></para>
-
</sect2>
-<sect2 id="autolisten"><title>Génération automatique de voie d'écoute</title>
-
+<sect2 id="autolisten">
+<title>Génération automatique de voie d'écoute</title>
<indexterm><primary>génération automatique de voie d'écoute </primary></indexterm>
-<para> Dans &slony1; version 1.1, une règle heuristique est introduite pour
+<para>
+ Dans &slony1; version 1.1, une règle heuristique est introduite pour
générer automatiquement les entrées <envar>sl_listen</envar>.
- Cela se fait en fonction de 3 types d'informations :
+ Cela se fait en fonction de trois types d'informations :
-<itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Les entrées de <xref linkend="table.sl-subscribe"/> sont des
+ informations primordiales et vitales sur qui doit écouter quoi ;
+ nous <emphasis>savons</emphasis> qu'il doit y avoir une voie directe
+ entre chaque abonné et son fournisseur.
+ </para>
+ </listitem>
-<listitem><para>Les entrées <xref linkend="table.sl-subscribe"/> sont
- les informations primordiales et vitales sur qui doit écouter quoi;
- nous <emphasis>savons</emphasis> qu'il doit y avoir une voie
- directe entre chaque abonné et son fournisseur.
- </para></listitem>
+ <listitem>
+ <para>
+ Les entrées <xref linkend="table.sl-path"/> sont le second
+ indicateur ; si la table <xref linkend="table.sl-subscribe"/>
+ n'indique pas <quote>comment écouter</quote>, alors un nœud
+ peut écouter directement l'origine s'il existe une voie praticable
+ dans <xref linkend="table.sl-path"/>.
+ </para>
+ </listitem>
-<listitem><para>Les entrées <xref linkend="table.sl-path"/> sont
- le second indicateur; si a table <xref linkend="table.sl-subscribe"/>
- n'indique pas <quote>comment écouter</quote>, alors un noeud
- peut écouter directement l'origine si il existe une voie praticable
- dans <xref linkend="table.sl-path"/>.</para></listitem>
+ <listitem>
+ <para>
+ Enfin, si aucune indication n'a été obtenue à partir des informations
+ précédentes. alors les nœuds peuvent écouter indirectement via
+ un nœud qui est fournisseur de l'abonné, ou qui utilise l'abonné comme
+ fournisseur.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
-<listitem><para> Enfin, si aucune indication n'a été obtenue à partir des
- informations précédentes. alors les noeuds peuvent écouter indirectement
- via un noeud qui est fournisseur de l'abonné, ou qui utilise l'abonné comme
- fournisseur.</para></listitem>
+<para>
+ À chaque fois que les tables <xref linkend="table.sl-subscribe"/> ou <xref
+ linkend="table.sl-path"/> sont modifiées, la fonction
+ <function>RebuildListenEntries()</function> est appelée pour mettre à jour
+ les voies d'écoute.
+</para>
-</itemizedlist></para>
+</sect2>
-<para> À chaque fois que les tables <xref linkend="table.sl-subscribe"/> ou <xref
-linkend="table.sl-path"/> sont modifiées, la fonction
-<function>RebuildListenEntries()</function> est appelée pour
-mettre à jour les voies d'écoute.</para>
-
-</sect2>
-</sect1>
\ No newline at end of file
+</sect1>
Modified: traduc/trunk/slony/monitoring.xml
===================================================================
--- traduc/trunk/slony/monitoring.xml 2009-01-19 21:20:59 UTC (rev 1221)
+++ traduc/trunk/slony/monitoring.xml 2009-01-19 21:21:45 UTC (rev 1222)
@@ -6,81 +6,110 @@
<sect1 id="monitoring">
<title>Surveillance</title>
-
<indexterm><primary>Surveiller &slony1;</primary></indexterm>
-<sect2> <title> Tester la replication avec &nagios; </title>
-
+<sect2>
+<title>Tester la replication avec &nagios;</title>
<indexterm><primary>&nagios; pour surveiller la réplication</primary></indexterm>
-<para> Le script <command> psql_replication_check.pl </command> qui se trouve
- dans le répertoire <filename>tools</filename> regroupe les meilleures
- tentatives de construire de création de tests utilisables par le système
- de surveillance <ulink url="http://www.nagios.org/"> &nagios;</ulink>.</para>
+<para>
+ Le script <command>psql_replication_check.pl</command>, qui se trouve dans le
+ répertoire <filename>tools</filename>, regroupe les meilleures tentatives de
+ de tests utilisables par le système de surveillance <ulink
+ url="http://www.nagios.org/">&nagios;</ulink>.
+</para>
-<para> Un script antérieur, nommé <filename>
-test_slony_replication.pl</filename>, utilisait une approche <quote>intelligente</quote>
-: un <quote>script de test</quote> est exécuté périodiquement et se déploie à travers les configurations
-&slony1; pour trouver l'origine et les abonnés, injecte un changement et observe sa propagation
-à travers le système. Il présentait deux problèmes :</para>
+<para>
+ Un script antérieur, nommé <filename>test_slony_replication.pl</filename>,
+ utilisait une approche <quote>intelligente</quote> : un <quote>script de
+ test</quote> est exécuté périodiquement et se déploie à travers les
+ configurations &slony1; pour trouver l'origine et les abonnés, injecte un
+ changement et observe sa propagation à travers le système. Il présentait deux
+ problèmes :
+</para>
+
<itemizedlist>
+ <listitem>
+ <para>
+ En cas de problème de connectique impactant le nœud qui jouait ce
+ test, c'est l'ensemble de réplication qui semblait détruite. De plus,
+ cette stratégie de surveillance est très fragile et dépend de nombreuses
+ conditions d'erreurs.
+ </para>
+ </listitem>
-<listitem><para> En cas de problème de connectique impactant le noeud qui jouait ce test
- c'est l'ensemble de réplication qui semblait détruite. De plus, cette stratégie de
- surveillance est très fragile et dépend de nombreuses conditions d'erreurs.</para>
-</listitem>
-
-<listitem><para> &nagios; n'a pas la possibilité de profiter de
-<quote>l'intelligence</quote> d'une exploration automatique d'un ensemble de noeuds.
-Vous devez mettre en place des règles de surveillance &nagios; pour chaque noeud.
-</para> </listitem>
+ <listitem>
+ <para>
+ &nagios; n'a pas la possibilité de profiter de l'
+ <quote>intelligence</quote> d'une exploration automatique d'un ensemble
+ de nœuds. Vous devez mettre en place des règles de surveillance
+ &nagios; pour chaque nœud.
+ </para>
+ </listitem>
</itemizedlist>
-<para> Le nouveau script, <command>psql_replication_check.pl</command>,
-utilise une approche minimaliste qui suppose que le système est une
-système en ligne recevant un <quote>trafic</quote> régulier, et vous
-permet de définir une vue spécifique pour le test de replication appelée
-<envar>replication_status</envar> qui doit contenir des mises à jour
-régulières. Cette vue regarde simplement la dernière
-<quote>transaction</quote> sur le noeud, et liste son timestamp, son âge,
-ainsi que quelques informations sur l'application qui peuvent être utiles.
+<para>
+ Le nouveau script, <command>psql_replication_check.pl</command>, utilise une
+ approche minimaliste qui suppose que le système est un système en ligne
+ recevant un <quote>trafic</quote> régulier, et vous permet de définir une vue
+ spécifique pour le test de réplication appelée
+ <envar>replication_status</envar> qui doit contenir des mises à jour
+ régulières. Cette vue regarde simplement la dernière
+ <quote>transaction</quote> sur le nœud, et liste son horodatage, son
+ âge ainsi que quelques informations sur l'application qui peuvent être
+ utiles.
</para>
<itemizedlist>
+ <listitem>
+ <para>
+ Pour un système d'inventaire, cela pourrait être le numéro de l'ordre
+ effectué le plus récemment.
+ </para>
+ </listitem>
-<listitem><para>Pour un système d'inventaire, cela pourrait être
- le numéro de l'ordre effectué le plus récemment. </para> </listitem>
-
-<listitem><para>Pour un serveur de nom de domaines, cela peut être le nom
- du dernier domaine crée.</para> </listitem>
-
+ <listitem>
+ <para>
+ Pour un serveur de nom de domaines, cela peut être le nom du dernier
+ domaine créé.
+ </para>
+ </listitem>
</itemizedlist>
-<para> Une instance du script doit être lancée sur chaque noeud surveillé;
- c'est ainsi que &nagios; fonctionne.</para>
+<para>
+ Une instance du script doit être exécutée sur chaque nœud
+ surveillé ; c'est ainsi que &nagios; fonctionne.
+</para>
</sect2>
-<sect2 id="slonymrtg"> <title> Surveiller &slony1; avec MRTG </title>
-
+<sect2 id="slonymrtg">
+<title>Surveiller &slony1; avec MRTG</title>
<indexterm><primary>Utiliser MRTG pour surveiller la réplication</primary></indexterm>
-<para> Un utilisateur a expliqué sur la liste de discussion de &slony1; comment
+<para>
+ Un utilisateur a expliqué sur la liste de discussion de &slony1; comment
configurer <ulink url="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/">
-<application> mrtg ( Multi Router Traffic Grapher )</application>
-</ulink> pour surveiller une réplication &slony1;.</para>
+ <application>MRTG</application></ulink> (acronyme de « Multi Router
+ Traffic Grapher ») pour surveiller une réplication &slony1;.
+</para>
-<para> ... Puisque j'utilise <application>mrtg</application> pour visualiser
- les données depuis plusieurs serveurs, j'utilise SNMP
- (<application>net-snmp</application> pour être exact).*
- Pour un serveur de base de données, j'ai ajouté la ligne suivante à la configuration
- <application>snmpd</application> :</para>
+<para>
+ [...] puisque j'utilise <application>MRTG</application> pour visualiser les
+ données depuis plusieurs serveurs, j'utilise SNMP
+ (<application>net-snmp</application> pour être exact). Pour un serveur de
+ bases de données, j'ai ajouté la ligne suivante à la configuration de
+ <application>snmpd</application> :
+</para>
<programlisting>
exec replicationLagTime /cvs/scripts/snmpReplicationLagTime.sh 2
-avec <filename> /cvs/scripts/snmpReplicationLagTime.sh</filename> contenant ceci :
</programlisting>
+<para>
+ avec <filename>/cvs/scripts/snmpReplicationLagTime.sh</filename> contenant
+ ceci :
+</para>
<programlisting>
#!/bin/bash
@@ -89,7 +118,10 @@
WHERE st_received = $1"
</programlisting>
-<para> Ensuite, dans la configuration de mrtg, ajouter la cible suivante :</para>
+<para>
+ Ensuite, dans la configuration de mrtg, j'ai ajouté la cible suivante :
+</para>
+
<programlisting>
Target[db_replication_lagtime]:extOutput.3&extOutput.3:public at db::30:::
MaxBytes[db_replication_lagtime]: 400000000
@@ -98,13 +130,16 @@
Options[db_replication_lagtime]: gauge,nopercent,growright
</programlisting>
+<para>
+ De son coté, Ismail Yenigul propose une méthode pour surveiller
+ &slony1; en utilisant <application>MRTG</application> sans installer
+ <application>SNMPD</application>.
+</para>
-<para> De son coté, Ismail Yenigul propose une méthode pour surveiller
- &slony1; en utilisant <application>MRTG</application> sans installer
-<application>SNMPD</application>.</para>
+<para>
+ Voici sa configuration MRTG :
+</para>
-<para>Voici sa configuration MRTG :</para>
-
<programlisting>
Target[db_replication_lagtime]:`/bin/snmpReplicationLagTime.sh 2`
MaxBytes[db_replication_lagtime]: 400000000
@@ -113,7 +148,9 @@
Options[db_replication_lagtime]: gauge,nopercent,growright
</programlisting>
-<para> et voici sa version modifiée du script :</para>
+<para>
+ Et voici sa version modifiée du script :
+</para>
<programlisting>
# cat /bin/snmpReplicationLagTime.sh
@@ -128,120 +165,168 @@
# end of script#
</programlisting>
+<note>
+ <para>
+ MRTG attend quatre lignes en provenance du script. Puisque le script n'en
+ fournit que deux, la sortie doit être prolongée de deux lignes.
+ </para>
+</note>
-<note><para> MRTG attend quatre lignes en provenance du script. Puisque le script n'en fournit
- que deux, la sortie doit être prolongée de deux lignes.
- </para> </note>
-
</sect2>
-<sect2 id="testslonystate"> <title> test_slony_state</title>
-
+<sect2 id="testslonystate">
+<title>test_slony_state</title>
<indexterm><primary>script test_slony_state pour tester l'état de la réplication</primary></indexterm>
-<para> Ce script effectue différents analyses sur l'état d'un cluster
-&slony1;.</para>
+<para>
+ Ce script effectue différents analyses sur l'état d'un cluster &slony1;.
+</para>
-<para>Vous devez spécifier les arguments tels que <option>la base de données</option>,
-<option>l'hôte</option>, <option>l'utilisateur</option>,
-<option>le cluster</option>, <option>le mot de passe</option>, et
-<option>le port</option> afin de se connecter à n'importe quel
-noeud du cluster. Vous devez également préciser une commande
- <option>mailprog</option> ( qui doit être un commande équivalente
-à la commande <productname>Unix</productname>
-<application>mailx</application>) et une destination pour le courrier. </para>
+<para>
+ Vous devez spécifier les arguments tels que la <option>base de
+ données</option>, l'<option>hôte</option>, l'<option>utilisateur</option>,
+ le <option>cluster</option>, le <option>mot de passe</option> et le
+ <option>port</option> afin de se connecter à n'importe quel nœud du
+ cluster. Vous devez également préciser une commande <option>mailprog</option>
+ (qui doit être une commande équivalente à la commande
+ <productname>Unix</productname> <application>mailx</application>) et une
+ destination pour le courrier.
+</para>
-<para> Par ailleurs vous spécifier les paramètres de connexion aux bases de données
- via les variables d'environnement utilisées par
-<application>libpq</application>, <emphasis>par exemple :</emphasis> - utiliser
-<envar>PGPORT</envar>, <envar>PGDATABASE</envar>,
-<envar>PGUSER</envar>, <envar>PGSERVICE</envar>, et ainsi de suite.</para>
+<para>
+ Par ailleurs, vous spécifiez les paramètres de connexion aux bases de données
+ via les variables d'environnement utilisées par
+ <application>libpq</application>, <emphasis>par exemple</emphasis> :
+ <envar>PGPORT</envar>, <envar>PGDATABASE</envar>, <envar>PGUSER</envar>,
+ <envar>PGSERVICE</envar> et ainsi de suite.
+</para>
-<para>Le script se promène à travers <xref linkend="table.sl-path"/>
-pour trouver tous les noeuds du cluster, et dans les DSNs qui lui
-permettront de se connecter à chaque noeud.</para>
+<para>
+ Le script se promène à travers <xref linkend="table.sl-path"/> pour trouver
+ tous les nœuds du cluster et dans les DSNs qui lui permettront de se
+ connecter à chaque nœud.
+</para>
-<para> Pour chaque noeud, le script examine l'état des données suivantes :
+<para>
+ Pour chaque nœud, le script examine l'état des données suivantes :
+</para>
<itemizedlist>
-<listitem><para> Vérification de <xref linkend="table.sl-listen"/>
- à la recherche de problèmes
-<quote>déterminés analytiquement</quote>. Cela liste les voies de communication
-qui ne sont pas couvertes.</para></listitem>
+ <listitem>
+ <para>
+ Vérification de <xref linkend="table.sl-listen"/> à la recherche de
+ problèmes <quote>déterminés analytiquement</quote>. Cela liste les voies
+ de communication qui ne sont pas couvertes.
+ </para>
+ </listitem>
-<listitem><para> Effectuer un résumé des événements sur le noeud d'origine</para>
+ <listitem>
+ <para>
+ Effectuer un résumé des événements sur le nœud d'origine.
+ </para>
-<para> Si un noeud n'a pas soumis un événement depuis longtemps, il y a certainement
- un problème.</para></listitem>
+ <para>
+ Si un nœud n'a pas soumis un événement depuis longtemps, il y a
+ certainement un problème.
+ </para>
+ </listitem>
-<listitem><para> Vérification de <quote>l'âge</quote> de la table <xref
-linkend="table.sl-confirm"/> </para>
+ <listitem>
+ <para>
+ Vérification de <quote>l'âge</quote> de la table <xref
+ linkend="table.sl-confirm"/>.
+ </para>
-<para> Si un ou plusieurs noeuds du cluster n'ont pas envoyé de rapport récemment
- alors cela peut conduire à l'absence de nettoyage dans certaines tables comme
- <xref linkend="table.sl-log-1"/> et <xref linkend="table.sl-seqlog"/></para></listitem>
+ <para>
+ Si un ou plusieurs nœuds du cluster n'ont pas envoyé de rapport
+ récemment, alors cela peut conduire à l'absence de nettoyage dans
+ certaines tables comme <xref linkend="table.sl-log-1"/> et <xref
+ linkend="table.sl-seqlog"/>.
+ </para>
+ </listitem>
-<listitem><para> Vérifications des transactions longues</para>
+ <listitem>
+ <para>
+ Vérifications des transactions longues.
+ </para>
-<para> Ceci ne fonctionne correctement que si le collecteur de statistique
- est configuré pour collecter les requêtes, c'est à dire l'option
- <option> stats_command_string = true</option> est présente dans <filename>
-postgresql.conf </filename>.</para>
+ <para>
+ Ceci ne fonctionne correctement que si le collecteur de statistique est
+ configuré pour collecter les requêtes, c'est-à-dire l'option
+ <option>stats_command_string = true</option> est présente dans
+ <filename>postgresql.conf</filename>.
+ </para>
-<para> Si des bugs applicatifs conservent des connexions ouvertes, ce script devrait les trouver
-.</para>
+ <para>
+ Si des applications buggées conservent des connexions ouvertes, ce script
+ devrait les trouver.
+ </para>
-<para> Si des bugs applicatifs conservent des connexions ouvertes,
- plusieurs effets négatifs sont à prévoir
- tels que <link
-linkend="longtxnsareevil">ceux décrits dans la FAQ
-</link>.</para></listitem>
+ <para>
+ Si des applications buggées conservent des connexions ouvertes, plusieurs
+ effets négatifs sont à prévoir tels que <link
+ linkend="longtxnsareevil">ceux décrits dans la FAQ</link>.
+ </para>
+ </listitem>
+</itemizedlist>
-</itemizedlist></para>
+<para>
+ Ce script fait des diagnostiques basés sur des paramètres définis dans le
+ script ; si vous n'aimez pas les valeurs par défaut, modifiez-les !
+</para>
-<para> Ce script fait des diagnostiques basé sur des paramètres défini dans le script
- ; si vous n'aimez pas les valeurs par défaut, modifiez-les !</para>
-
</sect2>
-<sect2 id="search-logs"> <title> <command>search-logs.sh</command> </title>
+<sect2 id="search-logs">
+<title><command>search-logs.sh</command></title>
+<indexterm><primary>chercher dans les journaux applicatifs &slony1; avec search-logs.sh</primary></indexterm>
-<indexterm><primary> Chercher les logs &slony1; avec search-logs.sh </primary></indexterm>
+<para>
+ Ce script est construit pour chercher dans les journaux applicatifs &slony1;,
+ à un emplacement donné (<envar>LOGHOME</envar>), en se basant à la fois
+ sur les conventions de nommage utilisées par les systèmes <xref
+ linkend="launchclusters"/> et <xref linkend="slonwatchdog"/> lors du
+ démarrage des processus &lslon;.
+</para>
-<para> Ce script est construit pour chercher les fichiers de trace &slony1;
- dans un emplacement donné (<envar>LOGHOME</envar>), en se basant à la fois
- sur les conventions de nommage utilisées par les systèmes
- <xref linkend="launchclusters"/> et <xref linkend="slonwatchdog"/> lors du démarrage
- des processus &lslon;.</para>
+<para>
+ Si des erreurs sont trouvées, elles sont listées pour chaque fichier et
+ transmises par courriel à un utilisateur spécifié
+ (<envar>LOGRECIPIENT</envar>) ; si aucun courriel n'est spécifié, le
+ résultat est affiché sur la sortie standard.
+</para>
-<para> Si des erreurs sont trouvées, elles sont listées pour chaque fichiers
- et transmises par courriel à un utilisateur spécifié (<envar>LOGRECIPIENT</envar>);
- si aucune adresse courriel n'est spécifiée, le résultat est affiché sur la sortie standard
- . </para>
+<para>
+ <envar>LOGTIMESTAMP</envar> permet de rechercher à partir de cette (plutôt
+ sur la dernière heure).
+</para>
-<para> <envar>LOGTIMESTAMP</envar> permet de surcharger quelle heure doit être évaluée
- (plutôt que la dernière heure). </para>
+<para>
+ Un administrateur peut exécuter ce script une fois par heure pour surveiller
+ les problèmes de réplication.
+</para>
-<para> Un administrateur peut exécuter ce script une fois par heure
- pour surveiller les problèmes de réplication.
-</para>
</sect2>
-<sect2 id="wikigen"> <title>Produire un rapport de surveillance au format MediaWiki</title>
+<sect2 id="wikigen">
+<title>Produire un rapport de surveillance au format MediaWiki</title>
+<indexterm><primary>générer la documentation Wiki d'un cluster</primary></indexterm>
-<indexterm><primary> générer la documentation Wiki d'un cluster </primary></indexterm>
-
-<para>Le script <filename>mkmediawiki.pl </filename>, situé dans
+<para>
+ Le script <filename>mkmediawiki.pl </filename>, situé dans
<filename>tools</filename>, peut être utilisé pour générer un rapport de
- surveillance du cluster compatible avec le logiciel populaire
- <ulink url="http://www.mediawiki.org/">MediaWiki </ulink>.
- Notons que l'option <option>--categories</option> permet à l'utilisateur
- de préciser un ensemble de catégories (séparées par une virgule) qui seront
- associées aux résultats. Si vous avez une série de clusters &slony1;
- passer l'option <option>--categories=slony1</option> entraînera la création
- d'une page catégorie répertoriant l'ensemble des clusters &slony1;. </para>
+ surveillance du cluster compatible avec le populaire logiciel <ulink
+ url="http://www.mediawiki.org/">MediaWiki</ulink>. Notons que l'option
+ <option>--categories</option> permet à l'utilisateur de préciser un ensemble
+ de catégories (séparées par une virgule) qui seront associées aux résultats.
+ Si vous avez passer l'option <option>--categories=slony1</option> à une série
+ de clusters &slony1;, cela entraînera la création d'une page catégorie
+ répertoriant l'ensemble des clusters &slony1;.
+</para>
-<para>On pourra utiliser le commande ainsi: </para>
+<para>
+ On pourra utiliser le commande ainsi :
+</para>
<screen>
~/logtail.en> mvs login -d mywiki.example.info -u "Chris Browne" -p `cat ~/.wikipass` -w wiki/index.php
@@ -251,11 +336,14 @@
Doing commit Slony_replication.wiki with host: logtail and lang: en
</screen>
-<para> Notons que <command>mvs</command> est un client Mediawiki écrit en Perl;
-sur <ulink url="http://www.debian.org/"> Debian GNU/Linux</ulink>, le paquet
-associé est nommé
-<application>libwww-mediawiki-client-perl</application>; d'autres systèmes
-dispose probablement d'une version packagée sous un nom similaire. </para>
+<para>
+ Notons que <command>mvs</command> est un client Mediawiki écrit en Perl ;
+ sur <ulink url="http://www.debian.org/">Debian GNU/Linux</ulink>, le paquet
+ associé est nommé <application>libwww-mediawiki-client-perl</application> ;
+ d'autres systèmes disposent probablement d'une version packagée sous un nom
+ similaire.
+</para>
</sect2>
+
</sect1>
Modified: traduc/trunk/slony/slonyupgrade.xml
===================================================================
--- traduc/trunk/slony/slonyupgrade.xml 2009-01-19 21:20:59 UTC (rev 1221)
+++ traduc/trunk/slony/slonyupgrade.xml 2009-01-19 21:21:45 UTC (rev 1222)
@@ -5,254 +5,377 @@
révision $Revision$ -->
<sect1 id="slonyupgrade">
-<title> Mise à jour de &slony1;</title>
-<indexterm><primary>Remplacer &slony1; par une nouvelle version</primary></indexterm>
+<title>Mise à jour de &slony1;</title>
+<indexterm><primary>remplacer &slony1; par une nouvelle version</primary></indexterm>
-<para>Lorsque l'on met à jour &slony1;, chaque noeud du cluster doit être mis à jour simultanément, en utilisant
- la commande &lslonik; <xref linkend="stmtupdatefunctions"/>.</para>
+<para>
+ Lorsqu'on met à jour &slony1;, chaque nœud du cluster doit être mis à
+ jour simultanément, en utilisant la commande <xref
+ linkend="stmtupdatefunctions"/> de &lslonik;.
+</para>
-<para> Cela nécessite un arrêt temporaire de la réplication, mais cela n'implique pas obligatoirement une
- coupure de service au niveau des applications qui utilisent le cluster. </para>
+<para>
+ Cela nécessite un arrêt temporaire de la réplication, mais cela n'implique
+ pas obligatoirement une coupure de service au niveau des applications qui
+ utilisent le cluster.
+</para>
-<para>La procédure correcte est la suivante :</para>
+<para>
+ La procédure correcte est la suivante :
+</para>
+
<itemizedlist>
-<listitem>
- <para> Arrêtez les processus &lslon; sur chaque noeud.
- (<emphasis>c.a.d</emphasis> l'ancienne version de &lslon;)
- </para>
-</listitem>
-<listitem><para> Installez la nouvelle version du logiciel &lslon; sur tous les noeuds.</para></listitem>
-<listitem>
- <para> Exécutez un script &lslonik; contenant la commande
- <command>update functions (id = [valeur]);</command> pour chaque noeud du cluster.
- </para>
- <note>
- <para>Souvenez-vous que le script de mise à jour, comme tous les scripts &slonik; doit contenir
- les fonctions adéquates pour fonctionner.
- </para>
- </note>
-</listitem>
-<listitem><para> Démarrez tous les slons. </para> </listitem>
+ <listitem>
+ <para>
+ Arrêtez les processus &lslon; sur chaque nœud
+ (<emphasis>c'est-à-dire</emphasis> l'ancienne version de &lslon;).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Installez la nouvelle version du logiciel &lslon; sur tous les
+ nœuds.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Exécutez un script &lslonik; contenant la commande
+ <command>update functions (id = [valeur]);</command> pour chaque
+ nœud du cluster.
+ </para>
+
+ <note>
+ <para>
+ Souvenez-vous que le script de mise à jour, comme tous les scripts
+ &slonik; doit contenir les fonctions adéquates pour fonctionner.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <para>
+ Démarrez tous les démons slons.
+ </para>
+ </listitem>
</itemizedlist>
-<para>Toute cette opération est relativement sûre : s'il y a une incohérence
-entre les versions des composants, le &lslon; refusera de démarrer, ce
-qui consitue une protection contre les corruption.
- </para>
+<para>
+ Toute cette opération est relativement sûre : s'il y a une incohérence
+ entre les versions des composants, le &lslon; refusera de démarrer, ce qui
+ constitue une protection contre les corruptions.
+</para>
-<para>Vous devez vous assurer que la librairie C contenant les fonctions
- trigger SPI ont été copié à la bonne place dans lors de la compilation
- de &postgres;. Il existe de multiples approches pour cela :</para>
+<para>
+ Vous devez vous assurer que la bibliothèque C contenant les fonctions trigger
+ SPI ont été copiées à la bonne place lors de la compilation de &postgres;. Il
+ existe de multiples approches pour cela :
+</para>
-<para>La partie la plus compliquée consiste à s'assurer que la librairie C
- contenant les fonctions SPI est copié au bon endroit lors de la compilation
- de &postgres;; la manière la plus simple et la plus sûre de faire cela consiste
- à avoir deux versions compilées de &postgres;, une pour chaque version de &slony1;
- puis d'éteindre le serveur et le relancer avec la <quote>nouvelle</quote> version compilée;
- cette approche implique une courte coupure de service sur chaque noeud.</para>
+<para>
+ La partie la plus compliquée consiste à s'assurer que la bibliothèque C
+ contenant les fonctions SPI est copiée au bon endroit lors de la compilation
+ de &postgres; ; la manière la plus simple et la plus sûre de faire cela
+ consiste à avoir deux versions compilées de &postgres;, une pour chaque
+ version de &slony1;, puis d'éteindre le serveur et de le relancer avec la
+ <quote>nouvelle</quote> version compilée ; cette approche implique une
+ courte coupure de service sur chaque nœud.
+</para>
-<para>Si cette approche est réputée plus simple et plus rapide,
- rien ne vous empêche de mettre en place avec précaution les composants &slony1;
- pour écraser l'ancienne version comme décrit dans l'étape d'installation.
- Ceci ne fonctionnera <emphasis>pas</emphasis> sous Windows si Windows pose un verrou
- sur les fichiers qui sont utilisés.</para>
+<para>
+ Si cette approche est réputée plus simple et plus rapide, rien ne vous
+ empêche de mettre en place avec précaution les composants &slony1; pour
+ écraser l'ancienne version comme décrit dans l'étape d'installation. Ceci
+ peut ne <emphasis>pas</emphasis> fonctionner sous Windows si Windows pose un
+ verrou sur les fichiers qui sont utilisés.
+</para>
<variablelist>
-
-<varlistentry><term>Exécuter <command>make install</command> pour installer les nouveaux
+ <varlistentry>
+ <term>Exécuter <command>make install</command> pour installer les nouveaux
composants &slony1; au dessus des anciens.</term>
-<listitem><para>Si vous compiler &slony1; sur le système sur où il sera
- déployé et que vous compiler à partir des sources, écraser l'ancienne
- version avec la nouvelle se fait simplement avec <command>make install</command>.
- Il n'est pas nécessaire de relancer la base de donnée, il faut juste arrêter les
- processus &slony1;, exécuter le script <command>UPDATE FUNCTIONS</command> et démarrer
- les nouveaux processus &lslon;.</para>
+ <listitem>
+ <para>
+ Si vous compilez &slony1; sur le système sur où il sera déployé et
+ que vous compilez à partir des sources, écraser l'ancienne version avec
+ la nouvelle se fait simplement avec <command>make install</command>.
+ Il n'est pas nécessaire de relancer la base de donnée, il faut juste
+ arrêter les processus &slony1;, exécuter le script <command>UPDATE
+ FUNCTIONS</command> et démarrer les nouveaux processus &lslon;.
+ </para>
-<para>Malheureusement cette approche nécessite un environnement de
- compilation sur le serveur où la mise à jour sera déployée.
- Ceci n'est pas forcément compatible avec la volonté d'utiliser
- des binaires commun à &postgres; et &slony1; sur l'ensemble des noeuds.
-</para>
-</listitem></varlistentry>
+ <para>
+ Malheureusement, cette approche nécessite un environnement de
+ compilation sur le serveur où la mise à jour sera déployée. Ceci n'est
+ pas forcément compatible avec la volonté d'utiliser des binaires
+ communs à &postgres; et &slony1; sur l'ensemble des nœuds.
+ </para>
+ </listitem>
+ </varlistentry>
-<varlistentry><term>Compiler à nouveau &postgres; et &slony1;</term>
+ <varlistentry>
+ <term>Compiler à nouveau &postgres; et &slony1;</term>
-<listitem><para>Avec cette approche, l'ancienne version de &postgres; accompagnée des
- anciens composants &slony1; sont conservés après la bascule vers une nouvelle
- version &postgres; accompagnée des nouveaux composants &slony1;. Afin de bascule
- vers la nouvelle version de &slony1; vous devez redémarrer le
- serveur <command>postmaster</command> &postgres;, ce qui implique l'interruption des
- applications. afin que le serveur soit informé de l'emplacement des nouveaux composants.
- </para></listitem></varlistentry>
-
+ <listitem>
+ <para>
+ Avec cette approche, l'ancienne version de &postgres; accompagnée des
+ anciens composants &slony1; est conservée après la bascule vers une
+ nouvelle version de &postgres; accompagnée des nouveaux composants
+ &slony1;. Afin de basculer vers la nouvelle version de &slony1;, vous
+ devez redémarrer le serveur <command>postmaster</command>, ce qui
+ implique l'interruption des applications. afin que le serveur soit
+ informé de l'emplacement des nouveaux composants.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
-<sect2> <title> Problème avec TABLE ADD KEY dans &slony1; 2.0 </title>
+<sect2>
+<title>Problème avec TABLE ADD KEY dans &slony1; 2.0</title>
-<para> Généralement, les mises à jour de versions &slony1; ne nécessitent
- pas de porter une attention particulière au réplicat existant. C'est à dire
- que vous pouvez simplement arrêter les &slon;s, mettre en place les binaires,
- lancer <xref linkend="stmtupdatefunctions"/> sur chaque noeud et redémarrer &lslon;s.
- Les modifications de schéma étant internes au schéma du cluster, <xref linkend="stmtupdatefunctions"/>
- est capable de réaliser toutes les altérations. Avec la version 2, cela change si il existe des
- tables qui utilisaient <xref linkend="stmttableaddkey"/>. La version 2 ne supporte pas la colonne
- <quote>extra</quote>, et <quote>réparer</quote> le schéma pour obtenir une clé primaire correcte
- n'est pas dans les attributions de <xref linkend="stmtupdatefunctions"/>.</para>
+<para>
+ Généralement, les mises à jour de versions &slony1; ne nécessitent pas de
+ porter une attention particulière au réplicat existant, c'est-à-dire que vous
+ pouvez simplement arrêter les &slon;s, mettre en place les binaires, lancer
+ <xref linkend="stmtupdatefunctions"/> sur chaque nœud et redémarrer
+ &lslon;. Les modifications de schéma étant uniquement sur le schéma du cluster,
+ <xref linkend="stmtupdatefunctions"/> est capable de réaliser toutes les
+ altérations. Avec la version 2, cela change s'il existe des tables qui
+ utilisaient <xref linkend="stmttableaddkey"/>. La version 2 ne supporte pas
+ la colonne <quote>extra</quote>, et <quote>réparer</quote> le schéma pour
+ obtenir une clé primaire correcte n'est pas dans les attributions de <xref
+ linkend="stmtupdatefunctions"/>.
+</para>
-<para> Lorsque que l'on met à jour depuis une version 1.0.x, 1.1.x ou 1.2.x vers une version
- 2, il est nécessaire de supprimer toute clé primaire gérée par &slony1;.</para>
+<para>
+ Lorsque qu'on met à jour depuis une version 1.0.x, 1.1.x ou 1.2.x vers une
+ version 2, il est nécessaire de supprimer toute clé primaire gérée par
+ &slony1;.
+</para>
-<para>On peut identifier les tables concernées avec la requête SQL suivantes :
- <command> SELECT n.nspname, c.relname FROM pg_class c,
+<para>
+ On peut identifier les tables concernées avec la requête SQL suivante :
+
+ <command>SELECT n.nspname, c.relname FROM pg_class c,
pg_namespace n WHERE c.oid in (SELECT attrelid FROM pg_attribute WHERE
attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype &lt&gt 0
-and n.oid = c.relnamespace order by n.nspname, c.relname; </command>
+and n.oid = c.relnamespace order by n.nspname, c.relname;</command>
+
</para>
-<para> L'approche la plus simple pour rectifier l'état de ces tables est la suivante : </para>
+<para>
+ L'approche la plus simple pour rectifier l'état de ces tables est la
+ suivante :
+</para>
<itemizedlist>
-<listitem><para> Retirer la table de la réplication avec la commande &lslonik;
-<xref linkend="stmtsetdroptable"/>. </para>
+ <listitem>
+ <para>
+ Retirer la table de la réplication avec la commande &lslonik;
+ <xref linkend="stmtsetdroptable"/>
+ </para>
-<para> Ceci ne supprime <emphasis>pas</emphasis> les colonnes créées par
-&slony1;. </para>
-</listitem>
+ <para>
+ Ceci ne supprime <emphasis>pas</emphasis> les colonnes créées par
+ &slony1;.
+ </para>
+ </listitem>
-<listitem><para> Sur chaque noeud, exécutez un script SQL pour modifier
- la table et supprimer les colonnes additionnelles.</para> <para>
- <command> alter table
-nom_table drop column "_Slony-I_cluster-rowID";</command> </para>
+ <listitem>
+ <para>
+ Sur chaque nœud, exécutez un script SQL pour modifier la table et
+ supprimez les colonnes additionnelles.
+ </para>
+
+ <para>
+ <command>ALTER TABLE nom_table DROP COLUMN "_Slony-I_cluster-rowID";</command>
+ </para>
-<para>Ceci doit être exécuté sur chaque noeud. Selon votre préférence, vous pouvez utiliser
- <xref linkend="stmtddlscript"/> pour cela.</para>
+ <para>
+ Ceci doit être exécuté sur chaque nœud. Selon votre préférence,
+ vous pouvez utiliser <xref linkend="stmtddlscript"/> pour cela.
+ </para>
+ <para>
+ Si la table est une table massivement mise à jour, sachez que cette
+ modification posera un verrou exclusif sur la table. Elle ne détiendra
+ pas ce verrou très longtemps ; supprimer une colonne est une
+ opération assez rapide car cela se contente de marquer la colonne comme
+ supprimée. Cela ne nécessite <emphasis>pas</emphasis> de réécrire toute
+ la table. Les lignes qui ont une valeur dans cette colonne continueront à
+ avoir cette valeur. Pour les nouvelles lignes, la valeur sera NULL, et
+ les requêtes ignoreront cette colonne. L'espace occupé par ces colonnes
+ sera récupéré lorsque les lignes seront mises à jour.
+ </para>
-<para>Si la table est une table massivement mise à jour, sachez que cette modification
- posera un verrou exclusif sur la table. Elle ne détiendra pas ce verrou très longtemps;
- supprimer une colonne est une opération assez rapide car cela ce contente de marquer
- la colonne comme supprimée. Cela ne nécessite <emphasis>pas</emphasis> de réécrire tout le
- contenu de la table. Les tuples qui ont une valeur dans cette colonne continueront à
- avoir cette valeur. Pour les nouveaux tuples le valeur sera NULL, et les requêtes ignorerons
- cette colonne. L'espace occupé par ces colonnes sera récupéré lorsque les tuples
- sera mis à jour. </para>
+ <para>
+ Notez qu'à cette étape de la procédure, cette table n'est pas répliquée.
+ Si une erreur a lieu, la réplication à cet instant n'apporte aucune
+ protection sur cette table. C'est dommage mais inévitable.
+ </para>
+ </listitem>
-<para>Notez qu'à cette étape de la procédure, cette table n'est pas répliquée.
- Si une erreur a lieu, la réplication à cet instant n'apporte aucune protection.
- sur cette table. C'est dommage mais inévitable.</para>
-</listitem>
+ <listitem>
+ <para>
+ Assurez-vous que la table possède un candidat éligible pour une clé
+ primaire, c'est-à-dire un ensemble de colonnes NOT NULL et UNIQUE.
+ </para>
-<listitem><para>Assurez-vous que la table possède un candidat éligible
- pour une clé primaire, c'est à dire un ensemble de colonnes NOT NULL et UNIQUE.</para>
+ <para>
+ Les différents cas possibles font que les développeurs n'ont pas fait
+ d'efforts pour automatiser cette procédure.
+ </para>
-<para>Les différents cas possibles font que les développeurs
- n'ont pas fait d'efforts pour automatiser cette procédure.</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Si la table est petite, il peut être parfaitement raisonnable
+ d'ajouter une nouvelle colonne (notez que cela doit être fait sur
+ <emphasis>chaque nœud</emphasis> !), lui assigner une
+ une nouvelle séquence et la déclarer comme clé primaire.
+ </para>
-<itemizedlist>
+ <para>
+ S'il n'y a que quelques lignes, cela ne prend qu'une fraction de
+ seconde et avec de la chance, cela n'aura pas d'impact sur
+ l'application.
+ </para>
-<listitem><para> Si la table est petite, il peut être parfaitement
- raisonnable d'ajouter une nouvelle colonne (notez que cela doit
- être fait sur <emphasis>chaque noeud</emphasis> ! ), lui assigner
- une nouvelle séquence et la déclarer comme clé primaire. </para>
+ <para>
+ Même si la table est relativement large, alors qu'elle n'est pas
+ accédée fréquemment par l'application, alors le verrouillage de la
+ table provoqué par <command>ALTER TABLE</command> n'entraînera pas
+ d'inconvénients.
+ </para>
+ </listitem>
-<para>Si il n'y a que quelques tuples, cela ne prendre qu'une fraction de seconde et
- avec de la chance, cela n'aura pas d'impact sur l'application.</para>
+ <listitem>
+ <para>
+ Si la table est large, qu'elle est vitale et fortement utilisée par
+ l'application, alors il peut être nécessaire de prévoir une coupure
+ de service de l'application afin d'accomplir les modifications, ce
+ qui vous laissera un peu vulnérable tant que la procédure ne sera pas
+ complétée.
+ </para>
-<para>Même si la table est relativement large, mais qu'elle n'est pas
- accédée fréquemment par l'application, alors le verrouillage de la table
- provoqué par <command>ALTER TABLE</command> n'entraînera pas d'inconvénients.
-</para></listitem>
+ <para>
+ Si une coupure de service est problématique, alors la mise à jour
+ vers &slony1; version 2 devra être planifiée avec soin...
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
-<listitem> <para>Si la table est large, qu'elle est vitale et fortement utilisée
- par l'application, alors il peut être nécessaire de prévoir une coupure
- de service de l'application afin d'accomplir les modifications, ce qui
- vous laissera un peu vulnérable tant que la procédure ne sera pas complétée.
+ <listitem>
+ <para>
+ Créez un nouvel ensemble de réplication (<xref linkend="stmtcreateset"/>
+ et ajoutez à nouveau la table dans cet ensemble (<xref
+ linkend="stmtsetaddtable"/>).
</para>
-<para>Si une coupure de service est problématique, alors la mise à jour vers
- &slony1; version 2 devra être planifiée avec soin...</para>
-</listitem>
+ <para>
+ S'il existe plusieurs tables, elles peuvent être gérées via un ensemble
+ de réplication unique.
+ </para>
+ </listitem>
-</itemizedlist>
-</listitem>
+ <listitem>
+ <para>
+ Abonnez l'ensemble de réplication (<xref linkend="stmtsubscribeset"/>)
+ pour tous les nœuds désirés.
+ </para>
+ </listitem>
-<listitem><para>Créez un nouvel ensemble de réplication (<xref
-linkend="stmtcreateset"/> et ajouter à nouveau la table
- dans cet ensemble (<xref
-linkend="stmtsetaddtable"/>). </para>
-
-
-<para>Si il existe plusieurs tables, elles peuvent être gérées via
- un ensemble de réplication unique.</para>
-</listitem>
-
-<listitem><para>Abonnez l'ensemble de réplication (<xref linkend="stmtsubscribeset"/>)
-sur tous les noeuds désirés. </para> </listitem>
-
-<listitem><para>Une fois que l'abonnement est complété, fusionnez les ensembles de réplications
- si nécessaire (<xref linkend="stmtmergeset"/>). </para> </listitem>
-
+ <listitem>
+ <para>
+ Une fois que l'abonnement est complété, fusionnez les ensembles de
+ réplications si nécessaire (<xref linkend="stmtmergeset"/>).
+ </para>
+ </listitem>
</itemizedlist>
-<para>Cette approche devrait fonctionner pour les tables qui sont
- relativement petites, ou rarement utilisées. D'autre part, si la table
- est large et massivement utilisée, une autre approche pourrait être nécessaire,
- c'est à dire créer votre propre séquence, et <quote>promouvoir</quote> l'ancienne
- colonne générée par &slony1; dans une colonne <quote>réelle</quote> au sein
- du schéma de votre base de données. Les grandes lignes de cette procédure sont
- les suivantes :
- </para>
+<para>
+ Cette approche devrait fonctionner pour les tables qui sont relativement
+ petites ou rarement utilisées. D'autre part, si la table est large et
+ massivement utilisée, une autre approche pourrait être nécessaire,
+ c'est-à-dire créer votre propre séquence, et <quote>promouvoir</quote>
+ l'ancienne colonne générée par &slony1; dans une colonne <quote>réelle</quote>
+ au sein du schéma de votre base de données. Les grandes lignes de cette
+ procédure sont les suivantes :
+</para>
<itemizedlist>
+ <listitem>
+ <para>
+ Ajouter une séquence qui assigne des valeurs à la colonne.
+ </para>
-<listitem><para>Ajouter une séquence qui assigne des valeurs à la colonne.</para>
+ <para>
+ Les étapes d'installation incluent les commandes SQL <command>CREATE
+ SEQUENCE</command>, <command>SELECT SETVAL()</command> (pour définir
+ une valeur de séquence assez haute pour refléter les valeurs utilisées
+ dans la table), le <xref linkend="stmtcreateset"/> de Slonik (pour créer
+ un ensemble de réplication dans lequel on placera la séquence), le
+ <xref linkend="stmtsetaddsequence"/> de Slonik (pour placer la séquence
+ dans l'ensemble de réplication), le <xref linkend="stmtsubscribeset"/>
+ de Slonik (pour définir les abonnements de ce nouvel ensemble de
+ réplication).
+ </para>
+ </listitem>
-<para>Les étapes d'installation incluent les commandes SQL <command>CREATE
-SEQUENCE</command>, SQL <command>SELECT SETVAL()</command> ( pour définir une valeur
-de séquence assez haute pour refléter les valeurs utilisées dans la table), Slonik <xref linkend="stmtcreateset"/>
-( pour créer un ensemble de réplication dans lequel on placera la séquence ),
- Slonik <xref linkend="stmtsetaddsequence"/> ( pour placer la séquence dans l'ensemble de réplication),
- Slonik <xref linkend="stmtsubscribeset"/> ( pour définir les abonnements de ce nouvel
- ensemble de réplication )</para>
-</listitem>
+ <listitem>
+ <para>
+ Attachez la séquence à la colonne dans la table.
+ </para>
-<listitem><para>Attachez la séquence à la colonne dans la table. </para>
+ <para>
+ Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
+ qui doivent être exécutées via la commande Slonik <xref
+ linkend="stmtddlscript"/>.
+ </para>
+ </listitem>
-<para> Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
-qui doivent être exécutées via la commande Slonik <xref
-linkend="stmtddlscript"/>. </para>
-</listitem>
+ <listitem>
+ <para>
+ Renommez la colonne <envar>_Slony-I_ at CLUSTERNAME@_rowID</envar> afin que
+ &slony1; ne considère pas qu'elle est sous son contrôle.
+ </para>
-<listitem><para> Renommez la colonne
-<envar>_Slony-I_ at CLUSTERNAME@_rowID</envar> afin que &slony1; ne considère
-pas qu'elle est sous son contrôle.</para>
+ <para>
+ Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
+ qui doivent être exécutées via la commande Slonik <xref
+ linkend="stmtddlscript"/>.
+ </para>
-<para> Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
-qui doivent être exécutées via la commande Slonik <xref
-linkend="stmtddlscript"/>. </para>
-
-
-<para>Notez que ces deux modifications peuvent être accomplies au sein
- d'une requête <xref linkend="stmtddlscript"/> unique. </para>
-</listitem>
-
+ <para>
+ Notez que ces deux modifications peuvent être accomplies au sein d'une
+ requête <xref linkend="stmtddlscript"/> unique.
+ </para>
+ </listitem>
</itemizedlist>
</sect2>
-<sect2> <title> Nouvelle gestion des triggers dans &slony1; Version 2 </title>
+<sect2>
+<title>Nouvelle gestion des triggers dans &slony1; Version 2</title>
-<para> Un des changement majeurs de &slony1; est que l'activation et la désactivation
- des triggers et règles ("rules") se fait maintenant entièrement en SQL, supporté
- par &postgres; 8.3+, plutôt que via des modifications directes dans le catalogue
- système. </para>
+<para>
+ Un des changements majeurs de &slony1; est que l'activation et la
+ désactivation des triggers et règles (« rules ») se fait
+ maintenant entièrement en SQL, supporté par &postgres; 8.3+, plutôt
+ que via des modifications directes dans le catalogue système.
+</para>
-<para>Cela implique que les utilisateurs de &slony1; doivent étudier la syntaxe &postgres; pour
-<command>ALTER TABLE</command>, car c'est ainsi qu'ils accompliront ce qu'ils accomplissait
-précédemment via les commandes <xref
-linkend="stmtstoretrigger"/> et <xref linkend="stmtdroptrigger"/>.
+<para>
+ Cela implique que les utilisateurs de &slony1; doivent étudier la syntaxe
+ &postgres; pour <command>ALTER TABLE</command> car c'est ainsi qu'ils
+ accompliront ce qu'ils accomplissait précédemment via les commandes <xref
+ linkend="stmtstoretrigger"/> et <xref linkend="stmtdroptrigger"/>.
</para>
+
</sect2>
+
</sect1>
Modified: traduc/trunk/slony/testbed.xml
===================================================================
--- traduc/trunk/slony/testbed.xml 2009-01-19 21:20:59 UTC (rev 1221)
+++ traduc/trunk/slony/testbed.xml 2009-01-19 21:21:45 UTC (rev 1222)
@@ -4,259 +4,425 @@
par $Author$
révision $Revision$ -->
-<sect1 id="testbed"><title>Banc d'essai &slony1; </title>
+<sect1 id="testbed">
+<title>Banc d'essai &slony1;</title>
+<indexterm><primary>plate-forme de tests</primary></indexterm>
- <indexterm><primary>plate-forme de tests</primary></indexterm>
+<para>
+ Jusqu'à la version 1.1.5, &slony1; dispose d'une plate-forme commune de tests
+ afin d'exécuter un ensemble compréhensible de tests de manière relativement
+ automatique. Les anciens tests étaient réalisés avec
+ <application>pgbench</application> (ce qui n'est pas une
+ <emphasis>mauvaise</emphasis> chose en soi) mais étaient difficiles à
+ automatiser car ils devaient être déployés sur chaque &lslon; dans un
+ <application>xterm</application> afin que l'utilisateur puisse
+ <emphasis>surveiller</emphasis>.
+</para>
- <para> Jusqu'à la version 1.1.5, &slony1; dispose d'une plate-forme
- commune de test afin d'exécuter un ensemble compréhensible de tests
- de manière relativement automatique. Les anciens tests étaient réalisés
- avec <application>pgbench</application> ( ce qui n'est pas une
- <emphasis>mauvaise</emphasis> chose en soi ) mais étaient difficiles
- à automatiser car ils devaient être déployés sur chaque &lslon;
- dans un <application>xterm</application> afin que l'utilisateur
- puisse <emphasis>surveiller</emphasis>.</para>
+<para>
+ La nouvelle plate-forme de test est principalement écrite en shell Bourne.
+ Elle est conçue pour être portable sous bash (largement répandu sous Linux)
+ et en Korn shell (que l'on retrouve souvent sur les systèmes UNIX
+ commerciaux). Le code se trouve dans l'arborescence des sources au sein du
+ répertoire <filename>tests</filename>.
+</para>
- <para> La nouvelle plate-forme de test est principalement écrite en Bourne shell,
- et est destinée à être portable en bash ( largement répandu sous Linux ) et
- en Korn shell ( que l'on retrouve souvent sur les systèmes UNIX commerciaux )
- Le code se trouve dans l'arborescence des sources au sein du répertoire
- <filename>tests</filename>.</para>
+<para>
+ À présent, presque tous les tests font appel à seulement deux bases de
+ données qui par défaut sont sur un postmaster &postgres; unique sur un seul
+ serveur hôte. Ceci est parfait pour les tests qui impliquent la vérification
+ des fonctions &slony1; pour divers types de données. Ces tests font des
+ choses tels que varier les styles de date, et créer des tables et des
+ séquences qui impliquent des noms inhabituels afin de vérifier que les
+ guillemets sont gérés correctement.
+</para>
- <para>À présent, presque tous les tests font appel à seulement deux
- bases de données qui par défaut sont sur un postmaster &postgres; unique
- sur un seul serveur hôte. Ceci est parfait pour les tests qui impliquent la
- vérification des fonctions &slony1; pour divers types de données.
- Ces tests font des choses tels que varier les styles de date, et créer des
- tables et des séquences qui implique des noms inhabituels afin de vérifier
- que les guillemets sont gérées correctement. </para>
+<para>
+ Il est également possible de configurer des variables d'environnement afin
+ que les nœuds de la réplication soient placés sur différents serveurs
+ de base de données, éventuellement sur des serveurs hôtes distants, utilisant
+ différentes versions de &postgres;.
+</para>
- <para> Il est également possible de configurer des variables d'environnement
- afin que les noeuds de la réplication soient placés sur différents serveurs
- de base de données, éventuellement sur des serveurs hôtes distants, utilisant
- différentes versions de &postgres;.</para>
+<para>
+ Voici quelques-uns des fichiers vitaux :
+</para>
- <para>Voici quelque uns des fichiers vitaux...</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ <filename>run_test.sh</filename>
+ </para>
+ </listitem>
+</itemizedlist>
-
- <itemizedlist>
- <listitem><para> <filename>run_test.sh</filename> </para></listitem>
- </itemizedlist>
- <para> Ceci est le script central pour exécuter les tests. Son utilisation
- typique est la suivante :</para>
+<para>
+ Ceci est le script central pour exécuter les tests. Son utilisation typique
+ est la suivante :
+</para>
- <para> <command> ./run_test.sh </command></para>
- <screen>
- usage ./run_test.sh nom_du_test
- </screen>
+<para>
+ <command>./run_test.sh</command>
+</para>
- <para> Vous devez spécifier le nom de sous-répertoire pour dans lequel
- l'ensemble du test sera réalisé; chaque ensemble est stocké un dans
- sous-répertoire de <filename>tests</filename>.</para>
+<screen>
+usage ./run_test.sh nom_du_test
+</screen>
- <para> Vous pouvez définir une ou plusieurs variables d'environnement
- pour préciser votre configuration locale. Par exemple, on
- exécute <quote>test1</quote> sur &postgres; 8.0.x en utilisant la commande
- suivante :</para>
+<para>
+ Vous devez spécifier le nom du sous-répertoire dans lequel l'ensemble du test
+ sera réalisé ; chaque ensemble est stocké dans un sous-répertoire de
+ <filename>tests</filename>.
+</para>
- <screen> PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1 </screen>
+<para>
+ Vous pouvez définir une ou plusieurs variables d'environnement pour préciser
+ votre configuration locale. Par exemple, on exécute <quote>test1</quote> sur
+ &postgres; 8.0.x en utilisant la commande suivante :
+</para>
- <glosslist>
- <glossentry>
- <glossterm> <envar>PGBINDIR</envar> </glossterm>
+<screen>PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1</screen>
- <glossdef><para> Ceci détermine où les scripts de tests doivent chercher
- les binaires &postgres; et &slony1;. La valeur par défaut est
- <filename>/usr/local/pgsql/bin</filename>.</para>
+<glosslist>
+ <glossentry>
+ <glossterm><envar>PGBINDIR</envar></glossterm>
- <para> Il existe également les variables <envar>PGBINDIR1</envar> jusqu'à
- <envar>PGBINDIR13</envar> qui permettent de définir un chemin spécifique
- pour chaque instance de base de données. Cela est particulièrement utile
- lorsque l'on teste l'inter-opérabilité de &slony1; sur différent versions
- de &postgres; et sur différentes plates-formes. Afin de créer une base de
- données de chaque version respective, vous devez pointer vers un
- <application>initdb</application> de la version appropriée.</para></glossdef>
- </glossentry>
+ <glossdef>
+ <para>
+ Ceci détermine où les scripts de tests doivent chercher les binaires
+ &postgres; et &slony1;. La valeur par défaut est
+ <filename>/usr/local/pgsql/bin</filename>.
+ </para>
- <glossentry><glossterm> <envar>PGPORT</envar> </glossterm>
- <glossdef><para> Ceci indique quel port le processus postmater écoute.
- Par défaut, le port 5432 est utilisé. </para>
+ <para>
+ Il existe également les variables <envar>PGBINDIR1</envar> jusqu'à
+ <envar>PGBINDIR13</envar> qui permettent de définir un chemin spécifique
+ pour chaque instance de base de données. C'est particulièrement utile
+ lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes versions
+ de &postgres; et sur différentes plates-formes. Afin de créer une base de
+ données de chaque version respective, vous devez pointer vers un
+ <application>initdb</application> de la version appropriée.
+ </para>
+ </glossdef>
+ </glossentry>
- <para> Il existe également des variables <envar>PORT1</envar> jusqu'à
- <envar>PORT13</envar> qui permet de spécifier un numéro de port pour
- chaque instance de base de données. Cela sera particulièrement utile
- lorsque que l'on teste l'inter-opérabilité de &slony1; sur différentes
- versions de &postgres;. </para> </glossdef> </glossentry>
+ <glossentry>
+ <glossterm><envar>PGPORT</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Ceci indique sur quel port le processus postmaster écoute. Par défaut,
+ le port 5432 est utilisé.
+ </para>
- <glossentry><glossterm> <envar>PGUSER</envar> </glossterm>
- <glossdef><para> Par défaut, l'utilisateur <filename>postgres</filename>
- est utilisé; Ceci est utilisé comme l'identifiant par défaut à utiliser
- sur toutes les bases de données. </para>
+ <para>
+ Il existe également des variables <envar>PORT1</envar> jusqu'à
+ <envar>PORT13</envar> qui permettent de spécifier un numéro de port
+ pour chaque instance de base de données. Cela sera particulièrement
+ utile lorsqu'on teste l'inter-opérabilité de &slony1; sur différentes
+ versions de &postgres;.
+ </para>
+ </glossdef>
+ </glossentry>
- <para> Il existent également des variables <envar>USER1</envar> jusqu'à
- <envar>USER13</envar> qui permettent de spécifier un nom d'utilisateur
- différent pour chaque instance. Comme toujours, avec &slony1;, l'utilisateur
- doit être un <quote>super-utilisateur</quote> &postgres; </para>
- </glossdef> </glossentry>
+ <glossentry>
+ <glossterm><envar>PGUSER</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, l'utilisateur <filename>postgres</filename> est
+ utilisé ; ceci est utilisé comme l'identifiant par défaut à
+ utiliser sur toutes les bases de données.
+ </para>
- <glossentry><glossterm> <envar>WEAKUSER</envar> </glossterm>
- <glossdef><para> Par défaut, l'utilisateur <filename>postgres</filename>
- est utilisé; Ceci est utilisé par défaut comme identifiant de l'utilisateur
- pour les connexions <xref linkend="stmtstorepath"/> sur toutes
- les bases de données.</para>
+ <para>
+ Il existe également des variables <envar>USER1</envar> jusqu'à
+ <envar>USER13</envar> qui permettent de spécifier un nom d'utilisateur
+ différent pour chaque instance. Comme toujours avec &slony1;, l'utilisateur
+ doit être un <quote>super-utilisateur</quote> &postgres;.
+ </para>
+ </glossdef>
+ </glossentry>
- <para> Il existe également des variables <envar>WEAKUSER1</envar> jusqu'à
- <envar>WEAKUSER13</envar> qui permettent de spécifier différents noms
- d'utilisateur pour chaque instance. Cet utilisateur doit être un <quote>
- super-utilisateur</quote> &postgres;. Cet utilisateur peut démarrer sans
- permissions; il obtient les permissions de lecture sur les tables que le
- test utilise, ainsi que les droits d'accès sur le schéma &slony1;, et les
- droits d'écriture sur la table et la séquence utilisées pour gérer les verrous
- sur les noeuds.
- </para> </glossdef> </glossentry>
+ <glossentry>
+ <glossterm><envar>WEAKUSER</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, l'utilisateur <filename>postgres</filename> est
+ utilisé ; c'est utilisé par défaut comme l'identifiant de
+ l'utilisateur pour les connexions <xref linkend="stmtstorepath"/>
+ sur toutes les bases de données.
+ </para>
- <glossentry><glossterm> <envar>HOST</envar> </glossterm>
- <glossdef><para>Par défaut, <filename>localhost</filename> est utilisé.
- </para>
+ <para>
+ Il existe également des variables <envar>WEAKUSER1</envar> jusqu'à
+ <envar>WEAKUSER13</envar> qui permettent de spécifier différents noms
+ d'utilisateur pour chaque instance. Cet utilisateur doit être un
+ <quote>super-utilisateur</quote> &postgres;. Cet utilisateur peut
+ commencer sans droits ; il obtient les droits de lecture sur les
+ tables que le test utilise, ainsi que les droits d'accès sur le schéma
+ &slony1;, et les droits d'écriture sur la table et la séquence
+ utilisées pour gérer les verrous sur les nœuds.
+ </para>
+ </glossdef>
+ </glossentry>
- <para> Il existe également les variables <envar>HOST1</envar> jusqu'à
- <envar>HOST13</envar> qui permet de spécifier un hôte différent pour
- chaque instance de base de données.</para></glossdef>
- </glossentry>
+ <glossentry>
+ <glossterm><envar>HOST</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, <filename>localhost</filename> est utilisé.
+ </para>
- <glossentry><glossterm> <envar>DB1</envar> jusqu'à <envar>DB13 </envar> </glossterm>
+ <para>
+ Il existe également les variables <envar>HOST1</envar> jusqu'à
+ <envar>HOST13</envar> qui permettent de spécifier un hôte différent
+ pour chaque instance de base de données.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossdef><para> Par défaut, les valeurs<filename>slonyregress1</filename> jusqu'à
- <filename>slonyregress13</filename> sont utilisées.
+ <glossentry>
+ <glossterm><envar>DB1</envar> jusqu'à <envar>DB13</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Par défaut, les valeurs<filename>slonyregress1</filename> jusqu'à
+ <filename>slonyregress13</filename> sont utilisées.
</para>
- <para> Vous pouvez surcharger cela depuis l'environnement
- si vous avez de bonne raisons d'utiliser des bonnes d'utiliser
- des noms différents. </para></glossdef>
- </glossentry>
+ <para>
+ Vous pouvez surcharger cela depuis l'environnement si vous avez de
+ bonnes raisons d'utiliser des noms différents.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>ENCODING</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>ENCODING</envar></glossterm>
- <glossdef><para>Par défaut, <filename>UNICODE</filename> est utilisé, afin
- que les tests puissent créer des tables UTF8 et tester les
- capacités multibyte.
- </para></glossdef>
- </glossentry>
+ <glossdef>
+ <para>
+ Par défaut, <filename>UNICODE</filename> est utilisé, afin que les
+ tests puissent créer des tables UTF8 et tester les capacités multibyte.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>MY_MKTEMP_IS_DECREPIT</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>MY_MKTEMP_IS_DECREPIT</envar></glossterm>
- <glossdef><para> Si votre version de Linux utilise une version de
- <application>mktemp</application> qui ne génère pas un chemin absolu
- vers l'emplacement du fichier/répertoire temporaire, alors modifier cette
- valeur. </para></glossdef>
-
- </glossentry>
+ <glossdef>
+ <para>
+ Si votre version de Linux utilise une version de
+ <application>mktemp</application> qui ne génère pas un chemin absolu
+ vers l'emplacement du fichier/répertoire temporaire, alors modifiez
+ cette valeur.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>SLTOOLDIR</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>SLTOOLDIR</envar></glossterm>
- <glossdef><para> Où trouver les outils &slony1; tels que
- <application>slony1_dump.sh</application>. </para></glossdef>
-
- </glossentry>
+ <glossdef>
+ <para>
+ Emplacement des outils &slony1; tels que
+ <application>slony1_dump.sh</application>.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>ARCHIVE[n]</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>ARCHIVE[n]</envar></glossterm>
- <glossdef><para> Si cette option est positionnée à <quote>true</quote>, pour un noeud donné,
- qui est normalement configuré automatiquement dans le fichier
- <filename>settings.ik</filename>, alors ce noeud sera utilisé comme
- source de données pour du <xref linkend="logshipping"/>, et cela impliquera
- que les outils de tests créeront le répertoire
- <link linkend="slon-config-archive-dir"> archive_dir</link>
- </para></glossdef>
-
- </glossentry>
+ <glossdef>
+ <para>
+ Si cette option est positionnée à <quote>true</quote> pour un
+ nœud donné, qui est normalement configurée automatiquement dans
+ le fichier <filename>settings.ik</filename>, alors ce nœud sera
+ utilisé comme source de données pour du <xref linkend="logshipping"/>,
+ et cela impliquera que les outils de tests créeront le répertoire
+ <link linkend="slon-config-archive-dir">archive_dir</link>.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>LOGSHIP[n]</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>LOGSHIP[n]</envar></glossterm>
- <glossdef><para> Si cette option est positionnée à <quote>true</quote>, pour un noeud donné,
- qui est normalement configuré automatiquement dans le fichier
- <filename>settings.ik</filename>, alors ce noeud est créé via
- <xref linkend="logshipping"/>, et &lslon; n'est pas nécessaire pour ce noeud.
- </para></glossdef>
- </glossentry>
+ <glossdef>
+ <para>
+ Si cette option est positionnée à <quote>true</quote> pour un
+ nœud donné, qui est normalement configurée automatiquement dans
+ le fichier <filename>settings.ik</filename>, alors ce nœud est
+ créé via <xref linkend="logshipping"/>, et &lslon; n'est pas nécessaire
+ pour ce nœud.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>SLONCONF[n]</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>SLONCONF[n]</envar></glossterm>
- <glossdef><para>Si cette valeur est positionnée à <quote>true</quote>, pour un noeud donnée,
- qui est généralement configuré dans le fichier <filename>settings.ik</filename>
- pour un test donné, alors la configuration sera placée dans un <link linkend="runtime-config">
- un fichier de configuration <filename>slon.conf</filename>
- spécifique pour chaque noeud.</link> </para>
- </glossdef>
- </glossentry>
+ <glossdef>
+ <para>
+ Si cette valeur est positionnée à <quote>true</quote> pour un nœud
+ donnée qui est généralement configurée dans le fichier
+ <filename>settings.ik</filename> pour un test donné, alors la
+ <link linkend="runtime-config">configuration</link> sera placée dans un
+ un fichier de configuration <filename>slon.conf</filename> spécifique
+ pour chaque nœud.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>SLONYTESTER</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>SLONYTESTER</envar></glossterm>
- <glossdef><para> Adresse e-mail de la personne qui reçoit les résultats des tests.
- Ceci est stocké dans <envar>SLONYTESTFILE</envar>, et peut être agréger
- dans un registre comparable à une ferme de compilation
- </para> </glossdef>
- </glossentry>
+ <glossdef>
+ <para>
+ Adresse e-mail de la personne qui reçoit les résultats des tests.
+ Ceci est stocké dans <envar>SLONYTESTFILE</envar> et peut être agrégé
+ dans un registre comparable à une ferme de compilation.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><envar>SLONYTESTFILE</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>SLONYTESTFILE</envar></glossterm>
- <glossdef><para> Fichier dans lequel sont stocké les résultats des tests.
- Ces résultats peuvent être utilisés pour construire un dépôt contenant
- l'agrégation des résultats de test.
- </para> </glossdef>
- </glossentry>
+ <glossdef>
+ <para>
+ Fichier dans lequel sont stockés les résultats des tests. Ces résultats
+ peuvent être utilisés pour construire un dépôt contenant l'agrégation
+ des résultats de test.
+ </para>
+ </glossdef>
+ </glossentry>
- <glossentry>
- <glossterm><filename>random_number</filename> et <filename>random_string</filename> </glossterm>
+ <glossentry>
+ <glossterm>
+ <filename>random_number</filename> et <filename>random_string</filename>
+ </glossterm>
- <glossdef><para> Si vous exécuté <command>make</command> dans le répertoire de
- <filename>test</filename>, les programmes C
- <application>random_number</application> et
- <application>random_string</application> seront compilé et seront
- ensuite utilisé lors de la génération de données aléatoires au lieu d'utiliser
- les fonctions shell/SQL qui sont beaucoup plus lentes que les programmes C.
- </para>
- </glossdef>
- </glossentry>
- </glosslist>
+ <glossdef>
+ <para>
+ Si vous exécutez <command>make</command> dans le répertoire de
+ <filename>test</filename>, les programmes C
+ <application>random_number</application> et
+ <application>random_string</application> seront compilés et seront
+ ensuite utilisés lors de la génération de données aléatoires au lieu
+ d'utiliser les fonctions shell/SQL qui sont beaucoup plus lentes que
+ les programmes C.
+ </para>
+ </glossdef>
+ </glossentry>
+</glosslist>
- <para> Pour chaque test, vous trouverez les fichiers suivants : </para>
+<para>
+ Pour chaque test, vous trouverez les fichiers suivants :
+</para>
- <itemizedlist>
- <listitem><para> <filename>README</filename> </para>
- <para> Ce fichier contient une description du test et est affiché
- au lecteur lorsque le test est invoqué. </para>
- </listitem>
- <listitem><para> <filename>generate_dml.sh</filename> </para>
- <para> contient le code du script qui génère le SQL pour réaliser les mises à jour. </para> </listitem>
- <listitem><para> <filename>init_add_tables.ik</filename> </para>
- <para> Script <xref linkend="slonik"/> pour ajouter les tables pour le test de réplication. </para> </listitem>
- <listitem><para> <filename>init_cluster.ik</filename> </para>
- <para> Script <xref linkend="slonik"/> pour initialiser le cluster pour le test.</para> </listitem>
- <listitem><para> <filename>init_create_set.ik</filename> </para>
- <para> Script <xref linkend="slonik"/> pour initialiser les noeuds supplémentaires qui seront utilisés dans le test. </para> </listitem>
- <listitem><para> <filename>init_schema.sql</filename> </para>
- <para> Script SQL pour créer le stables et les séquences nécessaires au démarrage du test.</para> </listitem>
- <listitem><para> <filename>init_data.sql</filename> </para>
- <para> Script SQL pour initialiser le schéma dans l'état nécessaire sur le noeud<quote>maître</quote> node. </para> </listitem>
- <listitem><para> <filename>init_subscribe_set.ik</filename> </para>
- <para> Script <xref linkend="slonik"/> pour mettre en place les abonnements.</para> </listitem>
- <listitem><para> <filename>settings.ik</filename> </para>
- <para> Script shell utilisé pour contrôler la taille du cluster, comment les noeuds seront créés, et où se trouve l'origine.</para> </listitem>
- <listitem><para> <filename>schema.diff</filename> </para>
- <para> Série de requêtes SQL, une par ligne, qui sont utilisés pour valider que les données se correspondent sur tous les noeuds. Notez qu'afin d'éviter des échecs inutiles, les requêtes doivent utiliser des clauses <command>ORDER BY</command> non-ambigües.</para> </listitem>
- </itemizedlist>
+<itemizedlist>
+ <listitem>
+ <para><filename>README</filename></para>
+
+ <para>
+ Ce fichier contient une description du test et est affiché au lecteur
+ lorsque le test est invoqué.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>generate_dml.sh</filename></para>
+
+ <para>
+ Contient le code du script qui génère le SQL pour réaliser les mises à
+ jour.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_add_tables.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour ajouter les tables pour le test de
+ réplication.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_cluster.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour initialiser le cluster pour le test.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_create_set.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour initialiser les nœuds
+ supplémentaires qui seront utilisés dans le test.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_schema.sql</filename></para>
+
+ <para>
+ Script SQL pour créer les tables et les séquences nécessaires au démarrage
+ du test.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_data.sql</filename></para>
+
+ <para>
+ Script SQL pour initialiser le schéma dans l'état nécessaire sur le
+ nœud <quote>maître</quote>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>init_subscribe_set.ik</filename></para>
+
+ <para>
+ Script <xref linkend="slonik"/> pour mettre en place les abonnements.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>settings.ik</filename></para>
+
+ <para>
+ Script shell utilisé pour contrôler la taille du cluster, comment les
+ nœuds seront créés, et où se trouve l'origine.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>schema.diff</filename></para>
+
+ <para>
+ Série de requêtes SQL, une par ligne, qui sont utilisés pour valider que
+ les données se correspondent sur tous les nœuds. Notez qu'afin
+ d'éviter des échecs inutiles, les requêtes doivent utiliser des clauses
+ <command>ORDER BY</command> non-ambigües.
+ </para>
+ </listitem>
+</itemizedlist>
- <para> Pour d'éventuels tests additionnels, tels que l'utilisation de
- <xref linkend="stmtddlscript"/>,
- des scripts <xref linkend="slonik"/> et SQL supplémentaires pourront être nécessaires.
- </para>
+<para>
+ Pour d'éventuels tests additionnels, tels que l'utilisation de <xref
+ linkend="stmtddlscript"/>, des scripts <xref linkend="slonik"/> et SQL
+ supplémentaires pourront être nécessaires.
+</para>
+
</sect1>
Modified: traduc/trunk/slony/triggers.xml
===================================================================
--- traduc/trunk/slony/triggers.xml 2009-01-19 21:20:59 UTC (rev 1221)
+++ traduc/trunk/slony/triggers.xml 2009-01-19 21:21:45 UTC (rev 1222)
@@ -3,33 +3,40 @@
le $Date$
par $Author$
révision $Revision$ -->
+
<sect1 id="triggers">
- <title>Gestion des triggers &slony1;</title>
- <indexterm><primary>gestion des triggers</primary></indexterm>
+<title>Gestion des triggers &slony1;</title>
+<indexterm><primary>gestion des triggers</primary></indexterm>
- <para> &slony1; a connu deux <quote>types</quote> des gestion de triggers
- <itemizedlist>
- <listitem>
- <para> Jusqu'à la version 1.2, &postgres; n'avait pas conscience
- de la réplication, ce qui impliquait que &slony1; avait besoin que l'on
- <quote>modifie directement</quote> le catalogue système afin de
- désactiver, sur les noeuds abonnés, les triggers qui ne devaient pas être
- exécutés.</para>
+<para>
+ &slony1; a connu deux <quote>types</quote> de gestion pour les
+ triggers
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Jusqu'à la version 1.2, &postgres; n'avait pas conscience de la
+ réplication, ce qui impliquait que &slony1; avait besoin que l'on
+ <quote>modifie directement</quote> le catalogue système afin de
+ désactiver, sur les nœuds abonnés, les triggers qui ne devaient
+ pas être exécutés.</para>
- <para> Ceci provoquait un nombre d'effets secondaires pénibles, tels que :
+ <para>Ceci provoquait un certain nombre d'effets secondaires pénibles,
+ tels que :
<itemizedlist>
<listitem>
- <para> La corruption du catalogue système sur les noeuds abonnés, car
- les triggers existants, qui sont généralement cachés, sont <quote>modifiés
- directement </quote>, en modifiant <envar>pg_catalog.pg_trigger</envar>, pour qu'elle
- désigne les index utilisés par &slony1;, comme <quote>clé primaire</quote>.</para>
+ <para>La corruption du catalogue système sur les nœuds abonnés car
+ les triggers existants, qui sont généralement placés en cache, sont <quote>modifiés
+ directement</quote> en changeant <envar>pg_catalog.pg_trigger</envar> pour qu'il
+ désigne les index utilisés par &slony1; comme <quote>clé primaire</quote>.</para>
- <para> Ceci est également vrai pour les règles ("rules"). </para>
+ <para>Ceci est également vrai pour les règles (« rules »).</para>
- <para> L'effet secondaire était que
+ <para>L'effet secondaire était que
<application>pg_dump</application> ne pouvait pas être utilisé pour
- récupérer proprement les schémas des noeuds abonnés.</para>
- </listitem>
+ récupérer proprement les schémas des nœuds abonnés.</para>
+ </listitem>
+
<listitem><para>Cela introduit la nécessité de poser des verrous exclusifs
sur <emphasis>toutes les tables répliquées</emphasis> lors de la commande
&rddlchanges; puisque les triggers de chaque table répliquée devaient être
@@ -37,47 +44,51 @@
</listitem>
</itemizedlist>
</para></listitem>
+
<listitem>
- <para> Avec &postgres; version 8.3, il y a de nouvelles fonctionnalités
+ <para>Avec &postgres; version 8.3, il y a de nouvelles fonctionnalités
qui permettent de modifier le comportement des triggers et des règles via
la commande <command>ALTER TABLE</command>, et de spécifier une des
- options de triggers suivantes :
+ options de triggers suivantes :
<itemizedlist>
- <listitem><para> <command> DISABLE TRIGGER nom_du_declencheur</command> </para></listitem>
- <listitem><para> <command> ENABLE TRIGGER nom_du_declencheur</command> </para></listitem>
- <listitem><para> <command> ENABLE REPLICA TRIGGER nom_du_declencheur</command> </para></listitem>
- <listitem><para> <command> ENABLE ALWAYS TRIGGER nom_du_declencheur</command> </para></listitem>
- <listitem><para> <command> DISABLE RULE nom_de_la_regle</command> </para></listitem>
- <listitem><para> <command> ENABLE RULE nom_de_la_regle</command> </para></listitem>
- <listitem><para> <command> ENABLE REPLICA RULE nom_de_la_regle</command> </para></listitem>
- <listitem><para> <command> ENABLE ALWAYS RULE nom_de_la_regle</command> </para></listitem>
+ <listitem><para><command>DISABLE TRIGGER nom_du_declencheur</command></para></listitem>
+ <listitem><para><command>ENABLE TRIGGER nom_du_declencheur</command></para></listitem>
+ <listitem><para><command>ENABLE REPLICA TRIGGER nom_du_declencheur</command></para></listitem>
+ <listitem><para><command>ENABLE ALWAYS TRIGGER nom_du_declencheur</command></para></listitem>
+ <listitem><para><command>DISABLE RULE nom_de_la_regle</command></para></listitem>
+ <listitem><para><command>ENABLE RULE nom_de_la_regle</command></para></listitem>
+ <listitem><para><command>ENABLE REPLICA RULE nom_de_la_regle</command></para></listitem>
+ <listitem><para><command>ENABLE ALWAYS RULE nom_de_la_regle</command></para></listitem>
</itemizedlist>
</para>
<para>Une nouvelle variable GUC, <envar>session_replication_role</envar>
contrôle si la session est en mode 'origin', 'replica' ou 'local', ce qui
combiné avec les options d'activation/désactivation permet de contrôler
- si un trigger est effectivement exécuté. </para>
+ si un trigger est effectivement exécuté.</para>
- <para> On peut déterminer quand les triggers se déclenche dans une réplication &slony1;
- en utilisant la table suivante; le même principe s'applique aux règles.</para>
+ <para>On peut déterminer quand les triggers se déclenchent dans une réplication &slony1;
+ en utilisant la table suivante ; le même principe s'applique aux règles.</para>
- <table id="triggerbehaviour"> <title>Comportement du trigger</title>
+ <table id="triggerbehaviour">
+ <title>Comportement du trigger</title>
<tgroup cols="7">
<thead>
- <row> <entry>Type de trigger</entry>
+ <row>
+ <entry>Type de trigger</entry>
<entry>Condition de déclenchement</entry>
- <entry>trigger de log</entry>
- <entry>trigger denyaccess</entry>
+ <entry>Trigger de log</entry>
+ <entry>Trigger denyaccess</entry>
<entry>Action - origin</entry>
<entry>Action - replica</entry>
- <entry>Action - local</entry> </row>
+ <entry>Action - local</entry>
+ </row>
</thead>
<tbody>
<row>
<entry>DISABLE TRIGGER</entry>
- <entry>Requête utilisateur</entry>
- <entry>désactivé sur les noeuds abonnés</entry>
- <entry>activé sur les noeuds abonnés</entry>
+ <entry>requête utilisateur</entry>
+ <entry>désactivé sur les nœuds abonnés</entry>
+ <entry>activé sur les nœuds abonnés</entry>
<entry>ne se déclenche pas</entry>
<entry>ne se déclenche pas</entry>
<entry>ne se déclenche pas</entry>
@@ -85,15 +96,15 @@
<row>
<entry>ENABLE TRIGGER</entry>
<entry>par défaut</entry>
- <entry>activé sur les noeuds abonnés</entry>
- <entry>désactivé sur les noeuds abonnés</entry>
+ <entry>activé sur les nœuds abonnés</entry>
+ <entry>désactivé sur les nœuds abonnés</entry>
<entry>se déclenche</entry>
<entry>ne se déclenche pas</entry>
<entry>se déclenche</entry>
</row>
<row>
<entry>ENABLE REPLICA TRIGGER</entry>
- <entry>Requête utilisateur</entry>
+ <entry>requête utilisateur</entry>
<entry>inapproprié</entry>
<entry>inapproprié</entry>
<entry>ne se déclenche pas</entry>
@@ -102,7 +113,7 @@
</row>
<row>
<entry>ENABLE ALWAYS TRIGGER</entry>
- <entry>Requête utilisateur</entry>
+ <entry>requête utilisateur</entry>
<entry>inapproprié</entry>
<entry>inapproprié</entry>
<entry>se déclenche</entry>
@@ -112,86 +123,87 @@
</tbody>
</tgroup>
</table>
- <para> Il y a désormais plusieurs façons pour &slony1; d'interagir avec cela.
- Précisons les cas intéressants :
+ <para>Il y a désormais plusieurs façons pour &slony1; d'interagir avec cela.
+ Précisons les cas intéressants :
<itemizedlist>
<listitem>
- <para> Avant que la réplication soit en place,
- <emphasis>chaque</emphasis> chaque base de données démarre avec
+ <para>Avant que la réplication ne soit en place,
+ <emphasis>chaque</emphasis> base de données démarre avec
le statut <quote>origin</quote> et, par défaut, tous les triggers sont du type
- <command>ENABLE TRIGGER</command>, afin qu'ils soient exécutés, comme
- dans un système non-répliqué. </para>
+ <command>ENABLE TRIGGER</command> afin qu'ils soient exécutés, comme
+ dans un système non répliqué.</para>
</listitem>
<listitem>
- <para> Lorsqu'un abonnement &slony1; est mis en place,
- sur le noeud d'origine, les triggers <function>logtrigger</function>
- et <function>denyaccess</function> sont ajoutés, le premier est activé
- et exécuté, le second est désactivé. </para>
+ <para>Lorsqu'un abonnement &slony1; est mis en place,
+ sur le nœud d'origine, les triggers <function>logtrigger</function>
+ et <function>denyaccess</function> sont ajoutés, le premier est activé
+ et exécuté, le second est désactivé.</para>
- <para> Au niveau des verrous, chaque instructions <xref
- linkend="stmtsetaddtable"/> demandera brièvement un verrou
- exclusif sur les table ou seront attachés les triggers, ce qui a
- toujours été le cas avec &slony1;. </para>
+ <para>Au niveau des verrous, chaque instruction <xref
+ linkend="stmtsetaddtable"/> demande brièvement un verrou
+ exclusif sur les table où sont attachés les triggers, ce qui a
+ toujours été le cas avec &slony1;.</para>
</listitem>
<listitem>
- <para> Sur le noeud abonné, le processus d'abonnement ajoutera
- les même triggers, mais avec une polarité <quote>inversée</quote>,
- pour protéger les données d'une corruption accidentelle. </para>
+ <para>Sur le nœud abonné, le processus d'abonnement ajoutera
+ les même triggers, mais avec une polarité <quote>inversée</quote>
+ pour protéger les données d'une corruption accidentelle.</para>
- <para> Au niveau des verrous, encore une fois, cela fait peu de différences
- avec l'ancien comportement, car le processus d'abonnement qui utilise
- <command>TRUNCATE</command>, copie les données, et altère le schéma des tables
+ <para>Au niveau des verrous, encore une fois, cela fait peu de différences
+ avec l'ancien comportement car le processus d'abonnement, qui utilise
+ <command>TRUNCATE</command> copie les données et altère le schéma des tables,
nécessite de <emphasis>nombreux</emphasis> verrous exclusifs sur les tables,
- et les changements dans le comportement des triggers ne change pas ce besoin.</para>
+ et les changements dans le comportement des triggers ne modifie pas ce besoin.</para>
- <para> Toutefois, notez que la capacité d'activer ou désactiver les triggers
+ <para>Toutefois, notez que la capacité d'activer ou désactiver les triggers
d'une manière supportée par &postgres; signifie qu'il n'est pas nécessaire
de <quote>corrompre</quote> le catalogue système, ainsi nous avons l'avantage
considérable de pouvoir utiliser <application>pg_dump</application> pour
- obtenir une sauvegarde complète et consistante sur n'importe quel noeud du
+ obtenir une sauvegarde complète et cohérente sur n'importe quel nœud du
cluster &slony1;.</para>
</listitem>
<listitem>
- <para> Si vous effectuez un <application>pg_dump</application> sur
- un noeud &slony1;, et supprimez le namespace &slony1;, cela supprime
+ <para>Si vous effectuez un <application>pg_dump</application> sur
+ un nœud &slony1; et supprimez le namespace &slony1;, cela supprime
<emphasis>tous</emphasis> les composants &slony1; et laisse la base
de données, <emphasis>y compris son schéma</emphasis>, dans un
- état consistant et <quote>vierge</quote>, prêt pour n'importe quelle
- utilisation. </para>
+ état cohérent et <quote>vierge</quote>, prêt pour n'importe quelle
+ utilisation.</para>
</listitem>
<listitem>
- <para> L'opération &rddlchanges; est désormais réalisée d'une façon
- toute à fait différente : plutôt que d'altérer chaque table répliquée pour
+ <para>L'opération &rddlchanges; est désormais réalisée d'une façon
+ toute à fait différente : plutôt que d'altérer chaque table répliquée pour
la <quote>retirer du mode répliqué</quote>, &slony1; glissera simplement
- en statut <command>local</command> pour le temps de l'opération. </para>
- <para> Sur le noeud origine, cela désactive le trigger
- <function>logtrigger</function>. </para>
- <para> Sur chaque noeud abonné, cela désactive le trigger
- <function>denyaccess</function>. </para>
+ en statut <command>local</command> le temps de l'opération. </para>
+ <para>Sur le nœud origine, cela désactive le trigger
+ <function>logtrigger</function>.</para>
+ <para>Sur chaque nœud abonné, cela désactive le trigger
+ <function>denyaccess</function>.</para>
<para>Ceci devrait rendre les modifications DDL
- <emphasis>énormément</emphasis> moins coûteuses, car plutôt que de poser des verrous
- exclusif sur <emphasis>toutes</emphasis> les tables répliquées ( nécessaire pour les
+ <emphasis>énormément</emphasis> moins coûteuses car, plutôt que de poser des verrous
+ exclusifs sur <emphasis>toutes</emphasis> les tables répliquées (nécessaire pour les
opérations de suppression et re-création des triggers &slony1;), seules les tables impactées
- par le script DDL sont verrouillées. </para>
+ par le script DDL sont verrouillées.</para>
</listitem>
<listitem>
- <para> Au moment d'invoquer <xref linkend="stmtmoveset"/> sur l'ancien
- noeud origine, &slony1; doit transformer ce noeud en noeud abonné, ce qui nécessite
- de supprimer les triggers <function>lockset</function>, désactiver les triggers
- <function>logtrigger</function> et activer les triggers <function>denyaccess</function>.
+ <para>Au moment d'invoquer <xref linkend="stmtmoveset"/> sur l'ancien
+ nœud origine, &slony1; doit transformer ce nœud en nœud abonné, ce qui nécessite
+ de supprimer les triggers <function>lockset</function>, de désactiver les triggers
+ <function>logtrigger</function> et d'activer les triggers <function>denyaccess</function>.
</para>
- <para> Au même moment, en réalisant <xref linkend="stmtmoveset"/> sur le
- nouveau noeud origine, &slony1; doit transformer ce noeud en origine, ce qui
+ <para>Au même moment, en réalisant <xref linkend="stmtmoveset"/> sur le
+ nouveau nœud origine, &slony1; doit transformer ce nœud en origine, ce qui
implique la désactivation des triggers <function>denyaccess</function>,
et d'activer les triggers <function>logtrigger</function>.</para>
- <para> Au niveau des verrous, ceci ne change pas par rapport aux nouvelles versions
- de &slony1; le verrouillage effectué ici est tout à fait nécessaire.</para>
+ <para>Au niveau des verrous, ceci ne change pas par rapport aux nouvelles versions
+ de &slony1; car le verrouillage effectué ici est tout à fait nécessaire.</para>
</listitem>
<listitem>
- <para> De le même manière que <xref linkend="stmtmoveset"/>, <xref linkend="stmtfailover"/> transforme un noeud abonné en noeud origine, ce qui
+ <para>
+ De le même manière que <xref linkend="stmtmoveset"/>, <xref linkend="stmtfailover"/> transforme un nœud abonné en nœud origine, ce qui
nécessite de désactiver les triggers <function>denyaccess</function>, et
d'activer les triggers <function>logtrigger</function>. Encore une fois,
l'implémentation des verrous est quasiment identique.</para>
Modified: traduc/trunk/slony/usingslonik.xml
===================================================================
--- traduc/trunk/slony/usingslonik.xml 2009-01-19 21:20:59 UTC (rev 1221)
+++ traduc/trunk/slony/usingslonik.xml 2009-01-19 21:21:45 UTC (rev 1222)
@@ -4,108 +4,142 @@
par $Author$
révision $Revision$ -->
-<sect1 id="usingslonik"> <title>Utiliser Slonik</title>
-
+<sect1 id="usingslonik">
+<title>Utiliser Slonik</title>
<indexterm><primary>utiliser slonik</primary></indexterm>
-<para> Il est parfois pénible d'écrire les scripts <application>Slonik</application>
-à la main, en particulier lorsqu'on travaille avec des clusters &slony1;
-dont le nombre de noeuds et d'ensemble de réplication augmente régulièrement.
-Les problèmes suivants ont été identifiés.
+<para>
+ Il est parfois pénible d'écrire les scripts <application>Slonik</application>
+ à la main, en particulier lorsqu'on travaille avec des clusters &slony1;
+ dont le nombre de nœuds et d'ensemble de réplication augmente
+ régulièrement. Les problèmes suivants ont été identifiés.
+</para>
<itemizedlist>
-<listitem><para> Si vous utilisez &slony1; pour une réplication
-<quote>maître/esclave</quote> avec un noeud
-<quote>maître</quote> et un noeud <quote>esclave</quote>, le plus simple
-est de nommer le noeud <quote>maître</quote> noeud 1 et le
-noeud <quote>esclave</quote> noeud 2.</para>
+ <listitem>
+ <para>
+ Si vous utilisez &slony1; pour une réplication
+ <quote>maître/esclave</quote> avec un nœud <quote>maître</quote>
+ et un nœud <quote>esclave</quote>, le plus simple est de nommer le
+ nœud <quote>maître</quote> nœud 1 et le nœud
+ <quote>esclave</quote> nœud 2.
+ </para>
-<para> Malheureusement, lorsque le nombre de noeud augmente, la correspondance
- entre les identifiants et les noeuds devient moins évidente, en particulier
- si vous avez un cluster dont l'origine est déplacée d'un noeud à l'autre de temps en temps.
-</para></listitem>
+ <para>
+ Malheureusement, lorsque le nombre de nœud augmente, la
+ correspondance entre les identifiants et les nœuds devient moins
+ évidente, en particulier si vous avez un cluster dont l'origine est
+ déplacée d'un nœud à l'autre de temps en temps.
+ </para>
+ </listitem>
-<listitem><para> De la même façon, s'il n'y a qu'un seul ensemble de réplication,
-il est facile de le nommer <quote>ensemble 1,</quote> mais s'il y a
-de multiples ensemble, la numérotation des ensembles sera moins intuitive.
-</para></listitem>
+ <listitem>
+ <para>
+ De la même façon, s'il n'y a qu'un seul ensemble de réplication, il est
+ facile de le nommer <quote>ensemble 1</quote> mais s'il y a de multiples
+ ensembles, la numérotation des ensembles sera moins intuitive.
+ </para>
+ </listitem>
-<listitem><para> On observe que
-<application>Slonik</application> ne fournit pas la notion d'itération
-Il est courant de vouloir créer un ensemble d'entrée <xref
-linkend="stmtstorepath"/> similaires, car la pluspart du temps,
-les hôtes accèdent à un serveur via le même nom d'hôte ou la même
-adresse IP.</para></listitem>
+ <listitem>
+ <para>
+ On observe que <application>Slonik</application> ne fournit pas la notion
+ d'itération. Il est courant de vouloir créer un ensemble d'entrées <xref
+ linkend="stmtstorepath"/> similaires car, la plupart du temps, les hôtes
+ accèdent à un serveur via le même nom d'hôte ou la même adresse IP.
+ </para>
+ </listitem>
-<listitem><para> Les utilisateurs a tout insérer à l'intérieur de blocs
- <command>TRY</command>, ce qui n'est pas aussi utile qu'on pourrait le penser
-</para></listitem>
+ <listitem>
+ <para>
+ Les utilisateurs semblent intéressés à tout insérer à l'intérieur de
+ blocs <command>TRY</command>, ce qui n'est pas aussi utile qu'on pourrait
+ le penser.
+ </para>
+ </listitem>
+</itemizedlist>
-</itemizedlist></para>
+<para>
+ Certaines évolutions ont résolu une partie de ces problèmes :
+</para>
-<para> Certaines évolutions ont résolu une partie de ces problèmes :
-
<itemizedlist>
-<listitem><para> Noeuds nommés, ensemble nommés</para>
+ <listitem>
+ <para>Nœuds nommés, ensemble nommés</para>
-<para> Ceci est supporté par les commandes <xref
-linkend="stmtdefine"/> and <xref linkend="stmtinclude"/> à partir
- de &slony1; 1.1.
-</para>
+ <para>
+ Ceci est supporté par les commandes <xref
+ linkend="stmtdefine"/> et <xref linkend="stmtinclude"/> à partir de
+ &slony1; 1.1.
+ </para>
-<para> L'utilisation de <xref linkend="stmtinclude"/> pour créer
- des <quote>fichiers préambule</quote> est un méthode essentielle
- pour réduire les erreurs. Un fichier préambule est un défini
-<emphasis>une seule fois</emphasis> et vérifié <emphasis>une seule fois</emphasis>.
-Ces fichiers peuvent être utilisé en tout confiance par les autres scripts
-slonik.
-</para>
-</listitem>
+ <para>
+ L'utilisation de <xref linkend="stmtinclude"/> pour créer des
+ <quote>fichiers préambule</quote> est une méthode essentielle
+ pour réduire les erreurs. Un fichier préambule est défini
+ <emphasis>une seule fois</emphasis> et vérifié <emphasis>une seule
+ fois</emphasis>. Ces fichiers peuvent être utilisés en tout confiance
+ par les autres scripts slonik.
+ </para>
+ </listitem>
-<listitem><para> Boucles et opérateurs de contrôle.</para>
+ <listitem>
+ <para>Boucles et opérateurs de contrôle</para>
-<para> Il est inutile de créer un analyseur complet pour permettre la
- développer le langage de script. Il y a de nombreux langages de script
- que l'on peut utiliser pour construire des scripts Slonik; il
- n'est pas intéressant d'en imposer un nouveau.
-</para></listitem>
+ <para>
+ Il est inutile de créer un analyseur complet, c'est trop complexe. Il
+ existe de nombreux langages de script que l'on peut utiliser pour
+ construire des scripts Slonik ; il n'est pas intéressant d'en
+ imposer un nouveau.
+ </para>
+ </listitem>
+</itemizedlist>
-</itemizedlist></para>
-
-<para> Il existe plusieurs façons de régler ces problèmes :
+<para>
+ Il existe plusieurs façons de régler ces problèmes :
</para>
<itemizedlist>
+ <listitem>
+ <para>Inclure la génération du script slonik dans un script shell</para>
-<listitem><para> Inclure la génération du script slonik dans un scripts shell</para>
+ <para>
+ Les tests trouvés dans le répertoire <filename>src/ducttape</filename>
+ utilisent cette approche.
+ </para>
+ </listitem>
-<para> Les tests trouvés dans le répertoire <filename>src/ducttape</filename>
-utilise cette approche.</para></listitem>
+ <listitem>
+ <para>
+ Les <link linkend="altperl">outils altperl</link> utilisent du code
+ Perl pour générer les scripts Slonik.
+ </para>
-<listitem><para> Les <link linkend="altperl"> outils altperl</link>
-utilise du code Perl pour générer les scripts Slonik.</para>
+ <para>
+ Vous définissez les configuration du cluster comme un ensemble d'objets
+ Perl ; chaque script altperl utilise les objets Perl pour produire
+ le script slonik adéquate.
+ </para>
+ </listitem>
+</itemizedlist>
-<para> Vous définissez les configuration du cluster comme un ensemble
- d'objets Perl; chaque script altperl utilise les objets Perl pour produire
- le script slonik adéquate.
-</para></listitem>
-
-</itemizedlist>
</sect1>
-<sect1 id="slonikshell"><title> Utiliser Slonik à partir d'un script Shell </title>
+<sect1 id="slonikshell">
+<title>Utiliser Slonik à partir d'un script shell</title>
+<indexterm><primary>utiliser slonik à l'intérieur de scripts shell</primary></indexterm>
-<indexterm><primary> Utiliser slonik à l'intérieur de scripts Shell</primary></indexterm>
+<para>
+ Comme on l'a vu précédemment, il existe de nombreux scripts de test pour
+ &slony1; dans le répertoire <filename>src/ducttape</filename> qui intègre
+ la génération de script Slonik à l'intérieur de code écrit en shell.
+</para>
-<para> Comme on l'a vu précédemment, il existe de nombreux scripts de test pour &slony1;
- dans le répertoire <filename>src/ducttape</filename> qui intègre la génération
- de script Slonik à l'intérieur de code écrit en Shell.</para>
+<para>
+ La plupart de ces scripts ne sont <emphasis>pas</emphasis> terriblement
+ sophistiqués. Typiquement, ils utilisent des structures comme celle-ci :
-<para> La pluspart de ces scripts ne sont <emphasis> pas </emphasis> terriblement
- sophistiqués. Typiquement, ils utilisent des structures comme celle-ci
- :
-
<programlisting><![CDATA[
DB1=slony_test1
DB2=slony_test2
@@ -136,10 +170,11 @@
_EOF_
]]></programlisting></para>
-<para> Une approche plus sophistiquée consiste à définir des composants
- communs, notamment un <quote>préambule</quote> qui contient les
- commandes <xref linkend="clustername"/> et <xref linkend="admconninfo"/>
- que l'on retrouve dans chaque script Slonik :
+<para>
+ Une approche plus sophistiquée consiste à définir des composants communs,
+ notamment un <quote>préambule</quote> qui contient les commandes <xref
+ linkend="clustername"/> et <xref linkend="admconninfo"/> que l'on
+ retrouve dans chaque script Slonik :
<programlisting>
CLUSTER=T1
@@ -151,15 +186,17 @@
"
</programlisting></para>
-<para> La variable <envar>PREAMBULE</envar> peut alors être
- réutilisée plusieurs fois lorsque que le script shell invoque
- plusieurs fois <command>slonik</command>.
- Vous pouvez également utiliser <xref linkend="stmtinclude"/> et
- placer le preambule dans un fichier que vous incluez.
- </para>
+<para>
+ La variable <envar>PREAMBULE</envar> peut alors être réutilisée plusieurs
+ fois lorsque le script shell invoque plusieurs fois <command>slonik</command>.
+ Vous pouvez également utiliser <xref linkend="stmtinclude"/> et placer le
+ preambule dans un fichier que vous incluez.
+</para>
-<para> Les variables Shell fournissent une méthode simple
- pour assigner les noms d'ensemble et de noeuds :
+<para>
+ Les variables shell fournissent une méthode simple pour assigner les noms
+ d'ensemble et de nœuds :
+</para>
<programlisting><![CDATA[
origin=1
@@ -186,10 +223,12 @@
exit 1;
}
_EOF_
-]]></programlisting></para>
+]]></programlisting>
-<para> Le script peut être utilisé en suite pour boucler sur la liste
- des tables :
+<para>
+ Le script peut être utilisé en suite pour boucler sur la liste des
+ tables :
+</para>
<programlisting><![CDATA[
# Basic configuration
@@ -218,144 +257,188 @@
exit 1;
}
_EOF_
-]]></programlisting></para>
+]]></programlisting>
-<para> Ce n'est peut-être pas nécessaire si vous n'avez que 4 tables
- mais cette méthode évite de recopier de longues listes de configuration
- à la main et préviendra les erreurs sur les grands ensembles que
- vous rencontrerez dans la <quote>vraie vie</quote>.</para>
+<para>
+ Ce n'est peut-être pas nécessaire si vous n'avez que quatre tables mais cette
+ méthode évite de recopier de longues listes de configuration à la main et
+ préviendra les erreurs sur les grands ensembles que vous rencontrerez dans
+ la <quote>vraie vie</quote>.
+</para>
-<para> Vous pouvez créer des scripts encore plus sophistiqués, si
- votre langage de script possède :
+<para>
+ Vous pouvez créer des scripts encore plus sophistiqués si votre langage de
+ script possède :
+</para>
<itemizedlist>
+ <listitem>
+ <para>
+ des structures de type <quote>Record</quote> qui permettent d'assigner
+ des objets en parallèle ;
+ </para>
+ </listitem>
-<listitem><para> des structures de type <quote>Record</quote> qui
- permette d'assigner des objets en parallèle.</para></listitem>
+ <listitem>
+ <para>
+ des fonctions, procédure ou des routines qui permettent d'implanter des
+ fonctionnalités une seule fois, puis de les appeler à divers endroits
+ de votre script.
+ </para>
+ </listitem>
-<listitem><para> des fonctions, procédure ou des routines, qui
- permettent d'implanter des fonctionnalités une seule fois,
- puis de les appeler à divers endroit de votre script.
- </para></listitem>
+ <listitem>
+ <para>
+ Un mécanisme d'<quote>import de module</quote> afin de partager de
+ fonctionnalités commune entre plusieurs scripts.
+ </para>
+ </listitem>
+</itemizedlist>
-<listitem><para> Un mécanisme <quote>d'import de module</quote> afin
- partager de fonctionnalités commune entre plusieurs scripts.
- </para></listitem>
+<para>
+ Si vous devez utiliser <ulink
+ url="http://www.gnu.org/software/bash/bash.html">Bash</ulink>, <ulink
+ url="http://www.zsh.org/">zsh</ulink> ou <ulink
+ url="http://www.kornshell.com/">Korn shell</ulink>, tous ces shells possèdent
+ des extensions qui gèrent correctement les structures de données
+ sophistiquées et les modules. Sur linux, Bash est très répandu ; sur les
+ systèmes <trademark>UNIX</trademark> commerciaux, Korn est le standard alors
+ que sur BSD, les shells <quote>sophistiqués</quote> sont en option.
+</para>
-</itemizedlist></para>
+<para>
+ N'oubliez pas de regarder du côté des des autres langages de script, parmi
+ lesquels Perl est le plus évident, puisqu'il est largement répandu sur Linux,
+ <trademark>UNIX</trademark> et BSD.
+</para>
-<para> Si vous devez utiliser <ulink
-url="http://www.gnu.org/software/bash/bash.html"> Bash</ulink>, <ulink
-url="http://www.zsh.org/"> zsh</ulink>, ou <ulink
-url="http://www.kornshell.com/"> Korn shell</ulink>, toutes
- ces shells possèdent des extensions qui gèrent correctement
- les structures de données sophistiquées et les modules.
- Sur linux, Bash est très répandu; sur les systèmes <trademark>UNIX</trademark>
- commerciaux, Korn est le standard, sur BSD, les shells <quote>sophistiqués</quote>
- sont en option.</para>
+</sect1>
-<para> N'oubliez pas de regarder du coté des des autres
- langages de script, parmi lesquels Perl est le plus évident,
- puisque est largement répandu sur Linux, <trademark>UNIX</trademark>,
- et BSD.
+<sect1 id="noslonik">
+<title>Ne pas utiliser Slonik - les fonctions &slony1; de bas niveau</title>
+<indexterm><primary>fonctions &slony1; de bas niveau</primary></indexterm>
+
+<para>
+ Il est parfois nécessaire d'utiliser directement les procédures stockées
+ qui composent les différentes parties de &slony1;. Slonik n'est pas
+ <quote>magique</quote> ; il est courant qu'une commande Slonik se
+ contente de décider le nœud qui va recevoir la commande et lui
+ envoie une requête SQL qui contient une seule procédure stockée &slony1;.
</para>
-</sect1>
-<sect1 id="noslonik"><title> Ne pas utiliser Slonik - les fonctions &slony1; de bas niveau</title>
+<para>
+ Les développeurs de &slony1; espèrent que quelqu'un développera des outils
+ graphiques qui constitueront une alternative à Slonik ; il serait alors
+ utile d'envoyer les ordres de configuration directement via les procédures
+ stockées. Si vous comptez vous lancer dans ce projet, il est conseillé
+ d'examiner comment les procédures stockées sont utilisées dans le fichier
+ <filename>slonik.c</filename> puisqu'il s'agit de l'utilisation la plus
+ correcte de ces fonctions.
+</para>
-<indexterm><primary> fonctions &slony1; de bas niveau </primary></indexterm>
+<para>
+ Lorsque qu'on corrige des problèmes sur un cluster &slony1;
+ <quote>endommagé</quote>, il est parfois utile d'utiliser les procédures
+ stockées. C'est particulièrement efficace lorsque la configuration de la table
+ <xref linkend="table.sl-listen"/> est corrompue et que les événements ne se
+ propagent plus correctement. La méthode la <quote>plus simple</quote> pour
+ réparer cela est la suivante :
+</para>
-<para> Il est parfois nécessaire d'utiliser directement les procédures stockées
- qui compose les différentes parties de &slony1;.
-Slonik n'est pas <quote>magique;</quote> il est courant qu'une commande
-Slonik se contente de décider quel noeud va recevoir la commande
-et lui envoie une requête SQL qui contient une seule procédure stockée
-&slony1;.</para>
+<para>
-<para> Les développeurs de &slony1; espèrent que quelqu'un développera des
- outils graphiques qui constitueront une alternative à Slonik; Il serait
- alors utile d'envoyer les ordres de configuration directement via
- les procédures stockées. Si vous comptez vous lancer dans ce projet,
- il est conseillé d'examiner comment les procédures stockées sont
- utilisées dans le fichier <filename>slonik.c</filename>,
- puisqu'il s'agit de l'utilisation la plus correcte de ces fonctions.</para>
+<command>SELECT _slonycluster.droplisten(li_origin,li_provider,li_receiver)
+FROM _slonycluster.sl_listen;</command>
-<para> Lorsque que l'on corrige des problèmes sur un cluster &slony1; <quote>endommagé</quote>,
- il est parfois utile d'utiliser les procédures stockées. C'est particulièrement
- efficace lorsque la configuration de la table <xref
-linkend="table.sl-listen"/> est corrompue et que les événements ne se
- propagent plus correctement.
- La méthode la <quote>plus simple</quote> pour réparer cela est la suivante :
</para>
-<para> <command> select
-_slonycluster.droplisten(li_origin,li_provider,li_receiver) from
-_slonycluster.sl_listen;</command></para>
+<para>
-<para> <command> select _slonycluster.storelisten(pa_server,
-pa_server, pa_client) from _slonycluster.sl_path;</command></para>
+<command>SELECT _slonycluster.storelisten(pa_server, pa_server, pa_client)
+FROM _slonycluster.sl_path;</command>
-<para> Le résultat de ces requêtes est la régénération et la
-<emphasis>propagation</emphasis> des voies d'écoute. En
-lançant à la main la fonction
-<function> _slonycluster.storelisten()</function>,
-on déclenche des évènements <command>STORE_LISTEN</command> qui provoque
-l'envoi des voies d'écoute sur les autres noeuds du cluster.
</para>
-<para> En cas de problème <emphasis>local</emphasis> sur un noeud, si
- vous ne souhaitez pas propager les corrections ( ce qui est assez
- rare, on cherche en général à réparer <emphasis>l'ensemble</emphasis> du cluster ),
- la requête est la suivante :
+<para>
+ Le résultat de ces requêtes est la regénération et la
+ <emphasis>propagation</emphasis> des voies d'écoute. En lançant à la main la
+ fonction <function> _slonycluster.storelisten()</function>, on déclenche des
+ évènements <command>STORE_LISTEN</command> qui provoquent l'envoi des voies
+ d'écoute sur les autres nœuds du cluster.
</para>
-<para> <command> select
-slonycluster.droplisten_int(li_origin,li_provider,li_receiver) from
-_slonycluster.sl_listen;</command></para>
+<para>
+ En cas de problème <emphasis>local</emphasis> sur un nœud, si vous ne
+ souhaitez pas propager les corrections (ce qui est assez rare, on cherche en
+ général à réparer <emphasis>l'ensemble</emphasis> du cluster), la requête
+ est la suivante :
+</para>
-<para> <command> select _slonycluster.storelisten_int(pa_server,
-pa_server, pa_client) from _slonycluster.sl_path;</command></para>
+<para><command>SELECT slonycluster.droplisten_int(li_origin,li_provider,li_receiver)
+FROM _slonycluster.sl_listen;</command></para>
-<para> Si vous souhaitez ajouter le support de &slony1; dans d'autres
- outils (<emphasis>par exemple :</emphasis> ajouter la
- réplication dans <ulink url="http://www.pgadmin.org/"> <productname>pgAdmin
-III</productname> </ulink>), vous devez savoir clairement quelles
-fonctions il faut appeler. Le <quote>protocole</quote> normal est le suivant :
+<para><command>SELECT _slonycluster.storelisten_int(pa_server, pa_server, pa_client)
+FROM_slonycluster.sl_path;</command></para>
+<para>
+ Si vous souhaitez ajouter le support de &slony1; dans d'autres outils
+ (<emphasis>par exemple :</emphasis> ajouter la réplication dans <ulink
+ url="http://www.pgadmin.org/"><productname>pgAdmin III</productname></ulink>),
+ vous devez savoir clairement quelles fonctions il faut appeler. Le
+ <quote>protocole</quote> normal est le suivant :
+</para>
+
<itemizedlist>
+ <listitem>
+ <para>
+ La fonction <quote>principale</quote> (<emphasis>par exemple</emphasis>
+ celle sans le suffixe <command>_int</command>) est appelée sur un
+ nœud <quote>adéquat</quote> du cluster &slony1;.
+ </para>
-<listitem><para> La fonction <quote>principale</quote>
-(<emphasis>par exemple </emphasis> celle sans le suffixe <command>_int</command>)
-est appelée sur un noeud <quote>adéquate</quote> du cluster &slony1;.</para>
+ <para>
+ Dans la plupart des cas, la fonction peut être appelée sur n'importe
+ quel nœud, et elle propage correctement les commandes aux autres
+ nœuds. C'est vrai pour <xref
+ linkend="function.storelisten-integer-integer-integer"/>, par exemple.
+ </para>
-<para> Dans la pluspart des cas, la fonction peut être appelées sur
- n'importe quel noeud, et elle propage correctement les commandes
- aux autres noeuds. C'est vrai pour <xref
-linkend="function.storelisten-integer-integer-integer"/>, par exemple.
+ <para>
+ Dans d'autres cas, la fonction doit être lancée depuis un nœud
+ particulier car c'est le seul endroit où les données sont valides.
+ Par exemple, <xref
+ linkend="function.subscribeset-integer-integer-integer-boolean"/> doit
+ être appelée sur le nœud récepteur.
+ </para>
+ </listitem>
-Dans d'autres cas, la fonction doit être lancée depuis un noeud
-particulier car c'est le seul endroit où les données sont valides.
-Par exemple, <xref
-linkend="function.subscribeset-integer-integer-integer-boolean"/> doit
-être appelée sur le noeud récepteur.</para></listitem>
+ <listitem>
+ <para>
+ Si la fonction <quote>principale</quote> réussit, alors le changement de
+ configuration est effectué sur le nœud local et un événement est
+ créé avec <xref linkend="function.createevent-name-text"/> pour que le
+ changement de configuration soit propagé à tous les autres nœuds
+ du cluster &slony1;.
+ </para>
+ </listitem>
-<listitem><para> Si la fonction <quote>principale</quote> réussit, alors
- le changement de configuration est effectué sur le noeud local et
- un événement est créé avec <xref linkend="function.createevent-name-text"/>
- pour que le changement de configuration soit propagé à tout les autres
- noeuds du cluster &slony1;.</para></listitem>
+ <listitem>
+ <para>
+ Troisièmement, la version <command>_int</command> de la fonction doit
+ être lancée.
+ </para>
-<listitem><para> Troisièmement, la version <command>_int</command> de la fonction
- doit être lancée.</para>
+ <para>
+ Dans certains cas, lorsque les fonctions sont idempotentes, le nœud
+ sur lequel la fonction <quote>principale</quote> est exécutée peut traiter
+ la version <command>_int</command> très tôt.
+ </para>
-<para> Dans certains cas, lorsque les fonctions sont idempotentes, le noeud
- sur lequel la fonction <quote>principale</quote> est exécutée peut
- traiter la version <command>_int</command> très tôt.
- </para>
+ <para>
+ Au moment où l'événement se propage, les nœuds lancent la version
+ <command>_int</command>, en espérant que tout se passe bien.
+ </para>
+ </listitem>
+</itemizedlist>
-<para> En même temps que l'événement se propagera, les noeuds lanceront la version
- <command>_int</command>, en espérant que tout se passe bien. </para></listitem>
-
-</itemizedlist></para>
-
</sect1>
More information about the Trad
mailing list