[Trad] [svn:pgfr] r1331 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 25 Mai 13:09:57 CEST 2009
Author: gleu
Date: 2009-05-25 13:09:57 +0200 (Mon, 25 May 2009)
New Revision: 1331
Modified:
traduc/trunk/slony/failover.xml
traduc/trunk/slony/installation.xml
traduc/trunk/slony/prerequisites.xml
traduc/trunk/slony/slonconf.xml
traduc/trunk/slony/slonik_ref.xml
Log:
Traduction de Slony 2.0.2.
Modified: traduc/trunk/slony/failover.xml
===================================================================
--- traduc/trunk/slony/failover.xml 2009-05-24 12:22:07 UTC (rev 1330)
+++ traduc/trunk/slony/failover.xml 2009-05-25 11:09:57 UTC (rev 1331)
@@ -303,86 +303,103 @@
</sect2>
<sect2 id="complexfailover">
-<title> Failover With Complex Node Set </title>
+<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>
-
-<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>
Modified: traduc/trunk/slony/installation.xml
===================================================================
--- traduc/trunk/slony/installation.xml 2009-05-24 12:22:07 UTC (rev 1330)
+++ traduc/trunk/slony/installation.xml 2009-05-25 11:09:57 UTC (rev 1331)
@@ -224,15 +224,17 @@
à une version a tendance à grossir...)
</para>
-<para>The <filename>.sql</filename> files are not fully substituted
-yet. And yes, versions for all supported versions of &postgres;
-(<emphasis>e.g.</emphasis> - such as 7.3, 7.4 8.0) get installed on
-every system, irrespective of its version. The <xref
-linkend="slonik"/> admin utility does namespace/cluster substitutions
-within these files, and loads the files when creating replication
-nodes. At that point in time, the database being initialized may be
-remote and may run a different version of &postgres; than that of the
-local host.</para>
+<para>
+ Les fichiers <filename>.sql</filename> ne sont pas encore complètement
+ substitués. Les versions pour chaque version supportée de &postgres;
+ (<emphasis>c'est-à-dire</emphasis> par exemple 7.3, 7.4, 8.0) sont
+ installées sur chaque système, quelque soit sa version. L'outil
+ d'administration <xref linkend="slonik"/> fait la substitution de
+ l'espace de noms et du cluster dans ces fichiers, puis charge ces fichiers
+ lors de la création desnœuds de répliation. À ce moment, la base de
+ données en cours d'initialisation peut se trouver à distance et être exécutée
+ par une autre version de &postgres; que celle de l'hôte local
+.</para>
<para>
Pour terminer, les deux objets partagés installés dans le répertoire
@@ -241,24 +243,35 @@
chargés à distance à partir des autres nœuds.).
</para>
-<para> In &slony1; version 2.0, this changes:</para>
+<para>
+ Dans &slony1; version 2.0, cela 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>
@@ -284,8 +297,8 @@
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/trunk/slony/prerequisites.xml
===================================================================
--- traduc/trunk/slony/prerequisites.xml 2009-05-24 12:22:07 UTC (rev 1330)
+++ traduc/trunk/slony/prerequisites.xml 2009-05-25 11:09:57 UTC (rev 1331)
@@ -19,10 +19,10 @@
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 and 5.3,
- OpenBSD-3.5-sparc64 and &windows; 2000, XP and 2003 (32 bit). There
- is enough diversity amongst these platforms that nothing ought to
- prevent running &slony1; on other similar platforms.
+ <trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1 et 5.3,
+ OpenBSD-3.5-sparc64 et &windows; 2000, XP et 2003 (32 bit). Il y a
+ suffisamment de diversité parmi ces plateformes que rien ne devrait
+ empêcher &slony1; de s'exécuter sur d'autres plateformes similaires.
</para>
<sect2>
@@ -99,9 +99,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.
+ Certaines versions de &postgres; ne sont pas compatibles avec certaines
+ versions de &slony1;. Voir <xref linkend="installation"/> pour plus de
+ détails.
</para>
</listitem>
Modified: traduc/trunk/slony/slonconf.xml
===================================================================
--- traduc/trunk/slony/slonconf.xml 2009-05-24 12:22:07 UTC (rev 1330)
+++ traduc/trunk/slony/slonconf.xml 2009-05-25 11:09:57 UTC (rev 1331)
@@ -140,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>
Modified: traduc/trunk/slony/slonik_ref.xml
===================================================================
--- traduc/trunk/slony/slonik_ref.xml 2009-05-24 12:22:07 UTC (rev 1330)
+++ traduc/trunk/slony/slonik_ref.xml 2009-05-25 11:09:57 UTC (rev 1331)
@@ -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,11 +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>
@@ -2520,12 +2525,13 @@
<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>
Plus d'informations sur la liste de diffusion Trad