[Trad] [svn:pgfr] r1173 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Jeu 30 Oct 11:58:18 CET 2008
Author: gleu
Date: 2008-10-30 11:58:17 +0100 (Thu, 30 Oct 2008)
New Revision: 1173
Modified:
traduc/trunk/slony/Makefile
traduc/trunk/slony/addthings.xml
traduc/trunk/slony/adminscripts.xml
traduc/trunk/slony/bestpractices.xml
traduc/trunk/slony/ddlchanges.xml
traduc/trunk/slony/failover.xml
traduc/trunk/slony/faq.xml
traduc/trunk/slony/frenchtranslation.xml
traduc/trunk/slony/legal.xml
traduc/trunk/slony/loganalysis.xml
traduc/trunk/slony/partitioning.xml
traduc/trunk/slony/prerequisites.xml
traduc/trunk/slony/releasechecklist.xml
traduc/trunk/slony/slon.xml
traduc/trunk/slony/slonconf.xml
traduc/trunk/slony/slonik.xml
traduc/trunk/slony/slonik_ref.xml
traduc/trunk/slony/slony.xml
traduc/trunk/slony/startslons.xml
traduc/trunk/slony/supportedplatforms.xml
traduc/trunk/slony/testbed.xml
traduc/trunk/slony/triggers.xml
Log:
Modifications pour permettre la g?\195?\169n?\195?\169ration du manuel.
Patch de Christophe Bouchet, avec quelques modifications suppl?\195?\169mentaires de ma
part.
Cependant, il reste encore du travail pour avoir une g?\195?\169n?\195?\169ration parfaite.
Modified: traduc/trunk/slony/Makefile
===================================================================
--- traduc/trunk/slony/Makefile 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/Makefile 2008-10-30 10:58:17 UTC (rev 1173)
@@ -42,6 +42,7 @@
cd $(BASEDIR)/$(HTM_OUTPUT)/; sed -i -e "s at ../images at images@g" *.html
for filename in `find $(BASEDIR)/$(HTM_OUTPUT) -name "*.html"`; do \
+ recode iso-8859-15..utf-8 $$filename; \
tidy -config tidy.conf $$filename; \
true; \
sed -i -e "s at text/html at application/xhtml+xml at g" $$filename; \
Modified: traduc/trunk/slony/addthings.xml
===================================================================
--- traduc/trunk/slony/addthings.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/addthings.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -60,7 +60,7 @@
complexes en s'assurant qu'un changement a été parfaitement réussi avant
de passer au suivant. Il est beaucoup plus simple de corriger un problème
unique que de réparer les dégâts provoqués par l'interaction erronée de cinq commandes
-successives.<</para>
+successives.</para>
<para> Voici un ensemble de <quote>recettes</quote> pour réaliser
différentes modifications sur la configuration de la réplication :</para>
@@ -94,7 +94,7 @@
<para> A contrario, vous pouvez ajouter la table via
<application>psql</application> sur chaque noeud.
-<n/para> </listitem>
+</para> </listitem>
<listitem><para> Créer un nouvel ensemble de réplication avec <xref linkend="stmtcreateset"/>
</para></listitem>
@@ -419,4 +419,4 @@
hors de la réplication, puis de créer un nouvel ensemble de réplication et de l'ajouter
à nouveau. </para>
</sect2>
-</sect1>
\ No newline at end of file
+</sect1>
Modified: traduc/trunk/slony/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/adminscripts.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -5,711 +5,717 @@
révision $Revision$ -->
<sect1 id="adminscripts">
-<title>Scripts d'administration</title>
+ <title>Scripts d'administration</title>
-<indexterm><primary>scripts d'administration de &slony1;</primary></indexterm>
+ <indexterm><primary>scripts d'administration de &slony1;</primary></indexterm>
-<para> Un certain nombre de scripts ont été développes tout au long de l'histoire de
+ <para> Un certain nombre de scripts ont été développes tout au long de l'histoire de
&slony1; pour aider les utilisateurs à gérer leurs clusters. Cette section ainsi
que celle sur le <xref linkend="monitoring"/> et la <xref
-linkend="maintenance"/> décrit leur utilisation. </para>
+ linkend="maintenance"/> décrit leur utilisation. </para>
-<sect2 id="altperl"> <title>Les scripts altperl</title>
+ <sect2 id="altperl"> <title>Les scripts altperl</title>
-<indexterm><primary> Script altperl pour &slony1;</primary></indexterm>
+ <indexterm><primary> Script altperl pour &slony1;</primary></indexterm>
-<para>Il existe un ensemble de scripts qui simplifie l'administration de plusieurs
-instances &slony1;. Ces scripts supportent une nombre variable de noeuds. Ils peuvent
-être installés pendant le processus d'installation :</para>
+ <para>Il existe un ensemble de scripts qui simplifie l'administration de plusieurs
+ instances &slony1;. Ces scripts supportent une nombre variable de noeuds. Ils peuvent
+ être installés pendant le processus d'installation :</para>
-<para><command>
- ./configure --with-perltools
-</command></para>
+ <para><command> ./configure --with-perltools</command></para>
-<para>Ceci va produire un certain nombre de scripts avec le préfixe
-<command>slonik_</command>. Ils éliminent les risques de confusion en se référençant
-à un fichier central de configuration qui contient les détails de la configuration
-de votre site. Un exemple documenté de ce fichier est fourni dans
-<filename>altperl/slon_tools.conf-sample</filename>. La plupart dispose également
-une aide en ligne grâce à l'option "--help", ce qui les rend plus facile à prendre en main
-et à utiliser.
-</para>
+ <para>Ceci va produire un certain nombre de scripts avec le préfixe
+ <command>slonik_</command>. Ils éliminent les risques de confusion en se référençant
+ à un fichier central de configuration qui contient les détails de la configuration
+ de votre site. Un exemple documenté de ce fichier est fourni dans
+ <filename>altperl/slon_tools.conf-sample</filename>. La plupart dispose également
+ une aide en ligne grâce à l'option "--help", ce qui les rend plus facile à prendre en main
+ et à utiliser.</para>
-<para>La plupart des scripts de génération Slonik utilise la sortie STDOUT.
-Pendant un temps, les commandes étaient passées directement à <xref linkend="slonik"/>
-pour qu'il les exécute. Malheureusement, il s'agit d'une méthode trop .
-<quote>agressive</quote>, car de légères coquilles dans la ligne de commande
-peuvent conduire, dans certains cas, à des situations calamiteuses.
-Tout administrateur qui se respecte doit relire le script
-<emphasis>avant</emphasis> de l'envoyer à <xref linkend="slonik"/>.</para>
+ <para>La plupart des scripts de génération Slonik utilise la sortie STDOUT.
+ Pendant un temps, les commandes étaient passées directement à <xref linkend="slonik"/>
+ pour qu'il les exécute. Malheureusement, il s'agit d'une méthode trop .
+ <quote>agressive</quote>, car de légères coquilles dans la ligne de commande
+ peuvent conduire, dans certains cas, à des situations calamiteuses.
+ Tout administrateur qui se respecte doit relire le script
+ <emphasis>avant</emphasis> de l'envoyer à <xref linkend="slonik"/>.</para>
-<sect3><title>Gestion de multiples clusters</title>
-<indexterm><primary>Gérer de multiples clusters avec les outils altperl</primary></indexterm>
+ <sect3><title>Gestion de multiples clusters</title>
+ <indexterm><primary>Gérer de multiples clusters avec les outils altperl</primary></indexterm>
-<para>La variable d'environnement <envar>SLONYNODES</envar> est utilisée pour déterminer
-quel fichier de configuration Perl sera utilisé pour controler les noeuds du cluster
-&slony1;. Si elle n'est pas fournie le fichier <filename>slon_tools.conf</filename>
-situé dans l'emplacement par défaut sera utilisé. </para>
+ <para>La variable d'environnement <envar>SLONYNODES</envar> est utilisée pour déterminer
+ quel fichier de configuration Perl sera utilisé pour controler les noeuds du cluster
+ &slony1;. Si elle n'est pas fournie le fichier <filename>slon_tools.conf</filename>
+ situé dans l'emplacement par défaut sera utilisé. </para>
-<para>Voici la liste des variables qui peuvent être configurées :
-<itemizedlist>
+ <para>Voici la liste des variables qui peuvent être configurées :
+ <itemizedlist>
-<listitem><para><envar>$CLUSTER_NAME</envar>=orglogs; # Quel est le nom du cluster de réplication ?</para></listitem>
-<listitem><para><envar>$LOGDIR</envar>='/opt/OXRS/log/LOGDBS'; # Quel est le répertoire des logs ?</para></listitem>
-<listitem><para><envar>$APACHE_ROTATOR</envar>="/opt/twcsds004/OXRS/apache/rotatelogs"; # Si ce paramètre est défini, il indique où trouver le gestionnaire de logs d'Apache</para></listitem>
-<listitem><para><envar>foldCase</envar> # Si la valeur est 1, les noms d'objet ( y compris les noms de schéma) seront transformés en minuscule. Par défaut, les noms d'objets restent inchangés. Notons que &postgres; lui-même transforme les noms d'objets en minuscule;
-Si vous créez une table avec la commande <command> CREATE TABLE
-MA_TABLE (Id INTEGER, MoNChamp text);</command>, le résultat sera
-équivalent à <command> create table ma_table (id integer,
-monchamp text);</command>, le nom de la table et ses champs sera transformé en minuscule.
-</para>
+ <listitem><para><envar>$CLUSTER_NAME</envar>=orglogs; # Quel est le nom du cluster de réplication ?</para></listitem>
+ <listitem><para><envar>$LOGDIR</envar>='/opt/OXRS/log/LOGDBS'; # Quel est le répertoire des logs ?</para></listitem>
+ <listitem><para><envar>$APACHE_ROTATOR</envar>="/opt/twcsds004/OXRS/apache/rotatelogs"; # Si ce paramètre est défini, il indique où trouver le gestionnaire de logs d'Apache</para></listitem>
+ <listitem><para><envar>foldCase</envar> # Si la valeur est 1, les noms d'objet ( y compris les noms de schéma) seront transformés en minuscule. Par défaut, les noms d'objets restent inchangés. Notons que &postgres; lui-même transforme les noms d'objets en minuscule;
+ Si vous créez une table avec la commande <command> CREATE TABLE
+ MA_TABLE (Id INTEGER, MoNChamp text);</command>, le résultat sera
+ équivalent à <command> create table ma_table (id integer,
+ monchamp text);</command>, le nom de la table et ses champs sera transformé en minuscule.
+ </para>
-</listitem>
-</itemizedlist>
-</para>
+ </listitem>
+ </itemizedlist>
+ </para>
-<para> Vous pouvez ensuite définir un ensemble de noeuds qui participeront à la réplication
-en utilisant plusieurs appels à la fonction <function>add_node()</function>.
-</para>
+ <para> Vous pouvez ensuite définir un ensemble de noeuds qui participeront à la réplication
+ en utilisant plusieurs appels à la fonction <function>add_node()</function>.
+ </para>
-<para><command>
- add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437,
- user => 'postgres', node => 4, parent => 1);
-</command></para>
+ <para><command>
+ add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437,
+ user => 'postgres', node => 4, parent => 1);
+ </command></para>
-<para>Les paramètres de la fonction <function>add_node()</function> sont les suivants :</para>
+ <para>Les paramètres de la fonction <function>add_node()</function> sont les suivants :</para>
-<programlisting>
-my %PARAMS = (host=> undef, # nom de l'hôte
- dbname => 'template1', # nom de la base
- port => 5432, # numéro du port
- user => 'postgres', # utilisateur de la connexion
- node => undef, # numéro du noeud
- password => undef, # mot de passe de l'utilisateur
- parent => 1, # l'identifiant du noeud père
- noforward => undef # ce noeud doit-il retransmettre les modifications ?
- sslmode => undef # mode SSL - détermine la priorité
- # d'utilisation de la couche SSL
- # = disable,allow,prefer,require
-);
-</programlisting>
-</sect3>
+ <programlisting>
+ my %PARAMS = (host=> undef, # nom de l'hôte
+ dbname => 'template1', # nom de la base
+ port => 5432, # numéro du port
+ user => 'postgres', # utilisateur de la connexion
+ node => undef, # numéro du noeud
+ password => undef, # mot de passe de l'utilisateur
+ parent => 1, # l'identifiant du noeud père
+ noforward => undef # ce noeud doit-il retransmettre les modifications ?
+ sslmode => undef # mode SSL - détermine la priorité
+ # d'utilisation de la couche SSL
+ # = disable,allow,prefer,require
+ );
+ </programlisting>
+ </sect3>
-<sect3><title>Configuration d'un ensemble de réplication </title>
-<indexterm><primary>cluster.set1 - configuration d'un ensemble de réplication pour les outils
-Perl</primary></indexterm>
+ <sect3><title>Configuration d'un ensemble de réplication </title>
+ <indexterm><primary>cluster.set1 - configuration d'un ensemble de réplication pour les outils
+ Perl</primary></indexterm>
-<para>La variable d'environnement UNIX <envar>SLONYSET</envar> est utilisée pour déterminer
-quel fichier de configuration doit être lu pour connaître les objets qui sont contenus
-dans un ensemble donné.</para>
+ <para>La variable d'environnement UNIX <envar>SLONYSET</envar> est utilisée pour déterminer
+ quel fichier de configuration doit être lu pour connaître les objets qui sont contenus
+ dans un ensemble donné.</para>
-<para>Contrairement à <envar>SLONYNODES</envar>, qui est essentielle pour
-<emphasis>tous</emphasis> les scripts de génération <xref linkend="slonik"/>,
-celle-ci n'est nécessaire que lorsqu'on exécute
-<filename>create_set</filename>, car il s'agit du seul script qui contrôle
-le placement des tables dans les différents ensemble de réplication.
-</para>
+ <para>Contrairement à <envar>SLONYNODES</envar>, qui est essentielle pour
+ <emphasis>tous</emphasis> les scripts de génération <xref linkend="slonik"/>,
+ celle-ci n'est nécessaire que lorsqu'on exécute
+ <filename>create_set</filename>, car il s'agit du seul script qui contrôle
+ le placement des tables dans les différents ensemble de réplication.
+ </para>
-</sect3>
-<sect3><title>slonik_build_env</title>
-<indexterm><primary>slonik_build_env</primary></indexterm>
+ </sect3>
+ <sect3><title>slonik_build_env</title>
+ <indexterm><primary>slonik_build_env</primary></indexterm>
-<para>Cette commande interroge la base de données et produit un résultat qui
-peut être utilisé dans <filename>slon_tools.conf</filename>, notamment :</para>
-<itemizedlist>
+ <para>Cette commande interroge la base de données et produit un résultat qui
+ peut être utilisé dans <filename>slon_tools.conf</filename>, notamment :</para>
+ <itemizedlist>
-<listitem><para> une série d'appel à <function>add_node()</function> pour configurer
-le cluster</para></listitem>
-<listitem><para> les tableaux <envar>@KEYEDTABLES</envar>,
-<envar>@SERIALT</envar>, et <envar>@SEQUENCES</envar></para></listitem>
-</itemizedlist>
-</sect3>
-<sect3><title>slonik_print_preamble</title>
+ <listitem><para> une série d'appel à <function>add_node()</function> pour configurer
+ le cluster</para></listitem>
+ <listitem><para> les tableaux <envar>@KEYEDTABLES</envar>,
+ <envar>@SERIALT</envar>, et <envar>@SEQUENCES</envar></para></listitem>
+ </itemizedlist>
+ </sect3>
+ <sect3><title>slonik_print_preamble</title>
-<para>Cette commande produit simplement le <quote>préambule</quote> qui est nécessaire
-à chaque scripts slonik. En fait, elle fournit un <quote>squelette</quote> de script slonik
-qui ne fait pas d'action particulière.</para>
-</sect3>
-<sect3><title>slonik_create_set</title>
+ <para>Cette commande produit simplement le <quote>préambule</quote> qui est nécessaire
+ à chaque scripts slonik. En fait, elle fournit un <quote>squelette</quote> de script slonik
+ qui ne fait pas d'action particulière.</para>
+ </sect3>
+ <sect3><title>slonik_create_set</title>
-<para>Cette commande nécessite que les variables <envar>SLONYSET</envar> et
-<envar>SLONYNODES</envar> soit configurées;
-Elle permet de produire le script <command>slonik</command>
-qui configure un ensemble de réplication en décrivant les tables et les séquences
-qui seront répliquées.</para>
-</sect3>
-<sect3><title>slonik_drop_node</title>
+ <para>Cette commande nécessite que les variables <envar>SLONYSET</envar> et
+ <envar>SLONYNODES</envar> soit configurées;
+ Elle permet de produire le script <command>slonik</command>
+ qui configure un ensemble de réplication en décrivant les tables et les séquences
+ qui seront répliquées.</para>
+ </sect3>
+ <sect3><title>slonik_drop_node</title>
+ <para>Cette commande produit une script Slonik qui supprime une noeud du cluster &slony1; .</para>
+ </sect3>
+ <sect3><title>slonik_drop_set</title>
+ <para>Cette commande produit un script Slonik qui supprime un ensemble de réplication
+ (<emphasis>c'est à dire</emphasis> un groupe de tables et de séquences).</para>
+ </sect3>
-<para>Cette commande produit une script Slonik qui supprime une noeud du cluster &slony1; .</para>
-</sect3>
-<sect3><title>slonik_drop_set</title>
+ <sect3 id="slonik-drop-table"><title>slonik_drop_table</title>
+ <para>Cette commande produit un script Slonik qui supprime une table de la réplication.
+ Elle nécessite en entrée l'identifiant de la table ( disponible dans le table
+ <envar>sl_table</envar>). </para>
+ </sect3>
-<para>Cette commande produit un script Slonik qui supprime un ensemble de réplication
-(<emphasis>c'est à dire</emphasis> un groupe de tables et de séquences).</para>
-</sect3>
+ <sect3><title>slonik_execute_script</title>
+ <para>Cette commande produit un script pour effectuer des changements DDL sur un ensemble
+ de réplication.</para>
+ </sect3>
-<sect3 id="slonik-drop-table"><title>slonik_drop_table</title>
+ <sect3><title>slonik_failover</title>
+ <para>Cette commande produit un script qui demande une bascule d'urgence entre un noeud
+ mort et une nouvelle origine</para>
+ </sect3>
+ <sect3><title>slonik_init_cluster</title>
+ <para>Cette commande produit un script Slonik qui intialise un cluster &slony1; tout entier,
+ y compris les noeuds, les voies de communications et les voies d'écoute.
+ </para>
+ </sect3>
-<para>Cette commande produit un script Slonik qui supprime une table de la réplication.
-Elle nécessite en entrée l'identifiant de la table ( disponible dans le table
-<envar>sl_table</envar>). </para>
-</sect3>
+ <sect3><title>slonik_merge_sets</title>
+ <para>Cette commande produit un script Slonik qui fusionne deux ensembles de réplication.
+ </para>
+ </sect3>
+
+ <sect3><title>slonik_move_set</title>
+ <para>Cette commande produit un script Slonik qui déplace l'origine d'un ensemble de réplication vers un autre noeud.</para>
+ </sect3>
+ <sect3><title>réplication_test</title>
-<sect3><title>slonik_execute_script</title>
+ <para>Ce script vérifie que &slony1; réplique correctement les données.</para>
+ </sect3>
+ <sect3><title>slonik_restart_node</title>
-<para>Cette commande produit un script pour effectuer des changements DDL sur un ensemble
-de réplication.</para>
-</sect3>
-<sect3><title>slonik_failover</title>
+ <para>Cette commande produit un script Slonik que demande le redémarrage d'un noeud.
+ Elle était particulièrement utile avant la version 1.0.5, lorsque les noeuds étaient
+ bloqués suite à la mort du démon slon.</para>
+ </sect3>
+ <sect3><title>slonik_restart_nodes</title>
-<para>Cette commande produit un script qui demande une bascule d'urgence entre un noeud
-mort et une nouvelle origine</para>
-</sect3>
-<sect3><title>slonik_init_cluster</title>
+ <para>Cette commande produit un script Slonik qui redémarre tous les noeuds du cluster.
+ Elle n'est pas très utile.</para>
+ </sect3>
-<para>Cette commande produit un script Slonik qui intialise un cluster &slony1; tout entier,
-y compris les noeuds, les voies de communications et les voies d'écoute.
-</para>
-</sect3>
-<sect3><title>slonik_merge_sets</title>
+ <sect3><title>slony_show_configuration</title>
+ <para>Cette commande affiche la configuration de l'environnement (c'est à dire la variable <envar>SLONYNODES</envar>).</para>
+ </sect3>
-<para>Cette commande produit un script Slonik qui fusionne deux ensembles de réplication.
-</para>
-</sect3>
-<sect3><title>slonik_move_set</title>
-
-<para>Cette commande produit un script Slonik qui déplace l'origine d'un ensemble de réplication vers un autre noeud.</para>
-</sect3>
-<sect3><title>réplication_test</title>
-
-<para>Ce script vérifie que &slony1; réplique correctement les données.</para>
-</sect3>
-<sect3><title>slonik_restart_node</title>
-
-<para>Cette commande produit un script Slonik que demande le redémarrage d'un noeud.
-Elle était particulièrement utile avant la version 1.0.5, lorsque les noeuds étaient
-bloqués suite à la mort du démon slon.</para>
-</sect3>
-<sect3><title>slonik_restart_nodes</title>
-
-<para>Cette commande produit un script Slonik qui redémarre tous les noeuds du cluster.
-Elle n'est pas très utile.</para>
-</sect3>
-<sect3><title>slony_show_configuration</title>
-
-<para>Cette commande affiche la configuration de l'environnement (c'est à dire la variable <envar>SLONYNODES</envar>).</para>
-</sect3>
-<sect3><title>slon_kill</title>
-
-<para>Cette commande tue le chien de garde slony et tous les démons slon pour un
-ensemble de réplication donné. Elle ne fonctionne que si ces processus fonctionnent sur l'hôte local, bien sûr !
-</para>
-</sect3>
-<sect3><title>slon_start</title>
-
-<para>Cette commande démarre le démon slon pour un cluster et un noeud donnés, elle utilise
-le chien de garde slon_watchdog pour s'assurer qu'il fonctionne.</para>
-</sect3>
-<sect3 id="slonwatchdog"><title>slon_watchdog</title>
-
-<para>Processus utilisé par <command>slon_start</command>.</para>
-
-</sect3><sect3><title>slon_watchdog2</title>
-
-<para>Ce script est un chien de garde plus malin; il surveille un noeud donné et relance
-le processus slon si il constate qu'aucune modification ne s'est produite depuis 20 minutes ou plus.</para>
-
-<para>Ceci est utile lorsqu'une connexion réseau est instable et que le démon slon s'arrête sans crier gare.</para>
-
-</sect3>
-<sect3><title>slonik_store_node</title>
-
-<para>Cette commande ajoute un noeud dans un cluster.</para>
-</sect3>
-<sect3><title>slonik_subscribe_set</title>
-
-<para>Ce script génère un script Slonik script pour abonner un noeud donné çà un ensemble donné.</para>
-
-</sect3><sect3><title>slonik_uninstall_nodes</title>
-
-<para>Cette commande parcours le cluster et supprime le schéma &slony1; sur tous les noeuds;
-Vous pouvez utilisez cet outil si vous souhaitez détruire la réplication sur l'ensemble du cluster. Il s'agit d'un script <emphasis>TRÈS</emphasis> dangereux !</para>
-
-</sect3><sect3><title>slonik_unsubscribe_set</title>
-
-<para>Cette commande produit un script Slonik qui désabonne un noeud d'un ensemble de réplication.</para>
-
-</sect3>
-<sect3><title>slonik_update_nodes</title>
-
-<para>Cette commande produit un script Slonik qui incite tous les noeuds à mettre à jour les fonctions &slony1;. Elle est utile lorsque l'on effectue un changement de version de &slony1;
-.</para>
-</sect3>
+ <sect3><title>slon_kill</title>
+ <para>Cette commande tue le chien de garde slony et tous les démons slon pour un
+ ensemble de réplication donné. Elle ne fonctionne que si ces processus fonctionnent sur l'hôte local, bien sûr !
+ </para>
+ </sect3>
+
+ <sect3><title>slon_start</title>
+ <para>Cette commande démarre le démon slon pour un cluster et un noeud donnés, elle utilise
+ le chien de garde slon_watchdog pour s'assurer qu'il fonctionne.</para>
+ </sect3>
+
+ <sect3 id="slonwatchdog"><title>slon_watchdog</title>
+ <para>Processus utilisé par <command>slon_start</command>.</para>
+ </sect3>
+
+ <sect3><title>slon_watchdog2</title>
+ <para>Ce script est un chien de garde plus malin; il surveille un noeud donné et relance
+ le processus slon si il constate qu'aucune modification ne s'est produite depuis 20 minutes ou plus.</para>
+ <para>Ceci est utile lorsqu'une connexion réseau est instable et que le démon slon s'arrête sans crier gare.</para>
+ </sect3>
+
+ <sect3><title>slonik_store_node</title>
+ <para>Cette commande ajoute un noeud dans un cluster.</para>
+ </sect3>
+
+ <sect3><title>slonik_subscribe_set</title>
+ <para>Ce script génère un script Slonik script pour abonner un noeud donné çà un ensemble donné.</para>
+ </sect3>
+
+ <sect3><title>slonik_uninstall_nodes</title>
+ <para>Cette commande parcours le cluster et supprime le schéma &slony1; sur tous les noeuds;
+ Vous pouvez utilisez cet outil si vous souhaitez détruire la réplication sur l'ensemble du cluster. Il s'agit d'un script <emphasis>TRÈS</emphasis> dangereux !</para>
+ </sect3>
+
+ <sect3><title>slonik_unsubscribe_set</title>
+ <para>Cette commande produit un script Slonik qui désabonne un noeud d'un ensemble de réplication.</para>
+ </sect3>
+
+ <sect3><title>slonik_update_nodes</title>
+ <para>Cette commande produit un script Slonik qui incite tous les noeuds à mettre à jour les fonctions &slony1;. Elle est utile lorsque l'on effectue un changement de version de &slony1;.</para>
+ </sect3>
</sect2>
-
<sect2 id="mkslonconf"><title>mkslonconf.sh</title>
+ <indexterm><primary>Générer le fichier slon.conf pour &slony1;</primary></indexterm>
-<indexterm><primary>Générer le fichier slon.conf pour &slony1;</primary></indexterm>
+ <para> Ce script shell est conçu parcourir un cluster &slony1; et
+ produire un ensemble de fichiers <filename>slon.conf</filename>
+ qui pourront être utilisé via l'option <command> slon -f slon.conf </command>.
+ </para>
-<para> Ce script shell est conçu parcourir un cluster &slony1; et
-produire un ensemble de fichiers <filename>slon.conf</filename>
-qui pourront être utilisé via l'option <command> slon -f slon.conf </command>.
-</para>
+ <para> Lorsque toute la configuration est placée dans un fichier pour chaque &lslon;,
+ on peut alors facilement les invoquer, sans risquer d'oublier l'option
+ <command>-a</command>, ce qui peut provoquer le crash d'un noeud en mode
+ <link linkend="logshipping"> log shipping </link>. </para>
-<para> Lorsque toute la configuration est placée dans un fichier pour chaque &lslon;,
-on peut alors facilement les invoquer, sans risquer d'oublier l'option
-<command>-a</command>, ce qui peut provoquer le crash d'un noeud en mode
-<link linkend="logshipping"> log shipping </link>. </para>
+ <para> Pour lancer le script, il faut configurer l'environnement de la manière suivante :</para>
-<para> Pour lancer le script, il faut configurer l'environnement de la manière suivante :
-</para>
+ <itemizedlist>
+ <listitem><para> Tout d'abord, l'environnement doit être configuré avec les paramètres
+ adéquats pour que libpq puisse se connecter à une des bases de données du cluster.
+ Vous devez donc définir une combinaison parmi les variables d'environnement suivantes :
+ </para>
-<itemizedlist>
+ <itemizedlist>
+ <listitem><para><envar>PGPORT</envar></para></listitem>
+ <listitem><para><envar>PGDATABASE</envar></para></listitem>
+ <listitem><para><envar>PGHOST</envar></para></listitem>
+ <listitem><para><envar>PGUSER</envar></para></listitem>
+ <listitem><para><envar>PGSERVICE</envar></para></listitem>
+ </itemizedlist>
+ </listitem>
-<listitem><para> Tout d'abord, l'environnement doit être configuré avec les paramètres
-adéquats pour que libpq puisse se connecter à une des bases de données du cluster.
-Vous devez donc définir une combinaison parmi les variables d'environnement suivantes :
-</para>
+ <listitem>
+ <para> <envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui
+ doit être <quote>parcouru</quote>. </para>
+ </listitem>
-<itemizedlist>
-<listitem><para><envar>PGPORT</envar></para></listitem>
-<listitem><para><envar>PGDATABASE</envar></para></listitem>
-<listitem><para><envar>PGHOST</envar></para></listitem>
-<listitem><para><envar>PGUSER</envar></para><riab/listitem>
-<listitem><para><envar>PGSERVICE</envar></para></listitem>
-</itemizedlist>
+ <listitem>
+ <para> <envar>MKDESTINATION</envar> - un répertoire qui accueillera
+ la configuration; le script crée un dossier
+ <filename>MKDESTINATION/$SLONYCLUSTER/conf</filename> pour les fichiers de configuration
+ des démons &lslon; et un dossier
+ <filename>MKDESTINATION/$SLONYCLUSTER/pid</filename> pour que &lslon; y stocke
+ les fichiers PID. </para>
+ </listitem>
-</listitem>
+ <listitem>
+ <para> <envar>LOGHOME</envar> - un répertoire qui accueillera les fichiers
+ de log; un dossier nommé
+ <command>$LOGHOME/$SLONYCLUSTER/node[numéro]</command> sera créé pour chaque noeud.</para>
+ </listitem>
+
+ </itemizedlist>
+ <para> Pour chaque <quote>nouveau</quote> noeud qu'il découvre, ce script
+ va créer un nouveau fichier de configuration &lslon;. </para>
-<listitem><para> <envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui
-doit être <quote>parcouru</quote>. </para></listitem>
+ <warning>
+ <para> Il est important de préciser que ce script présente quelques particularités
+ qu'il faut connaître, même aucune n'est vraiment surprenante.</para>
-<listitem><para> <envar>MKDESTINATION</envar> - un répertoire qui accueillera
-la configuration; le script crée un dossier
-<filename>MKDESTINATION/$SLONYCLUSTER/conf</filename> pour les fichiers de configuration
-des démons &lslon; et un dossier
-<filename>MKDESTINATION/$SLONYCLUSTER/pid</filename> pour que &lslon; y stocke
-les fichiers PID. </para></listitem>
+ <itemizedlist>
+ <listitem>
+ <para> Le DSN est positionné à la plus petite valeur trouvé pour
+ chaque noeud dans le table <envar>sl_path</envar>. Vous devrez probablement
+ modifier cette valeur.</para>
+ </listitem>
-<listitem><para> <envar>LOGHOME</envar> - un répertoire qui accueillera les fichiers
-de log; un dossier nommé
-<command>$LOGHOME/$SLONYCLUSTER/node[numéro]</command> sera créé pour chaque noeud.
-</para></listitem>
+ <listitem>
+ <para> Plusieurs paramètres sont initialisés avec leur valeur par défaut;
+ Vous devrez probablement les réajuster à la main. </para>
+ </listitem>
-</itemizedlist>
+ <listitem>
+ <para> Si vous exécutez les processus &lslon; sur de multiples noeuds (<emphasis>par exemple</emphasis> - si vous utilisez &slony1; à travers un réseau WAN),
+ ce script va joyeusement créer des fichiers de configuration pour des
+ &lslon;s que vous comptez lancer sur un hôte différent. </para>
-<para> Pour chaque <quote>nouveau</quote> noeud qu'il découvre, ce script
-va créer un nouveau fichier de configuration &lslon;. </para>
+ <para> Vérifiez bien quels noeuds sont configurés avant de redémarrer les &lslon;s. </para>
-<warning><para> Il est important de préciser que ce script présente quelques particularités
-qu'il faut connaître, même aucune n'est vraiment surprenante.
-</para>
+ <para> En général, cela provoque des inconvénients mineurs,
+ comme, par exemple, un &lslon; fonctionnant de manière inapproprié,
+ échouant suite à un problème de connectivité, (ce qui ne provoque pas
+ de dégâts ! ), ou fonctionnant moins efficacement vu qu'il se trouve du mauvais
+ coté du <quote>tuyau</quote>.</para>
-<itemizedlist>
+ <para> D'un autre côté, si vous faites fonctionner un noeud en mode log shipping sur
+ le site distant, l'arrivée d'un &lslon; que
+ <emphasis>ne collecte pas</emphasis> les logs peut ruiner une semaine complète d'activité. </para>
+ </listitem>
+ </itemizedlist>
+
+ </warning>
-<listitem><para> Le DSN est positionné à la plus petite valeur trouvé pour
-chaque noeud dans le table <envar>sl_path</envar>. Vous devrez probablement
-modifier cette valeur.</para></listitem>
+ <para> Les fichiers produits par <filename>mkslonconf.sh</filename>
+ sont spécifiquement conçu pour gérer des &lslon;s sur de multiples clusters
+ avec le script décrit dans la section suivante... </para>
-<listitem><para> Plusieurs paramètres sont initialisés avec leur valeur par défaut;
-Vous devrez probablement les réajuster à la main. </para></listitem>
-
-<listitem><para> Si vous exécutez les processus &lslon; sur de multiples noeuds (<emphasis>par exemple</emphasis> - si vous utilisez &slony1; à travers un réseau WAN),
-ce script va joyeusement créer des fichiers de configuration pour des
-&lslon;s que vous comptez lancer sur un hôte différent. </para>
-
-<para> Vérifiez bien quels noeuds sont configurés avant de redémarrer les &lslon;s. </para>
-
-<para> En général, cela provoque des inconvénients mineurs,
-comme, par exemple, un &lslon; fonctionnant de manière inapproprié,
- échouant suite à un problème de connectivité, (ce qui ne provoque pas
-de dégâts ! ), ou fonctionnant moins efficacement vu qu'il se trouve du mauvais
-coté du <quote>tuyau</quote>.</para>
-
-<para> D'un autre côté, si vous faites fonctionner un noeud en mode log shipping sur
-le site distant, l'arrivée d'un &lslon; que
-<emphasis>ne collecte pas</emphasis> les logs peut ruiner une semaine complète d'activité. </para>
-</listitem>
-</itemizedlist>
-
-</warning>
-
-<para> Les fichiers produits par <filename>mkslonconf.sh</filename>
-sont spécifiquement conçu pour gérer des &lslon;s sur de multiples clusters
-avec le script décrit dans la section suivante... </para>
-
</sect2>
<sect2 id="launchclusters"><title> launch_clusters.sh </title>
-<indexterm><primary>lancer un cluster &slony1; cluster en utilisant les fichiers slon.conf </primary></indexterm>
+ <indexterm><primary>lancer un cluster &slony1; cluster en utilisant les fichiers slon.conf </primary></indexterm>
-<para> Voici un autre script shell qui utilise la configuration produite
-par <filename>mkslonconf.sh</filename> et qui peut être utilisé lors du
-démarrage du système, à la suite des processus <filename>rc.d</filename>,
-ou dans un processus cron, pour s'assurer que les processus &lslon;
-fonctionnent.</para>
+ <para> Voici un autre script shell qui utilise la configuration produite
+ par <filename>mkslonconf.sh</filename> et qui peut être utilisé lors du
+ démarrage du système, à la suite des processus <filename>rc.d</filename>,
+ ou dans un processus cron, pour s'assurer que les processus &lslon;
+ fonctionnent.</para>
-<para> Il utilise les variables d'environnement suivantes :</para>
+ <para> Il utilise les variables d'environnement suivantes :</para>
-<itemizedlist>
+ <itemizedlist>
-<listitem><para><envar>PATH</envar> qui doit contenir, de préférence au début, le
-chemin vers les binaires &lslon; qui doivent être exécutés.</para></listitem>
+ <listitem><para><envar>PATH</envar> qui doit contenir, de préférence au début, le
+ chemin vers les binaires &lslon; qui doivent être exécutés.</para></listitem>
-<listitem><para><envar>SLHOME</envar> indique le répertoire
-<quote>home</quote> qui contient les fichiers de configuration de &lslon;;
-ces fichiers doivent être rangés en sous-répertoires, un pour chaque cluster,
-avec un nom de fichier du type <filename>node1.conf</filename>,
-<filename>node2.conf</filename>, et ainsi de suite. </para>
+ <listitem><para><envar>SLHOME</envar> indique le répertoire
+ <quote>home</quote> qui contient les fichiers de configuration de &lslon;;
+ ces fichiers doivent être rangés en sous-répertoires, un pour chaque cluster,
+ avec un nom de fichier du type <filename>node1.conf</filename>,
+ <filename>node2.conf</filename>, et ainsi de suite. </para>
-<para> Le script utilise la commande <command>find $SLHOME/$cluster/conf
--name "node[0-9]*.conf"</command> pour trouver les fichiers de configuration &lslon;.</para>
+ <para> Le script utilise la commande <command>find $SLHOME/$cluster/conf
+ -name "node[0-9]*.conf"</command> pour trouver les fichiers de configuration &lslon;.</para>
-<para> Si vous déplacez ces fichiers, ou si vous les renommez, ils ne seront pas trouvés;
-c'est une façon très simple de supprimer des noeuds.</para>
-</listitem>
+ <para> Si vous déplacez ces fichiers, ou si vous les renommez, ils ne seront pas trouvés;
+ c'est une façon très simple de supprimer des noeuds.</para>
+ </listitem>
-<listitem><para><envar>LOGHOME </envar> indique le répertoire
-<quote>home</quote> pour le stockage des journaux applicatifs.</para>
+ <listitem>
+ <para><envar>LOGHOME </envar> indique le répertoire
+ <quote>home</quote> pour le stockage des journaux applicatifs.</para>
-<para> Ce script ne nécessite pas l'utilisation de gestionnaire de logs d'Apache,
-sachant que &postgres; version 8 gère lui-même la rotation des logs,
-il semble inopportun de garder une dépendance à une <quote>technologie</quote>
-de rotation spécifique. </para></listitem>
+ <para> Ce script ne nécessite pas l'utilisation de gestionnaire de logs d'Apache,
+ sachant que &postgres; version 8 gère lui-même la rotation des logs,
+ il semble inopportun de garder une dépendance à une <quote>technologie</quote>
+ de rotation spécifique. </para>
+ </listitem>
-<listitem><para><envar>CLUSTERS</envar> est la liste des clusters &slony1; qui sont gérés.
-</para></listitem>
+ <listitem><para><envar>CLUSTERS</envar> est la liste des clusters &slony1; qui sont gérés.</para>
+ </listitem>
-</itemizedlist>
+ </itemizedlist>
-<para> En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il relancera tous
-les processus &lslon; manquants. </para>
+ <para> En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il relancera tous
+ les processus &lslon; manquants. </para>
</sect2>
<sect2 id="extractschema"><title> <filename> slony1_extract_schema.sh </filename> </title>
-<indexterm><primary>script - slony1_extract_schema.sh</primary></indexterm>
+ <indexterm><primary>script - slony1_extract_schema.sh</primary></indexterm>
-<para> Si vous souhaiterez créer un nouveau noeud, après la création du cluster, le script <filename>
-slony1_extract_schema.sh </filename> vous aidera dans cette tache.</para>
+ <para> Si vous souhaiterez créer un nouveau noeud, après la création du cluster, le script <filename>
+ slony1_extract_schema.sh </filename> vous aidera dans cette tache.</para>
-<para> La commande d'exécution peut ressembler à la ligne suivante :</para>
+ <para> La commande d'exécution peut ressembler à la ligne suivante :</para>
-<para><command> PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll </command> </para>
+ <para><command> PGPORT=5881 PGHOST=master.int.example.info ./slony1_extract_schema.sh payroll payroll temppayroll </command> </para>
-<para> Elle réalise les actions suivantes :</para>
+ <para> Elle réalise les actions suivantes :</para>
-<itemizedlist>
-<listitem><para> Elle fait un dump du schéma du noeud origine, y compris les informations du schéma
-du cluster &slony1;. </para>
+ <itemizedlist>
+ <listitem><para> Elle fait un dump du schéma du noeud origine, y compris les informations du schéma
+ du cluster &slony1;. </para>
+ <para> Notons que les variables d'environnement <envar>PGPORT</envar>
+ et <envar>PGHOST</envar> fournissent des informations additionnelles sur l'emplacement de la
+ base de données. </para>
+ </listitem>
-<para> Notons que les variables d'environnement <envar>PGPORT</envar>
-et <envar>PGHOST</envar> fournissent des informations additionnelles sur l'emplacement de la
-base de données. </para></listitem>
+ <listitem><para> Ces informations sont chargées dans une table temporaire fraîchement créée : <envar>temppayroll</envar> </para>
+ </listitem>
+ <listitem><para> Les OIDs de table et de séquence dans les tables &slony1; sont corrigées pour
+ pointer vers la configuration de la base temporaire. </para> </listitem>
+ <listitem><para> Un script slonik est lancé pour effectuer l'action <xref linkend="stmtuninstallnode"/>
+ sur la base temporaire. Ceci élimine toutes les tables et le schéma spécifique à &slony1;
+ et supprime les triggers &slony1; des tables répliquées. </para> </listitem>
+ <listitem><para> Enfin, la commande <application>pg_dump</application> est lancée sur la base
+ temporaire, et produit une copie nettoyée du schéma sur la sortie standard. </para> </listitem>
+ </itemizedlist>
-<listitem><para> Ces informations sont chargées dans une table temporaire fraîchement créée : <envar>temppayroll</envar> </para> </listitem>
-<listitem><para> Les OIDs de table et de séquence dans les tables &slony1; sont corrigées pour
-pointer vers la configuration de la base temporaire. </para> </listitem>
-<listitem><para> Un script slonik est lancé pour effectuer l'action <xref linkend="stmtuninstallnode"/>
-sur la base temporaire. Ceci élimine toutes les tables et le schéma spécifique à &slony1;
-et supprime les triggers &slony1; des tables répliquées. </para> </listitem>
-<listitem><para> Enfin, la commande <application>pg_dump</application> est lancée sur la base
-temporaire, et produit une copie nettoyée du schéma sur la sortie standard. </para> </listitem>
-</itemizedlist>
-
</sect2>
<sect2><title> slony-cluster-analysis </title>
-<indexterm><primary>script - slony-cluster-analysis</primary></indexterm>
+ <indexterm><primary>script - slony-cluster-analysis</primary></indexterm>
-<para> Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters &slony1;,
-il peut devenir pénible de suivre et de documenter votre architecture.
-L'outil suivant peut vous y aider.</para>
+ <para> Si vous exploitez beaucoup de bases répliquées, au sein de plusieurs clusters &slony1;,
+ il peut devenir pénible de suivre et de documenter votre architecture.
+ L'outil suivant peut vous y aider.</para>
-<para> <application>slony-cluster-analysis.sh</application> est un script shell
-conçu pour fournir une analyse à long terme de la configuration d'un cluster
-&slony1;. Vous passez les variables d'environnement
-<application>libpq</application> habituelles
-(<envar>PGHOST</envar>, <envar>PGPORT</envar>,
-<envar>PGDATABASE</envar>, et ainsi de suite) pour se connecter à un membre du cluster
-&slony1;, et passer le nom du cluster comme argument.</para>
+ <para> <application>slony-cluster-analysis.sh</application> est un script shell
+ conçu pour fournir une analyse à long terme de la configuration d'un cluster
+ &slony1;. Vous passez les variables d'environnement
+ <application>libpq</application> habituelles
+ (<envar>PGHOST</envar>, <envar>PGPORT</envar>,
+ <envar>PGDATABASE</envar>, et ainsi de suite) pour se connecter à un membre du cluster
+ &slony1;, et passer le nom du cluster comme argument.</para>
-<para> Le script effectue alors les actions suivantes :</para>
-<itemizedlist>
-<listitem><para> Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir la liste des
-noeuds, des voies de communication, des ensembles de réplication et des tables.
- </para> </listitem>
-<listitem><para> Ces données sont stockées dans un fichier temporaire situé dans <filename>/tmp</filename> </para> </listitem>
-<listitem><para> Une comparaison est effectuée entre la configuration présente et la configuration
-trouvée lors de la dernière exécution du script. Si la configuration a changé, un courriel contenant
-les différences ( produit avec <application>diff</application>)
-est envoyée à l'adresse spécifiée. </para> </listitem>
-<listitem><para> Si la configuration a changé, l'ancien fichier de configuration est renommé
-pour indiquer quand le script a remarqué le changement. </para></listitem>
-<listitem><para> Finalement, la configuration courante est stockée dans le dossier
-<envar>LOGDIR</envar> dans un fichier nommé <filename>cluster.last </filename> </para> </listitem>
-</itemizedlist>
+ <para> Le script effectue alors les actions suivantes :</para>
+ <itemizedlist>
+ <listitem><para> Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir la liste des
+ noeuds, des voies de communication, des ensembles de réplication et des tables.
+ </para> </listitem>
+ <listitem><para> Ces données sont stockées dans un fichier temporaire situé dans <filename>/tmp</filename> </para> </listitem>
+ <listitem><para> Une comparaison est effectuée entre la configuration présente et la configuration
+ trouvée lors de la dernière exécution du script. Si la configuration a changé, un courriel contenant
+ les différences ( produit avec <application>diff</application>)
+ est envoyée à l'adresse spécifiée. </para> </listitem>
+ <listitem><para> Si la configuration a changé, l'ancien fichier de configuration est renommé
+ pour indiquer quand le script a remarqué le changement. </para></listitem>
+ <listitem><para> Finalement, la configuration courante est stockée dans le dossier
+ <envar>LOGDIR</envar> dans un fichier nommé <filename>cluster.last </filename> </para> </listitem>
+ </itemizedlist>
-<para> Il existe une exemple de script <quote>d'encapsulation</quote>,
-<filename>slony-cluster-analysis-mass.sh</filename>, qui permet de
-pointer vers un ensemble de clusters &slony1;.</para>
+ <para> Il existe une exemple de script <quote>d'encapsulation</quote>,
+ <filename>slony-cluster-analysis-mass.sh</filename>, qui permet de
+ pointer vers un ensemble de clusters &slony1;.</para>
-<para> Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux plans : </para>
+ <para> Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux plans : </para>
-<itemizedlist>
+ <itemizedlist>
-<listitem><para> La documentation de l'état courant du système.
-</para></listitem>
+ <listitem><para> La documentation de l'état courant du système.</para>
+ </listitem>
-<listitem><para> La surveillance des changements de configuration. </para></listitem>
-</itemizedlist>
+ <listitem><para> La surveillance des changements de configuration. </para></listitem>
+ </itemizedlist>
</sect2>
<sect2 id="configurereplication"> <title> Génération de scripts slonik avec
-<filename>configure-replication.sh</filename> </title>
+ <filename>configure-replication.sh</filename> </title>
-<indexterm><primary> générer des scripts slonik pour un cluster </primary></indexterm>
+ <indexterm><primary> générer des scripts slonik pour un cluster </primary></indexterm>
-<para> Le script
-<filename>configure-replication.sh</filename>, situé dans le répertoire <filename>outil</filename>,
-est conçu pour automatiser la génération de scripts slonik de configuration de la
-réplication. La configuration de ce script reprend la même approche que le <xref
-linkend="testbed"/>.</para>
+ <para> Le script
+ <filename>configure-replication.sh</filename>, situé dans le répertoire <filename>outil</filename>,
+ est conçu pour automatiser la génération de scripts slonik de configuration de la
+ réplication. La configuration de ce script reprend la même approche que le <xref
+ linkend="testbed"/>.</para>
-<para> Ce script utilise beaucoup ( peut-être énormément, si votre configuration
-est particulièrement complexe) de variables d'environnement pour déterminer
-la forme de la configuration du cluster. Il utilise massivement les valeurs par
-défaut, et dans la plupart des cas, peu de valeurs doivent être positionnées
-afin d'obtenir une configuration viable. </para>
+ <para> Ce script utilise beaucoup ( peut-être énormément, si votre configuration
+ est particulièrement complexe) de variables d'environnement pour déterminer
+ la forme de la configuration du cluster. Il utilise massivement les valeurs par
+ défaut, et dans la plupart des cas, peu de valeurs doivent être positionnées
+ afin d'obtenir une configuration viable. </para>
-<sect3><title>Valeurs Globales</title>
+ <sect3><title>Valeurs Globales</title>
-<para> Certaines valeurs sont utilisées universellement partout sur le cluster : </para>
+ <para> Certaines valeurs sont utilisées universellement partout sur le cluster : </para>
-<variablelist>
-<varlistentry><term><envar> CLUSTER </envar></term>
-<listitem><para> Le nom du cluster Slony-I </para></listitem></varlistentry>
-<varlistentry><term><envar> NUMNODES </envar></term>
-<listitem><para> Le nombre de noeuds à configurer</para></listitem></varlistentry>
+ <variablelist>
+ <varlistentry><term><envar> CLUSTER </envar></term>
+ <listitem><para> Le nom du cluster Slony-I </para></listitem></varlistentry>
+ <varlistentry><term><envar> NUMNODES </envar></term>
+ <listitem><para> Le nombre de noeuds à configurer</para></listitem></varlistentry>
-<varlistentry><term><envar> PGUSER </envar></term>
-<listitem><para> Le nom du super-utilisateur qui contrôle la réplication</para></listitem></varlistentry>
-<varlistentry><term><envar> PGPORT </envar></term>
-<listitem><para> Le numéro du port par défaut</para></listitem></varlistentry>
-<varlistentry><term><envar> PGDATABASE </envar></term>
-<listitem><para> Le nom de la base de données par défaut</para></listitem></varlistentry>
+ <varlistentry><term><envar> PGUSER </envar></term>
+ <listitem><para> Le nom du super-utilisateur qui contrôle la réplication</para></listitem></varlistentry>
+ <varlistentry><term><envar> PGPORT </envar></term>
+ <listitem><para> Le numéro du port par défaut</para></listitem></varlistentry>
+ <varlistentry><term><envar> PGDATABASE </envar></term>
+ <listitem><para> Le nom de la base de données par défaut</para></listitem></varlistentry>
-<varlistentry><term><envar> TABLES </envar></term>
-<listitem><para> une liste de noms complets de tables (<emphasis>par exemple</emphasis> - un nom
-incluant l'espace de noms tel que <command>public.ma_table</command>)</para></listitem></varlistentry>
-<varlistentry><term><envar> SEQUENCES </envar></term>
-<listitem><para> une liste de noms complets de séquences (<emphasis>par exemple</emphasis> - un nom
-incluant l'espace de noms tel que <command>public.ma_sequence</command>)</para></listitem></varlistentry>
+ <varlistentry><term><envar> TABLES </envar></term>
+ <listitem><para> une liste de noms complets de tables (<emphasis>par exemple</emphasis> - un nom
+ incluant l'espace de noms tel que <command>public.ma_table</command>)</para></listitem></varlistentry>
+ <varlistentry><term><envar> SEQUENCES </envar></term>
+ <listitem><para> une liste de noms complets de séquences (<emphasis>par exemple</emphasis> - un nom
+ incluant l'espace de noms tel que <command>public.ma_sequence</command>)</para></listitem></varlistentry>
-</variablelist>
+ </variablelist>
-<para>Des valeurs par défauts sont fournies pour <emphasis>chacune</emphasis> de ces valeurs,
-si bien que si vous lancez <filename>configure-replication.sh</filename>
-sans configurer aucune variable d'environnement, vous obtiendrez
-un ensemble de scripts slonik.
-Bien sûr, ils ne correspondront pas aux bases que vous voudrez configurer...</para>
-</sect3>
+ <para>Des valeurs par défauts sont fournies pour <emphasis>chacune</emphasis> de ces valeurs,
+ si bien que si vous lancez <filename>configure-replication.sh</filename>
+ sans configurer aucune variable d'environnement, vous obtiendrez
+ un ensemble de scripts slonik.
+ Bien sûr, ils ne correspondront pas aux bases que vous voudrez configurer...</para>
+ </sect3>
-<sect3><title>Valeur spécifique à un noeud</title>
+ <sect3><title>Valeur spécifique à un noeud</title>
-<para>Pour chaque node, il y a également quatre variables d'environnement;
-pour le noeud 1: </para>
-<variablelist>
-<varlistentry><term><envar> DB1 </envar></term>
-<listitem><para> La base de données à laquelle les scripts
-doivent se connecter</para></listitem></varlistentry>
-<varlistentry><term><envar> USER1 </envar></term>
-<listitem><para> Le super-utilisateur utilisé pour la connexion</para></listitem></varlistentry>
-<varlistentry><term><envar> PORT1 </envar></term>
-<listitem><para> Le port</para></listitem></varlistentry>
-<varlistentry><term><envar> HOST1 </envar></term>
-<listitem><para> L'hôte</para></listitem></varlistentry>
-</variablelist>
+ <para>Pour chaque node, il y a également quatre variables d'environnement;
+ pour le noeud 1: </para>
+ <variablelist>
+ <varlistentry>
+ <term><envar> DB1 </envar></term>
+ <listitem><para> La base de données à laquelle les scripts doivent se connecter</para></listitem>
+ </varlistentry>
+ <varlistentry><term><envar> USER1 </envar></term>
+ <listitem><para> Le super-utilisateur utilisé pour la connexion</para></listitem>
+ </varlistentry>
+ <varlistentry><term><envar> PORT1 </envar></term>
+ <listitem><para> Le port</para></listitem>
+ </varlistentry>
+ <varlistentry><term><envar> HOST1 </envar></term>
+ <listitem><para> L'hôte</para></listitem>
+ </varlistentry>
+ </variablelist>
-<para> Il est très probable que <envar>DB*</envar>,
-<envar>USER*</envar>, et <envar>PORT*</envar> correspondent aux
-variables globales <envar>PGDATABASE</envar>, <envar>PGUSER</envar>, et
-<envar>PGPORT</envar> décrites précédemment;
-Conserver cette correspondance est souvent une bonne chose.</para>
+ <para> Il est très probable que <envar>DB*</envar>,
+ <envar>USER*</envar>, et <envar>PORT*</envar> correspondent aux
+ variables globales <envar>PGDATABASE</envar>, <envar>PGUSER</envar>, et
+ <envar>PGPORT</envar> décrites précédemment;
+ Conserver cette correspondance est souvent une bonne chose.</para>
-<para> En revanche, Les valeurs <envar>HOST*</envar> doivent être définies
-explicitement pour <envar>HOST1</envar>, <envar>HOST2</envar>, ...,
-car il n'est pas très malin de mettre en place un système de réplication
-si toutes les bases redondantes se trouvent sur le même serveur !</para>
+ <para> En revanche, Les valeurs <envar>HOST*</envar> doivent être définies
+ explicitement pour <envar>HOST1</envar>, <envar>HOST2</envar>, ...,
+ car il n'est pas très malin de mettre en place un système de réplication
+ si toutes les bases redondantes se trouvent sur le même serveur !</para>
-</sect3>
+ </sect3>
+ <sect3><title>Les scripts slonik générés</title>
+ <para> Les scripts de configuration slonik sont générés dans un répertoire
+ temporaire à l'intérieur de <filename>/tmp</filename>.
+ Leur usage est le suivant :</para>
-<sect3><title>Les scripts slonik générés</title>
+ <itemizedlist>
-<para> Les scripts de configuration slonik sont générés dans un répertoire
-temporaire à l'intérieur de <filename>/tmp</filename>.
-Leur usage est le suivant :</para>
+ <listitem> <para><filename>preamble.slonik</filename> est un fichier
+ <quote>préambule</quote> contenant les informations de connexion utilisées
+ par les autres scripts.</para>
-<itemizedlist>
+ <para> Vérifier attentivement celui-ci; vous pourrez le réutiliser pour
+ les futures opérations de maintenance que vous effectuerez sur le cluster.</para>
+ </listitem>
-<listitem> <para><filename>preamble.slonik</filename> est un fichier
-<quote>préambule</quote> contenant les informations de connexion utilisées
-par les autres scripts.</para>
+ <listitem><para> <filename>create_set.slonik</filename></para>
-<para> Vérifier attentivement celui-ci; vous pourrez le réutiliser pour
-les futures opérations de maintenance que vous effectuerez sur le cluster.
-</para></listitem>
+ <para>Ce script est le premier qu'il faut lancer; il paramètre les noeuds
+ spécifiés en noeud &slony1;, en y ajoutant les tables et les autres objets
+ spécifiques de &slony1;.
+ </para>
-<listitem><para> <filename>create_set.slonik</filename></para>
+ <para>Vous pouvez/devez lancer les processus slon juste après cette étape.</para>
+ </listitem>
+ <listitem><para><filename> store_paths.slonik</filename></para>
-<para>Ce script est le premier qu'il faut lancer; il paramètre les noeuds
-spécifiés en noeud &slony1;, en y ajoutant les tables et les autres objets
-spécifiques de &slony1;.
-</para>
+ <para> Le second script à exécuter; il indique comment
+ les &lslon;s doivent communiquer entre eux. Ce script suppose que
+ tous les &lslon; peuvent parler à tous les noeuds, ce qui n'est peut-être
+ exact dans un environnement peuplé de pare-feux complexes. Si cette supposition
+ n'est pas correcte, vous devez modifier ce script pour corriger les voies de
+ communications.</para>
+ </listitem>
-<para>Vous pouvez/devez lancer les processus slon juste après cette étape.</para></listitem>
+ <listitem>
+ <para><filename>create_set.slonik</filename></para>
+
+ <para> Ce script configure l'ensemble de réplication composé de toutes
+ les tables et les séquences présente dans le schéma de la base de données
+ de votre application.</para>
+
+ <para> Lorsque vous lancez ce script, la seule actions menées est
+ l'ajout de triggers sur le noeud origine (noeud #1) qui vont commencer
+ à collecter les mises à jours. La réplication ne commencera qu'à
+ l'étape #5...</para>
+
+ <para>Il y a deux suppositions dans ce scripts qui peuvent ne pas être
+ valides dans certaines circonstances:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para> que toutes les tables et les séquences soit répliquées.</para>
+ <para> Ceci n'est pas valide lorsque de nouvelles tables
+ sont ajoutée dans votre schéma et qu'elles ne sont pas ajoutées
+ dans le liste <envar>TABLES</envar>.</para>
+ </listitem>
+ <listitem>
+ <para> que toutes les tables sont définies avec des clefs primaires.</para>
+ <para> La bonne pratique est de toujours créer et utiliser de vraies clefs
+ primaires.
+ Si vous avez des tables qui nécessite de choisir une clef primaire candidate ou
+ qui nécessite la création d'une clef additionnelle avec la commande <xref
+ linkend="stmttableaddkey"/>, vous devez modifier ce script à la main pour l'accommoder.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para> <filename> subscribe_set_2.slonik </filename></para>
-<listitem><para><filename> store_paths.slonik</filename></para>
+ <para> et 3, 4, 5, si vous configurez d'autres noeuds... </para>
+
+ <para> Ceci est l'étape qui <quote>déclenche</quote>
+ réplication.</para>
-<para> Le second script à exécuter; il indique comment
-les &lslon;s doivent communiquer entre eux. Ce script suppose que
-tous les &lslon; peuvent parler à tous les noeuds, ce qui n'est peut-être
-exact dans un environnement peuplé de pare-feux complexes. Si cette supposition
-n'est pas correcte, vous devez modifier ce script pour corriger les voies de
-communications.</para></listitem>
+ <para> Ce script fait la supposition que tous les noeuds abonnés voudront
+ s'abonner directement au noeud origine. Si vous souhaitez mettre en place
+ des <quote>sous-clusters</quote>,avec peut-être un noeud maître dans chaque
+ datacenter, vous devez modifier ces scripts.</para>
-<listitem><para><filename>create_set.slonik</filename></para>
-
-<para> Ce script configure l'ensemble de réplication composé de toutes
-les tables et les séquences présente dans le schéma de la base de données
-de votre application.</para>
-
-<para> Lorsque vous lancez ce script, la seule actions menées est
-l'ajout de triggers sur le noeud origine (noeud #1) qui vont commencer
-à collecter les mises à jours. La réplication ne commencera qu'à
-l'étape #5...</para>
-
-<para>Il y a deux suppositions dans ce scripts qui peuvent ne pas être
-valides dans certaines circonstances:</para>
-
-<itemizedlist>
- <listitem><para> que toutes les tables et les séquences soit répliquées.</para>
-
- <para> Ceci n'est pas valide lorsque de nouvelles tables
- sont ajoutée dans votre schéma et qu'elles ne sont pas ajoutées
- dans le liste <envar>TABLES</envar>.</para> </listitem>
-
- <listitem><para> que toutes les tables sont définies avec des clefs primaires.</para>
-
- <para> La bonne pratique est de toujours créer et utiliser de vraies clefs
- primaires.
-
- Si vous avez des tables qui nécessite de choisir une clef primaire candidate ou
-qui nécessite la création d'une clef additionnelle avec la commande <xref
- linkend="stmttableaddkey"/>, vous devez modifier ce script à la main pour l'accommoder.
- </para></listitem>
-
-</itemizedlist>
-</listitem>
-
-<listitem><para> <filename> subscribe_set_2.slonik </filename></para>
-
- <para> et 3, 4, 5, si vous configurez d'autres noeuds... </para>
-
- <para> Ceci est l'étape qui <quote>déclenche</quote>
- réplication.</para>
-
- <para> Ce script fait la supposition que tous les noeuds abonnés voudront
-s'abonner directement au noeud origine. Si vous souhaitez mettre en place
-des <quote>sous-clusters</quote>,avec peut-être un noeud maître dans chaque
-datacenter, vous devez modifier ces scripts.</para>
-
-<para> Les processus slon doivent fonctionner au moment ou vous réaliser cette
-étape. Il est absurde de lancer ces scripts lorsque ce n'est pas le cas.
-</para> </listitem>
-</itemizedlist>
-
-</sect3>
+ <para> Les processus slon doivent fonctionner au moment ou vous réaliser cette
+ étape. Il est absurde de lancer ces scripts lorsque ce n'est pas le cas.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect3>
</sect2>
<sect2 id="bsd-ports-profile"> <title> <filename> slon.in-profiles </filename> </title>
-<subtitle> profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename> </subtitle>
+ <subtitle> profiles dans le style d'Apache pour FreeBSD <filename>ports/databases/slony/*</filename> </subtitle>
-<indexterm><primary> profiles dans le style d'Apache pour FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm>
+ <indexterm><primary> profiles dans le style d'Apache pour FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm>
-<para> Dans le répertoire <filename>tools</filename>, le script <filename>slon.in-profiles</filename> permet de lancer des instances
-&lslon; lors du démarrage du système. Il est conçu pour interagir avec
-systèmes des ports de FreeBSD.</para>
+ <para> Dans le répertoire <filename>tools</filename>, le script <filename>slon.in-profiles</filename> permet de lancer des instances
+ &lslon; lors du démarrage du système. Il est conçu pour interagir avec
+ systèmes des ports de FreeBSD.</para>
</sect2>
<sect2 id="duplicate-node"> <title> <filename> duplicate-node.sh </filename> </title>
-<indexterm><primary> dupliquer un noeud </primary> </indexterm>
-<para> Dans le répertoire <filename>tools</filename>, le script
-<filename>duplicate-node.sh</filename> aide à créer un nouveau noeud
-en dupliquant un des noeuds du cluster.
-</para>
+ <indexterm><primary> dupliquer un noeud </primary> </indexterm>
+ <para> Dans le répertoire <filename>tools</filename>, le script
+ <filename>duplicate-node.sh</filename> aide à créer un nouveau noeud
+ en dupliquant un des noeuds du cluster.</para>
-<para> Ce script attend les paramètres suivants : </para>
-<itemizedlist>
-<listitem><para> Le nom du cluster</para> </listitem>
-<listitem><para> Le numéro du nouveau noeud </para> </listitem>
-<listitem><para> Le noeud origine </para> </listitem>
-<listitem><para> Le noeud répliqué </para> </listitem>
-<listitem><para> Le nouveau noeud </para> </listitem>
-</itemizedlist>
+ <para> Ce script attend les paramètres suivants : </para>
+ <itemizedlist>
+ <listitem><para> Le nom du cluster</para> </listitem>
+ <listitem><para> Le numéro du nouveau noeud </para> </listitem>
+ <listitem><para> Le noeud origine </para> </listitem>
+ <listitem><para> Le noeud répliqué </para> </listitem>
+ <listitem><para> Le nouveau noeud </para> </listitem>
+ </itemizedlist>
+ <para> Pour chaque noeud spécifié, le scripts permet de préciser
+ les paramètres de type <function>libpq</function> pour
+ <envar>PGHOST</envar>, <envar>PGPORT</envar>,
+ <envar>PGDATABASE</envar>, et <envar>PGUSER</envar>; Le fichier
+ <filename>.pgpass</filename> peut être utilisé pour le stockage
+ des mots de passe, ce qui est généralement considéré comme une
+ bonne pratique. Lorsqu'elle ne sont pas définie, ces valeurs peuvent
+ hériter des variables d'environnement <function>libpq</function>,
+ ce qui est pratique quand on réalise des tests. Toutefois
+ lorsque que ce script est utilisé <quote>de manière brutale</quote>,
+ il est souvent nécessaire de définir les 14 paramètres disponibles.</para>
-<para> Pour chaque noeud spécifié, le scripts permet de préciser
-les paramètres de type <function>libpq</function> pour
-<envar>PGHOST</envar>, <envar>PGPORT</envar>,
-<envar>PGDATABASE</envar>, et <envar>PGUSER</envar>; Le fichier
-<filename>.pgpass</filename> peut être utilisé pour le stockage
-des mots de passe, ce qui est généralement considéré comme une
-bonne pratique. Lorsqu'elle ne sont pas définie, ces valeurs peuvent
-hériter des variables d'environnement <function>libpq</function>,
-ce qui est pratique quand on réalise des tests. Toutefois
-lorsque que ce script est utilisé <quote>de manière brutale</quote>,
-il est souvent nécessaire de définir les 14 paramètres disponibles.
-</para>
+ <para> Ce script prépare des fichiers, placés dans
+ <filename>/tmp</filename>, et annonce le nom du répertoire
+ qu'il a créé pour les scripts SQL et &lslonik; de configuration
+ du nouveau noeud. </para>
-<para> Ce script prépare des fichiers, placés dans
-<filename>/tmp</filename>, et annonce le nom du répertoire
-qu'il a créé pour les scripts SQL et &lslonik; de configuration
-du nouveau noeud. </para>
+ <itemizedlist>
+ <listitem>
+ <para><filename> schema.sql </filename></para>
+ <para> Ce script est tiré du noeud origine et contient le schéma
+ de données <quote>originel</quote> qui doit être appliqué au départ.</para>
+ </listitem>
+ <listitem>
+ <para> <filename> slonik.preamble </filename> </para>
+ <para> Ce fichier <quote>preamble</quote> est utilisé par l'ensemble des scripts slonik ci-dessous. </para>
+ </listitem>
+ <listitem>
+ <para> <filename> step1-storenode.slonik </filename> </para>
+ <para> Un script &lslonik; qui configure le nouveau noeud.</para>
+ </listitem>
+ <listitem>
+ <para> <filename> step2-storepath.slonik </filename> </para>
+ <para> Un script &lslonik; qui met en place les voies de communication entre
+ le noeud fournisseur et le nouveau noeud. </para>
+ </listitem>
+ <listitem>
+ <para> <filename> step3-subscribe-sets.slonik </filename> </para>
+ <para> Un script &lslonik; qui demande la souscriptions à tous les ensembles de
+ réplications.</para>
+ </listitem>
+ </itemizedlist>
+ <para> Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner
+ un nouveau noeud. La configuration ne doit pas forcément correspondre à une
+ configuration finale, notamment :</para>
+ <itemizedlist>
+ <listitem>
+ <para> Il est souhaitable de construire des voies de communication
+ supplémentaires afin d'assurer leur redondance. </para>
+ </listitem>
+ <listitem>
+ <para> Les scripts générés supposent que le nouveau noeud doit
+ être un noeud transmetteur ("forwarding"); ce qui n'est pas forcément vrai. </para>
+ </listitem>
+ <listitem>
+ <para> Il est parfois souhaitable, une fois que le processus d'abonnement
+ est réalisé complètement, de modifier les abonnements. </para>
+ </listitem>
+ </itemizedlist>
-<itemizedlist>
-<listitem><para> <filename> schema.sql </filename> </para>
-<para> Ce script est tiré du noeud origine et contient le schéma
-de données <quote>originel</quote> qui doit être appliqué au départ.</para></listitem>
-<listitem><para> <filename> slonik.preamble </filename> </para>
-
-<para> Ce fichier <quote>preamble</quote> est utilisé par l'ensemble des scripts slonik ci-dessous. </para> </listitem>
-
-<listitem><para> <filename> step1-storenode.slonik </filename> </para>
-<para> Un script &lslonik; qui configure le nouveau noeud.<para> </listitem>
-<listitem><para> <filename> step2-storepath.slonik </filename> </para>
-<para> Un script &lslonik; qui met en place les voies de communication entre
-le noeud fournisseur et le nouveau noeud. </para> </listitem>
-<listitem><para> <filename> step3-subscribe-sets.slonik </filename> </para>
-<para> Un script &lslonik; qui demande la souscriptions à tous les ensembles de
-réplications.</para> </listitem>
-</itemizedlist>
-
-<para> Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner
-un nouveau noeud. La configuration ne doit pas forcément correspondre à une
-configuration finale, notamment :</para>
-
-<itemizedlist>
-<listitem><para> Il est souhaitable de construire des voies de communication
-supplémentaires afin d'assurer leur redondance. </para> </listitem>
-<listitem><para> Les scripts générés supposent que le nouveau noeud doit
-être un noeud transmetteur ("forwarding"); ce qui n'est pas forcément vrai. </para> </listitem>
-<listitem><para> Il est parfois souhaitable, une fois que le processus d'abonnement
-est réalisé complètement, de modifier les abonnements. </para> </listitem>
-</itemizedlist>
-
</sect2>
-</sect1>
\ No newline at end of file
+</sect1>
Modified: traduc/trunk/slony/bestpractices.xml
===================================================================
--- traduc/trunk/slony/bestpractices.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/bestpractices.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -5,682 +5,660 @@
révision $Revision$ -->
<sect1 id="bestpractices">
-<title> &slony1; <quote>Bonnes Pratiques</quote> </title>
-<indexterm><primary>bonnes pratiques pour utiliser &slony1;</primary></indexterm>
-
-<para> Il est courant pour les administrateurs de vouloir exploiter des systèmes
+ <title> &slony1; <quote>Bonnes Pratiques</quote> </title>
+ <indexterm><primary>bonnes pratiques pour utiliser &slony1;</primary></indexterm>
+ <para> Il est courant pour les administrateurs de vouloir exploiter des systèmes
en utilisant un ensemble de <quote>bonnes pratiques</quote> disponibles et documentées.
Documenter ce genre de choses est essentiel pour l'ISO 9000, l'ISO 9001,
et d'autres type de certifications d'organisation. </para>
-<para> Il est intéressant d'introduire toute discussion sur des <quote>bonnes
-pratiques</quote> en mentionnant que chaque organisation utilisant &slony1; est unique,
-et qu'il est nécessaire qu'une politique locale reflète les caractéristiques administratives locales.
-C'est pour cette raison que &slony1; n'impose <emphasis>as</emphasis> ses propres règles pour des
-choses telles que <link linkend="failover">les bascules d'urgence</link>; elles devront être déterminées
-en fonction de l'architecture globale de votre réseau, de votre ensemble de serveurs de base de données,
-et de votre manière d'utiliser ces serveurs.</para>
+ <para> Il est intéressant d'introduire toute discussion sur des <quote>bonnes
+ pratiques</quote> en mentionnant que chaque organisation utilisant &slony1; est unique,
+ et qu'il est nécessaire qu'une politique locale reflète les caractéristiques administratives locales.
+ C'est pour cette raison que &slony1; n'impose <emphasis>as</emphasis> ses propres règles pour des
+ choses telles que <link linkend="failover">les bascules d'urgence</link>; elles devront être déterminées
+ en fonction de l'architecture globale de votre réseau, de votre ensemble de serveurs de base de données,
+ et de votre manière d'utiliser ces serveurs.</para>
-<para> Il y a toutefois, un certain nombre de choses que les pionniers de &slony1; ont
+ <para> Il y a toutefois, un certain nombre de choses que les pionniers de &slony1; ont
découvertes qui peuvent au moins aider à concevoir le genre de règles d'administration
que vous pourriez mettre en place. </para>
+ <itemizedlist>
+ <listitem>
+ <para> &slony1; est système multi-clients et multi-serveurs complexe,
+ ce qui implique qu'il existe un ensemble presque infini d'endroits
+ où des problèmes peuvent surgir.</para>
-<itemizedlist>
+ <para> c'est donc naturellement que la maintenance d'un environnement propre, cohérent
+ est réellement décisif, car tout type de <quote>cafouillage</quote> dans l'environnement
+ peut provoquer des problèmes ou masquer le problème réel. </para>
-<listitem>
-<para> &slony1; est système multi-clients et multi-serveurs complexe,
-ce qui implique qu'il existe un ensemble presque infini d'endroits
-où des problèmes peuvent surgir.</para>
+ <para> De nombreux utilisateurs ont rapportés des problèmes provenants d'incompatibilités
+ entre les versions de &slony1;, les librairies locales, et les librairies de &postgres;.
+ Chaque détail compte : vous devez identifier clairement sur quels hôtes sont hébergées
+ quelles versions de quels logiciels. </para>
-<para> c'est donc naturellement que la maintenance d'un environnement propre, cohérent
- est réellement décisif, car tout type de <quote>cafouillage</quote> dans l'environnement
- peut provoquer des problèmes ou masquer le problème réel. </para>
+ <para> Normalement il s'agit juste d'être discipliné lors du déploiement de vos logiciels, et
+ ce défi est une conséquence naturelle lorsqu'on met en place un système distribué constitué
+ par un grand nombre de composants qui doivent correspondre.</para>
+ </listitem>
-<para> De nombreux utilisateurs ont rapportés des problèmes provenants d'incompatibilités
- entre les versions de &slony1;, les librairies locales, et les librairies de &postgres;.
- Chaque détail compte : vous devez identifier clairement sur quels hôtes sont hébergées
- quelles versions de quels logiciels. </para>
+ <listitem>
+ <para> Si un script slonik ne fonctionne pas comme prévu à la première
+ tentative, il serait téméraire de tenter de l'exécuter à nouveau tant que le
+ problème n'a pas été trouvé et résolu. </para>
-<para> Normalement il s'agit juste d'être discipliné lors du déploiement de vos logiciels, et
- ce défi est une conséquence naturelle lorsqu'on met en place un système distribué constitué
- par un grand nombre de composants qui doivent correspondre.</para>
-</listitem>
+ <para> Il y a très peu de commandes slonik tel que <xref
+ linkend="stmtstorepath"/> qui se comporte de manière déterministe;
+ si vous exécuter <xref linkend="stmtstorepath"/> plusieurs fois,
+ cela mettra plusieurs fois la même valeur dans la table
+ <envar>sl_path</envar>. </para>
-<listitem><para> Si un script slonik ne fonctionne pas comme prévu à la première
- tentative, il serait téméraire de tenter de l'exécuter à nouveau tant que le
- problème n'a pas été trouvé et résolu. </para>
+ <para> Au contraire <xref linkend="stmtsubscribeset"/> se comporte de
+ deux manières <emphasis>très</emphasis> différentes selon si
+ l'abonnement a déjà été activé ou pas; si l'initialisation de
+ l'abonnement n'a pas fonctionné à la toute première tentative,
+ soumettre à nouveau cette requête n'arrangera <emphasis>pas</emphasis>
+ la situation. </para>
+ </listitem>
-<para> Il y a très peu de commandes slonik tel que <xref
-linkend="stmtstorepath"/> qui se comporte de manière déterministe;
- si vous exécuter <xref linkend="stmtstorepath"/> plusieurs fois,
- cela mettra plusieurs fois la même valeur dans la table
- <envar>sl_path</envar>. </para>
+ <listitem>
+ <para> Principe: Utilisez un zone de temps ("timezone") stable et non-ambigüe
+ tel que UTC ou GMT.</para>
-<para> Au contraire <xref linkend="stmtsubscribeset"/> se comporte de
- deux manières <emphasis>très</emphasis> différentes selon si
- l'abonnement a déjà été activé ou pas; si l'initialisation de
- l'abonnement n'a pas fonctionné à la toute première tentative,
- soumettre à nouveau cette requête n'arrangera <emphasis>pas</emphasis>
- la situation. </para>
-</listitem>
+ <para> Les utilisateurs ont rencontrés des problèmes pour faire fonctionner
+ &lslon; correctement lorsque leur système utilisait une zone de temps que
+ &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est nécessaire
+ que vous utilisiez une zone de temps que &postgres; reconnaît correctement.
+ De plus, il est préférable d'utiliser une zone qui n'est pas soumise au
+ basculement entre heure d'été et heure d'hivers.</para>
-<listitem>
-<para> Principe: Utilisez un zone de temps ("timezone") stable et non-ambigüe
- tel que UTC ou GMT.</para>
+ <para> Le choix <quote>géographiquement neutre</quote> semble être
+ <command><envar>TZ</envar>=UTC</command> ou
+ <command><envar>TZ</envar>=GMT</command>, par ailleurs Assurez-vous que
+ vos serveurs sont <quote>synchronisés</quote> grâce à l'utilisation
+ de NTP sur l'ensemble de votre environnement. </para>
-<para> Les utilisateurs ont rencontrés des problèmes pour faire fonctionner
- &lslon; correctement lorsque leur système utilisait une zone de temps que
- &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est nécessaire
- que vous utilisiez une zone de temps que &postgres; reconnaît correctement.
- De plus, il est préférable d'utiliser une zone qui n'est pas soumise au
- basculement entre heure d'été et heure d'hivers.</para>
+ <para> Voir aussi <xref linkend="times"/>.</para>
+ </listitem>
-<para> Le choix <quote>géographiquement neutre</quote> semble être
- <command><envar>TZ</envar>=UTC</command> ou
-<command><envar>TZ</envar>=GMT</command>, par ailleurs Assurez-vous que
-vos serveurs sont <quote>synchronisés</quote> grâce à l'utilisation
-de NTP sur l'ensemble de votre environnement. </para>
+ <listitem>
+ <para> Principe: Les transactions longues c'est mal </para>
-<para> Voir aussi <xref linkend="times"/>.</para>
-</listitem>
+ <para> La FAQ a un chapitre sur la <link linkend="pglistenerfull">croissance de
+ &pglistener; </link> qui explique tout cela en détails; pour simplifier :
+ les transactions longues ont de nombreux effets secondaires. Elles sont problématiques
+ en particulier sur un noeud <quote>origine</quote>, s'accaparant les verrous, rendant inefficace
+ les vacuums , et ainsi de suite.</para>
-<listitem>
-<para> Principe: Les transactions longues c'est mal </para>
+ <para> Dans la version 1.2, certains comportement <quote>désagréables</quote> devraient
+ être diminués car :</para>
-<para> La FAQ a un chapitre sur la<link linkend="pglistenerfull">croissance de
- &pglistener; </link> qui explique tout cela en détails; pour simplifier :
-les transactions longues ont de nombreux effets secondaires. Elles sont problématiques
-en particulier sur un noeud <quote>origine</quote>, s'accaparant les verrous, rendant inefficace
-les vacuums , et ainsi de suite.</para>
+ <itemizedlist>
+ <listitem>
+ <para> Les événements dans &pglistener; sont seulement générés lorsque
+ les mise à jours de réplication sont relativement rare, ce qui devrait
+ impliquer que les systèmes chargés ne vont pas générer beaucoup de tuples morts
+ dans cette table.</para>
+ </listitem>
-<para> Dans la version 1.2, certains comportement <quote>désagréables</quote> devraient
- être diminués car :</para>
+ <listitem>
+ <para> Le système va périodiquement faire une rotation (en utilisant
+ <command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les deux tables de logs,
+ <xref linkend="table.sl-log-1"/> et <xref linkend="table.sl-log-2"/>, évitant une croissance illimitée de l'espace <quote>mort</quote> à cet endroit. </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>Les règles de <link linkend="failover"> Bascule en urgence </link>
+ devraient être planifiées à l'avance. </para>
-<itemizedlist>
+ <para> Cela peut simplement se résumer à réfléchir à une liste
+ de priorité indiquant ce qui devrait basculer vers quoi, plutôt
+ que d'essayer d'automatiser la bascule. Quoiqu'il en soit savoir
+ au préalable ce qu'il faut faire réduit le nombre d'erreurs commises.</para>
-<listitem><para> Les événements dans &pglistener; sont seulement générés lorsque
- les mise à jours de réplication sont relativement rare, ce qui devrait
- impliquer que les systèmes chargés ne vont pas générer beaucoup de tuples morts
- dans cette table.
-</para></listitem>
+ <para> Chez Afilias, une grande variété de guide interne, tel que <citation>Le guide
+ de l'administrateur réveillé à 3 heures du matin..</citation>, ont été
+ rédigé pour fournir les procédures à suivre en cas d'événements <quote>malheureux</quote>.
+ Ce genre de matériel est hautement spécifique à l'environnement et à l'ensemble d'applications
+ présentes, donc vous devriez rédiger vos propres documents. Ceci est un des composants vitaux de
+ tout procédure de reprise après crash.</para>
+ </listitem>
-<listitem><para> Le système va périodiquement faire une rotation (en utilisant
- <command>TRUNCATE</command> pour nettoyer l'ancienne table) entre les deux tables de logs,
- <xref linkend="table.sl-log-1"/> et <xref
-linkend="table.sl-log-2"/>, évitant une croissance illimitée de l'espace <quote>mort</quote> à cet endroit. </para></listitem>
-</itemizedlist>
+ <listitem>
+ <para> <xref linkend="stmtmoveset"/> doit être utlisé� pour
+ la maintenance préventive afin d'éviter l'apparition des
+ problèmes nécessitant une <link linkend="failover">
+ bascule après panne ("failover") </link>. </para>
+ </listitem>
-</listitem>
+ <listitem>
+ <para> La politique de <command>VACUUM</command> doit être
+ définie avec soin.</para>
-<listitem>
-<para>Les règles de <link linkend="Failover"> Bascule en urgence </link>
- devraient être planifiées à l'avance. </para>
+ <para> Comme indiqué précédemment, <quote>les transactions longues sont maléfiques.</quote>
+ La commande <command>VACUUM</command> n'est pas une exception à cette règle.
+ Un <command>VACUUM</command> sur une grande table ouvrira une transaction longue
+ qui aura tous les effets négatifs déjà cités.</para>
+ </listitem>
-<para> Cela peut simplement se résumer à réfléchir à une liste
- de priorité indiquant ce qui devrait basculer vers quoi, plutôt
- que d'essayer d'automatiser la bascule. Quoiqu'il en soit savoir
- au préalable ce qu'il faut faire réduit le nombre d'erreurs commises.
- </para>
+ <listitem>
+ <para> Si vous utiliser le processus autovacuum process avec une
+ version récente de &postgres;, vous pouvez éviter de le faire pour les tables &slony1;
+ car &slony1; est un peu plus intelligent que le démon autovaccuum lorsqu'il s'agit de
+ vacuum dans des conditions de réplication ( <emphasis>par exemple</emphasis> : la purge
+ des anciennes données ).</para>
-<para> Chez Afilias, une grande variété de guide interne, tel que <citation>Le guide
- de l'administrateur réveillé à 3 heures du matin..</citation>, ont été
- rédigé pour fournir les procédures à suivre en cas d'événements <quote>malheureux</quote>.
- Ce genre de matériel est hautement spécifique à l'environnement et à l'ensemble d'applications
- présentes, donc vous devriez rédiger vos propres documents. Ceci est un des composants vitaux de
- tout procédure de reprise après crash.
-</para>
-</listitem>
+ <para> Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus de
+ détails. </para>
+ </listitem>
-<listitem><para> <xref linkend="stmtmoveset"/> doit être utlisé� pour
-la maintenance préventive afin d'éviter l'apparition des
-problèmes nécessitant une <link linkend="failover">
-bascule après panne ("failover") </link>. </para>
-</listitem>
-<listitem> <para> La politique de <command>VACUUM</command> doit être
-définie avec soin.</para>
+ <listitem>
+ <para> Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon;
+ sur un serveur central pour chaque sous-réseau. </para>
-<para> Comme indiqué précédemment, <quote>les transactions longues sont maléfiques.</quote>
- La commande <command>VACUUM</command> n'est pas une exception à cette règle.
- Un <command>VACUUM</command> sur une grande table ouvrira une transaction longue
- qui aura tous les effets négatifs déjà cités.</para>
-</listitem>
+ <para> Chaque &lslon; doit être hébergé par hôte sur le même réseau local que
+ le noeud qu'il opère, car il envoie <emphasis>beaucoup</emphasis> de
+ communications avec sa base de donnée et que la connexion doit être aussi fiable
+ que possible.</para>
-<listitem><para> Si vous utiliser le processus autovacuum process avec une
- version récente de &postgres;, vous pouvez éviter de le faire pour les tables &slony1;
- car &slony1; est un peu plus intelligent que le démon autovaccuum lorsqu'il s'agit de
- vacuum dans des conditions de réplication ( <emphasis>par exemple</emphasis> : la purge
- des anciennes données ).</para>
+ <para> En théorie, les <quote>meilleures</quote> performances sont prévues lorsque
+ le &lslon; fonctionne sur le même serveur que la base qu'il opère. </para>
-<para> Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus de
-détails. </para> </listitem>
+ <para> En pratique, déployer les processus &lslon; processes et leur configuration
+ à travers un réseau d'une douzaine de serveurs se révèle être difficilement gérable.</para>
+ </listitem>
+ <listitem>
+ <para>Les processus &lslon; doivent évoluer dans le même
+ <quote>contexte réseau</quote> que le noeud qu'il opère, afin que la
+ liaison entre eux soir une connexion <quote>locale</quote>.
+ N'établissez <emphasis>pas</emphasis> ce genre de liaison à
+ travers un réseau WAN. </para>
-<listitem> <para> Il a été prouvé qu'il est préférable d'exécuter tous les démons &lslon;
- sur un serveur central pour chaque sous-réseau. </para>
+ <para> Une coupure de lien WAN peut provoquer des connexions
+ <quote>zombies</quote>, et le comportement typique du TCP/IP consiste à
+ <link linkend="multipleslonconnections"> laisser ces connexions persister,
+ empêchant le démon slon de redémarrer pendant environ deux heures. </link></para>
-<para> Chaque &lslon; doit être hébergé par hôte sur le même réseau local que
- le noeud qu'il opère, car il envoie <emphasis>beaucoup</emphasis> de
- communications avec sa base de donnée et que la connexion doit être aussi fiable
- que possible.</para>
+ <para> Il n'est pas difficile de remédier à cela; Vous devez simplement tuer les
+ processus liés aux connexions persistantes avec la commande <command>kill
+ SIGINT</command>. Cependant en exécutant les &lslon; localement, vous êtes
+ généralement à l'abri de ce genre de problèmes. </para>
+ </listitem>
-<para> En théorie, les <quote>meilleures</quote> performances sont prévues lorsque
- le &lslon; fonctionne sur le même serveur que la base qu'il opère. </para>
+ <listitem>
+ <para> Si vous rencontrez ce genre de problèmes, avant de vous exciter,
+ essayez de tuer et redémarrer tous les processus &lslon;.
+ Historiquement, cette méthode a souvent résolu ce genre de
+ <quote>petit tracas.</quote>.</para>
-<para> En pratique, déployer les processus &lslon; processes et leur configuration
- à travers un réseau d'une douzaine de serveurs se révèle être difficilement gérable.</para>
-</listitem>
+ <para>A quelques rares exceptions, il n'est pas très grave de tuer et relancer les
+ processus &lslon;. Chaque &lslon; se connecte à la base de données qu'il gère, puis
+ ouvre les connexions nécessaires à la propagation des événements.
+ Si vous tuer un &lslon;, vous provoquez simplement l'interruption de ces connexions.
+ Si un évènement <command>SYNC</command> ou un autre événement est en cours de propagation,
+ il n'y a pas de problème : la transaction sera annulée ("roll back") et lorsque le &lslon;
+ sera relancé, l'évènement sera retraiter à partir de zéro.</para>
-<listitem><para>Les processus &lslon; doivent évoluer dans le même
- <quote>contexte réseau</quote> que le noeud qu'il opère, afin que la
- liaison entre eux soir une connexion <quote>locale</quote>.
- N'établissez <emphasis>pas</emphasis> ce genre de liaison à
- travers un réseau WAN. </para>
+ <para> L'exception qui rend un redémarrage de &lslon; indésirable est le cas
+ où une commande <command>COPY_SET</command> est en cours d'exécution sur un
+ grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon; peut
+ annuler plusieurs heures de travail. </para>
-<para> Une coupure de lien WAN peut provoquer des connexions
- <quote>zombies</quote>, et le comportement typique du TCP/IP consiste à
- <link linkend="multipleslonconnections"> laisser ces connexions persister,
- empêchant le démon slon de redémarrer pendant environ deux heures. </link>
-</para>
+ <para> Dans les premières versions de &slony1;, il était fréquent que
+ des connexions soient un peu <quote>dérangée</quote>, ce qu'on pouvait
+ réparer en redémarrant &lslon;. Ceci est devenu nettement plus rare,
+ mais il est parfois utile de redémarrer &lslon;. En cas de
+ <quote>panne réseau</quote>, cela peut résoudre le problème des
+ connexions à la base défuntes.</para>
+ </listitem>
-<para> Il n'est pas difficile de remédier à cela; Vous devez simplement tuer les
- processus liés aux connexions persistantes avec la commande <command>kill
-SIGINT</command>. Cependant en exécutant les &lslon; localement, vous êtes
-généralement à l'abri de ce genre de problèmes. </para>
-</listitem>
+ <listitem>
+ <para>La section sur les <link linkend="ddlchanges">changements de modèle de données</link>
+ détaille quelques bonnes pratiques qui sont utiles lorsque l'on souhaite modifier le
+ schémas de la base de données. </para>
+ </listitem>
-<listitem><para> Si vous rencontrez ce genre de problèmes, avant de vous exciter,
- essayez de tuer et redémarrer tous les processus &lslon;.
- Historiquement, cette méthode a souvent résolu ce genre de
- <quote>petit tracas.</quote>.</para>
+ <listitem>
+ <para> Gestion des clefs primaires </para>
-<para>A quelques rares exceptions, il n'est pas très grave de tuer et relancer les
- processus &lslon;. Chaque &lslon; se connecte à la base de données qu'il gère, puis
- ouvre les connexions nécessaires à la propagation des événements.
- Si vous tuer un &lslon;, vous provoquez simplement l'interruption de ces connexions.
- Si un évènement <command>SYNC</command> ou un autre événement est en cours de propagation,
- il n'y a pas de problème : la transaction sera annulée ("roll back") et lorsque le &lslon;
- sera relancé, l'évènement sera retraiter à partir de zéro.</para>
+ <para> Comme précisé dans la section <link linkend="definingsets">
+ Ensembles de réplication</link>, il est <emphasis>idéal</emphasis> que
+ chaque table répliquée dispose d'un vraie contrainte de clef primaire;
+ il est <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire
+ candidate.</quote></para>
-<para> L'exception qui rend un redémarrage de &lslon; indésirable est le cas
- où une commande <command>COPY_SET</command> est en cours d'exécution sur un
- grand ensemble de réplication. Dans ce genre de cas, arrêter un &lslon; peut
- annuler plusieurs heures de travail. </para>
+ <para> Il n'est <emphasis>pas recommandé</emphasis> d'utiliser une clef définie
+ par &slony1; (crée par <xref linkend="stmttableaddkey"/>) pour
+ proposer une clef primaire candidate, car cela introduit la possibilité
+ d'échecs de certaines mises à jour sur la table à cause de l'index unique de cette
+ clef. Ceci entraînerait potentiellement des bugs dans votre application à cause
+ de &slony1;.</para>
-<para> Dans les premières versions de &slony1;, il était fréquent que
- des connexions soient un peu <quote>dérangée</quote>, ce qu'on pouvait
- réparer en redémarrant &lslon;. Ceci est devenu nettement plus rare,
- mais il est parfois utile de redémarrer &lslon;. En cas de
- <quote>panne réseau</quote>, cela peut résoudre le problème des
- connexions à la base défuntes. </para> </listitem>
-<listitem>
-<para>La section sur les <link linkend="ddlchanges">changements de modèle de données</link>
-détaille quelques bonnes pratiques qui sont utiles lorsque l'on souhaite modifier le
-schémas de la base de données. </para></listitem>
+ <warning><para> Dans la version 2 de &slony1;, <xref
+ linkend="stmttableaddkey"/> n'est plus supportée. Vous <emphasis>devez</emphasis> absolument
+ avoir soit une vraie clef primaire, soit une clef primaire candidate.</para></warning>
+ </listitem>
-<listitem>
-<para> Gestion des clefs primaires </para>
+ <listitem>
+ <para> La section <link linkend="definesets"> Définir les ensembles de réplication
+ </link> vous suggère des stratégies pour déterminer comment regrouper les tables
+ et les séquences en ensembles de réplication. </para>
+ </listitem>
-<para> Comme précisé dans la section <link linkend="definingsets">
-Ensembles de réplication</link>, il est <emphasis>idéal</emphasis> que
-chaque table répliquée dispose d'un vraie contrainte de clef primaire;
-il est <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire
- candidate.</quote></para>
+ <listitem>
+ <para> Il est évident que les actions qui peuvent supprimer beaucoup
+ de données doivent être effectuées avec le plus grand soin; La section
+ <link linkend="dropthings">Supprimer des éléments de la réplication</link>
+ évoque les différentes sortes de <quote>suppression</quote> que &slony1; supporte. </para>
+ </listitem>
-<para> Il n'est <emphasis>pas recommandé</emphasis> d'utiliser une clef définie
- par &slony1; (crée par <xref linkend="stmttableaddkey"/>) pour
- proposer une clef primaire candidate, car cela introduit la possibilité
- d'échecs de certaines mises à jour sur la table à cause de l'index unique de cette
- clef. Ceci entraînerait potentiellement des bugs dans votre application à cause
- de &slony1;.</para>
+ <listitem>
+ <para> <link linkend="locking">Problèmes d'inter-blocages</link></para>
+ <para> Certaines opérations &slony1;, notament <link linkend="stmtsetaddtable"> <command>set add table</command> </link>,
+ <link linkend="stmtmoveset"> <command> move set</command> </link>,
+ <link linkend="stmtlockset"> <command> lock set </command> </link>,
+ et <link linkend="stmtddlscript"> <command>execute script</command>
+ </link> nécessite l'acquisition de <emphasis>verrous exclusifs</emphasis> sur les tables répliquées.</para>
-<warning><para> Dans la version 2 de &slony1;, <xref
-linkend="stmttableaddkey"/> n'est plus supportée. Vous <emphasis>devez</emphasis> absolument
- avoir soit une vraie clef primaire, soit une clef primaire candidate.</para></warning>
-</listitem>
+ <para> En fonction de type d'activité de votre base de données, cela
+ peut ( ou pas ) provoquer des coupures de services ( heureusement assez brèves ). </para>
+ </listitem>
-<listitem>
-<para> La section <link linkend="definesets"> Définir les ensembles de réplication
-</link> vous suggère des stratégies pour déterminer comment regrouper les tables
-et les séquences en ensembles de réplication. </para>
-</listitem>
+ <listitem>
+ <para> Que faire des ordres DDL ? </para>
-<listitem>
-<para> Il est évident que les actions qui peuvent supprimer beaucoup
- de données doivent être effectuées avec le plus grand soin; La section
- <link
-linkend="dropthings">Supprimer des éléments de la réplication</link>
-évoque les différentes sortes de <quote>suppression</quote> que &slony1;
-supporte. </para>
-</listitem>
+ <para> &slony1; fonctionne en détectant les mises à jour sur les tables
+ grâce à des triggers qui sont placés sur ces tables.
+ Cela implique que les mises à jours que sont font au moyen de
+ méthodes qui ne déclenche pas les triggers ne seront pas propagées.
+ Les commandes <command>ALTER TABLE</command>, <command>CREATE OR
+ REPLACE FUNCTION</command>, <command>CREATE TABLE</command>, sont toutes
+ des requêtes SQL que &slony1; ne peut pas détecter. </para>
+
+ <para> Pour ce genre de situation, la philosophie de &slony1;
+ consiste à considérer que les développeurs compétents n'écrivent
+ jamais de code auto-modifiant et en particulier du code modifiant
+ les modèles de données à la volée. &slony1; ne cherche pas à faciliter
+ ce genre de modification du schémas de données. </para>
+
+ <para> Cependant il existe des cas où cela est nécessaire, ainsi la <link
+ linkend="stmtddlscript"> <command>execute script</command> est fournie
+ pour appliquer des changements DDL au même point dans
+ le flux de transactions sur tous les serveurs.</link> </para>
+
+ <para> Malheureusement, cela provoque de nombreux verrous sur
+ les objets de la base de données. Modifier les tables nécessite
+ de l'acquisition d'un verrou exclusif sur ces objets; ainsi le
+ <command>script d'exécution des modification</command> entraîne
+ un verrous exclusif sur <emphasis>toutes</emphasis> les tables
+ répliquées. Cela peut s'avérer très problématiques lorsque les
+ applications fonctionnent; des inter-blocages ("deadlocks") peuvent
+ alors se produire.</para>
-<listitem>
-<para> <link linkend="Locking">Problèmes d'inter-blocages</link></para>
+ <para> Une position particulièrement dogmatique défendue par certains
+ consiste à dire qu'il faut <emphasis>toujours</emphasis> propager
+ les changements de modèles de données avec un <command>script d'exécution</command>.
+ Cela garantit que les noeuds restent consistants, cependant le coût des verrous
+ et des inter-blocages est trop élevé pour certains utilisateurs.</para>
-<para> Certaines opérations &slony1;, notament <link
-linkend="stmtsetaddtable"> <command>set add table</command> </link>,
-<link linkend="stmtmoveset"> <command> move set</command> </link>,
-<link linkend="stmtlockset"> <command> lock set </command> </link>,
-et <link linkend="stmtddlscript"> <command>execute script</command>
-</link> nécessite l'acquisition de <emphasis>verrous exclusifs</emphasis> sur les
-tables répliquées.</para>
+ <para> Chez Afilias, notre approche est moins dogmatique; il y a
+ <emphasis>certains</emphasis> changements qui
+ <emphasis>doivent</emphasis> être appliquées avec un <command>script d'exécution</command>,
+ mais nous appliquons certaines modification de manière indépendante.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para> Liste de changements qui doivent être effectuée dans un <command>script d'exécution</command> :</para>
+ <itemizedlist>
+ <listitem>
+ <para> Toutes les commandes <command>ALTER TABLE</command></para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para> Listes des changement qui ne nécessitent pas un <command>script d'exécution :</command> </para>
+ <itemizedlist>
+ <listitem>
+ <para> <command>CREATE INDEX</command> </para>
+ </listitem>
+ <listitem>
+ <para> <command>CREATE TABLE</command> </para>
+ <para> Les tables qui ne sont pas répliquées n'ont pas besoin de ces mécanismes.</para>
+ </listitem>
+ <listitem>
+ <para> <command>CREATE OR REPLACE FUNCTION </command> </para>
+ <para> Typiquement, le chargement de nouvelles version de fonctions
+ peut être effectuée sans que &slony1; en soit <quote>averti</quote>.
+ A l'exception évidente des cas où la nouvelle fonction est déployée suite
+ à la modification d'une table. Dans ce cas là, la nouvelle version
+ doit être déployé de manière synchronisée avec le
+ <command>script d'exécution</command> qui modifie la table.</para>
-<para> En fonction de type d'activité de votre base de données, cela
- peut ( ou pas ) provoquer des coupures de services ( heureusement assez brèves ). </para>
-</listitem>
+ <para> De la même manière, les ordres <command>CREATE TYPE</command>, <command> CREATE
+ AGGREGATE </command>, etc. n'ont pas besoin d'être forcément insérés de
+ manière <quote>parfaitement synchronisés</quote> sur l'ensemble des noeuds.</para>
+ </listitem>
+ <listitem>
+ <para> Les ordres de gestion des autorisations, tels que <command> CREATE USER
+ </command>, <command> CREATE ROLE </command>, <command>GRANT
+ </command>, etc. sont inutile pour &slony1; car il est exécuté avec les droits
+ de <quote>super-utilisateur</quote>. </para>
-<listitem><para> Que faire des ordres DDL ? </para>
+ <para>Dans la pratique, il est utile d'avoir différentes politiques de sécurité
+ sur les noeuds. L'accès au noeud <quote>maître</quote> doit être limité aux
+ applications qui en ont réellement besoin; Les utilisateurs effectuant de
+ l'extraction de données ("reporting") ont généralement des droits plus limités
+ sur le noeud maître que sur les noeuds abonnés.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem id="slonyuser">
+ <para> Noms d'utilisateur spécifiques à &slony1;. </para>
-<para> &slony1; fonctionne en détectant les mises à jour sur les tables
- grâce à des triggers qui sont placés sur ces tables.
- Cela implique que les mises à jours que sont font au moyen de
- méthodes qui ne déclenche pas les triggers ne seront pas propagées.
- Les commandes <command>ALTER TABLE</command>, <command>CREATE OR
-REPLACE FUNCTION</command>, <command>CREATE TABLE</command>, sont toutes
-des requêtes SQL que &slony1; ne peut pas détecter. </para>
+ <para> Il s'est avéré utile de définir un utilisateur <command>slony</command> employé
+ uniquement par &slony1;, un utilisateur distinct de l'utilisateur générique
+ <command>postgres</command> ou <command>pgsql</command>. </para>
-<para> Pour ce genre de situation, la philosophie de &slony1;
- consiste à considérer que les développeurs compétents n'écrivent
- jamais de code auto-modifiant et en particulier du code modifiant
- les modèles de données à la volée. &slony1; ne cherche pas à faciliter
- ce genre de modification du schémas de données. </para>
+ <para> Lorsque toutes sortes d'activités de <quote>maintenance</quote>
+ automatiques, telles que les <command>vacuum</command> et les sauvegardes,
+ sont effectuées avec l'<quote>identité</quote> de l'utilisateur &postgres;
+ , cela peut assez facilement provoquer des problèmes d'inter-blocages ("deadlocks").</para>
-<para> Cependant il existe des cas où cela est nécessaire, ainsi la <link
-linkend="stmtddlscript"> <command>execute script</command> est fournie
- pour appliquer des changements DDL au même point dans
- le flux de transactions sur tous les serveurs.</link> </para>
+ <para> Par exemple, une série de <command>vacuums</command> qui sont
+ lancés de manière inattendue sur une base de donnée avec un gros événement
+ <command>SUBSCRIBE_SET</command> en cours d'exécution pourra entraîner des
+ inter-blocages qui annuleront plusieurs heures de travail de copie de données.
+ </para>
-<para> Malheureusement, cela provoque de nombreux verrous sur
- les objets de la base de données. Modifier les tables nécessite
- de l'acquisition d'un verrou exclusif sur ces objets; ainsi le
- <command>script d'exécution des modification</command> entraîne
- un verrous exclusif sur <emphasis>toutes</emphasis> les tables
- répliquées. Cela peut s'avérer très problématiques lorsque les
- applications fonctionnent; des inter-blocages ("deadlocks") peuvent
- alors se produire.</para>
+ <para> À l'inverse, si les différentes opérations de maintenance sont exécutées par
+ différents utilisateurs, vous pourrez assurer la réussite d'une opération vitale
+ telle que <command>SUBSCRIBE_SET</command>, en bloquant les autres utilisateurs
+ au niveau du fichier <filename>pg_hba.conf</filename>, et autorisant uniquement
+ l'utilisateur slony, ce qui réduit considérablement le risque de problèmes lors d'un
+ processus de souscription.</para>
+ </listitem>
+ <listitem>
+ <para> Configuration des chemins</para>
+ <para> La section sur les <link linkend="plainpaths"> voies de communications
+ </link> évoque les problèmes liés aux connexions réseau nécessaire au
+ bon fonctionnement de &slony1;.</para>
+ </listitem>
-<para> Une position particulièrement dogmatique défendue par certains
- consiste à dire qu'il faut <emphasis>toujours</emphasis> propager
- les changements de modèles de données avec un <command>script d'exécution</command>.
- Cela garantit que les noeuds restent consistants, cependant le coût des verrous
- et des inter-blocages est trop élevé pour certains utilisateurs.</para>
+ <listitem>
+ <para> Réduction des super-pouvoirs </para>
+ <para> Traditionellement, on considère que <quote>&slony1; a besoin
+ de connexions en mode super-utilisateurs</quote>. Cela n'est pas
+ totalement vrai et si l'usage excessif de comptes super-utilisateurs
+ pose problème, il est possible de réduire nettement cet usage.</para>
-<para> Chez Afilias, notre approche est moins dogmatique; il y a
-<emphasis>certains</emphasis> changements qui
-<emphasis>doivent</emphasis> être appliquées avec un <command>script d'exécution</command>,
-mais nous appliquons certaines modification de manière indépendante.</para>
+ <para> Il est vrai que chaque &lslon; <emphasis>doit</emphasis>
+ avoir une connexion super-utilisateur afin de gérer le noeud dont il opère.
+ Il doit pouvoir modifier le catalogue système afin de mettre en place les
+ souscriptions et procéder aux modifications
+ (<emphasis>par exemple</emphasis> - pour exécuter <xref linkend="stmtddlscript"/> et
+ d'autres évènement qui peuvent modifier le rôle d'une tables répliquées sur un noeud
+ local). </para>
-<itemizedlist>
-<listitem><para> Liste de changements qui doivent être effectuée dans un <command>script d'exécution</command> :</para>
-<itemizedlist>
-<listitem><para> Toutes les commandes <command>ALTER TABLE</command></para></listitem>
-</itemizedlist>
+ <para> Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres noeuds
+ afin d'accéder aux événements et aux souscriptions n'ont pas besoin d'avoir
+ d'autant de permissions. Ainsi, on peut mettre en place un <quote>utilisateur
+ faible</quote> assigné à toutes les requêtes <xref linkend="stmtstorepath"/>.
+ Les permissions minimales de cet utilisateur, appellons-le
+ <command>weakuser</command>, sont les suivantes :</para>
+ <itemizedlist>
+ <listitem>
+ <para> Il doit avoir accès en lecture sur le namespace spécifique de &slony1;</para>
+ </listitem>
+ <listitem>
+ <para> Il doit avoir accès en lecture sur toutes les tables et les séquences de ce namespace</para>
+ </listitem>
+ <listitem>
+ <para> Il doit avoir accès en écriture sur la table <envar>sl_nodelock</envar> et la séquence <envar>sl_nodelock_nl_conncnt_seq</envar> </para>
+ </listitem>
+ <listitem>
+ <para> Lors de la souscrition, il doit avoir accès en lecture sur toutes les tables répliquées.</para>
+ <para> Après la souscription, il n'est plus nécessaire d'accéder aux tables répliquées. </para>
+ </listitem>
+ <listitem>
+ <para> Il est parfois nécessaire de lire les tables dans pg_catalog; sans qu'on ait pu vérifier
+ à quel niveau d'accès est convenable. </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para> Dans la version 1.3, les tests du <xref linkend="testbed"/>
+ permettent l'utilisation d'un utilisateur faible (<envar>WEAKUSER</envar>) afin de
+ tester si les permissions définies sont suffisantes pour supporter la réplication.</para>
+ </listitem>
+ <listitem>
+ <para> La section sur les <link linkend="listenpaths"> voies d'écoute </link>
+ parle des problèmes entourant la table <xref linkend="table.sl-listen"/>.</para>
-</listitem>
-<listitem><para> Listes des changement qui ne nécessitent pas un <command>script d'exécution :</command> </para>
-<itemizedlist>
-<listitem><para> <command>CREATE INDEX</command> </para></listitem>
-<listitem><para> <command>CREATE TABLE</command> </para>
-<para> Les tables qui ne sont pas répliquées n'ont pas besoin de ces
- mécanismes. </para></listitem>
+ <para> A partir la version &slony1; 1.1, le contenu de cette table
+ était calculé automatiquement en se basant sur les informations
+ dont disposait &slony1; ce qui devrait supprimer les problèmes
+ rencontrés. Beaucoup de problèmes de communication inexplicables,
+ avec des noeuds qui n'arrive pas à se parler alors que c'est techniquement
+ possible, étaient du à une configuration incorrecte des voies d'écoutes.</para>
+ </listitem>
-<listitem><para> <command>CREATE OR REPLACE FUNCTION </command> </para>
+ <listitem>
+ <para> Utilisez <filename>test_slony_state.pl</filename> pour rechercher
+ les problèmes de configuration.</para>
-<para> Typiquement, le chargement de nouvelles version de fonctions
- peut être effectuée sans que &slony1; en soit <quote>averti</quote>.
- A l'exception évidente des cas où la nouvelle fonction est déployée suite
- à la modification d'une table. Dans ce cas là, la nouvelle version
- doit être déployé de manière synchronisée avec le
- <command>script d'exécution</command> qui modifie la table.</para>
+ <para>Il s'agit d'un script Perl qui se connecte à un noeud &slony1; puis
+ parcours la configuration &slony1; à la recherche de différentes conditions
+ qui indique la présence de problèmes, en particulier :</para>
+ <itemizedlist>
+ <listitem><para>le gonflement de certaines tables de congfiguration;</para></listitem>
+ <listitem><para>l'analyse des voies d'écoute;</para></listitem>
+ <listitem><para>l'analyse de la propagation et de la confirmation des événements.</para></listitem>
+ </itemizedlist>
-<para> De la même manière, les ordres <command>CREATE TYPE</command>, <command> CREATE
-AGGREGATE </command>, etc. n'ont pas besoin d'être forcément insérés de
-manière <quote>parfaitement synchronisés</quote> sur l'ensemble des noeuds.
-</para></listitem>
+ <para> Si, de manière mystérieuse, la réplication <quote>ne marche pas</quote>, cet outil
+ peut vérifier beaucoup de problèmes potentiels pour vous. </para>
+ </listitem>
+ <listitem>
+ <para> Configurer &lslon; </para>
-<listitem><para> Les ordres de gestion des autorisations, tels que <command> CREATE USER
-</command>, <command> CREATE ROLE </command>, <command>GRANT
-</command>, etc. sont inutile pour &slony1; car il est exécuté avec les droits
-de <quote>super-utilisateur</quote>. </para>
+ <para> A partir de la version 1.1, la configuration de &lslon;
+ peut être définie par ligne de commande ou dans des fichiers de
+ configuration. De <quote>bonnes</quote> pratiques sont
+ conseillédans les deux cas :
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para> Configuration via les options en ligne de commande</para>
-<para>Dans la pratique, il est utile d'avoir différentes politiques de sécurité
- sur les noeuds. L'accès au noeud <quote>maître</quote> doit être limité aux
- applications qui en ont réellement besoin; Les utilisateurs effectuant de
- l'extraction de données ("reporting") ont généralement des droits plus limités
- sur le noeud maître que sur les noeuds abonnés.</para>
+ <para> Cette approche à le mérite de rendre visible dans
+ l'environnement système toutes les options actives.
+ (Ainsi s'il y en a beaucoup cela peut devenir pénible
+ à lire)</para>
-</listitem>
-</itemizedlist>
-</listitem>
-</itemizedlist>
+ <para>Malheureusement, si vous invoquer &lslon; à partir d'une
+ ligne de commande, vous pouvez <emphasis>oublier</emphasis> d'inclure
+ la configuration de &logshiplink; et ainsi détruire les
+ séquences de logs pour les noeuds de log shipping.</para>
+ </listitem>
+ <listitem>
+ <para> A la différence des options en ligne de
+ commande les options actives ne sont <emphasis>pas</emphasis> visible.
+ Elles peuvent seulement être positionnées à partir u nom
+ et du contenu du fichier de configuration de &lslon;, et ne
+ refléteront pas les changements apparus dans le fichier de
+ configuration.</para>
-</listitem>
-
-<listitem id="slonyuser"> <para> Noms d'utilisateur spécifiques à &slony1;. </para>
-
-<para> Il s'est avéré utile de définir un utilisateur <command>slony</command> employé
- uniquement par &slony1;, un utilisateur distinct de l'utilisateur générique
-<command>postgres</command> ou <command>pgsql</command>. </para>
-
-<para> Lorsque toutes sortes d'activités de <quote>maintenance</quote>
- automatiques, telles que les <command>vacuum</command> et les sauvegardes,
- sont effectuées avec l'<quote>identité</quote> de l'utilisateur &postgres;
- , cela peut assez facilement provoquer des problèmes d'inter-blocages ("deadlocks").</para>
-
-<para> Par exemple, une série de <command>vacuums</command> qui sont
- lancés de manière inattendue sur une base de donnée avec un gros événement
- <command>SUBSCRIBE_SET</command> en cours d'exécution pourra entraîner des
- inter-blocages qui annuleront plusieurs heures de travail de copie de données.
- </para>
-
-<para> À l'inverse, si les différentes opérations de maintenance sont exécutées par
- différents utilisateurs, vous pourrez assurer la réussite d'une opération vitale
- telle que <command>SUBSCRIBE_SET</command>, en bloquant les autres utilisateurs
- au niveau du fichier <filename>pg_hba.conf</filename>, et autorisant uniquement
- l'utilisateur slony, ce qui réduit considérablement le risque de problèmes lors d'un
- processus de souscription.
-</para>
-</listitem>
-
-<listitem>
-<para> Configuration des chemins</para>
-
-<para> La section sur les <link linkend="plainpaths"> voies de communications
-</link> évoque les problèmes liés aux connexions réseau nécessaire au
-bon fonctionnement de &slony1;.</para>
-</listitem>
-
-<listitem><para> Réduction des super-pouvoirs </para>
-
-<para> Traditionellement, on considère que <quote>&slony1; a besoin
- de connexions en mode super-utilisateurs</quote>. Cela n'est pas
- totalement vrai et si l'usage excessif de comptes super-utilisateurs
- pose problème, il est possible de réduire nettement cet usage.</para>
-
-<para> Il est vrai que chaque &lslon; <emphasis>doit</emphasis>
-avoir une connexion super-utilisateur afin de gérer le noeud dont il opère.
-Il doit pouvoir modifier le catalogue système afin de mettre en place les
-souscriptions et procéder aux modifications
-(<emphasis>par exemple</emphasis> - pour exécuter <xref linkend="stmtddlscript"/> et
-d'autres évènement qui peuvent modifier le rôle d'une tables répliquées sur un noeud
-local). </para>
-
-<para> Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres noeuds
- afin d'accéder aux événements et aux souscriptions n'ont pas besoin d'avoir
- d'autant de permissions. Ainsi, on peut mettre en place un <quote>utilisateur
- faible</quote> assigné à toutes les requêtes <xref linkend="stmtstorepath"/>.
- Les permissions minimales de cet utilisateur, appellons-le
-<command>weakuser</command>, sont les suivantes :</para>
-
-<itemizedlist>
-<listitem><para> Il doit avoir accès en lecture sur le namespace spécifique de &slony1;</para> </listitem>
-<listitem><para> Il doit avoir accès en lecture sur toutes les tables et les séquences de ce namespace</para> </listitem>
-<listitem><para> Il doit avoir accès en écriture sur la table <envar>sl_nodelock</envar> et la séquence <envar>sl_nodelock_nl_conncnt_seq</envar> </para> </listitem>
-<listitem><para> Lors de la souscrition, il doit avoir accès en lecture sur toutes les tables répliquées.</para>
-<para> Après la souscription, il n'est plus nécessaire d'accéder aux tables répliquées. </para> </listitem>
-<listitem><para> Il est parfois nécessaire de lire les tables dans pg_catalog; sans qu'on ait pu vérifier
- à quel niveau d'accès est convenable. </para> </listitem>
-</itemizedlist>
-
-<para> Dans la version 1.3, les tests du <xref linkend="testbed"/>
-permettent l'utilisation d'un utilisateur faible (<envar>WEAKUSER</envar>) afin de
-tester si les permissions définies sont suffisantes pour supporter la réplication.
-</para>
-
-</listitem>
-
-<listitem><para> La section sur les <link linkend="listenpaths"> voies d'écoute </link>
- parle des problèmes entourant la table <xref linkend="table.sl-listen"/>.</para>
-
-<para> A partir la version &slony1; 1.1, le contenu de cette table
- était calculé automatiquement en se basant sur les informations
- dont disposait &slony1; ce qui devrait supprimer les problèmes
- rencontrés. Beaucoup de problèmes de communication inexplicables,
- avec des noeuds qui n'arrive pas à se parler alors que c'est techniquement
- possible, étaient du à une configuration incorrecte des voies d'écoutes.
- </para>
-</listitem>
-
-<listitem><para> Utilisez <filename>test_slony_state.pl</filename> pour rechercher
- les problèmes de configuration.</para>
-
-<para>Il s'agit d'un script Perl qui se connecte à un noeud &slony1; puis
- parcours la configuration &slony1; à la recherche de différentes conditions
- qui indique la présence de problèmes, en particulier :
-<itemizedlist>
-<listitem><para>le gonflement de certaines tables de congfiguration;</para></listitem>
-<listitem><para>l'analyse des voies d'écoute;</para></listitem>
-<listitem><para>l'analyse de la propagation et de la confirmation des événements.</para></listitem>
-</itemizedlist></para>
-
-<para> Si, de manière mystérieuse, la réplication <quote>ne marche pas</quote>, cet outil
- peut vérifier beaucoup de problèmes potentiels pour vous. </para>
-
-</listitem>
-
-<listitem>
-<para> Configurer &lslon; </para>
-
-<para> A partir de la version 1.1, la configuration de &lslon;
-peut être définie par ligne de commande ou dans des fichiers de
-configuration. De <quote>bonnes</quote> pratiques sont
-conseillédans les deux cas :
-</para>
-
-<itemizedlist>
-
-<listitem>
-<para> Configuration via les options en ligne de commande</para>
-
-<para> Cette approche à le mérite de rendre visible dans
-l'environnement système toutes les options actives.
-( Ainsi s'il y en a beaucoup cela peut devenir pénible
-à lire )</para>
-
-<para>Malheureusement, si vous invoquer &lslon; à partir d'une
-ligne de commande, vous pouvez <emphasis>oublier</emphasis> d'inclure
-la configuration de &logshiplink; et ainsi détruire les
-séquences de logs pour les noeuds de log shipping.</para>
-</listitem>
-
-<listitem> <para> A la différence des options en ligne de
-commande les options actives ne sont <emphasis>pas</emphasis> visible.
-Elles peuvent seulement être positionnées à partir u nom
-et du contenu du fichier de configuration de &lslon;, et ne
-refléteront pas les changements apparus dans le fichier de
-configuration.
-</para>
-
-<para> En plaçant les options dans un fichier, vous n'oublierez
-aucune, ce qui est plus sur pour &logshiplink;. </para>
-</listitem>
-
-</itemizedlist>
-</listitem>
-
-<listitem><para> Taches à faire loque l'on abonne un noeud </para>
-
-<para> Lorsqu'un nouveau noeud exécute l'événement <command>COPY_SET</command>
-sur un grand ensemble de réplication (<emphasis>par
-exemple</emphasis> - un ensemble qui nécessite un abonnement de
-plusieurs heures) il est prouvé qu'il est souhaitable de
-verrouiller l'accès au noeud pour tous les utilisateurs
-autres que <command>slony</command> car :
-</para>
-</listitem>
-
-<itemizedlist>
-
-<listitem><para> Les applications s'exécutent sur des
-données partiellemen copiées qui ne seront pas
-consistantes.
-</para> </listitem>
-
-<listitem><para>Il est possible que certaines applications (et
-certains scripts de maintenance) soumettent une combinaison
-de requêtes qui placeront le système dans une situation
-d'inter-blocage ("deadlock"), ce qui annulera l'événement
-<command>COPY_SET</command>, et impliquera le ré-abonnement
-complet du noeud.</para> </listitem>
-
-</itemizedlist>
-
+ <para> En plaçant les options dans un fichier, vous n'oublierez
+ aucune, ce qui est plus sur pour &logshiplink;. </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para> Taches à faire loque l'on abonne un noeud </para>
+ <para> Lorsqu'un nouveau noeud exécute l'événement <command>COPY_SET</command>
+ sur un grand ensemble de réplication (<emphasis>par
+ exemple</emphasis> - un ensemble qui nécessite un abonnement de
+ plusieurs heures) il est prouvé qu'il est souhaitable de
+ verrouiller l'accès au noeud pour tous les utilisateurs
+ autres que <command>slony</command> car :</para>
+ <itemizedlist>
+ <listitem>
+ <para> Les applications s'exécutent sur des
+ données partiellemen copiées qui ne seront pas
+ consistantes.</para>
+ </listitem>
+ <listitem>
+ <para>Il est possible que certaines applications (et
+ certains scripts de maintenance) soumettent une combinaison
+ de requêtes qui placeront le système dans une situation
+ d'inter-blocage ("deadlock"), ce qui annulera l'événement
+ <command>COPY_SET</command>, et impliquera le ré-abonnement
+ complet du noeud.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+</itemizedlist>
<para> Il <emphasis>peut</emphasis> être intéressant de
désactive la fonctionnalité<function>fsync</function> de &postgres;
-pendant le copie des données, car cela améliorera les
-performances,
+pendant le copie des données, car cela améliorera les performances,
et en cas d'échec lors de l'évènement
-<command>COPY_SET</command>,
-vous pourrez redémarrer avec un copie entière de
-l'ensemble de réplication.</para>
+<command>COPY_SET</command>, vous pourrez redémarrer avec un copie entière de l'ensemble de réplication.</para>
+<itemizedlist>
+ <listitem>
+ <para> Gestion de slonik </para>
+ <para> Les notes sur <link linkend="usingslonik">l'utilisation de
+ Slonik </link> décrivent certaines lessons apprises en
+ gérant un grand nombre de scripts <xref linkend="slonik"/>.</para>
+ <para> Voici les principes importants se sont dégagés lors de
+ la création de ces scripts :</para>
+ <itemizedlist>
+ <listitem>
+ <para>Utiliser des fichiers <quote>préambule</quote>
+ est <emphasis>hautement recommandé</emphasis> car cela implique
+ que vous utilisiez et réutilisiez des
+ préambules vérifié maintes fois.</para>
+ </listitem>
+ <listitem>
+ <para>Toute opportunité de générer automatiquement
+ la configuration soit en la récpérant dans une base de
+ données, soit en utilisant un script de génération vous
+ aidera à éviter les erreurs humaines.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>Gèrer un très grand ensemble de réplication</para>
+ <para> Certains utilisateurs ont bâti des réplications sur des
+ ensembles de plusieurs dizaines, voire plusieurs centaines de
+ gigabytes, ce qui ajoute des <quote>contraintes</quote> sur le
+ système, n particulier lorsqu'il faut plusieurs jours pour
+ effectuer un évènement <command>COPY_SET</command>.
+ Voici quelques principes qui ont été définis
+ pour gérer ce genre de situations.</para>
+ </listitem>
+ <listitem>
+ <para> Supprimer tous les index autres que les index
+ primaire lorsque l'évènement en<command>COPY_SET</command>
+ est exécuté.</para>
+
+ <para> Lorsque les données sont copiées dans une table qui
+ dispose d'index, &postgres; construit les index de manière
+ incrémentale, à la vole.
+ Ceci est beaucoup plus lent que simplement copier les donnés
+ dans une table puis de recréerchaque index <quote>ex nihilo</quote>,
+ car cette dernière opération profite de l'avantage de la
+ mémoire de tri. </para>
+
+ <para> Dans &slony1; version 1.1.5 et dans les versions
+ ultérieures, les index sont supprimés et
+ recréés automatiquement, ce qui rend caduque ce
+ conseil.</para>
+ </listitem>
+ <listitem>
+ <para> Si beaucoup de mises à jour ont lieu lorsque de
+ grands ensemble sont copiés, ceci peut mener à un nombre
+ énormed'événements<command>SYNC</command> sur le
+ noeud qui s'abonne.</para>
+ <para>Si un <command> SYNC </command> est généré
+ une fois par seconde, ceci conduit à un <quote>retard</quote>
+ de plus de 90,000 <command>SYNC</command>s par jour, pendant
+ probablement plusieurs jours. </para>
+
+ <para>Parallèlement
+ on constatera une croissance <emphasis>énorme</emphasis>
+ des tables <xref linkend="table.sl-log-1"/> et <xref
+ linkend="table.sl-seqlog"/>.
+ Malheureusement, une fois que <command>COPY_SET</command>
+ est complété, on constate que les requêtes sur
+ ces tables se font via <command>seq scans</command>,
+ mémé si le <command>SYNC</command> ne traite qu'une petite
+ partie de ces 90 000 événements<command>SYNC</command>
+ la table sera lue dans son ensemble. Dans de tel cas, il
+ est possible que le noeud abonné ne rattrape
+ jamais le noeud origine.</para>
-<listitem><para> Gestion de slonik </para>
+ <para> Plusieurs taches peuvent résoudre ce problème,
+ notamment en réglant avec soin les paramètres
+ &lslon; :</para>
+ </listitem>
+ <listitem>
+ <para>Assurez-vous qu'il existe sur le noeud
+ <quote>maître</quote>, un index sur <function> sl_log_1(log_xid)</function>.
+ S'il n'y en a pas, comme avec les versions de &slony1;
+ inférieure à la version 1.1.1, regardez dans le fichier
+ <filename> slony1_base.sql </filename> pour
+ la configuration correcte de cet index. </para>
-<para> Les notes sur <link linkend="usingslonik">l'utilisation de
-Slonik </link> décrivent certaines lessons apprises en
-gérant un grand nombre de scripts <xref linkend="slonik"/>.</para>
-
-<para> Voici les principes importants se sont dégagés lors de
-la création de ces scripts :
-
-<itemizedlist>
-
-<listitem><para>Utiliser des fichiers <quote>préambule</quote>
-est <emphasis>hautement recommandé</emphasis> car cela implique
-que vous utilisiez et réutilisiez des
-préambules vérifié maintes fois.</para></listitem>
-
-<listitem><para>Toute opportunité de générer automatiquement
-la configuration soit en la récpérant dans une base de
-données, soit en utilisant un script de génération vous
-aidera à éviter les erreurs humaines.</para></listitem>
-
-</itemizedlist>
-</para>
-</listitem>
-
-<listitem><para>Gèrer un très grand ensemble de réplication</para>
-
-<para> Certains utilisateurs ont bâti des réplications sur des
- ensembles de plusieurs dizaines, voire plusieurs centaines de
- gigabytes, ce qui ajoute des <quote>contraintes</quote> sur le
-système, n particulier lorsqu'il faut plusieurs jours pour
- effectuer un évènement <command>COPY_SET</command>.
- Voici quelques principes qui ont été définis
- pour gérer ce genre de situations.</para></listitem>
-
-
-
-<itemizedlist>
-
-<listitem><para> Supprimer tous les index autres que les index
-primaire lorsque l'évènement en<command>COPY_SET</command>
-est exécuté. </para>
-
-<para> Lorsque les données sont copiées dans une table qui
-dispose d'index, &postgres; construit les index de manière
-incrémentale, à la vole.
-Ceci est beaucoup plus lent que simplement copier les donnés
-dans une table puis de recréerchaque index <quote>ex
-nihilo</quote>,
-car cette dernière opération profite de l'avantage de la
-mémoire de tri. </para>
-
-<para> Dans &slony1; version 1.1.5 et dans les versions
-ultérieures, les index sont supprimés et
-recréés automatiquement, ce qui rend caduque ce
-conseil.
-</para>
-</listitem>
-
-<listitem><para> Si beaucoup de mises à jour ont lieu lorsque de
-grands ensemble sont copiés, ceci peut mener à un nombre
-énormed'événements<command>SYNC</command> sur le
-noeud qui s'abonne.</para>
-
-<para>Si un <command> SYNC </command> est généré
-une fois par seconde, ceci conduit à un <quote>retard</quote>
- de plus de 90,000 <command>SYNC</command>s par jour, pendant
- probablement plusieurs jours. </para>
-
-<para>Parallèlement
-on constatera une croissance <emphasis>énorme</emphasis>
-des tables <xref linkend="table.sl-log-1"/> et <xref
-linkend="table.sl-seqlog"/>.
-Malheureusement, une fois que <command>COPY_SET</command>
-est complété, on constate que les requêtes sur
-ces tables se font via <command>seq scans</command>,
-mémé si le <command>SYNC</command> ne traite qu'une petite
-partie de ces 90 000 événements<command>SYNC</command>
-la table sera lue dans son ensemble. Dans de tel cas, il
-est possible que le noeud abonné ne rattrape
-jamais le noeud origine.
-</para>
-
-<para> Plusieurs taches peuvent résoudre ce problème,
-notamment en réglant avec soin les paramètres
-&lslon; :</para>
-</listitem>
-</itemizedlist>
-
-<itemizedlist>
-
-<listitem><para>Assurez-vous qu'il existe sur le noeud
-<quote>maître</quote>, un index sur <function> sl_log_1(log_xid)
-</function>.
-S'il n'y en a pas, comme avec les versions de &slony1;
-inférieure à la version 1.1.1, regardez dans le fichier
-<filename> slony1_base.sql </filename> pour
-la configuration correcte de cet index. </para>
-
-<para> Dans les versions 1.2 et suivantes, il y a un processus
-qui ajoute automatiquement les index partiels par numéro de
-noeud
-d'origine, ce qui est la forme optimale pour ces index.
-</para>
-</listitem>
-
-<listitem><para>Sur un noeud abonné, ajouter le nombres
-d'évènements<command>SYNC</command>
-traités ensemble, en réglant le paramètre
-<xref linkend= "slon-config-sync-group-maxsize"/>
-à une valeur lui permettant une portion significative
-de la masse d'événements <command>SYNC</command>.
-</para> </listitem>
-
-<listitem><para>Sur le noeud abonné, régler le paramètre
-<xref linkend="slon-config-desired-sync-time"/>
-à 0, car le système de regroupent adaptatif des
-<command>SYNC</command>
-fonctionne a avec de petits groupes, qui sous certaines
-circonstances, donne de mauvaises performances.
-</para> </listitem>
-
-<listitem><para> Augmenter le
-<xrefls linkend="slon-config-sync-interval"/>
-sur le noeud origine <xref linkend="slon"/>
-afin que les événement<command>SYNC</command>
-soit générés moins fréquemment.
-Si un <command>SYNC</command> est simplement
-généré
-une fois par minute plutôt qu'une fois par seconde, cela
-divisera par soixante le nombre d'évènements.
-</para> </listitem>
-
-</itemizedlist>
-
-<listitem><para> Il faudra probablement utiliser le
-<xref linkend="slon-config-vac-frequency"/> pour
-désactiver les vacuum lancés par<xref linkend="slon"/>
-afin d'utiliser vos propres scripts de vacuum,
-car il y aura un masse de données non-purgeables pendant
-que les données seront copiées et
-que l'abonné commencera à rattraper le fournisseur.
-</para>
-</listitem>
-</itemizedlist>
-
+ <para> Dans les versions 1.2 et suivantes, il y a un processus
+ qui ajoute automatiquement les index partiels par numéro de noeud
+ d'origine, ce qui est la forme optimale pour ces index.</para>
+ </listitem>
+ <listitem>
+ <para>Sur un noeud abonné, ajouter le nombres
+ d'évènements<command>SYNC</command>
+ traités ensemble, en réglant le paramètre
+ <xref linkend= "slon-config-sync-group-maxsize"/>
+ à une valeur lui permettant une portion significative
+ de la masse d'événements <command>SYNC</command>. </para>
+ </listitem>
+ <listitem>
+ <para>Sur le noeud abonné, régler le paramètre
+ <xref linkend="slon-config-desired-sync-time"/>
+ à 0, car le système de regroupent adaptatif des
+ <command>SYNC</command>
+ fonctionne a avec de petits groupes, qui sous certaines
+ circonstances, donne de mauvaises performances.
+ </para>
+ </listitem>
+ <listitem>
+ <para> Augmenter le
+ <xref linkend="slon-config-sync-interval"/>
+ sur le noeud origine <xref linkend="slon"/>
+ afin que les événement<command>SYNC</command>
+ soit générés moins fréquemment.
+ Si un <command>SYNC</command> est simplement
+ généré une fois par minute plutôt qu'une fois par seconde, cela
+ divisera par soixante le nombre d'évènements.
+ </para>
+ </listitem>
+ <listitem>
+ <para> Il faudra probablement utiliser le
+ <xref linkend="slon-config-vac-frequency"/> pour
+ désactiver les vacuum lancés par<xref linkend="slon"/>
+ afin d'utiliser vos propres scripts de vacuum,
+ car il y aura un masse de données non-purgeables pendant
+ que les données seront copiées et
+ que l'abonné commencera à rattraper le fournisseur.
+ </para>
+ </listitem>
+ </itemizedlist>
</sect1>
Modified: traduc/trunk/slony/ddlchanges.xml
===================================================================
--- traduc/trunk/slony/ddlchanges.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/ddlchanges.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -61,7 +61,8 @@
<para> La conséquence de cela est qu'il est
<emphasis>vital</emphasis> que les modifications ne soient pas faites
de manière hasardeuse sur un noeud ou un autre. Les schémas doivent toujours
-rester synchronisés.</para> </listitem>
+rester synchronisés.</para>
+</listitem>
<listitem><para> Pour &lslon; aussi, à ce niveau, <quote>panic</quote>
est probablement la réponse
@@ -116,8 +117,7 @@
<listitem><para> Vous devez envisager de <link linkend="definesets"> définir des jeux de réplication </link>
représentant un plus petit nombre de tables
-de manière à ce que moins de verrous soient posés et permettent au script DDL d'être joué.
-.</para>
+de manière à ce que moins de verrous soient posés et permettent au script DDL d'être joué.</para>
<para> Si un script DDL affecte une seule table, il ne devrait pas
être nécessaire de verrouiller <emphasis>toutes</emphasis> les tables de
@@ -289,10 +289,9 @@
de remettre ces machines a niveau, de facon a ce que le script
<emphasis> s'exécute</emphasis> sans erreur.
-<warning>Attention <para> Si le script contient un <command> COMMIT;
-</command> n'importe ou avant le <command> ROLLBACK; </command>, cela va
-effectuer des changements auxquels vous ne vous attendiez pas. </para>
-</warning></para>
-</sect2>
+ <warning><para>Attention Si le script contient un <command> COMMIT;
+ </command> n'importe ou avant le <command> ROLLBACK; </command>, cela va
+ effectuer des changements auxquels vous ne vous attendiez pas.</para></warning></para>
+ </sect2>
</sect1>
Modified: traduc/trunk/slony/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/failover.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -5,348 +5,341 @@
révision $Revision$ -->
<sect1 id="failover">
-<title>Effectuer une bascule d'urgence avec &slony1;</title>
-<indexterm><primary>bascule d'urgence</primary>
- <secondary>reprise sur panne</secondary>
-</indexterm>
+ <title>Effectuer une bascule d'urgence avec &slony1;</title>
+ <indexterm><primary>bascule d'urgence</primary>
+ <secondary>reprise sur panne</secondary>
+ </indexterm>
-<sect2><title>Avant-propos</title>
+ <sect2><title>Avant-propos</title>
-<para>&slony1; est un système de réplication asynchrone. À cause de cela,
- il est presque certain qu'au moment ou le noeud origine d'un ensemble de réplication
- tombe en panne, la dernière transaction <quote>committée</quote> sur
- l'origine ne soit pas encore propagée aux abonnés. Les systèmes qui tombent
- en panne souvent soumis à une forte charge; c'est une des corollaires de la
- loi de Murphy. Ainsi le but principal est d'<emphasis>éviter</emphasis> que le serveur principal
- tombe en panne. La meilleur façon d'éviter cela est d'effectuer une
- maintenance fréquente.</para>
+ <para>&slony1; est un système de réplication asynchrone. À cause de cela,
+ il est presque certain qu'au moment ou le noeud origine d'un ensemble de réplication
+ tombe en panne, la dernière transaction <quote>committée</quote> sur
+ l'origine ne soit pas encore propagée aux abonnés. Les systèmes qui tombent
+ en panne souvent soumis à une forte charge; c'est une des corollaires de la
+ loi de Murphy. Ainsi le but principal est d'<emphasis>éviter</emphasis> que le serveur principal
+ tombe en panne. La meilleur façon d'éviter cela est d'effectuer une
+ maintenance fréquente.</para>
-<para> Ouvrir le capot d'un serveur à chaud n'est pas ce qu'on peut
- une façon <quote>professionelle</quote> d'assurer la maintenance d'un système.
- En général, les utilisateurs qui ont besoin de réplication pour
- leur sauvegarde ou leur plan de reprise sur panne, ont également des critères
- très stricts en matière de <quote> temps d'arrêt du système</quote>.
- Pour répondre à ces critères, &slony1; ne se contente de fournir des
- méthodes de reprise sur panne, il intègre également la notion de
- transfert d'origine.</para>
+ <para> Ouvrir le capot d'un serveur à chaud n'est pas ce qu'on peut
+ une façon <quote>professionelle</quote> d'assurer la maintenance d'un système.
+ En général, les utilisateurs qui ont besoin de réplication pour
+ leur sauvegarde ou leur plan de reprise sur panne, ont également des critères
+ très stricts en matière de <quote> temps d'arrêt du système</quote>.
+ Pour répondre à ces critères, &slony1; ne se contente de fournir des
+ méthodes de reprise sur panne, il intègre également la notion de
+ transfert d'origine.</para>
-<para> On suppose dans cette partie que le lecteur est familier avec l'utilitaire <xref linkend="slonik"/>
- et qu'il sait comment mettre en place une système de réplication &slony1; composé de deux noeuds.
-</para></sect2>
+ <para> On suppose dans cette partie que le lecteur est familier avec l'utilitaire <xref linkend="slonik"/>
+ et qu'il sait comment mettre en place une système de réplication &slony1; composé de deux noeuds.
+ </para>
+ </sect2>
-<sect2><title>Bascule contrôlée</title>
+ <sect2><title>Bascule contrôlée</title>
-<indexterm>
- <primary>bascule contrôlée</primary>
-</indexterm>
+ <indexterm>
+ <primary>bascule contrôlée</primary>
+ </indexterm>
-<para> Imaginons un noeud <quote>origine</quote>, appelé noeud1, avec un
- <quote>abonné</quote> appelé noeud2 (l'esclave). Une application web, placée
- sur un troisième serveur, accède à la base de données sur noeud1.
- Les deux bases sont actives et fonctionnelles, la réplication est
- est à peu près synchronisée. On contrôle la bascule avec la commande
- <xref linkend="stmtmoveset"/>.
-</para>
-<itemizedlist>
+ <para> Imaginons un noeud <quote>origine</quote>, appelé noeud1, avec un
+ <quote>abonné</quote> appelé noeud2 (l'esclave). Une application web, placée
+ sur un troisième serveur, accède à la base de données sur noeud1.
+ Les deux bases sont actives et fonctionnelles, la réplication est
+ est à peu près synchronisée. On contrôle la bascule avec la commande
+ <xref linkend="stmtmoveset"/>.</para>
+ <itemizedlist>
<listitem><para> Au moment ou nous écrivons ces lignes, basculer
- vers un autre serveur nécessite que l'application se reconnecte
- à la nouvelle base de donnée. Donc pour éviter toute complication,
- nous éteignons le serveur web. Les utilisateurs qui ont installé
- <application>pg_pool</application> pour gérer les connexions peuvent
- simplement éteindre le pool.</para>
+ vers un autre serveur nécessite que l'application se reconnecte
+ à la nouvelle base de donnée. Donc pour éviter toute complication,
+ nous éteignons le serveur web. Les utilisateurs qui ont installé
+ <application>pg_pool</application> pour gérer les connexions peuvent
+ simplement éteindre le pool.</para>
+
+ <para> Les actions à mener dépendent beaucoup de la configuration des applications qui utilisent
+ la base de données. En général, les applications qui étaient connectées à
+ l'ancienne base doivent détruire leurs connexions et en établir de nouvelles
+ vers la base qui vient d'être promue dans le rôle du <quote>/maître/</quote> rôle.
+ Il y a différentes façon de configurer cela, et donc différentes façon d'effectuer
+ la bascule :
+ <itemizedlist>
+ <listitem><para> L'application stocke le nom de la base de donnée dans un fichier.</para>
+ <para> Dans ce cas, la reconfiguration nécessite de changer la valeur dans ce fichier, d'arrêter
+ puis de relancer l'application pour qu'elle pointe vers le nouvel emplacement des données.</para>
+ </listitem>
+
+ <listitem><para> Une utilisation pertinente de DNS consiste à créer
+ <ulink url="http://www.iana.org/assignments/dns-parameters"> champs DNS </ulink>
+ CNAME qui permet à l'application d'utiliser un nom pour référencer le noeud
+ qui joue le rôle du noeud <quote>maître</quote>.</para>
+
+ <para> Dans ce cas, la reconfiguration nécessite de changer le CNAME
+ pour point et vers le nouveau serveur, de plus il faut probablement relancer
+ l'application pour rafraîchir les connexions à la base.</para>
+ </listitem>
+
+ <listitem><para> si vous utilisez <application>pg_pool</application> ou
+ un <quote>gestionnaire de connexion</quote> similaire, alors la reconfiguration
+ implique de modifier le paramètre de cet outil, à part cela la procédure est similaire
+ à l'exemple DNS/CNAME ci-dessus. </para>
+ </listitem>
+ </itemizedlist></para>
+
+
-<para> Les actions à mener dépendent beaucoup de la configuration des applications qui utilisent
- la base de données. En général, les applications qui étaient connectées à
- l'ancienne base doivent détruire leurs connexions et en établir de nouvelles
- vers la base qui vient d'être promue dans le rôle du <quote>/maître/</quote> rôle.
- Il y a différentes façon de configurer cela, et donc différentes façon d'effectuer
- la bascule :
-</para>
+ <para> Le nécessité de redémarrer l'application qui se connecte à la base dépend
+ de la manière dont elle a été conçu et des mécanismes de gestion d'erreurs de
+ connexion qui ont été implémentés; si à la suite d'une erreur elle tente
+ d'ouvrir à nouveau un connexion, alors il n'est pas nécessaire de la relancer.</para>
</listitem>
-<itemizedlist>
-
-<listitem><para> L'application stocke le nom de la base de donnée dans un fichier.</para>
-
-<para> Dans ce cas, la reconfiguration nécessite de changer la valeur dans ce fichier, d'arrêter
- puis de relancer l'application pour qu'elle pointe vers le nouvel emplacement des données.
-</para> </listitem>
-
-<listitem><para> Une utilisation pertinente de DNS consiste à créer
-<ulink url="http://www.iana.org/assignments/dns-parameters"> champs DNS </ulink>
-CNAME qui permet à l'application d'utiliser un nom pour référencer le noeud
-qui joue le rôle du noeud <quote>maître</quote>.</para>
-
-<para> Dans ce cas, la reconfiguration nécessite de changer le CNAME
-pour point et vers le nouveau serveur, de plus il faut probablement relancer
-l'application pour rafraîchir les connexions à la base.
-</para> </listitem>
-
-<listitem><para> si vous utilisez <application>pg_pool</application> ou
- un <quote>gestionnaire de connexion</quote> similaire, alors la reconfiguration
- implique de modifier le paramètre de cet outil, à part cela la procédure est similaire
- à l'exemple DNS/CNAME ci-dessus. </para> </listitem>
-
-</itemizedlist>
-
-<para> Le nécessité de redémarrer l'application qui se connecte à la base dépend
- de la manière dont elle a été conçu et des mécanismes de gestion d'erreurs de
- connexion qui ont été implémentés; si à la suite d'une erreur elle tente
- d'ouvrir à nouveau un connexion, alors il n'est pas nécessaire de la relancer.
- </para>
-
-
-
-
-<listitem><para> Un petit script <xref linkend="slonik"/> exécute les commandes
- suivantes :
+ <listitem><para> Un petit script <xref linkend="slonik"/> exécute les commandes suivantes :
+ <programlisting>
+ lock set (id = 1, origin = 1);
+ wait for event (origin = 1, confirmed = 2);
+ move set (id = 1, old origin = 1, new origin = 2);
+ wait for event (origin = 1, confirmed = 2);
+ </programlisting></para>
+ <para> Après ces commandes, l'origine ( le rôle du maître) de l'ensemble de réplication 1
+ est transféré sur le noeud 2. En fait elle n'est pas simplement transférée; le noeud1 devient
+ un abonné parfaitement synchronisé et actif. En clair, les deux noeuds ont échangé
+ leurs rôles respectifs.</para>
+ </listitem>
+
+ <listitem><para> Après la reconfiguration de l'application web (ou
+ de <application><link linkend="pgpool"> pgpool </link></application>) pour
+ qu'elle se connecte à la base du noeud 2, le serveur web est redémarré et
+ reprend son activité normale.</para>
+
+ <para> Lorsqu'on utilise un script shell, pour stopper l'application,
+ lancer le script <application>slonik</application>, déplacer les fichiers de configuration
+ et relancer l'ensemble, toute la procédure prend en général moins de 10
+ secondes.</para>
+ </listitem>
+
+ </itemizedlist>
-<programlisting>
-lock set (id = 1, origin = 1);
-wait for event (origin = 1, confirmed = 2);
-move set (id = 1, old origin = 1, new origin = 2);
-wait for event (origin = 1, confirmed = 2);
-</programlisting></para>
+ <para> Vous pouvez désormais éteindre le serveur qui héberge le noeud 1 et
+ effectuer les opérations de maintenance requise. Lorsque le démon <xref
+ linkend="slon"/> du noeud 1 est redémarré, il reprend la réplication,
+ et rattrape son retard. Une fois synchronisé, on peut exécuter la procédure
+ à nouveau pour restaurer la configuration originale.</para>
-<para> Après ces commandes, l'origine ( le rôle du maître) de l'ensemble de réplication 1
-est transféré sur le noeud 2. En fait elle n'est pas simplement transférée; le noeud1 devient
-un abonné parfaitement synchronisé et actif. En clair, les deux noeuds ont échangé
-leurs rôles respectifs.</para></listitem>
+ <para> Ceci est la meilleure méthode pour ce genre d'opération de maintenance;
+ Elle s'effectue rapidement, sous le contrôle d'un administrateur, et elle
+ n'implique aucune perte de données.</para>
-<listitem><para> Après la reconfiguration de l'application web (ou
-de <application><link linkend="pgpool"> pgpool </link></application>) pour
-qu'elle se connecte à la base du noeud 2, le serveur web est redémarré et
-reprend son activité normale.</para>
+ </sect2>
+ <sect2><title>Bascule d'urgence</title>
-<para> Lorsqu'on utilise un script shell, pour stopper l'application,
- lancer le script <application>slonik</application>, déplacer les fichiers de configuration
- et relancer l'ensemble, toute la procédure prend en général moins de 10
-secondes.</para></listitem>
+ <indexterm>
+ <primary>Bascule suite à une panne du système</primary>
+ </indexterm>
-</itemizedlist>
+ <para> Lorsque de graves problèmes apparaissent sur le serveur
+ <quote>origine</quote>, il est parfois nécessaire d'effectuer une
+ bascule ( <xref linkend="stmtfailover"/> ) vers le serveur de sauvegarde.
+ C'est cas de figure qui n'a rien de souhaitable, car les transactions
+ <quote>committées</quote> sur le serveur mais pas sur les abonnés, seront
+ perdues. Certaines de ces transactions auront peut-être été annoncées
+ à l'utilisateur final comme <quote>validées</quote>. En conséquence, les
+ bascules d'urgence doivent être considérées comme un
+ <emphasis>dernier recours</emphasis>. Le serveur origine
+ qui subit <quote>l'avarie</quote> peut être maintenu assez longtemps, il est
+ <emphasis>nettement</emphasis>
+ préférable d'effectuer une bascule contrôlée.</para>
-<para> Vous pouvez désormais éteindre le serveur qui héberge le noeud 1 et
- effectuer les opérations de maintenance requise. Lorsque le démon <xref
-linkend="slon"/> du noeud 1 est redémarré, il reprend la réplication,
- et rattrape son retard. Une fois synchronisé, on peut exécuter la procédure
- à nouveau pour restaurer la configuration originale.</para>
+ <para> &slony1; ne fournit pas de moyen de détection des pannes du système.
+ Abandonner des transactions <quote>committées</quote> est une décision
+ commerciale qui ne peut pas être prise par un système de gestion de base de données.
+ Si vous voulez placer les commandes ci-dessous dans un script exécuté
+ automatiquement par un système de surveillance, et bien .... ce sont
+ <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique
+ de bascule d'urgence. </para>
-<para> Ceci est la meilleure méthode pour ce genre d'opération de maintenance;
- Elle s'effectue rapidement, sous le contrôle d'un administrateur, et elle
- n'implique aucune perte de données.</para>
+ <itemizedlist>
-</sect2>
-<sect2><title>Bascule d'urgence</title>
+ <listitem>
+ <para>La commande <xref linkend="slonik"/>
+ <programlisting>
+ failover (id = 1, backup node = 2);
+ </programlisting>
+ </para>
-<indexterm>
- <primary>Bascule suite à une panne du système</primary>
-</indexterm>
+ <para> ordonne au noeud 2 de se considérer comme le propriétaire
+ (l'origine) de tous les sets que le noeud 1 possédait. Si il
+ existe des noeuds supplémentaire dans le cluster &slony1;
+ Tous les noeuds abonnés au noeud 1 sont avertis du changement.
+ <application>Slonik</application> va aussi envoyer une requête
+ à chaque abonné pour déterminer quel noeud à le plus haut niveau
+ de synchronisation (<emphasis>c'est à dire</emphasis> - la dernière
+ transaction <quote>committée</quote>) pour chaque ensemble de réplication.
+ et la configuration sera changé de façon à ce que le noeud 2 applique
+ d'abord ces transactions finales, avant d'autoriser l'accès en écriture
+ sur les tables.</para>
-<para> Lorsque de graves problèmes apparaissent sur le serveur
-<quote>origine</quote>, il est parfois nécessaire d'effectuer une
-bascule ( <xref linkend="stmtfailover"/> ) vers le serveur de sauvegarde.
-C'est cas de figure qui n'a rien de souhaitable, car les transactions
-<quote>committées</quote> sur le serveur mais pas sur les abonnés, seront
-perdues. Certaines de ces transactions auront peut-être été annoncées
-à l'utilisateur final comme <quote>validées</quote>. En conséquence, les
-bascules d'urgence doivent être considérées comme un
-<emphasis>dernier recours</emphasis>. Le serveur origine
-qui subit <quote>l'avarie</quote> peut être maintenu assez longtemps, il est
-<emphasis>nettement</emphasis>
-préférable d'effectuer une bascule contrôlée.</para>
+ <para> De plus, tous les noeuds qui étaient abonnés directement au noeud 1
+ considéreront désormais le noeud 2 comme leur fournisseur de données
+ pour cet ensemble de replication. Cela signifie qu'une fois que la
+ commande de bascule d'urgence est complétée, plus aucun noeud du cluster ne
+ reçoit d'information de la part du noeud 1.</para>
-<para> &slony1; ne fournit pas de moyen de détection des pannes du système.
- Abandonner des transactions <quote>committées</quote> est une décision
- commerciale qui ne peut pas être prise par un système de gestion de base de données.
- Si vous voulez placer les commandes ci-dessous dans un script exécuté
- automatiquement par un système de surveillance, et bien .... ce sont
- <emphasis>vos</emphasis> données, et <emphasis>votre</emphasis> politique
- de bascule d'urgence. </para>
+ </listitem>
-<itemizedlist>
+ <listitem>
+ <para> Reconfigurer et relancer l'application ( ou
+ <application>pgpool</application>) pour qu'elle se reconnecte
+ au noeud 2.</para>
+ </listitem>
-<listitem>
-<para>La commande <xref linkend="slonik"/>
-<programlisting>
-failover (id = 1, backup node = 2);
-</programlisting>
-</para>
+ <listitem> <para> Purger le noeud abandonné </para>
-<para> ordonne au noeud 2 de se considérer comme le propriétaire
- (l'origine) de tous les sets que le noeud 1 possédait. Si il
- existe des noeuds supplémentaire dans le cluster &slony1;
- Tous les noeuds abonnés au noeud 1 sont avertis du changement.
- <application>Slonik</application> va aussi envoyer une requête
- à chaque abonné pour déterminer quel noeud à le plus haut niveau
- de synchronisation (<emphasis>c'est à dire</emphasis> - la dernière
- transaction <quote>committée</quote>) pour chaque ensemble de réplication.
- et la configuration sera changé de façon à ce que le noeud 2 applique
- d'abord ces transactions finales, avant d'autoriser l'accès en écriture
- sur les tables.</para>
+ <para> Vous découvrirez, après la bascule, qu'il existe encore
+ beaucoup de références au noeud 1 dans la table <xref linkend="table.sl-node"/>,
+ ainsi que ses tables associées telle que <xref linkend="table.sl-confirm"/>;
+ puisque des données sont toujours présentes dans <xref linkend="table.sl-log-1"/>,
+ &slony1; ne peut pas purger immédiatement le noeud. </para>
-<para> De plus, tous les noeuds qui étaient abonnés directement au noeud 1
- considéreront désormais le noeud 2 comme leur fournisseur de données
- pour cet ensemble de replication. Cela signifie qu'une fois que la
- commande de bascule d'urgence est complétée, plus aucun noeud du cluster ne
- reçoit d'information de la part du noeud 1.</para>
+ <para> Une fois que la bascule sera complète et que le noeud 2 accepte
+ les opérations d'écriture sur les tables répliquées, il faut supprimer
+ toutes informations de configuration rémanentes avec la commande
+ <xref linkend="stmtdropnode"/> :
-</listitem>
+ <programlisting>
+ drop node (id = 1, event node = 2);
+ </programlisting>
+ </para>
-<listitem>
-<para> Reconfigurer et relancer l'application ( ou
-<application>pgpool</application>) pour qu'elle se reconnecte
-au noeud 2.</para>
-</listitem>
+ <para> Supposons que la panne résulte d'un problème matériel catastrophique
+ sur le noeud 1, il est possible qu'il ne <quote>reste</quote> plus
+ rien sur le noeud 1. Si la panne n'est pas <quote>totale</quote>,
+ ce qui est souvent le cas lors d'une coupure réseau, vous découvrirez
+ que le noeud 1 <quote>imagine</quote> toujours que rien n'a changé
+ et qu'il est dans le même état qu'avant la panne. Reportez-vous à la
+ section <xref linkend="rebuildnode1"/> pour plus de détails sur ce
+ que cela implique.</para>
-<listitem> <para> Purger le noeud abandonné </para>
+ </listitem>
+ </itemizedlist>
-<para> Vous découvrirez, après la bascule, qu'il existe encore
- beaucoup de références au noeud 1 dans la table <xref linkend="table.sl-node"/>,
- ainsi que ses tables associées telle que <xref linkend="table.sl-confirm"/>;
- puisque des données sont toujours présentes dans <xref linkend="table.sl-log-1"/>,
- &slony1; ne peut pas purger immédiatement le noeud. </para>
+ </sect2>
-<para> Une fois que la bascule sera complète et que le noeud 2 accepte
- les opérations d'écriture sur les tables répliquées, il faut supprimer
- toutes informations de configuration rémanentes avec la commande
- <xref linkend="stmtdropnode"/> :
+ <sect2><title> Automatisation de la commande <command> FAIL OVER </command> </title>
-<programlisting>
-drop node (id = 1, event node = 2);
-</programlisting>
-</para>
+ <indexterm><primary>automatisation des bascules d'urgence</primary></indexterm>
-<para> Supposons que la panne résulte d'un problème matériel catastrophique
- sur le noeud 1, il est possible qu'il ne <quote>reste</quote> plus
- rien sur le noeud 1. Si la panne n'est pas <quote>totale</quote>,
- ce qui est souvent le cas lors d'une coupure réseau, vous découvrirez
- que le noeud 1 <quote>imagine</quote> toujours que rien n'a changé
- et qu'il est dans le même état qu'avant la panne. Reportez-vous à la
- section <xref linkend="rebuildnode1"/> pour plus de détails sur ce
- que cela implique.</para>
+ <para> Si vous choisissez d'automatiser la commande <command>FAIL OVER </command>,
+ il est important de le faire <emphasis>avec soin</emphasis>. Vous
+ devez être sur que le noeud en panne est réellement en panne, et vous
+ être capable de vous assurer que le noeud en panne ne redémarre pas,
+ ce qui entraînerait un conflit entre deux noeuds capables
+ de jouer le rôle du <quote>maître</quote>. </para>
-</listitem>
-</itemizedlist>
+ <note> <para> Le fait de <quote>tirer une balle dans la
+ tête du serveur en panne</quote> ne pose pas directement
+ de problème à la réplication ou à &slony1;; &slony1; supporte
+ cela de manière assez gravieuse, car une fois qu'une est marqué
+ comme étant en panne, les autres noeuds <quote>l'oublier</quote>
+ et l'ignorer. Le problème se situe plutôt au niveau de
+ <emphasis>votre application</emphasis>.
+ Supposons que le noeud en panne soit capable de répondre
+ aux requêtes de votre application, <emphasis>cela</emphasis>
+ va certainement poser un problème qui n'a rien à voir avec &slony1;.
+ Le problème est que deux bases de données sont en mesure de répondre
+ en tant que <quote>maître</quote>. </para> </note>
-</sect2>
+ <para> Lorsqu'une bascule d'urgence est effectuée, il faut un
+ mécanisme pour dégager de force le noeud en panne hors du réseau
+ afin d'éviter toute confusion au niveau des applications.
+ Cela peut être fait via une interface SNMP qui effectue
+ une partie des opérations suivantes :
-<sect2><title> Automatisation de la commande <command> FAIL OVER </command> </title>
+ <itemizedlist>
-<indexterm><primary>automatisation des bascules d'urgence</primary></indexterm>
+ <listitem><para> Éteindre l'alimentation du serveur en panne. </para>
-<para> Si vous choisissez d'automatiser la commande <command>FAIL OVER </command>,
- il est important de le faire <emphasis>avec soin</emphasis>. Vous
- devez être sur que le noeud en panne est réellement en panne, et vous
- être capable de vous assurer que le noeud en panne ne redémarre pas,
- ce qui entraînerait un conflit entre deux noeuds capables
- de jouer le rôle du <quote>maître</quote>. </para>
+ <para> Si l'on en fait attention, le serveur peut réapparaître dans le
+ système de réplication lorsque les administrateurs le rallume. </para>
-<note> <para> Le fait de <quote>tirer une balle dans la
- tête du serveur en panne</quote> ne pose pas directement
-de problème à la réplication ou à &slony1;; &slony1; supporte
-cela de manière assez gravieuse, car une fois qu'une est marqué
-comme étant en panne, les autres noeuds <quote>l'oublier</quote>
-et l'ignorer. Le problème se situe plutôt au niveau de
-<emphasis>votre application</emphasis>.
-Supposons que le noeud en panne soit capable de répondre
-aux requêtes de votre application, <emphasis>cela</emphasis>
-va certainement poser un problème qui n'a rien à voir avec &slony1;.
-Le problème est que deux bases de données sont en mesure de répondre
-en tant que <quote>maître</quote>. </para> </note>
+ </listitem>
-<para> Lorsqu'une bascule d'urgence est effectuée, il faut un
- mécanisme pour dégager de force le noeud en panne hors du réseau
- afin d'éviter toute confusion au niveau des applications.
- Cela peut être fait via une interface SNMP qui effectue
- une partie des opérations suivantes :
+ <listitem><para> Modifier de règles de pare-feu ou d'autres configuration
+ pour exclure du réseau l'adresse IP du serveur en panne. </para>
-<itemizedlist>
+ <para> Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
+ cette approche permet de supprimer/désactiver les adresses utilisées l'application,
+ tout en conservant les adresses <quote>administratives</quote> afin
+ que le serveur reste accessible par les administrateurs systèmes.
+ </para> </listitem>
-<listitem><para> Éteindre l'alimentation du serveur en panne. </para>
+ </itemizedlist>
+ </para>
+ </sect2>
-<para> Si l'on en fait attention, le serveur peut réapparaître dans le
- système de réplication lorsque les administrateurs le rallume. </para>
+ <sect2 id="rebuildnode1"><title>Après la bascule d'urgence, reconfiguration
+ de l'ancienne origine</title>
-</listitem>
+ <indexterm><primary>reconstruction après une bascule d'urgence</primary></indexterm>
-<listitem><para> Modifier de règles de pare-feu ou d'autres configuration
- pour exclure du réseau l'adresse IP du serveur en panne. </para>
+ <para> Ce qui arrive au noeud en panne dépend beaucoup de la nature de la catastrophe
+ qui a conduit à la bascule d'urgence vers un autre noeud. Si le noeud
+ a été abandonné à cause de la destruction physique des disques de stockage,
+ il n'y a plus grand-chose à faire. D'un autre coté, si un noeud a été abandonné
+ à cause d'une coupure réseau, qui n'a pas perturbé le fonctionnement normal
+ du noeud <quote>fournisseur</quote>. Toutefois une fois que les communications
+ sont restaurées, le fait est que le commande <command>FAIL OVER</command>
+ rend obligatoire l'abandon du noeud qui était en panne.</para>
-<para> Si le serveur a de multiples interfaces, et donc de multiple adresses IP,
- cette approche permet de supprimer/désactiver les adresses utilisées l'application,
- tout en conservant les adresses <quote>administratives</quote> afin
- que le serveur reste accessible par les administrateurs systèmes.
-</para> </listitem>
+ <para> Après ce genre de bascule d'urgence, les données stockées sur le
+ noeud 1 seront rapidement et de plus en plus désynchronisées.
+ par rapport aux autres noeuds. Elles doivent être considérées comme
+ corrompues. Ainsi le seul moyen pour que le noeud 1 retourne dans
+ le cluster de réplication et qu'il redevienne le noeud origine est de
+ le reconstruire à partir de zéro comme un abonné, de le laisser rattraper
+ son retard, puis d'effectuer la procédure de bascule contrôlée.
+ </para>
-</itemizedlist>
-</para>
-</sect2>
+ <para> Une bonne raison de <emphasis>ne pas</emphasis> faire cela
+ automatiquement est que d'importante mises à jour ( d'un point de
+ vue <emphasis>commercial</emphasis> ) ont pu être
+ <quote>committée</quote> sur le système en panne.
+ Vous souhaiterez probablement analyser les dernières transactions que
+ le noeud a réalisé avant de tomber en panne, afin de voir si certaines
+ doivent être ré-appliquer sur le cluster <quote>actif</quote>.
+ Par exemple, si quelqu'un réalisait des opérations bancaires impactant
+ des comptes clients au moment de la panne, il est souhaitable de
+ ne pas perdre cette information.</para>
-<sect2 id="rebuildnode1"><title>Après la bascule d'urgence, reconfiguration
-de l'ancienne origine</title>
+ <warning> <para> On a observé certains résultats étranges lorsqu'un
+ noeud <quote>tombe en panne</quote> à cause d'une coupure réseau persistante,
+ par opposition aux pannes du système de stockage. Dans de tel scénarios,
+ le noeud <quote>en panne</quote> dispose d'une base de données en
+ parfait état de marche; le fait est qu'ayant été coupé des autres noeuds,
+ il <quote>crie en silence</quote>. </para>
-<indexterm><primary>reconstruction après une bascule d'urgence</primary></indexterm>
+ <para> Lorsque la connexion réseau est réparée, ce noeud peut réapparaître
+ et conformément <emphasis>sa</emphasis> configuration, il va communiquer avec les
+ autres noeuds du cluster &slony1;. </para>
-<para> Ce qui arrive au noeud en panne dépend beaucoup de la nature de la catastrophe
- qui a conduit à la bascule d'urgence vers un autre noeud. Si le noeud
- a été abandonné à cause de la destruction physique des disques de stockage,
- il n'y a plus grand-chose à faire. D'un autre coté, si un noeud a été abandonné
- à cause d'une coupure réseau, qui n'a pas perturbé le fonctionnement normal
- du noeud <quote>fournisseur</quote>. Toutefois une fois que les communications
- sont restaurées, le fait est que le commande <command>FAIL OVER</command>
- rend obligatoire l'abandon du noeud qui était en panne.</para>
+ <para> En <emphasis>fait</emphasis>, la confusion se trouve uniquement sur
+ ce noeud. Les autres noeud du cluster ne sont pas du tout perturbés;
+ ils savent que ce noeud est <quote>mort</quote>, et qu'ils doivent
+ l'ignorer. Mais il est impossible de savoir cela en regardent le noeud
+ qui a était <quote>en panne</quote>.
+ </para>
-<para> Après ce genre de bascule d'urgence, les données stockées sur le
- noeud 1 seront rapidement et de plus en plus désynchronisées.
- par rapport aux autres noeuds. Elles doivent être considérées comme
- corrompues. Ainsi le seul moyen pour que le noeud 1 retourne dans
- le cluster de réplication et qu'il redevienne le noeud origine est de
- le reconstruire à partir de zéro comme un abonné, de le laisser rattraper
- son retard, puis d'effectuer la procédure de bascule contrôlée.
+ <para> Ceci nous ramène au fait que &slony1; n'est pas un outil de surveillance
+ de réseau. Vous devez avoir des méthodes claires pour signaler aux applications et
+ aux utilisateurs quels bases de données doivent être utilisées. En l'absence
+ de telles méthodes, la réplication ne fera qu'empirer le potentiel de confusion,
+ et les bascules d'urgence seront un énorme potentiel de confusion.
</para>
+ </warning>
-<para> Une bonne raison de <emphasis>ne pas</emphasis> faire cela
- automatiquement est que d'importante mises à jour ( d'un point de
- vue <emphasis>commercial</emphasis> ) ont pu être
-<quote>committée</quote> sur le système en panne.
-Vous souhaiterez probablement analyser les dernières transactions que
-le noeud a réalisé avant de tomber en panne, afin de voir si certaines
-doivent être ré-appliquer sur le cluster <quote>actif</quote>.
-Par exemple, si quelqu'un réalisait des opérations bancaires impactant
-des comptes clients au moment de la panne, il est souhaitable de
-ne pas perdre cette information.</para>
+ <para> Si la base de données est très volumineuse, la construction du noeud 1
+ peut prendre plusieurs heures; ceci est une autre raison de considérer
+ les bascules d'urgence comme un <quote>dernier recours</quote> non souhaitable.
+ </para>
-<warning> <para> On a observé certains résultats étranges lorsqu'un
- noeud <quote>tombe en panne</quote> à cause d'une coupure réseau persistante,
- par opposition aux pannes du système de stockage. Dans de tel scénarios,
- le noeud <quote>en panne</quote> dispose d'une base de données en
- parfait état de marche; le fait est qu'ayant été coupé des autres noeuds,
- il <quote>crie en silence</quote>. </para>
+ </sect2>
-<para> Lorsque la connexion réseau est réparée, ce noeud peut réapparaître
- et conformément <emphasis>sa</emphasis> configuration, il va communiquer avec les
- autres noeuds du cluster &slony1;. </para>
-
-<para> En <emphasis>fait</emphasis>, la confusion se trouve uniquement sur
- ce noeud. Les autres noeud du cluster ne sont pas du tout perturbés;
- ils savent que ce noeud est <quote>mort</quote>, et qu'ils doivent
- l'ignorer. Mais il est impossible de savoir cela en regardent le noeud
- qui a était <quote>en panne</quote>.
-</para>
-
-<para> Ceci nous ramène au fait que &slony1; n'est pas un outil de surveillance
- de réseau. Vous devez avoir des méthodes claires pour signaler aux applications et
- aux utilisateurs quels bases de données doivent être utilisées. En l'absence
- de telles méthodes, la réplication ne fera qu'empirer le potentiel de confusion,
- et les bascules d'urgence seront un énorme potentiel de confusion.
-</para>
-</warning>
-
-<para> Si la base de données est très volumineuse, la construction du noeud 1
- peut prendre plusieurs heures; ceci est une autre raison de considérer
- les bascules d'urgence comme un <quote>dernier recours</quote> non souhaitable.
-</para>
-
-</sect2>
-
</sect1>
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/faq.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -34,7 +34,7 @@
<listitem><para> &slony1; la version 1.0.5 et ultérieur nécessite d'avoir une version complètement configurées des sources de &postgres;, afin de recompiler
&slony1;.</para>
-TODO
+<!-- TODO -->
<para> <emphasis>Si tout va bien </emphasis> vous pouvez refaire la configuration,
ceci contre la configuration utilisée nativement par la paquetage d'origine, en utilisant la
@@ -1283,7 +1283,7 @@
mis à jour par le planificateur <application>cron</application>même si <xref
linkend="slon"/> ne tourne pas en tâche de fond.</para> </answer></qandaentry>
-<qandaentry id="PGLISTENERFULL">
+<qandaentry id="pglistenerfull">
<question><para>Quelques noeuds commencent à se ralentir constamment. </para>
<para>J'avais lancé, depuis un moment, &slony1; sur un noeud, et je vois que la machine est à
@@ -1351,12 +1351,6 @@
LISTEN</quote> et <quote>UNLISTEN - switch into polling
mode</quote>. </para> </question>
-Les seuils pour commuter entre ces modes sont commandés par le <xref linkend="slon-config-synchro-intervalle "/>
-de <xref linkend="slon-config-synchro-intervalle-temps mort "/>
-de <xref /> ; si la valeur du dépassement de durée (qui se transfère sur 10000, impliquant 10s) est le bas gardé,
-qui le rend facile pour le &lslon; pour décider de retourner au mode de <quote>listening</quote>.
-Vous pouvez vouloir augmenter la valeur du paramètre de temps imparti
-
<answer><para> Les seuils pour commuter entre ces modes sont commandés par
le paramètres de configuration <xref
linkend="slon-config-sync-interval"/> et celui de <xref
Modified: traduc/trunk/slony/frenchtranslation.xml
===================================================================
--- traduc/trunk/slony/frenchtranslation.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/frenchtranslation.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -68,9 +68,8 @@
</tgroup>
</table>
- <para>La liste complète est disponible sur le <link
- linkend="http://svn.postgresqlfr.org/log/traduc/trunk/slony">journal
- des modifications de la branche 1.2</link>.</para>
+ <para>La liste complète est disponible sur le <ulink url="http://svn.postgresqlfr.org/log/traduc/trunk/slony">journal
+ des modifications de la branche 1.2</ulink>.</para>
<para>
De même que tout logiciel peut contenir des erreurs de programmation, toute
Modified: traduc/trunk/slony/legal.xml
===================================================================
--- traduc/trunk/slony/legal.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/legal.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -37,7 +37,7 @@
L'UNIVERSITÉ DE CALIFORNIE REFUSENT SPECIFIQUEMENT TOUTE GARANTIE,
CE IMPLIQUE, SANS CE LIMITER À CELA, LES GARANTIES DE COMMERCIALISATION
ET CORRESPONDANCE A UN USAGE PARTICULIER. LE LOGICIEL EST FOURNI
-<QUOTE>TEL QUEL</QUOTE>, ET L'UNIVERSITÉ DE CALIFORNIE N'A AUCUNE OBLIGATIONS D'EN
+<quote>TEL QUEL</quote>, ET L'UNIVERSITÉ DE CALIFORNIE N'A AUCUNE OBLIGATIONS D'EN
ASSURER LA MAINTENANCE, LA SUPPORT, LES MISES À JOUR,
OU LES MODIFICATIONS
</para>
Modified: traduc/trunk/slony/loganalysis.xml
===================================================================
--- traduc/trunk/slony/loganalysis.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/loganalysis.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -13,1185 +13,1172 @@
ainsi que des explications sur leur signification.</para>
<sect2><title>Notification CONFIG</title>
+ <para>Ces lignes sont assez triviales. Ce sont des messages d'information
+ à propos de la configuration.</para>
+ <para>Voici quelques lignes typiques que vous pouvez rencontrer :
+ <screen>
+ CONFIG main: local node id = 1
+ CONFIG main: loading current cluster configuration
+ CONFIG storeNode: no_id=3 no_comment='Node 3'
+ CONFIG storePath: pa_server=5 pa_client=1 pa_conninfo="host=127.0.0.1 dbname=foo user=postgres port=6132" pa_connretry=10
+ CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3
+ CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1'
+ CONFIG main: configuration complete - starting threads
+ </screen>
+ </para>
+</sect2>
-<para>Ces lignes sont assez triviales. Ce sont des messages d'information
-à propos de la configuration.</para>
-
-<para>Voici quelques lignes typiques que vous pouvez rencontrer :
-
-<screen>
-CONFIG main: local node id = 1
-CONFIG main: loading current cluster configuration
-CONFIG storeNode: no_id=3 no_comment='Node 3'
-CONFIG storePath: pa_server=5 pa_client=1 pa_conninfo="host=127.0.0.1 dbname=foo user=postgres port=6132" pa_connretry=10
-CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3
-CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1'
-CONFIG main: configuration complete - starting threads
-</screen></para></sect2>
-
<sect2><title>Notifications INFO</title>
-
-<para> Les événements qui semble avoir un intérêt au niveau INFO,
-et qui sont toujours listés , tout comme les notifications CONFIG.
-</para>
-
+ <para> Les événements qui semble avoir un intérêt au niveau INFO,
+ et qui sont toujours listés , tout comme les notifications CONFIG.
+ </para>
</sect2>
<sect2><title>Notifications DEBUG</title>
-<para>Les notifications DEBUG sont moins intéressantes, et ne vous seront
-utile que lorsque vous rencontrez une problème avec &slony1;.</para>
+ <para>Les notifications DEBUG sont moins intéressantes, et ne vous seront
+ utile que lorsque vous rencontrez une problème avec &slony1;.</para>
</sect2>
<sect2><title>Nom du processus </title>
-<para> Les notifications sont toujours précédées par le nom du processus
-qui produit cette notification. Vous verrez des messages en provenance
-des processus suivants :
+ <para> Les notifications sont toujours précédées par le nom du processus
+ qui produit cette notification. Vous verrez des messages en provenance
+ des processus suivants :
-<variablelist>
-<varlistentry><term>localListenThread</term>
+ <variablelist>
+ <varlistentry><term>localListenThread</term>
+ <listitem><para> Le processus local qui écoute les événements sur le noeud local.</para></listitem>
+ </varlistentry>
-<listitem><para> Le processus local qui écoute les événements sur le noeud local.</para></listitem></varlistentry>
+ <varlistentry><term>remoteWorkerThread-X</term>
+ <listitem><para> Les processus qui traitent les événements distants. Vous verrez un de
+ ces processus pour chaque noeud qui est en communication avec le noeud local.
+ </para></listitem>
+ </varlistentry>
-<varlistentry><term>remoteWorkerThread-X</term>
+ <varlistentry><term>remoteListenThread-X</term>
+ <listitem><para>Les processus qui écoutent les événements distants.
+ Vous verrez un de
+ ces processus pour chaque noeud du cluster.</para></listitem>
+ </varlistentry>
-<listitem><para> Les processus qui traitent les événements distants. Vous verrez un de
-ces processus pour chaque noeud qui est en communication avec le noeud local.
-</para></listitem></varlistentry>
+ <varlistentry><term>cleanupThread</term>
+ <listitem><para> Le processus qui prend en charge les opérations telles que
+ les VACUUM, le nettoyage des tables confirm et event,
+ et la suppression des données périmées.</para>
+ </listitem>
+ </varlistentry>
-<varlistentry><term>remoteListenThread-X</term>
+ <varlistentry><term>syncThread</term>
+ <listitem><para> Le processus qui produit les événements SYNC.</para></listitem>
+ </varlistentry>
-<listitem><para>Les processus qui écoutent les événements distants.
-Vous verrez un de
-ces processus pour chaque noeud du cluster.</para></listitem></varlistentry>
+ </variablelist>
+ </para>
-<varlistentry><term>cleanupThread</term>
-<listitem><para> Le processus qui prend en charge les opérations telles que
-les VACUUM, le nettoyage des tables confirm et event,
-et la suppression des données périmées.</para></listitem></varlistentry>
-
-<varlistentry><term>syncThread</term> <listitem>
-<para> Le processus qui produit les événements SYNC.</para>
-</listitem></varlistentry>
-
-</variablelist>
-</para>
-
-<para> La quantité d'information que ces processus affichent est contrôlée par
-le paramètre <envar>log_level</envar> de &lslon;;
-Les messages de type ERROR/WARN/CONFIG/INFO seront toujours affichés,
-augmenter la valeur de 1 à 4 affichera des plus en plus de messages de DEBUG.
-</para>
+ <para> La quantité d'information que ces processus affichent est contrôlée par
+ le paramètre <envar>log_level</envar> de &lslon;;
+ Les messages de type ERROR/WARN/CONFIG/INFO seront toujours affichés,
+ augmenter la valeur de 1 à 4 affichera des plus en plus de messages de DEBUG.
+ </para>
</sect2>
<sect2> <title> Comment lire les logs &slony1; </title>
-<indexterm><primary>lire et comprendre les logs &slony1;</primary></indexterm>
+ <indexterm><primary>lire et comprendre les logs &slony1;</primary></indexterm>
-<para> Notons que du point de vue d'un processus slon, il n'y a pas de
-<quote>maître</quote> ni d'<quote>esclave</quote>. Il y a juste des noeuds.
-</para>
+ <para> Notons que du point de vue d'un processus slon, il n'y a pas de
+ <quote>maître</quote> ni d'<quote>esclave</quote>. Il y a juste des noeuds.
+ </para>
-<para>On s'attend, de prime abord, à voir sur chaque noeuds des événements
-se propager dans les deux sens. Dans un premier temps, il doit y avoir
-des événements publiés qui témoignent de la création des noeuds et des
-voies de communications. Si vous ne les voyez pas, alors les noeuds
-ne communiquent pas correctement entre eux et rien ne va se passer...
- </para>
+ <para>On s'attend, de prime abord, à voir sur chaque noeuds des événements
+ se propager dans les deux sens. Dans un premier temps, il doit y avoir
+ des événements publiés qui témoignent de la création des noeuds et des
+ voies de communications. Si vous ne les voyez pas, alors les noeuds
+ ne communiquent pas correctement entre eux et rien ne va se passer...
+ </para>
-<itemizedlist>
+ <itemizedlist>
-<listitem><para>Créer les deux noeuds.</para>
+ <listitem><para>Créer les deux noeuds.</para>
+ <para> Aucun slons ne fonctionne à ce stade, donc il n'y a aucun logs à consulter.</para>
+ </listitem>
-<para> Aucun slons ne fonctionne à ce stade, donc il n'y a aucun logs à consulter.</para>
+ <listitem><para>Lancer les deux noeuds</para>
-</listitem>
+ <para> Les logs de chaque noeuds n'auront pas une activité débordante, car aucun
+ les noeuds n'ont pas grand'chose à dire et qu'ils ne savent pas
+ comment communiquer entre eux. Chaque noeud génère périodiquement
+ un événement <command>SYNC</command>, mais ne perçoit <emphasis>rien</emphasis>
+ de ce qui se passe sur les autres noeuds.</para>
+
+ </listitem>
-<listitem><para>Lancer les deux noeuds</para>
+ <listitem><para> Lancer <xref linkend="stmtstorepath"/> pour configuration les
+ voies de communications. Ceci devrait permettre aux noeuds de prendre conscience
+ de l'existence de leurs voisins.</para>
-<para> Les logs de chaque noeuds n'auront pas une activité débordante, car aucun
-les noeuds n'ont pas grand'chose à dire et qu'ils ne savent pas
-comment communiquer entre eux. Chaque noeud génère périodiquement
-un événement <command>SYNC</command>, mais ne perçoit <emphasis>rien</emphasis>
-de ce qui se passe sur les autres noeuds.</para>
-
-</listitem>
+ <para> Les logs de slon doivent maintenant recevoir les événements en provenance
+ des noeuds <quote>étrangers</quote>.</para>
-<listitem><para> Lancer <xref linkend="stmtstorepath"/> pour configuration les
-voies de communications. Ceci devrait permettre aux noeuds de prendre conscience
-de l'existence de leurs voisins.</para>
+ <para> Dans la 1.0, <xref linkend="table.sl-listen"/> n'est pas configuré
+ automatiquement, donc les logs vont rester calmes tant que vous n'aurez
+ pas soumit explicitement les requêtes <command>STORE LISTEN</command>.
+ Dans la version 1.1, les <quote>voies d'écoute</quote> configurées automatiquement,
+ ce qui nous donne un réseau de communication opérationnel plus rapidement.
+ </para>
-<para> Les logs de slon doivent maintenant recevoir les événements en provenance
-des noeuds <quote>étrangers</quote>.</para>
+ <para> Si vous consultez le contenu des tables <xref
+ linkend="table.sl-node"/>, <xref linkend="table.sl-path"/> et <xref
+ linkend="table.sl-listen"/>, sur chaque noeud, cela vous donnera une bonne
+ idée de l'état du réseau de communication.
+ Jusqu'à ce que les <xref linkend="slon"/> démarrent, chaque noeud
+ est partiellement configuré. Si le cluster contient deux noeuds,
+ alors il doit y avoir deux entrées dans chacune des trois tables
+ une fois que les communications sont correctement configurées.
+ Si il y a moins d'entrées, vous devriez pouvoir deviner ce qui manque.
+ </para>
+ </listitem>
-<para> Dans la 1.0, <xref linkend="table.sl-listen"/> n'est pas configuré
-automatiquement, donc les logs vont rester calmes tant que vous n'aurez
-pas soumit explicitement les requêtes <command>STORE LISTEN</command>.
-Dans la version 1.1, les <quote>voies d'écoute</quote> configurées automatiquement,
-ce qui nous donne un réseau de communication opérationnel plus rapidement.
-</para>
+ <listitem><para> Si nécessaire (<emphasis>c'est à dire</emphasis> - si votre version est
+ antérieurs à la version 1.1), lancer des requêtes <xref linkend="stmtstorelisten"/>
+ pour indiquer comment les noeuds utiliseront les voies de communications.
+ </para>
-<para> Si vous consultez le contenu des tables <xref
-linkend="table.sl-node"/>, <xref linkend="table.sl-path"/> et <xref
-linkend="table.sl-listen"/>, sur chaque noeud, cela vous donnera une bonne
-idée de l'état du réseau de communication.
-Jusqu'à ce que les <xref linkend="slon"/> démarrent, chaque noeud
-est partiellement configuré. Si le cluster contient deux noeuds,
-alors il doit y avoir deux entrées dans chacune des trois tables
-une fois que les communications sont correctement configurées.
-Si il y a moins d'entrées, vous devriez pouvoir deviner ce qui manque.
-</para>
-</listitem>
+ <para> Une fois que c'est fait, les logs des noeuds afficheront un niveau
+ d'activité supérieur, notamment les événements produits périodiquement sur
+ les différents noeuds, ainsi que leur propagation. </para>
+ </listitem>
-<listitem><para> Si nécessaire (<emphasis>c'est à dire</emphasis> - si votre version est
-antérieurs à la version 1.1), lancer des requêtes <xref linkend="stmtstorelisten"/>
-pour indiquer comment les noeuds utiliseront les voies de communications.
-</para>
+ <listitem> <para> Configurer l'ensemble de réplication avec
+ (<xref linkend="stmtcreateset"/>), ajouter les tables avec
+ (<xref linkend="stmtsetaddtable"/>), les séquences avec
+ (<xref linkend="stmtsetaddsequence"/>), puis vérifier que vous
+ retrouvez des logs adéquats avec <xref linkend="logaddobjects"/>
+ uniquement dans les logs du noeud d'origine de l'ensemble de
+ réplication. </para></listitem>
-<para> Une fois que c'est fait, les logs des noeuds afficheront un niveau
-d'activité supérieur, notamment les événements produits périodiquement sur
-les différents noeuds, ainsi que leur propagation. </para>
-</listitem>
+ <listitem><para> Soumettre une requête <xref
+ linkend="stmtsubscribeset"/>, l'événement devrait être visible
+ sur les deux noeuds. </para>
-<listitem> <para> Configurer l'ensemble de réplication avec
-(<xref linkend="stmtcreateset"/>), ajouter les tables avec
-(<xref linkend="stmtsetaddtable"/>), les séquences avec
-(<xref linkend="stmtsetaddsequence"/>), puis vérifier que vous
-retrouvez des logs adéquats avec <xref linkend="logaddobjects"/>
-uniquement dans les logs du noeud d'origine de l'ensemble de
-réplication. </para></listitem>
+ <para> Il reste quelques actions à mener sur le noeud origine... L'abonné
+ doit ensuite recevoir un événement <command>COPY_SET</command>,
+ ce qui doit afficher des informations dans les logs à propos de
+ l'ajout de chaque table et de la copie de leurs données.
+ Consulter la section <xref linkend="logsubtime"/> pour pus de détails.
+ </para></listitem>
-<listitem><para> Soumettre une requête <xref
-linkend="stmtsubscribeset"/>, l'événement devrait être visible
-sur les deux noeuds. </para>
+ </itemizedlist>
-<para> Il reste quelques actions à mener sur le noeud origine... L'abonné
-doit ensuite recevoir un événement <command>COPY_SET</command>,
-ce qui doit afficher des informations dans les logs à propos de
-l'ajout de chaque table et de la copie de leurs données.
-Consulter la section <xref linkend="logsubtime"/> pour pus de détails.
-</para></listitem>
+ <para>A partir de là, vous constaterez deux types de comportements :</para>
-</itemizedlist>
+ <itemizedlist>
-<para>A partir de là, vous constaterez deux types de comportements :</para>
+ <listitem><para> Sur le noeud origine, peu d'informations seront enregistrés
+ dans les logs, juste des indications sur les événements <command>SYNC</command>
+ générés et confirmés par les autres noeuds. Consultez la section
+ <xref linkend="lognormalsync"/> pour plus d'informations sur les différents
+ types de lignes de logs que vous pouvez rencontrer.</para></listitem>
-<itemizedlist>
+ <listitem><para> Sur le noeud abonné, vous trouverez des rapports sur les
+ événements <command>SYNC</command>, et sur les données que l'abonné
+ obtient du fournisseur. Ceci se produit peu fréquemment si le noeud origine
+ ne reçoit pas de mises à jour; c'est au contraire très fréquent si le noeud
+ origine reçoit beaucoup de modifications.</para>
+ </listitem>
-<listitem><para> Sur le noeud origine, peu d'informations seront enregistrés
-dans les logs, juste des indications sur les événements <command>SYNC</command>
-générés et confirmés par les autres noeuds. Consultez la section
-<xref linkend="lognormalsync"/> pour plus d'informations sur les différents
-types de lignes de logs que vous pouvez rencontrer.</para></listitem>
+ </itemizedlist>
-<listitem><para> Sur le noeud abonné, vous trouverez des rapports sur les
-événements <command>SYNC</command>, et sur les données que l'abonné
-obtient du fournisseur. Ceci se produit peu fréquemment si le noeud origine
-ne reçoit pas de mises à jour; c'est au contraire très fréquent si le noeud
-origine reçoit beaucoup de modifications.</para>
-</listitem>
-
-</itemizedlist>
-
</sect2>
<sect2> <title> Les messages de log et leurs implications </title>
-<para> Cette section énumère les nombreux messages d'erreurs que l'on peut
-trouver dans les logs de &slony1;, ainsi qu'une brève explication de leur implication.
-Il s'agit d'une liste relativement compréhensible, qui omet simplement
-certain messages de niveau <command>DEBUG4</command> qui sont presque toujours
-inintéressant.</para>
+ <para> Cette section énumère les nombreux messages d'erreurs que l'on peut
+ trouver dans les logs de &slony1;, ainsi qu'une brève explication de leur implication.
+ Il s'agit d'une liste relativement compréhensible, qui omet simplement
+ certain messages de niveau <command>DEBUG4</command> qui sont presque toujours
+ inintéressant.</para>
-<sect3 id="logshiplog"><title> Les messages de log associés au Log Shipping </title>
+ <sect3 id="logshiplog"><title> Les messages de log associés au Log Shipping </title>
-<para> La plupart de ces messages concernent des erreurs qui se produisent
-lorsque le mécanisme de <xref linkend="logshipping"/> échoue. En général,
-cela se produit si le système de fichier utilisé pour le log shipping est plein,
-ou si les permissions d'un répertoire sont mal définies. </para>
+ <para> La plupart de ces messages concernent des erreurs qui se produisent
+ lorsque le mécanisme de <xref linkend="logshipping"/> échoue. En général,
+ cela se produit si le système de fichier utilisé pour le log shipping est plein,
+ ou si les permissions d'un répertoire sont mal définies. </para>
-<itemizedlist>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: log archive failed %s - %s\n</command> </para>
+ <itemizedlist>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: log archive failed %s - %s\n</command> </para>
+ <para> Ce message indique qu'une erreur a été rencontrée en essayent d'écrire un
+ fichier de log shipping. Normalement le démon &lslon; essaie à nouveau, jusqu'à ce qu'il réussisse. </para>
+ </listitem>
-<para> Ce message indique qu'une erreur a été rencontrée en essayent d'écrire un
-fichier de log shipping. Normalement le démon &lslon; essaie à nouveau, jusqu'à ce qu'il réussisse
-. </para> </listitem>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: writing archive log...</command></para>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: writing archive log...</command></para>
+ <para> Ce message indique qu'un fichier archive log est écrit pour un ensemble de <command>SYNC</command> particulier. </para></listitem>
-<para> Ce message indique qu'un fichier archive log est écrit pour un ensemble de <command>SYNC</command> particulier. </para></listitem>
+ <listitem><para><command>INFO: remoteWorkerThread_%d: Run Archive Command %s</command></para>
-<listitem><para><command>INFO: remoteWorkerThread_%d: Run Archive Command %s</command></para>
+ <para> Si &lslon; est configuré ( avec l'option <option>-x</option>
+ c'est à dire <envar>command_on_logarchive</envar>) pour lancer une commande
+ après chaque génération de fichier archive log, ce message indique quand cette commande
+ est effectuée via la fonction <function>system()</function>. </para> </listitem>
-<para> Si &lslon; est configuré ( avec l'option <option>-x</option>
-c'est à dire <envar>command_on_logarchive</envar>) pour lancer une commande
-après chaque génération de fichier archive log, ce message indique quand cette commande
-est effectuée via la fonction <function>system()</function>. </para> </listitem>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: Could not open
+ COPY SET archive file %s - %s</command></para>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not open
-COPY SET archive file %s - %s</command></para>
+ <para> Ce message semble assez explicite... </para></listitem>
-<para> Ce message semble assez explicite... </para></listitem>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate COPY SET archive header %s - %s</command></para>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate COPY SET archive header %s - %s</command></para>
+ <para> Ce message signifie probablement que vous avez saturé le système de fichier... </para></listitem>
-<para> Ce message signifie probablement que vous avez saturé le système de fichier... </para></listitem>
+ <listitem><para> <command>ERROR remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter set ac_num = ac_num + 1, ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR: could not serialize access due to concurrent update</command> </para>
-<listitem><para> <command>ERROR remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter set ac_num = ac_num + 1, ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR: could not serialize access due to concurrent update</command> </para>
+ <para> Ce message se produit occasionnellement lorsqu'on utilise le log shipping;
+ il se produit généralement lorsque que le cluster contient 3 noeuds ou plus,
+ et que le démon tente d'exécuter simultanément des événements en provenance de
+ différents noeuds. Ceci ne représenté pas un problème sérieux; &slony1;
+ tentera à nouveau de traiter l'événement qui a échoué, sans que l'intervention
+ d'un administrateur soit nécessaire. </para>
+ </listitem>
-<para> Ce message se produit occasionnellement lorsqu'on utilise le log shipping;
-il se produit généralement lorsque que le cluster contient 3 noeuds ou plus,
-et que le démon tente d'exécuter simultanément des événements en provenance de
-différents noeuds. Ceci ne représenté pas un problème sérieux; &slony1;
-tentera à nouveau de traiter l'événement qui a échoué, sans que l'intervention
-d'un administrateur soit nécessaire. </para>
-</listitem>
+ </itemizedlist>
+ </sect3>
-</itemizedlist>
-</sect3>
+ <sect3 id="ddllogs"><title> Messages de logs à propose des DDL scripts </title>
-<sect3 id="ddllogs"><title> Messages de logs à propose des DDL scripts </title>
+ <para> La gestion des ordres DDL est un peu fragile, comme indiqué
+ dans la section <xref linkend="ddlchanges"/>; voici des messages à
+ caractère informatif et des messages d'erreur qui se produisent lors de l'exécution d'une requête
+ <xref linkend="stmtddlscript"/>.</para>
-<para> La gestion des ordres DDL est un peu fragile, comme indiqué
-dans la section <xref linkend="ddlchanges"/>; voici des messages à
-caractère informatif et des messages d'erreur qui se produisent lors de l'exécution d'une requête
-<xref linkend="stmtddlscript"/>.</para>
+ <itemizedlist>
-<itemizedlist>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: DDL préparation
+ failed - set %d - only on node %</command></para>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: DDL préparation
-failed - set %d - only on node %</command></para>
+ <para> Quelque chose s'est cassé lors du traitement d'un script DDL sur un des noeuds.
+ Ceci indique probablement que le schéma du noeud était différent de celui du
+ noeud origine; vous devez probablement effectuer une modification à la main
+ sur ce noeud pour l'événement puisse être traité.
+ Une alternative très regrettable consiste à supprimer l'événement bloquant,
+ sachant qu'il est possible que cette suppression ne fonctionne pas...</para> </listitem>
-<para> Quelque chose s'est cassé lors du traitement d'un script DDL sur un des noeuds.
-Ceci indique probablement que le schéma du noeud était différent de celui du
-noeud origine; vous devez probablement effectuer une modification à la main
-sur ce noeud pour l'événement puisse être traité.
-Une alternative très regrettable consiste à supprimer l'événement bloquant,
-sachant qu'il est possible que cette suppression ne fonctionne pas...</para> </listitem>
+ <listitem><para><command>SLON_CONFIG: remoteWorkerThread_%d: DDL request with %d statements</command></para>
+ <para> Ce message est informatif, il indique combien de commandes SQL ont été traitées. </para></listitem>
-<listitem><para><command>SLON_CONFIG: remoteWorkerThread_%d: DDL request with %d statements</command></para>
-<para> Ce message est informatif, il indique combien de commandes SQL ont été traitées. </para></listitem>
+ <listitem><para><command>SLON_ERROR: remoteWorkerThread_%d: DDL had invalid number of statements - %d</command></para>
-<listitem><para><command>SLON_ERROR: remoteWorkerThread_%d: DDL had invalid number of statements - %d</command></para>
+ <para> Ce message se produit lorsque le nombre de commandes traitées est < 0 (ce qui est théoriquement impossible)
+ ou > MAXSTATEMENTS. Ceci indique que le scripts DDL est probablement mal écrit...</para></listitem>
-<para> Ce message se produit lorsque le nombre de commandes traitées est < 0 (ce qui est théoriquement impossible)
-ou > MAXSTATEMENTS. Ceci indique que le scripts DDL est probablement mal écrit...</para></listitem>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: malloc()
+ failure in DDL_SCRIPT - could not allocate %d bytes of
+ memory</command></para>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: malloc()
-failure in DDL_SCRIPT - could not allocate %d bytes of
-memory</command></para>
+ <para> Ceci se produit uniquement si vous soumettez un script DDL extraordinairement long,
+ qui sature la mémoire allouée à &lslon; ("out of memory") </para></listitem>
-<para> Ceci se produit uniquement si vous soumettez un script DDL extraordinairement long,
-qui sature la mémoire allouée à &lslon; ("out of memory") </para></listitem>
+ <listitem><para><command>CONFIG: remoteWorkerThread_%d: DDL Statement %d: [%s]</command></para>
-<listitem><para><command>CONFIG: remoteWorkerThread_%d: DDL Statement %d: [%s]</command></para>
+ <para> Ce message fait la liste de tous les ordres DDL au fur et à mesure qu'ils sont soumis.
+ </para></listitem>
-<para> Ce message fait la liste de tous les ordres DDL au fur et à mesure qu'ils sont soumis.
- </para></listitem>
+ <listitem><para><command>ERROR: DDL Statement failed - %s</command></para>
-<listitem><para><command>ERROR: DDL Statement failed - %s</command></para>
+ <para> Oh mon dieu ! un des ordres DDL a fonctionné sur le noeud origine mais il a échoués
+ sur le noeud local... </para></listitem>
-<para> Oh mon dieu ! un des ordres DDL a fonctionné sur le noeud origine mais il a échoués
-sur le noeud local... </para></listitem>
+ <listitem><para><command>CONFIG: DDL Statement success - %s</command></para>
-<listitem><para><command>CONFIG: DDL Statement success - %s</command></para>
+ <para> Tout va bien... </para></listitem>
-<para> Tout va bien... </para></listitem>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate DDL archive tracker %s - %s</command></para>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate DDL archive tracker %s - %s</command></para>
+ <para> Apparemment le script DDL ne peut pas être écrit dans le fichier de log shipping... </para></listitem>
-<para> Apparemment le script DDL ne peut pas être écrit dans le fichier de log shipping... </para></listitem>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: Could not submit DDL script %s - %s</command></para>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not submit DDL script %s - %s</command></para>
+ <para>Le script ne peut pas être écrit dans un ficheir de log shipping.</para> </listitem>
-<para>Le script ne peut pas être écrit dans un ficheir de log shipping.</para> </listitem>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: Could not close DDL script %s - %s</command></para>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not close DDL script %s - %s</command></para>
+ <para>Impossible de fermer un fichier de log shipping contenant un script DDL.</para> </listitem>
-<para>Impossible de fermer un fichier de log shipping contenant un script DDL.</para> </listitem>
+ <listitem><para><command>ERROR: Slony-I ddlScript_prepare(): set % not found</command></para>
-<listitem><para><command>ERROR: Slony-I ddlScript_prepare(): set % not found</command></para>
+ <para> L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un
+ mauvais identifiant de noeud... </para></listitem>
-<para> L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un
-mauvais identifiant de noeud... </para></listitem>
+ <listitem><para><command>ERROR: Slony-I ddlScript_prepare_int(): set % not found</command></para>
-<listitem><para><command>ERROR: Slony-I ddlScript_prepare_int(): set % not found</command></para>
+ <para>L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un
+ mauvais identifiant de noeud... </para></listitem>
-<para>L'ensemble de réplication est introuvable sur ce noeud; Vous avez probablement spécifier un
-mauvais identifiant de noeud... </para></listitem>
+ <listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table with id % not found</command></para>
-<listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table with id % not found</command></para>
+ <para> Apparemment la table n'a pas été trouvée; Le schéma est peut-être erroné ? </para> </listitem>
-<para> Apparemment la table n'a pas été trouvée; Le schéma est peut-être erroné ? </para> </listitem>
+ <listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table % is already in altered state</command></para>
-<listitem><para><command>ERROR: Slony-I: alterTableForReplication(): Table % is already in altered state</command></para>
+ <para> Curieux... Le script tente de répliquer une table une <emphasis>seconde</emphasis> fois ? </para> </listitem>
-<para> Curieux... Le script tente de répliquer une table une <emphasis>seconde</emphasis> fois ? </para> </listitem>
+ <listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table with id % not found</command></para>
-<listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table with id % not found</command></para>
+ <para> Ce message se produit lorsqu'une table est en cours de restauration vers un état <quote>non-repliqué</quote>;
+ apparemment la table répliquée n'a pas été trouvée.</para></listitem>
-<para> Ce message se produit lorsqu'une table est en cours de restauration vers un état <quote>non-repliqué</quote>;
-apparemment la table répliquée n'a pas été trouvée.</para></listitem>
+ <listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table % is not in altered state</command></para>
-<listitem><para><command>ERROR: Slony-I: alterTableRestore(): Table % is not in altered state</command></para>
+ <para> Hmm. La table n'est pas dans un état répliqué. Cela ne devrait pas se produire si la réplication
+ fonctionne correctement...</para> </listitem>
-<para> Hmm. La table n'est pas dans un état répliqué. Cela ne devrait pas se produire si la réplication
-fonctionne correctement...</para> </listitem>
+ <listitem><para><command>NOTICE: Slony-I: alterTableForReplication(): multiple instances of trigger % on table %'',</command></para>
-<listitem><para><command>NOTICE: Slony-I: alterTableForReplication(): multiple instances of trigger % on table %'',</command></para>
+ <para> Ceci se produit en général lorsque vous avez une table avec des triggers que la réplication a du cacher
+ lors de l'abonnement du noeud et que vous avez ajouter un triggrer portant le même nom. Maintenant, lorsque l'on tente de
+ réactiver le trigger caché, les deux triggers entre en conflit.
+ </para>
-<para> Ceci se produit en général lorsque vous avez une table avec des triggers que la réplication a du cacher
-lors de l'abonnement du noeud et que vous avez ajouter un triggrer portant le même nom. Maintenant, lorsque l'on tente de
-réactiver le trigger caché, les deux triggers entre en conflit.
- </para>
+ <para> Le script DDL continuera a tourner, encore et encore, ou la commande UNINSTALL NODE échouera,
+ jusqu'à ce que vous supprimiez le trigger <quote>visible</quote> à la main, puisque vous l'avez probablement
+ ajouté à la main un peu plus tôt. </para>
+ </listitem>
-<para> Le script DDL continuera a tourner, encore et encore, ou la commande UNINSTALL NODE échouera,
-jusqu'à ce que vous supprimiez le trigger <quote>visible</quote> à la main, puisque vous l'avez probablement
-ajouté à la main un peu plus tôt. </para>
-</listitem>
+ <listitem><para><command>ERROR: Slony-I: Unable to disable triggers</command></para>
+ <para> Cette erreur se produit à la suite du problème de <quote>triggers multiples</quote>. </para></listitem>
+ </itemizedlist>
+ </sect3>
-<listitem><para><command>ERROR: Slony-I: Unable to disable triggers</command></para>
-<para> Cette erreur se produit à la suite du problème de <quote>triggers multiples</quote>. </para></listitem>
-</itemizedlist>
-</sect3>
+ <sect3><title> Problèmes avec les processus</title>
+
+ <para> Le modèle de gestion des processus ("threading") de &slony1; n'est pas
+ directement <quote>paramétrable par les utilisateurs</quote>;
+ Chaque démon &lslon; crée un ensemble pré-défini de processus pour gérer
+ les différentes connexions nécessaires. La seule occasion où la gestion
+ des processus peut poser problème est lorsque les librairies de &postgres;
+ n'ont pas été compilées <quote>correctement</quote>, auquel cas
+ il sera de toute façon impossible de compiler &slony1;. </para>
-<sect3><title> Problèmes avec les processus</title>
+ <itemizedlist>
+ <listitem><para><command>FATAL: remoteWorkerThread_%d: pthread_create() - %s</command></para>
-<para> Le modèle de gestion des processus ("threading") de &slony1; n'est pas
-directement <quote>paramétrable par les utilisateurs</quote>;
-Chaque démon &lslon; crée un ensemble pré-défini de processus pour gérer
-les différentes connexions nécessaires. La seule occasion où la gestion
-des processus peut poser problème est lorsque les librairies de &postgres;
-n'ont pas été compilées <quote>correctement</quote>, auquel cas
-il sera de toute façon impossible de compiler &slony1;. </para>
+ <para> Impossible de créer un nouveau processus de traitement des événements distants. </para>
+ </listitem>
+ <listitem><para><command>DEBUG1 remoteWorkerThread_%d: helper thread for provider %d created</command></para>
-<itemizedlist>
-<listitem><para><command>FATAL: remoteWorkerThread_%d: pthread_create() - %s</command></para>
+ <para> Ceci se produit en général lorsque le démon &lslon; démarre : un processus est créé pour
+ chaque noeud que le le noeud local doit écouter.</para></listitem>
-<para> Impossible de créer un nouveau processus de traitement des événements distants. </para>
-</listitem>
-<listitem><para><command>DEBUG1 remoteWorkerThread_%d: helper thread for provider %d created</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: helper thread for provider %d terminated </command></para>
-<para> Ceci se produit en général lorsque le démon &lslon; démarre : un processus est créé pour
-chaque noeud que le le noeud local doit écouter.</para></listitem>
+ <para> Si un abonnement est modifié et qu'un noeud n'est plus un noeud fournisseur,
+ alors le processus qui traite les événements sur ce noeud peut être arrêté. </para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: helper thread for provider %d terminated </command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: disconnecting
+ from data provider %d </command></para>
-<para> Si un abonnement est modifié et qu'un noeud n'est plus un noeud fournisseur,
-alors le processus qui traite les événements sur ce noeud peut être arrêté. </para></listitem>
+ <para> Un noeud fournisseur qui n'est plus utilisé peut être supprimé;
+ si les informations de connexion sont changées, le démon &lslon; doit se déconnecter et
+ se reconnecter. </para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: disconnecting
-from data provider %d </command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: ignore new events due to shutdown</command></para>
-<para> Un noeud fournisseur qui n'est plus utilisé peut être supprimé;
-si les informations de connexion sont changées, le démon &lslon; doit se déconnecter et
-se reconnecter. </para></listitem>
+ <para> Si le démon &lslon; est en cours d'arrêt, il est futile de traiter d'autres événements.</para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: ignore new events due to shutdown</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: node %d - no worker thread</command></para>
-<para> Si le démon &lslon; est en cours d'arrêt, il est futile de traiter d'autres événements.</para></listitem>
+ <para> Curieux : il est impossible de réveiller le processus de traitement; pourtant il devrait déjà
+ y en avoir un... </para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: node %d - no worker thread</command></para>
+ </itemizedlist>
+ </sect3>
-<para> Curieux : il est impossible de réveiller le processus de traitement; pourtant il devrait déjà
-y en avoir un... </para></listitem>
+ <sect3 id="logsubtime"><title> Messages de log au moment d'un abonnement </title>
-</itemizedlist>
-</sect3>
+ <para> Un abonnement est une opération très spéciale pour &slony1;. Si vous
+ avez un grand volume de données à copier sur l'abonné, cela peut prendre
+ un temps considérable. &slony1; enregistre une quantité considérable d'informations
+ lors de ce processus, qui sera probablement très utiles aux utilisateurs.
+ En particulier, il produit des traces à chaque fois qu'il commence et termine
+ la copie des données d'une table et lorsqu'il finit l'indexation de la table.
+ Cela n'aide ne rend pas un abonnement de 28 heures plus rapide, mais au moins
+ cela vous aide suivre son déroulement.
+ </para>
-<sect3 id="logsubtime"><title> Messages de log au moment d'un abonnement </title>
+ <itemizedlist>
+ <listitem><para><command>DEBUG1: copy_set %d</command></para>
-<para> Un abonnement est une opération très spéciale pour &slony1;. Si vous
-avez un grand volume de données à copier sur l'abonné, cela peut prendre
-un temps considérable. &slony1; enregistre une quantité considérable d'informations
-lors de ce processus, qui sera probablement très utiles aux utilisateurs.
-En particulier, il produit des traces à chaque fois qu'il commence et termine
-la copie des données d'une table et lorsqu'il finit l'indexation de la table.
-Cela n'aide ne rend pas un abonnement de 28 heures plus rapide, mais au moins
-cela vous aide suivre son déroulement.
-</para>
+ <para> Ceci indique le départ de la copie de données pour un nouvel abonnement. </para></listitem>
-<itemizedlist>
-<listitem><para><command>DEBUG1: copy_set %d</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: set %d not found in runtime configuration </command></para>
-<para> Ceci indique le départ de la copie de données pour un nouvel abonnement. </para></listitem>
+ <para> &lslon; a tenté de lancer un abonnement; il n'a pas trouvé les informations de connexion à la source des données.
+ Peut-être que les chemins ne sont pas correctement propagés ?</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: set %d not found in runtime configuration </command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: node %d has no pa_conninfo </command></para>
-<para> &lslon; a tenté de lancer un abonnement; il n'a pas trouvé les informations de connexion à la source des données.
-Peut-être que les chemins ne sont pas correctement propagés ?</para></listitem>
+ <para> Apparemment les informations de connexion sont <emphasis>fausses</emphasis>...</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: node %d has no pa_conninfo </command></para>
+ <listitem><para><command>ERROR: copy set %d cannot connect to provider DB node %d </command></para>
-<para> Apparemment les informations de connexion sont <emphasis>fausses</emphasis>...</para></listitem>
+ <para> &lslon; n'a pas pu se connecter au fournisseur. Est-ce que les informations de connexion sont fausses ?
+ Peut-être que l'authentification est mal configurée ? Peut-être que la base de donnée ne fonctionne pas ?
+ </para></listitem>
-<listitem><para><command>ERROR: copy set %d cannot connect to provider DB node %d </command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: connected to provider DB </command></para>
-<para> &lslon; n'a pas pu se connecter au fournisseur. Est-ce que les informations de connexion sont fausses ?
-Peut-être que l'authentification est mal configurée ? Peut-être que la base de donnée ne fonctionne pas ?
-</para></listitem>
+ <para> Excellent : le processus de copie a pu se connecter au fournisseur</para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: connected to provider DB </command></para>
+ <listitem><para><command>ERROR: Slony-I: sequenceSetValue(): sequence % not found</command></para>
-<para> Excellent : le processus de copie a pu se connecter au fournisseur</para></listitem>
+ <para> Curieux; la séquence de l'objet est absente. Est-ce que quelqu'un l'a supprimé à la main du schéma ?
+ (<emphasis>c'est à dire</emphasis> - sans utiliser <xref linkend="stmtddlscript"/>)?</para></listitem>
-<listitem><para><command>ERROR: Slony-I: sequenceSetValue(): sequence % not found</command></para>
+ <listitem><para><command>ERROR: Slony-I: subscribeSet() must be called on provider</command></para>
-<para> Curieux; la séquence de l'objet est absente. Est-ce que quelqu'un l'a supprimé à la main du schéma ?
-(<emphasis>c'est à dire</emphasis> - sans utiliser <xref linkend="stmtddlscript"/>)?</para></listitem>
+ <para> Cette fonction devrait être appelée sur le noeud fournisseur. Normalement &lslonik;
+ gère correctement ce cas, à moins qu'il y ait de mauvais DSNs dans un script &lslonik;...</para>
+ </listitem>
-<listitem><para><command>ERROR: Slony-I: subscribeSet() must be called on provider</command></para>
+ <listitem><para><command>ERROR: Slony-I: subscribeSet(): set % not found</command></para>
-<para> Cette fonction devrait être appelée sur le noeud fournisseur. Normalement &lslonik;
-gère correctement ce cas, à moins qu'il y ait de mauvais DSNs dans un script &lslonik;...</para>
-</listitem>
+ <para> Hmm. Le noeud fournisseur ne connaît pas cet ensemble de réplication. Un mauvais paramètre dans un
+ script &lslonik; ?</para> </listitem>
-<listitem><para><command>ERROR: Slony-I: subscribeSet(): set % not found</command></para>
+ <listitem><para><command>ERROR: Slony-I: subscribeSet(): set origin and receiver cannot be identical</command></para>
-<para> Hmm. Le noeud fournisseur ne connaît pas cet ensemble de réplication. Un mauvais paramètre dans un
-script &lslonik; ?</para> </listitem>
+ <para> Ouh la la !, un noeud origine ne peut pas être abonné à lui-même.</para> </listitem>
-<listitem><para><command>ERROR: Slony-I: subscribeSet(): set origin and receiver cannot be identical</command></para>
+ <listitem><para><command>ERROR: Slony-I: subscribeSet(): set provider and receiver cannot be identical</command></para>
-<para> Ouh la la !, un noeud origine ne peut pas être abonné à lui-même.</para> </listitem>
+ <para> Un noeud récepteur doit s'abonner à un noeud <emphasis>différent</emphasis>...</para> </listitem>
-<listitem><para><command>ERROR: Slony-I: subscribeSet(): set provider and receiver cannot be identical</command></para>
+ <listitem><para><command>Slony-I: subscribeSet(): provider % is not an active forwarding node for replication set %</command></para>
-<para> Un noeud récepteur doit s'abonner à un noeud <emphasis>différent</emphasis>...</para> </listitem>
+ <para> Vous devez utiliser un noeud fournisseur actif et en cours de fonctionnement comme source des données.
+ </para></listitem>
-<listitem><para><command>Slony-I: subscribeSet(): provider % is not an active forwarding node for replication set %</command></para>
+ <listitem><para>Slony-I: subscribeSet_int(): set % is not active, cannot change provider<command></command></para>
-<para> Vous devez utiliser un noeud fournisseur actif et en cours de fonctionnement comme source des données.
-</para></listitem>
+ <para> Vous ne pouvez pas changer le fournisseur pour le moment...</para></listitem>
-<listitem><para>Slony-I: subscribeSet_int(): set % is not active, cannot change provider<command></command></para>
+ <listitem><para><command>Slony-I: subscribeSet_int(): set % not found</command></para>
-<para> Vous ne pouvez pas changer le fournisseur pour le moment...</para></listitem>
+ <para> Ce noeud ne connaît pas l'ensemble de réplication... Vous avez peut-être soumis un mauvais
+ paramètre ?</para></listitem>
-<listitem><para><command>Slony-I: subscribeSet_int(): set % not found</command></para>
+ <listitem><para><command>Slony-I: unsubscribeSet() must be called on receiver</command></para>
-<para> Ce noeud ne connaît pas l'ensemble de réplication... Vous avez peut-être soumis un mauvais
-paramètre ?</para></listitem>
+ <para> Cela parait trivial... Ceci indique probablement un mauvais DSN &lslonik;</para></listitem>
-<listitem><para><command>Slony-I: unsubscribeSet() must be called on receiver</command></para>
+ <listitem><para><command>Slony-I: Cannot unsubscribe set % while being provider</command></para>
-<para> Cela parait trivial... Ceci indique probablement un mauvais DSN &lslonik;</para></listitem>
+ <para> Cela semble évident; <xref linkend="stmtunsubscribeset"/> va échouer si un noeud est dépendant des abonnés
+ dont il est le fournisseur. </para> </listitem>
-<listitem><para><command>Slony-I: Cannot unsubscribe set % while being provider</command></para>
+ <listitem><para><command>Slony-I: cleanupEvent(): Single node - deleting events < %</command></para>
-<para> Cela semble évident; <xref linkend="stmtunsubscribeset"/> va échouer si un noeud est dépendant des abonnés
-dont il est le fournisseur. </para> </listitem>
+ <para> S'il n'y a qu'un seul noeud, l'événement de nettoyage va supprimer les anciens événements
+ afin pour ne pas récupérer le <quote>crud</quote>.</para></listitem>
-<listitem><para><command>Slony-I: cleanupEvent(): Single node - deleting events < %</command></para>
-<para> S'il n'y a qu'un seul noeud, l'événement de nettoyage va supprimer les anciens événements
-afin pour ne pas récupérer le <quote>crud</quote>.</para></listitem>
+ <listitem><para><command>Slony-I: tableAddKey(): table % not found</command></para>
+ <para> Peut-être que vous n'avez pas copié le schéma proprement ?</para></listitem>
-<listitem><para><command>Slony-I: tableAddKey(): table % not found</command></para>
+ <listitem><para><command>Slony-I: tableDropKey(): table with ID% not found</command></para>
-<para> Peut-être que vous n'avez pas copié le schéma proprement ?</para></listitem>
+ <para> Cela parait curieux; cette table est probablement déjà en cours de réplication;
+ il est donc étrange que que cette table ait disparue pas...</para></listitem>
-<listitem><para><command>Slony-I: tableDropKey(): table with ID% not found</command></para>
+ <listitem><para><command>Slony-I: determineIdxnameUnique(): table % not found</command></para>
-<para> Cela parait curieux; cette table est probablement déjà en cours de réplication;
-il est donc étrange que que cette table ait disparue pas...</para></listitem>
+ <para>Avez-vous correctement copié le schéma sur le nouveau noeud ???</para></listitem>
-<listitem><para><command>Slony-I: determineIdxnameUnique(): table % not found</command></para>
+ <listitem><para><command>Slony-I: table % has no primary key</command></para>
-<para>Avez-vous correctement copié le schéma sur le nouveau noeud ???</para></listitem>
+ <para> Ceci signifie probablement que le chargement du schéma s'est mal passé...</para></listitem>
-<listitem><para><command>Slony-I: table % has no primary key</command></para>
+ <listitem><para><command>Slony-I: table % has no unique index %</command></para>
-<para> Ceci signifie probablement que le chargement du schéma s'est mal passé...</para></listitem>
+ <para> Ceci signifie probablement que le chargement du schéma s'est mal passé... </para></listitem>
-<listitem><para><command>Slony-I: table % has no unique index %</command></para>
+ <listitem><para><command>WARN: remoteWorkerThread_%d: transactions
+ earlier than XID %s are still in progress</command></para>
-<para> Ceci signifie probablement que le chargement du schéma s'est mal passé... </para></listitem>
+ <para> Ceci indique qu'une vieille transaction est en cours d'exécution et qu'elle a débutée avant le
+ plus vieil événement <command>SYNC</command> disponible sur le fournisseur. &slony1; ne peut pas
+ lancer une réplication tant que cette transaction n'est pas achevée. Ce message sera répété jusqu'à
+ ce que la transaction aboutisse...
+ </para></listitem>
-<listitem><para><command>WARN: remoteWorkerThread_%d: transactions
-earlier than XID %s are still in progress</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: prepare to copy table %s </command></para>
-<para> Ceci indique qu'une vieille transaction est en cours d'exécution et qu'elle a débutée avant le
-plus vieil événement <command>SYNC</command> disponible sur le fournisseur. &slony1; ne peut pas
-lancer une réplication tant que cette transaction n'est pas achevée. Ce message sera répété jusqu'à
-ce que la transaction aboutisse...
-</para></listitem>
+ <para> Ceci indique que &lslon; commence les préparatifs pour mettre en place un abonnement pour une table.
+ </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: prepare to copy table %s </command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: table %s will require Slony-I serial key</command></para>
-<para> Ceci indique que &lslon; commence les préparatifs pour mettre en place un abonnement pour une table.
-</para></listitem>
+ <para> Évidement cette table est définie avec <xref linkend="stmttableaddkey"/> et &slony1; a ajouté une
+ clef primaire supplémentaire.</para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: table %s will require Slony-I serial key</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: Could not lock table %s on subscriber</command></para>
-<para> Évidement cette table est définie avec <xref linkend="stmttableaddkey"/> et &slony1; a ajouté une
-clef primaire supplémentaire.</para></listitem>
+ <para> Pour une certaine raison, la table ne peut pas être verrouillée, donc la réplication
+ soit être redémarrée. Si le problème concerne un inter-blocage ("deadlock"), essayer la commande
+ à nouveau peut fonctionner. S'il s'agit d'un autre problème, vous devez intervenir...
+ </para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not lock table %s on subscriber</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: all tables for set %d found on subscriber</command></para>
-<para> Pour une certaine raison, la table ne peut pas être verrouillée, donc la réplication
-soit être redémarrée. Si le problème concerne un inter-blocage ("deadlock"), essayer la commande
-à nouveau peut fonctionner. S'il s'agit d'un autre problème, vous devez intervenir...
-</para></listitem>
+ <para> Ce message d'information indique que lors du premier passage sur les tables, aucun problème
+ n'a été trouvé... </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: all tables for set %d found on subscriber</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy sequence %s</command></para>
-<para> Ce message d'information indique que lors du premier passage sur les tables, aucun problème
-n'a été trouvé... </para></listitem>
+ <para> Ce message indique qu'un séquence est traitée... </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy sequence %s</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy table %s</command></para>
-<para> Ce message indique qu'un séquence est traitée... </para></listitem>
+ <para> &lslon; commence la copie d'une table... </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy table %s</command></para>
+ <listitem><para><command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command></para>
-<para> &lslon; commence la copie d'une table... </para></listitem>
+ <para> Une nouvelle colonne vient d'être ajoutée dans la table afin qu'elle dispose d'une clef primaire.</para></listitem>
-<listitem><para><command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command></para>
+ <listitem><para><command>DEBUG3: remoteWorkerThread_%d: local table %s already has Slony-I serial key</command></para>
-<para> Une nouvelle colonne vient d'être ajoutée dans la table afin qu'elle dispose d'une clef primaire.</para></listitem>
+ <para> Il n'est pas nécessaire d'ajouter un clef de type 'serial'; apparemment elle existe déjà.</para></listitem>
-<listitem><para><command>DEBUG3: remoteWorkerThread_%d: local table %s already has Slony-I serial key</command></para>
+ <listitem><para><command>DEBUG3: remoteWorkerThread_%d: table %s does not require Slony-I serial key</command></para>
-<para> Il n'est pas nécessaire d'ajouter un clef de type 'serial'; apparemment elle existe déjà.</para></listitem>
+ <para> Apparemment cette table n'a pas besoin d'une clef primaire supplémentaire... </para>
+ </listitem>
+ <listitem><para><command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command></para> </listitem>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: Begin COPY of table %s</command></para>
-<listitem><para><command>DEBUG3: remoteWorkerThread_%d: table %s does not require Slony-I serial key</command></para>
+ <para> &lslon; va lancer la commande COPY des deux cotés pour copier la table... </para></listitem>
-<para> Apparemment cette table n'a pas besoin d'une clef primaire supplémentaire... </para>
-</listitem>
-<listitem><para><command>DEBUG3: remoteWorkerThread_%d: table %s Slony-I serial key added local</command></para> </listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: Begin COPY of table %s</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate copy_set request for %s - %s</command></para>
-<para> &lslon; va lancer la commande COPY des deux cotés pour copier la table... </para></listitem>
+ <para> Ceci indique que la requête <command>delete/copy</command> a échouée sur l'abonné.
+ Le &lslon; va répéter la tentative de <command>COPY_SET</command>; il est probable que l'opération continue
+ d'échouer... </para> </listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: Could not generate copy_set request for %s - %s</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: copy to stdout on provider - %s %s</command></para>
-<para> Ceci indique que la requête <command>delete/copy</command> a échouée sur l'abonné.
-Le &lslon; va répéter la tentative de <command>COPY_SET</command>; il est probable que l'opération continue
-d'échouer... </para> </listitem>
+ <para> Évidement quelque chose ne fonctionne pas au niveau de l'opération COPY vers la sortie <filename>stdout</filename>
+ sur le noeud fournisseur... L'événement va être lancé à nouveau... </para> </listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: copy to stdout on provider - %s %s</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: copy from stdin on local node - %s %s</command></para>
-<para> Évidement quelque chose ne fonctionne pas au niveau de l'opération COPY vers la sortie <filename>stdout</filename>
-sur le noeud fournisseur... L'événement va être lancé à nouveau... </para> </listitem>
+ <para> Évidemment quelque chose n'a pas fonctionné lors de l'opération COPY dans la table sur
+ le noeud abonné. .. L'événement va être lancé à nouveau...
+ </para> </listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: copy from stdin on local node - %s %s</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: %d bytes copied for table %s</command></para>
-<para> Évidemment quelque chose n'a pas fonctionné lors de l'opération COPY dans la table sur
-le noeud abonné. .. L'événement va être lancé à nouveau...
-</para> </listitem>
+ <para> Ce message indique que l'opération COPY sur la table est achevée.
+ Ceci est suivi d'un <command>ANALYZE</command> et d'une réindexation de la
+ table sur l'abonné.</para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: %d bytes copied for table %s</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: %.3f seconds
+ to copy table %s</command></para>
-<para> Ce message indique que l'opération COPY sur la table est achevée.
-Ceci est suivi d'un <command>ANALYZE</command> et d'une réindexation de la
-table sur l'abonné.</para></listitem>
+ <para> Après ce message, la copie, la réindexation et l'analyse sont terminées sur l'abonné.</para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: %.3f seconds
-to copy table %s</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: set last_value of sequence %s (%s) to %s</command></para>
-<para> Après ce message, la copie, la réindexation et l'analyse sont terminées sur l'abonné.</para></listitem>
+ <para> Sans surprise, cela indique qu'une séquence a été traitée sur l'abonnée.</para>
+ </listitem>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: %.3 seconds to copy sequences</command></para>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: set last_value of sequence %s (%s) to %s</command></para>
+ <para> Ce message indique le temps passé pour le traitement de l'événement <command>COPY_SET</command>. </para></listitem>
-<para> Sans surprise, cela indique qu'une séquence a été traitée sur l'abonnée.</para>
-</listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: %.3 seconds to copy sequences</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: query %s did not return a result </command></para>
-<para> Ce message indique le temps passé pour le traitement de l'événement <command>COPY_SET</command>. </para></listitem>
+ <para> Ceci indique qu'une requête, exécutée lors du traitement final de l'événement <command>COPY_SET</command>,
+ a échouée. La copie est redémarrée... </para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: query %s did not return a result </command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy_set no previous SYNC found, use enable event</command></para>
-<para> Ceci indique qu'une requête, exécutée lors du traitement final de l'événement <command>COPY_SET</command>,
-a échouée. La copie est redémarrée... </para></listitem>
+ <para> Ceci se produit si aucun événement SYNC n'a été trouvé; l'événement courant est positionné
+ au niveau de l'événement <command>ENABLE_SUBSCRIPTION</command>.
+ </para> </listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy_set no previous SYNC found, use enable event</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy_set SYNC found, use event seqno %s</command></para>
-<para> Ceci se produit si aucun événement SYNC n'a été trouvé; l'événement courant est positionné
-au niveau de l'événement <command>ENABLE_SUBSCRIPTION</command>.
-</para> </listitem>
+ <para> Ceci se produit si un événement SYNC est trouvé; l'événement courant est positionné à la valeur
+ indiquée. </para> </listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: copy_set SYNC found, use event seqno %s</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: sl_setsync entry for set %d not found on provider</command></para>
-<para> Ceci se produit si un événement SYNC est trouvé; l'événement courant est positionné à la valeur
-indiquée. </para> </listitem>
+ <para> Une information de synchronisation était attendues en provenance d'un noeud abonné existant, mais elle
+ n'a pas été trouvée. Il s'agit probablement d'une erreur capable de bloquer la réplication ... </para> </listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: sl_setsync entry for set %d not found on provider</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: could not insert to sl_setsync_offline</command></para>
-<para> Une information de synchronisation était attendues en provenance d'un noeud abonné existant, mais elle
-n'a pas été trouvée. Il s'agit probablement d'une erreur capable de bloquer la réplication ... </para> </listitem>
+ <para> Oups. Après la configuration d'un abonné, et presque tout est en place, des écritures dans un fichier de
+ log shipping ont échouées. Peut-être que le disque est plein... </para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: could not insert to sl_setsync_offline</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: %.3f seconds to build initial setsync status</command></para>
-<para> Oups. Après la configuration d'un abonné, et presque tout est en place, des écritures dans un fichier de
-log shipping ont échouées. Peut-être que le disque est plein... </para></listitem>
+ <para> Ce message indique le temps total nécessaire pour que l'événement copy_set soit réalisé...</para>
+ </listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: %.3f seconds to build initial setsync status</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: disconnected from provider DB</command></para>
-<para> Ce message indique le temps total nécessaire pour que l'événement copy_set soit réalisé...</para>
-</listitem>
+ <para> À la fin d'un événement d'abonnement, le &lslon; de l'abonné va se déconnecter du fournisseur et
+ supprimer les connexions...</para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: disconnected from provider DB</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command></para>
-<para> À la fin d'un événement d'abonnement, le &lslon; de l'abonné va se déconnecter du fournisseur et
-supprimer les connexions...</para></listitem>
+ <para> Ce message indique le temps total nécessaire pour effectuer la commande copy_set...
+ C'est le signe d'un abonné réussi !</para>
+ </listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command></para>
-<para> Ce message indique le temps total nécessaire pour effectuer la commande copy_set...
-C'est le signe d'un abonné réussi !</para>
-</listitem>
+ <para> Ce message indique le temps total nécessaire pour effectuer la commande copy_set...
+ C'est le signe d'un abonné réussi !</para>
+ </listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command></para>
+ </itemizedlist>
+ </sect3>
+ <sect3 id="logmergeset"> <title> Messages associés à la commande MERGE SET</title>
-<para> Ce message indique le temps total nécessaire pour effectuer la commande copy_set...
-C'est le signe d'un abonné réussi !</para>
-</listitem>
+ <para> Diverses exceptions peuvent conduire au rejet d'un <xref linkend="stmtmergeset"/>;
+ Ces problèmes doivent être avant de soumettre à nouveau la requête. </para>
-</itemizedlist>
-</sect3>
-<sect3 id="logmergeset"> <title> Messages associés à la commande MERGE SET</title>
+ <itemizedlist>
+ <listitem><para><command>ERROR: Slony-I: merged set ids cannot be identical</command></para>
-<para> Diverses exceptions peuvent conduire au rejet d'un <xref linkend="stmtmergeset"/>;
-Ces problèmes doivent être avant de soumettre à nouveau la requête. </para>
+ <para> Il est illogique d'essayer de fusionner un ensemble avec lui-même. </para></listitem>
-<itemizedlist>
-<listitem><para><command>ERROR: Slony-I: merged set ids cannot be identical</command></para>
+ <listitem><para><command>ERROR: Slony-I: set % not found </command></para>
-<para> Il est illogique d'essayer de fusionner un ensemble avec lui-même. </para></listitem>
+ <para> Un ensemble absent ne peut pas être fusionné. </para></listitem>
-<listitem><para><command>ERROR: Slony-I: set % not found </command></para>
+ <listitem><para><command>ERROR: Slony-I: set % does not originate on local node</command></para>
-<para> Un ensemble absent ne peut pas être fusionné. </para></listitem>
+ <para> La requête <xref linkend="stmtmergeset"/> doit être envoyée au noeud origine des ensembles qu'il faut
+ fusionner. </para></listitem>
-<listitem><para><command>ERROR: Slony-I: set % does not originate on local node</command></para>
+ <listitem><para><command>ERROR: Slony-I: subscriber lists of set % and % are different</command></para>
-<para> La requête <xref linkend="stmtmergeset"/> doit être envoyée au noeud origine des ensembles qu'il faut
-fusionner. </para></listitem>
+ <para> Les ensembles ne peuvent être fusionné que si ils ont la même liste d'abonnés. </para></listitem>
-<listitem><para><command>ERROR: Slony-I: subscriber lists of set % and % are different</command></para>
+ <listitem><para><command>ERROR: Slony-I: set % has subscriptions in progress - cannot merge</command></para>
-<para> Les ensembles ne peuvent être fusionné que si ils ont la même liste d'abonnés. </para></listitem>
+ <para> <xref linkend="stmtmergeset"/> ne peut pas fusionner tant que tous les abonnements
+ ne sont pas achevés. Si ce message apparaît, cela signifie que les listes d'abonnées sont
+ identique mais qu'un ou plusieurs noeuds n'ont pas terminé leur processus d'abonnement.
+ Il est probable qu'attendre un courte période avant de soumettre à nouveau la requête
+ <xref linkend="stmtmergeset"/> suffise à régler le problème.
+ </para></listitem>
-<listitem><para><command>ERROR: Slony-I: set % has subscriptions in progress - cannot merge</command></para>
+ </itemizedlist>
+ </sect3>
-<para> <xref linkend="stmtmergeset"/> ne peut pas fusionner tant que tous les abonnements
-ne sont pas achevés. Si ce message apparaît, cela signifie que les listes d'abonnées sont
-identique mais qu'un ou plusieurs noeuds n'ont pas terminé leur processus d'abonnement.
-Il est probable qu'attendre un courte période avant de soumettre à nouveau la requête
- <xref linkend="stmtmergeset"/> suffise à régler le problème.
-</para></listitem>
+ <sect3 id="lognormalsync"><title> Messages associés l'activité normale des SYNCs </title>
-</itemizedlist>
-</sect3>
+ <para> Certains de ces messages indique des erreurs, mais
+ <quote>normalement</quote> ils présentent les informations attendues lorsque la
+ réplication fonctionne correctement.</para>
-<sect3 id="lognormalsync"><title> Messages associés l'activité normale des SYNCs </title>
+ <itemizedlist>
-<para> Certains de ces messages indique des erreurs, mais
-<quote>normalement</quote> ils présentent les informations attendues lorsque la
-réplication fonctionne correctement.</para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: forward confirm %d,%s received by %d</command></para>
-<itemizedlist>
+ <para> Ces événements devraient apparaître fréquemment et suivant une certaine routine, car
+ ils témoignent des confirmations d'événements qui sont reçues. </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: forward confirm %d,%s received by %d</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: SYNC %d processing</command></para>
-<para> Ces événements devraient apparaître fréquemment et suivant une certaine routine, car
-ils témoignent des confirmations d'événements qui sont reçues. </para></listitem>
+ <para> Ce message indique que le début du traitement d'un <command>SYNC</command> </para> </listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: SYNC %d processing</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: No pa_conninfo
+ for data provider %d</command></para>
-<para> Ce message indique que le début du traitement d'un <command>SYNC</command> </para> </listitem>
+ <para> Oups, les informations de connexion au fournisseur ne sont pas disponibles.
+ . Normalement cela ne pas être possible...</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: No pa_conninfo
-for data provider %d</command></para>
+ <listitem><para><command>ERROR: remoteListenThread_%d: timeout for event selection</command></para>
-<para> Oups, les informations de connexion au fournisseur ne sont pas disponibles.
-. Normalement cela ne pas être possible...</para></listitem>
+ <para> Ce message signifie que le processus d'écoute
+ (<filename>src/slon/remote_listener.c</filename>) s'est arrêté après avoir tenté de
+ déterminer quels événements étaient en attente.</para>
-<listitem><para><command>ERROR: remoteListenThread_%d: timeout for event selection</command></para>
+ <para> Ceci se produit lorsqu'un connexion réseau est coupée. Si c'est le cas, redémarrer le démon
+ &lslon; devrait suffire pour résoudre le problème. </para>
-<para> Ce message signifie que le processus d'écoute
-(<filename>src/slon/remote_listener.c</filename>) s'est arrêté après avoir tenté de
-déterminer quels événements étaient en attente.</para>
+ <para> Par ailleurs, ceci peut se produite lorsque le démon &lslon; de ce noeud
+ a été en panne pendant longtemps, et qu'il y a une quantité énorme de lignes dans
+ la table <envar>sl_event</envar> sur ce noeud ou sur d'autres, en attente d'être
+ traitées et qu'il faut plus de <xref
+ linkend="slon-config-remote-listen-timeout"/> secondes pour exécuter la requête
+ SQL.
+ Dans les anciennes version de &slony1;, ce paramètre de configuration n'existait
+ pas; le temps maximum était fixé à 300 secondes. Dans les nouvelles versions, vous
+ pouvez augmenter cette valeur dans le fichier de configuration de &lslon; pour
+ que le démon continue à traiter les événements. Puis vous pourrez enquêter pour
+ découvrir pourquoi personne ne surveillait le processus et pourquoi la réplication
+ a été rompue pendant aussi longtemps... </para>
+ </listitem>
-<para> Ceci se produit lorsqu'un connexion réseau est coupée. Si c'est le cas, redémarrer le démon
- &lslon; devrait suffire pour résoudre le problème. </para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: cannot connect to data provider %d on 'dsn'</command></para>
-<para> Par ailleurs, ceci peut se produite lorsque le démon &lslon; de ce noeud
-a été en panne pendant longtemps, et qu'il y a une quantité énorme de lignes dans
-la table <envar>sl_event</envar> sur ce noeud ou sur d'autres, en attente d'être
-traitées et qu'il faut plus de <xref
-linkend="slon-config-remote-listen-timeout"/> secondes pour exécuter la requête
-SQL.
-Dans les anciennes version de &slony1;, ce paramètre de configuration n'existait
-pas; le temps maximum était fixé à 300 secondes. Dans les nouvelles versions, vous
-pouvez augmenter cette valeur dans le fichier de configuration de &lslon; pour
-que le démon continue à traiter les événements. Puis vous pourrez enquêter pour
-découvrir pourquoi personne ne surveillait le processus et pourquoi la réplication
-a été rompue pendant aussi longtemps... </para>
-</listitem>
+ <para> Oups, nous n'avons pas les informations de connexions <emphasis>correctes</emphasis> pour nous
+ connecter au fournisseur de données.</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: cannot connect to data provider %d on 'dsn'</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: connected to data provider %d on 'dsn'</command></para>
-<para> Oups, nous n'avons pas les informations de connexions <emphasis>correctes</emphasis> pour nous
-connecter au fournisseur de données.</para></listitem>
+ <para> Excellent; le démon &lslon; s'est connecté au fournisseur. </para> </listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: connected to data provider %d on 'dsn'</command></para>
+ <listitem><para><command>WARN: remoteWorkerThread_%d: don't know what ev_seqno node %d confirmed for ev_origin %d</command></para>
-<para> Excellent; le démon &lslon; s'est connecté au fournisseur. </para> </listitem>
+ <para> Il n'y a aucune information de confirmation en provenance de ce fournisseur;
+ Il faut annuler le <command>SYNC</command> et attendre en espérant que cette information
+ arrive rapidement...</para></listitem>
-<listitem><para><command>WARN: remoteWorkerThread_%d: don't know what ev_seqno node %d confirmed for ev_origin %d</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d: data provider %d only confirmed up to ev_seqno %d for ev_origin %d </command></para>
-<para> Il n'y a aucune information de confirmation en provenance de ce fournisseur;
-Il faut annuler le <command>SYNC</command> et attendre en espérant que cette information
-arrive rapidement...</para></listitem>
+ <para> Le fournisseur de ce noeud est un abonné, apparemment cet abonné est en retard.
+ Le démon &lslon; doit attendre que le fournisseur rattrape son retard avant de recevoir de
+ <emphasis> nouvelles</emphasis> données. </para></listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d: data provider %d only confirmed up to ev_seqno %d for ev_origin %d </command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: data provider %d confirmed up to ev_seqno %s for ev_origin %d - OK</command></para>
-<para> Le fournisseur de ce noeud est un abonné, apparemment cet abonné est en retard.
-Le démon &lslon; doit attendre que le fournisseur rattrape son retard avant de recevoir de
-<emphasis> nouvelles</emphasis> données. </para></listitem>
+ <para> Très bien; le fournisseur dispose des données dont l'abonné a besoin...</para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: data provider %d confirmed up to ev_seqno %s for ev_origin %d - OK</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: syncing set %d with %d table(s) from provider %d</command></para>
-<para> Très bien; le fournisseur dispose des données dont l'abonné a besoin...</para></listitem>
+ <para> Ce message indique les plans d'actions d'un <command>SYNC</command>: il y a un ensemble de tables
+ à traiter.</para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: syncing set %d with %d table(s) from provider %d</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: ssy_action_list value: %s length: %d</command></para>
-<para> Ce message indique les plans d'actions d'un <command>SYNC</command>: il y a un ensemble de tables
-à traiter.</para></listitem>
+ <para> Cette partie de la requête a collecter des données qui semblent être <quote>volumineuses</quote>;
+ ce message indique comment elles ont été compressées... </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: ssy_action_list value: %s length: %d</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: Didn't add OR to provider</command></para>
-<para> Cette partie de la requête a collecter des données qui semblent être <quote>volumineuses</quote>;
-ce message indique comment elles ont été compressées... </para></listitem>
+ <para> Ce message indique qu'il n'y avait rien dans une clause <quote>fournisseur</quote> à l'intérieur
+ de la requête qui collecte les données à appliquer, ce qui ne devrait pas se produire.
+ Il est probable que les choses ait mal tournées quelque part... </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: Didn't add OR to provider</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: no sets need syncing for this event</command></para>
-<para> Ce message indique qu'il n'y avait rien dans une clause <quote>fournisseur</quote> à l'intérieur
-de la requête qui collecte les données à appliquer, ce qui ne devrait pas se produire.
-Il est probable que les choses ait mal tournées quelque part... </para></listitem>
+ <para>Ceci se produira pour tous les événements <command>SYNC</command> générés sur les noeuds qui
+ ne sont l'origine d'un ensemble de réplication. Vous pouvez vous attendre à voir ces messages
+ assez fréquemment. </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: no sets need syncing for this event</command></para>
+ <listitem><para><command>DEBUG3: remoteWorkerThread_%d: activate helper %d</command></para>
-<para>Ceci se produira pour tous les événements <command>SYNC</command> générés sur les noeuds qui
-ne sont l'origine d'un ensemble de réplication. Vous pouvez vous attendre à voir ces messages
-assez fréquemment. </para></listitem>
+ <para> Un processus va être lancé pour aider à traiter les données de l'événement
+ <command>SYNC</command>...</para></listitem>
-<listitem><para><command>DEBUG3: remoteWorkerThread_%d: activate helper %d</command></para>
+ <listitem><para><command>DEBUG4: remoteWorkerThread_%d: waiting for log data</command></para>
-<para> Un processus va être lancé pour aider à traiter les données de l'événement
- <command>SYNC</command>...</para></listitem>
+ <para>Le processus attend que les données se consument (c'est à dire : qu'elles soient appliquées sur
+ le réplicat).</para></listitem>
-<listitem><para><command>DEBUG4: remoteWorkerThread_%d: waiting for log data</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: %s %s - qualification was %s </command></para>
-<para>Le processus attend que les données se consument (c'est à dire : qu'elles soient appliquées sur
-le réplicat).</para></listitem>
+ <para> Apparemment l'application de données répliquées sur l'abonné à échouée....
+ Ceci indique très certainement une corruption assez grave.</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: %s %s - qualification was %s </command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: replication query did not affect one row (cmdTuples = %s) - query was: %s qualification was: %s</command></para>
-<para> Apparemment l'application de données répliquées sur l'abonné à échouée....
-Ceci indique très certainement une corruption assez grave.</para></listitem>
+ <para> Si <envar> SLON_CHECK_CMDTUPLES</envar> est défini, &lslon; applique les
+ changement tuple par tuple, et vérifie que chaque changement affecte exactement un tuple.
+ Apparemment ce n'était pas le cas ici, ce qui semble indiquer une corruption de la
+ réplication. C'est plutôt une mauvaise nouvelle...</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: replication query did not affect one row (cmdTuples = %s) - query was: %s qualification was: %s</command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: SYNC aborted</command></para>
-<para> Si <envar> SLON_CHECK_CMDTUPLES</envar> est défini, &lslon; applique les
-changement tuple par tuple, et vérifie que chaque changement affecte exactement un tuple.
-Apparemment ce n'était pas le cas ici, ce qui semble indiquer une corruption de la
-réplication. C'est plutôt une mauvaise nouvelle...</para></listitem>
+ <para>Le <command>SYNC</command> a été annulé. Le &lslon; va probablement
+ retenter ce <command>SYNC</command> dans quelque temps. Si le
+ <command>SYNC</command> échoue encore et toujours, il y un problème récurrent,
+ et la réplication ne va probablement pas reprendre sans une intervention.
+ Il est peut-être nécessaire de désabonner/réabonner l'ensemble de réplication
+ concerné, ou si il n'y a qu'un seul ensemble de réplication sur le noeud esclave,
+ il est parfois plus simple de supprimer et de recréer le noeud. Si les connexions
+ de l'application peuvent être détournées vers le noeud maître pendant cette opération,
+ alors il n'est pas nécessaire d'arrêter le service. </para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: SYNC aborted</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: new sl_rowid_seq value: %s</command></para>
-<para>Le <command>SYNC</command> a été annulé. Le &lslon; va probablement
-retenter ce <command>SYNC</command> dans quelque temps. Si le
-<command>SYNC</command> échoue encore et toujours, il y un problème récurrent,
-et la réplication ne va probablement pas reprendre sans une intervention.
-Il est peut-être nécessaire de désabonner/réabonner l'ensemble de réplication
-concerné, ou si il n'y a qu'un seul ensemble de réplication sur le noeud esclave,
-il est parfois plus simple de supprimer et de recréer le noeud. Si les connexions
-de l'application peuvent être détournées vers le noeud maître pendant cette opération,
-alors il n'est pas nécessaire d'arrêter le service. </para></listitem>
+ <para> Ce message rend compte de la progression de cette séquence interne de &slony1; . </para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: new sl_rowid_seq value: %s</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: SYNC %d done in %.3f seconds</command></para>
-<para> Ce message rend compte de la progression de cette séquence interne de &slony1; . </para></listitem>
+ <para> Ce message indique qu'un <command>SYNC</command> s'est achevé correctement. Hourra !</para></listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: SYNC %d done in %.3f seconds</command></para>
+ <listitem><para><command>DEBUG1: remoteWorkerThread_%d_d:%.3f seconds delay for first row </command></para>
-<para> Ce message indique qu'un <command>SYNC</command> s'est achevé correctement. Hourra !</para></listitem>
+ <para> Ce message indique combien de temps il a fallu pour récupérer la première ligne
+ du curseur LOG qui lit les données dans les tables sl_log tables.</para> </listitem>
-<listitem><para><command>DEBUG1: remoteWorkerThread_%d_d:%.3f seconds delay for first row </command></para>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d_d: large log_cmddata for actionseq %s not found</command></para>
-<para> Ce message indique combien de temps il a fallu pour récupérer la première ligne
-du curseur LOG qui lit les données dans les tables sl_log tables.</para> </listitem>
+ <para> &lslon; n'a pas trouvé les données relatives à un <quote>très grand</quote> tuple de la table sl_log
+ qui a été récupéré individuellement. Ceci ne devrait pas se produire.</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d_d: large log_cmddata for actionseq %s not found</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d_d:%.3f seconds until close cursor </command></para>
-<para> &lslon; n'a pas trouvé les données relatives à un <quote>très grand</quote> tuple de la table sl_log
-qui a été récupéré individuellement. Ceci ne devrait pas se produire.</para></listitem>
+ <para> Ceci indique combien de temps il a fallu pour lire les données dans le curseur LOG qui extrait les données des tables sl_log.</para> </listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d_d:%.3f seconds until close cursor </command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d_d: inserts=%d updates=%d deletes=%d </command></para>
-<para> Ceci indique combien de temps il a fallu pour lire les données dans le curseur LOG qui extrait les données des tables sl_log.</para> </listitem>
+ <para> Ce message montre quelle activité a été enregistré dans le <command>SYNC</command> courant. </para> </listitem>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d_d: inserts=%d updates=%d deletes=%d </command></para>
+ <listitem><para><command>DEBUG3: remoteWorkerThread_%d: compress_actionseq(list,subquery) Action list: %s</command></para>
-<para> Ce message montre quelle activité a été enregistré dans le <command>SYNC</command> courant. </para> </listitem>
+ <para> Ce message indique qu'une partir de la requête du curseur LOG va être compressée.
+ (Dans certains cas, les requêtes peuvent grossir jusqu'à une taille <emphasis>énorme</emphasis>
+ et faire exploser l'analyseur de requêtes...) </para></listitem>
+ <listitem><para><command>DEBUG3: remoteWorkerThread_%d: compressed actionseq subquery %s</command></para>
-<listitem><para><command>DEBUG3: remoteWorkerThread_%d: compress_actionseq(list,subquery) Action list: %s</command></para>
+ <para> Ce message indique comment la sous-requête a été compressée. </para></listitem>
-<para> Ce message indique qu'une partir de la requête du curseur LOG va être compressée.
-(Dans certains cas, les requêtes peuvent grossir jusqu'à une taille <emphasis>énorme</emphasis>
-et faire exploser l'analyseur de requêtes...) </para></listitem>
-<listitem><para><command>DEBUG3: remoteWorkerThread_%d: compressed actionseq subquery %s</command></para>
+ </itemizedlist>
+ </sect3>
-<para> Ce message indique comment la sous-requête a été compressée. </para></listitem>
+ <sect3 id="logaddobjects"><title> Messages concernant l'ajout d'objets dans des ensembles de réplication</title>
-</itemizedlist>
-</sect3>
+ <para> Ces messages apparaîtront dans les logs d'un noeud origine au moment
+ ou vous configurerez un ensemble de réplication; certains apparaîtront sur les noeuds abonnés
+ lors de leurs abonnement. </para>
-<sect3 id="logaddobjects"><title> Messages concernant l'ajout d'objets dans des ensembles de réplication</title>
+ <itemizedlist>
+ <listitem><para><command>ERROR: Slony-I: setAddTable_int(): table % has no index %</command></para>
+ <para> Apparemment un index PK qui a été spécifié est absent sur ce noeud...</para></listitem>
-<para> Ces messages apparaîtront dans les logs d'un noeud origine au moment
-ou vous configurerez un ensemble de réplication; certains apparaîtront sur les noeuds abonnés
-lors de leurs abonnement. </para>
+ <listitem><para><command>ERROR: Slony-I setAddTable_int(): table % not found</command></para>
-<itemizedlist>
-<listitem><para><command>ERROR: Slony-I: setAddTable_int(): table % has no index %</command></para>
+ <para> La table n'a pas été trouvé sur ce noeud; Avez-vous chargé correctement le schéma ? </para></listitem>
-<para> Apparemment un index PK qui a été spécifié est absent sur ce noeud...</para></listitem>
+ <listitem><para><command>ERROR: Slony-I setAddTable_int(): table % is not a regular table</command></para>
-<listitem><para><command>ERROR: Slony-I setAddTable_int(): table % not found</command></para>
+ <para> Vous avez tenté de répliquer quelque chose qui n'est pas dans la table;
+ Vous ne pouvez pas faire ça ! </para></listitem>
-<para> La table n'a pas été trouvé sur ce noeud; Avez-vous chargé correctement le schéma ? </para></listitem>
+ <listitem><para><command>NOTICE: Slony-I setAddTable_int(): table % PK column % nullable</command></para>
+ <para> Vous avez tenté de répliquer une table dont une colonne de la clef primaire candidate peut être null.
+ Toute les colonnes participant à une clef primaire doivent être <command>NOT NULL</command>.
+ Cette requête va échouer. </para>
-<listitem><para><command>ERROR: Slony-I setAddTable_int(): table % is not a regular table</command></para>
+ <para> Une vérification de cette condition fut introduit dans la version 1.2 de &slony1;.
+ Si vous avez un réplicat 1.1, il va continuer à fonctionner après la mise à jour en
+ 1.2, mais vous rencontrerez ce message lorsque vous essaierez d'ajouter de nouveaux abonnés.
+ </para>
-<para> Vous avez tenté de répliquer quelque chose qui n'est pas dans la table;
-Vous ne pouvez pas faire ça ! </para></listitem>
+ <para> Vous pouvez chercher des combinaisons table/index ayant des colonnes NULLABLE
+ sur un noeud existant avec la requête suivante :
+ following query:
+ <screen>
+ select c.relname as table_name, ic.relname as index_name, att.attname, att2.attnotnull
+ from _cluster.sl_table t, pg_catalog.pg_class c, pg_index i, pg_catalog.pg_class ic, pg_catalog.pg_attribute att, pg_catalog.pg_attribute att2
+ where t.tab_reloid = c.oid
+ and t.tab_idxname = ic.relname
+ and ic.oid = i.indexrelid
+ and att.attrelid = i.indexrelid
+ and att2.attname = att.attname
+ and att2.attrelid = c.oid
+ and att2.attnotnull = 'f';
+ </screen> </para>
-<listitem><para><command>NOTICE: Slony-I setAddTable_int(): table % PK column % nullable</command></para>
+ <para> Ces cas peuvent être rectifiés en exécutant à chaque fois un requête
+ du type : <command> alter table matable alter column nullablecol set
+ not null; </command>
-<para> Vous avez tenté de répliquer une table dont une colonne de la clef primaire candidate peut être null.
-Toute les colonnes participant à une clef primaire doivent être <command>NOT NULL</command>.
-Cette requête va échouer. </para>
+ Lancée sur un abonné ayant un table vide, cette requête s'exécutera très rapidement.
+ Elle prendra plus de temps sur une table qui contient déjà beaucoup de données,
+ car la modification nécessite un scan de la table pour vérifier qu'il n'existe aucun
+ tuple ayant la valeur NULL dans la colonne.
+ </para></listitem>
-<para> Une vérification de cette condition fut introduit dans la version 1.2 de &slony1;.
-Si vous avez un réplicat 1.1, il va continuer à fonctionner après la mise à jour en
-1.2, mais vous rencontrerez ce message lorsque vous essaierez d'ajouter de nouveaux abonnés.
-</para>
+ <listitem><para><command>ERROR: Slony-I setAddTable_int(): table % not replicable!</command></para>
+ <para> Ceci se produit à cause d'une colonne qui n'est pas NOT NULL dans un clef primaire . </para></listitem>
-<para> Vous pouvez chercher des combinaisons table/index ayant des colonnes NULLABLE
-sur un noeud existant avec la requête suivante :
-following query:
-<screen>
-select c.relname as table_name, ic.relname as index_name, att.attname, att2.attnotnull
-from _cluster.sl_table t, pg_catalog.pg_class c, pg_index i, pg_catalog.pg_class ic, pg_catalog.pg_attribute att, pg_catalog.pg_attribute att2
-where t.tab_reloid = c.oid
- and t.tab_idxname = ic.relname
- and ic.oid = i.indexrelid
- and att.attrelid = i.indexrelid
- and att2.attname = att.attname
- and att2.attrelid = c.oid
- and att2.attnotnull = 'f';
-</screen> </para>
+ <listitem><para><command>ERROR: Slony-I setAddTable_int(): table id % has already been assigned!</command></para>
+ <para> L'identifiant de la table doit être assigné de manière unique dans
+ <xref linkend="stmtsetaddtable"/>; apparemment vous avez demandé une valeur qui est déjà utilisée.
+ </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setAddSequence(): set % not found</command></para>
+ <para> Apparemment l'ensemble que vous demandez n'est pas disponible...</para></listitem>
-<para> Ces cas peuvent être rectifiés en exécutant à chaque fois un requête
-du type : <command> alter table matable alter column nullablecol set
-not null; </command>
+ <listitem><para><command>ERROR: Slony-I setAddSequence(): set % has remote origin</command></para>
+ <para> Vous pouvez uniquement ajouter des choses sur le noeud origine.</para></listitem>
-Lancée sur un abonné ayant un table vide, cette requête s'exécutera très rapidement.
-Elle prendra plus de temps sur une table qui contient déjà beaucoup de données,
-car la modification nécessite un scan de la table pour vérifier qu'il n'existe aucun
-tuple ayant la valeur NULL dans la colonne.
-</para>
+ <listitem>
+ <para><command>ERROR: Slony-I setAddSequence(): cannot add sequence to currently subscribed set %</command></para>
+ <para> Apparemment l'ensemble de réplication que vous demandez a déjà été abonné.
+ Vous ne pouvez pas ajouter des tables/séquences dans un ensemble qui a déjà des abonnés.
+ Vous devez créer un nouvel ensemble, y ajouter des objets, et définir ses abonnements
+ </para></listitem>
-</listitem>
+ <listitem><para><command>ERROR: Slony-I setAddSequence_int(): set % not found</command></para>
+ <para> Apparemment l'ensemble que vous demandez n'est pas disponible...</para></listitem>
-<listitem><para><command>ERROR: Slony-I setAddTable_int(): table % not replicable!</command></para>
+ <listitem><para><command>ERROR: Slony-I setAddSequence_int(): sequence % not found</command></para>
+ <para> Apparemment la séquence que vous demandez n'est pas disponible sur ce noeud.
+ Comment avez-vous mis en place le schéma sur les noeuds abonnés ???</para></listitem>
-<para> Ceci se produit à cause d'une colonne qui n'est pas NOT NULL dans un clef primaire . </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setAddSequence_int(): % is not a sequence</command></para>
+ <para> Ce message est assez évident :-).</para></listitem>
-<listitem><para><command>ERROR: Slony-I setAddTable_int(): table id % has already been assigned!</command></para>
+ <listitem><para><command>ERROR: Slony-I setAddSequence_int(): sequence ID % has already been assigned</command></para>
+ <para> Chaque identifiant de séquence ajouté doit être unique. Apparemment vous avez réutilisé un identifiant
+ déjà existant.</para></listitem>
+ </itemizedlist>
+ </sect3>
-<para> L'identifiant de la table doit être assigné de manière unique dans
-<xref linkend="stmtsetaddtable"/>; apparemment vous avez demandé une valeur qui est déjà utilisée.
-</para></listitem>
-<listitem><para><command>ERROR: Slony-I setAddSequence(): set % not found</command></para>
-<para> Apparemment l'ensemble que vous demandez n'est pas disponible...</para></listitem>
+ <sect3><title> Messages lors du déplacement d'un objet d'un ensemble vers un autre </title>
-<listitem><para><command>ERROR: Slony-I setAddSequence(): set % has remote origin</command></para>
-<para> Vous pouvez uniquement ajouter des choses sur le noeud origine.</para></listitem>
+ <itemizedlist>
+ <listitem><para><command>ERROR: Slony-I setMoveTable_int(): table % not found</command></para>
-<listitem><para><command>ERROR: Slony-I setAddSequence(): cannot add sequence to currently subscribed set %</command></para>
-<para> Apparemment l'ensemble de réplication que vous demandez a déjà été abonné.
-Vous ne pouvez pas ajouter des tables/séquences dans un ensemble qui a déjà des abonnés.
-Vous devez créer un nouvel ensemble, y ajouter des objets, et définir ses abonnements
-</p>
+ <para> La table n'a pas été trouvée sur ce noeud; vous avez probablement indiqué le mauvais
+ identifiant.. </para></listitem>
-<listitem><para><command>ERROR: Slony-I setAddSequence_int(): set % not found</command></para>
+ <listitem><para><command>ERROR: Slony-I setMoveTable_int(): set ids cannot be identical</command></para>
-<para> Apparemment l'ensemble que vous demandez n'est pas disponible...</para></listitem>
+ <para> Quel est l'intérêt de déplacer une table dans un ensemble où elle se trouve déjà ?
+ </para></listitem>
-<listitem><para><command>ERROR: Slony-I setAddSequence_int(): sequence % not found</command></para>
+ <listitem><para><command>ERROR: Slony-I setMoveTable_int(): set % not found</command></para>
-<para> Apparemment la séquence que vous demandez n'est pas disponible sur ce noeud.
-Comment avez-vous mis en place le schéma sur les noeuds abonnés ???</para></listitem>
+ <para> L'ensemble n'a pas été trouvé sur le noeud; vous avez probablement indiqué un mauvais identifiant... </para></listitem>
-<listitem><para><command>ERROR: Slony-I setAddSequence_int(): % is not a sequence</command></para>
+ <listitem><para><command>ERROR: Slony-I setMoveTable_int(): set % does not originate on local node</command></para>
-<para> Ce message est assez évident :-).</para></listitem>
+ <para> L'ensemble n'est pas originaire de ce noeud; vous avez probablement indiqué le mauvais EVENT NODE... </para></listitem>
-<listitem><para><command>ERROR: Slony-I setAddSequence_int(): sequence ID % has already been assigned</command></para>
-<para> Chaque identifiant de séquence ajouté doit être unique. Apparemment vous avez réutilisé un identifiant
-déjà existant.</para></listitem>
+ <listitem><para><command>ERROR: Slony-I setMoveTable_int(): subscriber lists of set % and % are different</command></para>
-</itemizedlist>
-</sect3>
+ <para> Vous pouvez uniquement déplacer les objets entre des ensembles qui ont la même liste d'abonnés. </para></listitem>
-<sect3><title> Messages lors du déplacement d'un objet d'un ensemble vers un autre </title>
+ <listitem><para><command>ERROR: Slony-I setMoveSequence_int(): sequence % not found</command></para>
-<itemizedlist>
-<listitem><para><command>ERROR: Slony-I setMoveTable_int(): table % not found</command></para>
+ <para> La séquence n'a pas été trouvé sur ce noeud; vous avez probablement indiqué un mauvais identifiant... </para></listitem>
-<para> La table n'a pas été trouvée sur ce noeud; vous avez probablement indiqué le mauvais
-identifiant.. </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setMoveSequence_int(): set ids cannot be identical</command></para>
-<listitem><para><command>ERROR: Slony-I setMoveTable_int(): set ids cannot be identical</command></para>
+ <para> Quel est l'intérêt de déplacer une séquence dans un ensemble où elle se trouve déjà ? </para></listitem>
-<para> Quel est l'intérêt de déplacer une table dans un ensemble où elle se trouve déjà ?
-</para></listitem>
+ <listitem><para><command>ERROR: Slony-I setMoveSequence_int(): set % not found</command></para>
-<listitem><para><command>ERROR: Slony-I setMoveTable_int(): set % not found</command></para>
+ <para> L'ensemble n'a pas été trouvé sur le noeud; vous avez probablement indiqué un mauvais identifiant... </para></listitem>
-<para> L'ensemble n'a pas été trouvé sur le noeud; vous avez probablement indiqué un mauvais identifiant... </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setMoveSequence_int(): set % does not originate on local node</command></para>
-<listitem><para><command>ERROR: Slony-I setMoveTable_int(): set % does not originate on local node</command></para>
+ <para> L'ensemble n'est pas originaire de ce noeud; vous avez probablement indiqué le mauvais EVENT NODE.... </para></listitem>
-<para> L'ensemble n'est pas originaire de ce noeud; vous avez probablement indiqué le mauvais EVENT NODE... </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setMoveSequence_int(): subscriber lists of set % and % are different</command></para>
-<listitem><para><command>ERROR: Slony-I setMoveTable_int(): subscriber lists of set % and % are different</command></para>
+ <para> Vous pouvez uniquement déplacer les objets entre des ensembles qui ont la même liste d'abonnés. </para></listitem>
+ </itemizedlist>
+ </sect3>
-<para> Vous pouvez uniquement déplacer les objets entre des ensembles qui ont la même liste d'abonnés. </para></listitem>
-<listitem><para><command>ERROR: Slony-I setMoveSequence_int(): sequence % not found</command></para>
+ <sect3><title> Problèmes lors de la suppression d'objets</title>
-<para> La séquence n'a pas été trouvé sur ce noeud; vous avez probablement indiqué un mauvais identifiant... </para></listitem>
+ <itemizedlist>
+ <listitem><para><command>ERROR: Slony-I setDropTable(): table % not found</command></para>
-<listitem><para><command>ERROR: Slony-I setMoveSequence_int(): set ids cannot be identical</command></para>
+ <para> La table n'a pas été trouvée sur ce noeud; Êtes-vous sur(e) d'avoir indiqué le bon identifiant ?
+ </para></listitem>
-<para> Quel est l'intérêt de déplacer une séquence dans un ensemble où elle se trouve déjà ? </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setDropTable(): set % not found</command></para>
-<listitem><para><command>ERROR: Slony-I setMoveSequence_int(): set % not found</command></para>
+ <para> L'ensemble de réplication n'a pas été trouvé sur ce noeud; Êtes-vous sûre d'avoir indiqué le bon identifiant ? </para></listitem>
-<para> L'ensemble n'a pas été trouvé sur le noeud; vous avez probablement indiqué un mauvais identifiant... </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setDropTable(): set % has remote origin</command></para>
-<listitem><para><command>ERROR: Slony-I setMoveSequence_int(): set % does not originate on local node</command></para>
+ <para> L'ensemble de réplication n'a pas ce noeud pour origine; Vous devez probablement spécifier le paramètre
+ <command>EVENT NODE</command> dans la commande <xref linkend="stmtsetdroptable"/>. </para></listitem>
-<para> L'ensemble n'est pas originaire de ce noeud; vous avez probablement indiqué le mauvais EVENT NODE.... </para></listitem>
+ <listitem><para><command>ERROR: Slony-I setDropSequence_int(): sequence % not found</command></para>
+ <para> Est-ce que cette séquence ne trouverait pas plutôt dans un autre ensemble ?</para></listitem>
-<listitem><para><command>ERROR: Slony-I setMoveSequence_int(): subscriber lists of set % and % are different</command></para>
+ <listitem><para><command>ERROR: Slony-I setDropSequence_int(): set % not found</command></para>
+ <para> Avez-vous spécifié le bon identifiant d'ensemble de réplication ?</para></listitem>
-<para> Vous pouvez uniquement déplacer les objets entre des ensembles qui ont la même liste d'abonnés. </para></listitem>
-</itemizedlist>
-</sect3>
+ <listitem><para><command>ERROR: Slony-I setDropSequence_int(): set % has origin at another node - submit this to that node</command></para>
+ <para> Ce message semble assez évident...</para></listitem>
-<sect3><title> Problèmes lors de la suppression d'objets</title>
+ </itemizedlist>
+ </sect3>
-<itemizedlist>
-<listitem><para><command>ERROR: Slony-I setDropTable(): table % not found</command></para>
+ <sect3><title> Problèmes lors de MOVE SET, FAILOVER, DROP NODE </title>
-<para> La table n'a pas été trouvée sur ce noeud; Êtes-vous sur(e) d'avoir indiqué le bon identifiant ?
-</para></listitem>
+ <para> Beaucoup de ces erreurs se produiront si vous soumettez un script &lslonik;
+ qui décrit une reconfiguration incompatible avec la configuration actuelle de votre
+ cluster. Ceci devrait vous faire dire :
+ <quote>Whaou, heureusement que &lslonik; a détecté ce problème à ma place !</quote> </para>
-<listitem><para><command>ERROR: Slony-I setDropTable(): set % not found</command></para>
+ <para> D'autres messages se produisent lorsque &lslon; s'avertit lui-même qu'il va
+ s'arrêter. Tout <emphasis>devrait</emphasis> bien se passer lorsque vous le redémarrez,
+ car il lira la nouvelle configuration lors de son redémarrage.</para>
-<para> L'ensemble de réplication n'a pas été trouvé sur ce noeud; Êtes-vous sûre d'avoir indiqué le bon identifiant ? </para></listitem>
+ <para> Hélas, quelques messages indiquent que <quote>quelque chose de mauvais est arrivé
+ </quote>, auquel cas la solution ne sera pas nécessairement simple.
+ Personne n'a dit que la réplication c'était facile...</para>
-<listitem><para><command>ERROR: Slony-I setDropTable(): set % has remote origin</command></para>
+ <itemizedlist>
+ <listitem><para><command>ERROR: Slony-I: DROP_NODE cannot initiate on the dropped node</command></para>
-<para> L'ensemble de réplication n'a pas ce noeud pour origine; Vous devez probablement spécifier le paramètre
-<command>EVENT NODE</command> dans la commande <xref linkend="stmtsetdroptable"/>. </para></listitem>
+ <para> Vous devez préciser un paramètre EVENT NODE différent du noeud que vous voulez supprimer.... </para></listitem>
-<listitem><para><command>ERROR: Slony-I setDropSequence_int(): sequence % not found</command></para>
-<para> Est-ce que cette séquence ne trouverait pas plutôt dans un autre ensemble ?</para></listitem>
+ <listitem><para><command>ERROR: Slony-I: Node % is still configured as a data provider</command></para>
-<listitem><para><command>ERROR: Slony-I setDropSequence_int(): set % not found</command></para>
-<para> Avez-vous spécifié le bon identifiant d'ensemble de réplication ?</para></listitem>
+ <para> Vous ne pouvez pas supprimer un noeud qui est utilisé comme fournisseur de données;
+ vous devez remodeler les abonnements pour qu'aucun noeud ne soit dépendant de celui-ci.
+ </para></listitem>
-<listitem><para><command>ERROR: Slony-I setDropSequence_int(): set % has origin at another node - submit this to that node</command></para>
+ <listitem><para><command>ERROR: Slony-I: Node % is still origin of one or more sets</command></para>
-<para> Ce message semble assez évident...</para></listitem>
+ <para> Vous ne pouvez pas supprimer un noeud si c'est l'origine d'un ensemble de réplication !
+ Utilisez d'abord <xref linkend="stmtmoveset"/> ou <xref linkend="stmtfailover"/>. </para></listitem>
-</itemizedlist>
-</sect3>
+ <listitem><para><command>ERROR: Slony-I: cannot failover - node % has no path to the backup node</command></para>
-<sect3><title> Problèmes lors de MOVE SET, FAILOVER, DROP NODE </title>
+ <para> Vous ne pouvez pas effectuer une bascule d'urgence vers un noeud qui n'est pas connecté à tous les abonnés, au moins indirectement.
+ </para></listitem>
-<para> Beaucoup de ces erreurs se produiront si vous soumettez un script &lslonik;
-qui décrit une reconfiguration incompatible avec la configuration actuelle de votre
-cluster. Ceci devrait vous faire dire :
-<quote>Whaou, heureusement que &lslonik; a détecté ce problème à ma place !</quote> </para>
+ <listitem><para><command>ERROR: Slony-I: cannot failover - node % is not subscribed to set %</command></para>
-<para> D'autres messages se produisent lorsque &lslon; s'avertit lui-même qu'il va
-s'arrêter. Tout <emphasis>devrait</emphasis> bien se passer lorsque vous le redémarrez,
-car il lira la nouvelle configuration lors de son redémarrage.</para>
+ <para> Vous ne pouvez pas faire une bascule d'urgence vers un noeud qui n'est pas abonné à tous les ensembles de réplication essentiels. </para></listitem>
-<para> Hélas, quelques messages indiquent que <quote>quelque chose de mauvais est arrivé
-</quote>, auquel cas la solution ne sera pas nécessairement simple.
-Personne n'a dit que la réplication c'était facile...</para>
+ <listitem><para><command>ERROR: Slony-I: cannot failover - subscription for set % is not active</command></para>
-<itemizedlist>
-<listitem><para><command>ERROR: Slony-I: DROP_NODE cannot initiate on the dropped node</command></para>
+ <para> Si l'abonnement a été configuré mais pas activé, la bascule d'urgence n'est pas possible.</para></listitem>
-<para> Vous devez préciser un paramètre EVENT NODE différent du noeud que vous voulez supprimer.... </para></listitem>
+ <listitem><para><command>ERROR: Slony-I: cannot failover - node % is not a forwarder of set %</command></para>
-<listitem><para><command>ERROR: Slony-I: Node % is still configured as a data provider</command></para>
+ <para> Vous ne pouvez effectuer une bascule d'urgence ou un bascule contrôlée que vers un noeud
+ transmetteur. </para></listitem>
-<para> Vous ne pouvez pas supprimer un noeud qui est utilisé comme fournisseur de données;
-vous devez remodeler les abonnements pour qu'aucun noeud ne soit dépendant de celui-ci.
-</para></listitem>
+ <listitem><para><command>NOTICE: failedNode: set % has no other direct receivers - move now</command></para>
-<listitem><para><command>ERROR: Slony-I: Node % is still origin of one or more sets</command></para>
+ <para> Si le noeud de sauvegarde est le seul abonné direct, alors la situation est simplifiée...
+ Pas besoin de remodeler les abonnements !</para></listitem>
-<para> Vous ne pouvez pas supprimer un noeud si c'est l'origine d'un ensemble de réplication !
-Utilisez d'abord <xref linkend="stmtmoveset"/> ou <xref linkend="stmtfailover"/>. </para></listitem>
+ <listitem><para><command>NOTICE: failedNode set % has other direct receivers - change providers only</command></para>
+ <para> Dans ce cas, tous les abonnés direct sont redirigés vers le noeud de sauvegarde et le noeud de sauvegarde est redirigé
+ vers un autre noeud pour qu'il puisse rattraper son retard.</para></listitem>
-<listitem><para><command>ERROR: Slony-I: cannot failover - node % has no path to the backup node</command></para>
+ <listitem><para><command>NOTICE: Slony-I: Please drop schema _ at CLUSTERNAME@</command></para>
-<para> Vous ne pouvez pas effectuer une bascule d'urgence vers un noeud qui n'est pas connecté à tous les abonnés, au moins indirectement.
-</para></listitem>
+ <para> Un noeud a été désinstallé; vous pouvez supprimer le schéma... </para></listitem>
-<listitem><para><command>ERROR: Slony-I: cannot failover - node % is not subscribed to set %</command></para>
-<para> Vous ne pouvez pas faire une bascule d'urgence vers un noeud qui n'est pas abonné à tous les ensembles de réplication essentiels. </para></listitem>
+ </itemizedlist>
+ </sect3>
-<listitem><para><command>ERROR: Slony-I: cannot failover - subscription for set % is not active</command></para>
+ <sect3><title> Permutation des logs </title>
-<para> Si l'abonnement a été configuré mais pas activé, la bascule d'urgence n'est pas possible.</para></listitem>
+ <para> Ces messages sont liés à la nouvelle fonctionnalité apparue dans la version 1.2 qui
+ permet à &slony1; de permuter périodiquement le stockage des données entre
+ <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.</para>
-<listitem><para><command>ERROR: Slony-I: cannot failover - node % is not a forwarder of set %</command></para>
+ <itemizedlist>
+ <listitem><para><command>Slony-I: Logswitch to sl_log_2 initiated'</command></para>
-<para> Vous ne pouvez effectuer une bascule d'urgence ou un bascule contrôlée que vers un noeud
-transmetteur. </para></listitem>
+ <para> Ce message indique que &lslon; est en train de permuter vers cette table de log.</para></listitem>
-<listitem><para><command>NOTICE: failedNode: set % has no other direct receivers - move now</command></para>
+ <listitem><para><command>Slony-I: Logswitch to sl_log_1 initiated'</command></para>
-<para> Si le noeud de sauvegarde est le seul abonné direct, alors la situation est simplifiée...
-Pas besoin de remodeler les abonnements !</para></listitem>
+ <para> Ce message indique &lslon; est en train de permuter vers cette table de log .</para></listitem>
-<listitem><para><command>NOTICE: failedNode set % has other direct receivers - change providers only</command></para>
-<para> Dans ce cas, tous les abonnés direct sont redirigés vers le noeud de sauvegarde et le noeud de sauvegarde est redirigé
-vers un autre noeud pour qu'il puisse rattraper son retard.</para></listitem>
+ <listitem><para><command>Previous logswitch still in progress</command></para>
-<listitem><para><command>NOTICE: Slony-I: Please drop schema _ at CLUSTERNAME@</command></para>
+ <para> Un tentative de permutation a été faite alors qu'une permutation était déjà en cours...</para></listitem>
-<para> Un noeud a été désinstallé; vous pouvez supprimer le schéma... </para></listitem>
+ <listitem><para><command>ERROR: remoteWorkerThread_%d: cannot détermine current log status</command></para>
+ <para> La tentative de lecture dans la table sl_log_status, qui détermine si on travaille sur
+ <envar>sl_log_1</envar> ou <envar>sl_log_2</envar>, n'a donné aucun résultat.
+ Ce n'est pas bon signe, car il doit y avoir des données dans cette table....
+ La réplication va probablement s'arrêter dans peu de temps...</para> </listitem>
-</itemizedlist>
-</sect3>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: current local log_status is %d</command></para>
+ <para> Ce message indique quelle table ( <envar>sl_log_1</envar> ou <envar>sl_log_2</envar> ) est utilisé
+ pour stocker les données de réplication. </para>
+ </listitem>
-<sect3><title> Permutation des logs </title>
+ </itemizedlist>
+ </sect3>
+ <sect3><title> Divers </title>
-<para> Ces messages sont liés à la nouvelle fonctionnalité apparue dans la version 1.2 qui
-permet à &slony1; de permuter périodiquement le stockage des données entre
- <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.</para>
+ <para> Le messages ci-dessous ne sont pas encore classés; les auteurs de la documentation ont
+ encore du travail...
+ <itemizedlist>
-<itemizedlist>
-<listitem><para><command>Slony-I: Logswitch to sl_log_2 initiated'</command></para>
+ <listitem><para><command>ERROR: Slonik version: @MODULEVERSION@ != Slony-I version in PG build %</command></para>
-<para> Ce message indique que &lslon; est en train de permuter vers cette table de log.</para></listitem>
+ <para> Ce message est produit par la fonction <function>checkmoduleversion()</function> lorsqu'il y a
+ un problème de correspondance entre la version de &slony1; telle qu'elle est indiquée par &lslonik;
+ et le version avec laquelle &postgres; a été compilé.</para></listitem>
-<listitem><para><command>Slony-I: Logswitch to sl_log_1 initiated'</command></para>
+ <listitem><para><command>ERROR: Slony-I: registry key % is not an int4 value</command></para>
-<para> Ce message indique &lslon; est en train de permuter vers cette table de log .</para></listitem>
+ <para> Message produit par <function>registry_get_int4()</function>, cela indique que la valeur demandée semble être à NULL.</para> </listitem>
+ <listitem><para><command>ERROR: registry key % is not a text value</command></para>
-<listitem><para><command>Previous logswitch still in progress</command></para>
+ <para> Message produit par <function>registry_get_text()</function>, cela indique que la valeur demandée semble être à NULL</para></listitem>
+ <listitem><para><command>ERROR: registry key % is not a timestamp value</command></para>
-<para> Un tentative de permutation a été faite alors qu'une permutation était déjà en cours...</para></listitem>
+ <para> Message produit par <function>registry_get_timestamp()</function>, cela indique que la valeur demandée semble être à NULL</para></listitem>
-<listitem><para><command>ERROR: remoteWorkerThread_%d: cannot détermine current log status</command></para>
+ <listitem><para><command>NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=%</command></para>
-<para> La tentative de lecture dans la table sl_log_status, qui détermine si on travaille sur
-<envar>sl_log_1</envar> ou <envar>sl_log_2</envar>, n'a donné aucun résultat.
-Ce n'est pas bon signe, car il doit y avoir des données dans cette table....
-La réplication va probablement s'arrêter dans peu de temps...</para> </listitem>
+ <para> This will occur when a &lslon; starts up after another has crashed; this is routine cleanup.</para></listitem>
+ <listitem><para><command>ERROR: Slony-I: This node is already initialized</command></para>
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: current local log_status is %d</command></para>
-<para> Ce message indique quelle table ( <envar>sl_log_1</envar> ou <envar>sl_log_2</envar> ) est utilisé
-pour stocker les données de réplication. </para>
-</listitem>
+ <para> Ceci se produit typiquement lorsque l'on soumet une commande <xref linkend="stmtstorenode"/> sur une noeud
+ qui a déjà été configuré avec le schéma &slony1;. </para></listitem>
-</itemizedlist>
-</sect3>
-<sect3><title> Divers </title>
+ <listitem><para><command>ERROR: Slony-I: node % not found</command></para>
-<para> Le messages ci-dessous ne sont pas encore classés; les auteurs de la documentation ont
-encore du travail...</para>
+ <para> Toute tentative pour marquer un noeud non listé localement comme actif devrait échouer...</para></listitem>
+ <listitem><para><command>ERROR: Slony-I: node % is already active</command></para>
-<itemizedlist>
+ <para> Toute tentative pour marquer un noeud déjà marqué comme actif devrait échouer...</para></listitem>
+ <listitem><para><command>DEBUG4: remoteWorkerThread_%d: added active set %d to provider %d</command></para>
-<listitem><para><command>ERROR: Slonik version: @MODULEVERSION@ != Slony-I version in PG build %</command></para>
+ <para> Indique que cet ensemble est fourni par ce fournisseur.</para></listitem>
-<para> Ce message est produit par la fonction <function>checkmoduleversion()</function> lorsqu'il y a
-un problème de correspondance entre la version de &slony1; telle qu'elle est indiquée par &lslonik;
-et le version avec laquelle &postgres; a été compilé.</para></listitem>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: event %d
+ ignored - unknown origin</command></para>
-<listitem><para><command>ERROR: Slony-I: registry key % is not an int4 value</command></para>
+ <para> Ceci se produit probablement lorsque des événements arrivent avant
+ l'événement <command>STORE_NODE</command> qui annonce que le nouveau noeud existe... </para></listitem>
-<para> Message produit par <function>registry_get_int4()</function>, cela indique que la valeur demandée semble être à NULL.</para> </listitem>
-<listitem><para><command>ERROR: registry key % is not a text value</command></para>
+ <listitem><para><command>WARN: remoteWorkerThread_%d: event %d ignored - origin inactive</command></para>
-<para> Message produit par <function>registry_get_text()</function>, cela indique que la valeur demandée semble être à NULL</para></listitem>
-<listitem><para><command>ERROR: registry key % is not a timestamp value</command></para>
+ <para> Ceci ce produit actuellement (2007) car la désactivation d'un noeud n'est pas une fonctionnalité supportée... </para>
+ </listitem>
-<para> Message produit par <function>registry_get_timestamp()</function>, cela indique que la valeur demandée semble être à NULL</para></listitem>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: event %d ignored - duplicate </command></para>
-<listitem><para><command>NOTICE: Slony-I: cleanup stale sl_nodelock entry for pid=%</command></para>
+ <para> Ceci devrait se produire lorsqu'une notification d'événement arrive en provenance de
+ deux sources... </para> </listitem>
-<para> This will occur when a &lslon; starts up after another has crashed; this is routine cleanup.</para></listitem>
-<listitem><para><command>ERROR: Slony-I: This node is already initialized</command></para>
+ <listitem><para><command>DEBUG2: remoteWorkerThread_%d: unknown node %d</command></para>
-<para> Ceci se produit typiquement lorsque l'on soumet une commande <xref linkend="stmtstorenode"/> sur une noeud
-qui a déjà été configuré avec le schéma &slony1;. </para></listitem>
-
-<listitem><para><command>ERROR: Slony-I: node % not found</command></para>
-
-<para> Toute tentative pour marquer un noeud non listé localement comme actif devrait échouer...</para></listitem>
-<listitem><para><command>ERROR: Slony-I: node % is already active</command></para>
-
-<para> Toute tentative pour marquer un noeud déjà marqué comme actif devrait échouer...</para></listitem>
-<listitem><para><command>DEBUG4: remoteWorkerThread_%d: added active set %d to provider %d</command></para>
-
-<para> Indique que cet ensemble est fourni par ce fournisseur.</para></listitem>
-
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: event %d
-ignored - unknown origin</command></para>
-
-<para> Ceci se produit probablement lorsque des événements arrivent avant
-l'événement <command>STORE_NODE</command> qui annonce que le nouveau noeud existe... </para></listitem>
-
-<listitem><para><command>WARN: remoteWorkerThread_%d: event %d ignored - origin inactive</command></para>
-
-<para> Ceci ce produit actuellement (2007) car la désactivation d'un noeud n'est pas une fonctionnalité supportée... </para>
-</listitem>
-
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: event %d ignored - duplicate </command></para>
-
-<para> Ceci devrait se produire lorsqu'une notification d'événement arrive en provenance de
-deux sources... </para> </listitem>
-
-<listitem><para><command>DEBUG2: remoteWorkerThread_%d: unknown node %d</command></para>
-
-<para> Ceci se produit lorsque le démon &lslon; n'est conscient de l'existence de ce noeud;
-C'est probablement un signe que les requêtes <command>STORE_NODE</command> ne se propagent pas
-... </para> </listitem>
-</itemizedlist>
-</sect3>
+ <para> Ceci se produit lorsque le démon &lslon; n'est conscient de l'existence de ce noeud;
+ C'est probablement un signe que les requêtes <command>STORE_NODE</command> ne se propagent pas
+ ... </para> </listitem>
+ </itemizedlist>
+ </para>
+ </sect3>
</sect2>
</sect1>
Modified: traduc/trunk/slony/partitioning.xml
===================================================================
--- traduc/trunk/slony/partitioning.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/partitioning.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -27,7 +27,7 @@
<para> Cet exemple est un peu simpliste car il fournit uniquement des règles
d'insertion dans les différentes partitions; il ne permet pas de migrer des
tuples d'une partition à une autre si ils sont modifiés via une commande
- <COMMAND>UPDATE</COMMAND> statement. D'un autre coté, à la différence de
+ <command>UPDATE</command> statement. D'un autre coté, à la différence de
de beaucoup de partitionnement, celui-ci permet à la table <quote>parente</quote>
de contenir des tuples. </para>
Modified: traduc/trunk/slony/prerequisites.xml
===================================================================
--- traduc/trunk/slony/prerequisites.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/prerequisites.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -141,7 +141,7 @@
un bug (corrigé en 8.1.4) empêche la fonction
<xref linkend="stmtupdatefunctions" />
de s'exécuter correctement. Pour plus de détails, voir
- <xref linkend="FAQ" />
+ <xref linkend="faq" />
,
<link linkend="pg81funs">
Modified: traduc/trunk/slony/releasechecklist.xml
===================================================================
--- traduc/trunk/slony/releasechecklist.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/releasechecklist.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -4,7 +4,7 @@
par $Author$
révision $Revision$ -->
-<article id="releasechecklist"> <title>Liste de vérification pour chaque version</title>
+<sect1 id="releasechecklist"> <title>Liste de vérification pour chaque version</title>
<indexterm><primary>Liste de vérifications pour chaque version</primary></indexterm>
@@ -154,4 +154,4 @@
</para></listitem>
</itemizedlist>
-</article>
+</sect1>
Modified: traduc/trunk/slony/slon.xml
===================================================================
--- traduc/trunk/slony/slon.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/slon.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -5,425 +5,339 @@
révision $Revision$ -->
<refentry id="slon">
- <refmeta>
- <refentrytitle id="app-slon-title"><application>slon</application></refentrytitle>
- <manvolnum>1</manvolnum>
- <refmiscinfo>Application</refmiscinfo>
- </refmeta>
- <refnamediv>
- <refname><application>slon</application></refname>
- <refpurpose>
- Le démon &slony1;
- </refpurpose>
- </refnamediv>
+ <refmeta>
+ <refentrytitle id="app-slon-title"><application>slon</application></refentrytitle>
+ <manvolnum>1</manvolnum>
+ <refmiscinfo>Application</refmiscinfo>
+ </refmeta>
+ <refnamediv>
+ <refname><application>slon</application></refname>
+ <refpurpose>
+ Le démon &slony1;
+ </refpurpose>
+ </refnamediv>
- <indexterm zone="slon">
- <primary>slon</primary>
- </indexterm>
+ <indexterm zone="slon">
+ <primary>slon</primary>
+ </indexterm>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>slon</command>
- <arg rep="repeat"><replaceable class="parameter">option</replaceable></arg>
- <arg><replaceable class="parameter">clustername</replaceable></arg>
- <arg><replaceable class="parameter">conninfo</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>slon</command>
+ <arg rep="repeat"><replaceable class="parameter">option</replaceable></arg>
+ <arg><replaceable class="parameter">clustername</replaceable></arg>
+ <arg><replaceable class="parameter">conninfo</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- <application>slon</application> est un démon applicatif qui
- <quote>contrôle</quote> la réplication &slony1;. Une
- instance <application>slon</application> doit être lancée pour
- chaque noeud du cluster &slony1;.
- </para>
- </refsect1>
-
- <refsect1 id="r1-app-slon-3">
- <title>Options</title>
+ <refsect1>
+ <title>Description</title>
+ <para><application>slon</application> est un démon applicatif qui
+ <quote>contrôle</quote> la réplication &slony1;. Une
+ instance <application>slon</application> doit être lancée pour
+ chaque noeud du cluster &slony1;.</para>
+ </refsect1>
- <variablelist>
- <varlistentry>
- <term><option>-d</option><replaceable class="parameter"> log_level</replaceable></term>
- <listitem>
- <para>
- Le paramètre <envar>log_level</envar> spécifie quel niveau de messages de debug
- <application>slon</application> doit afficher dans son journal d'activité.
- </para>
- <para id="nineloglevels">
- Il y a neuf niveaux de log :
- <itemizedlist>
- <listitem><para>Fatal</para></listitem>
- <listitem><para>Error</para></listitem>
- <listitem><para>Warn</para></listitem>
- <listitem><para>Config</para></listitem>
- <listitem><para>Info</para></listitem>
- <listitem><para>Debug1</para></listitem>
- <listitem><para>Debug2</para></listitem>
- <listitem><para>Debug3</para></listitem>
- <listitem><para>Debug4</para></listitem>
- </itemizedlist>
- </para>
+ <refsect1 id="r1-app-slon-3">
+ <title>Options</title>
+ <variablelist>
+ <varlistentry>
+ <term><option>-d</option><replaceable class="parameter"> log_level</replaceable></term>
+ <listitem>
+ <para>Le paramètre <envar>log_level</envar> spécifie quel niveau de messages de debug
+ <application>slon</application> doit afficher dans son journal d'activité.</para>
+ <para id="nineloglevels">Il y a neuf niveaux de log :
+ <itemizedlist>
+ <listitem><para>Fatal</para></listitem>
+ <listitem><para>Error</para></listitem>
+ <listitem><para>Warn</para></listitem>
+ <listitem><para>Config</para></listitem>
+ <listitem><para>Info</para></listitem>
+ <listitem><para>Debug1</para></listitem>
+ <listitem><para>Debug2</para></listitem>
+ <listitem><para>Debug3</para></listitem>
+ <listitem><para>Debug4</para></listitem>
+ </itemizedlist>
+ </para>
+ <para> Les cinq premiers niveau de log ( de Fatal à
+ Info) sont <emphasis>toujours</emphasis> affichés dans les logs.
+ Dans les premières versions de &slony1;, le niveau de log
+ <quote>suggéré</quote> était 2, ce qui affichait tous les messages
+ jusqu'au niveau Debug2. Avec &slony1; version 2, il est
+ recommandé de positionner <envar>log_level</envar> à 0; la
+ pluspart des informations intéressantes sont produites à
+ des niveaux supérieurs à celui-là.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-s</option><replaceable class="parameter"> Interval entre les vérifications SYNC</replaceable></term>
+ <listitem>
+ <para>Le paramètre <envar>sync_interval</envar>, exprimé en millisecondes,
+ indique à quelle fréquence <application>slon</application> doit
+ vérifier si un événement <command>SYNC</command> doit
+ être produit. La valeur par défaut est 2000 ms. La boucle principale
+ dans <function>sync_Thread_main()</function> est endormie pendant
+ des intervalles de <envar>sync_interval</envar> millisecondes
+ entre chaque itérations.</para>
+
+ <para>Un intervalle de vérifications très court garantit que le noeud
+ origine soit <quote>très suivi</quote>, car il met à jour les abonnés
+ plus fréquemment. Si vous avez des séquences répliquées qui sont
+ souvent mises à jour <emphasis>sans</emphasis> que certaines tables
+ ne soient affectées, cela évite que des opérations qui mettent
+ à jour uniquement ces séquences soient effectuées, et ainsi
+ évite la génération d'événements de synchronisations.</para>
- <para> Les cinq premiers niveau de log ( de Fatal à
- Info) sont <emphasis>toujours</emphasis> affichés dans les logs.
- Dans les premières versions de &slony1;, le niveau de log
- <quote>suggéré</quote> était 2, ce qui affichait tous les messages
- jusqu'au niveau Debug2. Avec &slony1; version 2, il est
- recommandé de positionner <envar>log_level</envar> à 0; la
- pluspart des informations intéressantes sont produites à
- des niveaux supérieurs à celui-là.
- </para>
-
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-s</option><replaceable class="parameter"> Interval entre les vérifications SYNC</replaceable></term>
- <listitem>
+ <para>Si un noeud n'est pas l'origine d'un set de réplication, et donc qu'il
+ ne reçoit aucune mise à jour des données répliquées, alors il est
+ un peu inutile de mettre une valeur inférieure à celle du paramètre
+ <envar>sync_interval_timeout</envar>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-t</option><replaceable class="parameter">intervalle maximal entre deux SYNC</replaceable></term>
+ <listitem>
+ <para>A la fin de chaque période <envar>sync_interval_timeout</envar>
+ , un événement <command>SYNC</command> est produit sur le noeud
+ <quote>local</quote> même si il n'y eu aucune mise à jour des
+ données répliquées et qu'aucun <command>SYNC</command> n'a été
+ généré. </para>
- <para>
- Le paramètre <envar>sync_interval</envar>, exprimé en millisecondes,
- indique à quelle fréquence <application>slon</application> doit
- vérifier si un événement <command>SYNC</command> doit
- être produit. La valeur par défaut est 2000 ms. La boucle principale
- dans <function>sync_Thread_main()</function> est endormie pendant
- des intervalles de <envar>sync_interval</envar> millisecondes
- entre chaque itérations.
- </para>
-
- <para>
- Un intervalle de vérifications très court garantit que le noeud
- origine soit <quote>très suivi</quote>, car il met à jour les abonnés
- plus fréquemment. Si vous avez des séquences répliquées qui sont
- souvent mises à jour <emphasis>sans</emphasis> que certaines tables
- ne soient affectées, cela évite que des opérations qui mettent
- à jour uniquement ces séquences soient effectuées, et ainsi
- évite la génération d'événements de synchronisations.
- </para>
+ <para> Si l'activité de l'application s'arrête, soit parce que
+ l'application a été éteinte, soit parce que les utilisateurs humains
+ sont rentrés chez eux et arrêtés les mises à jour, alors le
+ démon &lslon; continue de tourner et se réveille toutes les
+ <envar>sync_interval</envar> millisecondes, et si aucune mise
+ à jour ne s'est produite, alors aucun événement <command>SYNC</command>
+ n'est généré. Sans ce paramètre <quote>timeout</quote>,
+ <emphasis>aucun</emphasis> événement <command>SYNC</command>
+ ne pourrait être produit, et cela entraînerait le chute du
+ système de réplication. </para>
- <para>
- Si un noeud n'est pas l'origine d'un set de réplication, et donc qu'il
- ne reçoit aucune mise à jour des données répliquées, alors il est
- un peu inutile de mettre une valeur inférieure à celle du paramètre
- <envar>sync_interval_timeout</envar>.
- </para>
+ <para> Le paramètre <envar>sync_interval_timeout</envar> provoque
+ la génération de <command>SYNC</command>, même si il n'y a pas
+ réellement de travail de réplication a faire. Plus la valeur de
+ cette paramètre est basse, plus les évènements <command>SYNC</command>
+ lorsque l'application n'est pas active. Ceci a deux 2 effets :</para>
+ <itemizedlist>
+ <listitem>
+ <para> Le système aura plus de travail.</para>
+ <para> ( Cependant puisque l'application n'utilise pas
+ la base de données et qu'il n'y a pas de données à répliquer,
+ la charge de travail supplémentaire sera assez simple à gérer.)</para>
+ </listitem>
+ <listitem>
+ <para> La réplication sera tenue un peu plus <quote>à jour</quote>.</para>
+ <para> ( Cependant puisqu'il n'y a pas de données à répliquer, être
+ plus souvent <quote>mis à jour</quote> est un mirage.) </para>
+ </listitem>
+ </itemizedlist>
+ <para>La valeur par défaut est 10000 ms et la valeur maximale est 120000 ms.
+ Par défaut, vous pouvez prévoir que chaque noeud soit
+ <quote>synchronisé</quote> par un <command>SYNC</command> toutes les 10 secondes.</para>
+ <para>Notez que des événements <command>SYNC</command> sont aussi générés
+ sur chaque noeud abonné. Cependant puisqu'ils ne contiennent
+ de données à répliquer par les autres noeuds, les évènements
+ <command>SYNC</command> des noeuds abonnés ne sont pas terriblement intéressant.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-g</option><replaceable class="parameter"> taille du groupe</replaceable></term>
+ <listitem>
+ <para>L'option <envar>sync_group_maxsize</envar> contrôle la taille maximumale d'un groupe <command>SYNC</command>,
+ . La valeur par défaut est 6. Ainsi, si un noeud particulier a
+ 200 événements <command>SYNC</command>s de retard, il essaiera de les regrouper
+ par groupes dont la taille maximale sera <envar>sync_group_maxsize</envar>.
+ Ceci doit permettre de réduire le temps de lantence au démarrage (NdT : "overhead")
+ en réduisant le nombre de transactions à <quote>comitter</quote>.</para>
+ <para>La valeur par défaut est 6 est probablement adéquate pour les petits systèmes
+ qui ne peuvent allouer que des quantités limitées de mémoire à
+ <application>slon</application>. Si vous avez beaucoup de mémoire
+ il est raisonnable d'augmenter cette valeur, car cela augmentera
+ la quantité de travail réalisée à chaque transaction, et cela
+ permettra a un noeud abonné de rattraper plus vite son retard.</para>
+ <para>Les processus Slon sont souvent très petits; même en cas
+ de valeur très forte pour cette option, <application>slon</application>
+ devrait simplement grossir de quelques MB.</para>
+ <para>Le gros avantage d'augmenter ce paramètre est que
+ cela divise le nombre de transaction
+ <command>COMMIT</command>s; passer de 1 to 2 aura probablement
+ un impact considérable, mais le bénéfice se réduit progressivement
+ lorsque la taille des groupes est suffisamment large.
+ Il n'y aura probablement pas de différence notable entre 80 et 90.
+ Rendu à ce niveau, l'augmentation de cette
+ valeur dépend du fait que les grands ensembles de <command>SYNC</command>s
+ perturbent les curseurs de <envar>LOG</envar> en consommant
+ de plus en plus de mémoire et nécessitant plus d'efforts lors
+ des tris.</para>
+ <para>Dans &slony1; version 1.0, <application>slon</application> essaie
+ toujours de regrouper un maximum de <command>SYNC</command>s ensemble
+ , ce qui <emphasis>n'est pas</emphasis> idéal si la réplication
+ a été déstabilisée par de grosses mises à jour ( <emphasis>par exemple
+ </emphasis> : une transaction unique qui met à jour des centaines
+ de milliers de lignes) ou lorsque les <command>SYNC</command>s
+ ont été interrompus sur un noeud origine, ce qui fait
+ que les suivants sont volumineux. Vous rencontrerez
+ ce problème : en regroupant des <command>SYNC</command>s très
+ larges, le processus <application>slon</application> peut échouer.
+ Au redémarrage, il essaie a nouveau de traiter ce large ensemble
+ de <command>SYNC</command>s, et il retombe sur le même problème
+ encore et encore jusqu'à ce qu'un administrateur interrompe tout cela
+ et change la valeur de l'option <option>-g</option> pour
+ sortir de cette situation d'<quote>inter-blocage</quote>.</para>
+ <para>Au contraire Avec &slony1; version 1.0, le démon <application>slon</application>
+ 'adapte en augmentant <quote>progressivement</quote> le nombre de
+ <command>SYNC</command> par groupe, de 1 jusqu'à la valeur maximale.
+ Ainsi, si quelques <command>SYNC</command>s pausent problème, le démon
+ <application>slon</application> pourra (avec s'il est surveillé par
+ un processus chien de garde) traiter un par un ces évènements
+ <command>SYNC</command>s problématique, et ainsi éviter l'intervention
+ d'un administrateur.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-o</option><replaceable class="parameter"> temps de synchronisation souhaité</replaceable></term>
+ <listitem>
+ <para> La période <quote>maximale</quote> pour un groupe de <command>SYNC</command>s.</para>
+ <para> Si la réplication est en retard, le démon slon va progressivement augmenter le
+ nombre de <command>SYNC</command>s groupés ensemble, dans le but de
+ ne pas dépasser le temps spécifié par <envar>desired_sync_time</envar>.
+ (pour cela, Slon se base sur le temps pris par le
+ <emphasis>dernier</emphasis> group de <command>SYNC</command>s).</para>
+ <para> La valeur par défaut est 60000ms, c'est à dire une minute. </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-t</option><replaceable class="parameter">intervalle maximal entre deux SYNC
- </replaceable></term>
- <listitem>
+ <para> Ainsi vous pouvez prévoir (en tout cas espérer ! )
+ que vous aurez un <command>COMMIT</command> environ
+ toutes les minutes.</para>
- <para>
- A la fin de chaque période <envar>sync_interval_timeout</envar>
- , un événement <command>SYNC</command> est produit sur le noeud
- <quote>local</quote> même si il n'y eu aucune mise à jour des
- données répliquées et qu'aucun <command>SYNC</command> n'a été
- généré. </para>
+ <para> Cela n'est pas <emphasis>complètement</emphasis> prévisible,
+ car il est possible de demander une <emphasis>très grosse mise à jour
+ </emphasis>,qui fera <quote>exploser</quote> la taille du
+ <command>SYNC</command>. Dans ce cas là, l'heuristique sera
+ rétablie pour le <emphasis>prochain</emphasis> groupe.</para>
- <para> Si l'activité de l'application s'arrête, soit parce que
- l'application a été éteinte, soit parce que les utilisateurs humains
- sont rentrés chez eux et arrêtés les mises à jour, alors le
- démon &lslon; continue de tourner et se réveille toutes les
- <envar>sync_interval</envar> millisecondes, et si aucune mise
- à jour ne s'est produite, alors aucun événement <command>SYNC</command>
- n'est généré. Sans ce paramètre <quote>timeout</quote>,
- <emphasis>aucun</emphasis> événement <command>SYNC</command>
- ne pourrait être produit, et cela entraînerait le chute du
- système de réplication. </para>
+ <para> L'effet final est d'améliorer la façon dont
+ <productname>Slony-I</productname> gère les variations
+ du trafic. En commençant avec 1 événement <command>SYNC</command>, puis
+ en augmentant progressivement, même si certaines variations seront
+ assez grandes pour provoquer un crash du processus <productname>PostgreSQL</productname>,
+ <productname>Slony-I</productname> redémarrera en traitant un seul <command>SYNC</command>
+ à la fois, afin que poursuivre le processus de réplication autant que possible.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-c</option><replaceable class="parameter"> cycles de nettoyage</replaceable></term>
+ <listitem>
+ <para>La valeur <envar>vac_frequency</envar> indique la fréquence des opérations
+ <command>VACUUM</command> lors des cycles de nettoyage.</para>
+ <para>Positionner cette valeur à zéro pour désactiver les nettoyages
+ initiés par <application>slon</application>. Si vous utilisés un
+ mécanisme tel que <application>pg_autovacuum</application> pour
+ lancer les vacuums, vous n'aurez probablement pas besoin que
+ slon initie des vacuums de lui-même. Sinon, il existe des tables
+ utilisées par <productname>Slony-I</productname> qui collectent
+ <emphasis>beaucoup</emphasis> de tuples morts, et qui doivent
+ être nettoyées fréquemment, en particulier &pglistener;.</para>
+ <para> A partir de &slony1; version 1.1, cela change un peu; le processus
+ de nettoyage cherche, d'itération en itération, l'identifiant
+ de la plus ancienne transaction encore active dans le système.
+ Si l'identifiant ne change pas entre deux itérations, alors
+ il existe une vieille transaction en activité, et donc un
+ <command>VACUUM</command> n'apportera rien de bon. A la place,
+ le processus de nettoyage déclenche simplement une opération <command>ANALYZE</command>
+ sur ces tables afin de mettre à jours les statistiques dans <envar>pg_statistics</envar>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-p</option><replaceable class="parameter"> fichier du PID </replaceable></term>
+ <listitem>
+ <para>La variable <envar>pid_file</envar> contient le nom du fichier dans lequel le PID
+ (identifiant du processus) du démon <application>slon</application> est stocké.</para>
+ <para>Cela simplifie la création de scripts de surveillance des processus
+ <application>slon</application> qui s'exécute sur un hôte.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-f</option><replaceable class="parameter"> fichier de configuration</replaceable></term>
+ <listitem>
+ <para>Fichier qui contient la configuration <application>slon</application>.</para>
+
+ <para> La configuration configuration est détaillée plus loin dans le chapitre <link
+ linkend="runtime-config">Configuration de Slon</link>. Si
+ vous avez défini un ensemble complexe de paramètre, ou si vous ne voulez
+ pas que les paramètres soient visibles dans les variable d'environnement
+ ( notamment les mots de passe ), il est plus pratique de placer une partie,
+ voire l'ensemble des paramètres dans un fichier de configuration.
+ Vous pouvez pouvez également placer les paramètres communs à tous les
+ processus slon dans un fichier de configuration partagé et définir
+ en ligne de commande d'autres paramètres que les informations de connexions.
+ Vous pouvez aussi créer un fichier de configuration pour chaque noeud.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-a</option><replaceable class="parameter"> répertoire des archives</replaceable></term>
+ <listitem>
+ <para>L'option <envar>archive_dir</envar> indique le dossier dans lequel on
+ place la séquence de fichiers archives contenant les événements <command>SYNC</command>
+ utilisés en mode &logshiplink;.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-x</option><replaceable class="parameter"> commande à appliquer pour l'archivage des journaux</replaceable></term>
+ <listitem>
+ <para>Le paramètre <envar>command_on_logarchive</envar> indique la commande qui doit
+ être exécutée à chaque fois qu'un fichier SYNC est correctement généré.</para>
+ <para> Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/> pour plus de détails.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-q</option><replaceable class="parameter"> quitter en fonction d'un fournisseur </replaceable></term>
+ <listitem>
+ <para>L'option <envar>quit_sync_provider</envar> indique quel processus fournisseur
+ doit être surveiller afin d'arrêter la réplication après un événement donné.
+ Ceci doit être utilisé conjointement avec l'option
+ <option>-r</option> ci-dessous...</para>
- <para> Le paramètre <envar>sync_interval_timeout</envar> provoque
- la génération de <command>SYNC</command>, même si il n'y a pas
- réellement de travail de réplication a faire. Plus la valeur de
- cette paramètre est basse, plus les évènements <command>SYNC</command>
- lorsque l'application n'est pas active. Ceci a deux 2 effets
- :</para>
- <itemizedlist>
+ <para> Cela permet de stopper la réplication sur un processus <application>slon</application>
+ après un certain point. </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-r</option><replaceable class="parameter"> quitte après un numéro d'événement </replaceable></term>
+ <listitem>
+ <para>Le paramètre <envar>quit_sync_finalsync</envar> indique le numéro de l'événement
+ après lequel un processus de réplication doit se terminer.
+ Ceci doit être utilisé conjointement avec l'option
+ <option>-q</option> ci-dessus...</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-l</option><replaceable class="parameter"> interval de retard </replaceable></term>
+ <listitem>
+ <para>L'option <envar>lag_interval</envar> spécifie une valeur temporelle
+ ( en anglais ) telle que <command> 3 minutes </command>, <command> 4 hours </command>
+ ou <command> 2 days </command> qui indique que le temps de retard qu'un noeud doit avoir
+ par rapport à son fournisseur. Cela implique que les événements seront
+ ignorés tant que leur age sera inférieur à cet intervalle.</para>
- <listitem><para> Le système aura plus de travail.</para>
+ <warning><para> Il y a un effet secondaire à ce retard;
+ Les événements qui demande que tous les noeuds se synchronisent,
+ notamment ceux qui sont produits lors d'une opération <xref linkend="stmtfailover"/>
+ et d'un <xref linkend="stmtmoveset"/>, devront attendre pendant cet interval
+ de temps.</para>
- <para> ( Cependant puisque l'application n'utilise pas
- la base de données et qu'il n'y a pas de données à répliquer,
- la charge de travail supplémentaire sera assez simple à gérer.)
- </para></listitem>
-
- <listitem><para> La réplication sera tenue un peu plus <quote>à jour</quote>.</para>
-
- <para> ( Cependant puisqu'il n'y a pas de données à répliquer, être
- plus souvent <quote>mis à jour</quote> est un mirage.) </para></listitem>
-
- </itemizedlist>
-
- <para>
- La valeur par défaut est 10000 ms et la valeur maximale est 120000 ms.
- Par défaut, vous pouvez prévoir que chaque noeud soit
- <quote>synchronisé</quote> par un <command>SYNC</command> toutes les 10 secondes.
- </para>
- <para>
- Notez que des événements <command>SYNC</command> sont aussi générés
- sur chaque noeud abonné. Cependant puisqu'ils ne contiennent
- de données à répliquer par les autres noeuds, les évènements
- <command>SYNC</command> des noeuds abonnés ne sont pas terriblement intéressant.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-g</option><replaceable class="parameter"> taille du groupe</replaceable></term>
- <listitem>
- <para>
- L'option <envar>sync_group_maxsize</envar> contrôle la taille maximumale d'un groupe <command>SYNC</command>,
- . La valeur par défaut est 6. Ainsi, si un noeud particulier a
- 200 événements <command>SYNC</command>s de retard, il essaiera de les regrouper
- par groupes dont la taille maximale sera <envar>sync_group_maxsize</envar>.
- Ceci doit permettre de réduire le temps de lantence au démarrage (NdT : "overhead")
- en réduisant le nombre de transactions à <quote>comitter</quote>.
- </para>
- <para>
- La valeur par défaut est 6 est probablement adéquate pour les petits systèmes
- qui ne peuvent allouer que des quantités limitées de mémoire à
- <application>slon</application>. Si vous avez beaucoup de mémoire
- il est raisonnable d'augmenter cette valeur, car cela augmentera
- la quantité de travail réalisée à chaque transaction, et cela
- permettra a un noeud abonné de rattraper plus vite son retard.
- </para>
- <para>
- Les processus Slon sont souvent très petits; même en cas
- de valeur très forte pour cette option, <application>slon</application>
- devrait simplement grossir de quelques MB.
- </para>
- <para>
- Le gros avantage d'augmenter ce paramètre est que
- cela divise le nombre de transaction
- <command>COMMIT</command>s; passer de 1 to 2 aura probablement
- un impact considérable, mais le bénéfice se réduit progressivement
- lorsque la taille des groupes est suffisamment large.
- Il n'y aura probablement pas de différence notable entre 80 et 90.
- Rendu à ce niveau, l'augmentation de cette
- valeur dépend du fait que les grands ensembles de <command>SYNC</command>s
- perturbent les curseurs de <envar>LOG</envar> en consommant
- de plus en plus de mémoire et nécessitant plus d'efforts lors
- des tris.
- </para>
- <para>
- Dans &slony1; version 1.0, <application>slon</application> essaie
- toujours de regrouper un maximum de <command>SYNC</command>s ensemble
- , ce qui <emphasis>n'est pas</emphasis> idéal si la réplication
- a été déstabilisée par de grosses mises à jour ( <emphasis>par exemple
- </emphasis> : une transaction unique qui met à jour des centaines
- de milliers de lignes) ou lorsque les <command>SYNC</command>s
- ont été interrompus sur un noeud origine, ce qui fait
- que les suivants sont volumineux. Vous rencontrerez
- ce problème : en regroupant des <command>SYNC</command>s très
- larges, le processus <application>slon</application> peut échouer.
- Au redémarrage, il essaie a nouveau de traiter ce large ensemble
- de <command>SYNC</command>s, et il retombe sur le même problème
- encore et encore jusqu'à ce qu'un administrateur interrompe tout cela
- et change la valeur de l'option <option>-g</option> pour
- sortir de cette situation d'<quote>inter-blocage</quote>.
- </para>
- <para>
- Au contraire Avec &slony1; version 1.0, le démon <application>slon</application>
- 'adapte en augmentant <quote>progressivement</quote> le nombre de
- <command>SYNC</command> par groupe, de 1 jusqu'à la valeur maximale.
- Ainsi, si quelques <command>SYNC</command>s pausent problème, le démon
- <application>slon</application> pourra (avec s'il est surveillé par
- un processus chien de garde) traiter un par un ces évènements
- <command>SYNC</command>s problématique, et ainsi éviter l'intervention
- d'un administrateur.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-o</option><replaceable class="parameter"> temps de synchronisation souhaité</replaceable></term>
- <listitem><para> La période <quote>maximale</quote> pour un groupe de <command>SYNC</command>s.</para>
-
- <para> Si la réplication est en retard, le démon slon va progressivement augmenter le
- nombre de <command>SYNC</command>s groupés ensemble, dans le but de
- ne pas dépasser le temps spécifié par <envar>desired_sync_time</envar>.
- (pour cela, Slon se base sur le temps pris par le
- <emphasis>dernier</emphasis> group de <command>SYNC</command>s)
- .</para>
-
- <para> La valeur par défaut est 60000ms,
- c'est à dire une minute. </para>
-
- <para> Ainsi vous pouvez prévoir (en tout cas espérer ! )
- que vous aurez un <command>COMMIT</command> environ
- toutes les minutes.</para>
-
- <para> Cela n'est pas <emphasis>complètement</emphasis> prévisible,
- car il est possible de demander une <emphasis>très grosse mise à jour
- </emphasis>,qui fera <quote>exploser</quote> la taille du
- <command>SYNC</command>. Dans ce cas là, l'heuristique sera
- rétablie pour le <emphasis>prochain</emphasis> groupe.</para>
-
- <para> L'effet final est d'améliorer la façon dont
- <productname>Slony-I</productname> gère les variations
- du trafic. En commençant avec 1 événement <command>SYNC</command>, puis
- en augmentant progressivement, même si certaines variations seront
- assez grandes pour provoquer un crash du processus <productname>PostgreSQL</productname>,
- <productname>Slony-I</productname> redémarrera en traitant un seul <command>SYNC</command>
- à la fois, afin que poursuivre le processus de réplication autant que possible.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-c</option><replaceable class="parameter"> cycles de nettoyage</replaceable></term>
- <listitem>
- <para>
- La valeur <envar>vac_frequency</envar> indique la fréquence des opérations
- <command>VACUUM</command> lors des cycles de nettoyage.
- </para>
- <para>
- Positionner cette valeur à zéro pour désactiver les nettoyages
- initiés par <application>slon</application>. Si vous utilisés un
- mécanisme tel que <application>pg_autovacuum</application> pour
- lancer les vacuums, vous n'aurez probablement pas besoin que
- slon initie des vacuums de lui-même. Sinon, il existe des tables
- utilisées par <productname>Slony-I</productname> qui collectent
- <emphasis>beaucoup</emphasis> de tuples morts, et qui doivent
- être nettoyées fréquemment, en particulier &pglistener;.
- </para>
-
- <para> A partir de &slony1; version 1.1, cela change un peu; le processus
- de nettoyage cherche, d'itération en itération, l'identifiant
- de la plus ancienne transaction encore active dans le système.
- Si l'identifiant ne change pas entre deux itérations, alors
- il existe une vieille transaction en activité, et donc un
- <command>VACUUM</command> n'apportera rien de bon. A la place,
- le processus de nettoyage déclenche simplement une opération <command>ANALYZE</command>
- sur ces tables afin de mettre à jours les statistiques dans <envar>pg_statistics</envar>.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-p</option><replaceable class="parameter"> fichier du PID </replaceable></term>
- <listitem>
- <para>
- La variable <envar>pid_file</envar> contient le nom du fichier dans lequel le PID
- (identifiant du processus) du démon <application>slon</application> est stocké.
- </para>
-
- <para>
- Cela simplifie la création de scripts de surveillance des processus
- <application>slon</application> qui s'exécute sur un hôte.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-f</option><replaceable class="parameter"> fichier de configuration</replaceable></term>
- <listitem>
- <para>
- Fichier qui contient la configuration <application>slon</application>.
- </para>
-
- <para> La configuration configuration est détaillée plus loin dans le chapitre <link
- linkend="runtime-config">Configuration de Slon</link>. Si
- vous avez défini un ensemble complexe de paramètre, ou si vous ne voulez
- pas que les paramètres soient visibles dans les variable d'environnement
- ( notamment les mots de passe ), il est plus pratique de placer une partie,
- voire l'ensemble des paramètres dans un fichier de configuration.
- Vous pouvez pouvez également placer les paramètres communs à tous les
- processus slon dans un fichier de configuration partagé et définir
- en ligne de commande d'autres paramètres que les informations de connexions.
- Vous pouvez aussi créer un fichier de configuration pour chaque noeud.
- </para>
-
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><option>-a</option><replaceable class="parameter"> répertoire des archives</replaceable></term>
- <listitem>
- <para>
- L'option <envar>archive_dir</envar> indique le dossier dans lequel on
- place la séquence de fichiers archives contenant les événements <command>SYNC</command>
- utilisés en mode &logshiplink;.
- </para>
- </listitem>
- </varlistentry>
-
-
- <varlistentry>
- <term><option>-x</option><replaceable class="parameter"> commande à appliquer pour l'archivage des journaux</replaceable></term>
- <listitem>
- <para>
- Le paramètre <envar>command_on_logarchive</envar> indique la commande qui doit
- être exécutée à chaque fois qu'un fichier SYNC est correctement généré.
- </para>
-
- <para> Voir le chapitre <xref linkend="slon-config-command-on-logarchive"/> pour plus de détails.</para>
- </listitem>
- </varlistentry>
-
-
- <varlistentry>
- <term><option>-q</option><replaceable class="parameter"> quitter en fonction d'un fournisseur </replaceable></term>
- <listitem>
- <para>
- L'option <envar>quit_sync_provider</envar> indique quel processus fournisseur
- doit être surveiller afin d'arrêter la réplication après un événement donné.
- Ceci doit être utilisé conjointement avec l'option
- <option>-r</option> ci-dessous...
- </para>
-
- <para> Cela permet de stopper la réplication sur un processus <application>slon</application>
- après un certain point. </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-r</option><replaceable class="parameter"> quitte après un numéro d'événement </replaceable></term>
- <listitem>
- <para>
- Le paramètre <envar>quit_sync_finalsync</envar> indique le numéro de l'événement
- après lequel un processus de réplication doit se terminer.
- Ceci doit être utilisé conjointement avec l'option
- <option>-q</option> ci-dessus...
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>-l</option><replaceable class="parameter"> interval de retard </replaceable></term>
- <listitem>
- <para>
- L'option <envar>lag_interval</envar> spécifie une valeur temporelle
- ( en anglais ) telle que <command> 3 minutes </command>, <command> 4 hours </command>
- ou <command> 2 days </command> qui indique que le temps de retard qu'un noeud doit avoir
- par rapport à son fournisseur. Cela implique que les événements seront
- ignorés tant que leur age sera inférieur à cet intervalle.
- </para>
-
- <warning><para> Il y a un effet secondaire à ce retard;
- Les événements qui demande que tous les noeuds se synchronisent,
- notamment ceux qui sont produits lors d'une opération <xref linkend="stmtfailover"/>
- et d'un <xref linkend="stmtmoveset"/>, devront attendre pendant cet interval
- de temps.</para>
-
- <para> C'est un comportement qui n'est pas idéal dans le cas d'une bascule
- après une panne, ou lorsque l'on veut exécuter des scripts DDL ( <xref
- linkend="stmtddlscript"/> ). </para></warning>
- </listitem>
- </varlistentry>
-
- </variablelist>
- </refsect1>
- <refsect1>
- <title>Valeur de retour ( "Exit Status" ) </title>
- <para>
- <application>slon</application> renvoie 0 dans le shell si il s'est terminé
- normalement. En cas d'erreur fatale, il exécute la fonction <function>exit(-1)</function>
- ( qui envoie en général un valeur de retour de 127 ou 255, suivant votre système d'exploitation )
- .
- </para>
- </refsect1>
+ <para> C'est un comportement qui n'est pas idéal dans le cas d'une bascule
+ après une panne, ou lorsque l'on veut exécuter des scripts DDL ( <xref
+ linkend="stmtddlscript"/> ). </para>
+ </warning>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+ <refsect1>
+ <title>Valeur de retour ( "Exit Status" ) </title>
+ <para><application>slon</application> renvoie 0 dans le shell si il s'est terminé
+ normalement. En cas d'erreur fatale, il exécute la fonction <function>exit(-1)</function>
+ ( qui envoie en général un valeur de retour de 127 ou 255, suivant votre système d'exploitation ).</para>
+ </refsect1>
</refentry>
Modified: traduc/trunk/slony/slonconf.xml
===================================================================
--- traduc/trunk/slony/slonconf.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/slonconf.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -50,120 +50,122 @@
<title>Traces</title>
<variablelist>
<varlistentry id="slon-config-logging-syslog" xreflabel="slon_conf_syslog">
- <term><varname>syslog</varname> (<type>entier</type>)</term>
- <indexterm>
- <primary>paramètre de configuration de<varname>syslog</varname></primary>
- </indexterm>
+ <term>
+ <varname>syslog</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>paramètre de configuration de<varname>syslog</varname></primary>
+ </indexterm>
+ </term>
<listitem>
<para>Active les traces avec syslog. Si les paramètre est 1, les messages vont
- à la fois vers systlog et la sortie standard. La valeur 2 envoie les traces
- uniquement à syslog. ( toutefois certains messages seront toujours envoyés
- sur la sortie standard ou sur la sortie d'erreur). Par défaut, ce paramètre
- est à 0, ce qui signifie que syslog est désactivé.
- </para>
+ à la fois vers systlog et la sortie standard. La valeur 2 envoie les traces
+ uniquement à syslog. ( toutefois certains messages seront toujours envoyés
+ sur la sortie standard ou sur la sortie d'erreur). Par défaut, ce paramètre
+ est à 0, ce qui signifie que syslog est désactivé.</para>
</listitem>
</varlistentry>
-
<varlistentry id="slon-config-logging-syslog-facility" xreflabel="slon_conf_syslog_facility">
- <term><varname>syslog_facility</varname> (<type>chaîne</type>)</term>
- <indexterm>
- <primary>paramètre de configuration de <varname>syslog_facility</varname></primary>
- </indexterm>
+ <term>
+ <varname>syslog_facility</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration de <varname>syslog_facility</varname></primary>
+ </indexterm>
+ </term>
<listitem>
<para>Positionne la <quote>facility</quote> que syslog devra utiliser
- Les valeurs valides sont LOCAL0, LOCAL1, LOCAL2,
+ Les valeurs valides sont LOCAL0, LOCAL1, LOCAL2,
LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. La valeur par défaut est
- LOCAL0.
- </para>
+ LOCAL0.</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-logging-syslog-ident" xreflabel="slon_conf_syslog_ident">
- <term><varname>syslog_ident</varname> (<type>chaîne</type>)</term>
- <indexterm>
- <primary>Paramètre de configuration de <varname>syslog_ident</varname></primary>
- </indexterm>
+ <term>
+ <varname>syslog_ident</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>Paramètre de configuration de <varname>syslog_ident</varname></primary>
+ </indexterm>
+ </term>
<listitem>
- <para>
- Définit le nom du programme utilisé pour identifié les messages slon
- dans syslog. La valeur par défaut est slon.
- </para>
+ <para>Définit le nom du programme utilisé pour identifié les messages slon
+ dans syslog. La valeur par défaut est slon.</para>
</listitem>
</varlistentry>
-
+
<varlistentry id="slon-config-logging-log-level" xreflabel="lon_conf_log_level">
- <term><varname>log_level</varname> (<type>entier</type>)</term>
- <indexterm>
- <primary>Paramètre de configuration du <varname>log_level</varname></primary>
- </indexterm>
+ <term>
+ <varname>log_level</varname> (<type>entier</type>)
+ <indexterm>
+ <primary>Paramètre de configuration du <varname>log_level</varname></primary>
+ </indexterm>
+ </term>
<listitem>
<para>Niveau de traces de debug (plus la valeur est haute, plus les messages sont verbeux).
- Valeurs possibles : de 0 à 4, valeur par défaut : 0
- </para>
+ Valeurs possibles : de 0 à 4, valeur par défaut : 0</para>
- <para> Il y a <link linkend="nineloglevels">neuf niveaux de messages
- de trace</link>; en utilisant cette option, une partie ou l'ensemble
- des niveaux <quote>debug</quote> peuvent être désactivés.
- Avec &slony1; version 2, beaucoup de niveaux de message ont
- été révisé afin que des <quote>trucs intéressants</quote>
- apparaissent à partir des niveaux CONFIG/INFO, et qu'il soit possible
- de fonctionner au niveau 0, en ignorant tous les messages
- <quote>DEBUG</quote> et continuer à recevoir des informations
- utiles dans les fichiers de trace.</para>
-
+ <para> Il y a <link linkend="nineloglevels">neuf niveaux de messages
+ de trace</link>; en utilisant cette option, une partie ou l'ensemble
+ des niveaux <quote>debug</quote> peuvent être désactivés.
+ Avec &slony1; version 2, beaucoup de niveaux de message ont
+ été révisé afin que des <quote>trucs intéressants</quote>
+ apparaissent à partir des niveaux CONFIG/INFO, et qu'il soit possible
+ de fonctionner au niveau 0, en ignorant tous les messages
+ <quote>DEBUG</quote> et continuer à recevoir des informations
+ utiles dans les fichiers de trace.</para>
</listitem>
</varlistentry>
-
+
<varlistentry id="slon-config-logging-log-pid" xreflabel="slon_conf_log_pid">
- <term><varname>log_pid</varname> (<type>booléen</type>)</term>
- <indexterm>
- <primary>paramètre de configuration du <varname>log_pid</varname></primary>
- </indexterm>
+ <term>
+ <varname>log_pid</varname> (<type>booléen</type>)
+ <indexterm>
+ <primary>paramètre de configuration du <varname>log_pid</varname></primary>
+ </indexterm>
+ </term>
<listitem>
<para>Détermine si vous souhaitez que le PID du processus père slon
- doit apparaître dans chaque ligne du fichier de trace.
- </para>
+ doit apparaître dans chaque ligne du fichier de trace. </para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-logging-log-timestamp" xreflabel="slon_conf_log_timestamp">
- <term><varname>log_timestamp</varname> (<type>booléen</type>)</term>
- <indexterm>
- <primary>paramètre de configuration de <varname>log_timestamp</varname></primary>
- </indexterm>
+ <term>
+ <varname>log_timestamp</varname> (<type>booléen</type>)
+ <indexterm>
+ <primary>paramètre de configuration de <varname>log_timestamp</varname></primary>
+ </indexterm>
+ </term>
<listitem>
<para>Détermine si vous souhaitez que le timestamp de chaque événement doit
- apparaître dans chaque ligne du fichier de trace.
- </para>
+ apparaître dans chaque ligne du fichier de trace.</para>
</listitem>
</varlistentry>
-
-
-
<varlistentry id="slon-config-logging-log-timestamp-format" xreflabel="slon_conf_log_timestamp_format">
- <term><varname>log_timestamp_format</varname> (<type>chaîne</type>)</term>
- <indexterm>
- <primary>paramètre de configuration du <varname>log_timestamp_format</varname></primary>
- </indexterm>
+ <term>
+ <varname>log_timestamp_format</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration du <varname>log_timestamp_format</varname></primary>
+ </indexterm>
+ </term>
<listitem>
<para>Une chaîne au format conforme avec <function>strftime()</function>
- qui sera utilisé si <envar>log_timestamp</envar> est activé.
- La valeur par défaut est <quote>%Y-%m-%d %H:%M:%S %Z</quote>
- </para>
+ qui sera utilisé si <envar>log_timestamp</envar> est activé.
+ La valeur par défaut est <quote>%Y-%m-%d %H:%M:%S %Z</quote></para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-logging-pid-file" xreflabel="slon_conf_log_pid_file">
- <term><varname>pid_file</varname> (<type>chaîne</type>)</term>
- <indexterm>
- <primary>paramètre de configuration du <varname>pid_file</varname></primary>
- </indexterm>
+ <term>
+ <varname>pid_file</varname> (<type>chaîne</type>)
+ <indexterm>
+ <primary>paramètre de configuration du <varname>pid_file</varname></primary>
+ </indexterm>
+ </term>
<listitem>
<para>L'emplacement et le nom du fichier où vous souhaitez
- stocker le PID du processus slon. La valeur par défaut n'est
- pas défini, ce qui implique qu'aucun fichier n'est écrit.
- </para>
+ stocker le PID du processus slon. La valeur par défaut n'est
+ pas défini, ce qui implique qu'aucun fichier n'est écrit.</para>
</listitem>
</varlistentry>
</variablelist>
@@ -173,10 +175,12 @@
<title>Paramètres de connexion</title>
<variablelist>
<varlistentry id="slon-config-connection-cluster-name" xreflabel="slon_conf_cluster_name">
- <term><varname>cluster_name</varname> (<type>chaîne</type>) </term>
+ <term>
+ <varname>cluster_name</varname> (<type>chaîne</type>)
<indexterm>
<primary>paramètre de configuration <varname>cluster_name</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Définit le nom du cluster que l'instance de
@@ -187,10 +191,11 @@
</varlistentry>
<varlistentry id="slon-config-connection-conn-info" xreflabel="slon_conf_conn_info">
- <term><varname>conn_info</varname> (<type>chaîne</type>)</term>
+ <term><varname>conn_info</varname> (<type>chaîne</type>)
<indexterm>
<primary>paramètre de configuration <varname>conn_info</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Définit les informations de connexion pour <application>slon</application>;
@@ -200,10 +205,11 @@
</varlistentry>
<varlistentry id="slon-config-sql-on-connection" xreflabel="slon_conf_sql_on_connection">
- <term><varname>sql_on_connection</varname> (<type>chaîne</type>)</term>
+ <term><varname>sql_on_connection</varname> (<type>chaîne</type>)
<indexterm>
<primary>paramètre de configuration de <varname>sql_on_connection</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Exécute cette requête SQL sur chaque noeud lorsque
@@ -222,10 +228,11 @@
<title> Options d'archivage </title>
<variablelist>
<varlistentry id="slon-config-archive-dir" xreflabel="slon_conf_archive_dir">
- <term><varname>archive_dir</varname> (<type>text</type>)</term>
+ <term><varname>archive_dir</varname> (<type>text</type>)
<indexterm>
<primary>paramètre de configuration <varname>archive_dir</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Ceci indique dans quel répertoire les fichiers d'archivages des syncs doivent
être stockés.
@@ -234,10 +241,11 @@
</varlistentry>
<varlistentry id="slon-config-command-on-logarchive" xreflabel="slon_conf_command_on_log_archive">
- <term><varname>command_on_logarchive</varname> (<type>texte</type>)</term>
+ <term><varname>command_on_logarchive</varname> (<type>texte</type>)
<indexterm>
<primary>paramètre de configuration de <varname>command_on_logarchive</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Ceci définit une commande Unix qui sera lancé à
chaque fois qu'un fichier d'archive est produit.
@@ -279,10 +287,11 @@
<title>Configuration des évènements</title>
<variablelist>
<varlistentry id="slon-config-sync-interval" xreflabel="slon_conf_sync_interval">
- <term><varname>sync_interval</varname> (<type>entier</type>)</term>
+ <term><varname>sync_interval</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration <varname>sync_interval</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Fréquence maximale (en millisecondes) de vérification des mises à jour.
Valeurs possibles : de 10 à 60000, La valeur par défaut est 100.
@@ -291,10 +300,11 @@
</varlistentry>
<varlistentry id="slon-config-sync-interval-timeout" xreflabel="slon_conf_sync_interval_timeout">
- <term><varname>sync_interval_timeout</varname> (<type>entier</type>)</term>
+ <term><varname>sync_interval_timeout</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>sync_interval_timeout</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Délai maximal, en millisecondes,avant qu'un événements
@@ -320,10 +330,11 @@
</varlistentry>
<varlistentry id="slon-config-sync-group-maxsize" xreflabel="slon_conf_sync_group_maxsize">
- <term><varname>sync_group_maxsize</varname> (<type>entier</type>)</term>
+ <term><varname>sync_group_maxsize</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>sync_group_maxsize</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Nombre maximum d'événements <command>SYNC</command> qui seront regroupés
@@ -340,10 +351,11 @@
</varlistentry>
<varlistentry id="slon-config-vac-frequency" xreflabel="slon_conf_vac_frequency">
- <term><varname>vac_frequency</varname> (<type>entier</type>)</term>
+ <term><varname>vac_frequency</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>vac_frequency</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Définit le nombre de cycles de nettoyage sont lancé avant qu'un
@@ -355,10 +367,11 @@
</varlistentry>
<varlistentry id="slon-config-cleanup-interval" xreflabel="slon_config_cleanup_interval">
- <term><varname>cleanup_interval</varname> (<type>interval</type>)</term>
+ <term><varname>cleanup_interval</varname> (<type>interval</type>)
<indexterm>
<primary>paramètre de configuration<varname>cleanup_interval</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Contrôle à quelle fréquence les vieux événements doivent être effacés.
@@ -370,10 +383,11 @@
</varlistentry>
<varlistentry id="slon-config-cleanup-deletelogs" xreflabel="slon_conf_cleanup_deletelogs">
- <term><varname>cleanup_deletelogs</varname> (<type>booléen</type>)</term>
+ <term><varname>cleanup_deletelogs</varname> (<type>booléen</type>)
<indexterm>
<primary>paramètre de configuration<varname>cleanup_deletelogs</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
Contrôle si la commande DELETE est utilisée (ou pas) pour effacer les anciennes données
@@ -384,10 +398,11 @@
</varlistentry>
<varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
- <term><varname>desired_sync_time</varname> (<type>entier</type>)</term>
+ <term><varname>desired_sync_time</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>desired_sync_time</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Temps maximum prévu pour un groupe d'événements
<command>SYNC</command>s. Si la réplication est en retard,
@@ -400,10 +415,11 @@
</varlistentry>
<varlistentry id="slon-config-quit-sync-provider" xreflabel="quit_sync_provider">
- <term><varname>quit_sync_provider</varname> (<type>entier</type>)</term>
+ <term><varname>quit_sync_provider</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>quit_sync_provider</varname></primary>
</indexterm>
+ </term>
<listitem>
<para> Ce paramètre doit être utilisé conjointement avec <xref
linkend="slon-config-quit-sync-finalsync"/>, et indique
@@ -415,10 +431,11 @@
</listitem>
</varlistentry>
<varlistentry id="slon-config-quit-sync-finalsync" xreflabel="quit_sync_finalsync">
- <term><varname>quit_sync_finalsync</varname> (<type>entier</type>)</term>
+ <term><varname>quit_sync_finalsync</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>quit_sync_finalsync</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Numéro de l'événement final à traiter. Ceci
doit être utilisé en conjonction avec <xref linkend="slon-config-quit-sync-finalsync"/>,
@@ -430,10 +447,11 @@
</varlistentry>
<varlistentry id="slon-config-lag-interval" xreflabel="lag_interval">
- <term><varname>lag_interval</varname> (<type>chaîne/interval</type>)</term>
+ <term><varname>lag_interval</varname> (<type>chaîne/interval</type>)
<indexterm>
<primary>paramètre de configuration<varname>lag_interval</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Indiques un intervalle à partir duquel le noeud
est en décalage avec son fournisseur. Si cette valeur est définie,
@@ -448,10 +466,11 @@
</varlistentry>
<varlistentry id="slon-config-max-rowsize" xreflabel="sync_max_rowsize">
- <term><varname>sync_max_rowsize</varname> (<type>entier</type>)</term>
+ <term><varname>sync_max_rowsize</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>sync_max_rowsize</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Taille à partir de laquelle le champ <envar>log_cmddata</envar> d'une ligne d'une
table sl_log_? est considéré comme volumineux.
@@ -469,10 +488,11 @@
</varlistentry>
<varlistentry id="slon-config-max-largemem" xreflabel="sync_max_largemem">
- <term><varname>sync_max_largemem</varname> (<type>entier</type>)</term>
+ <term><varname>sync_max_largemem</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>sync_max_largemem</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Taille maximum de ma mémoire allouée pour les lignes volumineuses
quand <envar>log_cmddata</envar> est plus grand que
@@ -488,10 +508,11 @@
</listitem>
</varlistentry>
<varlistentry id="slon-config-remote-listen-timeout" xreflabel="slon_conf_remote_listen_timeout">
- <term><varname>remote_listen_timeout</varname> (<type>entier</type>)</term>
+ <term><varname>remote_listen_timeout</varname> (<type>entier</type>)
<indexterm>
<primary>paramètre de configuration<varname>remote_listen_timeout</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>Combien de temps le processus d'écoute distant doit attendre avant
de considérer qu'un événement est périmé.
Modified: traduc/trunk/slony/slonik.xml
===================================================================
--- traduc/trunk/slony/slonik.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/slonik.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -5,7 +5,7 @@
révision $Revision$ -->
<refentry id="slonik">
-<refmeta>
+ <refmeta>
<refentrytitle id="app-slonik-title"><application>slonik</application></refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo>Application</refmiscinfo>
@@ -18,39 +18,37 @@
</refpurpose>
</refnamediv>
- <indexterm zone="slonik">
- <primary>slonik</primary>
- </indexterm>
+ <indexterm zone="slonik">
+ <primary>slonik</primary>
+ </indexterm>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>slonik</command>
- <arg><replaceable class="parameter">filename</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
-
- <refsect1>
- <title>Description</title>
-
- <para>
- <application>slonik</application> est processeur de commandes qui est
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>slonik</command>
+ <arg><replaceable class="parameter">filename</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+
+ <refsect1>
+ <title>Description</title>
+ <para><application>slonik</application> est processeur de commandes qui est
utilisé pour mettre en place et modifier les configurations de clusters
de réplication &slony1;
</para>
- </refsect1>
-
- <refsect1><title>Précisions</title>
-
- <para>L'outil en ligne de commande <application>slonik</application>
+ </refsect1>
+
+ <refsect1>
+ <title>Précisions</title>
+ <para>L'outil en ligne de commande <application>slonik</application>
doit être utilisé dans des scripts shell; il lit des commandes placées
dans des fichiers ou à partir de stdin.</para>
- <para>Il lit un ensemble de commandes Slonik, qui sont écrites dans
+ <para>Il lit un ensemble de commandes Slonik, qui sont écrites dans
un langage de script dont la syntaxe est similaire à celle du SQL,
et réalise l'ensemble des modifications sur les noeuds slony spécifiées
dans le script.</para>
- <para>Presque tout le travail de configuration est réalisé en appelant
+ <para>Presque tout le travail de configuration est réalisé en appelant
des procédures stockées après que la base <productname>Slony-I</productname>
a été chargée dans un noeud. <application>Slonik</application> a
été créé car ces procédures stockées ont des comportements spécifiques
@@ -58,10 +56,9 @@
pour les procédures stockées rend tout cela difficile à réaliser depuis
la console <application>psql</application>, et <application>psql</application>
n'a pas la capacité de maintenir de multiples connexions avec des transactions
- ouvertes vers de multiples bases de données.
- </para>
+ ouvertes vers de multiples bases de données.</para>
- <para>Le format du <quote>langage</quote> Slonik est très similaire au SQL
+ <para>Le format du <quote>langage</quote> Slonik est très similaire au SQL
et l'analyseur syntaxique est basé sur un ensemble équivalent de règles de
syntaxes pour les nombres ou les chaînes de caractères. Notez que
slonik est un langage déclaratif qui utilise les valeurs littérales.
@@ -70,18 +67,13 @@
ont de très bonnes méthodes pour gérer les variables, les itérations,
et ainsi de suite...</para>
- <para>Pour plus d'information, se reporter au chapitre <link linkend="slonikref"> Manuel de référence
- du langage Slonik</link>. </para>
+ <para>Pour plus d'information, se reporter au chapitre <link linkend="slonikref"> Manuel de référence du langage Slonik</link>. </para>
+ </refsect1>
- </refsect1>
-
- <refsect1>
- <title>Code de sortie</title>
-
- <para>
- <application>slonik</application> retourne 0 au shell si tout c'est terminé normalement.
- Chaque script peut retourner des codes spécifiques....
- </para>
- </refsect1>
+ <refsect1>
+ <title>Code de sortie</title>
+ <para><application>slonik</application> retourne 0 au shell si tout c'est terminé normalement.
+ Chaque script peut retourner des codes spécifiques...</para>
+ </refsect1>
</refentry>
Modified: traduc/trunk/slony/slonik_ref.xml
===================================================================
--- traduc/trunk/slony/slonik_ref.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/slonik_ref.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -6,364 +6,308 @@
<article id="slonikref">
<title>Tour d'horizon des commandes Slonik</title>
- <sect1><title>Introduction</title>
-
- <para>
- <application>Slonik</application> est un utilitaire en ligne de commande
- conçu spécifiquement pour mettre en place et modifier la configuration
- d'un système de réplication &slony1;.
- </para>
-
- <sect2 id="outline">
- <title>Considérations générales</title>
-
- <para>
- L'utilitaire en ligne de commande <application>slonik</application>
- est supposé être intégré dans des scripts shell et lit
- les commandes à partir d'un fichier ou de stdin ( voir plus
- bas pour des exemples ). Presque tout le travail de configuration
+ <sect1><title>Introduction</title>
+ <para><application>Slonik</application> est un utilitaire en ligne de commande
+ conçu spécifiquement pour mettre en place et modifier la configuration
+ d'un système de réplication &slony1;.</para>
+ <sect2 id="outline">
+ <title>Considérations générales</title>
+ <para>
+ L'utilitaire en ligne de commande <application>slonik</application>
+ est supposé être intégré dans des scripts shell et lit
+ les commandes à partir d'un fichier ou de stdin ( voir plus
+ bas pour des exemples ). Presque tout le travail de configuration
<emphasis>réel</emphasis> est effectué en appelant des procédures
stockées après avoir chargé la base de support &slony1; dans
la base de données. Vous pouvez trouver de la documentation sur
ces procédures dans le chapitre <ulink url="schemadoc">&slony1;
- Documentation du Schéma</ulink>, ainsi que dans les commentaires
- qui sont associé aux procédures dans la base de données.
- </para>
-
- <para>
- <application>Slonik</application> a été créé car:
- <itemizedlist>
-
- <listitem><para>Les procédures stockées ont des besoin d'informations
- spécifiques telles que l'identifiant du noeud de réplication
- sur lequel elles sont appelées;</para></listitem>
-
- <listitem><para>L'absence de paramètres nommés dans les
- procédures stockées rend difficile de faire cela depuis
- l'invite de commande <application>psql</application>;
- </para></listitem>
-
- <listitem><para><application>psql</application>n'a pas la possibilité
- de maintenir plusieurs connexions avec des transactions ouvertes.
- </para></listitem>
- </itemizedlist>
- </para>
- <para>
+ Documentation du Schéma</ulink>, ainsi que dans les commentaires
+ qui sont associé aux procédures dans la base de données.
+ </para>
+ <para>
+ <application>Slonik</application> a été créé car:
+ <itemizedlist>
+
+ <listitem><para>Les procédures stockées ont des besoin d'informations
+ spécifiques telles que l'identifiant du noeud de réplication
+ sur lequel elles sont appelées;</para></listitem>
+
+ <listitem><para>L'absence de paramètres nommés dans les
+ procédures stockées rend difficile de faire cela depuis
+ l'invite de commande <application>psql</application>;
+ </para></listitem>
+
+ <listitem><para><application>psql</application>n'a pas la possibilité
+ de maintenir plusieurs connexions avec des transactions ouvertes.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ <para>
- </para>
- <sect3><title>Commandes</title>
- <para>
- Le format du langage de commande slonik est libre.
- Les commandes commence par des mots-clefs et sont terminées
- par un point-virgule. La plupart des commande ont une liste de
- paramètres, certains ont une valeur par défaut et sont donc
- facultatifs. Les paramètres de commandes sont entourés par des
- parenthèses. Chaque option est constituée d'un ou plusieurs
- mots-clefs, suivis d'un symbole égal, suivi d'une valeur. Les
- optons multiples à l'intérieur de parenthèses sont séparées par
- des virgules. Tous les mot-clefs sont sensibles à la casse. Le
- langage devrait rappeler le SQL.
- </para>
- <para>
- Les valeurs d'option peuvent être :
- <itemizedlist>
- <listitem><para>des entiers;</para></listitem>
- <listitem><para>des chaînes caractères entourés de quotes;</para></listitem>
- <listitem><para>des valeurs booléennes {TRUE|ON|YES} ou {FALSE|OFF|NO};</para></listitem>
- <listitem><para>des mots-clefs dans des cas spécifiques</para></listitem>
- </itemizedlist>
- </para></sect3>
- <sect3><title>Commentaires</title>
- <para>
- Les commentaires commencent par un dièse (#) et vont jusqu'à la fin de la ligne.
- </para></sect3>
- <sect3><title>Groupes de commandes</title>
- <para>
- Les commandes peuvent être combinées par groupes de commandes avec une
- éventuellement une condition <command>on error</command> et
- <command>on success</command>.
- La syntaxe est la suivante :
- <programlisting>
- try {
- commands;
- }
- [on error { commands; }
- [on success { commands; }
- </programlisting></para>
+ </para>
+ <sect3><title>Commandes</title>
+ <para>Le format du langage de commande slonik est libre.
+ Les commandes commence par des mots-clefs et sont terminées
+ par un point-virgule. La plupart des commande ont une liste de
+ paramètres, certains ont une valeur par défaut et sont donc
+ facultatifs. Les paramètres de commandes sont entourés par des
+ parenthèses. Chaque option est constituée d'un ou plusieurs
+ mots-clefs, suivis d'un symbole égal, suivi d'une valeur. Les
+ optons multiples à l'intérieur de parenthèses sont séparées par
+ des virgules. Tous les mot-clefs sont sensibles à la casse. Le
+ langage devrait rappeler le SQL.</para>
+ <para>Les valeurs d'option peuvent être : </para>
+ <itemizedlist>
+ <listitem><para>des entiers;</para></listitem>
+ <listitem><para>des chaînes caractères entourés de quotes;</para></listitem>
+ <listitem><para>des valeurs booléennes {TRUE|ON|YES} ou {FALSE|OFF|NO};</para></listitem>
+ <listitem><para>des mots-clefs dans des cas spécifiques</para></listitem>
+ </itemizedlist>
- <para> Ces commandes sont regroupées ensemble au sein d'une transaction
- pour chaque noeud participant.</para>
-<!-- ************************************************************ --></sect3></sect2></sect1></article>
+ </sect3>
+ <sect3><title>Commentaires</title>
+ <para>Les commentaires commencent par un dièse (#) et vont jusqu'à la fin de la ligne.</para>
+ </sect3>
+ <sect3><title>Groupes de commandes</title>
+ <para>Les commandes peuvent être combinées par groupes de commandes avec une
+ éventuellement une condition <command>on error</command> et
+ <command>on success</command>.
+ La syntaxe est la suivante :
+ <programlisting>
+ try {
+ commands;
+ }
+ [on error { commands; }
+ [on success { commands; }
+ </programlisting></para>
- <reference id="metacmds">
+ <para> Ces commandes sont regroupées ensemble au sein d'une transaction
+ pour chaque noeud participant.</para>
+
+ </sect3>
+ </sect2>
+ </sect1>
+</article>
+<!-- ************************************************************ -->
+<reference id="metacmds">
<title>Meta-commandes Slonik</title>
<partintro>
- <para>
- Les commandes suivantes sont utilisées pour séparer
- les définitions des composants des scripts Slonik;
- <xref linkend="stmtinclude"/> regroupe la configuration
- dans des fichiers centraux qui peuvent être réutilisés, et
- <xref linkend="stmtdefine"/> permet de remplacer les identifiants
- numérique et ésotérique des objets par des identifiants mnémotechniques.
- </para>
+ <para>Les commandes suivantes sont utilisées pour séparer
+ les définitions des composants des scripts Slonik;
+ <xref linkend="stmtinclude"/> regroupe la configuration
+ dans des fichiers centraux qui peuvent être réutilisés, et
+ <xref linkend="stmtdefine"/> permet de remplacer les identifiants
+ numérique et ésotérique des objets par des identifiants mnémotechniques.</para>
</partintro>
<!-- **************************************** -->
- <refentry id ="stmtinclude"><refmeta><refentrytitle>INCLUDE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>INCLUDE</refname>
-
- <refpurpose> insérer du code slonik à partir d'un autre fichier </refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>include </command>
- <arg><replaceable class="parameter"> <chemin></replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Ceci injecte le script slonik spécifié à l'intérieur du script actuel.
+ <refentry id ="stmtinclude">
+ <refmeta><refentrytitle>INCLUDE</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>INCLUDE</refname>
+ <refpurpose> insérer du code slonik à partir d'un autre fichier </refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>include </command>
+ <arg><replaceable class="parameter"> <chemin></replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Ceci injecte le script slonik spécifié à l'intérieur du script actuel.
Si le <option>chemin</option> est relatif, <xref linkend="slonik"/>
- cherchera à partir du répertoire de travail.
- </para>
-
- <para>
- Les inclusions imbriquées sont supportées. Le scanner et l'analyser
+ cherchera à partir du répertoire de travail.</para>
+ <para>Les inclusions imbriquées sont supportées. Le scanner et l'analyser
retourne le bon nom de fichier et le numéro ligne correcte en cas
- d'erreur.
- </para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- include </tmp/preamble.slonik>;
- </programlisting>
- </refsect1>
- <refsect1> <title> Note de version </title>
- <para> Cette commande fut introduite dans &slony1; 1.1 </para>
- </refsect1>
+ d'erreur.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ include </tmp/preamble.slonik>;
+ </programlisting>
+ </refsect1>
+ <refsect1> <title> Note de version </title>
+ <para> Cette commande fut introduite dans &slony1; 1.1 </para>
+ </refsect1>
</refentry>
<!-- **************************************** -->
- <refentry id ="stmtdefine"><refmeta><refentrytitle>DEFINE</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>DEFINE</refname>
-
- <refpurpose> Définir un nom symbolique </refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>define </command>
- <arg><replaceable class="parameter"> nom </replaceable></arg>
- <arg><replaceable class="parameter"> valeur </replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Ceci définit un nom symbolique. Les noms symboliques doivent
+ <refentry id ="stmtdefine"><refmeta><refentrytitle>DEFINE</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv><refname>DEFINE</refname>
+ <refpurpose> Définir un nom symbolique </refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>define </command>
+ <arg><replaceable class="parameter"> nom </replaceable></arg>
+ <arg><replaceable class="parameter"> valeur </replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Ceci définit un nom symbolique. Les noms symboliques doivent
respecter les règles de slonik en matière de construction d'identifiant,
- en commençant par une lettre, suivie de lettres, de nombres et de soulignés ("_").
- </para>
-
- <para>
- Les valeurs des noms symboliques peuvent contenir des espaces et peuvent contenir
- des références à des noms symboliques, de manière récursive.
- </para>
-
- <para>
- Les symboles sont référencés en utilisant une arobase <quote>@</quote> suivi
+ en commençant par une lettre, suivie de lettres, de nombres et de soulignés ("_").</para>
+ <para>Les valeurs des noms symboliques peuvent contenir des espaces et peuvent contenir
+ des références à des noms symboliques, de manière récursive.</para>
+ <para>Les symboles sont référencés en utilisant une arobase <quote>@</quote> suivi
du nom symbolique. Notons que le référencement d'un symbole est annulé
- à l'intérieur des chaînes de caractères.
- </para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
-define cluster films;
-define sakai 1;
-define chen 2;
-define fqn fully qualified name;
+ à l'intérieur des chaînes de caractères.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ define cluster films;
+ define sakai 1;
+ define chen 2;
+ define fqn fully qualified name;
-cluster name = @cluster;
-node @sakai admin conninfo = 'service=sakai-replication';
-node @chen admin conninfo = 'service=chen-replication';
-define setFilms id = 1;
-define sakaiFilms @setFilms, origin = @sakai;
+ cluster name = @cluster;
+ node @sakai admin conninfo = 'service=sakai-replication';
+ node @chen admin conninfo = 'service=chen-replication';
+ define setFilms id = 1;
+ define sakaiFilms @setFilms, origin = @sakai;
-create set ( @sakaiFilms, comment = 'films' );
+ create set ( @sakaiFilms, comment = 'films' );
-set add table( set @sakaiFilms, id = 1, @fqn = 'public.clients',
+ set add table( set @sakaiFilms, id = 1, @fqn = 'public.clients',
comment = 'sakai customers' );
-set add table( set @sakaiFilms, id = 2, @fqn = 'public.cassettes',
+ set add table( set @sakaiFilms, id = 2, @fqn = 'public.cassettes',
comment = 'sakai cassettes' );
-echo '@sakaiFilms sera affiché comme une chaîne, et ne sera pas interprété';
- </programlisting>
- </refsect1>
+ echo '@sakaiFilms sera affiché comme une chaîne, et ne sera pas interprété';
+ </programlisting>
+ </refsect1>
- <refsect1> <title> Note de version </title>
- <para> Cette commande fut introduite dans &slony1; 1.1 </para>
- </refsect1>
+ <refsect1> <title> Note de version </title>
+ <para> Cette commande fut introduite dans &slony1; 1.1 </para>
+ </refsect1>
</refentry>
-
- </reference>
+</reference>
<!-- **************************************** -->
- <reference id="hdrcmds">
+<reference id="hdrcmds">
<title>Commandes slonik préliminaires</title>
<partintro>
- <para>
- Les commandes suivantes doivent apparaître en <quote>préambule</quote> au
+ <para>Les commandes suivantes doivent apparaître en <quote>préambule</quote> au
de chaque script de commande <application>slonik</application>.
Ils ne provoque aucune action directement sur les noeuds du
- système de réplication, mais affecte l'exécution du script tout entier.
- </para>
+ système de réplication, mais affecte l'exécution du script tout entier.</para>
</partintro>
- <!-- **************************************** -->
-
- <refentry id ="clustername"><refmeta><refentrytitle>CLUSTER NAME</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>CLUSTER NAME</refname>
+ <refentry id ="clustername">
+ <refmeta><refentrytitle>CLUSTER NAME</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>CLUSTER NAME</refname>
+ <refpurpose> préambule - identifier le cluster &slony1; </refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>CLUSTER NAME = </command>
+ <arg><replaceable class="parameter"> nom;</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Ceci doit être la toute première ligne de chaque script
+ <application>slonik</application>. Elle définit l'espace
+ de nom dans lequel toutes les fonctions spécifiques, les procédures,
+ les tables et les séquences de &slony1; sont déclarées.
+ Le nom de l'espace de nom est construit en préfixant le chaîne
+ de caractère fournie par un souligné. Ce nom d'espace sera
+ identique sur toutes les bases de données qui participent
+ aux même groupe de réplication.</para>
- <refpurpose> préambule - identifier le cluster &slony1; </refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>CLUSTER NAME = </command>
- <arg><replaceable class="parameter"> nom;</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Ceci doit être la toute première ligne de chaque script
- <application>slonik</application>. Elle définit l'espace
- de nom dans lequel toutes les fonctions spécifiques, les procédures,
- les tables et les séquences de &slony1; sont déclarées.
- Le nom de l'espace de nom est construit en préfixant le chaîne
- de caractère fournie par un souligné. Ce nom d'espace sera
- identique sur toutes les bases de données qui participent
- aux même groupe de réplication.
- </para>
-
- <para>
- Aucun objet utilisateur n'est supposé être placé dans cet espace de nom,
- et l'espace de nom ne doit exister avant l'ajout de la base de données
- dans le système de réplication. Ainsi, si vous ajouter un nouveau noeud
- en utilisant <command> pg_dump -s </command> sur une base qui est déjà
- dans le cluster de réplication, vous devrez supprimer l'espace de nom
- avec la commande SQL<command> DROP SCHEMA _testcluster CASCADE; </command>.
- </para>
- </refsect1>
- <refsect1><title>Exemple</title>
- <programlisting>
- CLUSTER NAME = testcluster;
- </programlisting>
- </refsect1>
- <refsect1> <title> Note de version </title>
- <para> Cette commande fut introduite dans &slony1; 1.0 </para>
- </refsect1>
+ <para>Aucun objet utilisateur n'est supposé être placé dans cet espace de nom,
+ et l'espace de nom ne doit exister avant l'ajout de la base de données
+ dans le système de réplication. Ainsi, si vous ajouter un nouveau noeud
+ en utilisant <command> pg_dump -s </command> sur une base qui est déjà
+ dans le cluster de réplication, vous devrez supprimer l'espace de nom
+ avec la commande SQL<command> DROP SCHEMA _testcluster CASCADE; </command>.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ CLUSTER NAME = testcluster;
+ </programlisting>
+ </refsect1>
+ <refsect1> <title> Note de version </title>
+ <para> Cette commande fut introduite dans &slony1; 1.0 </para>
+ </refsect1>
</refentry>
-
-
-<!-- **************************************** -->
+ <refentry id ="admconninfo">
+ <refmeta><refentrytitle>ADMIN CONNINFO</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>ADMIN CONNINFO</refname>
+ <refpurpose> preambule - identifier la base &postgres;</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>NODE ival ADMIN CONNINFO = 'DSN';</command>
+ <arg><replaceable class="parameter"> ival;</replaceable></arg>
+ <arg><replaceable class="parameter"> 'conninfo'</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Décrit comment l'utilitaire <application>slonik</application> peut
+ atteindre les bases des noeuds du cluster à partir du l'endroit
+ où il se trouve (en général le poste de travail de l'administrateur)
+ La chaîne connifo est l'argument passé à la fonction
+ libpq <function>PQconnectdb()</function>. L'utilisateur qui se connecter
+ doit être un super-utilisateur spécifique à la réplication, car certaines
+ actions réalisées par la suite comprennent des opérations strictement réservées
+ aux super-utilisateurs du serveur &postgres;.</para>
- <refentry id ="admconninfo"><refmeta><refentrytitle>ADMIN CONNINFO</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>ADMIN CONNINFO</refname>
- <refpurpose> preambule - identifier la base &postgres;</refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>NODE ival ADMIN CONNINFO = 'DSN';</command>
- <arg><replaceable class="parameter"> ival;</replaceable></arg>
- <arg><replaceable class="parameter"> 'conninfo'</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Décrit comment l'utilitaire <application>slonik</application> peut
- atteindre les bases des noeuds du cluster à partir du l'endroit
- où il se trouve (en général le poste de travail de l'administrateur)
- La chaîne connifo est l'argument passé à la fonction
- libpq <function>PQconnectdb()</function>. L'utilisateur qui se connecter
- doit être un super-utilisateur spécifique à la réplication, car certaines
- actions réalisées par la suite comprennent des opérations strictement réservées
- aux super-utilisateurs du serveur &postgres;.
- </para>
+ <para>L'utilitaire <application>slonik</application> n'essaie pas de se connecter
+ à une base de donnée que si un commande nécessite une connexion.</para>
- <para>
- L'utilitaire <application>slonik</application> n'essaie pas de se connecter
- à une base de donnée que si un commande nécessite une connexion.
- </para>
+ <note><para>Comme indique dans les document originaux, &slony1; est conçu comme
+ une système de réplication d'entreprises pour datacenters. Lors du développement
+ du logiciel, on présuppose que les serveurs de bases de données et les postes
+ de travail impliqués dans la réplication et/ou dans les activités de mise en place et
+ de configuration peuvent utiliser des méthodes simples d'authentification telle que
+ <quote>trust</quote>. Cependant, libpq peut lire les mots de passe dans le fichier
+ <filename> .pgpass </filename>.</para></note>
+ <note><para>Si vous devez changer les informations DSN pour un noeud, par exemple si
+ l'adresse IP d'un hôte est modifiée, vous devez soumettre cette nouvelle
+ information avec la commande <xref linkend="stmtstorepath"/>,
+ et la configuration sera propagée. Certains processus
+ <application> slon </application> existant devront être relancés afin qu'il
+ soient avertis de ce changement de configuration.</para></note>
- <note> <para>
- Comme indique dans les document originaux, &slony1; est conçu comme
- une système de réplication d'entreprises pour datacenters. Lors du développement
- du logiciel, on présuppose que les serveurs de bases de données et les postes
- de travail impliqués dans la réplication et/ou dans les activités de mise en place et
- de configuration peuvent utiliser des méthodes simples d'authentification telle que
- <quote>trust</quote>. Cependant, libpq peut lire les mots de passe dans le fichier
- <filename> .pgpass </filename>.
- </para>
- </note>
- <note>
- <para>
- Si vous devez changer les informations DSN pour un noeud, par exemple si
- l'adresse IP d'un hôte est modifiée, vous devez soumettre cette nouvelle
- information avec la commande <xref linkend="stmtstorepath"/>,
- et la configuration sera propagée. Certains processus
- <application> slon </application> existant devront être relancés afin qu'il
- soient avertis de ce changement de configuration.
- </para>
- </note>
+ <para>Pour plus de détails sur la distinction entre ceci et <xref
+ linkend="stmtstorepath"/>, consultez le chapitre &rplainpaths;.</para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
+ </programlisting>
+ </refsect1>
+ <refsect1> <title> Note de version </title>
+ <para> Cette commande fut introduite dans &slony1; 1.0 </para>
+ </refsect1>
+ </refentry>
+</reference>
- <para>Pour plus de détails sur la distinction entre ceci et <xref
- linkend="stmtstorepath"/>, consultez le chapitre &rplainpaths;.</para>
-
- </refsect1>
+<!-- ************************************************************ -->
+<reference id="cmds">
+ <title>Commande de configuration et d'action</title>
+ <refentry id ="stmtecho">
+ <refmeta>
+ <refentrytitle>ECHO</refentrytitle><manvolnum>7</manvolnum></refmeta>
+ <refnamediv>
+ <refname>ECHO</refname>
+ <refpurpose> Outil générique de sortie </refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>echo </command>
+ <arg><replaceable class="parameter"> 'message'</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>Affiche un message littéral sur la sortie standard.</para>
+ </refsect1>
<refsect1><title>Exemple</title>
<programlisting>
- NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
- </programlisting>
- </refsect1>
- <refsect1> <title> Note de version </title>
- <para> Cette commande fut introduite dans &slony1; 1.0 </para>
- </refsect1>
- </refentry>
- </reference>
-<!-- ************************************************************ -->
-
-<!-- **************************************** -->
- <reference id="cmds">
- <title>Commande de configuration et d'action</title>
-<!-- **************************************** -->
-
- <refentry id ="stmtecho"><refmeta><refentrytitle>ECHO</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>ECHO</refname>
-
- <refpurpose> Outil générique de sortie </refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>echo </command>
- <arg><replaceable class="parameter"> 'message'</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Affiche un message littéral sur la sortie standard.
- </para>
- </refsect1>
- <refsect1><Title>Exemple</Title>
- <programlisting>
ECHO 'Noeud 1 initialisé correctement';
</programlisting>
</refsect1>
@@ -396,7 +340,7 @@
la valeur indiquée comme code de terminaison du programme.
</para>
</refsect1>
- <refsect1><Title>Exemple</Title>
+ <refsect1><title>Exemple</title>
<programlisting>
EXIT 0;
</programlisting>
@@ -540,7 +484,7 @@
<para> Ceci utilise &funinitializelocalnode; et &funenablenode;. </para>
</refsect1>
- <refsect1><Title>Exemple</Title>
+ <refsect1><title>Exemple</title>
<programlisting>
STORE NODE ( ID = 2, COMMENT = 'Noeud 2');
</programlisting>
@@ -1893,32 +1837,31 @@
<refsect1>
<title>Description</title>
- <para> Supprime la gestion particulière du trigger spécifié.
-
- <variablelist>
- <varlistentry><term><literal> TABLE ID = ival </literal></term>
- <listitem><para> L'identifiant numérique et unique de la table pour laquelle le
-trigger est défini.</para></listitem>
-
+ <para> Supprime la gestion particulière du trigger spécifié.
+ <variablelist>
+ <varlistentry>
+ <term><literal> TABLE ID = ival </literal></term>
+ <listitem>
+ <para> L'identifiant numérique et unique de la table pour laquelle le
+ trigger est défini.</para>
+ </listitem>
</varlistentry>
- <varlistentry><term><literal> TRIGGER NAME = 'string' </literal></term>
-
- <listitem><para> Le nom du trigger tel qu'on le trouve dans le catalogue système
- <envar>pg_trigger</envar>.</para></listitem>
-
+ <varlistentry>
+ <term><literal> TRIGGER NAME = 'string' </literal></term>
+ <listitem><para> Le nom du trigger tel qu'on le trouve dans le catalogue système
+ <envar>pg_trigger</envar>.</para>
+ </listitem>
</varlistentry>
- <varlistentry><term><literal> EVENT NODE = ival </literal></term>
-
- <listitem><para> (Optionnel) L'identifiant du noeud utilisé pour
-créer l'événement de configuration qui annonce aux noeuds existants la
-présence d'un trigger spécial. Par défaut, cette valeur est 1.
- </para></listitem>
-
+ <varlistentry>
+ <term><literal> EVENT NODE = ival </literal></term>
+ <listitem>
+ <para> (Optionnel) L'identifiant du noeud utilisé pour
+ créer l'événement de configuration qui annonce aux noeuds existants la
+ présence d'un trigger spécial. Par défaut, cette valeur est 1.</para>
+ </listitem>
</varlistentry>
-
- </varlistentry>
- </variablelist>
- </para>
+ </variablelist>
+ </para>
<para> Cette commande utilise &fundroptrigger;. </para>
</refsect1>
<refsect1><title>Exemple</title>
@@ -2298,7 +2241,7 @@
</para>
<para> Cette commande utilise &funlockset;. </para>
</refsect1>
- <refsect1><Title>Exemple</Title>
+ <refsect1><title>Exemple</title>
<programlisting>
LOCK SET (
ID = 1,
@@ -2557,12 +2500,11 @@
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
- <title>Description</title>
-
- <para> Cette commande exécutes un script contenant de ordres SQL sur
-tous les noeuds qui sont abonnés à un ensemble de réplication à un
-point précis dans le flux des transactions.</para>
- OA
+ <title>Description</title>
+ <para> Cette commande exécutes un script contenant de ordres SQL sur
+ tous les noeuds qui sont abonnés à un ensemble de réplication à un
+ point précis dans le flux des transactions.</para>
+
<para> L'origine de l'événement doit être l'origine de l'ensemble
de réplication. Le fichier de script ne doit pas contenir d'ordres
<command>START</command> ou <command>COMMIT TRANSACTION</command>.
@@ -2993,7 +2935,7 @@
Cette commande endors les opérations pendant un certain nombre de secondes.
</para>
</refsect1>
- <refsect1><Title>Exemple</Title>
+ <refsect1><title>Exemple</title>
<programlisting>
sleep (seconds = 5);
</programlisting>
@@ -3038,54 +2980,46 @@
</para>
</refsect1>
- <refsect1><Title>Exemple</Title>
- <Programlisting>
+ <refsect1><title>Exemple</title>
+ <programlisting>
clone prepare (id = 33, provider = 22, comment='Clone 33');
sync (id=11);
sync (id=22);
- </Programlisting>
+ </programlisting>
</refsect1>
<refsect1> <title> Note de version </title>
<para> Cette commande fut introduite dans &slony1; 1.2.0. </para>
</refsect1>
</refentry>
-
-
<refentry id ="stmtclonefinish"><refmeta><refentrytitle>CLONE FINISH</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>CLONE FINISH</refname>
-
- <refpurpose> Termine le clonage d'un noeud. </refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>clone prepare </command>
- <arg><replaceable class="parameter"> id</replaceable></arg>
- <arg><replaceable class="parameter"> provider</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Cette commande achève le clonage sur un noeud donné.
- </para>
-
- <para>
- Ceci complète le travail effectué par <xref
- linkend="stmtcloneprepare"/>, en établissant les données de confirmation
-pour le nouveau <quote>clone</quote> à partir du statut trouvé pour le
-noeud <quote>fournisseur</quote>.
- </para>
- </refsect1>
- <refsect1><Title>Exemple</Title>
- <Programlisting>
- clone finish (id = 33, provider = 22);
- </Programlisting>
- </refsect1>
- <refsect1> <title> Note de version </title>
- <para> Cette commande fut introduite dans &slony1; 1.2.0. </para>
- </refsect1>
+ <manvolnum>7</manvolnum></refmeta>
+ <refnamediv><refname>CLONE FINISH</refname>
+ <refpurpose> Termine le clonage d'un noeud. </refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>clone prepare </command>
+ <arg><replaceable class="parameter"> id</replaceable></arg>
+ <arg><replaceable class="parameter"> provider</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>
+ Cette commande achève le clonage sur un noeud donné.
+ </para>
+ <para>Ceci complète le travail effectué par <xref linkend="stmtcloneprepare"/>, en établissant les données de confirmation
+ pour le nouveau <quote>clone</quote> à partir du statut trouvé pour le noeud <quote>fournisseur</quote>.
+ </para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ clone finish (id = 33, provider = 22);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title> Note de version </title>
+ <para> Cette commande fut introduite dans &slony1; 1.2.0. </para>
+ </refsect1>
</refentry>
Modified: traduc/trunk/slony/slony.xml
===================================================================
--- traduc/trunk/slony/slony.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/slony.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -31,37 +31,35 @@
<!ENTITY funsetaddsequence "<xref linkend='function.setaddsequence-integer-integer-text-text'/>">
<!ENTITY funsetdropsequence "<xref linkend='function.setdropsequence-integer'/>">
<!ENTITY funsetmovetable "<xref linkend='function.setmovetable-integer-integer'/>">
-<!ENTITY fundroptrigger "<xref linkend='function.droptrigger-integer-name'/>">
-<!ENTITY funddlscript "<xref linkend='function.ddlscript-complete-integer-text-integer'/>">
-<!ENTITY fundropnode "<xref linkend='function.dropnode-integer'/>">
-<!ENTITY funenablenode "<xref linkend='function.enablenode-integer'/>">
-<!ENTITY funfailednode "<xref linkend='function.failednode-integer-integer'/>">
-<!ENTITY funinitializelocalnode "<xref linkend='function.initializelocalnode-integer-text'/>">
-<!ENTITY funlockset "<xref linkend='function.lockset-integer'/>">
-<!ENTITY funmoveset "<xref linkend='function.moveset-integer-integer'/>">
-<!ENTITY funsetmovesequence "<xref linkend='function.setmovesequence-integer-integer'/>">
-<!ENTITY funstoretrigger "<xref linkend='function.storetrigger-integer-name'/>">
-<!ENTITY funsubscribeset "<xref linkend='function.subscribeset-integer-integer-integer-boolean'/>">
-<!ENTITY fununinstallnode "<xref linkend='function.uninstallnode'/>">
-<!ENTITY fununlockset "<xref linkend='function.unlockset-integer'/>">
-<!ENTITY fununsubscribeset "<xref linkend='function.unsubscribeset-integer-integer'/>">
-<!ENTITY bestpracticelink "<link linkend='bestpractices'>Best Practice</link>">
-<!ENTITY rmissingoids "<link linkend='missingoids'>error messages indicating missing OIDs</link>">
-<!ENTITY slnode "<xref linkend='table.sl-node'/>">
-<!ENTITY sllog1 "<xref linkend='table.sl-log-1'/>">
-<!ENTITY sllog2 "<xref linkend='table.sl-log-2'/>">
-<!ENTITY slconfirm "<xref linkend='table.sl-confirm'/>">
-<!ENTITY rplainpaths "<xref linkend='plainpaths'/>">
-<!ENTITY rlistenpaths "<xref linkend='listenpaths'/>">
-<!ENTITY pglistener "<envar>pg_listener</envar>">
-<!ENTITY lslon "<xref linkend='slon'/>">
-<!ENTITY lslonik "<xref linkend='slonik'/>">
-<!ENTITY frenchtranslation "<xref linkend='frenchtranslation'/>">
-
-
+ <!ENTITY fundroptrigger "<xref linkend='function.droptrigger-integer-name'/>">
+ <!ENTITY funddlscript "<xref linkend='function.ddlscript-complete-integer-text-integer'/>">
+ <!ENTITY fundropnode "<xref linkend='function.dropnode-integer'/>">
+ <!ENTITY funenablenode "<xref linkend='function.enablenode-integer'/>">
+ <!ENTITY funfailednode "<xref linkend='function.failednode-integer-integer'/>">
+ <!ENTITY funinitializelocalnode "<xref linkend='function.initializelocalnode-integer-text'/>">
+ <!ENTITY funlockset "<xref linkend='function.lockset-integer'/>">
+ <!ENTITY funmoveset "<xref linkend='function.moveset-integer-integer'/>">
+ <!ENTITY funsetmovesequence "<xref linkend='function.setmovesequence-integer-integer'/>">
+ <!ENTITY funstoretrigger "<xref linkend='function.storetrigger-integer-name'/>">
+ <!ENTITY funsubscribeset "<xref linkend='function.subscribeset-integer-integer-integer-boolean'/>">
+ <!ENTITY fununinstallnode "<xref linkend='function.uninstallnode'/>">
+ <!ENTITY fununlockset "<xref linkend='function.unlockset-integer'/>">
+ <!ENTITY fununsubscribeset "<xref linkend='function.unsubscribeset-integer-integer'/>">
+ <!ENTITY bestpracticelink "<link linkend='bestpractices'>Best Practice</link>">
+ <!ENTITY rmissingoids "<link linkend='missingoids'>error messages indicating missing OIDs</link>">
+ <!ENTITY slnode "<xref linkend='table.sl-node'/>">
+ <!ENTITY sllog1 "<xref linkend='table.sl-log-1'/>">
+ <!ENTITY sllog2 "<xref linkend='table.sl-log-2'/>">
+ <!ENTITY slconfirm "<xref linkend='table.sl-confirm'/>">
+ <!ENTITY rplainpaths "<xref linkend='plainpaths'/>">
+ <!ENTITY rlistenpaths "<xref linkend='listenpaths'/>">
+ <!ENTITY pglistener "<envar>pg_listener</envar>">
+ <!ENTITY lslon "<xref linkend='slon'/>">
+ <!ENTITY lslonik "<xref linkend='slonik'/>">
+ <!ENTITY lfrenchtranslation "<xref linkend='frenchtranslation'/>">
]>
-<book id="slony">
+<book id="slony" lang="fr">
<title>Documentation &slony1; &version;</title>
<bookinfo>
<corpauthor>The PostgreSQL Global Development Group</corpauthor>
@@ -85,57 +83,52 @@
&reference;
-<article id="slonyadmin">
-<title> Administration Slony-I</title>
- <articleinfo>
- <corpauthor>The PostgreSQL Global Development Group</corpauthor>
- <author> <firstname>Christopher</firstname> <surname>Browne</surname> </author>
- </articleinfo>
- &bestpractices;
- &firstdb;
- &startslons;
- &subscribenodes;
- &monitoring;
- &maintenance;
- &reshape;
- &failover;
- &listenpaths;
- &plainpaths;
- &triggers;
- &locking;
- &raceconditions;
- &addthings;
- &dropthings;
- &logshipfile;
- &ddlchanges;
- &usingslonik;
- &adminscripts;
- &partitioning;
- &slonyupgrade;
- &versionupgrade;
- &testbed;
- &loganalysis;
- &help;
- &supportedplatforms;
- &releasechecklist;
-</article>
+ <article id="slonyadmin">
+ <title> Administration Slony-I</title>
+ <articleinfo>
+ <corpauthor>The PostgreSQL Global Development Group</corpauthor>
+ <author> <firstname>Christopher</firstname> <surname>Browne</surname> </author>
+ </articleinfo>
+ &bestpractices;
+ &firstdb;
+ &startslons;
+ &subscribenodes;
+ &monitoring;
+ &maintenance;
+ &reshape;
+ &failover;
+ &listenpaths;
+ &plainpaths;
+ &triggers;
+ &locking;
+ &raceconditions;
+ &addthings;
+ &dropthings;
+ &logshipfile;
+ &ddlchanges;
+ &usingslonik;
+ &adminscripts;
+ &partitioning;
+ &slonyupgrade;
+ &versionupgrade;
+ &testbed;
+ &loganalysis;
+ &help;
+ &supportedplatforms;
+ &releasechecklist;
+ </article>
-<article id="faq">
-
-<title>FAQ Slony-I</title>
-<articleinfo>
+ <article id="faq">
+ <title>FAQ Slony-I</title>
+ <articleinfo>
<corpauthor>The Slony Global Development Group</corpauthor>
- <author>
- <firstname>Christopher </firstname>
- <surname>Browne</surname>
- </author>
+ <author><firstname>Christopher </firstname><surname>Browne</surname></author>
</articleinfo>
-
-<para> Ces questions ne sont pas toutes, au sens strict, des questions <quote>fréquemment posées</quote>;
+ <para> Ces questions ne sont pas toutes, au sens strict, des questions <quote>fréquemment posées</quote>;
certaines illustrent des <emphasis>problèmes identifiés qu'il semble bon de documenter</emphasis>.</para>
- &faq;
-</article>
+ &faq;
+ </article>
<part id="commandreference">
<title>Le Coeur de &slony1;</title>
&slon;
Modified: traduc/trunk/slony/startslons.xml
===================================================================
--- traduc/trunk/slony/startslons.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/startslons.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -54,7 +54,7 @@
Tout problème avec ce lien peut tuer les connexions et ainsi laisser
des connexions <quote>zombies</quote> sur le noeud qui subsisteront
(de manière générale) pendant environ deux heures. Ceci empêche le démarrage
- d'un autre slon, comme cela est décrit dans la <link linkend="FAQ"> FAQ
+ d'un autre slon, comme cela est décrit dans la <link linkend="faq"> FAQ
</link> au sein de la section sur <link linkend="multipleslonconnections">les connexions
slon multiples slon</link>. </para> </warning>
Modified: traduc/trunk/slony/supportedplatforms.xml
===================================================================
--- traduc/trunk/slony/supportedplatforms.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/supportedplatforms.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -4,7 +4,7 @@
par $Author$
révision $Revision$ -->
-<article id="supportedplatforms">
+<sect1 id="supportedplatforms">
<title>Plate-formes supportées par &slony1;</title>
<indexterm><primary>Plateformes supportées</primary></indexterm>
@@ -181,4 +181,4 @@
</tbody>
</tgroup>
</table>
-</article>
+</sect1>
Modified: traduc/trunk/slony/testbed.xml
===================================================================
--- traduc/trunk/slony/testbed.xml 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/testbed.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -6,263 +6,257 @@
<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 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> 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 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> 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 implique des noms inhabituels afin de vérifier
- que les guillemets sont gérées 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 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> 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 quelque uns des fichiers vitaux...</para>
+ <para>Voici quelque uns des fichiers vitaux...</para>
-<itemizedlist>
-
-<listitem><para> <filename>run_test.sh</filename> </para></listitem>
-
-</itemizedlist>
-
-<para> Ceci est le script central pour exécuter les tests. Son utilisation
+
+ <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> <command> ./run_test.sh </command></para>
+ <screen>
+ usage ./run_test.sh nom_du_test
+ </screen>
-<para> <command> ./run_test.sh </command></para>
-<screen>
-usage ./run_test.sh nom_du_test
-</screen>
+ <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>
-<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>
+ <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 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>
+ <screen> PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1 </screen>
-<screen> PGBINDIR=/opt/OXRS/dbs/pgsql8/bin PGPORT=5532 PGUSER=cbbrowne ./run_test.sh test1 </screen>
+ <glosslist>
+ <glossentry>
+ <glossterm> <envar>PGBINDIR</envar> </glossterm>
-<glosslist>
-<glossentry><glossterm> <envar>PGBINDIR</envar> </glossterm>
+ <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>
-<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>
+ <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>
-<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>
+ <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>
-<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 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>
-<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>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>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 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>
-<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>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>
-<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>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>
-<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>HOST</envar> </glossterm>
+ <glossdef><para>Par défaut, <filename>localhost</filename> est utilisé.
+ </para>
-<glossentry><glossterm> <envar>HOST</envar> </glossterm>
-<glossdef><para>Par défaut, <filename>localhost</filename> est utilisé.
-</para>
+ <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>
-<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>DB1</envar> jusqu'à <envar>DB13 </envar> </glossterm>
-<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>
-<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 bonne raisons d'utiliser des bonnes 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>
+ <glossterm><envar>MY_MKTEMP_IS_DECREPIT</envar></glossterm>
-</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 modifier cette
+ valeur. </para></glossdef>
+
+ </glossentry>
-<glossentry>
-<glossterm><envar>MY_MKTEMP_IS_DECREPIT</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>
+
+ <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 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>
+ <glossterm><envar>LOGSHIP[n]</envar></glossterm>
-</glossentry>
+ <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>
-<glossentry>
-<glossterm><envar>SLTOOLDIR</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>SLONCONF[n]</envar></glossterm>
-<glossdef><para> Où trouver les outils &slony1; tels que
-<application>slony1_dump.sh</application>. </para></glossdef>
+ <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>
-</glossentry>
+ <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>
-<glossentry>
-<glossterm><envar>ARCHIVE[n]</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>SLONYTESTFILE</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>
+ <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>
-</glossentry>
+ <glossentry>
+ <glossterm><filename>random_number</filename> et <filename>random_string</filename> </glossterm>
-<glossentry>
-<glossterm><envar>LOGSHIP[n]</envar></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 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>
+ <para> Pour chaque test, vous trouverez les fichiers suivants : </para>
-</glossentry>
+ <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>
-<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>
-
-<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>
-
-<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>
-
-<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>
-
-<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>
-o<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>
-
-<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>
\ No newline at end of file
+ <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 2008-10-29 23:25:58 UTC (rev 1172)
+++ traduc/trunk/slony/triggers.xml 2008-10-30 10:58:17 UTC (rev 1173)
@@ -3,214 +3,203 @@
le $Date$
par $Author$
révision $Revision$ -->
-<sect1 id="triggers"><title>Gestion des triggers &slony1;</title>
+<sect1 id="triggers">
+ <title>Gestion des triggers &slony1;</title>
+ <indexterm><primary>gestion des triggers</primary></indexterm>
-<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> Ceci provoquait un 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> &slony1; a connu deux <quote>types</quote> des gestion de triggers
-</para>
-<itemizedlist>
+ <para> Ceci est également vrai pour les règles ("rules"). </para>
-<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>
-</listitem>
-
-<para> Ceci provoquait un nombre d'effets secondaires pénibles, tels que :</para>
-<itemizedlist>
+ <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>
+ <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
+ supprimés et ajoutés à nouveau par cette opération.</para>
+ </listitem>
+ </itemizedlist>
+ </para></listitem>
+ <listitem>
+ <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 :
+ <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>
+ </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>
-<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> 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> Ceci est également vrai pour les règles ("rules"). </para>
+ <table id="triggerbehaviour"> <title>Comportement du trigger</title>
+ <tgroup cols="7">
+ <thead>
+ <row> <entry>Type de trigger</entry>
+ <entry>Condition de déclenchement</entry>
+ <entry>trigger de log</entry>
+ <entry>trigger denyaccess</entry>
+ <entry>Action - origin</entry>
+ <entry>Action - replica</entry>
+ <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>ne se déclenche pas</entry>
+ <entry>ne se déclenche pas</entry>
+ <entry>ne se déclenche pas</entry>
+ </row>
+ <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>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>inapproprié</entry>
+ <entry>inapproprié</entry>
+ <entry>ne se déclenche pas</entry>
+ <entry>se déclenche</entry>
+ <entry>ne se déclenche pas</entry>
+ </row>
+ <row>
+ <entry>ENABLE ALWAYS TRIGGER</entry>
+ <entry>Requête utilisateur</entry>
+ <entry>inapproprié</entry>
+ <entry>inapproprié</entry>
+ <entry>se déclenche</entry>
+ <entry>se déclenche</entry>
+ <entry>se déclenche</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ <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
+ 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>
+ </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> 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>
+ </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> 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>
+ <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>
-<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
- supprimés et ajoutés à nouveau par cette opération.</para></listitem>
+ <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
+ 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
+ <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>
+ </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
+ 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>
+ <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
+ opérations de suppression et re-création des triggers &slony1;), seules les tables impactées
+ 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>
-</itemizedlist>
+ <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
+ implique la désactivation des triggers <function>denyaccess</function>,
+ et d'activer les triggers <function>logtrigger</function>.</para>
-<listitem><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 :</para>
-</listitem>
-<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>
-
-</itemizedlist>
-
-<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>
-
-<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>
-
-<table id="triggerbehaviour"> <title>Comportement du trigger</title>
-<tgroup cols="7">
-<thead>
- <row> <entry>Type de trigger</entry>
- <entry>Condition de déclenchement</entry>
- <entry>trigger de log</entry>
- <entry>trigger denyaccess</entry>
- <entry>Action - origin</entry>
- <entry>Action - replica</entry>
- <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>ne se déclenche pas</entry>
- <entry>ne se déclenche pas</entry>
- <entry>ne se déclenche pas</entry>
-</row>
-<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>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>inapproprié</entry>
- <entry>inapproprié</entry>
- <entry>ne se déclenche pas</entry>
- <entry>se déclenche</entry>
- <entry>ne se déclenche pas</entry>
-</row>
-<row>
- <entry>ENABLE ALWAYS TRIGGER</entry>
- <entry>Requête utilisateur</entry>
- <entry>inapproprié</entry>
- <entry>inapproprié</entry>
- <entry>se déclenche</entry>
- <entry>se déclenche</entry>
- <entry>se déclenche</entry>
-</row>
-</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>
-
-<itemizedlist>
-
-<listitem><para> Avant que la réplication soit en place,
- <emphasis>chaque</emphasis> chaque 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> </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> 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>
-</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> 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> 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>
+ </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
+ 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>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ </listitem>
+ </itemizedlist>
</para>
-
-<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
- 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
- <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> </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
- 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>
-
-<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
-opérations de suppression et re-création des triggers &slony1;), seules les tables impactées
-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>
-
-<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
- 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>
-
-</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
- 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>
-</listitem>
-
-</itemizedlist>
-</itemizedlist>
-</sect1>
\ No newline at end of file
+</sect1>
More information about the Trad
mailing list