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

[svncommit at kryskool.org]

Auteur: daamien
Date: 2008-06-11 21:24:03 +0200 (mer, 11 jun 2008)
Nouvelle Révision: 1073

Modification:
   traduc/trunk/slony/locking.xml
Log:
1ere traduction, à relire 



Modified: traduc/trunk/slony/locking.xml
===================================================================
--- traduc/trunk/slony/locking.xml	2008-06-11 09:04:23 UTC (rev 1072)
+++ traduc/trunk/slony/locking.xml	2008-06-11 19:24:03 UTC (rev 1073)
@@ -4,188 +4,194 @@
      par      $Author$
      révision $Revision$ -->
 
-<sect1 id="locking"> <title>Locking Issues</title>
+<sect1 id="locking"> <title>Problèmes de verrous</title>
 
-<indexterm><primary>locking issues</primary></indexterm>
+<indexterm><primary>problèmes de verrous</primary></indexterm>
 
-<para> One of the usual merits the use, by &postgres;, of
-Multi-Version Concurrency Control (<acronym>MVCC</acronym>) is that
-this eliminates a whole host of reasons to need to lock database
-objects.  On some other database systems, you need to acquire a table
-lock in order to insert data into the table; that can
-<emphasis>severely</emphasis> hinder performance.  On other systems,
-read locks can impede writes; with <acronym>MVCC</acronym>, &postgres;
-eliminates that whole class of locks in that <quote>old reads</quote>
-can access <quote>old tuples.</quote> Most of the time, this allows
-the gentle user of &postgres; to not need to worry very much about
-locks. </para>
+<para> L'un des avantages de &postgres; et de son contrôleur de concurrence de 
+  multiple version ( "Multi-Version Concurrency Control", nommé 
+  <acronym>MVCC</acronym> par la suite ) est qu'il élimine de nombreuses
+  raison de verrouiller les objets de base de données. Sur certains 
+  systèmes de gestion de bases de données, vous devez verrouiller une table
+  lorsque vous souhaitez insérer des données dans celle-ci; cela peut entraver
+  <emphasis>sévèrement</emphasis> les performances. Sur d'autres systèmes,
+  les lectures bloque les écritures concurrentes. Avec <acronym>MVCC</acronym>, &postgres;
+  supprime tous une catégorie de verrous, dans le sens ou les 
+  <quote>vieilles lectures</quote> peuvent accéder aux <quote>anciens tuples</quote>.
+  La pluspart du temps, cela évite aux aimables utilisateurs de 
+  &postgres; de trop se préoccuper des verrous.</para>
 
-<para> Unfortunately, there are several sorts of &slony1; events that
-do require exclusive locks on &postgres; tables, with the result that
-modifying &slony1; configuration can bring back some of those
-<quote>locking irritations.</quote>  In particular:</para>
+<para> Malheureusement, il existe plusieurs sortes d'événements &slony1; 
+  qui nécessite des verrous exclusifs sur les tables  &postgres;,
+  ce qui entraine que la modification de la configuration &slony1;,
+  peut provoquer des <quote>verrous génants</quote>.
+  En particulier:</para>
 
 <itemizedlist>
 
 <listitem><para><link linkend="stmtsetaddtable"> <command>set add
 table</command> </link></para>
 
-<para> A momentary exclusive table lock must be acquired on the
-<quote>origin</quote> node in order to add the trigger that collects
-updates for that table.  It only needs to be acquired long enough to
-establish the new trigger.</para>
+<para> Un verrou exclusif et momentané doit être posé sur
+  une table du noeud <quote>origine</quote> afin de d'ajouter le trigger
+  qui collecte les mises à jour de cette table. I doit simplement être
+  posé assez longtemps pour établir le nouveau trigger.</para>
 </listitem>
 
 <listitem><para><link linkend="stmtmoveset"> <command> move
 set</command> </link></para>
 
-<para> When a set origin is shifted from one node to another,
-exclusive locks must be acquired on each replicated table on both the
-old origin and the new origin in order to change the triggers on the
-tables.  </para></listitem>
+<para> Lorsqu'un ensemble sur un noeud origine est déplacé vers un autre noeud,
+  des verrous exclusifs sont posé sur chaque table répliquée à la fois sur 
+  l'ancien et le nouveau noeud origine afin de modifier les triggers sur ces tables.
+  </para></listitem>
 
 <listitem><para><link linkend="stmtlockset"> <command> lock set
 </command> </link> </para>
 
-<para> This operation expressly requests locks on each of the tables in a
-given replication set on the origin node.</para>
+<para> Cette opération demande explicitement des verrous sur chaque
+  table dans un ensemble de réplication donné sur le noeud origine.
+  </para>
 </listitem>
 
 <listitem><para><link linkend="stmtddlscript"> <command>execute
 script</command> </link> </para>
 
-<para> This operation runs a set of SQL queries; in order for it to
-work, the &slony1; triggers must be removed, followed by the query
-(which potentially updates the data) running, followed by triggers
-being restored.  The operation therefore must acquire table locks on
-all replicated tables on each node. </para>
+<para> Cette opération lance un ensemble de requête SQL;
+  pour qu'elle fonctionne, les triggers  &slony1; doivent être
+  retirés, ensuite les requêtes sont exécutées ( ce qui peut modifier
+  les données ), enfin les triggers sont restaurés. Pour cela, 
+  l'opération doit acquérir des verrous sur toutes les tables de
+  chaque noeuds. </para>
 </listitem>
 
-<listitem><para> During the <command>SUBSCRIBE_SET</command> event on
-a new subscriber </para>
+<listitem><para> Pendant un événement <command>SUBSCRIBE_SET</command> sur 
+    un nouvel abonné </para>
 
-<para> In a sense, this is the least provocative scenario, since,
-before the replication set has been populated, it is pretty reasonable
-to say that the node is <quote>unusable</quote> and that &slony1;
-could reasonably demand exclusive access to the node. </para>
+<para> Dans un sens, c'est le scénario le moins perturbant, car
+  avant que l'ensemble de réplication soit complet, on peut
+  penser que le noeud <quote>inutilisable</quote> et que 
+   &slony1; peut raisonnablement demander l'accès exclusif sur le noeud.
+    </para>
 
-<para> A change in version 1.2 is that an express <command>LOCK
-TABLE</command> SQL request is submitted in the loop that validates
-that all of the tables are there.  This means that
-<emphasis>all</emphasis> tables in the replication set will be locked
-via an exclusive lock for the entire duration of the process of
-subscription.  By locking the tables early, this means that the
-subscription cannot fail after copying some of the data due to some
-other process having held on to a table. </para>
+<para> Un changement dans la version 1.2 provoque une requête SQL <command>LOCK
+TABLE</command> explicite qui est placé dans la boucle qui valide que toutes les
+tables sont présentes. Cela signifie que 
+<emphasis>toutes</emphasis> les tables de l'ensemble de réplication
+sont verrouiller avec un verrou exclusif pour la durée totale du processus
+de souscription. En verrouillant les tables très tôt, on s'assure que
+le souscription n'échouera pas à cause d'un autre processus ayant un 
+verrou sur une table.
+</para>
 
-<para> In any case, note that this one began with the wording
-<quote>on a new subscriber.</quote> The locks are applied <emphasis>on
-the new subscriber.</emphasis> They are <emphasis>not</emphasis>
-applied on the provider or on the origin. </para>
+<para> Dans tous les cas, notez que ce script opère 
+<quote>sur un nouveau noeud abonné</quote>. Les verrous sont posés
+<quote>sur un nouveau noeud abonné</quote>. Ils s'appliquent <emphasis>pas</emphasis>  
+au noeud fournisseur ou au noeud origine. </para>
 
 </listitem>
 
-<listitem><para> <application>pg_autovacuum</application> may not be
-part of &slony1;, but those that run it find that it wakes up roughly
-once per minute and may, at any time, start vacuuming a table, thereby
-taking out a <envar>ShareUpdateExclusiveLock</envar> lock.  This may
-block the other events for an unpredictable period of time.</para>
+<listitem><para> <application>pg_autovacuum</application> ne fait pas partie
+de &slony1;, mais il se réveille une fois par minute et peut, à tout moment,
+se lancer dans le nettoyage d'une table, et ainsi poser un verrou
+<envar>ShareUpdateExclusiveLock</envar>. Ceci peut bloquer les autres événements
+pendant un période imprévisible.</para>
 </listitem>
 
 </itemizedlist>
 
-<para> Each of these actions requires, at some point, modifying each
-of the tables in the affected replication set, which requires
-acquiring an exclusive lock on the table.  Some users that have tried
-running these operations on &slony1; nodes that were actively
-servicing applications have experienced difficulties with deadlocks
-and/or with the operations hanging up. </para>
+<para> Chacune de ces actions nécessite, à un certain de point, de 
+  modifier chaque table de l'ensemble de réplication, ce qui implique
+  l'acquisition d'un verrou exclusif sur les tables. Certains utilisateurs
+  ont tenté d'effectuer ces opérations sur des noeuds qui étaient activement
+  sollicités par la couche applicative; ils ont rencontré des problèmes
+  d'inter-blocages ("deadlocks") et/ou des arrêts de réplication. </para>
 
-<para> The obvious question: <quote>What to do about such
-deadlocks?</quote> </para>
+<para> La question évident est : <quote>Que faire pour éviter ces inter-blocages ?</quote> </para>
 
-<para> Several possibilities admit themselves: </para>
+<para> Plusieurs possibilités sont envisageables : </para>
 
 <itemizedlist>
 
-<listitem><para> Announce an application outage to avoid deadlocks
-</para>
+<listitem><para> Annoncer une coupure de service pour éviter les inter-blocages 
+    </para>
 
-<para> If you can temporarily block applications from using the
-database, that will provide a window of time during which there is
-nothing running against the database other than administrative
-processes under your control. </para> </listitem>
+<para>Si vous pouvez empêcher temporairement les applications 
+  d'accéder à la base de données, cela vous offrira une fenêtre de temps
+  pendant laquelle aucune opération ne sera effectuée sur la base de données,
+  à l'exception des processus d'administration que vous controllerez.
+  </para> </listitem>
 
-<listitem><para> Try the operation, hoping for things to work </para> 
+<listitem><para> Tenter l'operation, en espérant que cela fonctionne </para> 
 
-<para> Since nothing prevents applications from leaving access locks
-in your way, you may find yourself deadlocked.  But if the number of
-remaining locks are small, you may be able to negotiate with users to
-<quote>get in edgewise.</quote> </para>
+<para> Puisque rien n'empêche les application de laisser de verrous sur
+  votre chemin, vous pourrez vous retrouver dans une situation de blocage.
+  Mais si le nombre de verrous restant est faible, vous pouvez négocier 
+  avec les utilisateurs pour <quote>avoir la priorité</quote>. </para>
 </listitem>
 
-<listitem><para> Use pgpool </para> 
+<listitem><para> Utiliser pgpool </para> 
 
-<para> If you can use this or some similar <quote>connection
-broker</quote>, you may be able to tell the connection manager to stop
-using the database for a little while, thereby letting it
-<quote>block</quote> the applications for you.  What would be ideal
-would be for the connection manager to hold up user queries for a
-little while so that the brief database outage looks, to them, like a
-period where things were running slowly.  </para></listitem>
+<para> Si vous pouvez utiliser pgpool ou un <quote>gestionnaire de connexion
+</quote> similaire, vous pouvez configurer le programme pour
+qu'il n'utilise plus la base pendant un petit moment, et ainsi 
+le laisser <quote>bloquer</quote> les applications pour vous.
+L'idéal étant que le gestionnaire de connexion retiennent les requêtes
+assez longtemps pour que la coupure de service apparaisse comme un
+simple ralentissement. </para></listitem>
 
-<listitem><para> Rapid Outage Management </para> 
+<listitem><para> Gestion rapide de coupure de service </para> 
 
-<para> The following procedure may minimize the period of the outage:
+<para> La procédure suivante minimisera le temps de coupure de service:
 
 <itemizedlist>
 
-<listitem><para> Modify <filename>pg_hba.conf</filename> so that only
-the <link linkend="slonyuser"> <command>slony</command> user </link>
-will have access to the database. </para> </listitem>
+<listitem><para> Modifier <filename>pg_hba.conf</filename> afin que seul
+<link linkend="slonyuser">l'utilisateur <command>slony</command> user </link>
+ait accès à la base de données.</para> </listitem>
 
-<listitem><para> Issue a <command>kill -SIGHUP</command> to the
-&postgres; postmaster.</para>
+<listitem><para> Envoyer un  <command>kill -SIGHUP</command> au postmaster de
+&postgres;.</para>
 
-<para> This will not kill off existing possibly-long-running queries,
-but will prevent new ones from coming in.  There is an application
-impact in that incoming queries will be rejected until the end of the
-process.
+<para> Ceci ne tuera pas les longues requêtes qui pourraient être en cours d'exécution
+  mais cela empêchera les nouvelles d'entrer. Cela a un impact sur l'application
+  puisque les requêtes entrantes seront rejetées jusqu'à la fin de la procédure.
 </para>
 </listitem>
 
-<listitem><para> If <quote>all looks good,</quote> then it should be
-safe to proceed with the &slony1; operation. </para> </listitem>
+<listitem><para> Si <quote>tout va bien</quote>, alors on peut
+    effectuer sans danger l'opération &slony1;. </para> </listitem>
 
-<listitem><para> If some old query is lingering around, you may need
-to <command>kill -SIGQUIT</command> one of the &postgres; processes.
-This will restart the backend and kill off any lingering queries.  You
-probably need to restart the <xref linkend="slon"/> processes that
-attach to the node. </para> 
+<listitem><para> si une requête est toujours en cours, vous devrez peut-être
+    effectuer un  <command>kill -SIGQUIT</command> sur un des processus
+    &postgres;. Cela relancera le moteur et tuera toutes les requêtes 
+    en attente. Vous devrez probablement relancer les processus  
+    <xref linkend="slon"/> qui sont attachés à ce noeud. </para> 
 
-<para> At that point, it will be safe to proceed with the &slony1;
-operation; there will be no competing processes.</para></listitem>
+<para> A ce point, l'opération &slony1; peut être effectuée sans danger;
+  Il n'y aura aucun autre processus concurrent.
+  </para></listitem>
 
-<listitem><para> Reset <filename>pg_hba.conf</filename> to allow other
-users in, and <command>kill -SIGHUP</command> the postmaster to make
-it reload the security configuration. </para> </listitem>
+<listitem><para> Recharger l'ancienne version du fichier <filename>pg_hba.conf</filename>
+    pour autoriser les utilisateurs, et envoyer un <command>kill -SIGHUP</command>
+    au processus postmaster pour qu'il recharge la configuration de sécurité. </para> </listitem>
 </itemizedlist>
 
 </para>
 </listitem>
 
-<listitem><para> The section  &rddlchanges; suggests some additional
-techniques that may be useful, such as moving tables between
-replication sets in such a way that you minimize the set of tables
-that need to be locked. </para></listitem>
+<listitem><para> La section  &rddlchanges; suggère des techniques
+    supplémentaires qui peuvent être utiles, telles que le déplacement
+    des tables vers d'autres ensemble de réplication afin de minimiser
+    le nombre de tables qu'il faut verrouiller.</para></listitem>
 
 </itemizedlist>
 
-<para> Regrettably, there is no perfect answer to this.  If it is
-<emphasis>necessary</emphasis> to submit a <xref
-linkend="stmtmoveset"/> request, then it is presumably
-<emphasis>necessary</emphasis> to accept the brief application outage.
-As &slony1;/<link linkend="pgpool"> pgpool </link> linkages improve,
-that may become a better way to handle this.</para>
-
-</sect1>
+<para> Malheureusement, il n'y a pas de solution miracle. 
+  Si il est <emphasis>nécessaire</emphasis> de soumettre une requête
+  <xref linkend="stmtmoveset"/>, alors il est probablement
+<emphasis>nécessaire</emphasis> d'accepter une courte coupure de service.
+Au fur et à mesure que les relations entre &slony1; et <link linkend="pgpool"> pgpool </link>,
+s'améliore, ce couple semble être la meilleure méthode pour éviter les inter-blocages. 
+</para>
+</sect1>
\ No newline at end of file