[Trad] [svn:pgfr] r1241 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mar 17 Fév 19:39:33 CET 2009
Author: gleu
Date: 2009-02-17 19:39:33 +0100 (Tue, 17 Feb 2009)
New Revision: 1241
Modified:
traduc/trunk/slony/adminscripts.xml
traduc/trunk/slony/bestpractices.xml
traduc/trunk/slony/slonconf.xml
Log:
Relecture, ?\195?\169tape 7.
Modified: traduc/trunk/slony/adminscripts.xml
===================================================================
--- traduc/trunk/slony/adminscripts.xml 2009-02-16 23:34:31 UTC (rev 1240)
+++ traduc/trunk/slony/adminscripts.xml 2009-02-17 18:39:33 UTC (rev 1241)
@@ -5,717 +5,1190 @@
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éveloppés 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>
- <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>
+<sect2 id="altperl">
+<title>Les scripts altperl</title>
+<indexterm><primary>Script altperl pour &slony1;</primary></indexterm>
- <sect2 id="altperl"> <title>Les scripts altperl</title>
+<para>
+ Il existe un ensemble de scripts qui simplifie l'administration de plusieurs
+ instances &slony1;. Ces scripts supportent une nombre variable de nœuds.
+ Ils peuvent être installés pendant le processus d'installation :
+</para>
- <indexterm><primary> Script altperl pour &slony1;</primary></indexterm>
+<para>
+ <command>./configure --with-perltools</command>
+</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>
+ 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 d'une aide en ligne grâce à l'option "--help", ce qui les
+ rend plus facile à prendre en main et à utiliser.
+</para>
- <para><command> ./configure --with-perltools</command></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>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>
+<sect3>
+<title>Gestion de multiples clusters</title>
+<indexterm><primary>gérer de multiples clusters avec les outils altperl</primary></indexterm>
- <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 variable d'environnement <envar>SLONYNODES</envar> est utilisée pour
+ déterminer le fichier de configuration Perl qui sera utilisé pour contrôler
+ les nœuds 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>
- <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>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>
- </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>
-
- <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>.
+ </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
+ gestion des traces 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) sont 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 celui de ses champs seront transformés en
+ minuscule.
+ </para>
+ </listitem>
+ </itemizedlist>
+</para>
- <para><command>
- add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437,
- user => 'postgres', node => 4, parent => 1);
- </command></para>
+<para>
+ Vous pouvez ensuite définir un ensemble de nœuds qui participeront à
+ la réplication en utilisant plusieurs appels à la fonction
+ <function>add_node()</function>.
+</para>
- <para>Les paramètres de la fonction <function>add_node()</function> sont les suivants :</para>
+<para>
+ <command>add_node (host => '10.20.30.40', dbname => 'orglogs',
+ port => 5437, user => 'postgres', node => 4, parent => 1);</command>
+</para>
- <programlisting>
- my %PARAMS = (host=> undef, # nom de l'hôte
+<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
+ node => undef, # numéro du nœud
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 ?
+ parent => 1, # l'identifiant du nœud père
+ noforward => undef # ce nœud 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>
- <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>
- <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>
+<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>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>
+ La variable d'environnement UNIX <envar>SLONYSET</envar> est utilisée pour
+ déterminer le fichier de configuration à lire pour connaître les objets qui
+ sont contenus dans un ensemble donné.
+</para>
- </sect3>
- <sect3><title>slonik_build_env</title>
- <indexterm><primary>slonik_build_env</primary></indexterm>
+<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 ensembles de réplication.
+</para>
- <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>
+</sect3>
- <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>
+<sect3>
+<title>slonik_build_env</title>
+<indexterm><primary>slonik_build_env</primary></indexterm>
- <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 interroge la base de données et produit un résultat qui peut
+ être utilisé dans <filename>slon_tools.conf</filename>, notamment :
+</para>
- <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>
+<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 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>
+</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>
+<title>slonik_print_preamble</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 simplement le <quote>préambule</quote> qui est
+ nécessaire à chaque script slonik. En fait, elle fournit un
+ <quote>squelette</quote> de script slonik qui ne fait pas d'action
+ particulière.
+</para>
- <sect3><title>slonik_merge_sets</title>
- <para>Cette commande produit un script Slonik qui fusionne deux ensembles de réplication.
- </para>
- </sect3>
+</sect3>
+
+<sect3>
+<title>slonik_create_set</title>
+
+<para>
+ Cette commande nécessite que les variables <envar>SLONYSET</envar> et
+ <envar>SLONYNODES</envar> soient 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 un script Slonik qui supprime un nœud 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>
+
+<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 la table
+ <envar>sl_table</envar>).
+</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>
+<title>slonik_failover</title>
+
+<para>
+ Cette commande produit un script qui demande une bascule d'urgence entre un
+ nœud 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 nœuds, les voies de communications et les
+ voies d'écoute.
+</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_move_set</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 qui déplace l'origine d'un ensemble de
+ réplication vers un autre nœud.
+</para>
- <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>
+</sect3>
- <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>réplication_test</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>
+ Ce script vérifie que &slony1; réplique correctement les données.
+</para>
- <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>
+
+<sect3>
+<title>slonik_restart_node</title>
+
+<para>
+ Cette commande produit un script Slonik qui demande le redémarrage d'un
+ nœud. Elle était particulièrement utile avant la version 1.0.5,
+ lorsque les nœuds é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 nœuds
+ 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>
+<title>slon_start</title>
+
+<para>
+ Cette commande démarre le démon slon pour un cluster et un nœud 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 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>slon_watchdog2</title>
+
+<para>
+ Ce script est un chien de garde plus malin ; il surveille un nœud
+ donné et relance le processus slon s'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_store_node</title>
+
+<para>
+ Cette commande ajoute un nœud 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_subscribe_set</title>
+
+<para>
+ Ce script génère un script Slonik script pour abonner un nœud 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_uninstall_nodes</title>
+
+<para>
+ Cette commande parcourt le cluster et supprime le schéma &slony1; sur tous
+ les nœuds. Vous pouvez utiliser 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_unsubscribe_set</title>
+
+<para>
+ Cette commande produit un script Slonik qui désabonne un nœud 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>slonik_update_nodes</title>
+
+<para>
+ Cette commande produit un script Slonik qui incite tous les nœuds
+ à 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 pour parcourir un cluster &slony1; et produire un
+ ensemble de fichiers <filename>slon.conf</filename> qui pourront être
+ utilisés via l'option <command>slon -f slon.conf</command>.
+</para>
- <para> Lorsque toute la configuration est placée dans un fichier pour chaque &lslon;,
+<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>
+ <command>-a</command>, ce qui peut provoquer le crash d'un nœud 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>
+ <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>
- <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>
+ <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>
+ <envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui doit être
+ <quote>parcouru</quote>.
+ </para>
+ </listitem>
+
+ <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>
+ <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 nœud.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Pour chaque <quote>nouveau</quote> nœud qu'il découvre, ce script va
+ créer un nouveau fichier de configuration &lslon;.
+</para>
+
+<warning>
+ <para>
+ Il est important de préciser que ce script présente quelques particularités
+ qu'il faut connaître, mais aucune n'est vraiment surprenante.
+ </para>
+
+ <itemizedlist>
<listitem>
- <para> <envar>SLONYCLUSTER</envar> - le nom du cluster &slony1; qui
- doit être <quote>parcouru</quote>. </para>
+ <para>
+ Le DSN est positionné à la plus petite valeur trouvé pour chaque
+ nœud dans le table <envar>sl_path</envar>. Vous devrez
+ probablement modifier cette valeur.
+ </para>
</listitem>
<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>
+ <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> <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>
+ <para>
+ Si vous exécutez les processus &lslon; sur de multiples nœuds
+ (<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>
- <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>
+ Vérifiez bien les nœuds configurés avant de redémarrer les &lslon;s.
+ </para>
- <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>
+ <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>
- <listitem>
- <para> Plusieurs paramètres sont initialisés avec leur valeur par défaut;
- Vous devrez probablement les réajuster à la main. </para>
- </listitem>
+ <para>
+ D'un autre côté, si vous faites fonctionner un nœud en mode log
+ shipping sur le site distant, l'arrivée d'un &lslon; qui <emphasis>ne
+ collecte pas</emphasis> les logs peut ruiner une semaine complète
+ d'activité.
+ </para>
+ </listitem>
+ </itemizedlist>
+</warning>
- <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>
+ Les fichiers produits par <filename>mkslonconf.sh</filename> sont
+ spécifiquement conçus pour gérer des &lslon;s sur de multiples clusters avec
+ le script décrit dans la section suivante...
+</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>
+<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>
+ <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>
- <itemizedlist>
+ <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>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>
+ <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>
- <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>
+ 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 nœuds.
+ </para>
+ </listitem>
- <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>
+ <listitem>
+ <para>
+ <envar>LOGHOME </envar> indique le répertoire <quote>home</quote> pour le
+ stockage des journaux applicatifs.
+ </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>
+ Ce script ne nécessite pas l'utilisation du gestionnaire de journaux
+ applicatifs d'Apache, sachant que &postgres; version 8 gère lui-même la
+ rotation des journaux applicatifs, il semble inopportun de garder une
+ dépendance à une <quote>technologie</quote> de rotation spécifique.
+ </para>
+ </listitem>
- <listitem>
- <para><envar>LOGHOME </envar> indique le répertoire
- <quote>home</quote> pour le stockage des journaux applicatifs.</para>
+ <listitem>
+ <para>
+ <envar>CLUSTERS</envar> est la liste des clusters &slony1; qui sont
+ gérés.
+ </para>
+ </listitem>
+</itemizedlist>
- <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>
+ En pratique, vous pouvez lancer ce programme toutes les cinq minutes, et il
+ relancera tous les processus &lslon; manquants.
+</para>
- <listitem><para><envar>CLUSTERS</envar> est la liste des clusters &slony1; qui sont gérés.</para>
- </listitem>
-
- </itemizedlist>
-
- <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>
+<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 souhaitez créer un nouveau nœud, 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 nœud 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>
- <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>
+ <listitem>
+ <para>
+ Ces informations sont chargées dans une table temporaire fraîchement
+ créée : <envar>temppayroll</envar>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Les OID 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>
+<sect2>
+<title>slony-cluster-analysis</title>
+<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
+<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>
+ &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>
- <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>
+<itemizedlist>
+ <listitem>
+ <para>
+ Lancement d'une séries de requêtes sur les tables &slony1; pour obtenir
+ la liste des nœuds, 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> Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux plans : </para>
+<para>
+ Il existe un 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>
- <itemizedlist>
+<para>
+ Ceci devrait simplifier la taches des administrateurs ("DBA") sur deux
+ plans :
+</para>
- <listitem><para> La documentation de l'état courant du système.</para>
- </listitem>
+<itemizedlist>
- <listitem><para> La surveillance des changements de configuration. </para></listitem>
- </itemizedlist>
+ <listitem>
+ <para>la documentation de l'état courant du système </para>
+ </listitem>
+ <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>
+<sect2 id="configurereplication">
+<title>Génération de scripts slonik avec <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>Nom du cluster Slony-I</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>NUMNODES</envar></term>
+ <listitem><para>Nombre de nœuds à configurer</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>PGUSER</envar></term>
+ <listitem><para>Nom du super-utilisateur qui contrôle la réplication</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>PGPORT</envar></term>
+ <listitem><para>Numéro du port par défaut</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>PGDATABASE</envar></term>
+ <listitem><para>Nom de la base de données par défaut</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>TABLES</envar></term>
+ <listitem>
+ <para>
+ Liste de noms complets de tables (<emphasis>par exemple</emphasis> - un
+ nom incluant le schéma tel que <command>public.ma_table</command>)
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><envar>SEQUENCES</envar></term>
+ <listitem>
+ <para>
+ Liste de noms complets de séquences (<emphasis>par exemple</emphasis>
+ - un nom incluant le schéma tel que <command>public.ma_sequence</command>)
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
- <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>
+<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>
- <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>
+</sect3>
- <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>
+<sect3>
+<title>Valeur spécifique à un nœud</title>
- </variablelist>
+<para>
+ Pour chaque nœ, il y a également quatre variables d'environnement ;
+ pour le nœud 1 :
+</para>
- <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>
+<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>
- <sect3><title>Valeur spécifique à un noeud</title>
+<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>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>
+ 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> 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>
+</sect3>
- <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>
+<title>Les scripts slonik générés</title>
- </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>
+<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>
- <itemizedlist>
+<itemizedlist>
+ <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>preamble.slonik</filename> est un fichier
- <quote>préambule</quote> contenant les informations de connexion utilisées
- par les autres scripts.</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> 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>create_set.slonik</filename>
+ </para>
- <listitem><para> <filename>create_set.slonik</filename></para>
+ <para>
+ Ce script est le premier qu'il faut lancer ; il configure les
+ nœuds spécifiés en nœud &slony1;, en y ajoutant les tables
+ et les autres objets spécifiques de &slony1;.
+ </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>
+ Vous pouvez/devez lancer les processus slon juste après cette étape.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>store_paths.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>
+ Le second script à exécuter ; il indique comment les &lslon;
+ doivent communiquer entre eux. Ce script suppose que tous les &lslon;
+ peuvent parler à tous les nœuds, ce qui n'est peut-être pas exact
+ dans un environnement peuplé de pare-feu complexes. Si cette supposition
+ n'est pas correcte, vous devez modifier ce script pour corriger les voies
+ de communications.
+ </para>
+ </listitem>
- <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>
-
- <listitem>
- <para><filename>create_set.slonik</filename></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>
+ Ce script configure l'ensemble de réplication composé de toutes les
+ tables et les séquences présentes 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>
+ Lorsque vous lancez ce script, la seule action menée est l'ajout de
+ triggers sur le nœud origine (nœud #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>
+ <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>
+ <itemizedlist>
<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>
+ 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 la 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écessitent 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>
- </sect3>
-</sect2>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>subscribe_set_2.slonik</filename>
+ </para>
-<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>
+ <para>
+ et 3, 4, 5, si vous configurez d'autres nœuds...
+ </para>
+
+ <para>
+ Ceci est l'étape qui <quote>déclenche</quote> la réplication.
+ </para>
- <indexterm><primary> profiles dans le style d'Apache pour FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm>
+ <para>
+ Ce script fait la supposition que tous les nœuds abonnés voudront
+ s'abonner directement au nœud origine. Si vous souhaitez mettre en
+ place des <quote>sous-clusters</quote> avec peut-être un nœud
+ maître dans chaque centre de données, vous devez modifier ces scripts.
+ </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>
+ <para>
+ Les processus slon doivent fonctionner au moment où vous réalisez 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>
+<indexterm>
+ <primary>profiles dans le style d'Apache pour FreeBSD</primary>
+ <secondary>FreeBSD</secondary>
+</indexterm>
-<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>
+<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 le système des
+ ports de FreeBSD.
+</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> 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>
+</sect2>
- <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>
+<sect2 id="duplicate-node">
+<title><filename>duplicate-node.sh</filename></title>
+<indexterm><primary>dupliquer un nœud</primary></indexterm>
- <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>
+<para>
+ Dans le répertoire <filename>tools</filename>, le script
+ <filename>duplicate-node.sh</filename> aide à créer un nouveau nœud
+ en dupliquant un des nœuds 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 nœud ;</para></listitem>
+ <listitem><para>le nœud origine ;</para></listitem>
+ <listitem><para>le nœud répliqué ;</para></listitem>
+ <listitem><para>le nouveau nœud ;</para></listitem>
+</itemizedlist>
+
+<para>
+ Pour chaque nœud spécifié, le script 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'elles ne sont pas définies, 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 nœud.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para><filename>schema.sql</filename></para>
+ <para>
+ Ce script est tiré du nœud 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>preambule</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 nœud.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>step2-storepath.slonik</filename></para>
+ <para>
+ Un script &lslonik; qui met en place des voies de communication entre
+ le nœud fournisseur et le nouveau nœud.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><filename>step3-subscribe-sets.slonik</filename></para>
+ <para>
+ Un script &lslonik; qui demande la souscription à tous les ensembles de
+ réplication.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+ Lorsque l'on effectue un test, cela est suffisant pour faire fonctionner un
+ nouveau nœud. 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 nœud doit être un
+ nœud 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>
Modified: traduc/trunk/slony/bestpractices.xml
===================================================================
--- traduc/trunk/slony/bestpractices.xml 2009-02-16 23:34:31 UTC (rev 1240)
+++ traduc/trunk/slony/bestpractices.xml 2009-02-17 18:39:33 UTC (rev 1241)
@@ -5,660 +5,925 @@
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
- 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>
+<title><quote>Bonnes Pratiques</quote> avec &slony1;</title>
+<indexterm><primary>bonnes pratiques pour utiliser &slony1;</primary></indexterm>
- <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 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 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>
+<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>pas</emphasis> ses propres règles pour des
+ points tels que les <link linkend="failover">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> 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>
+ Il y a, toutefois, un certain nombre de découvertes des pionniers de &slony1;
+ qui peuvent au moins aider à concevoir le genre de règles d'administration
+ que vous pourriez mettre en place.
+</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>
+<itemizedlist>
+ <listitem>
+ <para>
+ &slony1; est un 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> 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>
+ 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> 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>
+ De nombreux utilisateurs ont rapporté des problèmes provenants
+ d'incompatibilités entre les versions de &slony1;, les bibliothèques
+ locales et les bibliothèques 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> 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,
+ <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>
+
+ <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>
+ 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écutez <xref linkend="stmtstorepath"/> plusieurs fois,
cela mettra plusieurs fois la même valeur dans la table
- <envar>sl_path</envar>. </para>
+ <envar>sl_path</envar>.
+ </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>
+ Au contraire, <xref linkend="stmtsubscribeset"/> se comporte de deux
+ manières <emphasis>très</emphasis> différentes selon que 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>
- <listitem>
- <para> Principe: Utilisez un zone de temps ("timezone") stable et non-ambigüe
- tel que UTC ou GMT.</para>
+ <listitem>
+ <para>
+ Principe : utilisez un fuseau horaire stable et non-ambigüe tel que
+ UTC ou GMT.
+ </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>
+ Les utilisateurs ont rencontrés des problèmes pour faire fonctionner
+ &lslon; correctement lorsque leur système utilisait un fuseau horaire
+ que &postgres; ne pouvait pas reconnaître tel que CUT0 ou WST. Il est
+ nécessaire que vous utilisiez un fuseau horaire que &postgres; reconnaît
+ correctement. De plus, il est préférable d'utiliser un fuseau qui n'est
+ pas soumis au basculement entre heure d'été et heure d'hiver.
+ </para>
- <para> Le choix <quote>géographiquement neutre</quote> semble être
+ <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>
+ <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> Voir aussi <xref linkend="times"/>.</para>
- </listitem>
+ <para>
+ Voir aussi <xref linkend="times"/>.
+ </para>
+ </listitem>
- <listitem>
- <para> Principe: Les transactions longues c'est mal </para>
+ <listitem>
+ <para>
+ Principe : les transactions longues, c'est mal.
+ </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>
+ <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 nœud
+ <quote>origine</quote> s'accaparant les verrous, rendant inefficace les
+ VACUUM, et ainsi de suite.
+ </para>
- <para> Dans la version 1.2, certains comportement <quote>désagréables</quote> devraient
- être diminués car :</para>
+ <para>
+ Dans la version 1.2, certains comportements <quote>désagréables</quote>
+ devraient être diminués car :
+ </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>
+ <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
+ lignes mortes dans cette table.
+ </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>
- <listitem>
- <para>Les règles de <link linkend="failover"> Bascule en urgence </link>
- devraient être planifiées à l'avance. </para>
+ <listitem>
+ <para>
+ Le système va périodiquement faire un troncage (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>
- <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>
+ <para>
+ Cela peut simplement se résumer à réfléchir à une liste de priorités
+ indiquant 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>
- <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>
+ Chez Afilias, une grande variété de guides internes, 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> <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>
+ <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>
+ La politique de <command>VACUUM</command> doit être définie avec soin.
+ </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>
+ 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>
- <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>
+ <listitem>
+ <para>
+ Si vous utilisez le processus autovacuum 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 des VACUUM dans des conditions de réplication (<emphasis>par
+ exemple</emphasis> : la purge des anciennes données).
+ </para>
- <para> Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus de
- détails. </para>
- </listitem>
+ <para>
+ Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus
+ de détails.
+ </para>
+ </listitem>
+ <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>
- <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>
+ Chaque &lslon; doit être hébergé par hôte sur le même réseau local que
+ le nœud 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> 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>
+ En théorie, les <quote>meilleures</quote> performances sont prévues
+ lorsque l&lslon; fonctionne sur le même serveur que la base qu'il opère.
+ </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>
+ En pratique, déployer les processus &lslon; et leur configuration à
+ travers un réseau d'une douzaine de serveurs se révèle être
+ difficilement gérable.
+ </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 nœud d'origine, afin que la liaison entre
+ eux soit une connexion <quote>locale</quote>. N'établissez
+ <emphasis>pas</emphasis> ce genre de liaison à travers un réseau WAN.
+ </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>
+ 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> 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> Il n'est pas difficile de remédier à cela; Vous devez simplement tuer les
+ <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>
+ 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> 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>
+ 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>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>
+ À 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 tuez 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 (via un ROLLBACK) et lorsque
+ le &lslon; sera relancé, l'évènement sera retraité à partir de zéro.
+ </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>
+ 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> 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>
+ Dans les premières versions de &slony1;, il était fréquent que des
+ connexions soient un peu <quote>dérangées</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 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>
+ <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
+ lorsqu'on souhaite modifier le schéma de la base de données.
+ </para>
+ </listitem>
- <listitem>
- <para> Gestion des clefs primaires </para>
+ <listitem>
+ <para>
+ Gestion des clefs primaires.
+ </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>
+ 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'une vraie contrainte de clef primaire ; il est
+ <emphasis>acceptable</emphasis> d'utiliser une <quote>clef primaire
+ candidate</quote>.
+ </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>
+ 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 bogues dans votre application
+ à cause de &slony1;.
+ </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>
- <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>
+ 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> 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>
+ 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>
- <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>
+ <listitem>
+ <para><link linkend="locking">Problèmes d'inter-blocages</link></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écessitent l'acquisition de <emphasis>verrous exclusifs</emphasis> sur
+ les tables répliquées.
+ </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>
+ 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> 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>Que faire des ordres DDL ?</para>
- <listitem>
- <para> Que faire des ordres DDL ? </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>
+ &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 se font au moyen de méthodes qui ne déclenchent 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>
+ 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éma 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>
+ Cependant, il existe des cas où cela est nécessaire, ainsi <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>
+ <para>
+ Malheureusement, cela provoque de nombreux verrous sur les objets de
+ la base de données. Modifier les tables nécessite l'acquisition d'un
+ verrou exclusif sur ces objets ; ainsi le <command>script
+ d'exécution des modifications</command> entraîne un verrou exclusif sur
+ <emphasis>toutes</emphasis> les tables répliquées. Cela peut s'avérer
+ très problématique lorsque les applications fonctionnent ; des
+ inter-blocages (« deadlocks ») peuvent alors se produire.
+ </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>
+ 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 nœuds restent cohérents. Cependant, le coût des
+ verrous et des inter-blocages est trop élevé pour certains utilisateurs.
+ </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>
+ Chez Afilias, notre approche est moins dogmatique ; il y a
+ <emphasis>certains</emphasis> changements qui <emphasis>doivent</emphasis>
+ être appliqués avec un <command>script d'exécution</command> mais nous
+ appliquons certaines modifications 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>
+ <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>. À
+ 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ée de manière synchronisée avec le
+ <command>script d'exécution</command> qui modifie la table.
+ </para>
- <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>
+ <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 nœuds.
+ </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 inutiles pour &slony1; car
+ ce dernier est exécuté avec les droits de
+ <quote>super-utilisateur</quote>.
+ </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>
+ Dans la pratique, il est utile d'avoir différentes politiques de
+ sécurité sur les nœuds. L'accès au nœud
+ <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 nœud maître que sur les nœuds
+ abonnés.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </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>
+ 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>
+ 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>
+ Par exemple, une série de <command>VACUUM</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 peut entraîner des
+ inter-blocages qui peuvent annuler 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>
+ <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 en autorisant uniquement
+ l'utilisateur slony, ce qui réduit considérablement les risques lors
+ d'une 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écessaires 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>
+ <listitem>
+ <para>Réduction des super-pouvoirs</para>
+
+ <para>
+ Traditionellement, on considère que <quote>&slony1; a besoin de
+ connexions en mode super-utilisateur</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>
+ Il est vrai que chaque &lslon; <emphasis>doit</emphasis> avoir une
+ connexion super-utilisateur afin de gérer le nœud qu'il opère.
+ Il doit pouvoir modifier le catalogue système afin de mettre en place les
+ abonnements 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é sur un nœud 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>
- </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>
+ <para>
+ Toutefois, les connexions que les processus &lslon; ouvrent vers d'autres
+ nœuds afin d'accéder aux événements et aux souscriptions n'ont pas
+ besoin d'avoir d'autant de droits. Ainsi, on peut mettre en place un
+ <quote>utilisateur faible</quote> assigné à toutes les requêtes <xref
+ linkend="stmtstorepath"/>. Les droits minimaux de cet utilisateur,
+ appellons-le <command>weakuser</command>, sont les suivantes :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Il doit avoir accès en lecture sur le schéma 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 schéma ;
+ </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 le niveau d'accès 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 droits définis sont suffisants 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>
+ <para>
+ À partir de 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 nœuds qui
+ n'arrivent 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>
+ <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 :</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>
+ Il s'agit d'un script Perl qui se connecte à un nœud &slony1; puis
+ parcourt la configuration &slony1; à la recherche de différentes
+ conditions qui indiquent 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> 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>
+ 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>
+ À 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ées 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>
+ Cette approche a 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>
+ Malheureusement, si vous invoquez &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 nœuds de log shipping.
+ </para>
+ </listitem>
- <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>
+ <listitem>
+ <para>
+ À la différence des options en ligne de commande, les options
+ actives ne sont <emphasis>pas</emphasis> visibles. Elles peuvent
+ seulement être positionnées à partir du 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'en oublierez aucune,
+ ce qui est plus sûr pour &logshiplink;.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>Taches à faire lorsqu'on abonne un nœud</para>
+
+ <para>
+ Lorsqu'un nouveau nœud 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 nœud pour tous les utilisateurs autres que
+ <command>slony</command> car :
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Les applications s'exécutent sur des données partiellement copiées
+ qui ne seront pas cohérentes.
+ </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 nœud.
+ </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,
-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>
+
+<para>
+ Il <emphasis>peut</emphasis> être intéressant de désactiver la fonctionnalité
+ <function>fsync</function> de &postgres; pendant la 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 une 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>
+ <listitem>
+ <para>Gestion de slonik</para>
+
+ <para>
+ Les notes sur l'<link linkend="usingslonik">utilisation de Slonik</link>
+ décrivent certaines leçons apprises en gérant un grand nombre de scripts
+ <xref linkend="slonik"/>.
+ </para>
+
+ <para>
+ Voici les principes importants 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és maintes fois.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Toute opportunité de générer automatiquement la configuration soit en
+ la récupé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>
- <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>
+ <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 gigaoctets, ce qui
+ ajoute des <quote>contraintes</quote> sur le système, en 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>
- <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>
+ <listitem>
+ <para>
+ Supprimer tous les index autres que les index primaires 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 volée. Ceci
+ est beaucoup plus lent que simplement copier les donnés dans une table
+ puis de recréer chaque 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 ensembles sont
+ copiés, ceci peut mener à un nombre énorme d'événements
+ <command>SYNC</command> sur le nœud 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>
+ 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> par jour, pendant probablement plusieurs jours.
+ </para>
- <para>Parallèlement
- on constatera une croissance <emphasis>énorme</emphasis>
+ <para>
+ Parallèlement, on constate 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>
+ linkend="table.sl-seqlog"/>. Malheureusement, une fois que
+ <command>COPY_SET</command> est terminé, on constate que les requêtes
+ sur ces tables se font via des <command>parcours séquentiels</command>.
+ Même 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 tels cas, il est possible que le nœud
+ abonné ne rattrape jamais le nœud origine.
+ </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>
+ 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 nœud <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érieures à 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
- <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>
+ <para>
+ Dans les versions 1.2 et suivantes, il y a un processus qui ajoute
+ automatiquement les index partiels par numéro de nœud d'origine,
+ ce qui est la forme optimale pour ces index.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Sur un nœud abonné, ajoutez le nombre 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 nœud abonné, réglez le paramètre <xref
+ linkend="slon-config-desired-sync-time"/> à 0 car le système de
+ regroupement adaptatif des <command>SYNC</command> fonctionne 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
+ nœud origine <xref linkend="slon"/> afin que les événements
+ <command>SYNC</command> soient 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 une 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/slonconf.xml
===================================================================
--- traduc/trunk/slony/slonconf.xml 2009-02-16 23:34:31 UTC (rev 1240)
+++ traduc/trunk/slony/slonconf.xml 2009-02-17 18:39:33 UTC (rev 1241)
@@ -8,35 +8,35 @@
<title>Configuration</title>
<indexterm>
<primary>configuration</primary>
- <secondary>du démon slon </secondary>
+ <secondary>du démon slon</secondary>
</indexterm>
<para>
- Il y a plusieurs paramètres de configuration qui affectent le comportement
+ Il existe plusieurs paramètres de configuration qui affectent le comportement
du système de réplication. Dans cette section, nous allons décrire
- comment définir les paramètres de configuration du démon
- <application>slon</application>; La sous-section qui suit détaille
- chaque paramètre :
+ comment définir les paramètres de configuration du démon
+ <application>slon</application> ; La sous-section qui suit détaille
+ chaque paramètre :
</para>
<para>
Tous les noms de paramètres sont sensibles à la casse des lettres.
- Chaque paramètre se voir assigné une valeur de types : booléen,
+ Chaque paramètre se voir assigner un type : booléen,
entier, flottant ou chaîne de caractères. Les valeurs booléennes
peuvent être <literal>ON</literal>, <literal>OFF</literal>,
<literal>FALSE</literal>, <literal>YES</literal>, <literal>NO</literal>,
<literal>1</literal>, <literal>0</literal> (toutes en majuscule) ou
- n'importe quel préfixe non-ambigüe de ces valeurs.
+ n'importe quel préfixe non ambigü de ces valeurs.
</para>
<para>
On spécifie un paramètre par ligne. Le signe égal entre le nom
- et la valeur est optionnel. Les espaces ne sont pas
+ et la valeur est optionnel. Les espaces ne sont pas
significatifs et les lignes vides sont ignorées.
- Le caracière dièse (<literal>#</literal>) permet de placer
+ Le caractère dièse (<literal>#</literal>) permet de placer
un commentaire n'importe où. Les valeurs des paramètres qui ne
sont pas des identifiant ou des nombres doivent être encadrées
- par des simples quotes.
+ par des guillemets simples.
</para>
<para>
@@ -53,14 +53,14 @@
<term>
<varname>syslog</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration de<varname>syslog</varname></primary>
+ <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
+ <para>Active les traces avec syslog. Si le paramètre vaut 1, les messages vont
+ à la fois vers syslog 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 des erreurs. Par défaut, ce paramètre
est à 0, ce qui signifie que syslog est désactivé.</para>
</listitem>
</varlistentry>
@@ -72,8 +72,8 @@
</indexterm>
</term>
<listitem>
- <para>Positionne la <quote>facility</quote> que syslog devra utiliser
- Les valeurs valides sont LOCAL0, LOCAL1, LOCAL2,
+ <para>Positionne la <quote>facility</quote> que syslog devra utiliser.
+ Les valeurs valides sont LOCAL0, LOCAL1, LOCAL2,
LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. La valeur par défaut est
LOCAL0.</para>
</listitem>
@@ -87,7 +87,7 @@
</indexterm>
</term>
<listitem>
- <para>Définit le nom du programme utilisé pour identifié les messages slon
+ <para>Définit le nom du programme utilisé pour identifier les messages slon
dans syslog. La valeur par défaut est slon.</para>
</listitem>
</varlistentry>
@@ -100,18 +100,19 @@
</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>
+ <para>Niveau de traces de débogage (plus la valeur est haute, plus les
+ messages sont verbeux).
+ 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.
+ <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> peut être désactivé.
Avec &slony1; version 2, beaucoup de niveaux de message ont
- été révisé afin que des <quote>trucs intéressants</quote>
+ été révisé afin que des <quote>informations intéressantes</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>
+ utiles dans les journaux applicatifs.</para>
</listitem>
</varlistentry>
@@ -123,8 +124,8 @@
</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>
+ <para>Détermine si le PID du processus père slon
+ doit apparaître dans chaque ligne du journal applicatif.</para>
</listitem>
</varlistentry>
@@ -136,8 +137,8 @@
</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>
+ <para>Détermine si l'horodatage de chaque événement doit
+ apparaître dans chaque ligne du journal applicatif.</para>
</listitem>
</varlistentry>
@@ -165,7 +166,7 @@
<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>
+ pas définie, ce qui implique qu'aucun fichier n'est écrit.</para>
</listitem>
</varlistentry>
</variablelist>
@@ -185,7 +186,7 @@
<para>
Définit le nom du cluster que l'instance de
<application>slon</application> doit gérer.
- Par défaut cette valeur est obtenue en ligne de commande.
+ Par défaut, cette valeur est obtenue en ligne de commande.
</para>
</listitem>
</varlistentry>
@@ -198,8 +199,8 @@
</term>
<listitem>
<para>
- Définit les informations de connexion pour <application>slon</application>;
- Par défaut cette valeur est obtenue en ligne de commande.
+ Définit les informations de connexion pour <application>slon</application>.
+ Par défaut, cette valeur est obtenue en ligne de commande.
</para>
</listitem>
</varlistentry>
@@ -212,7 +213,7 @@
</term>
<listitem>
<para>
- Exécute cette requête SQL sur chaque noeud lorsque
+ Exécute cette requête SQL sur chaque nœud lorsque
<application>slon</application> s'y connecte. Utile pour
définir un niveau de trace, ou pour configurer les
paramètres du planificateur ou de la mémoire.
@@ -225,7 +226,7 @@
</variablelist>
</sect1>
<sect1 id="slon-archive-logging">
- <title> Options d'archivage </title>
+ <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>)
@@ -234,7 +235,7 @@
</indexterm>
</term>
<listitem>
- <para>Ceci indique dans quel répertoire les fichiers d'archivages des syncs doivent
+ <para>Ceci indique dans quel répertoire les fichiers d'archivages des SYNC doivent
être stockés.
</para>
</listitem>
@@ -247,12 +248,12 @@
</indexterm>
</term>
<listitem>
- <para>Ceci définit une commande Unix qui sera lancé à
+ <para>Ce paramètre définit une commande Unix qui sera exécutée à
chaque fois qu'un fichier d'archive est produit.
</para>
- <para> Un paramètre sera passé à cette commande : le chemin absolu du fichier d'archive.
- Ainsi si on imagine la configuration suivante :
+ <para>Un paramètre est passé à cette commande : le chemin absolu
+ du fichier d'archive. Ainsi, si on imagine la configuration suivante :
</para>
<para>
@@ -262,20 +263,20 @@
<command>archive_dir = <filename>/var/log/slony1/archivelogs/payroll</filename></command>
</para>
- <para> Un fichier de d'archive sera nommé de cette façon :
+ <para>Un fichier de d'archive sera nommé de cette façon :
<filename>/var/log/slony1/archivelogs/payroll/slony1_log_1_00000000000000000036.sql</filename></para>
- <para> La commande exécutée après que le SYNC soit généré sera : </para>
+ <para>La commande exécutée après que le SYNC soit généré est :</para>
<para>
<command><filename>/usr/local/bin/logstuff</filename> <filename>/var/log/slony1/archivelogs/payroll/slony1_log_1_00000000000000000036.sql</filename></command>
</para>
- <warning> <para> Notons que cette commande est lancée avec la fonction
- <function>system(const char *COMMAND)</function>; si le programme
- exécuté dure 5 minutes, cela retardera le prochain
+ <warning><para>Notons que cette commande est lancée avec la fonction
+ <function>system(const char *COMMAND)</function> ; si le programme
+ exécuté dure 5 minutes, cela retardera le prochain
<command>SYNC</command> de cinq minutes. Vous devez vous assurer
- que la commande d'archivage ne fait des choses trop
+ que la commande d'archivage ne fait pas de choses trop
<quote>compliquées</quote>.</para></warning>
</listitem>
@@ -294,7 +295,7 @@
</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.
+ Valeurs possibles : de 10 à 60000, La valeur par défaut est 100.
</para>
</listitem>
</varlistentry>
@@ -307,24 +308,24 @@
</term>
<listitem>
<para>
- Délai maximal, en millisecondes,avant qu'un événements
+ Délai maximal, en millisecondes, avant qu'un événement
<command>SYNC</command> soit déclenché. Ceci évite les
- situation de compétition ( "race conditions" ) lorsqu'une
- séquence d'actions est lancé par un trigger alors que des
- tuples très longs sont insérés, ce qui fait que la séquence d'action
+ situations de compétition (« race conditions ») lorsqu'une
+ séquence d'actions est lancée par un trigger alors que des
+ lignes très longues sont insérées, ce qui fait que la séquence d'action
est immédiatement visible pour le processus de synchronisation
- alors que les lignes insérées ne sont pas encore visible.
+ alors que les lignes insérées ne sont pas encore visibles.
Si l'événement <command>SYNC</command> est attrapé
- par un noeud abonné, puis traité et terminé avant que la
- transaction ne soit committée, les changements de cette
- transaction ne seront pas répliqués avant le
- <command>SYNC</command> suivant. Cependant si
+ par un nœud abonné, puis traité et terminé avant que la
+ transaction ne soit validée, les changements de cette
+ transaction ne seront pas répliqués avant le
+ <command>SYNC</command> suivant. Cependant, si
toutes les applications s'arrêtent soudainement, il n'y
aura plus de séquence d'actions, et les vérifications
- fréquente avec <option>-s</option> n'y feront rien.
- Ainsi il est nécessaire d'avoir un paramètre
+ fréquentes avec <option>-s</option> n'y feront rien.
+ Ainsi, il est nécessaire d'avoir un paramètre
<envar>sync_interval_timeout</envar>.
- Valeurs possibles : [0-120000], valeur par défaut 1000
+ Valeurs possibles : [0-120000]. Valeur par défaut : 1000.
</para>
</listitem>
</varlistentry>
@@ -332,20 +333,20 @@
<varlistentry id="slon-config-sync-group-maxsize" xreflabel="slon_conf_sync_group_maxsize">
<term><varname>sync_group_maxsize</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>sync_group_maxsize</varname></primary>
+ <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
- ensemble lorsqu'un noeud abonné tombe en panne.
+ ensemble lorsqu'un nœud abonné tombe en panne.
Les événements <command>SYNC</command>s ne sont empaquetés
- que si ils ont nombreux et qu'ils sont contiguës.
+ que s'ils sont nombreux et qu'ils sont contiguës.
S'il n'y qu'un seul événement <command>SYNC</command> disponible,
même l'option <option>-g60</option> s'appliquera à cet évènement unique.
- Dès qu'un noeud abonné rattrape son retard, il appliquera chaque événement
- <command>SYNC</command> individuellement.
- Valeurs possibles : [0,10000], valeur par défaut : 20
+ Dès qu'un nœud abonné rattrape son retard, il appliquera chaque événement
+ <command>SYNC</command> individuellement.
+ Valeurs possibles : [0,10000]. Valeur par défaut : 20.
</para>
</listitem>
</varlistentry>
@@ -353,15 +354,15 @@
<varlistentry id="slon-config-vac-frequency" xreflabel="slon_conf_vac_frequency">
<term><varname>vac_frequency</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>vac_frequency</varname></primary>
+ <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
- vacuum soit exécutés. O désactive les vacuums interne, utilisé
- avec le démon <application>pg_autovacuum</application>.
- Valeurs possibles : [0,100], valeur par défaut: 3
+ Définit le nombre de cycles de nettoyage lancés avant qu'un
+ VACUUM ne soit exécuté. O désactive les VACUUM internes, utilisés
+ avec le démon <application>pg_autovacuum</application>.
+ Valeurs possibles : [0,100]. Valeur par défaut : 3.
</para>
</listitem>
</varlistentry>
@@ -369,15 +370,15 @@
<varlistentry id="slon-config-cleanup-interval" xreflabel="slon_config_cleanup_interval">
<term><varname>cleanup_interval</varname> (<type>interval</type>)
<indexterm>
- <primary>paramètre de configuration<varname>cleanup_interval</varname></primary>
+ <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.
- En corollaire cela contrôle le nettoyage des tables
+ En corollaire, cela contrôle le nettoyage des tables
<envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
- Valeur par défaut: '10 minutes'.
+ Valeur par défaut : '10 minutes'.
</para>
</listitem>
</varlistentry>
@@ -385,14 +386,14 @@
<varlistentry id="slon-config-cleanup-deletelogs" xreflabel="slon_conf_cleanup_deletelogs">
<term><varname>cleanup_deletelogs</varname> (<type>booléen</type>)
<indexterm>
- <primary>paramètre de configuration<varname>cleanup_deletelogs</varname></primary>
+ <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
à l'intérieur des tables <envar>sl_log_1</envar> et <envar>sl_log_2</envar>.
- Valeur par défaut: false
+ Valeur par défaut : false.
</para>
</listitem>
</varlistentry>
@@ -400,15 +401,15 @@
<varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
<term><varname>desired_sync_time</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>desired_sync_time</varname></primary>
+ <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,
+ <command>SYNC</command>. Si la réplication est en retard,
<application>slon</application> essaie d'augmenter le nombre
- de syncs en évaluant le temps d'exécution qu'ils auraient du prendre.
- Valeurs possibles : [10000,600000] ms, Valeur par défaut : 60000. </para>
+ de SYNC en évaluant le temps d'exécution qu'ils auraient du prendre.
+ Valeurs possibles : [10000,600000] ms. Valeur par défaut : 60000.</para>
<para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
</listitem>
@@ -417,13 +418,13 @@
<varlistentry id="slon-config-quit-sync-provider" xreflabel="quit_sync_provider">
<term><varname>quit_sync_provider</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>quit_sync_provider</varname></primary>
+ <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
- quel processus du noeud fournisseur devrait être surveiller pour
+ <para>Ce paramètre doit être utilisé conjointement avec <xref
+ linkend="slon-config-quit-sync-finalsync"/>. Il indique
+ le processus du nœud fournisseur à surveiller pour
savoir si le slon doit s'arrêter après avoir atteint le numéro d'un
événement <quote>final</quote>.</para>
@@ -433,42 +434,42 @@
<varlistentry id="slon-config-quit-sync-finalsync" xreflabel="quit_sync_finalsync">
<term><varname>quit_sync_finalsync</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>quit_sync_finalsync</varname></primary>
+ <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"/>,
et permet à <application>slon</application> de s'arrêter lorsqu'il atteint
- un certain événements sur du noeud fournisseur.</para>
+ un certain événement sur le nœud fournisseur.</para>
- <para>Si cette valeur est à 0, alors ce mécanisme est désactivé. </para>
+ <para>Si cette valeur est à 0, alors ce mécanisme est désactivé.</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-lag-interval" xreflabel="lag_interval">
<term><varname>lag_interval</varname> (<type>chaîne/interval</type>)
<indexterm>
- <primary>paramètre de configuration<varname>lag_interval</varname></primary>
+ <primary>paramètre de configuration <varname>lag_interval</varname></primary>
</indexterm>
</term>
<listitem>
- <para>Indiques un intervalle à partir duquel le noeud
+ <para>Indique un intervalle à partir duquel le nœud
est en décalage avec son fournisseur. Si cette valeur est définie,
elle est utilisée dans la boucle de gestion des événements
- afin de modifier la priorité des événements dans la file d'attente;
- les événements plus récents que <command> now() - lag_interval::interval
- </command> sont laissés de côté, afin d'être traités plus tard. </para>
+ afin de modifier la priorité des événements dans la file d'attente ;
+ les événements plus récents que <command>now() -
+ lag_interval::interval</command> sont laissés de côté afin d'être
+ traités plus tard.</para>
- <para>Si cette valeur est vide, alors ce mécanisme est désactivé.
- </para>
+ <para>Si cette valeur est vide, alors ce mécanisme est désactivé.</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-max-rowsize" xreflabel="sync_max_rowsize">
- <term><varname>sync_max_rowsize</varname> (<type>entier</type>)
+ <term><varname>sync_max_rowsize</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>sync_max_rowsize</varname></primary>
+ <primary>paramètre de configuration <varname>sync_max_rowsize</varname></primary>
</indexterm>
</term>
<listitem>
@@ -476,13 +477,12 @@
table sl_log_? est considéré comme volumineux.
Jusqu'à 500 lignes de cette taille sont autorisées en mémoire à
un instant t. Les lignes plus larges sont comptées dans l'espace
- d'allocation <envar>sync_max_largemem</envar> et libéré à la demande ( avec
- la fonction <function>free()</function> ).
+ d'allocation <envar>sync_max_largemem</envar> et libérées à la demande (avec
+ la fonction <function>free()</function>).
</para>
<para>La valeur par défaut est 8192, ce qui signifie que la consommation
- mémoire (pour le curseur de LOG) ne doit pas dépasser 8MB.
-
+ mémoire (pour le curseur de LOG) ne doit pas dépasser 8 Mo.
</para>
</listitem>
</varlistentry>
@@ -490,33 +490,33 @@
<varlistentry id="slon-config-max-largemem" xreflabel="sync_max_largemem">
<term><varname>sync_max_largemem</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>sync_max_largemem</varname></primary>
+ <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
+ <para>Taille maximum de la mémoire allouée pour les lignes volumineuses
quand <envar>log_cmddata</envar> est plus grand que
- <envar>sync_max_rowsize</envar>. </para>
+ <envar>sync_max_rowsize</envar>.</para>
<para>Notez que l'algorithme lit les lignes jusqu'à ce que la valeur soit
- <emphasis>dépassée</emphasis>. Sinon, un tuple plus large que cette valeur bloquerait la
- réplication. En conséquence, ne prévoyez pas que la consommation mémoire restera
+ <emphasis>dépassée</emphasis>. Sinon, une ligne plus large que cette valeur bloquerait la
+ réplication. En conséquence, ne supposez pas que la consommation mémoire restera
inférieure à cette valeur.
</para>
- <para> La valeur par défaut est 5242880.</para>
+ <para>La valeur par défaut est 5242880.</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-remote-listen-timeout" xreflabel="slon_conf_remote_listen_timeout">
<term><varname>remote_listen_timeout</varname> (<type>entier</type>)
<indexterm>
- <primary>paramètre de configuration<varname>remote_listen_timeout</varname></primary>
+ <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é.
- Valeurs possibles : [30-30000], valeur par défaut : 300
+ <para>Durée que le processus d'écoute distant doit attendre avant
+ de considérer qu'un événement est périmé.
+ Valeurs possibles : [30-30000]. Valeur par défaut : 300.
</para>
</listitem>
</varlistentry>
More information about the Trad
mailing list