[Trad] [svn:pgfr] r1154 - traduc/trunk/postgresql

[admin at listes.postgresql.fr]

Author: sas
Date: 2008-09-22 19:04:00 +0200 (Mon, 22 Sep 2008)
New Revision: 1154

Modified:
   traduc/trunk/postgresql/high-availability.xml
Log:
On remet ?\195?\167a ?


Modified: traduc/trunk/postgresql/high-availability.xml
===================================================================
--- traduc/trunk/postgresql/high-availability.xml	2008-09-22 14:01:13 UTC (rev 1153)
+++ traduc/trunk/postgresql/high-availability.xml	2008-09-22 17:04:00 UTC (rev 1154)
@@ -107,15 +107,14 @@
     rapide sans perte de données.
    </para>
 
-<!-- SAS::ICI -->
    <para>
     La fonctionnalité de matériel partagé est commune aux périphériques de
     stockage en réseau. Il est également possible d'utiliser un système de
     fichiers réseau bien qu'il faille porter une grande attention au système de
     fichiers pour s'assurer qu'il a un comportement <acronym>POSIX</acronym>
-    complet (voir <xref linkend="creating-cluster-nfs"/>). Une
-    limitation significative de cette méthode est que si les disques ont un
-    problème ou sont corrompus, les serveurs primaire et en attente sont tous
+    complet (voir <xref linkend="creating-cluster-nfs"/>). Cette méthode
+    comporte une limitation significative&nbsp;: si les disques ont un
+    problème ou sont corrompus, le serveur primaire et le serveur en attente sont tous
     les deux non fonctionnels. Un autre problème est que le serveur en attente
     ne devra jamais accéder au stockage partagé tant que le serveur principal
     est en cours d'exécution.
@@ -133,7 +132,7 @@
     avec une réplication du système de fichiers, où toutes les modifications
     d'un système de fichiers sont renvoyées sur un système de fichiers situé
     sur un autre ordinateur. La seule restriction est que ce miroir doit être
-    construit d'une façon qui assure le fait que le serveur en attente a une
+    construit de telle sorte que le serveur en attente dispose d'une
     version cohérente du système de fichiers &mdash; spécifiquement, les
     écritures sur le serveur en attente doivent être réalisées dans le même
     ordre que celles sur le maître. <productname>DRBD</productname> est une
@@ -164,8 +163,8 @@
     échoue, le serveur
     <foreignphrase>warm standby</foreignphrase> contient pratiquement toutes
     les données du serveur principal et peut rapidement devenir le nouveau
-    serveur maître. Ceci est asynchrone et peut seulement se faire pour le
-    serveur de bases entier.
+    serveur maître. Ceci est asynchrone et ne peut se faire que pour le
+    serveur de bases complet.
    </para>
   </listitem>
  </varlistentry>
@@ -186,7 +185,7 @@
    <para>
     <productname>Slony-I</productname> est un exemple de ce type de
     réplication, avec une granularité par
-    table et un support des esclaves multiple. Comme il met à jour le serveur
+    table et un support des esclaves multiples. Comme il met à jour le serveur
     esclave de façon asynchrone (par lots), il existe une possibilité de perte
     de données pendant un <foreignphrase>failover</foreignphrase>.
    </para>
@@ -194,7 +193,7 @@
  </varlistentry>
 
  <varlistentry>
-  <term><foreignphrase>Middleware</foreignphrase> de réplication basés sur les
+  <term><foreignphrase>Middleware</foreignphrase> de réplication basé sur les
     instructions</term>
   <listitem>
 
@@ -203,31 +202,32 @@
     sur les instructions, un programme intercepte chaque requête SQL et
     l'envoie à un ou tous les serveurs. Chaque serveur opère indépendamment.
     Les requêtes en lecture/écriture sont envoyées à tous les serveurs alors
-    que les requêtes en lecture seule peuvent seulement être envoyées à un seul
-    serveur permettant la distribution du vrai travail.
+    que les requêtes en lecture seule ne peuvent être envoyées qu'à un seul
+    serveur, ce qui permet de distribuer la charge de lecture.
    </para>
 
    <para>
     Si les requêtes sont envoyées sans modification, les fonctions comme
     <function>random()</function>, <function>CURRENT_TIMESTAMP</function> ainsi
-    que les séquences auront des valeurs différentes sur des serveurs
-    différents. Ceci est dû au fait que chaque serveur opère indépendamment
-    et que les requêtes SQL sont envoyées à tous (et non pas les données
-    modifiées). Si ceci est inacceptable, soit le
-    <foreignphrase>middleware</foreignphrase> soit l'application doivent
-    demander ces valeurs à partir d'un seul serveur, puis les utiliser dans
-    des requêtes d'écriture. De plus, une attention doit être portée à ce que
-    toutes les transactions soient validées soit annulées sur tous les serveurs
-    par exemple en utilisant la validation en deux phases (<xref
+    que les séquences ont des valeurs différentes sur les différents serveurs.
+    Cela parce que chaque serveur opère indépendamment alors que
+    les requêtes SQL sont diffusées (et non les données
+    modifiées). Si cette solution est inacceptable, le
+    <foreignphrase>middleware</foreignphrase> ou l'application doivent
+    demander ces valeurs à un seul serveur, et les utiliser dans
+    des requêtes d'écriture. De plus, il est impératif que
+    toute transaction soit validée ou annulée sur tous les serveurs,
+    éventuellement par validation en deux phases (<xref
     linkend="sql-prepare-transaction"
     endterm="sql-prepare-transaction-title"/> et <xref
     linkend="sql-commit-prepared" endterm="sql-commit-prepared-title"/>.
     <productname>Pgpool-II</productname> et <productname>Sequoia</productname>
-    sont un exemple de ce type de réplication.
+    sont des exemples de ce type de réplication.
    </para>
   </listitem>
  </varlistentry>
 
+<!-- SAS::ICI -->
  <varlistentry>
   <term>Réplication asynchrone à plusieurs maîtres</term>
   <listitem>