[Trad] [svn:pgfr] r1093 - traduc/trunk/slony

[svncommit at kryskool.org]

Auteur: daamien
Date: 2008-07-08 14:08:52 +0200 (mar, 08 jui 2008)
Nouvelle Révision: 1093

Modification:
   traduc/trunk/slony/ddlchanges.xml
Log:
Slony : ddlchanges traduit par Marie (à relire)


Modified: traduc/trunk/slony/ddlchanges.xml
===================================================================
--- traduc/trunk/slony/ddlchanges.xml	2008-07-08 10:52:44 UTC (rev 1092)
+++ traduc/trunk/slony/ddlchanges.xml	2008-07-08 12:08:52 UTC (rev 1093)
@@ -5,84 +5,83 @@
      révision $Revision$ -->
 
 <sect1 id="ddlchanges">
-<title>Database Schema Changes (DDL)</title>
+<title>Changements du schéma de la base (DDL)</title>
 
 <indexterm>
- <primary>DDL changes</primary>
- <secondary>database schema changes</secondary>
+ <primary>Changements DDL</primary>
+ <secondary>changements du schéma de la base</secondary>
 </indexterm>
 
-<para>When changes are made to the database schema,
-<emphasis>e.g.</emphasis> - adding fields to a table, it is necessary
-for this to be handled rather carefully, otherwise different nodes may
-get rather deranged because they disagree on how particular tables are
-built.</para>
+<para>Lorsque des changements sont faits sur la base,
+<emphasis>tels que</emphasis> - l'ajout de champs à une table, il est nécessaire
+de la faire prudemment, pour éviter que certains noeuds
+ne soient bloqués lors de la création de certaines tables
+.</para>
 
-<para>If you pass the changes through &slony1; via <xref
-linkend="stmtddlscript"/> (slonik) / &funddlscript; (stored function),
-this allows you to be certain that the changes take effect at the same
-point in the transaction streams on all of the nodes.  That may not be
-so important if you can take something of an outage to do schema
-changes, but if you want to do upgrades that take place while
-transactions are still winding their way through your systems, this is
-necessary.  </para>
+<para>Si vous opérez les changements à travers &slony1; via <xref
+linkend="stmtddlscript"/> (slonik) / &funddlscript; (fonction stockée),
+cela vous garantie que les changements prendront effets
+au même niveau dans les flux de transactions sur tous les noeuds. Cela n'est pas aussi vital
+si vous pouvez arrêter votre système pour appliquer vos modifications de schéma,
+mais si vous voulez faire vos mises à jour en même temps que vos transactions continuent de processer à travers votre système,
+cela est nécessaire.  </para>
 
-<para>It is essential to use <command>EXECUTE SCRIPT</command> if you
-alter tables so as to change their schemas.  If you do not, then you
-may run into the problems <link linkend="neededexecddl"> described
-here </link> where triggers on modified tables do not take account of
-the schema change.  This has the potential to corrupt data on
-subscriber nodes.</para>
+<para>Il est essentiel d'utiliser <command>EXECUTE SCRIPT</command> si vous
+modifiez des tables pour changer leurs schémas.  Si vous ne le faites pas, vous pouvez rencontrer
+des problèmes <link linkend="neededexecddl"> décrits
+ici </link> où les triggers des tables modifiées ne tiennent pas compte des changements
+de schéma faits. Cela peut conduire à une corruption de données sur le
+noeud abonné.</para>
 
-<para>It's worth making a couple of comments on <quote>special
-things</quote> about <xref linkend="stmtddlscript"/>:</para>
+<para>Il est utile de faire quelques <quote>recommandations</quote> sur
+ <xref linkend="stmtddlscript"/>:</para>
 
 <itemizedlist>
 
-<listitem><para>The script <emphasis>must not</emphasis> contain
-transaction <command>BEGIN</command> or <command>END</command>
-statements, as the script is already executed inside a transaction.
-In &postgres; version 8, the introduction of nested transactions
-changes this somewhat, but you must still remain aware that the
-actions in the script are processed within the scope of a single
-transaction whose <command>BEGIN</command> and <command>END</command>
-you do not control.</para></listitem>
+<listitem><para>Le script <emphasis>ne doit pas</emphasis> contenir
+de transaction <command>BEGIN</command> ou <command>END</command>
+, car il s'exécute déjà dans une transaction.
+Avec la version 8 de &postgres;, l'introduction des transactions imbriquées
+change cela quelque peu, mais vous devez rester attentif au fait que
+les actions du script sont exécutées comme une transaction simple
+dans laquelle on ne maîtrise pas le <command>BEGIN</command> et le <command>END</command>
+.</para></listitem>
 
-<listitem><para>If there is <emphasis>anything</emphasis> broken about
-the script, or about how it executes on a particular node, this will
-cause the <xref linkend="slon"/> daemon for that node to panic and
-crash.  You may see various expected messages (positive and negative)
-in <xref linkend="ddllogs"/>.  If you restart the &lslon;, it will,
-more likely than not, try to
-<emphasis>repeat</emphasis> the DDL script, which will, almost
-certainly, fail the second time in the same way it did the first time.
-I have found this scenario to lead to a need to go to the
-<quote>master</quote> node to delete the event from the
-table <envar>sl_event</envar> in order to stop it from continuing to
-fail.</para>
+<listitem><para>Si il y a une erreur<emphasis>quelconque</emphasis> dans le script
+, ou un problème quelconque sur la manière dont il s'éxécute sur un noeud particulier,
+cela conduira le démon <xref linkend="slon"/> de ce noeud à paniquer et à tomber.
+Vous pouvez consulter plusieurs types de messages attendus lors d'un déroulement normal ou anormal
+à <xref linkend="ddllogs"/>.  Si vous redémarrez le &lslon;, il tentera,
+de manière très probable, de
+<emphasis>rejouer</emphasis> le script DDL, ce qui conduira certainement au même échec que la première tentative.
+J'ai eu un tel scénario, m'obligeant à supprimer du noeud
+<quote>maître</quote> l'évènement de la table
+<envar>sl_event</envar> pour arrêter de le voir tomber en échec.</para>
 
-<para> The implication of this is that it is
-<emphasis>vital</emphasis> that modifications not be made in a
-haphazard way on one node or another.  The schemas must always stay in
-sync.</para> </listitem>
+<para> La conséquence de cela est qu'il est
+<emphasis>vital</emphasis> que les modifications ne soient pas faites
+de manière hasardeuse sur un noeud ou un autre. Les schémas doivent toujours 
+rester synchronisés.</para> </listitem>
 
-<listitem><para> For &lslon; to, at that point, <quote>panic</quote>
-is probably the
-<emphasis>correct</emphasis> answer, as it allows the DBA to head over
-to the database node that is broken, and manually fix things before
-cleaning out the defective event and restarting
-&lslon;.  You can be certain that the updates
-made <emphasis>after</emphasis> the DDL change on the provider node
-are queued up, waiting to head to the subscriber.  You don't run the
+<listitem><para> Pour &lslon; aussi, à ce niveau, <quote>panic</quote>
+est probablement la réponse
+<emphasis>correcte</emphasis>, car il permet au DBA de sortir la base du noeud défecteux,
+de fixer manuellement le problème en supprimant l'évènement incorrect et de redémarrer
+&lslon;.  Vous pouvez être certain que les mises à jour faites 
+<emphasis>après</emphasis> le changement DDL sur le noeud maître sont enregistrées
+dans une file d'attente, en attente d'être traitées par l'abonné.
+Vous ne courrez ainsi pas le risque que des updates non centralisés par DDL
+
+You don't run the
 risk of there being updates made that depended on the DDL changes in
 order to be correct.</para></listitem>
 
-<listitem><para> When you run <xref linkend="stmtddlscript"/>, this
-causes the &lslonik; to request, <emphasis>for each table in the
-specified set</emphasis>, an exclusive table lock.</para>
+<listitem><para> Lorsque vous exécutez <xref linkend="stmtddlscript"/>, cela
+conduit &lslonik; à poser, <emphasis>pour chaque table faisant partie du jeu de réplication</emphasis>,
+un verrou exclusif table.</para>
 
-<para> It starts by requesting the lock, altering the table to remove
-&slony1; triggers, and restoring any triggers that had been hidden:
+<para> Cela commence par la pose du lock, l'altération de la table pour supprimer les
+&slony1; triggers, et la restauration de tous les triggers qui ont étés cachés
 
 <screen>
 BEGIN;
@@ -91,9 +90,9 @@
 --tab_id is _slony_schema.sl_table.tab_id
 </screen></para>
 
-<para> After the script executes, each table is
-<quote>restored</quote> to add back either the trigger that collects
-updates at the origin or that denies updates on subscribers:
+<para> Après l'exécution du script, chaque table est
+<quote>restorée</quote> dans le but d'ajouter en fin soit le trigger qui collecte
+les mises à jour sur le noeud origine soit celui qui rejette les mises à jour sur l'abonné.
 
 <screen>
 SELECT _oxrsorg.altertableforreplication(tab_id);
@@ -101,131 +100,123 @@
 COMMIT;
 </screen></para>
 
-<para>Note that this is what allows &slony1; to take notice of
-alterations to tables: <emphasis>before</emphasis>
-that <command>SYNC</command>, &slony1; has been replicating tuples
-based on the <emphasis>old</emphasis>
-schema; <emphasis>after</emphasis> the <command>DDL_SCRIPT</command>,
-tuples are being replicated based on the <emphasis>new</emphasis>
-schema. </para>
+<para>Notez que c'est ce qui permet à &slony1; de prendre connaissance de
+l'altération de tables: <emphasis>avant</emphasis>
+ce <command>SYNC</command>, &slony1; réplique des tuples suivant le
+ <emphasis>vieux</emphasis>
+schéma; <emphasis>après</emphasis> le script <command>DDL_SCRIPT</command>,
+les tuples sont répliqués suivant le <emphasis>nouveau</emphasis>
+schéma. </para>
 
-<para> On a system which is busily taking updates, it may be
-troublesome to <quote>get in edgewise</quote> to actually successfully
-engage all the required locks.  The locks may run into deadlocks.
-This points to two ways to address this:
+<para> Sur un système réalisant de nombreuses mises à jour, il peut être
+difficile <quote>d'obtenir</quote> tous les verrous nécéssaires.
+ Les verrous peuvent conduire à des deadlocks.
+Vous pouvez régler le problème de 2 manières différentes :
 </para></listitem>
 
-<listitem><para> You may be able to <link linkend="definesets"> define
-replication sets </link> that consist of smaller sets of tables so
-that fewer locks need to be taken in order for the DDL script to make
-it into place.</para>
+<listitem><para> Vous devez envisager de <link linkend="definesets"> définir des jeux de réplication </link>
+ représentant un plus petit nombre de tables
+de manière à ce que moins de verrous soient posés et permettent au script DDL d'être joué.
+.</para>
 
-<para> If a particular DDL script only affects one table, it should be
-unnecessary to lock <emphasis>all</emphasis> application
-tables.</para>
+<para> Si un script DDL affecte une seule table, il ne devrait pas
+être nécessaire de verrouiller <emphasis>toutes</emphasis> les tables de
+l'application.</para>
 
-<note><para> Actually, as of version 1.1.5 and later, this
-is <emphasis>NOT TRUE.</emphasis> The danger of someone making DDL
-changes that crosses replication sets seems sufficiently palpable that
-&lslon; has been changed to lock <emphasis>ALL</emphasis> replicated
-tables, whether they are in the specified replication set or
-not. </para></note></listitem>
+<note><para> Véritablement, à partir de la version 1.1.5 ou plus, ce
+n'est <emphasis>plus vrai.</emphasis> Le danger que quelqu'un opère des changements
+DDL interférant avec le jeux de réplication est suffisamment évident pour que 
+&lslon; verrouille  <emphasis>toutes</emphasis> les tables
+répliquées, qu'elles soient ou pas dans le jeu de réplication
+. </para></note></listitem>
 
-<listitem><para> You may need to take a brief application outage in
-order to ensure that your applications are not demanding locks that
-will conflict with the ones you need to take in order to update the
-database schema.</para></listitem>
+<listitem><para> Vous pouvez avoir besoin de faire un arrêt de votre système
+pour vous assurer que vos applications ne demandent pas des verrous
+qui rentreraient en conflit avec ceux dont vous auriez besoin pour faire les changements de schéma de base.
+.</para></listitem>
 
-<listitem><para> In &slony1; versions 1.0 thru 1.1.5, the script is
-processed as a single query request, which can cause problems if you
-are making complex changes.  Starting in version 1.2, the script is
-properly parsed into individual SQL statements, and each statement is
-submitted separately, which is a preferable handling of this.  </para>
+<listitem><para> Dans les versions 1.0 à 1.1.5 de &slony1; le script s'exécute
+comme une simple requête, ce qui peut poser problème si vous réaliser des modifications
+complexes. A partir de la version 1.2, le script est découpé en traitements SQL individuels,
+et chaque requête est soumise séparemment, ce qui est préférable.</para>
 
-<para> The trouble with one query processing a <quote>compound
-statement</quote> is that the SQL parser does its planning for that
-entire set of queries based on the state of the database at the
-<emphasis>beginning</emphasis> of the query.</para>   
+<para> Le problème avec une requête traitant une <quote>requête imbriquée</quote> est que le parser SQL
+réalise son plan d'exécution pour le jeu entier de requête <emphasis>avant même</emphasis>
+ l'exécution de la requête.</para>   
 
-<para> This causes no particular trouble if those statements are
-independent of one another, such as if you have two statements to add
-two columns to a table.</para>
+<para> Cela ne pose pas de problème particulier si les requêtes
+sont indépendantes les unes des autres, tel que 2 requêtes d'ajout de 2 colonnes
+à une table.</para>
 
 <para> <command> alter table t1 add column c1 integer; alter table t1 add
 column c2 integer; </command></para>
 
-<para> Trouble arises if a subsequent query needs to reference an
-earlier one.  Consider the following DDL statements...  </para>
+<para> Par contre, les problèmes se rencontrent si vous devez référencer une requête précédente.
+Considérer la requête DDL suivante ...</para>
 
 <para><command> alter table t1 add column c1 integer; create sequence s1;
 update t1 set c1=nextval('s1'); alter table t1 alter column c1 set not
 null; alter table t1 add primary key(c1); </command></para>
 
-<para> Up until &slony1; version 1.2, this query would <emphasis> fail
-</emphasis>.  It would specifically fail upon reaching the
-<command>UPDATE</command> statement, complaining that column
-<envar>c1</envar> doesn't exist.  This happens because
-<emphasis>all</emphasis> of those queries are parsed based on the
-state of things immediately before the query.  So, the
-<command>UPDATE</command> is evaluated based on a table definition
-<emphasis>before</emphasis> the new column was added. Oops. </para>
+<para> Jusqu'à la version 1.2 de  &slony1; cette requête aurait <emphasis> échouée
+</emphasis>, lors de l'atteinte de la conditon
+<command>UPDATE</command> , indiquant l'inexistence de la colonne
+<envar>c1</envar>.  Cela est dû au fait que <emphasis>toutes</emphasis> ces requêtes sont découpées
+ et analysées avant même l'exécution de l'une d'entre elles.
+Ainsi, l'<command>UPDATE</command> est évalué sur une table avant que la colonne n'ai été ajoutée.
+ Oops. </para>
 
-<para>If you are running one of the earlier versions, the workaround
-is that you invoke a separate <xref linkend="stmtddlscript"/> request
-with a separate script, cutting off to a new script each time a
-statement refers to something created in previous statements. </para>
+<para>Si vous avez des versions antérieures, vous pouvez contourner cela en
+invoquant une requête séparée <xref linkend="stmtddlscript"/> dans un script distinct
+, en générant un nouveau script pour chaque requête qui  référence un objet créé dans une requête précédente.
+. </para>
 
-<para> In &slony1; version 1.2, there is a state machine that pulls
-apart the DDL script into individual statements.  Each statement is
-submitted as a separate <function>PQexec()</function> request, with
-the result that this is no longer an issue. </para>
+<para> Dans le version 1.2 de &slony1; , il y a un mécanisme qui sépare
+le script DDL en requêtes individuelles.  Chaque requête est soumise par une requête
+<function>PQexec()</function> séparée, ce qui ne pose plus de problème. </para>
 </listitem>
 
 </itemizedlist>
 
-<para>Unfortunately, this nonetheless implies that the use of the DDL
-facility is somewhat fragile and fairly dangerous.  Making DDL changes
-must not be done in a sloppy or cavalier manner.  If your applications
-do not have fairly stable SQL schemas, then using &slony1; for
-replication is likely to be fraught with trouble and frustration.  See
-the section on <link linkend="locking"> locking issues </link> for
-more discussion of related issues.</para>
+<para>Malheureusement, cela conduit à une vulnérabilité du script DDL, suivant la manière
+dont les changements DDL sont écrits.
+Si vos applications n'ont pas de schémas SQL suffisamment stables,
+l'utilisation de &slony1; pour le mécanisme de réplication peut ne
+pas être adaptée. Voir la section <link linkend="locking"> questions de verrous </link>
+pour plus de discussion sur le sujet.</para>
 
-<para>There is an article on how to manage &slony1; schema changes
-here: <ulink url="http://www.varlena.com/varlena/GeneralBits/88.php">
+
+<para>Voici un article sur l'administration des changements de schémas avec &slony1;:
+ <ulink url="http://www.varlena.com/varlena/GeneralBits/88.php">
 Varlena General Bits</ulink></para>
 
-<sect2><title> Changes that you might <emphasis>not</emphasis> want to
-process using <command>EXECUTE SCRIPT</command></title>
+<sect2><title> Changements <emphasis>hors</emphasis> utilisation de
+ <command>EXECUTE SCRIPT</command></title>
 
-<para> While it is <emphasis> vitally necessary </emphasis> to use
-<command>EXECUTE SCRIPT</command> to propagate DDL modifications to
-tables that are being replicated, there are several sorts of changes
-that you might wish to handle some other way:
 
+<para> Alors qu'il est <emphasis> vital </emphasis> d'utiliser
+<command>EXECUTE SCRIPT</command> pour propager des modifications DDL sur des tables répliquées,
+il y a plusieurs autres modifications que vous pouvez vouloir réaliser d'une autre façon :
+
 <itemizedlist>
 
-<listitem><para> There are various sorts of objects that don't have
-triggers that &slony1; <emphasis>doesn't</emphasis> replicate, such as
-stored functions, and it is quite likely to cause you grief if you
-propagate updates to them associated with a replication set where
-<command>EXECUTE SCRIPT</command> will lock a whole lot of tables that
-didn't really need to be locked.</para>
+<listitem><para> Il y a plusieurs types d'objets n'ayant pas de trigger que
+&slony1; <emphasis>ne</emphasis> peut répliquer, tels que les fonctions
+stockées. Et il est assez probable que cela vous posera problème de propager ces mises à jour
+en association avec un jeu de réplication où <command>EXECUTE SCRIPT</command> 
+va vérouiller tout un jeu de tables qui n'ont pas réellement besoin de l'être.
 
-<para> If you are propagating a stored procedure that
-<emphasis>isn't</emphasis> used all the time (such that you'd care if
-it was briefly out of sync between nodes), then you could simply
-submit it to each node using <application>psql</application>, making
-no special use of &slony1;.</para>
+<para> Si vous propagez une procédure stockée qui n'est pas utilisée tout le temps
+(de telle sorte que vous acceptiez une petite desynchronisation entre les noeuds), alors vous pouvez
+simplement la soumettre à chaque noeud par l'intermédiare d'une commande <application>psql</application>,
+ne faisant pas d'utilisation particulière de &slony1;
 
-<para> If it <emphasis>does</emphasis> matter that the object be
-propagated at the same location in the transaction stream on all the
-nodes, then you but no tables need to be locked, then you need to use
-<command>EXECUTE SCRIPT</command>, locking challenges or
-no.</para></listitem>
+<para>Si vous <emphasis>avez</emphasis> besoin d'une parfaite synchronisation sur l'ensemble des noeuds,
+a ce moment là, vous devez utiliser <command>EXECUTE SCRIPT</command>
+ pour verouiller vos travaux.</para></listitem>
 
-<listitem><para> You may want an extra index on some replicated
-node(s) in order to improve performance there.</para>
+<listitem><para> Vous pouvez avoir besoin d'index suplémentaires sur quelques
+noeuds répliqués pour accroître les performances.</para>
 
 <para> For instance, a table consisting of transactions may only need
 indices related to referential integrity on the <quote>origin</quote>
@@ -234,66 +225,73 @@
 additional indices to improve the performance of reports that run
 against replicated nodes.</para>
 
-<para> It would be unwise to add additional indices that
-<emphasis>constrain</emphasis> things on replicated nodes, as if they
-find problems, this leads to replication breaking down as the
-subscriber(s) will be unable to apply changes coming from the origin
-that violate the constraints.</para>
+<para> Il serait imprudent d'ajouter des indicateurs qui 
+<emphasis>contraindraient</emphasis> les évènements sur les noeuds répliqués,
+en cas de problème, cela conduirait la réplication à s'arrêter
+car le ou les  noeuds abonnés ne pourraient appliquer les changements provenant
+ du noeud origine violant la contrainte.</para>
 
-<para> But it's no big deal to add some performance-enhancing indices.
-You should almost certainly <emphasis>not</emphasis> use
-<command>EXECUTE SCRIPT</command> to add them; that leads to some
-replication set locking and unlocking tables, and possibly failing to
-apply the event due to some locks outstanding on objects and having to
-retry a few times before it gets the change in.  If you instead apply
-the index <quote>directly</quote> such as with
-<application>psql</application>, you can determine the time at which
-the table lock is introduced.  Adding an index to a table will require
-an exclusive lock for the time it takes to build the index; that will
-implicitly stop replication, while the index builds, but shouldn't
-cause any particular problems.  If you add an index on a table that
-takes 20 minutes to build, replication will block for 20 minutes, but
-should catch up quickly enough once the index is
-created.</para></listitem>
+<para> Cela ne pose pas de difficultes d'ajouter quelques mesures d'ameliorations de performances.
+Il ne faut pratiquement <emphasis>jamais</emphasis> utiliser
+<command>EXECUTE SCRIPT</command> dans ce cadre; cela conduit certains jeux de replication a 
+verrouiller/deverouiller des tables et potentiellement échouer à appliquer l'evenement a cause de verrous en cours
+sur les objets, puis devoir reessayer un certain nombre de fois avant de pouvoir effectuer le changement.
+.  
 
-<listitem><para> &slony1; stores the <quote>primary index</quote> name
-in <xref linkend="table.sl-table"/>, and uses that name to control what
-columns are considered the <quote>key columns</quote> when the log
-trigger is attached.  It would be plausible to drop that index and
-replace it with another primary key candidate, but changing the name
-of the primary key candidate would break things. </para> </listitem>
 
+A la place, si vous appliquer l'index <quote>directement</quote>, au travers de 
+<application>psql</application>, vous pouvez determiner le moment auquel 
+le verrou s'exerce sur la table.
+
+Ajouter un index a une table necessite un verrou exlusif pour la duree
+de creation de cet index: cela va implicitement stopper la replication, pendant la duree
+de construction de l'index, mais sans causer de problemes particuliers.
+
+
+Si vous ajoutez un index sur une table et que sa construction dure 20 minutes, la replication sera stoppee
+pendant 20 minutes, mais repartira juste apres la fin de la creation.
+.</para></listitem>
+
+<listitem><para> &slony1; stocke le nom de l'<quote>index primaire</quote> dans
+ <xref linkend="table.sl-table"/>, et utilise ce nom pour controler les colonnes considérées 
+ comme les <quote>colonnes cles"</quote> lorsque le declencheur de log est present.
+ Il pourrait etre envisageable de supprimer cet index et de le remplacer
+par une autre cle primaire potentielle, mais un changement de nom de cette cle primaire
+casserait certainement certaines choses.</para> </listitem>
+
 </itemizedlist></para></sect2>
 
-<sect2><title> Testing DDL Changes </title>
+<sect2><title> Tester les changements DDL </title>
 
-<indexterm><primary> testing DDL changes </primary></indexterm>
+<indexterm><primary> tester les changements DDL </primary></indexterm>
 
-<para> A method for testing DDL changes has been pointed out as a
-likely <quote>best practice.</quote></para>
 
-<para> You <emphasis>need</emphasis> to test DDL scripts in a
-non-destructive manner.</para>
+<para> Une methode de test des changements DDL a ete validee
+ comme <quote>bonne pratique.</quote></para>
+ 
+<para> Vous <emphasis>devez</emphasis>
+ tester les scripts DDL de facon non destructrice.</para>
 
-<para> The problem is that if nodes are, for whatever reason, at all
-out of sync, replication is likely to fall over, and this takes place
-at what is quite likely one of the most inconvenient times, namely the
-moment when you wanted it to <emphasis> work. </emphasis></para>
 
-<para> You may indeed check to see if schema scripts work well or
-badly, by running them by hand, against each node, adding <command>
-BEGIN; </command> at the beginning, and <command> ROLLBACK; </command>
-at the end, so that the would-be changes roll back.</para>
+<para> Si les noeuds sont, pour une raison ou une autre, totalement desynchonisés,
+la replication va tres certainement echouer, et cela a lieu la plupart du temps 
+au plus mauvais moment: celui ou vous vouliez que cela
+ <emphasis> fonctionne. </emphasis></para>
 
-<para> If this script works OK on all of the nodes, that suggests that
-it should work fine everywhere if executed via &lslonik;.  If problems
-are encountered on some nodes, that will hopefully allow you to fix
-the state of affairs on those nodes so that the script
-<emphasis>will</emphasis> run without error.
 
-<warning> <para> If the SQL script contains a <command> COMMIT;
-</command> somewhere before the <command> ROLLBACK; </command>, that
-may allow changes to go in unexpectedly.  </para>
+<para> Vous pouvez verifier si vos scripts DDL fonctionnent bien ou pas en les executant manuellement
+en ajoutant <command>BEGIN; </command>  au debut et <command> ROLLBACK; </command> a la fin.
+ De cette facon, les changements effectuent un retour arriere.</para>
+
+<para> Si le script s'effectue correctement sur tous les noeuds, cela semble dire 
+qu'il devrait s'executer également correctement via &lslonik;.
+Si des problèmes apparaissent sur certains noeuds, cela devrait vous permettre
+de remettre ces machines a niveau, de facon a ce que le script
+ <emphasis> s'exécute</emphasis>  sans erreur.
+
+Attention <para> Si le script contient un  <command> COMMIT;
+</command> n'importe ou avant le <command> ROLLBACK; </command>, cela va 
+effectuer des changements auxquels vous ne vous attendiez pas.  </para>
 </warning></para>
 </sect2>
 </sect1>