[Trad] [svn:pgfr] r1127 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Dim 24 Aou 22:54:14 CEST 2008
Author: daamien
Date: 2008-08-24 22:54:14 +0200 (Sun, 24 Aug 2008)
New Revision: 1127
Modified:
traduc/trunk/slony/addthings.xml
Log:
Slony : addthings ( ?\195?\160 relire )
Modified: traduc/trunk/slony/addthings.xml
===================================================================
--- traduc/trunk/slony/addthings.xml 2008-08-24 19:31:18 UTC (rev 1126)
+++ traduc/trunk/slony/addthings.xml 2008-08-24 20:54:14 UTC (rev 1127)
@@ -5,7 +5,7 @@
révision $Revision$ -->
<sect1 id="addthings">
-<title>Une vue des taches &slony1;</title>
+<title>Ajouter des objets à la réplication</title>
<indexterm><primary>ajouter des objets à la réplication</primary></indexterm>
@@ -37,7 +37,7 @@
Ce problème fut résolu avec la version 1.0.5. Jusqu'à la version 1.2.1,
il existait toujours un problème avec <xref linkend="stmtmergeset"/>,
si la commande était lancée avant que tous les abonnements soient complets,
-des <quote>perturbations</quote> pouvaient apparaitre sur les noeuds
+des <quote>perturbations</quote> pouvaient apparaître sur les noeuds
où l'activité d'abonnement n'était pas terminée. </para>
<para> Notez que si vous ajoutez des noeuds, vous devez également ajouter
@@ -59,7 +59,7 @@
<para>Mais en général, il est plus facile de gérer les reconfigurations
complexes en s'assurant qu'un changement a été parfaitement réussi avant
de passer au suivant. Il est beaucoup plus simple de corriger un problème
-unique que de réparer les dégats provoqués par l'interaction erronée de cing commandes
+unique que de réparer les dégâts provoqués par l'interaction erronée de cinq commandes
successives.<</para>
<para> Voici un ensemble de <quote>recettes</quote> pour réaliser
@@ -69,7 +69,7 @@
<indexterm><primary> ajouter une table dans le cluster de réplication </primary></indexterm>
-<para> &slony1; ne vous permet pas d'ajouter une table dans un ensemblde de
+<para> &slony1; ne vous permet pas d'ajouter une table dans un ensemble de
qui est déjà en cours de réplication. En principe, c'est certainement
<emphasis>possible</emphasis>; mais cela implique l'événement SET_ADD_TABLE
produise le code adéquat à partir de l'événement SUBSCRIBE_SET invoqué
@@ -136,7 +136,7 @@
au autres questions du type <quote>Comment modifier la définition
de tables répliquées ?</quote></para>
-<para>Si vous changez la <quote>shape</quote> d'une table répliquée, vous devez le
+<para>Si vous changez la <quote>forme</quote> d'une table répliquée, vous devez le
faire au même instant dans le <quote>flux de transaction</quote> sur tous les noeuds
qui sont abonnés à l'ensemble qui contient la table.</para>
@@ -159,25 +159,25 @@
<itemizedlist>
<listitem><para> Vous <emphasis>ne devez absolument jamais</emphasis> inclure
-des commandes de controle de transaction, notamment <command>BEGIN</command>
+des commandes de contrôle de transaction, notamment <command>BEGIN</command>
et <command>COMMIT</command>, à l'intérieur de ces scripts. &slony1;
encapsule les scripts DDL avec une paire <command>BEGIN</command>/<command>COMMIT</command>
-; ajouter de opérateur de controle de transaction supplémentaire
+; ajouter de opérateur de contrôle de transaction supplémentaire
implique que des parties des ordres DDL seront <quote>committés</quote>
-en dehors du controle de &slony1; </para></listitem>
+en dehors du contrôle de &slony1; </para></listitem>
<listitem><para> Avant la version 1.2, il était nécessaire d'être
extrêmement restrictif sur ce qu'on envoyait au script
<xref linkend="stmtddlscript"/>. </para>
<para> Il était interdit de placer du texte <command>'entre quotes'</command>
-dans le script, car cela l'empéchait d'être stocké et transmis correctement
+dans le script, car cela l'empêchait d'être stocké et transmis correctement
. A partir de la version 1.2, les quotes sont correctement prises en compte. </para>
-<para> Si vous soumettez une séries d'order DDL, les derniers
+<para> Si vous soumettez une séries d'ordre DDL, les derniers
ne peuvent pas faire référence aux objets créés par les premiers,
car tous les ordres sont soumis dans un requête unique,
-dont le plan d'execution est basé sur l'état de la base de donnée
+dont le plan d'exécution est basé sur l'état de la base de donnée
au <emphasis>début</emphasis>, avant que les modifications ne soient
effectuées. À partir de la version 1.2, il y a 12 ordres SQL, chacun est soumis
individuellement, ainsi la commande <command> alter table x add column c1
@@ -219,7 +219,7 @@
<listitem><para> Vous pouvez utiliser la commande Slonik <xref linkend="stmtdropnode"/>
pour supprimer un noeud du cluster. Ceci provoquera la suppression
des triggers et tout ce qui se trouve dans schéma cluster.
-Le processus <xref linkend="slon"/> sera automatiquement mourrir.</para></listitem>
+Le processus <xref linkend="slon"/> sera automatiquement mourir.</para></listitem>
<listitem><para> Dans le cas d'un noeud en échec ( lorsque vous avez utilisé
la commande <xref linkend="stmtfailover"/> pour basculer sur un autre noeud
@@ -231,7 +231,7 @@
il est possible qu'il n'y ait plus de traces de la base de données sur le noeud;
En général, la base ne survive que lorsque la panne matérielle est un
problème de réseau qui n'endommage pas les données mais qui vous oblige à
-supprimer le noeud à cause de coupures réseau persitantes.
+supprimer le noeud à cause de coupures réseau persistantes.
</para></listitem>
<listitem><para> Si les opérations ci-dessus se sont particulièrement
@@ -278,7 +278,7 @@
<listitem><para> Si le noeud était un noeud en échec, vous devez lancer
la commande <xref linkend="slonik"/> <xref linkend="stmtdropnode"/>
-afin de vous débarasser de ses vestiges dans le cluster et de supprimer
+afin de vous débarrasser de ses vestiges dans le cluster et de supprimer
le schéma que &slony1; a créé.
</para></listitem>
@@ -287,7 +287,7 @@
</para></listitem>
<listitem><para> À cet instant, vous pouvez lancer le démon &lslon; sur le nouveau
-noeud. Il ne connaitra rien des autres noeuds, donc les logs de ce noeud seront
+noeud. Il ne connaîtra rien des autres noeuds, donc les logs de ce noeud seront
particulièrement calmes.
</para></listitem>
@@ -301,125 +301,122 @@
</para></listitem>
<listitem><para> A cet instant, lancer le script
-<command>test_slony_state-dbi.pl</command> est une excellente idée, 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.</para> </listitem>
+<command>test_slony_state-dbi.pl</command> est une excellente idée.
+Ce script parcours le cluster le tout entier et pointe les anomalies
+qu'il trouve. Il peut notamment identifier une grande variété de
+problèmes de communication.</para> </listitem>
-<listitem><para> Issue the slonik
-command <xref linkend="stmtsubscribeset"/> to subscribe the node to
-some replication set.
+<listitem><para> Lancer commande slonik
+<xref linkend="stmtsubscribeset"/> pour abonner le noeud à l'ensemble de réplication.
</para></listitem>
</itemizedlist>
</sect2>
-<sect2><title> How do I reshape subscriptions?</title>
+<sect2><title> Comment remanier les abonnements ?</title>
-<para> For instance, I want subscriber node 3 to draw data from node
-1, when it is presently drawing data from node 2. </para>
+<para> Par exemple, on souhaite que le noeud 3 reçoivent les données
+en provenance du noeud 1, alors qu'actuellement il reçoit les données du noeud 2. </para>
-<para> This isn't a case for <xref linkend="stmtmoveset"/>; we're not
-shifting the origin, just reshaping the subscribers. </para>
+<para> Il ne s'agit pas d'un cas d'utilisation de la commande <xref linkend="stmtmoveset"/>;
+car on ne souhaite pas déplacer l'origine, mais simplement remanier les abonnés.
+</para>
-<para> For this purpose, you can simply submit <xref
-linkend="stmtsubscribeset"/> requests to <emphasis>revise</emphasis>
-the subscriptions. Subscriptions will not be started from scratch;
-they will merely be reconfigured. </para></sect2>
+<para> Pour cela, on peut simplement soumettre des requêtes <xref
+linkend="stmtsubscribeset"/> pour <emphasis>modifier</emphasis>
+les abonnements. Ces abonnements ne seront pas redémarrés à partir de zéro,
+mais simplement reconfigurés.
+</para></sect2>
-<sect2><title> How do I use <link linkend="logshipping">Log Shipping?</link> </title>
-<para> Discussed in the <link linkend="logshipping"> Log Shipping </link> section... </para>
+<sect2><title> Comment utiliser le <link linkend="logshipping">Log Shipping</link> ?</title>
+<para> Cette question est largement débattue dans la section <link linkend="logshipping"> Log Shipping </link>... </para>
</sect2>
-<sect2><title> How do I know replication is working?</title>
+<sect2><title> Comment savoir si la réplication fonctionne ?</title>
-<para> The ultimate proof is in looking at whether data added at the
-origin makes it to the subscribers. That's a <quote>simply matter of
-querying</quote>.</para>
+<para> La preuve ultime est le fait que les données ajoutées sur l'origine
+soit présentes sur les abonnés. Il suffit <quote>simplement de lancer une
+requête</quote> pour le savoir.</para>
-<para> There are several ways of examining replication status, however: </para>
+<para> Cependant, il existe quelques autres méthode pour examiner l'état de la réplication : </para>
<itemizedlist>
-<listitem><para> Look in the &lslon; logs.</para>
+<listitem><para> Regarder les logs des processus &lslon;.</para>
-<para> They won't say too much, even at very high debugging levels, on
-an origin node; at debugging level 2, you should see, on subscribers,
-that SYNCs are being processed. As of version 1.2, the information
-reported for SYNC processing includes counts of the numbers of tables
-processed, as well as numbers of tuples inserted, deleted, and
-updated.</para> </listitem>
+<para> Ils ne vous diront pas grand chose, même à une niveau de debug
+élevé sur le noeud origine; Au niveau 2 de debug, vous devriez voir
+sur les abonnés les événements SYNCs qui sont en cours de traitement.
+À partir de la version 1.2, les informations sur le traitement des
+SYNCs incluent le nombres de tables traitées, ainsi que le nombre
+de tuples insérés, supprimés et mis à jour.</para> </listitem>
-<listitem><para> Look in the view <command> sl_status </command>, on
-the origin node. </para>
+<listitem><para> Regarder dans la vue <command> sl_status </command>, sur
+le noeud origine. </para>
-<para> This view will tell how far behind the various subscribing
-nodes are in processing events from the node where you run the query.
-It will only be <emphasis>very</emphasis> informative on a node that
-originates a replication set.</para> </listitem>
+<para> Cette vue indique quel est le retard des différents noeuds abonnés.
+Cette information n'est pertinente que sur un noeud origine.</para> </listitem>
-<listitem><para> Run the <filename>tools</filename>
-script <command>test_slony_state-dbi.pl</command>, which rummages
-through the state of the entire cluster, pointing out any anomalies
-that it notices, as well as some information on the status of each
-node. </para> </listitem>
+<listitem><para> Lancer le script
+script <command>test_slony_state-dbi.pl</command> qui se trouve dans le répertoire
+<filename>tools</filename>. Ce script parcours le cluster tout entier et pointe les
+anomalies qu'il détecte, ainsi que des informations sur le statut de chaque noeud.
+</para> </listitem>
</itemizedlist>
</sect2>
-<sect2><title>How do I upgrade &slony1; to a newer version? </title>
+<sect2><title>Comment mettre à jour la version de &slony1; ? </title>
-<para> Discussed <link linkend="slonyupgrade"> here </link> </para> </sect2>
+<para> La réponse se trouve <link linkend="slonyupgrade"> ici </link> </para> </sect2>
-<sect2><title> What happens when I fail over?</title>
+<sect2><title> Que se passe-t-il lors d'une bascule d'urgence ?</title>
-<para> Some of this is described under <xref linkend="failover"/> but
-more of a procedure should be written...</para> </sect2>
+<para> Une partie de la réponse se trouve dans la section <xref linkend="failover"/>
+mais il reste beaucoup de choses à écrire sur le sujet...</para> </sect2>
-<sect2><title> How do I <quote>move master</quote> to a new node? </title>
+<sect2><title> Comment <quote>déplacer le maître</quote> vers un autre noeud ? </title>
-<para> You must first pick a node that is connected to the former
-origin (otherwise it is not straightforward to reverse connections in
-the move to keep everything connected). </para>
+<para> Tout d'abord il faut choisir un noeud qui est connecté à l'ancienne origine
+(sinon il n'est pas évident de conserver les connexions lors du changement). </para>
-<para> Second, you must run a &lslonik; script with the
-command <xref linkend="stmtlockset"/> to lock the set on the origin
-node. Note that at this point you have an application outage under
-way, as what this does is to put triggers on the origin that rejects
-updates. </para>
+<para> Deuxièmement, vous devez lancer un script &lslonik; avec la commande
+<xref linkend="stmtlockset"/> pour verrouiller l'ensemble de réplication sur
+le noeud origine. Notez qu'à cet instant votre application risque de ne plus fonctionner,
+car cette opération pose des triggers sur l'origine qui rejetent toutes les mises
+à jour. </para>
-<para> Now, submit the &lslonik; <xref linkend="stmtmoveset"/> request.
-It's perfectly reasonable to submit both requests in the same
-&lslonik; script. Now, the origin gets switched over to the new
-origin node. If the new node is a few events behind, it may take a
-little while for this to take place. </para> </sect2>
+<para> Maintenant, lancez la requête &lslonik; <xref linkend="stmtmoveset"/>.
+Il parfaitement raisonnable de soumettre les deux requêtes à l'intérieur
+d'un même script &lslonik;.
-<sect2> <title> How Do I Do A <quote>Full Sync</quote> On A Table? </title>
+Désormais, l'origine est basculée vers le nouveau noeud origine. Si le nouveau noeud a quelques
+événement de retard, il faudra un peu de temps pour que tout se mette en place. </para> </sect2>
-<para> The &slony1; notion of a <command>SYNC</command> is actually
-always an <emphasis>incremental</emphasis> thing; a
-<command>SYNC</command> represents the set of updates that were
-committed during the scope of a particular <command>SYNC</command>
-event on the origin node. If a set of updates that altered the entire
-contents of a table were committed in a single
-<command>SYNC</command>, that would affect the entire contents of the
-table. But as far as &slony1; is concerned, this change is
-<quote>incremental</quote> even though the increment happened to be
-<quote>the whole table.</quote> </para>
+<sect2> <title> Comment réaliser <quote>synchronisation complète</quote> sur une table? </title>
-<para> The only time that &slony1; <quote>synchronizes</quote> the
-contents of a table is at the time the subscription is set up, at
-which time it uses <command>COPY</command> to draw in the entire
-contents from the provider node.</para>
+<para> Pour &slony1;, la notion de <command>SYNC</command> est toujours quelque chose
+d'<emphasis>incrémental</emphasis>; un <command>SYNC</command> représente
+un ensemble de mises à jour qui furent <quote>committée</quote> pendant
+durée d'un événement <command>SYNC</command> donné sur le noeud origine.
+Si des mises à jour qui ont altérées l'ensemble du contenu d'une
+table sont <quote>committées</quote> au cours d'un
+<command>SYNC</command> unique, alors cela affectera l'ensemble
+du contenu de la table. Mais du point de vue de &slony1;, ce changement est
+<quote>incrémental</quote> même si la modification concerne
+<quote>la table toute entière</quote>.</para>
-<para> Since subscriber tables are protected against modification by
-anything other than &slony1;, there should be no way (aside from
-horrible bugs) for tables to fall out of synchronization. If they do,
-there is some rather serious problem with &slony1;. </para>
+<para> La seule fois où &slony1; <quote>synchronise</quote> le contenu
+d'une table est lors de la mise en place de l'abonnement, à ce moment-là
+il utilise la commande <command>COPY</command> pour rapatrier la totalité
+du contenu de la table à partir du noeud fournisseur.</para>
-<para> If some such severe corruption takes place, the answer is to
-drop the table from replication, then create a new replication set and
-add it back. </para>
+<para> Puisque les tables abonnées sont protégées contre les modifications
+réalisées par un autre utilisateur que &slony1;, il est impossible
+(mis à part d'horribles bogues) que les tables soient désynchronisées.
+Si c'est le cas, alors il y a vraiment un gros problème dans &slony1;. </para>
+<para> Si une corruption très grave se produit, la réponse est de retirer la table
+hors de la réplication, puis de créer un nouvel ensemble de réplication et de l'ajouter
+à nouveau. </para>
</sect2>
-
-</sect1>
+</sect1>
\ No newline at end of file
More information about the Trad
mailing list