[Trad] [svn:pgfr] r1253 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Mar 24 Fév 20:22:05 CET 2009
Author: gleu
Date: 2009-02-24 20:22:04 +0100 (Tue, 24 Feb 2009)
New Revision: 1253
Modified:
traduc/trunk/slony/monitoring.xml
traduc/trunk/slony/slonik_ref.xml
traduc/trunk/slony/versionupgrade.xml
Log:
Suite de la traduction de la version 2.0 de Slony.
Modified: traduc/trunk/slony/monitoring.xml
===================================================================
--- traduc/trunk/slony/monitoring.xml 2009-02-24 14:11:33 UTC (rev 1252)
+++ traduc/trunk/slony/monitoring.xml 2009-02-24 19:22:04 UTC (rev 1253)
@@ -9,18 +9,17 @@
<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.
+ 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.
+ Voici une liste des tables contenant une information particulièrement
+ intéressante d'un point de vue surveillance et diagnostique.
</para>
<glosslist>
@@ -29,20 +28,19 @@
<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.
+ 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.
+ 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>
@@ -52,8 +50,9 @@
<glossdef>
<para>
- Contains confirmations of replication events; this may be used to infer
- which events have, and <emphasis>have not</emphasis> been processed.
+ 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>
@@ -63,21 +62,21 @@
<glossdef>
<para>
- Contains information about the replication events processed on the
- local node.
+ 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>
+ <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.
+ 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>
@@ -87,7 +86,7 @@
<glossdef>
<para>
- The list of nodes in the cluster.
+ La liste des nœuds du cluster.
</para>
</glossdef>
</glossentry>
@@ -97,9 +96,10 @@
<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.
+ Cette table contient les informations de connexion. Elle indique comment
+ les processus slon 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>
@@ -109,10 +109,11 @@
<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>
+ 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>
@@ -122,9 +123,9 @@
<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.
+ 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>
@@ -134,8 +135,7 @@
<glossdef>
<para>
- Contains the <quote>last value</quote> of replicated
- sequences.
+ Contient la <quote>dernière valeur</quote> des séquences répliquées.
</para>
</glossdef>
</glossentry>
@@ -145,9 +145,8 @@
<glossdef>
<para>
- Contains definition information for replication sets,
- which is the mechanism used to group together related replicable
- tables and sequences.
+ 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>
@@ -157,8 +156,9 @@
<glossdef>
<para>
- Contains information about the state of synchronization of each
- replication set, including transaction snapshot data.
+ Contient des informations sur l'état de la syncrhonisation pour chaque
+ ensemble de réplication, ceci incluant les données des images de
+ transaction.
</para>
</glossdef>
</glossentry>
@@ -168,7 +168,8 @@
<glossdef>
<para>
- Indicates what subscriptions are in effect for each replication set.
+ Indique quels abonnements sont effectifs pour chaque ensemble de
+ réplication.
</para>
</glossdef>
</glossentry>
@@ -178,7 +179,7 @@
<glossdef>
<para>
- Contains the list of tables being replicated.
+ Contient la liste des tables en cours de réplication.
</para>
</glossdef>
</glossentry>
@@ -186,116 +187,113 @@
<sect2 id="testslonystate">
<title>test_slony_state</title>
-<indexterm><primary>script test_slony_state to test replication state</primary></indexterm>
+<indexterm><primary>script test_slony_state pour tester l'état de la réplication</primary></indexterm>
<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.
+ 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>
- You specify arguments including <option>database</option>,
+ Vous pouvez spécifier les arguments en incluant <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.
+ <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 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.
+ 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>
- 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.
+ 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>
- For each node, the script examines the state of things,
- including such things as:
+ Pour chaque nœ, the script examine l'état de différents éléments,
+ dont :
</para>
<itemizedlist>
<listitem>
<para>
- Checking <xref linkend="table.sl-listen"/> for some
- <quote>analytically determinable</quote> problems. It lists paths
- that are not covered.
+ 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
+ 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.
+ 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"/>
+ 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.
+ 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
+ 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>.
+ 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.
+ 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>.
+ 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>
<para>
- The script does some diagnosis work based on parameters in the
- script; if you don't like the values, pick your favorites!
+ 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>
<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>.
+ 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>
@@ -466,13 +464,13 @@
</note>
<para>
- Alternatively, Ismail Yenigul points out how he managed to
- monitor slony using <application>MRTG</application> without installing
+ Autrement, Ismail Yenigul indique comment il a géré la surveillance de Slony
+ en utilisant <application>MRTG</application> sans installer
<application>SNMPD</application>.
</para>
<para>
- Here is the mrtg configuration
+ Voici la configuration de mrtg :
</para>
<programlisting>
@@ -484,7 +482,7 @@
</programlisting>
<para>
- and here is the modified version of the script
+ et voici une version modifiée du script :
</para>
<programlisting>
@@ -503,9 +501,8 @@
<note>
<para>
- MRTG expects four lines from the script, and since there
- are only two lines provided, the output must be padded to four
- lines.
+ MRTG attend quatre lignes du script et comme il n'y a que deux lignes
+ fournies, l'affichage doit se voir ajouter quatre lignes.
</para>
</note>
@@ -581,11 +578,11 @@
</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"/>.
+ 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>
@@ -606,54 +603,54 @@
</screen>
<para>
- Here are some notes to interpret this output:
+ Voici quelques notes pour interpréter cet affichage :
</para>
<itemizedlist>
<listitem>
<para>
- Note the line that indicates
+ Notez la ligne qui indique
<screen>inserts=144 updates=1084 deletes=0</screen>
</para>
<para>
- This indicates how many tuples were affected by this particular SYNC.
+ Ceci indique le nombre de lignes touchées par ce SYNC.
</para>
</listitem>
<listitem>
<para>
- Note the line indicating
+ 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.
+ 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
+ Notez la ligne qui indique
<screen>0.978 seconds until close cursor</screen>
</para>
<para>
- This indicates how long processing took against the provider.
+ Ceci indique la durée du traitement par le fournisseur.
</para>
</listitem>
<listitem>
- <para> sync_helper timing: large tuples 0.315/288 </para>
+ <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.
+ 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>
@@ -661,8 +658,8 @@
<para><screen>SYNC 19 done in 1.272 seconds</screen></para>
<para>
- This indicates that it took 0.108 seconds, in total, to process
- this set of SYNCs.
+ Ceci indique qe le traitement a pris au total 0.108 seconds pour cet
+ ensemble de SYNC.
</para>
</listitem>
@@ -672,17 +669,15 @@
</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.
+ 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.
+ 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>
@@ -692,9 +687,9 @@
</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.
+ 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>
Modified: traduc/trunk/slony/slonik_ref.xml
===================================================================
--- traduc/trunk/slony/slonik_ref.xml 2009-02-24 14:11:33 UTC (rev 1252)
+++ traduc/trunk/slony/slonik_ref.xml 2009-02-24 19:22:04 UTC (rev 1253)
@@ -457,9 +457,9 @@
<variablelist>
<varlistentry><term><literal>ID = ival</literal></term>
<listitem><para>L'identifiant numérique 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>
+ <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>
@@ -475,11 +475,11 @@
<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>
@@ -510,10 +510,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>
@@ -585,8 +585,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>
- </refsect1>
+ <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>
</refentry>
<!-- **************************************** -->
@@ -695,10 +695,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>
@@ -1329,13 +1329,13 @@
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>
@@ -1427,10 +1427,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>
@@ -2031,10 +2032,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>
@@ -2506,7 +2505,8 @@
</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>
@@ -2578,14 +2578,14 @@
<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, 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 essentiel que les triggers soient régénérés (<emphasis>e.g.</emphasis> - by
+ <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 attributes in the <function>logtrigger()</function> trigger peuvent
être inadaptés à la nouvelle forme du schéma.
</para>
@@ -2656,8 +2656,8 @@
que les triggers sont retirés au départ et restaurés à la fin).
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>
@@ -2757,8 +2757,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 for confirmation of an event, which hopefully means that
- the the next action.
+script <application>slonik</application> d'attendre pour la confirmation d'un événement,
+ce qui est important pour la prochaine action.
</para>
<para><command>WAIT FOR EVENT</command> doit être appelée en dehors d'un
@@ -2808,8 +2808,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>
Modified: traduc/trunk/slony/versionupgrade.xml
===================================================================
--- traduc/trunk/slony/versionupgrade.xml 2009-02-24 14:11:33 UTC (rev 1252)
+++ traduc/trunk/slony/versionupgrade.xml 2009-02-24 19:22:04 UTC (rev 1253)
@@ -105,12 +105,11 @@
</para>
<para>
- This procedure should only need to take a very short time,
- likely 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>
@@ -222,132 +221,183 @@
</note>
<sect2>
-<title>Example: Upgrading a single database with no existing replication </title>
+<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>
+Database machine:
+ 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;
@@ -395,73 +445,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';
@@ -478,93 +553,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';
@@ -575,68 +681,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>
More information about the Trad
mailing list