[Trad] [svn:pgfr] r1334 - traduc/branches/slony_1_2
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Ven 29 Mai 16:12:20 CEST 2009
Author: gleu
Date: 2009-05-29 16:12:20 +0200 (Fri, 29 May 2009)
New Revision: 1334
Modified:
traduc/branches/slony_1_2/addthings.xml
traduc/branches/slony_1_2/adminscripts.xml
traduc/branches/slony_1_2/bestpractices.xml
traduc/branches/slony_1_2/cluster.xml
traduc/branches/slony_1_2/defineset.xml
traduc/branches/slony_1_2/dropthings.xml
traduc/branches/slony_1_2/failover.xml
traduc/branches/slony_1_2/firstdb.xml
traduc/branches/slony_1_2/help.xml
traduc/branches/slony_1_2/installation.xml
traduc/branches/slony_1_2/locking.xml
traduc/branches/slony_1_2/loganalysis.xml
traduc/branches/slony_1_2/logshipping.xml
traduc/branches/slony_1_2/maintenance.xml
traduc/branches/slony_1_2/monitoring.xml
traduc/branches/slony_1_2/prerequisites.xml
traduc/branches/slony_1_2/releasechecklist.xml
traduc/branches/slony_1_2/reshape.xml
traduc/branches/slony_1_2/slon.xml
traduc/branches/slony_1_2/slonconf.xml
traduc/branches/slony_1_2/slonik_ref.xml
traduc/branches/slony_1_2/slonyupgrade.xml
traduc/branches/slony_1_2/testbed.xml
traduc/branches/slony_1_2/versionupgrade.xml
Log:
Mise ?\195?\160 jour Slony 1.2.16.
Modified: traduc/branches/slony_1_2/addthings.xml
===================================================================
--- traduc/branches/slony_1_2/addthings.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/addthings.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -339,10 +339,10 @@
<note>
<para>
- In &slony1; version 2.0, <xref linkend="stmttableaddkey"/> is
- <emphasis>no longer supported</emphasis>, and thus <xref
- linkend="stmtuninstallnode"/> consists very simply of
- <command>DROP SCHEMA "_ClusterName" CASCADE;</command>.
+ Dans &slony1; 2.0, <xref linkend="stmttableaddkey"/> n'est
+ <emphasis>plus supporté</emphasis> et, du coup, <xref
+ linkend="stmtuninstallnode"/> consiste très simplement en des commandes
+ <command>DROP SCHEMA "Nom_du_cluster" CASCADE;</command>.
</para>
</note>
</listitem>
Modified: traduc/branches/slony_1_2/adminscripts.xml
===================================================================
--- traduc/branches/slony_1_2/adminscripts.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/adminscripts.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -215,16 +215,15 @@
</para>
<para>
- This represents a pretty big potential <quote>foot gun</quote>
- as this eliminates a replication set all at once. A typo that points
- it to the wrong set could be rather damaging. Compare to <xref
- linkend="slonik-unsubscribe-set"/> and <xref
- linkend="slonik-drop-node"/>; with both of those, attempting to drop a
- subscription or a node that is vital to your operations will be
- blocked (via a foreign key constraint violation) if there exists a
- downstream subscriber that would be adversely affected. In contrast,
- there will be no warnings or errors if you drop a set; the set will
- simply disappear from replication.
+ Ceci représente un risque potentiellement très dangereux car cela élimine
+ un ensemble de réplication complet en une commande. Une erreur de saisie qui
+ indiquerait un mauvais ensemble serait dévastateur. À comparer avec <xref
+ linkend="slonik-unsubscribe-set"/> et <xref linkend="slonik-drop-node"/> ;
+ avec ces deux-là, tenter de supprimer un abonnement ou un nœud vital à
+ vos opérations sera bloqué (via une constrainte de clé étrangère) s'il existe
+ un abonné qui pourrait être affecté. En contraste, il n'y aura pas de
+ messages d'avertissements ou d'erreurs si vous supprimez un ensemble ;
+ l'ensemble disparaitra tout simplement de la réplication.
</para>
</sect3>
@@ -576,46 +575,135 @@
</sect2>
-<sect2 id="startslon"> <title>start_slon.sh</title>
+<sect2 id="startslon">
+<title>start_slon.sh</title>
-<para> This <filename>rc.d</filename>-style script was introduced in
-&slony1; version 2.0; it provides automatable ways of:</para>
+<para>
+ Ce script du style <filename>rc.d</filename> est disponible à partir de la
+ version 2.0 de &slony1; ; il fournit un moyen automatique de :
+</para>
<itemizedlist>
-<listitem><para>Starting the &lslon;, via <command> start_slon.sh start </command> </para> </listitem>
+ <listitem>
+ <para>
+ Démarrer &lslon;, via la commande <command>start_slon.sh start</command>
+ </para>
+ </listitem>
</itemizedlist>
-<para> Attempts to start the &lslon;, checking first to verify that it
-is not already running, that configuration exists, and that the log
-file location is writable. Failure cases include:</para>
+<para>
+ Il essaie de démarrer &lslon;, en vérifiant au préalable qu'il n'est pas
+ déjà en cours d'exécution, que la configuration existe et qu'il dispose des
+ droits pour écrire sur le journal applicatif associé. Voici les échecs
+ possibles :
+</para>
+
<itemizedlist>
-<listitem><para> No <link linkend="runtime-config"> slon runtime configuration file </link> exists, </para></listitem>
-<listitem><para> A &lslon; is found with the PID indicated via the runtime configuration, </para></listitem>
-<listitem><para> The specified <envar>SLON_LOG</envar> location is not writable. </para></listitem>
-<listitem><para>Stopping the &lslon;, via <command> start_slon.sh stop </command> </para>
-<para> This fails (doing nothing) if the PID (indicated via the runtime configuration file) does not exist; </para> </listitem>
-<listitem><para>Monitoring the status of the &lslon;, via <command> start_slon.sh status </command> </para>
-<para> This indicates whether or not the &lslon; is running, and, if so, prints out the process ID. </para> </listitem>
-
+ <listitem>
+ <para>
+ Il n'y a pas de <link linkend="runtime-config">fichier de configuration
+ slon</link>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Un processus &lslon; est trouvé avec le PID indiqué via la configuration.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ L'emplacement spécifié via <envar>SLON_LOG</envar> n'est pas disponible en
+ écriture.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Arrêt du &lslon;, via <command>start_slon.sh stop</command>
+ </para>
+
+ <para>
+ Ceci échoue (ne fait rien) si le PID (indiqué via le fichier de
+ configuration) n'existe pas.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Surveiller le statut de &lslon;, via <command>start_slon.sh status</command>
+ </para>
+
+ <para>
+ Ceci indique si le processus &lslon; est en cours d'exécution et, dans ce
+ cas, affiche l'identifiant du processus.
+ </para>
+ </listitem>
</itemizedlist>
-<para> The following environment variables are used to control &lslon; configuration:</para>
+<para>
+ Les variables d'environnement suivantes sont utilisées pour contrôler la
+ configuration de &lslon; :
+</para>
<glosslist>
-<glossentry><glossterm> <envar> SLON_BIN_PATH </envar> </glossterm>
-<glossdef><para> This indicates where the &lslon; binary program is found. </para> </glossdef> </glossentry>
-<glossentry><glossterm> <envar> SLON_CONF </envar> </glossterm>
-<glossdef><para> This indicates the location of the <link linkend="runtime-config"> slon runtime configuration file </link> that controls how the &lslon; behaves. </para>
-<para> Note that this file is <emphasis>required</emphasis> to contain a value for <link linkend="slon-config-logging-pid-file">log_pid_file</link>; that is necessary to allow this script to detect whether the &lslon; is running or not. </para>
-</glossdef> </glossentry>
-<glossentry><glossterm> <envar> SLON_LOG </envar> </glossterm>
-<glossdef><para> This file is the location where &lslon; log files are to be stored, if need be. There is an option <xref linkend ="slon-config-logging-syslog"/> for &lslon; to use <application>syslog</application> to manage logging; in that case, you may prefer to set <envar>SLON_LOG</envar> to <filename>/dev/null</filename>. </para> </glossdef> </glossentry>
+ <glossentry>
+ <glossterm>
+ <envar>SLON_BIN_PATH</envar>
+ </glossterm>
+
+ <glossdef>
+ <para>
+ Ceci indique où trouver le programme &lslon;.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>
+ <envar>SLON_CONF</envar>
+ </glossterm>
+
+ <glossdef>
+ <para>
+ Ceci indique l'emplacement du <link linkend="runtime-config">fichier
+ de configuration slon</link> contrôlant le comportement de &lslon;.
+ </para>
+
+ <para>
+ Notez que ce fichier <emphasis>doit</emphasis> contenir la valeur de
+ l'option <link linkend="slon-config-logging-pid-file">log_pid_file</link> ;
+ c'est nécessaire pour permettre à ce script de détecter si &lslon; est
+ en cours d'exécution.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry>
+ <glossterm>
+ <envar>SLON_LOG</envar>
+ </glossterm>
+
+ <glossdef>
+ <para>
+ Cette option indique l'emplacement où les journaux applicatifs de &lslon;
+ sont stockés. Il existe une option <xref
+ linkend ="slon-config-logging-syslog"/> pour que &lslon; utilise
+ <application>syslog</application> pour gérer ses journaux
+ applicatifs ; dans ce cas, vous pouvez configurer
+ <envar>SLON_LOG</envar> à <filename>/dev/null</filename>.
+ </para>
+ </glossdef>
+ </glossentry>
</glosslist>
-<para> Note that these environment variables may either be set, in the
-script, or overridden by values passed in from the environment. The
-latter usage makes it easy to use this script in conjunction with the
-<xref linkend="testbed"/> so that it is regularly tested. </para>
+<para>
+ Notez que ces variables d'environnement peuvent être configurées soit dans le
+ script soit dans les valeurs passées dans l'environnement. Ce dernier rend
+ l'utilisation de ce script plus simple lorsqu'il combine <xref linkend="testbed"/>
+ pour être régulièrement testé.
+</para>
</sect2>
@@ -625,10 +713,10 @@
<para>
Voici un autre script shell qui utilise la configuration produite par
- <filename>mkslonconf.sh</filename> et qui a pour but de support an
- approach to running &slony1; involving regularly
- (<emphasis>e.g.</emphasis> via a cron process) checking to ensure that
- &lslon; processes are running.
+ <filename>mkslonconf.sh</filename> et qui a pour but de supporter une
+ approche sur l'exécution de &slony1; consistant à vérifier régulièrement
+ (<emphasis>c'est-à-dire</emphasis> avec un cron) que les processus &lslon;
+ sont en cours d'exécution.
</para>
<para>
@@ -1121,9 +1209,11 @@
<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>
-<indexterm><primary> Apache-style profiles for FreeBSD </primary> <secondary>FreeBSD </secondary> </indexterm>
-
<para>
Dans le répertoire <filename>tools</filename>, le script
<filename>slon.in-profiles</filename> permet de lancer des instances &lslon;
@@ -1134,60 +1224,115 @@
</sect2>
<sect2 id="duplicate-node">
-<title><filename> duplicate-node.sh </filename></title>
+<title><filename>duplicate-node.sh</filename></title>
+<indexterm><primary>dupliquer un nœud</primary></indexterm>
-<indexterm><primary> duplicating nodes </primary> </indexterm>
+<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> In the <filename>tools</filename> area,
-<filename>duplicate-node.sh</filename> is a script that may be used to
-help create a new node that duplicates one of the ones in the
-cluster. </para>
+<para>
+ Ce script attend les paramètres suivants :
+</para>
-<para> The script expects the following parameters: </para>
<itemizedlist>
-<listitem><para> Cluster name </para> </listitem>
-<listitem><para> New node number </para> </listitem>
-<listitem><para> Origin node </para> </listitem>
-<listitem><para> Node being duplicated </para> </listitem>
-<listitem><para> New node </para> </listitem>
+ <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> For each of the nodes specified, the script offers flags to
-specify <function>libpq</function>-style parameters for
-<envar>PGHOST</envar>, <envar>PGPORT</envar>,
-<envar>PGDATABASE</envar>, and <envar>PGUSER</envar>; it is expected
-that <filename>.pgpass</filename> will be used for storage of
-passwords, as is generally considered best practice. Those values may
-inherit from the <function>libpq</function> environment variables, if
-not set, which is useful when using this for testing. When
-<quote>used in anger,</quote> however, it is likely that nearly all of
-the 14 available parameters should be used. </para>
+<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> The script prepares files, normally in
-<filename>/tmp</filename>, and will report the name of the directory
-that it creates that contain SQL and &lslonik; scripts to set up the
-new node. </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> This is drawn from the origin node, and contains the <quote>pristine</quote> database schema that must be applied first.</para></listitem>
-<listitem><para> <filename> slonik.preamble </filename> </para>
-
-<para> This <quote>preamble</quote> is used by the subsequent set of slonik scripts. </para> </listitem>
-<listitem><para> <filename> step1-storenode.slonik </filename> </para>
-<para> A &lslonik; script to set up the new node. </para> </listitem>
-<listitem><para> <filename> step2-storepath.slonik </filename> </para>
-<para> A &lslonik; script to set up path communications between the provider node and the new node. </para> </listitem>
-<listitem><para> <filename> step3-subscribe-sets.slonik </filename> </para>
-<para> A &lslonik; script to request subscriptions for all replications sets.</para> </listitem>
+ <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> For testing purposes, this is sufficient to get a new node working. The configuration may not necessarily reflect what is desired as a final state:</para>
+<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> Additional communications paths may be desirable in order to have redundancy. </para> </listitem>
-<listitem><para> It is assumed, in the generated scripts, that the new node should support forwarding; that may not be true. </para> </listitem>
-<listitem><para> It may be desirable later, after the subscription process is complete, to revise subscriptions. </para> </listitem>
+ <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>
Modified: traduc/branches/slony_1_2/bestpractices.xml
===================================================================
--- traduc/branches/slony_1_2/bestpractices.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/bestpractices.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -163,12 +163,12 @@
</para>
<para>
- Most pointedly, any node that is expected to be a failover
- target must have its subscription(s) set up with the option
- <command>FORWARD = YES</command>. Otherwise, that node is not a
- candidate for being promoted to origin node.
+ Plus précisément, tout nœud qui a pour but d'être une cible dans
+ le cadre d'une bascule doit avoir ces abonnements configurés avec
+ l'option <command>FORWARD = YES</command>. Autrement, ce nœud
+ ne peut pas être un candidat pour devenir nœud origine.
</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
@@ -211,16 +211,16 @@
<listitem>
<para>
- If you are using the autovacuum process in recent
- versions of &postgres;, you may wish to leave &slony1; tables out, as
- &slony1; is a bit more intelligent about vacuuming when it is expected
- to be conspicuously useful (<emphasis>e.g.</emphasis> - immediately
- after purging old data) to do so than autovacuum can be.
+ 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>
- See <xref linkend="maintenance-autovac"/> for more
- details.
+ Reportez-vous au chapitre <xref linkend="maintenance-autovac"/> pour plus
+ de détails.
</para>
</listitem>
@@ -255,9 +255,10 @@
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.
- Thus, if you have nodes in London and nodes in New
- York, the &lslon;s managing London nodes should run in London, and the
- &lslon;s managing New York nodes should run in New York.
+ Donc, si vous avez des nœuds à Londres et d'autres à New York,
+ les processus &lslon; gérant les nœuds de Londres devraient être
+ exécutés à Londres, et les processus &lslon; gérant les nœuds
+ de New York devraient être exécutés à New York.
</para>
<para>
@@ -341,9 +342,9 @@
<warning>
<para>
- In version 2 of &slony1;, <xref linkend="stmttableaddkey"/> is no longer
- supported. You <emphasis>must</emphasis> have either a true primary key
- or a candidate primary key.
+ 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>
@@ -419,10 +420,11 @@
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 when running
- DDL; &slony1; is asking for those exclusive table locks, whilst,
- simultaneously, some application connections are gradually relinquishing
- locks, whilst others are backing up behind the &slony1; locks.
+ très problématique si les applications fonctionnent alors que des
+ instructions DDL sont en cours d'exécution ; &slony1; demande pour
+ elles des verrous exclusifs sur les tables alors que, simultanément,
+ certaines connexions renoncent graduellement à des verrous et que d'autres
+ récupèrent les verrous &slony1;.
</para>
<para>
@@ -692,11 +694,11 @@
</para>
<para>
- It will also notice a number of sorts of situations where
- something has broken. Not only should it be run when problems have
- been noticed - it should be run frequently (<emphasis>e.g.</emphasis>
- - hourly, or thereabouts) as a general purpose <quote>health
- check</quote> for each &slony1; cluster.
+ Il remarquera un ensemble de situations où quelque chose a cassé. Il doit
+ être utilisé quand des problèmes ont été remarqués, mais il devrait aussi
+ être utilisé fréquemment (<emphasis>c'est-à-dire</emphasis> environ toutes
+ les heures) comme un outil de vérification de la <quote>santé</quote>
+ pour chaque cluster &slony1;.
</para>
</listitem>
@@ -758,13 +760,12 @@
</para>
<para>
- It is also a very good idea to change &lslon; configuration for
- <xref linkend="slon-config-sync-interval"/> on the origin node to
- reduce how many <command>SYNC</command> events are generated. If the
- subscription takes 8 hours, there is little sense in there being 28800
- <command>SYNC</command>s waiting to be applied. Running a
- <command>SYNC</command> every minute or so is likely to make catching
- up easier.
+ C'est aussi une très bonne idée de modifier la configuration de &lslon;
+ pour <xref linkend="slon-config-sync-interval"/> sur le nœud origine
+ de façon à réduire le nombre d'événements <command>SYNC</command> générés.
+ Si l'abonnement prend huit heures, il y a peu d'intérêt à avoir 28800
+ <command>SYNC</command> en attente. En exécutant un <command>SYNC</command>
+ chaque minute, il devient plus simple de récupérer la latence.
</para>
</listitem>
</itemizedlist>
Modified: traduc/branches/slony_1_2/cluster.xml
===================================================================
--- traduc/branches/slony_1_2/cluster.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/cluster.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -35,10 +35,11 @@
</para>
<para>
- Note that, as recorded in the <xref linkend="faq"/> under <link
- linkend="cannotrenumbernodes"> How can I renumber nodes?</link>, the
- node number is immutable, so it is not possible to change a node's
- node number after it has been set up.
+ Notez que, comme indiqué dans la <xref linkend="faq"/> sous la question <link
+ linkend="cannotrenumbernodes">Comment puis-je renuméroter les
+ nœuds ?</link>, le numéro du nœud est non modifiable, donc
+ il n'est pas possible de changer le numéro d'un nœud une fois que ce
+ dernier a été configuré.
</para>
<para>
Modified: traduc/branches/slony_1_2/defineset.xml
===================================================================
--- traduc/branches/slony_1_2/defineset.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/defineset.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -113,9 +113,10 @@
<warning>
<para>
- <xref linkend="stmttableaddkey"/> was always considered a
- <quote>kludge</quote>, at best, and as of version 2.0, it is considered
- such a misfeature that it is being removed.
+ La commande <xref linkend="stmttableaddkey"/> a toujours été considérée
+ au mieux comme un <quote>bricolage</quote>, et à partir de la version
+ 2.0, elle est considérée comme une mauvaise fonctionnalité qu'il faut
+ supprimer.
</para>
</warning>
</listitem>
@@ -172,15 +173,15 @@
</para>
<para>
- Another issue comes up particularly frequently when replicating
- across a WAN; sometimes the network connection is a little bit
- unstable, such that there is a risk that a connection held open for
- several hours will lead to <command>CONNECTION TIMEOUT.</command> If
- that happens when 95% done copying a 50-table replication set
- consisting of 250GB of data, that could ruin your whole day. If the
- tables were, instead, associated with separate replication sets, that
- failure at the 95% point might only interrupt, temporarily, the
- copying of <emphasis>one</emphasis> of those tables.
+ Un autre problème survient fréquemment lorsque l'on réplique via un
+ WAN ; parfois la connexion réseau est un peu instable, si bien
+ qu'il y a des risques qu'une connexion reste ouverte pendant plusieurs
+ heures et entraîne un <command>CONNECTION TIMEOUT</command>. Si cela se
+ produit à 95% d'une copie d'un ensemble de réplication de 50 tables,
+ représentant 250GB de données, cela va gâcher votre journée. Au contraire
+ si les tables sont séparées en plusieurs ensembles de réplication, cette
+ panne réseau qui intervient à 95% n'interrompra que la copie
+ d'<emphasis>un seul</emphasis> ensemble.
</para>
<para>
@@ -277,9 +278,9 @@
<para>
Pour répliquer 300 séquences, 300 lignes doivent être ajoutées dans la
- &slseqlog; de manière régulière, at least, thru until the 2.0 branch,
- where updates are only applied when the value of a given sequence is
- seen to change.
+ &slseqlog; de manière régulière, au moins jusqu'à la branche 2.0 où les
+ mises à jour sont seulement appliquées quand la valeur d'une séquence
+ données est visible modifiée.
</para>
<para>
Modified: traduc/branches/slony_1_2/dropthings.xml
===================================================================
--- traduc/branches/slony_1_2/dropthings.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/dropthings.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -215,14 +215,13 @@
</sect2>
<sect2>
-<title> Verifying Cluster Health </title>
+<title>Vérifier la santé du cluster</title>
<para>
- After performing any of these procedures, it is an excellent
- idea to run the <filename>tools</filename> script <eststate;, which
- rummages through the state of the entire cluster, pointing out any
- anomalies that it finds. This includes a variety of sorts of
- communications problems.
+ Après avoir exécuté une de ces prodécures, une excellente pratique est
+ d'exécuter le script <eststate; des <filename>tools</filename>, qui
+ vérifie l'intégralité de l'état du cluster, pointant toutes les anomalies
+ qu'il découvre. Ceci inclut un ensemble de problèmes de communication.
</para>
</sect2>
Modified: traduc/branches/slony_1_2/failover.xml
===================================================================
--- traduc/branches/slony_1_2/failover.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/failover.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -59,7 +59,7 @@
<itemizedlist>
<listitem>
<para>
- Au moment ou nous écrivons ces lignes, basculer vers un autre serveur
+ Au moment où nous écrivons ces lignes, basculer vers un autre serveur
nécessite que l'application se reconnecte à la nouvelle base de donnée.
Donc, pour éviter toute complication, nous éteignons le serveur web. Les
utilisateurs qui ont installé <application>pgpool</application> pour
@@ -67,62 +67,61 @@
</para>
<para>
- What needs to be done, here, is highly dependent on the way
- that the application(s) that use the database are configured. The
- general point is thus: Applications that were connected to the old
- database must drop those connections and establish new connections to
- the database that has been promoted to the <quote>master</quote>. There
- are a number of ways that this may be configured, and therefore, a
- number of possible methods for accomplishing the change:
+ Les actions à mener dépendent beaucoup de la configuration des
+ applications qui utilisent la base de données. En général, les
+ applications qui étaient connectées à l'ancienne base doivent détruire
+ leurs connexions et en établir de nouvelles vers la base qui vient d'être
+ promue dans le rôle du <quote>maître</quote>. Il y a différentes façons
+ de configurer cela, et donc différentes façon d'effectuer la bascule :
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ L'application stocke le nom de la base de donnée dans un fichier.
+ </para>
+
+ <para>
+ Dans ce cas, la reconfiguration nécessite de changer la valeur dans
+ ce fichier, d'arrêter puis de relancer l'application pour qu'elle
+ pointe vers le nouvel emplacement des données.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Une utilisation pertinente de DNS consiste à créer des <ulink
+ url="http://www.iana.org/assignments/dns-parameters">champs DNS</ulink>
+ CNAME qui permettent à l'application d'utiliser un nom pour
+ référencer le nœud qui joue le rôle du nœud
+ <quote>maître</quote>.
+ </para>
+
+ <para>
+ Dans ce cas, la reconfiguration nécessite de changer le CNAME pour
+ pointer vers le nouveau serveur. De plus, il faut probablement
+ relancer l'application pour rafraîchir les connexions à la base.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Si vous utilisez <application>pgpool</application> ou un
+ <quote>gestionnaire de connexions</quote> similaire, alors la
+ reconfiguration implique de modifier le paramètrage de cet outil,
+ à part cela la procédure est similaire à l'exemple DNS/CNAME
+ ci-dessus.
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The application may store the name of the database in a file.
- </para>
-
- <para>
- In that case, the reconfiguration may require changing the
- value in the file, and stopping and restarting the application to get
- it to point to the new location.
- </para>
- </listitem>
-
- <listitem>
- <para>
- A clever usage of DNS might involve creating a CNAME
- <ulink url="http://www.iana.org/assignments/dns-parameters"> DNS
- record </ulink> that establishes a name for the application to use to
- reference the node that is in the <quote>master</quote> role.
- </para>
-
- <para>
- In that case, reconfiguration would require changing the CNAME
- to point to the new server, and possibly restarting the application to
- refresh database connections.
- </para>
- </listitem>
-
- <listitem>
- <para>
- If you are using <application>pg_pool</application> or some
- similar <quote>connection pool manager,</quote> then the reconfiguration
- involves reconfiguring this management tool, but is otherwise similar
- to the DNS/CNAME example above.
- </para>
- </listitem>
-
- </itemizedlist>
-
+
<para>
- Whether or not the application that accesses the database needs
- to be restarted depends on how it is coded to cope with failed
- database connections; if, after encountering an error it tries
- re-opening them, then there may be no need to restart it.
+ La nécessité de redémarrer l'application qui se connecte à la base dépend
+ de la manière dont elle a été conçue et des mécanismes de gestion d'erreurs
+ de connexion qui ont été implémentés ; si à la suite d'une erreur
+ elle tente d'ouvrir à nouveau une connexion, alors il n'est pas nécessaire
+ de la relancer.
</para>
-
</listitem>
<listitem>
@@ -177,10 +176,9 @@
</para>
<para>
- After performing the configuration change, you should, as <xref
- linkend="bestpractices"/>, run the <eststate; scripts in order to
- validate that the cluster state remains in good order after this
- change.
+ Après avoir réalisé les modifications dans la configuration, vous devriez,
+ comme <xref linkend="bestpractices"/>, exécuter les scripts <eststate;
+ dans l'ordre pour valider que l'état du cluster reste bon.
</para>
</sect2>
@@ -241,13 +239,13 @@
<note>
<para>
- Note that in order for node 2 to be considered as a
- candidate for failover, it must have been set up with the <xref
- linkend="stmtsubscribeset"/> option <command>forwarding =
- yes</command>, which has the effect that replication log data is
- collected in &sllog1;/&sllog2; on node 2. If replication log data is
- <emphasis>not</emphasis> being collected, then failover to that node
- is not possible.
+ Notez que, pour que le nœud 2 soit considéré comme un candidat
+ pour la bascule, il doit avoir été configuré avec l'option
+ <command>forwarding = yes</command> de <xref linkend="stmtsubscribeset"/>,
+ ce qui a pour effet que les données du log de réplication sont conservées
+ dans &sllog1;/&sllog2; du nœud 2. Si ces données ne sont
+ <emphasis>pas</emphasis> conservées, alors la bascule vers ce nœud
+ n'est pas possible.
</para>
</note>
</listitem>
@@ -295,96 +293,115 @@
<listitem>
<para>
- After performing the configuration change, you should, as <xref
- linkend="bestpractices"/>, run the <eststate; scripts in order to
- validate that the cluster state remains in good order after this change.
+ Après avoir réalisé les modifications dans la configuration, vous devriez,
+ comme <xref linkend="bestpractices"/>, exécuter les scripts <eststate;
+ dans l'ordre pour valider que l'état du cluster reste bon.
</para>
</listitem>
</itemizedlist>
</sect2>
-<sect2 id="complexfailover"> <title> Failover With Complex Node Set </title>
+<sect2 id="complexfailover">
+<title>Bascule avec un ensemble de nœuds complexe</title>
-<para> Failover is relatively <quote>simple</quote> if there are only two
-nodes; if a &slony1; cluster comprises many nodes, achieving a clean
-failover requires careful planning and execution. </para>
+<para>
+ La bascule est assez <quote>simple</quote> s'il n'y a que deux
+ nœuds ; si un cluster &slony1; comprends de nombreux nœuds,
+ exécuter une bascule propre demande une planification et une exécution très
+ attentives aux détails.
+</para>
-<para> Consider the following diagram describing a set of six nodes at two sites.
+<para>
+ Considérez le diagramme suivant décrivant un ensemble de six nœuds sur
+ deux sites.
<inlinemediaobject>
<imageobject>
<imagedata fileref="complexenv.png"/>
</imageobject>
<textobject>
- <phrase> Symmetric Multisites</phrase>
+ <phrase>Multisites symétriques</phrase>
</textobject>
</inlinemediaobject>
</para>
-<para> Let us assume that nodes 1, 2, and 3 reside at one data
-centre, and that we find ourselves needing to perform failover due to
-failure of that entire site. Causes could range from a persistent
-loss of communications to the physical destruction of the site; the
-cause is not actually important, as what we are concerned about is how
-to get &slony1; to properly fail over to the new site.</para>
+<para>
+ Supposons que les nœuds 1, 2 et 3 résident à un point central et que
+ nous ayons besoin d'effectuer une bascule à cause d'un problème sur ce site
+ complet. Les causes peuvent aller d'une perte persistente de communications
+ à la destruction physique de ce site. La cause n'a pas d'importance en soi
+ car ce qui nous intéresse est de savoir comment réaluser une bascule propre
+ de &slony1; vers le nouveau site.
+</para>
-<para> We will further assume that node 5 is to be the new origin,
-after failover. </para>
+<para>
+ Nous supposerons maintenant que le nœud 5 doit devenir la nouvelle
+ origine après bascule.
+</para>
-<para> The sequence of &slony1; reconfiguration required to properly
-failover this sort of node configuration is as follows:
+<para>
+ La séquence de reconfiguration de &slony1; requiert d'exécuter les étapes
+ suivantes pour une bascule propre de la configuration des nœuds :
</para>
<itemizedlist>
-<listitem><para> Resubscribe (using <xref linkend="stmtsubscribeset"/>
-ech node that is to be kept in the reformation of the cluster that is
-not already subscribed to the intended data provider. </para>
+ <listitem>
+ <para>
+ Réabonner chaque nœud (en utilisant <xref linkend="stmtsubscribeset"/>
+ nécessaire à la reformation d'un cluster qui n'est pas encore abonné au
+ futur fournisseur de données.
+ </para>
-<para> In the example cluster, this means we would likely wish to
-resubscribe nodes 4 and 6 to both point to node 5.</para>
+ <para>
+ Dans notre cluster d'exemple, cela signifie que nous voulons réabonner
+ les nœuds 4 et 6 , qui doivent tous les deux pointer vers 5.
+ </para>
-<programlisting>
- include </tmp/failover-preamble.slonik>;
- subscribe set (id = 1, provider = 5, receiver = 4);
- subscribe set (id = 1, provider = 5, receiver = 4);
-</programlisting>
+ <programlisting>include </tmp/failover-preamble.slonik>;
+subscribe set (id = 1, provider = 5, receiver = 4);
+subscribe set (id = 1, provider = 5, receiver = 4);</programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ Supprimer tous les nœuds inutiles, en commençant par les derniers
+ esclaves.
+ </para>
-</listitem>
-<listitem><para> Drop all unimportant nodes, starting with leaf nodes.</para>
+ <para>
+ Comme les nœuds 1, 2 et 3 sont inaccessibles, nous devons indiquer
+ <envar>EVENT NODE</envar> pour que chaque événement atteigne les portions
+ toujours vivantes du cluster.
+ </para>
-<para> Since nodes 1, 2, and 3 are unaccessible, we must indicate the
-<envar>EVENT NODE</envar> so that the event reaches the still-live
-portions of the cluster. </para>
+ <programlisting>include </tmp/failover-preamble.slonik>;
+drop node (id=2, event node = 4);
+drop node (id=3, event node = 4);</programlisting>
+ </listitem>
-<programlisting>
- include </tmp/failover-preamble.slonik>;
- drop node (id=2, event node = 4);
- drop node (id=3, event node = 4);
-</programlisting>
+ <listitem>
+ <para>
+ Maintenant exécuter la bascule avec <command>FAILOVER</command>.
+ </para>
-</listitem>
+ <programlisting>include </tmp/failover-preamble.slonik>;
+failover (id = 1, backup node = 5);</programlisting>
+ </listitem>
-<listitem><para> Now, run <command>FAILOVER</command>.</para>
+ <listitem>
+ <para>
+ Enfin, supprimez l'ancienne origine du cluster.
+ </para>
-<programlisting>
- include </tmp/failover-preamble.slonik>;
- failover (id = 1, backup node = 5);
-</programlisting>
+ <programlisting>include </tmp/failover-preamble.slonik>;
+drop node (id=1, event node = 4);</programlisting>
+ </listitem>
-</listitem>
+</itemizedlist>
-<listitem><para> Finally, drop the former origin from the cluster.</para>
-
-<programlisting>
- include </tmp/failover-preamble.slonik>;
- drop node (id=1, event node = 4);
-</programlisting>
-</listitem>
-
-</itemizedlist>
</sect2>
<sect2>
Modified: traduc/branches/slony_1_2/firstdb.xml
===================================================================
--- traduc/branches/slony_1_2/firstdb.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/firstdb.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -46,7 +46,8 @@
<note>
<para>
- This is no longer needed for &postgres; 8.0 and later versions.
+ Ce n'est plus nécessaire pour les versions &postgres; 8.0 et
+ ultérieures.
</para>
</note>
</listitem>
@@ -132,16 +133,21 @@
createdb -O $PGBENCHUSER -h $SLAVEHOST $SLAVEDBNAME
pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</programlisting>
-<para> One of the tables created by
-<application>pgbench</application>, <envar>history</envar>, does not
-have a primary key. In earlier versions of &slony1;, a &lslonik;
-command called <xref linkend="stmttableaddkey"/> could be used to
-introduce one. This caused a number of problems, and so this feature
-has been removed in version 2 of &slony1;. It now
-<emphasis>requires</emphasis> that there is a suitable candidate
-primary key. </para>
+<para>
+ Une des tables créées par <application>pgbench</application>,
+ <envar>history</envar>, n'a pas de clé primaire. Dans les versions
+ antérieures de &slony1;, une commande &slonik; nommée <xref
+ linkend="stmttableaddkey"/> pouvait être utilisées pour en introduire une.
+ Ceci provoquait de nombreux problèmes si bien que cette fonctionnalité fut
+ supprimée dans la version 2 de &slony1;. Il est désormais
+ <emphasis>nécessaire</emphasis> d'avoir une ensemble éligible en tant que
+ clé primaire.
+</para>
-<para> The following SQL requests will establish a proper primary key on this table: </para>
+<para>
+ Les requêtes SQL suivantes établissent une clé primaire cohérente pour cette
+ table :
+</para>
<programlisting>
psql -U $PGBENCHUSER -h $HOST1 -d $MASTERDBNAME -c "begin; alter table
@@ -203,22 +209,31 @@
principalement des procédures stockées sur les nœuds maître et esclaves.
</para>
-<para> The example that follows uses <xref linkend="slonik"/> directly
-(or embedded directly into scripts). This is not necessarily the most
-pleasant way to get started; there exist tools for building <xref
-linkend="slonik"/> scripts under the <filename>tools</filename>
-directory, including:</para>
+<para>
+ L'exemple qui suit utilise <xref linkend="slonik"/> directement (ou l'embarque
+ directement dans les scripts). Ce n'est pas forcément la façon la plus
+ plaisante pour débuter : il existe des outils pour construire les
+ scripts de <xref linkend="slonik"/> dans le répertoire
+ <filename>tools</filename> :
+</para>
+
<itemizedlist>
-<listitem><para> <xref linkend="altperl"/> - a set of Perl scripts that
-build <xref linkend="slonik"/> scripts based on a single
-<filename>slon_tools.conf</filename> file. </para> </listitem>
-
-<listitem><para> <xref linkend="mkslonconf"/> - a shell script
-(<emphasis>e.g.</emphasis> - works with Bash) which, based either on
-self-contained configuration or on shell environment variables,
-generates a set of <xref linkend="slonik"/> scripts to configure a
-whole cluster. </para> </listitem>
-
+ <listitem>
+ <para>
+ <xref linkend="altperl"/> - un ensemble de scripts Perl qui construisent
+ des scripts <xref linkend="slonik"/> basés sur un seul fichier
+ <filename>slon_tools.conf</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <xref linkend="mkslonconf"/> - un script shell (<emphasis>c'est-à-dire</emphasis>
+ qu'il fonctionne avec Bash) qui, en se basant soit sur sa configuration
+ interne soit sur les variables d'environnement, génère un ensemble de
+ scripts <xref linkend="slonik"/> pour configurer un cluster complet.
+ </para>
+ </listitem>
</itemizedlist>
<sect3>
@@ -363,11 +378,11 @@
</para>
<para>
- If you encounter problems getting this working, check over the
- logs for the &lslon; processes, as error messages are likely to be
- suggestive of the nature of the problem. The tool <eststate; is
- also useful for diagnosing problems with nearly-functioning
- replication clusters.
+ Si vous rencontrez des problèmes pour faire fonctionner ceci, vérifiez les
+ journaux applicatifs des processus &lslon; car il y a de fortes chances que
+ des messages d'erreur intéressants décrivent la nature du problème. L'outil
+ <eststate; peut aussi être utile pour diagnostiquer les problèmes avec
+ des clusters de réplication pratiquement fonctionnels.
</para>
<para>
@@ -432,46 +447,50 @@
</para>
<para>
-. Be sure to be prepared with useful
-diagnostic information including the logs generated by &lslon;
-processes and the output of <eststate;. </para></sect3>
+ Préparez-vous aussi à fournir des informations de diagnostique, comme les
+ journaux applicatifs créés par les processus &lslon; et les résultats de la
+ commande <eststate;.
+</para>
-<sect3><title>Using the altperl scripts</title>
+</sect3>
-<indexterm><primary> altperl script example </primary></indexterm>
+<sect3>
+<title>Utiliser les scripts altperl</title>
+<indexterm><primary>exemple d'un script altperl</primary></indexterm>
<para>
-Using the <xref linkend="altperl"/> scripts is an alternative way to
-get started; it allows you to avoid writing slonik scripts, at least
-for some of the simple ways of configuring &slony1;. The
-<command>slonik_build_env</command> script will generate output
-providing details you need to build a
-<filename>slon_tools.conf</filename>, which is required by these
-scripts. An example <filename>slon_tools.conf</filename> is provided
-in the distribution to get you started. The altperl scripts all
-reference this central configuration file centralize cluster
-configuration information. Once slon_tools.conf has been created, you
-can proceed as follows:
+ L'utilisation des scripts <xref linkend="altperl"/> est une autre façon de
+ débuter ; cela vous évite d'avoir à écrire les scripts slonik, au moins
+ pour certaines des façons simples de configurer &slony1;. Le script
+ <command>slonik_build_env</command> génère une sortie fournissant les détails
+ dont vous avez besoin pour créer le fichier
+ <filename>slon_tools.conf</filename>, dont la présence est nécessaire pour
+ les scripts. Un exemple de fichier <filename>slon_tools.conf</filename> est
+ fourni dans la distribution pour vous aider à commencer. Les scripts altperl
+ font tous référence à ce fichier de configuration central. Une fois que
+ slon_tools.conf est créé, vous pouvez continuer ainsi :
</para>
<programlisting>
-# Initialize cluster:
+# Initialisation du cluster :
$ slonik_init_cluster | slonik
-# Start slon (here 1 and 2 are node numbers)
+# Lancement de slon (ici 1 et 2 sont les numéros de noeuds)
$ slon_start 1
$ slon_start 2
-# Create Sets (here 1 is a set number)
+# Créer les ensembles (ici 1 est le numéro de l'ensemble)
$ slonik_create_set 1 | slonik
-# subscribe set to second node (1= set ID, 2= node ID)
+# abonner le second noeud à l'ensemble (1= identifiant du set, 2= identifiant du noeud)
$ slonik_subscribe_set 1 2 | slonik
</programlisting>
-<para> You have now replicated your first database. You can skip the
-following section of documentation if you'd like, which documents more
-of a <quote>bare-metal</quote> approach.</para>
+<para>
+ Vous avez maintenant répliqué votre première base de données. Vous pouvez
+ ignorer la section suivante de la documentation si vous le souhaitez. Elle
+ documente une approche plus complexe.
+</para>
</sect3>
Modified: traduc/branches/slony_1_2/help.xml
===================================================================
--- traduc/branches/slony_1_2/help.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/help.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -23,8 +23,8 @@
<para>
Avant de soumettre des questions sur un forum public en demandant
pourquoi <quote>quelque chose d'étrange</quote> s'est produit dans
- votre cluster de réplication, be sure to run the <eststate; tool and be
- prepared to provide its output.
+ votre cluster de réplication, assurez-vous d'exécuter l'outil
+ <eststate; et d'être préparé à fournir sa sortie.
Cela peut vous donner plus d'idées sur ce qui ne va pas, et les
résultats seront sûrement d'une grande aide dans l'analyse du
problème.
Modified: traduc/branches/slony_1_2/installation.xml
===================================================================
--- traduc/branches/slony_1_2/installation.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/installation.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -243,24 +243,35 @@
chargés à distance à partir des autres nœuds.).
</para>
-<para> In &slony1; version 2.0, this changes:</para>
+<para>
+ Dans &slony1; 2.0, ceci change :
+</para>
+
<itemizedlist>
-<listitem><para><filename> $bindir/slon</filename></para></listitem>
-<listitem><para><filename> $bindir/slonik</filename></para></listitem>
-<listitem><para><filename> $libdir/slony1_funcs$(DLSUFFIX)</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_base.sql</filename></para></listitem>
-<listitem><para><filename> $datadir/slony1_funcs.sql</filename></para></listitem>
+ <listitem><para><filename>$bindir/slon</filename></para></listitem>
+ <listitem><para><filename>$bindir/slonik</filename></para></listitem>
+ <listitem><para><filename>$libdir/slony1_funcs$(DLSUFFIX)</filename></para></listitem>
+ <listitem><para><filename>$datadir/slony1_base.sql</filename></para></listitem>
+ <listitem><para><filename>$datadir/slony1_funcs.sql</filename></para></listitem>
</itemizedlist>
-<note> <para> Note the loss of <filename>xxid.so</filename> - the txid
-data type introduced in &postgres; 8.3 makes it
-obsolete. </para></note>
+<note>
+ <para>
+ Notez l'abandon de <filename>xxid.so</filename>, le type de données txid
+ introduit avec &postgres; 8.3 le rendant obsolète.
+ </para>
+</note>
-<note> <para> &slony1; 2.0 gives up compatibility with versions of
-&postgres; prior to 8.3, and hence <quote>resets</quote> the
-version-specific base function handling. There may be function files
-for version 8.3, 8.4, and such, as replication-relevant divergences of
-&postgres; functionality take place. </para></note>
+<note>
+ <para>
+ &slony1; 2.0 abandonne la compatibilité avec les versions de &postgres;
+ antérieures à la 8.3, et du coup <quote>ré-initialise</quote> la gestion
+ des fonctions de base spécifiques à la version. Il peut exister des
+ fichiers de fonction pour les versions 8.3, 8.4, et ainsi de suite, si
+ des différences importantes pour la réplication sont notées dans les
+ fonctionnalités de &postgres;.
+ </para>
+</note>
</sect2>
@@ -283,11 +294,11 @@
documentation sur les systèmes basés sur Red Hat à cause de la valeur NAMELEN
qui est trop faible. Havoc Pennington a déclaré ce bug au milieu de l'année
2001, à l'époque de Red Hat 7.1 ; La société Red Hat Software a reconnu
- ce bug mais il n'y a eu aucun progrès depuis. La seconde URL ci-dessous
+ ce bug mais il n'y a eu aucun progrès depuis. La seconde URL ci-dessous
indique qu'il y a eu des tentatives de correction en élevant la valeur de
NAMELEN dans une future version de Red Hat Enterprise Linux, mais cela n'est
- pas le cas if you are using an elder version where this
-will never be rectified. Les distribution Fedora actuelles ont déjà corrigé ce
+ pas le cas si vous utilisez une version plus récente pour laquelle cela ne
+ sera jamais rectifié. Les distribution Fedora actuelles ont déjà corrigé ce
problème.
</para>
Modified: traduc/branches/slony_1_2/locking.xml
===================================================================
--- traduc/branches/slony_1_2/locking.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/locking.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -19,12 +19,12 @@
les lectures bloquent les écritures concurrentes. Avec
<acronym>MVCC</acronym>, &postgres; supprime toute une catégorie de verrous,
dans le sens où les <quote>vieilles lectures</quote> peuvent accéder aux
- <quote>anciennes lignes</quote>. La plupart du temps, cela évite aux aimables
- utilisateurs de &postgres; de trop se préoccuper des verrous.
- &slony1; configuration events normally grab locks on an
- internal table, <envar>sl_config_lock</envar>, which should not be
- visible to applications unless they are performing actions on &slony1;
- components.
+ <quote>anciennes lignes</quote>. La plupart du temps, cela évite aux
+ utilisateurs de &postgres; de trop se préoccuper des verrous. Les événements
+ de configuration de &slony1; récupèrent habituellement des verrous sur une
+ table interne, <envar>sl_config_lock</envar>, qui ne devrait pas être visible
+ pour les applications à moins que ces dernières doivent exécuter des actions
+ sur les composants &slony1;.
</para>
<para>
Modified: traduc/branches/slony_1_2/loganalysis.xml
===================================================================
--- traduc/branches/slony_1_2/loganalysis.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/loganalysis.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -34,23 +34,28 @@
</sect2>
-<sect2><title>INFO notices</title>
+<sect2>
+<title>Notifications INFO</title>
-<para> Events that take place that seem like they will generally be of
-interest are recorded at the INFO level, and, just as with CONFIG
-notices, are always listed. </para>
+<para>
+ Les événements, qui semblent avoir un intérêt au niveau INFO et qui sont
+ toujours listés, tout comme les notifications CONFIG.
+</para>
</sect2>
<sect2>
<title>Notifications DEBUG</title>
-<para>Debug notices are of less interest, and will quite likely only
-need to be shown if you are running into some problem with &slony1;.</para>
+<para>
+ Les messages de débogage sont de peu d'intérêt. Vous en aurez seulement besoin
+ si vous avez des problèmes avec &slony1;.
+</para>
</sect2>
-<sect2><title>Thread name </title>
+<sect2>
+<title>Nom du thread</title>
<para>
Les notifications DEBUG sont moins intéressantes et ne vous seront utiles
@@ -127,12 +132,6 @@
4 affichera des plus en plus de messages de niveau DEBUG.
</para>
-<para> How much information they display is controlled by the
-<envar>log_level</envar> &lslon; parameter; ERROR/WARN/CONFIG/INFO
-messages will always be displayed, while choosing increasing values
-from 1 to 4 will lead to additional DEBUG level messages being
-displayed. </para>
-
</sect2>
<sect2>
@@ -2402,10 +2401,10 @@
</para>
<para>
- This happens if you try to do <xref linkend="stmtsubscribeset"/>
- when the node unaware of a would-be new node; probably a sign of
- <command>STORE_NODE</command> and <command>STORE_PATH</command>
- requests not propagating...
+ Ceci survient si vous essayez d'exécuter <xref linkend="stmtsubscribeset"/>
+ quand le nœud n'a pa connaissance d'un probable nouveau nœud.
+ C'est généralement un signe que les requêtes <command>STORE_NODE</command>
+ et <command>STORE_PATH</command> ne sont pas propagées...
</para>
</listitem>
Modified: traduc/branches/slony_1_2/logshipping.xml
===================================================================
--- traduc/branches/slony_1_2/logshipping.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/logshipping.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -524,27 +524,32 @@
</sect2>
-<sect2><title> <application> find-triggers-to-deactivate.sh
-</application> </title>
+<sect2>
+<title><application>find-triggers-to-deactivate.sh</application></title>
+<indexterm><primary>désactivation des triggers</primary></indexterm>
-<indexterm><primary> trigger deactivation </primary> </indexterm>
+<para>
+ Le <ulink url="http://www.slony.info/bugzilla/show_bug.cgi?id=19">bug
+ #19</ulink> indique que le dump d'un schéma peut contenir des triggers
+ et des règles que l'on ne souhaite pas activer sur un nœud de log
+ shipping.
+</para>
-<para> It was once pointed out (<ulink
-url="http://www.slony.info/bugzilla/show_bug.cgi?id=19"> Bugzilla bug
-#19</ulink>) that the dump of a schema may include triggers and rules
-that you may not wish to have running on the log shipped node.</para>
+<para>
+ L'outil <filename> tools/find-triggers-to-deactivate.sh</filename> a été
+ créé pour assister l'utilisateur dans cette tache. Il peut être lancé sur un
+ nœud qui sera utilisé comme schéma source, et il liste les règles et
+ les triggers, présents sur ce nœud, qui devraient être désactivés.
+</para>
-<para> The tool <filename> tools/find-triggers-to-deactivate.sh
-</filename> was created to assist with this task. It may be run
-against the node that is to be used as a schema source, and it will
-list the rules and triggers present on that node that may, in turn
-need to be deactivated.</para>
+<para>
+ Cela comprend le trigger <function>logtrigger</function> et
+ <function>denyaccess</function> qui sont normalement exclut du schéma extrait
+ avec pgdump. Il est toutefois de la responsabilité de l'administrateur de
+ vérifier que des triggers comme ceux-ci sont bien retirés du réplicat du log
+ shipping.
+</para>
-<para> It includes <function>logtrigger</function> and <function>denyaccess</function>
-triggers which will may be left out of the extracted schema, but it is
-still worth the Gentle Administrator verifying that such triggers are
-kept out of the log shipped replica.</para>
-
</sect2>
<sect2>
Modified: traduc/branches/slony_1_2/maintenance.xml
===================================================================
--- traduc/branches/slony_1_2/maintenance.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/maintenance.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -53,18 +53,18 @@
<listitem>
<para>
Le bogue <link linkend="dupkey">violation par clef dupliquée</link> a
- permis d'isoler a number of rather obscure
- &postgres; race conditions, so that in modern versions of &slony1; and
- &postgres;, there should be little to worry about.
+ permis d'isoler un certain nombre de cas d'exceptions assez obscures au
+ niveau de &postgres;. Donc, dans les versions modernes de &slony1; et
+ &postgres;, il n'y a pas lieu de s'inquiéter.
</para>
</listitem>
<listitem>
<para>
À partir de la version 1.2, la fonctionnalité <quote>log
- switching</quote> est arrivée ;de temps en temps (by default, once per week,
- though you may induce it by calling the stored
- function <function>logswitch_start()</function>), elle tente
+ switching</quote> est arrivée ;de temps en temps (par défaut
+ une fois par semaine bien que vous pouvez modifier cela en appelant
+ la procédure stockée <function>logswitch_start()</function>), elle tente
d'interchanger les données entre &sllog1; et &sllog2; afin de réaliser
un <command>TRUNCATE</command> sur les <quote>plus vieilles</quote>
données.
@@ -76,43 +76,47 @@
importante et qu'elles deviennent impossibles à nettoyer.
</para>
-<para> In version 2.0, <command>DELETE</command> is no longer used to
-clear out data in &sllog1; and &sllog2;; instead, the log switch logic
-is induced frequently, every time the cleanup loop does not find a
-switch in progress, and these tables are purely cleared out
-via <command>TRUNCATE</command>. This eliminates the need to vacuum
-these tables. </para>
-
+ <para>
+ En version 2.0, <command>DELETE</command> n'est plus utilisé pour
+ nettoyer les données dans &sllog1; et &sllog2; ; à la place, la
+ logique de la bascule des logs est utilisée fréquemment, à chaque fois
+ que la boucle de nettoyage ne trouve pas une bascule en cours. Cela
+ permet de nettoyer proprement ces tables via <command>TRUNCATE</command>.
+ Ceci élimine le besoin d'un VACUUM pour ces tables.
+ </para>
</listitem>
</itemizedlist>
</para>
-<sect2 id="maintenance-autovac"> <title> Interaction with &postgres;
-autovacuum </title>
+<sect2 id="maintenance-autovac">
+<title>Interaction avec l'autovacuum de &postgres;</title>
+<indexterm><primary>interaction avec autovacuum</primary></indexterm>
-<indexterm><primary>autovacuum interaction</primary></indexterm>
+<para>
+ Les versions récentes de&postgres; proposent un processus
+ <quote>autovacuum</quote> qui détecte les modifications sur les tables et
+ la création de lignes mortes, puis nettoie ces tables, <quote>à la
+ demande</quote>. On a constaté que cela peut interagir de manière négative
+ avec la politique de VACUUM de &slony1; sur ces propres tables.
+</para>
-<para> Recent versions of &postgres; support an
-<quote>autovacuum</quote> process which notices when tables are
-modified, thereby creating dead tuples, and vacuums those tables,
-<quote>on demand.</quote> It has been observed that this can interact
-somewhat negatively with &slony1;'s own vacuuming policies on its own
-tables. </para>
+<para>
+ &slony1; demande des VACUUM sur ses tables immédiatement après avoir complété
+ les transactions qui sont sensées supprimer de vieilles données, ce qui est
+ considéré comme le meilleur moment pour le faire. Il semble que l'autovacuum
+ détecte les changements un peu trop tôt, et lance un VACUUM alors que les
+ transactions ne sont pas terminées, ce qui est relativement inutile. Il
+ apparaît préférable de configurer l'autovacuum pour éviter les tables de
+ configuration gérées par &slony1;.
+</para>
-<para> &slony1; requests vacuums on its tables immediately after
-completing transactions that are expected to clean out old data, which
-may be expected to be the ideal time to do so. It appears as though
-autovacuum may notice the changes a bit earlier, and attempts
-vacuuming when transactions are not complete, rendering the work
-pretty useless. It seems preferable to configure autovacuum to avoid
-vacuum &slony1;-managed configuration tables. </para>
+<para>
+ La requête suivante identifie les tables que l'autovacuum ne doit pas traiter
+ (remplacez le nom du cluster par celui de votre configuration locale) :
+</para>
-<para> The following query (change the cluster name to match your
-local configuration) will identify the tables that autovacuum should
-be configured not to process: </para>
-
<programlisting>
-mycluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'MyCluster') and relhasindex;
+moncluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'monCluster') and relhasindex;
oid | relname
-------+--------------
17946 | sl_nodelock
@@ -133,10 +137,15 @@
(15 rows)
</programlisting>
-<para> The following query will populate
-<envar>pg_catalog.pg_autovacuum</envar> with suitable configuration
-information: <command> INSERT INTO pg_catalog.pg_autovacuum (vacrelid, enabled, vac_base_thresh, vac_scale_factor, anl_base_thresh, anl_scale_factor, vac_cost_delay, vac_cost_limit, freeze_min_age, freeze_max_age) SELECT oid, 'f', -1, -1, -1, -1, -1, -1, -1, -1 FROM pg_catalog.pg_class WHERE relnamespace = (SELECT OID FROM pg_namespace WHERE nspname = '_' || 'MyCluster') AND relhasindex; </command>
+<para>
+ La requête suivante remplira la table <envar>pg_catalog.pg_autovacuum</envar>
+ avec les informations de configuration adéquates :
+ <command>INSERT INTO pg_catalog.pg_autovacuum (vacrelid, enabled)
+ SELECT oid, 'f' FROM pg_catalog.pg_class
+ WHERE relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = '_' || 'monCluster')
+ AND relhasindex;</command>
</para>
+
</sect2>
<sect2><title>Chiens de garde : garder les Slons en vie</title>
@@ -175,8 +184,8 @@
<sect2 id="gensync"><title>En parallèle aux chiens de garde :
generate_syncs.sh</title>
+<indexterm><primary>générer des SYNC</primary></indexterm>
-<indexterm><primary>generate SYNCs</primary></indexterm>
<para>
Un nouveau script est apparu dans &slony1; 1.1, il s'agit de
<application>generate_syncs.sh</application>, qui est utilise dans les
@@ -368,9 +377,8 @@
</sect2>
<sect2><title>Autres tests de réplication</title>
+<indexterm><primary>tester la réplication</primary></indexterm>
-<indexterm><primary>testing replication</primary></indexterm>
-
<para>
La méthodologie de la section précédente est conçu avec un vue pour minimiser
le coût des requêtes de tests ; sur un cluster très chargé, supportant
@@ -469,99 +477,188 @@
</sect2>
-<sect2><title>mkservice </title>
-<indexterm><primary>mkservice for BSD </primary></indexterm>
+<sect2><title>mkservice</title>
+<indexterm><primary>mkservice pour BSD </primary></indexterm>
<sect3><title>slon-mkservice.sh</title>
-<para> Create a slon service directory for use with svscan from
-daemontools. This uses multilog in a pretty basic way, which seems to
-be standard for daemontools / multilog setups. If you want clever
-logging, see logrep below. Currently this script has very limited
-error handling capabilities.</para>
+<para>
+ Ce script crée un répertoire pour le service slon qui pourra être utilisé
+ avec la commande svscan de daemontools. Ce script utilise multilog de manière
+ très basique, ce qui semble être standard pour les installations daemontools
+ / multilog. Si vous souhaitez une gestion intelligente des journaux applicatifs,
+ consultez la section logrep ci-dessous. Actuellement, ce script a des
+ possibilités de gestion d'erreurs très limitées.
+</para>
-<para> For non-interactive use, set the following environment
-variables. <envar>BASEDIR</envar> <envar>SYSUSR</envar>
-<envar>PASSFILE</envar> <envar>DBUSER</envar> <envar>HOST</envar>
-<envar>PORT</envar> <envar>DATABASE</envar> <envar>CLUSTER</envar>
-<envar>SLON_BINARY</envar> If any of the above are not set, the script
-asks for configuration information interactively.</para>
+<para>
+ Pour les usages non-interactifs, configurez les variables d'environnement
+ suivantes : <envar>BASEDIR</envar>, <envar>SYSUSR</envar>,
+ <envar>PASSFILE</envar>, <envar>DBUSER</envar>, <envar>HOST</envar>,
+ <envar>PORT</envar>, <envar>DATABASE</envar>, <envar>CLUSTER</envar> et
+ <envar>SLON_BINARY</envar>. Si une seule de ces valeurs n'est pas définie,
+ le script demande les informations de manière interactive.
+</para>
<itemizedlist>
-<listitem><para>
-<envar>BASEDIR</envar> where you want the service directory structure for the slon
-to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem>
-<listitem><para>
-<envar>SYSUSR</envar> the unix user under which the slon (and multilog) process should run.</para></listitem>
-<listitem><para>
-<envar>PASSFILE</envar> location of the <filename>.pgpass</filename> file to be used. (default <filename>~sysusr/.pgpass</filename>)</para></listitem>
-<listitem><para>
-<envar>DBUSER</envar> the postgres user the slon should connect as (default slony)</para></listitem>
-<listitem><para>
-<envar>HOST</envar> what database server to connect to (default localhost)</para></listitem>
-<listitem><para>
-<envar>PORT</envar> what port to connect to (default 5432)</para></listitem>
-<listitem><para>
-<envar>DATABASE</envar> which database to connect to (default dbuser)</para></listitem>
-<listitem><para>
-<envar>CLUSTER</envar> the name of your Slony1 cluster? (default database)</para></listitem>
-<listitem><para>
-<envar>SLON_BINARY</envar> the full path name of the slon binary (default <command>which slon</command>)</para></listitem>
+ <listitem>
+ <para>
+ <envar>BASEDIR</envar>, l'emplacement où la structure du répertoire du
+ service slon sera créée. Il ne faut <emphasis>pas</emphasis> que ce soit
+ le répertoire <filename>/var/service</filename> ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>SYSUSR</envar>, l'utilisateur unix qui lancera le processus slon
+ (et multilog) ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>PASSFILE</envar>, l'emplacement du fichier
+ <filename>.pgpass</filename> (par défaut
+ <filename>~sysusr/.pgpass</filename>) ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>DBUSER</envar>, l'utilisateur postgres que slon doit utiliser (par
+ défaut slony) ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>HOST</envar>, l'adresse du serveur ou slon doit se connecter (par
+ défaut localhost) ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>PORT</envar>, le port de connexion (par défaut 5432) ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>DATABASE</envar>, la base de données sur laquelle slon se connecte
+ (par défaut dbuser)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>CLUSTER</envar>, le nom du cluster Slony1 (par défaut database) ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>SLON_BINARY</envar>, le chemin complet vers le binaire slon (par
+ défaut <command>which slon</command>).
+ </para>
+ </listitem>
</itemizedlist>
+
</sect3>
<sect3><title>logrep-mkservice.sh</title>
-<para>This uses <command>tail -F</command> to pull data from log files allowing
-you to use multilog filters (by setting the CRITERIA) to create
-special purpose log files. The goal is to provide a way to monitor log
-files in near realtime for <quote>interesting</quote> data without either
-hacking up the initial log file or wasting CPU/IO by re-scanning the
-same log repeatedly.
+<para>
+ Ce script utilise <command>tail -F</command> pour extraire des données des
+ journaux applicatifs en vous permettant d'utiliser des filtres multilog (via
+ l'option CRITERIA) afin de créer des journaux de transactions spécifiques.
+ Le but est de fournir un moyen de surveiller les journaux de transactions en
+ temps réel en quête de données <quote>intéressante</quote> sans devoir
+ modifier le journal applicatif initial ou gacher des ressources CPU/IO
+ en parcourant les journaux régulièrement.
</para>
-<para>For non-interactive use, set the following environment
-variables. <envar>BASEDIR</envar> <envar>SYSUSR</envar> <envar>SOURCE</envar>
-<envar>EXTENSION</envar> <envar>CRITERIA</envar> If any of the above are not set,
-the script asks for configuration information interactively.
+<para>
+ Pour une utilisation non interactive, il faut configurer les variables :
+ <envar>BASEDIR</envar>, <envar>SYSUSR</envar>, <envar>SOURCE</envar>,
+ <envar>EXTENSION</envar> et <envar>CRITERIA</envar>. Si une seule de ces
+ options n'est pas définie, le script demande interactivement les informations
+ de configuration.
</para>
<itemizedlist>
-<listitem><para>
-<envar>BASEDIR</envar> where you want the service directory structure for the logrep
-to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem>
-<listitem><para><envar>SYSUSR</envar> unix user under which the service should run.</para></listitem>
-<listitem><para><envar>SOURCE</envar> name of the service with the log you want to follow.</para></listitem>
-<listitem><para><envar>EXTENSION</envar> a tag to differentiate this logrep from others using the same source.</para></listitem>
-<listitem><para><envar>CRITERIA</envar> the multilog filter you want to use.</para></listitem>
+ <listitem>
+ <para>
+ <envar>BASEDIR</envar>, l'emplacement où sera créée la structure du
+ répertoire du service de logrep. Il ne faut <emphasis>pas</emphasis> que
+ ce soit le répertoire <filename>/var/service</filename>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>SYSUSR</envar>, l'utilisateur unix qui lancera le service.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>SOURCE</envar>, le nom du service de log que vous voulez utiliser.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>EXTENSION</envar>, une balise pour différencier ce logrep de ceux
+ qui utilisent la même source.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>CRITERIA</envar>, le filtre multilog que vous voulez utiliser.
+ </para>
+ </listitem>
</itemizedlist>
-<para> A trivial example of this would be to provide a log file of all slon
-ERROR messages which could be used to trigger a nagios alarm.
-<command>EXTENSION='ERRORS'</command>
-<command>CRITERIA="'-*' '+* * ERROR*'"</command>
-(Reset the monitor by rotating the log using <command>svc -a $svc_dir</command>)
+<para>
+ Un exemple trivial consiste à produire un journal applicatif de tous les
+ messages d'erreur slon qui pourraient être utilisés pour déclencher une
+ alerte nagios :
+ <command>EXTENSION='ERRORS'</command>
+ <command>CRITERIA="'-*' '+* * ERROR*'"</command>
+ (on relance la surveillance en déclenchant une rotation des journaux
+ applicatifs avec <command>svc -a $svc_dir</command>)
</para>
-<para> A more interesting application is a subscription progress log.
-<command>EXTENSION='COPY'</command>
-<command>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</command>
+<para>
+ Une application plus intéressante est la surveillance de la progression
+ d'une souscription d'un nœud :
+ <command>EXTENSION='COPY'</command>
+ <command>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</command>
</para>
-<para>If you have a subscription log then it's easy to determine if a given
-slon is in the process of handling copies or other subscription activity.
-If the log isn't empty, and doesn't end with a
-<command>"CONFIG enableSubscription: sub_set:1"</command>
-(or whatever set number you've subscribed) then the slon is currently in
-the middle of initial copies.</para>
+<para>
+ Si vous avez une trace d'abonnement, alors il est facile de déterminer si un
+ nœud donné est en train de réaliser une copie ou une autre activité de
+ souscription. Si les journaux applicatifs ne sont pas vide et ne se terminent
+ pas par <command>"CONFIG enableSubscription: sub_set:1"</command> (où 1 est
+ le numéro d'ensemble de réplication que vous avez abonné) alors le slon est
+ au milieu d'une copie initiale.
+</para>
-<para> If you happen to be monitoring the mtime of your primary slony logs to
-determine if your slon has gone brain-dead, checking this is a good way
-to avoid mistakenly clobbering it in the middle of a subscribe. As a bonus,
-recall that since the the slons are running under svscan, you only need to
-kill it (via the svc interface) and let svscan start it up again laster.
-I've also found the COPY logs handy for following subscribe activity
-interactively.</para>
+<para>
+ Si vous surveillez l'horodatage de modification du journal applicatif de
+ votre nœud primaire pour déterminer si le slon est tombé dans le coma,
+ vérifier cette trace d'abonnement est un bon moyen d'éviter de stopper le
+ nœud alors qu'un abonnement est en cours. En bonus, puisque les slons
+ utilisent svscan, vous pouvez simplement détruire le fichier (via l'interface
+ svc) et laisser svscan le recommencer plus tard. J'ai également découvert que
+ les traces de COPY sont pratiques pour suivre de manière interactive
+ l'activité des abonnements.
+</para>
+
</sect3>
</sect2>
Modified: traduc/branches/slony_1_2/monitoring.xml
===================================================================
--- traduc/branches/slony_1_2/monitoring.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/monitoring.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -8,164 +8,295 @@
<title>Surveillance</title>
<indexterm><primary>Surveiller &slony1;</primary></indexterm>
-<para> As a prelude to the discussion, it is worth pointing out that
-since the bulk of &slony1; functionality is implemented via running
-database functions and SQL queries against tables within a &slony1;
-schema, most of the things that one might want to monitor about
-replication may be found by querying tables in the schema created for
-the cluster in each database in the cluster. </para>
+<para>
+ Comme prélude à la discussion, il est intéressant de pointer que comme
+ le corps de des fonctionnalités &slony1; est implanté via des fonctions
+ stockées dans la base de données et via les tables comprises dans le
+ schéma &slony1;, la majorité de la surveillance peut se faire en
+ exécutant des requêtes sur les tables du schéma pour chaque base de
+ données du cluster.
+</para>
-<para> Here are some of the tables that contain information likely to
-be particularly interesting from a monitoring and diagnostic
-perspective.</para>
+<para>
+ Voici une liste des tables contenant une information particulièrement
+ intéressante d'un point de vue surveillance et diagnostique.
+</para>
<glosslist>
-<glossentry><glossterm><envar>sl_status</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>sl_status</envar></glossterm>
-<glossdef><para>This view is the first, most obviously useful thing to
-look at from a monitoring perspective. It looks at the local node's
-events, and checks to see how quickly they are being confirmed on
-other nodes.</para>
+ <glossdef>
+ <para>
+ Cette vue est à coup sûr la plus utile pour surveiller l'activité
+ de la réplication. Elle regarde les événements du nœud local
+ et vérifie à quelle vitesse ils sont confirmés sur les autres
+ nœuds.
+ </para>
-<para> The view is primarily useful to run against an origin
-(<quote>master</quote>) node, as it is only there where the events
-generated are generally expected to require interesting work to be
-done. The events generated on non-origin nodes tend to
-be <command>SYNC</command> events that require no replication work be
-done, and that are nearly no-ops, as a
-result. </para></glossdef></glossentry>
+ <para>
+ Cette vue est principalement utile sur le nœud origine
+ (le <quote>maître</quote>) car c'est seulement sur ce nœud que
+ les événements nécessitent du travail. Les événements générés sur les
+ autres nœuds sont généralements des événements de synchronisation
+ qui ne réclame pas de travail de réplication. Ce sont pratiquement des
+ opérations vides.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slconfirm;</glossterm>
+ <glossentry>
+ <glossterm>&slconfirm;</glossterm>
-<glossdef><para>Contains confirmations of replication events; this may be used to infer which events have, and <emphasis>have not</emphasis> been processed.</para></glossdef></glossentry>
+ <glossdef>
+ <para>
+ Contient les confirmations des événements de réplication ; ceci
+ peut ensuite être utilisé pour inférer les événements traités et
+ surtout ceux qui <emphasis>ne sont pas encore</emphasis> traités.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slevent;</glossterm>
-<glossdef><para>Contains information about the replication events processed on the local node. </para></glossdef></glossentry>
+ <glossentry>
+ <glossterm>&slevent;</glossterm>
+
+ <glossdef>
+ <para>
+ Contient des informations sur les événements de réplication traités
+ sur le nœud local.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>
-&sllog1;
-and
-&sllog2;
-</glossterm>
+ <glossentry>
+ <glossterm>&sllog1; et &sllog2;</glossterm>
-<glossdef><para>These tables contain replicable data. On an origin node, this is the <quote>queue</quote> of data that has not necessarily been replicated everywhere. By examining the table, you may examine the details of what data is replicable. </para></glossdef></glossentry>
+ <glossdef>
+ <para>
+ Ces tables contiennent des données réplicables. Sur un nœud
+ origine, node, cela représente la <quote>queue</quote> des données
+ qui ne sont pas nécessairement répliquées partout. En examinant cette
+ table, vous pouvez examiner le détail des données réplicables.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slnode;</glossterm>
-<glossdef><para>The list of nodes in the cluster.</para></glossdef></glossentry>
+ <glossentry>
+ <glossterm>&slnode;</glossterm>
+
+ <glossdef>
+ <para>
+ La liste des nœuds du cluster.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slpath;</glossterm>
-<glossdef><para>This table holds connection information indicating how &lslon; processes are to connect to remote nodes, whether to access events, or to request replication data. </para></glossdef></glossentry>
+ <glossentry>
+ <glossterm>&slpath;</glossterm>
+
+ <glossdef>
+ <para>
+ Cette table contient les informations de connexion. Elle indique comment
+ les processus &lslon; peuvent se connecter aux nœuds distants, que
+ ce soit pour accéder aux événements ou pour réclamer les données
+ réplicables.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&sllisten;</glossterm>
+ <glossentry>
+ <glossterm>&sllisten;</glossterm>
-<glossdef><para>This configuration table indicates how nodes listen
-for events coming from other nodes. Usually this is automatically
-populated; generally you can detect configuration problems by this
-table being <quote>underpopulated.</quote> </para></glossdef></glossentry>
+ <glossdef>
+ <para>
+ Cette configuration indique comment les nœuds écoutent les
+ événements en provenance des autres nœuds. Généralement,
+ cette table est peuplée automatiquement ; vous pouvez
+ détecter des problèmes de configuration si cette table est
+ <quote>sous-peuplée</quote>.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slregistry;</glossterm>
+ <glossentry>
+ <glossterm>&slregistry;</glossterm>
-<glossdef><para>A configuration table that may be used to store
-miscellaneous runtime data. Presently used only to manage switching
-between the two log tables. </para></glossdef></glossentry>
+ <glossdef>
+ <para>
+ Une table de configuration qui peut être utilisée pour stocker
+ différentes données à l'exécution. Actuellement seulement utilisée
+ pour férer la bascule entre les deux tables de log.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slseqlog;</glossterm>
+ <glossentry>
+ <glossterm>&slseqlog;</glossterm>
-<glossdef><para>Contains the <quote>last value</quote> of replicated
-sequences.</para></glossdef></glossentry>
+ <glossdef>
+ <para>
+ Contient la <quote>dernière valeur</quote> des séquences répliquées.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slset;</glossterm>
+ <glossentry>
+ <glossterm>&slset;</glossterm>
-<glossdef><para>Contains definition information for replication sets,
-which is the mechanism used to group together related replicable
-tables and sequences.</para></glossdef></glossentry>
+ <glossdef>
+ <para>
+ Contient la définition des ensembles de réplication. C'est le mécanisme
+ utilisé pour grouper les tables et séquences réplicables.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slsetsync;</glossterm>
-<glossdef><para>Contains information about the state of synchronization of each replication set, including transaction snapshot data.</para></glossdef></glossentry>
+ <glossentry>
+ <glossterm>&slsetsync;</glossterm>
+
+ <glossdef>
+ <para>
+ Contient des informations sur l'état de la synchronisation pour chaque
+ ensemble de réplication, ceci incluant les données des images de
+ transaction.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&slsubscribe;</glossterm>
-<glossdef><para>Indicates what subscriptions are in effect for each replication set.</para></glossdef></glossentry>
+ <glossentry>
+ <glossterm>&slsubscribe;</glossterm>
+
+ <glossdef>
+ <para>
+ Indique quels abonnements sont effectifs pour chaque ensemble de
+ réplication.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry><glossterm>&sltable;</glossterm>
-<glossdef><para>Contains the list of tables being replicated.</para></glossdef></glossentry>
-
+ <glossentry>
+ <glossterm>&sltable;</glossterm>
+
+ <glossdef>
+ <para>
+ Contient la liste des tables en cours de réplication.
+ </para>
+ </glossdef>
+ </glossentry>
</glosslist>
-<sect2 id="testslonystate"> <title> test_slony_state</title>
+<sect2 id="testslonystate">
+<title>test_slony_state</title>
+<indexterm><primary>script test_slony_state pour tester l'état de la réplication</primary></indexterm>
-<indexterm><primary>script test_slony_state to test replication state</primary></indexterm>
+<para>
+ Ce script indispensable réalise différentes sortes d'analyse de l'état d'un
+ cluster &slony1;. Les <xref linkend="bestpractices"/> de &slony1; recommendent
+ l'exécution de ces scripts fréquemment (toutes les heures est une bonne idée)
+ pour découvrir les problèmes aussi rapidement que possible.
+</para>
-<para> This invaluable script does various sorts of analysis of the
-state of a &slony1; cluster. &slony1; <xref linkend="bestpractices"/>
-recommend running these scripts frequently (hourly seems suitable) to
-find problems as early as possible. </para>
+<para>
+ Vous pouvez spécifier les arguments en incluant <option>database</option>,
+ <option>host</option>, <option>user</option>,
+ <option>cluster</option>, <option>password</option> et
+ <option>port</option> pour vous connecter à un nœud du cluster. Vous
+ pouvez aussi indiquer une commande <option>mailprog</option> (qui doit être
+ un équivalent de l'application <productname>Unix</productname>
+ <application>mailx</application>) et un destinataire des messages.
+</para>
-<para> You specify arguments including <option>database</option>,
-<option>host</option>, <option>user</option>,
-<option>cluster</option>, <option>password</option>, and
-<option>port</option> to connect to any of the nodes on a cluster.
-You also specify a <option>mailprog</option> command (which should be
-a program equivalent to <productname>Unix</productname>
-<application>mailx</application>) and a recipient of email. </para>
+<para>
+ Autrement, vous pouvez spécifier les paramètres de connexion à la base de
+ données via les variables d'environnement utilisées par
+ <application>libpq</application>, <emphasis>c'est-à-dire</emphasis> en
+ utilisant <envar>PGPORT</envar>, <envar>PGDATABASE</envar>,
+ <envar>PGUSER</envar>, <envar>PGSERVICE</envar> et ainsi de suite.
+</para>
-<para> You may alternatively specify database connection parameters
-via the environment variables used by
-<application>libpq</application>, <emphasis>e.g.</emphasis> - using
-<envar>PGPORT</envar>, <envar>PGDATABASE</envar>,
-<envar>PGUSER</envar>, <envar>PGSERVICE</envar>, and such.</para>
+<para>
+ Le script parcourt <xref linkend="table.sl-path"/> pour trouver tous les
+ nœuds du cluster et les DSN pour lui permettre de se connecter à
+ chacun d'entre eux.
+</para>
-<para> The script then rummages through <xref linkend="table.sl-path"/>
-to find all of the nodes in the cluster, and the DSNs to allow it to,
-in turn, connect to each of them.</para>
+<para>
+ Pour chaque nœ, the script examine l'état de différents éléments,
+ dont :
+</para>
-<para> For each node, the script examines the state of things,
-including such things as:
-
<itemizedlist>
-<listitem><para> Checking <xref linkend="table.sl-listen"/> for some
-<quote>analytically determinable</quote> problems. It lists paths
-that are not covered.</para></listitem>
+ <listitem>
+ <para>
+ Vérification de <xref linkend="table.sl-listen"/> sur certains
+ problèmes <quote>analytiquement déterminables</quote>. Il liste
+ les chemins non couverts.
+ </para>
+ </listitem>
-<listitem><para> Providing a summary of events by origin node</para>
+ <listitem>
+ <para>
+ Rapport des événements par nœud d'origine.
+ </para>
-<para> If a node hasn't submitted any events in a while, that likely
-suggests a problem.</para></listitem>
+ <para>
+ Si un nœud n'a pas soumis d'événements depuis un moment, cela suggère
+ un problème.
+ </para>
+ </listitem>
-<listitem><para> Summarizes the <quote>aging</quote> of table <xref
-linkend="table.sl-confirm"/> </para>
+ <listitem>
+ <para>
+ Résumé de l'<quote>âge</quote> de la table <xref linkend="table.sl-confirm"/>
+ </para>
-<para> If one or another of the nodes in the cluster hasn't reported
-back recently, that tends to lead to cleanups of tables like &sllog1;,
-&sllog2; and &slseqlog; not taking place.</para></listitem>
+ <para>
+ Si un des nœuds du cluster ne s'est pas manifesté récemment, cela fait que
+ tables comme &sllog1;, &sllog2; et &slseqlog; ne sont plus nettoyées.
+ </para>
+ </listitem>
-<listitem><para> Summarizes what transactions have been running for a
-long time</para>
+ <listitem>
+ <para>
+ Résumé des transactions longues
+ </para>
-<para> This only works properly if the statistics collector is
-configured to collect command strings, as controlled by the option
-<option> stats_command_string = true </option> in <filename>
-postgresql.conf </filename>.</para>
+ <para>
+ Ceci fonctionne seulement si le collecteur de statistiques est configuré
+ pour récupérer les requêtes en cours d'exécution, option contrôlée par
+ le paramètre <option>stats_command_string</option> du fichier
+ <filename>postgresql.conf</filename>.
+ </para>
-<para> If you have broken applications that hold connections open,
-this will find them.</para>
+ <para>
+ Si vous avez des applications qui maintiennent anormalement des connexions
+ ouvertes, le script les trouvera.
+ </para>
-<para> If you have broken applications that hold connections open,
-that has several unsalutory effects as <link
-linkend="longtxnsareevil"> described in the
-FAQ</link>.</para></listitem>
+ <para>
+ Si vous avez des applications qui maintiennent anormalement des connexions
+ ouvertes, cela aura des effets néfastes comme ceux <link
+ linkend="longtxnsareevil">décrits dans la FAQ</link>.
+ </para>
+ </listitem>
+</itemizedlist>
-</itemizedlist></para>
+<para>
+ Le script réalise un travail de diagnostique se basant sur les paramètres
+ du script ; si vous n'aimez pas les valeurs par défaut, n'hésitez pas
+ à les modifier !
+</para>
-<para> The script does some diagnosis work based on parameters in the
-script; if you don't like the values, pick your favorites!</para>
+<note>
+ <para>
+ Notez qu'il existe deux versions, une utilisant le module Perl
+ <quote>classic</quote> <filename>Pg.pm</filename> pour accéder aux bases de
+ données &postgres; et une, dont le nom contient <filename>dbi</filename>,
+ qui utilise la nouvelle interface <function> DBI</function> de Perl.
+ Il sera plus facile de trouver des packages pour<function>DBI</function>.
+ </para>
+</note>
-<note><para> Note that there are two versions, one using the
-<quote>classic</quote> <filename>Pg.pm</filename> Perl module for
-accessing &postgres; databases, and one, with <filename>dbi</filename>
-in its name, that uses the newer Perl <function> DBI</function>
-interface. It is likely going to be easier to find packaging for
-<function>DBI</function>. </para> </note>
-
</sect2>
<sect2>
@@ -476,13 +607,12 @@
Le script <filename>mkmediawiki.pl </filename>, situé dans
<filename>tools</filename>, peut être utilisé pour générer un rapport de
surveillance du cluster compatible avec le populaire logiciel <ulink
- url="http://www.mediawiki.org/">MediaWiki</ulink>. Note that the
- <option>--categories</option> permits the user to specify a set of
- (comma-delimited) categories with which to associate the output. If
- you have a series of &slony1; clusters, passing in the option
- <option>--categories=slony1</option> leads to the MediaWiki instance
- generating a category page listing all &slony1; clusters so
- categorized on the wiki.
+ url="http://www.mediawiki.org/">MediaWiki</ulink>. Notons que l'option
+ <option>--categories</option> permet à l'utilisateur de préciser un ensemble
+ de catégories (séparées par une virgule) qui seront associées aux résultats.
+ Si vous avez passer l'option <option>--categories=slony1</option> à une série
+ de clusters &slony1;, cela entraînera la création d'une page catégorie
+ répertoriant l'ensemble des clusters &slony1;.
</para>
<para>
@@ -508,10 +638,12 @@
</sect2>
<sect2>
-<title> Analysis of a SYNC </title>
+<title>Analyse d'un SYNC</title>
-<para> The following is (as of 2.0) an extract from the &lslon; log for node
-#2 in a run of <quote>test1</quote> from the <xref linkend="testbed"/>. </para>
+<para>
+ Ce qui suit est un extrait du log &lslon; (version 2.0) pour le nœud
+ #2 dans une exécution de <quote>test1</quote> à partir de <xref linkend="testbed"/>.
+</para>
<screen>
DEBUG2 remoteWorkerThread_1: SYNC 19 processing
@@ -530,56 +662,96 @@
INFO remoteWorkerThread_1: SYNC 19 sync_event timing: pqexec (s/count)- provider 0.001/1 - subscriber 0.004/1 - IUD 0.972/248
</screen>
-<para> Here are some notes to interpret this output: </para>
+<para>
+ Voici quelques notes pour interpréter cet affichage :
+</para>
<itemizedlist>
-<listitem><para> Note the line that indicates <screen>inserts=144 updates=1084 deletes=0</screen> </para>
-<para> This indicates how many tuples were affected by this particular SYNC. </para></listitem>
-<listitem><para> Note the line indicating <screen>0.028 seconds delay for first row</screen></para>
+ <listitem>
+ <para>
+ Notez la ligne qui indique
+ <screen>inserts=144 updates=1084 deletes=0</screen>
+ </para>
+
+ <para>
+ Ceci indique le nombre de lignes touchées par ce SYNC.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Notez la ligne qui indique
+ <screen>0.028 seconds delay for first row</screen>
+ </para>
-<para> This indicates the time it took for the <screen>LOG
-cursor</screen> to get to the point of processing the first row of
-data. Normally, this takes a long time if the SYNC is a large one,
-and one requiring sorting of a sizable result set.</para></listitem>
+ <para>
+ Ceci indique le temps que <screen>LOG cursor</screen> a pris pour
+ traiter la première ligne de données. Habituellement, ceci prend du
+ temps si le SYNC est important et nécessite un tri d'un ensemble
+ de résultats.
+ </para>
+ </listitem>
-<listitem><para> Note the line indicating <screen>0.978 seconds until
-close cursor</screen></para>
+ <listitem>
+ <para>
+ Notez la ligne qui indique
+ <screen>0.978 seconds until close cursor</screen>
+ </para>
-<para> This indicates how long processing took against the
-provider.</para></listitem>
+ <para>
+ Ceci indique la durée du traitement par le fournisseur.
+ </para>
+ </listitem>
-<listitem><para> sync_helper timing: large tuples 0.315/288 </para>
+ <listitem>
+ <para>sync_helper timing: large tuples 0.315/288</para>
-<para> This breaks off, as a separate item, the number of large tuples
-(<emphasis>e.g.</emphasis> - where size exceeded the configuration
-parameter <xref linkend="slon-config-max-rowsize"/>) and where the
-tuples had to be processed individually. </para></listitem>
+ <para>
+ Cet élément séparé est le nombre de grosses lignes
+ (<emphasis>c'est-à-dire</emphasis> dont la taille dépasse la valeur du
+ paramètre de configuration <xref linkend="slon-config-max-rowsize"/>).
+ Ces lignes ont été traités individuellement.
+ </para>
+ </listitem>
-<listitem><para> <screen>SYNC 19 done in 1.272 seconds</screen></para>
+ <listitem>
+ <para><screen>SYNC 19 done in 1.272 seconds</screen></para>
-<para> This indicates that it took 1.272 seconds, in total, to process
-this set of SYNCs. </para>
-</listitem>
+ <para>
+ Ceci indique qe le traitement a pris au total 1.272 secondes pour cet
+ ensemble de SYNC.
+ </para>
+ </listitem>
-<listitem><para> <screen>SYNC 19 sync_event timing: pqexec (s/count)- provider 0.001/1 - subscriber 0.004/0 - IUD 0.972/248</screen></para>
+ <listitem>
+ <para>
+ <screen>SYNC 19 sync_event timing: pqexec (s/count)- provider 0.001/1 - subscriber 0.004/0 - IUD 0.972/248</screen>
+ </para>
-<para> This records information about how many queries were issued
-against providers and subscribers in function
-<function>sync_event()</function>, and how long they took. </para>
+ <para>
+ Ceci enregistre une information sur le nombre de requêtes lancées sur les
+ fournisseurs et abonnés dans la fonction <function>sync_event()</function>
+ ainsi que le temps pris pour cela.
+ </para>
-<para> Note that 248 does not match against the numbers of inserts,
-updates, and deletes, described earlier, as I/U/D requests are
-clustered into groups of queries that are submitted via a single
-<function>pqexec()</function> call on the
-subscriber. </para></listitem>
+ <para>
+ Notez que 248 ne correspond pas aux nombres d'INSERT/UPDATE/DELETE
+ décrits précédemment car ces requêtes sont groupées pour être soumises
+ via un seul appel à <function>pqexec()</function> sur le fournisseur.
+ </para>
+ </listitem>
-<listitem><para> <screen>sync_helper timing: pqexec (s/count)- provider 0.063/6 - subscriber 0.000/6</screen></para>
+ <listitem>
+ <para>
+ <screen>sync_helper timing: pqexec (s/count)- provider 0.063/6 - subscriber 0.000/6</screen>
+ </para>
-<para> This records information about how many queries were issued
-against providers and subscribers in function
-<function>sync_helper()</function>, and how long they took.
-</para></listitem>
-
+ <para>
+ Ceci enregistre l'information du nombre de requêtes exécutées sur les
+ fournisseurs et les abonnés dans la fonction <function>sync_helper()</function>,
+ ainsi que le temps pris pour cela.
+ </para>
+ </listitem>
</itemizedlist>
</sect2>
Modified: traduc/branches/slony_1_2/prerequisites.xml
===================================================================
--- traduc/branches/slony_1_2/prerequisites.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/prerequisites.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -19,9 +19,9 @@
FreeBSD-5X-i386, FreeBSD-5X-alpha, OS-X-10.3, Linux-2.4X-i386, Linux-2.6X-i386,
Linux-2.6X-amd64, <trademark>Solaris</trademark>-2.8-SPARC,
<trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1 et 5.3, OpenBSD-3.5-sparc64
- et &windows; 2000, XP et 2003 (32 bit). There
- is enough diversity amongst these platforms that nothing ought to
- prevent running &slony1; on other similar platforms.
+ et &windows; 2000, XP et 2003 (32 bit). Il existe suffisamment de diversité
+ parmi ces plateformes que rien ne semble empêcher l'exécution de &slony1; sur
+ des plateformes similaires.
</para>
<sect2>
@@ -98,9 +98,9 @@
</para>
<para>
- There is variation between what versions of &postgres; are
- compatible with what versions of &slony1;. See <xref
- linkend="installation"/> for more details.
+ Il existe des différences entre les versions de &postgres; compatibles
+ avec les versions de &slony1;. Voir <xref linkend="installation"/> pour
+ plus de détails.
</para>
</listitem>
Modified: traduc/branches/slony_1_2/releasechecklist.xml
===================================================================
--- traduc/branches/slony_1_2/releasechecklist.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/releasechecklist.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -104,7 +104,8 @@
soit pas inclus dans la compilation.
</para>
<para>
- Does not need to be done by hand - the later <command> make distclean </command> step does this for you.
+ Ceci n'a pas besoin d'être fait manuellement. Une des étapes suivantes,
+ <command>make distclean</command>, le fait pour vous.
</para>
</listitem>
@@ -114,7 +115,8 @@
<command>find . -name .cvsignore | xargs rm</command>
</para>
<para>
- Does not need to be done by hand - the later <command> make distclean </command> step does this for you.
+ Ceci n'a pas besoin d'être fait manuellement. Une des étapes suivantes,
+ <command>make distclean</command>, le fait pour vous.
</para>
</listitem>
@@ -192,7 +194,7 @@
</para>
<para>
- Slightly better may be
+ Une commande un peu meilleure serait
<command>./configure && make src/slon/conf-file.c src/slonik/parser.c src/slonik/scan.c</command>
</para>
</listitem>
@@ -208,10 +210,10 @@
</para>
<para>
- Note that <command>make distclean</command> also clears out
- <filename>.cvsignore</filename> files and
- <filename>autom4te.cache</filename>, thus obsoleting some former steps
- that suggested that it was needful to delete them.
+ Notez que <command>make distclean</command> efface aussi les fichiers
+ <filename>.cvsignore</filename> et <filename>autom4te.cache</filename>,
+ rendant du coup obsolète certaines des premières étapes qui suggéraient
+ qu'il était utile de les supprimer.
</para>
</listitem>
Modified: traduc/branches/slony_1_2/reshape.xml
===================================================================
--- traduc/branches/slony_1_2/reshape.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/reshape.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -65,10 +65,10 @@
<listitem>
<para>
- After performing the configuration change, you should, as <xref
- linkend="bestpractices"/>, run the <eststate; scripts in order to
- validate that the cluster state remains in good order after this
- change.
+ Après avoir exécuté les modifications de configuration, vous devez,
+ comme l'indiquent <xref
+ linkend="bestpractices"/>, exécuter les scripts <eststate; pour
+ valider que l'état du cluster reste en bon état après ce changement.
</para>
</listitem>
Modified: traduc/branches/slony_1_2/slon.xml
===================================================================
--- traduc/branches/slony_1_2/slon.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/slon.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -67,13 +67,13 @@
<para>
Les cinq premiers niveaux de débogage (de Fatal à Info) sont
- <emphasis>toujours</emphasis> affichés dans les traces. In
- early versions of &slony1;, the <quote>suggested</quote>
- <envar>log_level</envar> value was 2, which would list output at
- all levels down to debugging level 2. In &slony1; version 2, it
- is recommended to set <envar>log_level</envar> to 0; most of the
- consistently interesting log information is generated at levels
- higher than that.
+ <emphasis>toujours</emphasis> affichés dans les traces. Dans les
+ précédentes versions de &slony1;, la valeur <quote>suggérée</quote>
+ pour <envar>log_level</envar> était 2, qui fournit toutes les traces
+ jusqu'au niveau de débogage 2. Dans &slony1; version 2, il est
+ recommandé de configurer <envar>log_level</envar> à 0 ; la
+ plupart des informations intéressantes dans les traces est générée
+ à des niveaux supérieurs.
</para>
</listitem>
</varlistentry>
Modified: traduc/branches/slony_1_2/slonconf.xml
===================================================================
--- traduc/branches/slony_1_2/slonconf.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/slonconf.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -106,12 +106,13 @@
<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é. In &slony1; version 2, a lot of log message levels have
- been revised in an attempt to ensure the <quote>interesting
- stuff</quote> comes in at CONFIG/INFO levels, so that you
- could run at level 0, omitting all of the <quote>DEBUG</quote>
- messages, and still have meaningful contents in the
- logs.</para>
+ 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>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 journaux applicatifs.</para>
</listitem>
</varlistentry>
@@ -139,10 +140,11 @@
<para>Détermine si l'horodatage de chaque événement doit
apparaître dans chaque ligne du journal applicatif.</para>
- <para> Note that if <envar>syslog</envar> usage is configured,
- then this is ignored; it is assumed that
- <application>syslog</application> will be supplying
- timestamps, and timestamps are therefore suppressed.
+ <para>
+ Notez que si l'utilisation de <envar>syslog</envar> est configuré,
+ alors ceci est ignoré ; il est supposé que
+ <application>syslog</application> fournira des horodatages, ce qui
+ fait cet horodatage est supprimé car inutile.
</para>
</listitem>
</varlistentry>
@@ -303,12 +305,13 @@
Valeurs possibles : de 10 à 60000, La valeur par défaut est 100.
</para>
- <para> This parameter is primarily of concern on nodes that
- originate replication sets. On a non-origin node, there
- will never be update activity that would induce a SYNC;
- instead, the timeout value described below will induce a
- SYNC every so often <emphasis>despite absence of changes to
- replicate.</emphasis> </para>
+ <para>
+ Ce paramètre est principalement intéressant sur les nœuds origines
+ des ensembles de réplication. Sur les autres nœuds, il n'y aura
+ pas d'activité de mise à jour qui pourrait induire un SYNC ; à
+ la place, le délai décrit ci-dessous induit un SYNC à cette fréquence
+ <emphasis>même en absence de modifications du réplicat</emphasis>.
+ </para>
</listitem>
</varlistentry>
@@ -340,40 +343,45 @@
Valeurs possibles : [0-120000]. Valeur par défaut : 1000.
</para>
- <para> This parameter is likely to be primarily of concern on
- nodes that originate replication sets, though it does affect
- how often events are generated on other nodes.</para>
+ <para>
+ Ce paramètre peut rapidement devenir important pour les nœuds
+ orgines bien qu'il affecte la façon dont les événements sont générés
+ sur les autes nœuds.
+ </para>
<para>
- On a non-origin node, there never is activity to cause a
- SYNC to get generated; as a result, there will be a SYNC
- generated every <envar>sync_interval_timeout</envar>
- milliseconds. There are no subscribers looking for those
- SYNCs, so these events do not lead to any replication
- activity. They will, however, clutter sl_event up a little,
- so it would be undesirable for this timeout value to be set
- too terribly low. 120000ms represents 2 minutes, which is
- not a terrible value.
+ Sur un nœud qui n'est pas une origine, il n'y a aucune activité
+ réclamant la génération d'un SYNC ; du coup, il va y avoir un
+ SYNC généré chaque <envar>sync_interval_timeout</envar> milli-secondes.
+ Il n'y a pas d'abonnés cherchant ces SYNC, donc ces événements ne
+ vont pas déclencher une activité de réplication. Par contre, ils
+ vont occuper sl_event un moment, donc il est fortement indésirable
+ que cette valeur soit basse. 120000ms représente 2 minutes, ce qui
+ n'est pas une mauvaise valeur.
</para>
- <para> The two values function together in varying ways: </para>
+ <para>
+ Les deux valeurs fonctionnent ensemble de façon différente :
+ </para>
- <para> On an origin node, <envar>sync_interval</envar> is
- the <emphasis>minimum</emphasis> time period that will be
- covered by a SYNC, and during periods of heavy application
- activity, it may be that a SYNC is being generated
- every <envar>sync_interval</envar> milliseconds. </para>
+ <para>
+ Sur un nœud origine, <envar>sync_interval</envar> est la période
+ de temps <emphasis>minimum</emphasis> qui sera couverte par un SYNC,
+ et, durant les périodes de grosse activité, il se pourrait qu'un
+ SYNC soit généré toutes les <envar>sync_interval</envar> millisecondes.
+ </para>
- <para> On that same origin node, there may be quiet intervals,
- when no replicatable changes are being submitted. A SYNC will
- be induced, anyways,
- every <envar>sync_interval_timeout</envar>
- milliseconds. </para>
+ <para>
+ Sur le même nœud origine, il peut y avoir des intervalles assez
+ calmes, quand aucune modification réplicable de données n'est soumise.
+ Un SYNC aura quand meme lieu, chaque <envar>sync_interval_timeout</envar>
+ millisecondes.
+ </para>
- <para> On a subscriber node that does not originate any sets,
- only the <quote>timeout-induced</quote> SYNCs will
- occur. </para>
-
+ <para>
+ Sur un nœud abonné qui n'est l'origine d'aucun ensemble, seuls
+ des SYNC <quote>de délai</quote> seront générés.
+ </para>
</listitem>
</varlistentry>
@@ -385,19 +393,17 @@
</term>
<listitem>
<para>
- Maximum number of <command>SYNC</command> events that a
- subscriber node will group together when/if a subscriber
- falls behind. <command>SYNC</command>s are batched only if
- there are that many available and if they are
- contiguous. Every other event type in between leads to a
- smaller batch. And if there is only
- one <command>SYNC</command> available, even though you used
- <option>-g600</option>, the &lslon; will apply just the one
- that is available. As soon as a subscriber catches up, it
- will tend to apply each
- <command>SYNC</command> by itself, as a singleton, unless
- processing should fall behind for some reason. Range:
- [0,10000], default: 20
+ Nombre maximum d'événements <command>SYNC</command> qu'un nœud
+ abonné groupera ensemble quand/si un abonné accuse trop de retard. Les
+ <command>SYNC</command> sont seulement groupés s'il sont trop nombreux
+ et s'ils sont contigus. Tout autre type d'événement inséré entre
+ entrainera la création d'un groupe plus petit. Et si un seul
+ <command>SYNC</command> est disponible, alors que vous avez utilisé
+ l'option <option>-g600</option>, &lslon; n'appliquera que celui qui
+ est disponible. Dès que l'abonné a rattrapé son retard, il cherchera
+ à appliquer chaque <command>SYNC</command> séparément, en solo, sauf si
+ le traitement entraîne à nouveau un retard.
+ Valeurs possibles : [0,10000]. Valeur par défaut : 20.
</para>
</listitem>
</varlistentry>
@@ -419,34 +425,36 @@
</varlistentry>
<varlistentry id="slon-config-cleanup-interval" xreflabel="slon_config_cleanup_interval">
- <term><varname>cleanup_interval</varname> (<type>interval</type>)</term>
+ <term><varname>cleanup_interval</varname> (<type>interval</type>)
<indexterm>
- <primary><varname>cleanup_interval</varname> configuration parameter</primary>
+ <primary>paramètre de configuration <varname>cleanup_interval</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
- Controls how quickly old events are trimmed out. That
- subsequently controls when the data in the log tables,
- <envar>sl_log_1</envar> and <envar>sl_log_2</envar>, get
- trimmed out. Default: '10 minutes'.
+ Contrôle à quelle fréquence les vieux événements doivent être effacés.
+ 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'.
</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-cleanup-deletelogs" xreflabel="slon_conf_cleanup_deletelogs">
- <term><varname>cleanup_deletelogs</varname> (<type>boolean</type>)</term>
+ <term><varname>cleanup_deletelogs</varname> (<type>booléen</type>)
<indexterm>
- <primary><varname>cleanup_deletelogs</varname> configuration parameter</primary>
+ <primary>paramètre de configuration <varname>cleanup_deletelogs</varname></primary>
</indexterm>
+ </term>
<listitem>
<para>
- Controls whether or not we use DELETE to trim old data from the log tables,
- <envar>sl_log_1</envar> and <envar>sl_log_2</envar>.
- Default: false
+ 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.
</para>
</listitem>
</varlistentry>
-
+
<varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
<term><varname>desired_sync_time</varname> (<type>entier</type>)
<indexterm>
Modified: traduc/branches/slony_1_2/slonik_ref.xml
===================================================================
--- traduc/branches/slony_1_2/slonik_ref.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/slonik_ref.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -84,9 +84,12 @@
<para>Ces commandes sont regroupées ensemble au sein d'une transaction
pour chaque nœud participant.</para>
- <para> Note that this does not enforce grouping of the actions as
- a single transaction on all nodes. For instance, consider the
- following slonik code:</para>
+ <para>
+ Notez que ceci ne force par le groupement des actions sur une seule
+ transaction pour tous les nœuds. Par exemple, jetez un œil
+ au code slonik suivant :
+ </para>
+
<programlisting>
try {
execute script (set id = 1, filename = '/tmp/script1.sql', event node=1);
@@ -94,12 +97,13 @@
}
</programlisting>
- <para> This <emphasis>would</emphasis> be processed within a
- single BEGIN/COMMIT on node 1. However, the requests are
- separated into two <command>DDL_SCRIPT</command> events so that
- each will be run individually, in separate transactions, on other
- nodes in the cluster. </para>
-
+ <para>
+ Ceci <emphasis>pourrait</emphasis> être taitré dans une transaction
+ simple sur le nœud 1. Néanmoins, les requêtes sont séparées en
+ deux événements <command>DDL_SCRIPT</command> de façon à ce que chacune
+ d'elle soit exécutée individuellement, dans des transactions séparées,
+ sur les autres nœuds du cluster.
+ </para>
</sect3>
</sect2>
</sect1>
@@ -434,12 +438,14 @@
tables à l'intérieur ; aucun objet public ne doit être verrouillé
pendant l'exécution de cette commande.</para>
- <note> <para> Be aware that some objects are created that contain
- the cluster name as part of their name. (Notably, partial indexes
- on <envar>sl_log_1</envar> and <envar>sl_log_2</envar>.) As a
- result, <emphasis>really long</emphasis> cluster names are a bad
- idea, as they can make object names <quote>blow up</quote> past the
- typical maximum name length of 63 characters. </para> </note>
+ <note> <para>Soyez conscients que certains objets qui sont créés contiennent
+ le nom du cluster à l'intérieur de leur nom (notamment, les index
+ partiels sur <envar>sl_log_1</envar> et <envar>sl_log_2</envar>).
+ Ceci implique que les noms de cluster <emphasis>très longs</emphasis>
+ sont une mauvaise idée car ils entraînent un dépassement des noms
+ d'objets au delà de la limite de 63 caractères.
+ </para> </note>
+
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
@@ -474,9 +480,10 @@
<variablelist>
<varlistentry><term><literal>ID = ival</literal></term>
<listitem><para>L'identifiant numérique, immutable et unique du nouveau nœud.</para>
-<para> Note that the ID is <emphasis>immutable</emphasis>
- because it is used as the basis for inter-node event
- communications. </para> </listitem>
+ <para>Notez que l'identifiant n'est pas <emphasis>modifiable</emphasis>
+ cat il a été utilisé comme base des communications pour les événements
+ inter-nœuds.</para>
+ </listitem>
</varlistentry>
<varlistentry><term><literal> COMMENT = 'description' </literal></term>
@@ -490,11 +497,11 @@
pour l'archivage de journaux de réplication. Si ce paramètre est à true,
<application>slonik</application> n'essaiera pas d'initialiser la base de
donnée avec le schéma de réplication.</para>
- <warning><para> Never use the SPOOLNODE value - no released
- version of &slony1; has ever behaved in the fashion described
- in the preceding fashion. Log shipping, as it finally emerged
- in 1.2.11, does not require initializing <quote>spool
- nodes</quote>.</para> </warning> </listitem>
+ <warning><para>Ne jamais utiliser la valeur de SPOOLNODE -
+ aucune version sortie de &slony1; ne s'est comportée de la façon décrite
+ précédemment. Le log shipping, de la façon dont il a été finalement
+ implanté en 1.2.11, ne nécessite par d'initialiser les <quote>nœuds
+ du spool</quote>.</para> </warning></listitem>
</varlistentry>
<varlistentry><term><literal>EVENT NODE = ival</literal></term>
@@ -525,10 +532,10 @@
<para>Cette commande fut introduite dans &slony1; 1.0. Le paramètre <envar>SPOOLNODE</envar>
fut introduit dans la version 1.1 mais n'était pas implémentée dans cette version.
La fonctionnalité <envar>SPOOLNODE</envar> est arrivée dans la
- version 1.2., but <envar>SPOOLNODE</envar> was not used
- for this purpose. In later versions, hopefully
- <envar>SPOOLNODE</envar> will be unavailable. </para>
- <para> In version 2.0, the default value for <envar>EVENT NODE</envar> was removed, so a node must be specified.</para>
+ version 1.2 mais <envar>SPOOLNODE</envar> n'était pas utiliser dans ce but.
+ Dans des versions ultérieures, <envar>SPOOLNODE</envar> ne sera pas disponible.</para>
+ <para>Dans la version 2.0, la valeur par défaut <envar>EVENT NODE</envar> a été supprimée,
+ donc un nœud doit être spécifié.</para>
</refsect1>
</refentry>
@@ -600,7 +607,8 @@
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
- <para> In version 2.0, the default value for <envar>EVENT NODE</envar> was removed, so a node must be specified.</para>
+ <para>Dans la version 2.0, la valeur par défaut pour <envar>EVENT NODE</envar> a été supprimée,
+ donc un nœud doit être spécifié.</para>
</refsect1>
</refentry>
@@ -683,8 +691,8 @@
<refsect1>
<title>Description</title>
- <para> Provoque l'arrêt et le redémarrage d'un démon
- de réplication (<application>slon</application> process) sur le nœud spécifié.
+ <para> Provoque l'arrêt et le redémarrage d'un démon de réplication
+ (processus <application>slon</application>) sur le nœud spécifié.
Théoriquement, cette commande est obsolète. En pratique,
les délais TCP peuvent retarder les changements critiques
de configuration jusqu'à ce qu'il soit effectué alors que le
@@ -709,10 +717,10 @@
<para>Aucun verrouillage ne devrait être visible depuis l'application.</para>
</refsect1>
<refsect1> <title>Note de version</title>
- <para>Cette commande fut introduite dans &slony1; 1.0 ;frequent use became unnecessary as
- of version 1.0.5. There are, however, occasional cases where it is
- necessary to interrupt a <application>slon</application> process,
- and this allows this to be scripted via slonik. </para>
+ <para>Cette commande fut introduite dans &slony1; 1.0 ; une utilisation
+ fréquente devient inutile à partir de la version 1.0.5. Néanmoins, dans certains
+ cas occasionnels, il devient nécessaire d'interrompre le processus
+ <application>slon</application> et ceci vous permet de scripter via slonik.</para>
</refsect1>
</refentry>
@@ -1001,8 +1009,8 @@
</para>
<para>
- En dernier recours, <emphasis>in versions of &slony1; prior to
- 2.0</emphasis>, cette commande peut être utilisée pour ajouter
+ En dernier recours, <emphasis>dans les versions de &slony1; antérieures
+ à la 2.0</emphasis>, cette commande peut être utilisée pour ajouter
un attribut à une table qui ne possède par de clef primaire.
Sachant que cette modification peut avoir des effets secondaires
indésirables, <emphasis>il est très fortement recommandé que les
@@ -1010,11 +1018,12 @@
leurs propres moyens</emphasis>.
</para>
- <para> If you intend to use &slony1; version 2.0, you
- <emphasis>must</emphasis> arrange for a more proper primary key.
- &slony1; will not provide one for you, and if you have cases of
- keys created via <command>TABLE ADD KEY</command>, you cannot
- expect &slony1; to function properly. </para>
+ <para>Si vous comptez utilisez &slony1; version 2.0, vous
+ <emphasis>devez</emphasis> vous débrouiller pour définir
+ une clef primaire plus adéquate.
+ &slony1; ne vous en fournira pas une et si vous
+ avez des clefs créées via <command>TABLE ADD KEY</command>,
+ ne vous attendez pas à ce que &slony1; fonctionne correctement.</para>
<variablelist>
<varlistentry><term><literal>NODE ID = ival</literal></term>
@@ -1082,15 +1091,16 @@
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
-<warning> <para> This command is <emphasis> no longer supported </emphasis>
- as of &slony1; version 2.0. In version 2, the various
- <quote>catalogue breakages</quote> done in &postgres; versions
- prior to 8.3 are being eliminated so that schema dumps may be
- taken from any node. That leaves the <quote>kludgy</quote>
- columns created via <command>TABLE ADD KEY</command> as the only
- thing that prevents <xref linkend="stmtuninstallnode"/> from being
- comprised of the SQL statement <command>drop schema _ClusterName
- cascade;</command>.</para> </warning>
+<warning> <para>Cette commande n'est <emphasis>plus supportée</emphasis>
+ à partir de &slony1; version 2.0. Dans la version 2, les différentes
+ <quote>modifications du catalogue</quote> réalisée sur les
+ versions de &postgres; antérieures à la 8.3 sont éliminées
+ afin que les exports de schéma puissent être utilisés sur n'importe
+ quel nœud. Ainsi les colonnes <quote>bricolées</quote> par
+ <command>TABLE ADD KEY</command> sont la chose qui empêche la commande
+ <xref linkend="stmtuninstallnode"/> d'être équivalente à
+ la commande SQL <command>drop schema _nom_du_cluster
+ cascade;</command>.</para> </warning>
</refsect1>
</refentry>
@@ -1327,7 +1337,7 @@
</varlistentry>
<varlistentry><term><literal>ORIGIN = ival</literal></term>
<listitem><para>Nœud origine de l'ensemble. Les prochaines versions de <application>slonik</application>
- devraient pouvoir deviner cette information, but there do lie race conditions, there.</para></listitem>
+ devraient pouvoir deviner cette information, mais cela amène quelques complications.</para></listitem>
</varlistentry>
<varlistentry><term><literal>ID = ival</literal></term>
@@ -1342,13 +1352,13 @@
<para>Cet identifiant doit être unique pour tous les ensembles de réplication ;
vous ne devez pas avoir deux tables du même cluster avec le même identifiant.
</para>
- <para> Note that &slony1; generates an in-memory array
- indicating all of the fully qualified table names; if you use
- large table ID numbers, the sparsely-utilized array can lead
- to substantial wastage of memory. Each potential table ID
- consumes a pointer to a char, commonly costing 4 bytes per
- table ID on 32 bit architectures, and 8 bytes per table ID on
- 64 bit architectures. </para>
+ <para>Notez que &slony1; génère un tableau en mémoire indiquant tous
+ les noms de table complètement qualifiés ; si vous utilisez
+ des gros numéros d'identifiant pour les tables, le tableau peu utilisé
+ peut amener des pertes substantiels de mémoire. Chaque identifiant de
+ table potentiel consomme un pointeur vers un caractère, ce qui fait
+ habituellement quatre octets par identifiants de table sur les
+ architectures 32 bits et 8 octets sur les architectures 64 bits.</para>
</listitem>
</varlistentry>
@@ -1440,11 +1450,11 @@
<varlistentry><term><literal>Slony-I: cannot add table to currently subscribed set 1</literal></term>
<listitem><para>&slony1; ne peut pas ajouter des tables dans un ensemble qui est
- en cours de réplication. Instead, you need to define a new replication set, and add any
- new tables to <emphasis>that</emphasis> set. You might then
- use <xref linkend="stmtmergeset"/> to merge the new set into an
- existing one, if that seems appropriate. </para> </listitem>
- </varlistentry>
+ en cours de réplication.À la place, vous devez définir un nouvel ensemble
+ de réplication puis ajouter toutes les nouvelles tables à <emphasis>cet</emphasis>
+ ensemble. Vous pouvez ensuite utiliser <xref linkend="stmtmergeset"/>
+ pour fusionner le nouvel ensemble avec un ensemble existant, si cela
+ vous semble approprié.</para> </listitem> </varlistentry>
</variablelist>
@@ -1819,17 +1829,17 @@
</varlistentry>
</variablelist>
</para>
- <note><para> A nifty trick is that you can run <command>STORE
- TRIGGER</command> <emphasis>before the trigger is
- installed;</emphasis> that will not cause any errors. You could
- thus add &slony1;'s handling of the trigger
- <emphasis>before</emphasis> it is installed. That allows you to
- be certain that it becomes active on all nodes immediately upon
- its installation via <xref linkend="stmtddlscript"/>; there is no
- risk of events getting through in between the <command>EXECUTE
- SCRIPT</command> and <command>STORE TRIGGER</command>
- events. </para>
- </note>
+ <note><para>Une astuce consiste à lancer <command>STORE
+ TRIGGER</command> <emphasis>avant que le trigger ne soit installé
+ </emphasis>, ce qui ne provoquera pas d'erreurs. Vous pouvez
+ ainsi définir la gestion d'un trigger par &slony1;
+ <emphasis>avant</emphasis> qu'il ne soit installé. Vous êtes alors
+ certain que le trigger est actif sur tous les nœuds immédiatement
+ après son installation via <xref linkend="stmtddlscript"/> ; il n'y a
+ aucun risque de voir un événement passer entre les événements
+ <command>EXECUTE SCRIPT</command> et <command>STORE TRIGGER</command>.
+ </para>
+ </note>
<para>Cette commande utilise &funstoretrigger;.</para>
</refsect1>
@@ -1911,15 +1921,15 @@
<para>Cette opération pose brièvement un verrou exclusif sur la table spécifiée
sur chaque nœud auquel elle s'applique, afin de modifier le schéma de la table
-et y ajouter de nouveau le trigger, but (hopefully!) only briefly.
+et y ajouter de nouveau le trigger, mais (heureusement) très brièvement.
</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
- <para> In &slony1; version 2.0, this command is removed as
- obsolete because triggers are no longer <quote>messed around
- with</quote> in the system catalogue. </para>
+ <para>Avec &slony1; version 2.0, cette commande est supprimée car
+obsolète. En effet, les triggers ne sont plus <quote>trafiqués</quote>
+dans le catalogue système.</para>
</refsect1>
</refentry>
@@ -2044,10 +2054,8 @@
<listitem><para>Indique si le nouvel abonné doit stocker les logs
pendant la réplication afin de pouvoir devenir fournisseur pour de futurs
-nœuds. Any
- node that is intended to be a candidate for FAILOVER
- <emphasis>must</emphasis> have <command>FORWARD =
- yes</command>.</para></listitem>
+nœuds. Tout nœud qui a pour but d'être un candidat pour le
+FAILOVER <emphasis>doit</emphasis> avoir <command>FORWARD = yes</command>.</para></listitem>
</varlistentry>
</variablelist>
@@ -2516,18 +2524,20 @@
<xref linkend="stmtmoveset"/> car elle n'abandonne
<emphasis>pas</emphasis> le nœud en panne.
</para>
- <para> If there are many nodes in a cluster, and failover includes
- dropping out additional nodes (<emphasis>e.g.</emphasis> when it
- is necessary to treat <emphasis>all</emphasis> nodes at a site
- including an origin as well as subscribers as failed), it is
- necessary to carefully sequence the actions, as described in <xref
- linkend="complexfailover"/>.
+ <para>
+ S'il y a beaucoup de nœuds dans un cluster et que la bascule inclut
+ la suppression de nœuds supplémentaires (<emphasis>c'est-à-dire</emphasis>
+ quand il est nécessaire de traiter <emphasis>tous</emphasis> les nœuds
+ d'un site, ceci incluant une origine ainsi que les abonnés, comme ayant
+ échoué, il est nécessaire de séquencer les actions avec une grande attention,
+ comme décrit dans <xref linkend="complexfailover"/>.
</para>
</refsect1>
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
- <para> In version 2.0, the default <envar>BACKUP NODE</envar> value of 1 was removed, so it is mandatory to provide a value for this parameter.</para>
+ <para>Dans la version 2.0, la valeur par défaut pour <envar>BACKUP NODE</envar>, 1, a
+ été supprimée, donc il est nécessaire de fournir une valeur pour ce paramètre.</para>
</refsect1>
</refentry>
@@ -2599,19 +2609,21 @@
<para>Notons qu'il s'agit d'une opération &rlocking;, ce qui signifie qu'elle peut être
bloquée par l'activité d'une autre base.</para>
- <para>In versions up to (and including) the 1.2 branch, au démarrage de cet événement, toutes les tables répliquées sont
+ <para>Dans les versions de la branche 1.2 et dans les versions antérieures,
+ au démarrage de cet événement, toutes les tables répliquées sont
déverrouillées par la fonction <function>alterTableRestore(tab_id)</function>.
Une fois le script SQL exécuté, elles sont remises en <quote>mode réplication
</quote> avec <function>alterTableForReplication(tab_id)</function>.
Cela implique que toutes les tables sont verrouillées par ce processus
&slon; pendant la durée du script SQL.</para>
- <para>Si les colonnes d'une table sont modifiées, il est très
-important que les triggers soient régénérés (<emphasis>e.g.</emphasis> - by
- <function>alterTableForReplication(tab_id)</function>), sinon les attributes in the <function>logtrigger()</function> trigger
-peuvent être inadaptés à la nouvelle forme du schéma.
- </para>
+ <para>Si les colonnes d'une table sont modifiées, il est essentiel que les
+ triggers soient régénérés (<emphasis>e.g.</emphasis> - par
+ <function>alterTableForReplication(tab_id)</function>), sinon les attributs
+ dans le trigger <function>logtrigger()</function> peuvent être inadaptés à
+ la nouvelle forme du schéma.</para>
+
<para>Notez que si vous devez faire référence au nom du cluster,
vous pouvez utiliser l'alias <command>@CLUSTERNAME@</command> ;
si vous devez faire référence au schéma &slony1;,
@@ -2631,7 +2643,7 @@
</refsect1>
<refsect1> <title>Utilisation de verrous</title>
- <para>Up until the 2.0 branch, un verrou exclusif est posé
+ <para>Jusqu'à la branche 2.0, un verrou exclusif est posé
sur chaque table répliquée sur le nœud origine, afin de retirer les triggers
de réplication. Une fois le script DDL achevé, ces verrous sont enlevés.
</para>
@@ -2641,12 +2653,12 @@
les triggers des tables répliquées.
</para>
- <para> As of the 2.0 branch, &slony1; uses a GUC that controls
- trigger behaviour, which allows deactivating the &slony1;-created
- triggers during this operation <emphasis>without</emphasis> the
- need to take out exclusive locks on all tables. Now, the only
- tables requiring exclusive locks are those tables that are
- actually altered as a part of the DDL script. </para>
+ <para>À partir de la branche 2.0, &slony1; utilise un GUC qui contrôle
+le comportement des triggers, ce qui permet de désactiver les triggers créés par
+&slony1; pendant l'opération <emphasis>sans</emphasis> poser de verrous exclusifs sur
+toutes les tables. Désormais, les seules tables qui sont verrouillées sont les tables
+qui sont effectivement modifiées par le script DDL.
+ </para>
</refsect1>
<refsect1> <title>Note de version</title>
@@ -2679,8 +2691,8 @@
Ceci couvre les risques lorsqu'on lance une requête de changements DDL
sur des tables appartenant à plusieurs ensemble de réplication.</para>
- <para> In version 2.0, the default value for <envar>EVENT
- NODE</envar> was removed, so a node must be specified.</para>
+ <para>Dans la version 2.0, la valeur par défaut pour <envar>EVENT
+ NODE</envar> a été supprimée, donc un nœud doit être spécifié.</para>
</refsect1>
</refentry>
@@ -2779,8 +2791,8 @@
<command>CREATE SET</command>) soient traités sur un autre nœud avant de
lancer d'autres commandes (par exemple <xref linkend="stmtsubscribeset"/>).
<command>WAIT FOR EVENT</command> peut être utilisé pour demander à un
-script <application>slonik</application> d'attendre jusqu'à ce que confirmation of an event, which hopefully means that
- the subscriber node is ready for the next action.
+script <application>slonik</application> d'attendre pour la confirmation d'un événement,
+ce qui signifie que le nœud abonné est prêt pour la prochaine action.
</para>
<para><command>WAIT FOR EVENT</command> doit être appelée en dehors d'un
@@ -2830,8 +2842,8 @@
<refsect1> <title>Note de version</title>
<para>Cette commande fut introduite dans &slony1; 1.0.</para>
- <para> In version 2.0, the default value for <envar>WAIT ON</envar>
- was removed, so a node must be specified.</para>
+ <para>Dans la version 2.0, la valeur par défaut pour <envar>WAIT ON</envar>
+ a été supprimée, donc un nœud doit être spécifié.</para>
</refsect1>
<refsect1> <title>Bizarreries</title>
@@ -2995,96 +3007,81 @@
</refsect1>
</refentry>
-
-
<refentry id ="stmtcloneprepare"><refmeta><refentrytitle>SLONIK CLONE PREPARE</refentrytitle>
<manvolnum>7</manvolnum></refmeta>
<refnamediv><refname>CLONE PREPARE</refname>
- <refpurpose> Prepare for cloning a node. </refpurpose>
+ <refpurpose>Prépare le clonage d'un nœud.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
- <command>clone prepare </command>
- <arg><replaceable class="parameter"> id</replaceable></arg>
- <arg><replaceable class="parameter"> provider</replaceable></arg>
- <arg><replaceable class="parameter"> comment</replaceable></arg>
+ <command>clone prepare</command>
+ <arg><replaceable class="parameter">id</replaceable></arg>
+ <arg><replaceable class="parameter">provider</replaceable></arg>
+ <arg><replaceable class="parameter">comment</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
- Prepares for cloning a specified node.
+ Cette commande prépare le clonage d'un nœud donné.
</para>
<para>
- This duplicates the <quote>provider</quote> node's configuration
- under a new node ID in preparation for the node to be copied via
- standard database tools.
+ Ceci duplique la configuration d'un nœud <quote>fournisseur</quote>
+ sous un nouvel identifiant en préparation de la copie de ce nœud
+ via un outil standard.
</para>
- <para> Note that in order that we be certain that this new node be
- consistent with all nodes, it is important to issue a SYNC event
- against every node aside from the provider and wait to start
- copying the provider database at least until all those SYNC events
- have been confirmed by the provider. Otherwise, it is possible
- for the clone to miss some events. </para>
+ <para>Notez que pour être certain que ce nouveau nœud est cohérent avec
+tous les nœuds, il est important de lancer un événement SYNC sur tous les
+nœuds à l'exception du fournisseur et d'attendre que tous ces événements
+SYNC soient confirmés avant de copier la base fournisseur.
+Sinon il est possible que le clone ait raté des événements.
+ </para>
</refsect1>
-
- <refsect1>
- <title>Example</title>
- <programlisting>
+ <refsect1><title>Exemple</title>
+ <programlisting>
clone prepare (id = 33, provider = 22, comment='Clone 33');
sync (id=11);
sync (id=22);
- </programlisting>
+ </programlisting>
</refsect1>
-
- <refsect1> <title> Version Information </title>
- <para> This command was introduced in &slony1; 2.0. </para>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.2.0.</para>
</refsect1>
</refentry>
-
-
<refentry id ="stmtclonefinish"><refmeta><refentrytitle>SLONIK CLONE FINISH</refentrytitle>
- <manvolnum>7</manvolnum></refmeta>
-
- <refnamediv><refname>CLONE FINISH</refname>
-
- <refpurpose> Complete cloning a node. </refpurpose>
- </refnamediv>
- <refsynopsisdiv>
- <cmdsynopsis>
- <command>clone prepare </command>
- <arg><replaceable class="parameter"> id</replaceable></arg>
- <arg><replaceable class="parameter"> provider</replaceable></arg>
- </cmdsynopsis>
- </refsynopsisdiv>
- <refsect1>
- <title>Description</title>
- <para>
- Finishes cloning a specified node.
- </para>
-
- <para>
- This completes the work done by <xref
- linkend="stmtcloneprepare"/>, establishing confirmation data for
- the new <quote>clone</quote> based on the status found for the
- <quote>provider</quote> node.
- </para>
- </refsect1>
-
- <refsect1><title>Example</title>
- <programlisting>
- clone finish (id = 33, provider = 22);
- </programlisting>
- </refsect1>
-
- <refsect1> <title> Version Information </title>
- <para> This command was introduced in &slony1; 2.0. </para>
- </refsect1>
+ <manvolnum>7</manvolnum></refmeta>
+ <refnamediv><refname>CLONE FINISH</refname>
+ <refpurpose>Termine le clonage d'un nœud.</refpurpose>
+ </refnamediv>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>clone prepare</command>
+ <arg><replaceable class="parameter">id</replaceable></arg>
+ <arg><replaceable class="parameter">provider</replaceable></arg>
+ </cmdsynopsis>
+ </refsynopsisdiv>
+ <refsect1>
+ <title>Description</title>
+ <para>
+ Cette commande achève le clonage sur un nœud donné.
+ </para>
+ <para>Ceci complète le travail effectué par <xref linkend="stmtcloneprepare"/> en établissant les données de confirmation
+ pour le nouveau <quote>clone</quote> à partir du statut trouvé pour le nœud <quote>fournisseur</quote>.
+ </para>
+ </refsect1>
+ <refsect1><title>Exemple</title>
+ <programlisting>
+ clone finish (id = 33, provider = 22);
+ </programlisting>
+ </refsect1>
+ <refsect1> <title>Note de version</title>
+ <para>Cette commande fut introduite dans &slony1; 1.2.0.</para>
+ </refsect1>
</refentry>
</reference>
Modified: traduc/branches/slony_1_2/slonyupgrade.xml
===================================================================
--- traduc/branches/slony_1_2/slonyupgrade.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/slonyupgrade.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -132,180 +132,249 @@
</varlistentry>
</variablelist>
+<sect2>
+<title>Problème avec TABLE ADD KEY dans &slony1; 2.0</title>
-<sect2> <title> TABLE ADD KEY issue in &slony1; 2.0 </title>
+<para>
+ Généralement, les mises à jour de versions &slony1; ne nécessitent pas de
+ porter une attention particulière au réplicat existant, c'est-à-dire que vous
+ pouvez simplement arrêter les &slon;s, mettre en place les binaires, lancer
+ <xref linkend="stmtupdatefunctions"/> sur chaque nœud et redémarrer
+ &lslon;. Les modifications de schéma étant uniquement sur le schéma du cluster,
+ <xref linkend="stmtupdatefunctions"/> est capable de réaliser toutes les
+ altérations. Avec la version 2, cela change s'il existe des tables qui
+ utilisaient <xref linkend="stmttableaddkey"/>. La version 2 ne supporte pas
+ la colonne <quote>extra</quote>, et <quote>réparer</quote> le schéma pour
+ obtenir une clé primaire correcte n'est pas dans les attributions de <xref
+ linkend="stmtupdatefunctions"/>.
+</para>
-<para> Usually, upgrades between &slony1; versions have required no
-special attention to the condition of the existing replica. That is,
-you fairly much merely need to stop &lslon;s, put new binaries in
-place, run <xref linkend="stmtupdatefunctions"/> against each node, and
-restart &lslon;s. Schema changes have been internal to the cluster
-schema, and <xref linkend="stmtupdatefunctions"/> has been capable to
-make all of the needed alterations. With version 2, this changes, if
-there are tables that used <xref linkend="stmttableaddkey"/>. Version
-2 does not support the <quote>extra</quote> column, and
-<quote>fixing</quote> the schema to have a proper primary key is not
-within the scope of what <xref linkend="stmtupdatefunctions"/> can
-perform. </para>
+<para>
+ Lorsque qu'on met à jour depuis une version 1.0.x, 1.1.x ou 1.2.x vers une
+ version 2, il est nécessaire de supprimer toute clé primaire gérée par
+ &slony1;.
+</para>
-<para> When upgrading from versions 1.0.x, 1.1.x, or 1.2.x to version
-2, it will be necessary to have already eliminated any such
-&slony1;-managed primary keys. </para>
+<para>
+ On peut identifier les tables concernées avec la requête SQL suivante :
+
+ <command>SELECT n.nspname, c.relname FROM pg_class c,
+pg_namespace n WHERE c.oid in (SELECT attrelid FROM pg_attribute WHERE
+attname LIKE '_Slony-I_%rowID' and not attisdropped) and reltype &lt&gt 0
+and n.oid = c.relnamespace order by n.nspname, c.relname;</command>
-<para> One may identify the tables affected via the following SQL
-query: <command> select n.nspname, c.relname from pg_class c,
-pg_namespace n where c.oid in (select attrelid from pg_attribute where
-attname like '_Slony-I_%rowID' and not attisdropped) and reltype <> 0
-and n.oid = c.relnamespace order by n.nspname, c.relname; </command>
</para>
-<para> The simplest approach that may be taken to rectify the
-<quote>broken</quote> state of such tables is as follows: </para>
+<para>
+ L'approche la plus simple pour rectifier l'état de ces tables est la
+ suivante :
+</para>
<itemizedlist>
-<listitem><para> Drop the table from replication using the &lslonik;
-command <xref linkend="stmtsetdroptable"/>. </para>
+ <listitem>
+ <para>
+ Retirer la table de la réplication avec la commande &lslonik;
+ <xref linkend="stmtsetdroptable"/>
+ </para>
-<para> This does <emphasis>not</emphasis> drop out the
-&slony1;-generated column. </para>
-</listitem>
+ <para>
+ Ceci ne supprime <emphasis>pas</emphasis> les colonnes créées par
+ &slony1;.
+ </para>
+ </listitem>
-<listitem><para> On each node, run an SQL script to alter the table,
-dropping the extra column.</para> <para> <command> alter table
-whatever drop column "_Slony-I_cluster-rowID";</command> </para>
+ <listitem>
+ <para>
+ Sur chaque nœud, exécutez un script SQL pour modifier la table et
+ supprimez les colonnes additionnelles.
+ </para>
+
+ <para>
+ <command>ALTER TABLE nom_table DROP COLUMN "_Slony-I_cluster-rowID";</command>
+ </para>
-<para> This needs to be run individually against each node. Depending
-on your preferences, you might wish to use <xref
-linkend="stmtddlscript"/> to do this. </para>
+ <para>
+ Ceci doit être exécuté sur chaque nœud. Selon votre préférence,
+ vous pouvez utiliser <xref linkend="stmtddlscript"/> pour cela.
+ </para>
-<para> If the table is a heavily updated one, it is worth observing
-that this alteration will require acquiring an exclusive lock on the
-table. It will not hold this lock for terribly long; dropping the
-column should be quite a rapid operation as all it does internally is
-to mark the column as being dropped; it <emphasis>does not</emphasis>
-require rewriting the entire contents of the table. Tuples that have
-values in that column will continue to have that value; new tuples
-will leave it NULL, and queries will ignore the column. Space for
-those columns will get reclaimed as tuples get updated. </para>
+ <para>
+ Si la table est une table massivement mise à jour, sachez que cette
+ modification posera un verrou exclusif sur la table. Elle ne détiendra
+ pas ce verrou très longtemps ; supprimer une colonne est une
+ opération assez rapide car cela se contente de marquer la colonne comme
+ supprimée. Cela ne nécessite <emphasis>pas</emphasis> de réécrire toute
+ la table. Les lignes qui ont une valeur dans cette colonne continueront à
+ avoir cette valeur. Pour les nouvelles lignes, la valeur sera NULL, et
+ les requêtes ignoreront cette colonne. L'espace occupé par ces colonnes
+ sera récupéré lorsque les lignes seront mises à jour.
+ </para>
-<para> Note that at this point in the process, this table is not being
-replicated. If a failure takes place, replication is not, at this
-point, providing protection on this table. This is unfortunate but
-unavoidable. </para>
-</listitem>
+ <para>
+ Notez qu'à cette étape de la procédure, cette table n'est pas répliquée.
+ Si une erreur a lieu, la réplication à cet instant n'apporte aucune
+ protection sur cette table. C'est dommage mais inévitable.
+ </para>
+ </listitem>
-<listitem><para> Make sure the table has a legitimate candidate for
-primary key, some set of NOT NULL, UNIQUE columns. </para>
+ <listitem>
+ <para>
+ Assurez-vous que la table possède un candidat éligible pour une clé
+ primaire, c'est-à-dire un ensemble de colonnes NOT NULL et UNIQUE.
+ </para>
-<para> The possible variations to this are the reason that the
-developers have made no effort to try to assist automation of
-this.</para></listitem>
-</itemizedlist>
+ <para>
+ Les différents cas possibles font que les développeurs n'ont pas fait
+ d'efforts pour automatiser cette procédure.
+ </para>
-<itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Si la table est petite, il peut être parfaitement raisonnable
+ d'ajouter une nouvelle colonne (notez que cela doit être fait sur
+ <emphasis>chaque nœud</emphasis> !), lui assigner une
+ une nouvelle séquence et la déclarer comme clé primaire.
+ </para>
-<listitem><para> If the table is a small one, it may be perfectly
-reasonable to do alterations (note that they must be applied to
-<emphasis>every node</emphasis>!) to add a new column, assign it via a
-new sequence, and then declare it to be a primary key. </para>
+ <para>
+ S'il n'y a que quelques lignes, cela ne prend qu'une fraction de
+ seconde et avec de la chance, cela n'aura pas d'impact sur
+ l'application.
+ </para>
-<para> If there are only a few tuples, this should take a fraction of
-a second, and, with luck, be unnoticeable to a running
-application. </para>
+ <para>
+ Même si la table est relativement large, alors qu'elle n'est pas
+ accédée fréquemment par l'application, alors le verrouillage de la
+ table provoqué par <command>ALTER TABLE</command> n'entraînera pas
+ d'inconvénients.
+ </para>
+ </listitem>
-<para> Even if the table is fairly large, if it is not frequently
-accessed by the application, the locking of the table that takes place
-when you run <command>ALTER TABLE</command> may not cause much
-inconvenience. </para></listitem>
+ <listitem>
+ <para>
+ Si la table est large, qu'elle est vitale et fortement utilisée par
+ l'application, alors il peut être nécessaire de prévoir une coupure
+ de service de l'application afin d'accomplir les modifications, ce
+ qui vous laissera un peu vulnérable tant que la procédure ne sera pas
+ complétée.
+ </para>
-<listitem> <para> If the table is a large one, and is vital to and
-heavily accessed by the application, then it may be necessary to take
-an application outage in order to accomplish the alterations, leaving
-you necessarily somewhat vulnerable until the process is
-complete. </para>
+ <para>
+ Si une coupure de service est problématique, alors la mise à jour
+ vers &slony1; version 2 devra être planifiée avec soin...
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
-<para> If it is troublesome to take outages, then the upgrade to
-&slony1; version 2 may take some planning... </para>
-</listitem>
+ <listitem>
+ <para>
+ Créez un nouvel ensemble de réplication (<xref linkend="stmtcreateset"/>
+ et ajoutez à nouveau la table dans cet ensemble (<xref
+ linkend="stmtsetaddtable"/>).
+ </para>
-</itemizedlist>
+ <para>
+ S'il existe plusieurs tables, elles peuvent être gérées via un ensemble
+ de réplication unique.
+ </para>
+ </listitem>
-<itemizedlist>
+ <listitem>
+ <para>
+ Abonnez l'ensemble de réplication (<xref linkend="stmtsubscribeset"/>)
+ pour tous les nœuds désirés.
+ </para>
+ </listitem>
-<listitem><para> Create a new replication set (<xref
-linkend="stmtcreateset"/>) and re-add the table to that set (<xref
-linkend="stmtsetaddtable"/>). </para>
-
-<para> If there are multiple tables, they may be handled via a single
-replication set.</para>
-</listitem>
-
-<listitem><para> Subscribe the set (<xref linkend="stmtsubscribeset"/>)
-on all the nodes desired. </para> </listitem>
-
-<listitem><para> Once subscriptions are complete, merge the set(s) in,
-if desired (<xref linkend="stmtmergeset"/>). </para> </listitem>
-
+ <listitem>
+ <para>
+ Une fois que l'abonnement est complété, fusionnez les ensembles de
+ réplications si nécessaire (<xref linkend="stmtmergeset"/>).
+ </para>
+ </listitem>
</itemizedlist>
-<para> This approach should be fine for tables that are relatively
-small, or infrequently used. If, on the other hand, the table is
-large and heavily used, another approach may prove necessary, namely
-to create your own sequence, and <quote>promote</quote> the formerly
-&slony1;-generated column into a <quote>real</quote> column in your
-database schema. An outline of the steps is as follows: </para>
+<para>
+ Cette approche devrait fonctionner pour les tables qui sont relativement
+ petites ou rarement utilisées. D'autre part, si la table est large et
+ massivement utilisée, une autre approche pourrait être nécessaire,
+ c'est-à-dire créer votre propre séquence, et <quote>promouvoir</quote>
+ l'ancienne colonne générée par &slony1; dans une colonne <quote>réelle</quote>
+ au sein du schéma de votre base de données. Les grandes lignes de cette
+ procédure sont les suivantes :
+</para>
<itemizedlist>
+ <listitem>
+ <para>
+ Ajouter une séquence qui assigne des valeurs à la colonne.
+ </para>
-<listitem><para> Add a sequence that assigns values to the
-column. </para>
+ <para>
+ Les étapes d'installation incluent les commandes SQL <command>CREATE
+ SEQUENCE</command>, <command>SELECT SETVAL()</command> (pour définir
+ une valeur de séquence assez haute pour refléter les valeurs utilisées
+ dans la table), le <xref linkend="stmtcreateset"/> de Slonik (pour créer
+ un ensemble de réplication dans lequel on placera la séquence), le
+ <xref linkend="stmtsetaddsequence"/> de Slonik (pour placer la séquence
+ dans l'ensemble de réplication), le <xref linkend="stmtsubscribeset"/>
+ de Slonik (pour définir les abonnements de ce nouvel ensemble de
+ réplication).
+ </para>
+ </listitem>
-<para> Setup steps will include SQL <command>CREATE
-SEQUENCE</command>, SQL <command>SELECT SETVAL()</command> (to set the
-value of the sequence high enough to reflect values used in the
-table), Slonik <xref linkend="stmtcreateset"/> (to create a set to
-assign the sequence to), Slonik <xref linkend="stmtsetaddsequence"/>
-(to assign the sequence to the set), Slonik <xref
-linkend="stmtsubscribeset"/> (to set up subscriptions to the new
-set)</para>
-</listitem>
+ <listitem>
+ <para>
+ Attachez la séquence à la colonne dans la table.
+ </para>
-<listitem><para> Attach the sequence to the column on the
-table. </para>
+ <para>
+ Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
+ qui doivent être exécutées via la commande Slonik <xref
+ linkend="stmtddlscript"/>.
+ </para>
+ </listitem>
-<para> This involves <command>ALTER TABLE ALTER COLUMN</command>,
-which must be submitted via the Slonik command <xref
-linkend="stmtddlscript"/>. </para>
-</listitem>
+ <listitem>
+ <para>
+ Renommez la colonne <envar>_Slony-I_ at CLUSTERNAME@_rowID</envar> afin que
+ &slony1; ne considère pas qu'elle est sous son contrôle.
+ </para>
-<listitem><para> Rename the column
-<envar>_Slony-I_ at CLUSTERNAME@_rowID</envar> so that &slony1; won't
-consider it to be under its control.</para>
+ <para>
+ Ceci implique les commandes <command>ALTER TABLE ALTER COLUMN</command>,
+ qui doivent être exécutées via la commande Slonik <xref
+ linkend="stmtddlscript"/>.
+ </para>
-<para> This involves <command>ALTER TABLE ALTER COLUMN</command>,
-which must be submitted via the Slonik command <xref
-linkend="stmtddlscript"/>. </para>
-
-<para> Note that these two alterations might be accomplished via the
-same <xref linkend="stmtddlscript"/> request. </para>
-</listitem>
-
+ <para>
+ Notez que ces deux modifications peuvent être accomplies au sein d'une
+ requête <xref linkend="stmtddlscript"/> unique.
+ </para>
+ </listitem>
</itemizedlist>
</sect2>
-<sect2> <title> New Trigger Handling in &slony1; Version 2 </title>
+<sect2>
+<title>Nouvelle gestion des triggers dans &slony1; Version 2</title>
-<para> One of the major changes to &slony1; is that enabling/disabling
-of triggers and rules now takes place as plain SQL, supported by
-&postgres; 8.3+, rather than via <quote>hacking</quote> on the system
-catalog. </para>
+<para>
+ Un des changements majeurs de &slony1; est que l'activation et la
+ désactivation des triggers et règles (« rules ») se fait
+ maintenant entièrement en SQL, supporté par &postgres; 8.3+, plutôt
+ que via des modifications directes dans le catalogue système.
+</para>
-<para> As a result, &slony1; users should be aware of the &postgres;
-syntax for <command>ALTER TABLE</command>, as that is how they can
-accomplish what was formerly accomplished via <xref
-linkend="stmtstoretrigger"/> and <xref linkend="stmtdroptrigger"/>. </para>
+<para>
+ Cela implique que les utilisateurs de &slony1; doivent étudier la syntaxe
+ &postgres; pour <command>ALTER TABLE</command> car c'est ainsi qu'ils
+ accompliront ce qu'ils accomplissait précédemment via les commandes <xref
+ linkend="stmtstoretrigger"/> et <xref linkend="stmtdroptrigger"/>.
+</para>
</sect2>
Modified: traduc/branches/slony_1_2/testbed.xml
===================================================================
--- traduc/branches/slony_1_2/testbed.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/testbed.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -230,10 +230,10 @@
<glossdef>
<para>
- By default, the tests will generate their output in
- <filename>/tmp</filename>, <filename>/usr/tmp</filename>, or
- <filename>/var/tmp</filename>, unless you set your own value for this
- environment variable.
+ Par défaut, les tests créeront des fichiers résultats dans
+ <filename>/tmp</filename>, <filename>/usr/tmp</filename> ou
+ <filename>/var/tmp</filename>, sauf si vous configurez cette variable
+ autrement.
</para>
</glossdef>
</glossentry>
@@ -281,41 +281,59 @@
<glossentry>
<glossterm><envar>SLONCONF[n]</envar></glossterm>
-<glossdef><para> If set to <quote>true</quote>, for a particular node,
-typically handled in <filename>settings.ik</filename> for a given
-test, then configuration will be set up in a <link
-linkend="runtime-config"> per-node <filename>slon.conf</filename>
-runtime config file. </link> </para> </glossdef>
-</glossentry>
+ <glossdef>
+ <para>
+ Si cette valeur est positionnée à <quote>true</quote> pour un nœud
+ donné qui est généralement configurée dans le fichier
+ <filename>settings.ik</filename> pour un test donné, alors la
+ <link linkend="runtime-config">configuration</link> sera placée dans un
+ un fichier de configuration <filename>slon.conf</filename> spécifique
+ pour chaque nœud.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossentry>
-<glossterm><envar>SLONYTESTER</envar></glossterm>
+ <glossentry>
+ <glossterm><envar>SLONYTESTER</envar></glossterm>
+
+ <glossdef>
+ <para>
+ Adresse e-mail de la personne qui reçoit les résultats des tests.
+ Ceci est stocké dans <envar>SLONYTESTFILE</envar> et peut être agrégé
+ dans un registre comparable à une ferme de compilation.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossdef><para> Email address of the person who might be
-contacted about the test results. This is stored in the
-<envar>SLONYTESTFILE</envar>, and may eventually be aggregated in some
-sort of buildfarm-like registry. </para> </glossdef>
-</glossentry>
+ <glossentry>
+ <glossterm><envar>SLONYTESTFILE</envar></glossterm>
-<glossentry>
-<glossterm><envar>SLONYTESTFILE</envar></glossterm>
+ <glossdef>
+ <para>
+ Fichier dans lequel sont stockés les résultats des tests. Ces résultats
+ peuvent être utilisés pour construire un dépôt contenant l'agrégation
+ des résultats de test.
+ </para>
+ </glossdef>
+ </glossentry>
-<glossdef><para> File in which to store summary results from tests.
-Eventually, this may be used to construct a buildfarm-like repository of
-aggregated test results. </para> </glossdef>
-</glossentry>
+ <glossentry>
+ <glossterm>
+ <filename>random_number</filename> et <filename>random_string</filename>
+ </glossterm>
-<glossentry>
-<glossterm><filename>random_number</filename> and <filename>random_string</filename> </glossterm>
-
-<glossdef><para> If you run <command>make</command> in the
-<filename>test</filename> directory, C programs
-<application>random_number</application> and
-<application>random_string</application> will be built which will then
-be used when generating random data in lieu of using shell/SQL
-capabilities that are much slower than the C programs. </para>
-</glossdef>
-</glossentry>
+ <glossdef>
+ <para>
+ Si vous exécutez <command>make</command> dans le répertoire de
+ <filename>test</filename>, les programmes C
+ <application>random_number</application> et
+ <application>random_string</application> seront compilés et seront
+ ensuite utilisés lors de la génération de données aléatoires au lieu
+ d'utiliser les fonctions shell/SQL qui sont beaucoup plus lentes que
+ les programmes C.
+ </para>
+ </glossdef>
+ </glossentry>
</glosslist>
<para>
Modified: traduc/branches/slony_1_2/versionupgrade.xml
===================================================================
--- traduc/branches/slony_1_2/versionupgrade.xml 2009-05-29 14:09:21 UTC (rev 1333)
+++ traduc/branches/slony_1_2/versionupgrade.xml 2009-05-29 14:12:20 UTC (rev 1334)
@@ -105,12 +105,11 @@
</para>
<para>
- Cette procédure devrait prendre un temps très court, qui dépendra
- principalement based more on how much time is required to reconfigure your
- applications than anything else. If you can automate all of these
- steps, the outage may conceivably be a second or less. If manual
- handling is necessary, then it is likely to take somewhere between a
- few seconds and a few minutes.
+ Cette procédure devrait prendre très peu de temps, principalement le temps
+ nécessaire à la reconfiguration de vos applications. Si vous pouvez
+ automatiser toutes ces étapes, le temps hors production devrait être d'une
+ seconde, voire moins. Si la gestion manuelle est nécessaire, cela prendra
+ entre quelques secondes et quelques minutes.
</para>
<para>
@@ -150,10 +149,10 @@
</para>
<para>
- Note that this imposes a need to have &slony1; built against
- <emphasis>both</emphasis> databases (<emphasis>e.g.</emphasis> - at
- the very least, the binaries for the stored procedures need to have
- been compiled against both versions of &postgres;).
+ Notez que ceci impose d'avoir une construction de &slony1; pour toutes les
+ bases de données <emphasis>à la fois</emphasis> (<emphasis>c'est-à-dire</emphasis>
+ à tout le moins, les binaires pour les procédures stockées doivent avoir
+ été compilés avec les différentes versions de &postgres;).
</para>
</listitem>
@@ -220,132 +219,183 @@
</para>
</note>
-<sect2> <title>Example: Upgrading a single database with no existing replication </title>
+<sect2>
+<title>Exemple : mise à jour d'une base simple sans réplication
+existante</title>
-<para>This example shows names, IP addresses, ports, etc to describe
-in detail what is going on</para>
+<para>
+ Cet exemple montre noms, adresses IP, numéros de port, etc pour décrire en
+ détails ce qui se passe.
+</para>
- <sect3>
- <title>The Environment</title>
- <programlisting>
- Database machine:
- name = rome
- ip = 192.168.1.23
- OS: Ubuntu 6.06 LTS
- postgres user = postgres, group postgres
+<sect3>
+<title>L'environnement</title>
+
+<programlisting>
+Machine de la base de données :
+ nom = rome
+ ip = 192.168.1.23
+ OS: Ubuntu 6.06 LTS
+ utilisateur postgres = postgres, groupe postgres
+
+Version actuelle de PostgreSQL
+ Version = 8.2.3
+ Port 5432
+ Installé sur : /data/pgsql-8.2.3
+ Répertoire des données : /data/pgsql-8.2.3/data
+ Base de données à déplacer : mydb
+
+Nouvelle installation de PostgreSQL
+ Version = 8.3.3
+ Port 5433
+ Installé sur : /data/pgsql-8.3.3
+ Répertoire des données : /data/pgsql-8.3.3/data
- Current PostgreSQL
- Version = 8.2.3
- Port 5432
- Installed at: /data/pgsql-8.2.3
- Data directory: /data/pgsql-8.2.3/data
- Database to be moved: mydb
-
- New PostgreSQL installation
- Version = 8.3.3
- Port 5433
- Installed at: /data/pgsql-8.3.3
- Data directory: /data/pgsql-8.3.3/data
-
- Slony Version to be used = 1.2.14
- </programlisting>
- </sect3>
- <sect3>
- <title>Installing &slony1;</title>
+Version Slony à utiliser = 1.2.14
+</programlisting>
- <para>
- How to install &slony1; is covered quite well in other parts of
- the documentation (<xref linkend="installation"/>); we will just
- provide a quick guide here.</para>
+</sect3>
- <programlisting>
- wget http://main.slony.info/downloads/1.2/source/slony1-1.2.14.tar.bz2
- </programlisting>
+<sect3>
+<title>Installer &slony1;</title>
- <para> Unpack and build as root with</para>
- <programlisting>
- tar xjf slony1-1.2.14.tar.bz2
- cd slony1-1.2.14
- ./configure --prefix=/data/pgsql-8.2.3 --with-perltools=/data/pgsql-8.2.3/slony --with-pgconfigdir=/data/pgsql-8.2.3/bin
- make clean
- make
- make install
- chown -R postgres:postgres /data/pgsq-8.2.3
- mkdir /var/log/slony
- chown -R postgres:postgres /var/log/slony
- </programlisting>
+<para>
+ L'installation de &slony1; est couverte assez bien dans les autres parties
+ de la documentation (<xref linkend="installation"/>) ; nous allons
+ seulement fournir un guide rapide ici.
+</para>
- <para> Then repeat this for the 8.3.3 build. A very important
- step is the <command>make clean</command>; it is not so
- important the first time, but when building the second time, it
- is essential to clean out the old binaries, otherwise the
- binaries will not match the &postgres; 8.3.3 build with the
- result that &slony1; will not work there. </para>
+<programlisting>
+ wget http://main.slony.info/downloads/1.2/source/slony1-1.2.14.tar.bz2
+</programlisting>
- </sect3>
- <sect3>
- <title>Creating the slon_tools.conf</title>
+<para>
+ Déballez l'archive et construisez le paquet en tant que root avec :
+</para>
+<programlisting>
+tar xjf slony1-1.2.14.tar.bz2
+cd slony1-1.2.14
+./configure --prefix=/data/pgsql-8.2.3 --with-perltools=/data/pgsql-8.2.3/slony --with-pgconfigdir=/data/pgsql-8.2.3/bin
+make clean
+make
+make install
+chown -R postgres:postgres /data/pgsq-8.2.3
+mkdir /var/log/slony
+chown -R postgres:postgres /var/log/slony
+</programlisting>
+
+<para>
+ Puis répétez ceci pour la construction de PostgreSQL 8.3.3. <command>make
+ clean</command> est une étape très importante ; ce n'est pas si important
+ la première fois mais lors de la deuxième construction, il est essentiel de
+ supprimer les anciens binaires, sinon les binaires ne vont pas correspondre
+ à la construction 8.3.3 de &postgres; 8.3.3 avec comme résultat le non
+ fonctionnement de &slony1;.
+</para>
+
+</sect3>
+
+<sect3>
+<title>Créer slon_tools.conf</title>
+
+<para>
+ slon_tools.conf est <emphasis>le</emphasis> fichier de configuration. Il
+ contient entre autres :
+
+ <orderedlist>
+ <listitem>
+ <para>
+ Tous les nœuds et leurs détails (IP, port, base de données,
+ utilisateur, mot de passe) ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Toutes les tables à répliquer ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Toutes les séquences à répliquer ;
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ L'arrangement des tables et séquences en ensembles.
+ </para>
+ </listitem>
+ </orderedlist>
+</para>
+
+<para>
+ Faites une copie de
+ <filename>/data/pgsql-8.2.3/etc/slon_tools.conf-sample</filename> dans
+ <filename>slon_tools.conf</filename> et ouvrez ce dernier. Les commentaires
+ dans ce fichier sont suffisamment explicatifs. Comme il s'agit d'une
+ réplication en un temps, vous n'aurez généralement pas besoin de créer
+ plusieurs ensembles. Sur une machine de production comprenant 500 tables et
+ 100 séquences, les placer dans un seul ensemble a bien fonctionné.
+</para>
+
+<para>
+ Quelques modifications à entreprendre :
+</para>
+
+<orderedlist>
+ <listitem>
<para>
- The slon_tools.conf is <emphasis>the</emphasis> configuration
- file. It contain all all the configuration information such as:
+ Dans notre cas, nous avons seulement besoin de deux nœuds, donc
+ supprimez les <command>add_node</command> pour 3 et 4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ L'entrée <envar>pkeyedtables</envar> doit être mise à jour avec chacune de
+ vos tables qui ont une clé primaire. Si vos tables sont dans différents
+ schémas, vous devez qualifier le nom de la table avec celui du schéma
+ (nomschéma.nomtable).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ L'entrée <envar>keyedtables</envar> doit être mise à jour avec toute
+ table correspondant au commentaire (si la conception du schéma est bonne,
+ il ne devrait pas y en avoir).
+ </para>
+ </listitem>
- <orderedlist>
- <listitem>
- <para>All the nodes and their details (IPs, ports, db, user,
- password)</para>
- </listitem>
- <listitem>
- <para>All the tables to be replicated</para>
- </listitem>
- <listitem>
- <para>All the sequences to be replicated</para>
- </listitem>
- <listitem>
- <para> How the tables and sequences are arranged in sets</para>
- </listitem>
- </orderedlist>
- </para>
- <para> Make a copy of
- <filename>/data/pgsql-8.2.3/etc/slon_tools.conf-sample</filename>
- to <filename>slon_tools.conf</filename> and open it. The comments
- in this file are fairly self explanatory. Since this is a one time
- replication you will generally not need to split into multiple
- sets. On a production machine running with 500 tables and 100
- sequences, putting them all in a single set has worked fine.</para>
-
- <orderedlist>
- <para>A few modifications to do:</para>
- <listitem>
- <para> In our case we only need 2 nodes so delete the <command>add_node</command>
- for 3 and 4.</para>
- </listitem>
- <listitem>
- <para> <envar>pkeyedtables</envar> entry need to be updated with your tables that
- have a primary key. If your tables are spread across multiple
- schemas, then you need to qualify the table name with the schema
- (schema.tablename)</para>
- </listitem>
- <listitem>
- <para> <envar>keyedtables</envar> entries need to be updated
- with any tables that match the comment (with good schema
- design, there should not be any).
- </para>
- </listitem>
- <listitem>
- <para> <envar>serialtables</envar> (if you have any; as it says, it is wise to avoid this).</para>
- </listitem>
- <listitem>
- <para> <envar>sequences</envar> needs to be updated with your sequences.
- </para>
- </listitem>
- <listitem>
- <para>Remove the whole set2 entry (as we are only using set1)</para>
- </listitem>
- </orderedlist>
- <para>
- This is what it look like with all comments stripped out:
- <programlisting>
+ <listitem>
+ <para>
+ <envar>serialtables</envar> (si vous en avez, mais il est préférable de
+ les éviter).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <envar>sequences</envar> doit être mise à jour avec la liste de vos
+ séquences.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Supprimez complètement l'entrée set2 (car nous allons seulement utilisé
+ set1).
+ </para>
+ </listitem>
+</orderedlist>
+
+<para>
+ Voici à quoi cela ressemble une fois tous les commentaires supprimés :
+
+ <programlisting>
$CLUSTER_NAME = 'replication';
$LOGDIR = '/var/log/slony';
$MASTERNODE = 1;
@@ -393,73 +443,98 @@
};
1;
- </programlisting>
- </para>
- <para> As can be seen this database is pretty small with only 8
- tables and 6 sequences. Now copy your
- <filename>slon_tools.conf</filename> into
- <filename>/data/pgsql-8.2.3/etc/</filename> and
- <filename>/data/pgsql-8.3.3/etc/</filename>
- </para>
- </sect3>
- <sect3>
- <title>Preparing the new &postgres; instance</title>
- <para> You now have a fresh second instance of &postgres; running on
- port 5433 on the same machine. Now is time to prepare to
- receive &slony1; replication data.</para>
- <orderedlist>
- <listitem>
- <para>Slony does not replicate roles, so first create all the
- users on the new instance so it is identical in terms of
- roles/groups</para>
- </listitem>
- <listitem>
- <para>
- Create your db in the same encoding as original db, in my case
- UTF8
- <command>/data/pgsql-8.3.3/bin/createdb
- -E UNICODE -p5433 mydb</command>
- </para>
- </listitem>
- <listitem>
- <para>
- &slony1; replicates data, not schemas, so take a dump of your schema
- <command>/data/pgsql-8.2.3/bin/pg_dump
- -s mydb > /tmp/mydb.schema</command>
- and then import it on the new instance.
- <command>cat /tmp/mydb.schema | /data/pgsql-8.3.3/bin/psql -p5433
- mydb</command>
- </para>
- </listitem>
- </orderedlist>
+ </programlisting>
+</para>
- <para>The new database is now ready to start receiving replication
- data</para>
+<para>
+ Comme vous le voyez, cette base de données est très petite avec seulement huit
+ tables et six séquences. Maintenant, copiez votre fichier
+ <filename>slon_tools.conf</filename> dans
+ <filename>/data/pgsql-8.2.3/etc/</filename> et
+ <filename>/data/pgsql-8.3.3/etc/</filename>.
+</para>
- </sect3>
- <sect3>
- <title>Initiating &slony1; Replication</title>
- <para>This is the point where we start changing your current
- production database by adding a new schema to it that contains
- all the &slony1; replication information</para>
- <para>The first thing to do is to initialize the &slony1;
- schema. Do the following as, in the example, the postgres user.</para>
- <note>
- <para> All commands starting with <command>slonik</command> does not do anything
- themself they only generate command output that can be interpreted
- by the slonik binary. So issuing any of the scripts starting with
- slonik_ will not do anything to your database. Also by default the
- slonik_ scripts will look for your slon_tools.conf in your etc
- directory of the postgresSQL directory. In my case
- <filename>/data/pgsql-8.x.x/etc</filename> depending on which you are working on.</para>
- </note>
+</sect3>
+
+<sect3>
+<title>Préparer la nouvelle instance &postgres;</title>
+
+<para>
+ Vous avez maintenant une toute nouvelle seconde instance de &postgres;
+ fonctionnant sur le port 5433 de la même machine. C'est le moment de préparer
+ la réception des données à répliquer par &slony1;.
+</para>
+
+<orderedlist>
+ <listitem>
<para>
- <command>/data/pgsql-8.2.3/slony/slonik_init_cluster
- > /tmp/init.txt</command>
+ Slony ne réplique pas les rôles, donc il faut tout d'abord créer tous
+ les utilisateurs sur la nouvelle instance pour qu'elle soit identique
+ en terme de rôles/groupes.
</para>
- <para>open /tmp/init.txt and it should look like something like
- this</para>
- <programlisting>
+ </listitem>
+
+ <listitem>
+ <para>
+ Créez votre base de données dans le même encodage que la base de données
+ origine, dans mon cas il s'agit de l'UTF8
+ <command>/data/pgsql-8.3.3/bin/createdb -E UNICODE -p5433 mydb</command>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ &slony1; réplique les données, pas les schémas. Donc faites une sauvegarde
+ de votre schéma avec la commande
+ <command>/data/pgsql-8.2.3/bin/pg_dump -s mydb > /tmp/mydb.schema</command>
+ puis importez-le dans la nouvelle instance avec
+ <command>cat /tmp/mydb.schema | /data/pgsql-8.3.3/bin/psql -p5433 mydb</command>
+ </para>
+ </listitem>
+</orderedlist>
+
+<para>
+ La nouvelle base de données est enfin prête à recevoir les données de la
+ réplication.
+</para>
+
+</sect3>
+
+<sect3>
+<title>Lancer la réplication &slony1;</title>
+
+<para>
+ C'est le moment où nous commençons à modifier la base de données de production
+ en y ajoutant un nouveau schéma contenant toutes les informations de
+ réplication de &slony1;.
+</para>
+
+<para>
+ La première chose à faire est d'initialiser le schéma de &slony1;. Faites-le
+ en tant qu'utilisateur postgres, comme dans l'exemple qui suit.
+</para>
+
+<note>
+ <para>
+ Toutes les commandes commençant avec <command>slonik</command> ne font rien
+ elles-même. Elles génèrent des commandes qui peuvent être interprétées par
+ l'outil slonik. Donc exécuter des scripts commençant par slonik_ ne fera
+ rien à votre base de données. De plus, par défaut, les scripts slonik_
+ recherchent votre fichier slon_tools.conf dans le sous-répertoire etc du
+ répertoire PostgreSQL, dans mon cas <filename>/data/pgsql-8.x.x/etc</filename>.
+ </para>
+</note>
+
+<para>
+ <command>/data/pgsql-8.2.3/slony/slonik_init_cluster > /tmp/init.txt</command>
+</para>
+
+<para>
+ Ouvrez /tmp/init.txt et vérifiez qu'il contient un texte ressemblant à celui
+ disponible ci-dessous :
+</para>
+
+<programlisting>
# INIT CLUSTER
cluster name = replication;
node 1 admin conninfo='host=rome dbname=mydb user=postgres port=5432';
@@ -476,93 +551,124 @@
store path (server = 2, client = 1, conninfo = 'host=rome dbname=mydb user=postgres port=5433');
echo 'Replication nodes prepared';
echo 'Please start a slon replication daemon for each node';
-
- </programlisting>
- <para>The first section indicates node information and the
- initialization of the cluster, then it adds the second node to the
- cluster and finally stores communications paths for both nodes in
- the slony schema.</para>
- <para>
- Now is time to execute the command:
- <command>cat /tmp/init.txt | /data/pgsql-8.2.3/bin/slonik</command>
- </para>
- <para>This will run pretty quickly and give you some output to
- indicate success.</para>
- <para>
- If things do fail, the most likely reasons would be database
- permissions, <filename>pg_hba.conf</filename> settings, or typos
- in <filename>slon_tools.conf</filename>. Look over your problem
- and solve it. If slony schemas were created but it still failed
- you can issue the script <command>slonik_uninstall_nodes</command> to
- clean things up. In the worst case you may connect to each
- database and issue <command>drop schema _replication cascade;</command>
- to clean up.
- </para>
- </sect3>
- <sect3>
- <title>The slon daemon</title>
+</programlisting>
- <para>As the result from the last command told us, we should now
- be starting a slon replication daemon for each node! The slon
- daemon is what makes the replication work. All transfers and all
- work is done by the slon daemon. One is needed for each node. So
- in our case we need one for the 8.2.3 installation and one for the
- 8.3.3.</para>
+<para>
+ La première section indique les informations du nœud et l'initialisation
+ du cluster. Puis il y a l'ajout du deuxième nœud au cluster. Enfin,
+ les chemins de communication sont stockés pour les deux nœuds dans
+ le schéma de slony.
+</para>
- <para> to start one for 8.2.3 you would do:
- <command>/data/pgsql-8.2.3/slony/slon_start 1 --nowatchdog</command>
- This would start the daemon for node 1, the --nowatchdog since we
- are running a very small replication we do not need any watchdogs
- that keep an eye on the slon process if it stays up etc. </para>
+<para>
+ C'est le bon moment pour exécuter la commande :
+ <command>cat /tmp/init.txt | /data/pgsql-8.2.3/bin/slonik</command>
+</para>
- <para>if it says started successfully have a look in the log file
- at /var/log/slony/slony1/node1/ It will show that the process was
- started ok</para>
+<para>
+ L'exécution sera rapide et indiquera par un affichage le succès.
+</para>
- <para> We need to start one for 8.3.3 as well. <command>
- <command>/data/pgsql-8.3.3/slony/slon_start 2 --nowatchdog</command>
- </command> </para>
+<para>
+ En cas d'échec, les raisons les plus probables sont un problème de droits
+ sur la base de données, une mauvaise configuration de
+ <filename>pg_hba.conf</filename> ou une erreur de saisie dans
+ <filename>slon_tools.conf</filename>. Cherchez le problème et résolvez-le.
+ Si les schémas slony ont été créés mais que le script échoue toujours,
+ vous pouvez exécuter le script <command>slonik_uninstall_nodes</command>
+ pour tout nettoyer. Dans le pire des cas, vous pouvez vous connecter à
+ chaque base de données et exécuter <command>drop schema _replication
+ cascade;</command> pour bien nettoyer.
+</para>
- <para>If it says it started successfully have a look in the log
- file at /var/log/slony/slony1/node2/ It will show that the process
- was started ok</para>
- </sect3>
- <sect3>
- <title>Adding the replication set</title>
- <para>We now need to let the slon replication know which tables and
- sequences it is to replicate. We need to create the set.</para>
- <para>
- Issue the following:
- <command>/data/pgsql-8.2.3/slony/slonik_create_set
- set1 > /tmp/createset.txt</command>
- </para>
+</sect3>
- <para> <filename> /tmp/createset.txt</filename> may be quite lengthy depending on how
- many tables; in any case, take a quick look and it should make sense as it
- defines all the tables and sequences to be replicated</para>
+<sect3>
+<title>Le démon slon</title>
- <para>
- If you are happy with the result send the file to the slonik for
- execution
- <command>cat /tmp/createset.txt | /data/pgsql-8.2.3/bin/slonik
- </command>
- You will see quite a lot rolling by, one entry for each table.
- </para>
- <para>You now have defined what is to be replicated</para>
- </sect3>
- <sect3>
- <title>Subscribing all the data</title>
- <para>
- The final step is to get all the data onto the new database. It is
- simply done using the subscribe script.
- <command>data/pgsql-8.2.3/slony/slonik_subscribe_set
- 1 2 > /tmp/subscribe.txt</command>
- the first is the ID of the set, second is which node that is to
- subscribe.
- </para>
- <para>
- will look something like this:
- <programlisting>
+<para>
+ Comme l'indique le résultat de la dernière commande, nous devons maintenant
+ lancer le démon de réplication slon pour chaque nœud. Le démon slon
+ est le moteur de la réplication. Tous les transferts et tout le reste du
+ travail sont réalisés par le démon slon. Il est nécessaire d'en avoir un
+ pour chaque nœud. Donc, dans notre cas, nous en avons besoin d'un
+ pour l'installation 8.2.3 et un autre pour la 8.3.3.
+</para>
+
+<para>
+ Pour lancer celui de la 8.2.3, faites ceci :
+ <command>/data/pgsql-8.2.3/slony/slon_start 1 --nowatchdog</command>
+ Ceci va démarrer le démon du nœud 1. L'option --nowatchdog est
+ intéressante car nous faisons une toute petite réplication et que nous
+ n'avons donc pas besoin de chiens de garde ayant un œil sur
+ l'exécution du processus slon.
+</para>
+
+<para>
+ S'il démarre bien, jetez un œil dans les traces du répertoire
+ /var/log/slony/slony1/node1/. Elles doivent indiquer que le processus
+ s'est bien lancé.
+</para>
+
+<para>
+ Nous avons besoin d'en lancer un aussi pour la 8.3.3.
+ <command>/data/pgsql-8.3.3/slony/slon_start 2 --nowatchdog</command>
+</para>
+
+<para>
+ S'il démarre bien, jetez un œil dans les traces du répertoire
+ /var/log/slony/slony1/node2/. Elles doivent indiquer que le processus
+ s'est bien lancé.
+</para>
+
+</sect3>
+
+<sect3>
+<title>Ajouter l'ensemble de réplication</title>
+
+<para>
+ Maintenant, nous avons besoin d'indiquer à slon les tables et séquences à
+ répliquer. Nous devons donc créer l'ensemble de réplication.
+</para>
+
+<para>
+ Exécutez la commande suivante :
+ <command>/data/pgsql-8.2.3/slony/slonik_create_set set1 > /tmp/createset.txt</command>
+</para>
+
+<para>
+ <filename>/tmp/createset.txt</filename> peut devenir vraiment gros, cela
+ dépend du nombre de tables ; de toute façon, jetez-y un œil pour
+ vérifier qu'il a bien défini toutes les tables et séquences à répliquer.
+</para>
+
+<para>
+ Si vous êtes satisfait du résultat, envoyez le fichier à slonik pour qu'il
+ soit exécuté :
+ <command>cat /tmp/createset.txt | /data/pgsql-8.2.3/bin/slonik</command>
+ Vous verrez des traces indiquant chaque table à répliquer.
+</para>
+
+<para>
+ Et voilà, vous avez défini l'ensemble de tables et séquences à répliquer.
+</para>
+
+</sect3>
+
+<sect3>
+<title>L'abonnement</title>
+
+<para>
+ L'étape finale est d'obtenir toutes les données sur la nouvelle base de
+ données. Cela se fait simplement en utilisant le script d'abonnement.
+ <command>data/pgsql-8.2.3/slony/slonik_subscribe_set 1 2 > /tmp/subscribe.txt</command>
+ Le premier argument est l'identifiant de l'ensemble, le second est celui du
+ nœud à abonner.
+</para>
+
+<para>
+ Ce script généré ressemble à ceci :
+ <programlisting>
cluster name = replication;
node 1 admin conninfo='host=rome dbname=mydb user=postgres port=5432';
node 2 admin conninfo='host=rome dbname=mydb user=postgres port=5433';
@@ -573,68 +679,89 @@
exit 1;
}
echo 'Subscribed nodes to set 1';
- </programlisting>
- send it to the slonik
- <command>cat /tmp/subscribe.txt | /data/pgsql-8.2.3/bin/slonik
- </command>
+ </programlisting>
+ Envoyez-le à slonik :
+ <command>cat /tmp/subscribe.txt | /data/pgsql-8.2.3/bin/slonik</command>
+</para>
+
+<para>
+ La réplication va maintenant commencer. Elle va copier toutes les données
+ des tables/séquences appartenant à l'ensemble de réplication. Cela peut
+ prendre du temps, suivant la taille de la base de données et la puissance
+ de la machine.
+</para>
+
+<para>
+ Une façon de visualiser la progression est de regarder le contenu des traces
+ avec la commande :
+ <command>tail -f /var/log/slony/slony1/node2/log | grep -i copy</command>
+ Les traces de slony sont verbeuses, mais cela vous permettra de suivre
+ l'avancée de la réplication initiale. À un moment, vous verrez le message
+ « copy completed sucessfully in xxx seconds ». Cela vous dira que
+ la réplication initiale est terminée !
+</para>
+
+<para>
+ Une fois que ceci est fait, il va commencer à rattraper l'activité survenue
+ depuis le début de la réplication initiale. Vous pouvez facilement voir la
+ progression de ce processus dans la base de données. Connectez-vous à la
+ base de données maître. Il existe une vue appelée sl_status dans le schéma
+ de la réplication. Le champ le plus intéressant est st_lag_num_event. Cela
+ déclare le nombre d'événements slony en retard. 0 est le but à atteindre.
+ Évidemment, cela dépend de l'activité de votre base de données. Le champ
+ suivant est st_lag_time, une estimation du temps restant. À considérer
+ avec prudence, st_lag_num_event étant une mesure bien plus précise.
+</para>
+
+<para>
+ Vous avez maintenant une base de données entièrement répliquée.
+</para>
+
+</sect3>
+
+<sect3>
+<title>La bascule</title>
+
+<para>
+ Notre base de données est entièrement répliquée. Il existe différentes options
+ pour faire la bascule.
+</para>
+
+<orderedlist>
+ <listitem>
+ <para>
+ Tout d'abord, modifiez le fichier postgresql.conf pour que la version
+ 8.3.3 utilise le port 5432, de façon à ce qu'il soit prêt dès le
+ redémarrage.
</para>
- <para>The replication will now start. It will copy everything in
- tables/sequneces that were in the set. understandable this can take
- quite some time, all depending on the size of db and power of the
- machine.</para>
+ </listitem>
+ <listitem>
<para>
- One way to keep track of the progress would be to do the following:
- <command>tail -f /var/log/slony/slony1/node2/log | grep -i copy
- </command>
- The slony logging is pretty verbose and doing it this way will let
- you know how the copying is going. At some point it will say "copy
- completed sucessfully in xxx seconds" when you do get this it is
- done!
+ À partir de ce moment, vous êtes hors production. Arrêtez le serveur
+ 8.2.3.
</para>
- <para>Once this is done it will start trying to catch up with all
- data that has come in since the replication was started. You can
- easily view the progress of this in the database. Go to the master
- database, in the replication schema there is a view called
- sl_status. It is pretty self explanatory. The field of most interest
- is the "st_lag_num_events" this declare how many slony events behind
- the node is. 0 is best. but it all depends how active your db is.
- The field next to it st_lag_time is an estimation how much in time
- it is lagging behind. Take this with a grain of salt. The actual
- events is a more accurate messure of lag.</para>
- <para>You now have a fully replicated database</para>
- </sect3>
- <sect3>
- <title>Switching over</title>
- <para>Our database is fully replicated and its keeping up. There
- are few different options for doing the actual switch over it all
- depends on how much time you got to work with, down time vs. data
- loss ratio. the most brute force fast way of doing it would be
+ </listitem>
+ <listitem>
+ <para>
+ Redémarrez le serveur 8.3.3. Cela ne devrait pas poser de problèmes.
</para>
- <orderedlist>
- <listitem>
- <para>First modify the postgresql.conf file for the 8.3.3 to
- use port 5432 so that it is ready for the restart</para>
- </listitem>
- <listitem>
- <para>From this point you will have down time. shutdown the
- 8.2.3 postgreSQL installation</para>
- </listitem>
- <listitem>
- <para>restart the 8.3.3 postgreSQL installation. It should
- come up ok.</para>
- </listitem>
- <listitem>
- <para>
- drop all the slony stuff from the 8.3.3 installation login psql to
- the 8.3.3 and issue
+ </listitem>
+ <listitem>
+ <para>
+ Supprimez les objets slony du serveur 8.3.3, puis exécutez la commande :
<command>drop schema _replication cascade;</command>
</para>
- </listitem>
- </orderedlist>
- <para>You have now upgraded to 8.3.3 with, hopefully, minimal down
- time. This procedure represents roughly the simplest way to do
- this.</para>
- </sect3>
- </sect2>
+ </listitem>
+</orderedlist>
+<para>
+ Vous êtes maintenant en 8.3.3. La mise à jour est terminée avec, on l'espère,
+ un temps minimal passé hors production. Cette procédure est la façon le plus
+ simple de le faire.
+</para>
+
+</sect3>
+
+</sect2>
+
</sect1>
Plus d'informations sur la liste de diffusion Trad