high-availability.xml - Traduction, relecture cohérence et typos

postgresql/high-availability.xml

@@ -195,7 +195,7 @@ ce que les nœuds s'accordent dans un système transactionnel sérialisable.
       Pour plus d'informations sur la réplication logique, voir <xref
       linkend="logical-replication"/>. Au travers de l'interface de décodage
       logique (<xref linkend="logicaldecoding"/>), les extensions tierces
-      peuvent aussi fournir des fonctionnalitées similaires.
+      peuvent aussi fournir des fonctionnalités similaires.
      </para>
     </listitem>
   </varlistentry>
@@ -528,19 +528,19 @@ ce que les nœuds s'accordent dans un système transactionnel sérialisable.
   </variablelist>
 
   <para>
-   It should also be noted that because <productname>PostgreSQL</productname>
-   is open source and easily extended, a number of companies have
-   taken <productname>PostgreSQL</productname> and created commercial
-   closed-source solutions with unique failover, replication, and load
-   balancing capabilities.  These are not discussed here.
+   Il faut aussi noter que puisque <productname>PostgreSQL</productname>
+   est un outil libre et facilement extensible, un certain nombre de sociétés
+   se sont basées sur <productname>PostgreSQL</productname> pour créer leurs
+   solutions propriétaires avec des possibilités spécifiques de
+   <foreignphrase>failover</foreignphrase>, réplication ou répartition de charge.
+   Cela ne sera toutefois pas abordé ici.
   </para>
 
  </sect1>
 
  <sect1 id="warm-standby">
   <title>Serveurs de Standby par transfert de journaux</title>
 
-
   <para>
    L'archivage en continu peut être utilisé pour créer une configuration
    de cluster en <firstterm>haute disponibilité</firstterm> (HA) avec un ou
@@ -745,7 +745,7 @@ ce que les nœuds s'accordent dans un système transactionnel sérialisable.
 
    <para>
     Pour paramétrer le serveur de standby, restaurez la sauvegarde de base
-    effectué sur le serveur primaire (voir (see <xref
+    effectué sur le serveur primaire (voir <xref
     linkend="backup-pitr-recovery"/>). Créez un fichier
     <filename>recovery.signal</filename> dans le répertoire de données du
     cluster de standby. Positionnez <xref linkend="guc-restore-command"/> à
@@ -898,7 +898,7 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
    <sect3 id="streaming-replication-authentication">
     <title>Authentification</title>
     <para>
-     Il est très important que les privilèges d'accès pour la réplications
+     Il est très important que les privilèges d'accès pour la réplication
      soient paramétrés pour que seuls les utilisateurs de confiance puissent
      lire le flux WAL, parce qu'il est facile d'en extraire des informations
      privilégiées. Les serveurs de standby doivent s'authentifier au serveur
@@ -1001,16 +1001,17 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
    </para>
    <para>
     Au lieu d'utiliser des slots de réplication, il est possible d'empêcher la
-    suppression des anciens journaux de transations en utilisant
+    suppression des anciens journaux de transactions en utilisant
     <xref linkend="guc-wal-keep-segments"/>, ou en les stockant dans un
     répertoire d'archive en utilisant <xref linkend="guc-archive-command"/>.
     Cependant, ces méthodes ont souvent pour résultat le stockage de plus de
     journaux de transactions que nécessaire, alors que les slots de réplication
-    ne conservent que le nombre nécessaire de journaux de transactions. On the
-    other hand, replication slots can retain so many WAL segments that they
-    fill up the space allocated for <literal>pg_wal</literal>; <xref
-    linkend="guc-max-slot-wal-keep-size"/> limits the size of WAL files
-    retained by replication slots.
+    ne conservent que le nombre nécessaire de journaux de transactions. D'un
+    autre côté, les slots de réplication peuvent retenir tellement de journaux
+    de transactions qu'ils rempliraient l'espace disque alloué à
+    <literal>pg_wal</literal>; <xref linkend="guc-max-slot-wal-keep-size"/>
+    limitera la taille des journaux de transactions à retenir par les slots de
+    réplication.
    </para>
    <para>
     De la même manière, <xref linkend="guc-hot-standby-feedback"/>
@@ -1019,7 +1020,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     premier paramètre n'offre aucune protection durant la période pendant
     laquelle le serveur de standby n'est pas connecté, et le second nécessite
     souvent d'être positionné à une grande valeur pour fournir une protection
-    adéquate.  Les slots de réplication surmontent ces désavantages.
+    adéquate. Les slots de réplication surmontent ces désavantages.
    </para>
    <sect3 id="streaming-replication-slots-manipulation">
     <title>Requêter et manipuler des slots de réplication</title>
@@ -1071,10 +1072,10 @@ primary_slot_name = 'node_a_slot'
    </indexterm>
 
    <para>
-    La fonctionnalité de la réplication en cascade permet à un serveur
-    standard d'accepter les connexions de réplication et d'envoyer un flux
+    La fonctionnalité de réplication en cascade permet à un serveur
+    standby d'accepter les connexions de réplication et d'envoyer un flux
     d'enregistrements de journaux de transactions à d'autres secondaires,
-    agissant ainsi comme un relai. C'est généralement utilisé pour réduire
+    agissant ainsi comme un relais. C'est généralement utilisé pour réduire
     le nombre de connexions directes au primaire et minimise ainsi l'utilisation
     de bande passante entre sites distants.
    </para>
@@ -1110,7 +1111,7 @@ primary_slot_name = 'node_a_slot'
 
    <para>
     Les messages en retour des serveurs Hot Standby se propagent vers les
-    serveurs upstream, quelque soit la configuration de la réplication en
+    serveurs upstream, quelle que soit la configuration de la réplication en
     cascade.
    </para>
 
@@ -1285,13 +1286,13 @@ primary_slot_name = 'node_a_slot'
 
    <para>
     La méthode <literal>FIRST</literal> définit une réplication synchrone 
-    priorisée&nbsp;: elle temporise la validation de la transaction 
-    jusqu'à que les enregistrements WAL soient répliqués en 
+    priorisée&nbsp;: elle temporise la validation de la transaction
+    jusqu'à ce que les enregistrements WAL soient répliqués en
     fonction de la priorité définie des serveurs standbys dans une liste
     ordonnée.
-    Le serveur standby dont le nom apparait en premier sur la liste est
+    Le serveur standby dont le nom apparaît en premier sur la liste est
     prioritaire et est celui qui est considéré comme synchrone.
-    Les serveurs standbys suivants sont considérés comme un/des 
+    Les serveurs standbys suivants sont considérés comme un/des
     serveurs standbys synchrones potentiels.
     Si le premier serveur synchrone venait à tomber,
     il serait immédiatement remplacé par le serveur 
@@ -1349,7 +1350,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
      les serveurs de standby pour apporter un bon niveau de performances aux applications. Les phases d'attente d'écriture
      n'utilisent pas les ressources systèmes, mais les verrous transactionnels restent
      positionnés jusqu'à ce que le transfert vers les serveurs de standby soit confirmé. En conséquence, une utilisation non avertie de
-     la réplication synchrone aura pour impact une baisse des performances de la base de donnée
+     la réplication synchrone aura pour impact une baisse des performances de la base de données
      d'une application due à l'augmentation des temps de réponses et à un moins bon support de la charge.
     </para>
 
@@ -1423,7 +1424,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
      la différence entre le serveur de standby et le serveur primaire ramenée à zéro,
      le mode <literal>streaming</literal> est atteint.
      La durée du mode catchup peut être longue surtout juste après la création du serveur de standby.
-     Si le serveur de standby est arrêté sur cette période, alors la durée du mode CATCHUP
+     Si le serveur de standby est arrêté sur cette période, alors la durée du mode catchup
      sera d'autant plus longue.
      Le serveur de standby ne peut devenir un serveur de standby synchrone
      que lorsque le mode <literal>streaming</literal> est atteint.
@@ -1440,7 +1441,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
      transactions pourraient ne pas être considérées comme sauvegardées sur le serveur de standby, même si
      elles l'étaient sur le serveur primaire. La seule garantie offerte dans ce cadre est que
      l'application ne recevra pas de confirmation explicite de la
-     réussite d'une opération de validation avant qu'il soit sûr que les données WAL sont
+     réussite d'une opération de validation avant qu'il ne soit sûr que les données WAL sont
      reçues proprement par tous les serveurs de standby synchrones.
     </para>
 
@@ -1532,7 +1533,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
    serveur de standby peut être redémarré, même plus tard, alors le processus de récupération
    peut aussi être redémarré au même moment, en bénéficiant du fait que la récupération sait reprendre
    où elle en était. Si le serveur de standby ne peut pas être redémarré, alors
-   une nouvelle instance complète de standby devrait être créé.
+   une nouvelle instance complète de standby devrait être créée.
   </para>
 
   <para>
@@ -1593,8 +1594,7 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
    exécutez la commande <command>pg_ctl promote</command>, lancez la fonction
    <function>pg_promote()</function> ou créez un fichier trigger (déclencheur)
    avec le nom de fichier et le chemin spécifiés par le paramètre
-   <varname>promote_trigger_file</varname> de
-   <filename>recovery.conf</filename>. Si vous comptez utiliser la commande
+   <varname>promote_trigger_file</varname>. Si vous comptez utiliser la commande
    <command>pg_ctl promote</command> ou la fonction
    <function>pg_promote()</function> pour effectuer la bascule, la variable
    <varname>promote_trigger_file</varname> n'est pas nécessaire. S'il s'agit
@@ -1719,8 +1719,8 @@ if (!triggered)
      </listitem>
      <listitem>
       <para>
-       Effectuez une sauvegarde de base du serveur primaire( voir <xref
-       linkend="backup-base-backup"/>), , et chargez ces données sur le standby.
+       Effectuez une sauvegarde de base du serveur primaire (voir <xref
+       linkend="backup-base-backup"/>), et chargez ces données sur le standby.
       </para>
      </listitem>
      <listitem>
@@ -1748,7 +1748,7 @@ if (!triggered)
     pas plus que cela ne pourrait être décrit comme de la haute disponibilité.
    </para>
   </sect2>
-  .
+
   <sect2 id="warm-standby-record">
    <title>Log Shipping par Enregistrements</title>
 
@@ -1793,7 +1793,7 @@ if (!triggered)
   <para>
    Hot Standby est le terme utilisé pour décrire la possibilité de se
    connecter et d'exécuter des requêtes en lecture seule alors que le
-   serveur est en récupération d'archive or standby mode. C'est
+   serveur est en récupération d'archive ou mode standby. C'est
    utile à la fois pour la réplication et pour restaurer
    une sauvegarde à un état désiré avec une grande précision.
    Le terme Hot Standby fait aussi référence à la capacité du serveur à passer
@@ -1835,7 +1835,7 @@ if (!triggered)
 
    <para>
     Les transactions exécutées pendant la période de restauration sur un
-    serveur en mode hotstandby peuvent inclure les commandes suivantes&nbsp;:
+    serveur en mode hot standby peuvent inclure les commandes suivantes&nbsp;:
     <itemizedlist>
      <listitem>
       <para>
@@ -1900,7 +1900,7 @@ if (!triggered)
    </para>
 
    <para>
-    Les transactions lancées pendant la restauration d'un serveur en hotstandby
+    Les transactions lancées pendant la restauration d'un serveur en hot standby
     ne se verront jamais affectées un identifiant de transactions et ne peuvent
     pas être écrites dans les journaux de transactions. Du coup, les actions
     suivantes produiront des messages d'erreur&nbsp;:
@@ -1937,7 +1937,7 @@ if (!triggered)
      </listitem>
      <listitem>
       <para>
-       Rules sur des ordres <command>SELECT</command> qui génèrent des commandes LMD.
+       Règles sur des ordres <command>SELECT</command> qui génèrent des commandes LMD.
       </para>
      </listitem>
      <listitem>
@@ -2006,15 +2006,15 @@ if (!triggered)
    </para>
 
    <para>
-    Lors du fonctionnement en serveur hotstandby, le paramètre
+    Lors du fonctionnement en serveur hot standby, le paramètre
     <varname>transaction_read_only</varname> est toujours à true et ne peut
     pas être modifié. Tant qu'il n'y a pas de tentative de modification sur
-    la base de données, les connexions sur un serveur en hotstandby se
+    la base de données, les connexions sur un serveur en hot standby se
     comportent de façon pratiquement identiques à celles sur un serveur normal.
     Quand une bascule (<foreignphrase>failover</foreignphrase> ou
     <foreignphrase>switchover</foreignphrase>) survient, la base de données
     bascule dans le mode de traitement normal. Les sessions resteront
-    connectées pendant le changement de mode. Quand le mode hotstandby est
+    connectées pendant le changement de mode. Quand le mode hot standby est
     terminé, il sera possible de lancer des transactions en lecture/écriture,
     y compris pour les sessions connectées avant la bascule.
    </para>
@@ -2034,7 +2034,7 @@ if (!triggered)
    <title>Gestion des conflits avec les requêtes</title>
 
    <para>
-    Les nœuds primaire et standby sont de bien des façons faiblement couplés. Des
+    Les nœuds primaire et standby sont faiblement couplés à bien des égards. Des
     actions sur le primaire auront un effet sur le standby. Par conséquent, il y a
     un risque d'interactions négatives ou de conflits entre eux. Le conflit le
     plus simple à comprendre est la performance : si un gros chargement de données a
@@ -2165,7 +2165,7 @@ if (!triggered)
     <varname>max_standby_streaming_delay</varname> a été dépassé, toutes les
     requêtes en conflit seront annulées. Ceci résulte habituellement en une
     erreur d'annulation, bien que certains cas, comme un <command>DROP
-     DATABASE</command>, peuvent occassionner l'arrêt complet de la connexion.
+     DATABASE</command>, peuvent occasionner l'arrêt complet de la connexion.
     De plus, si le conflit intervient sur un verrou détenu par une transaction
     en attente, la session en conflit sera terminée (ce comportement pourrait
     changer dans le futur).
@@ -2183,7 +2183,7 @@ if (!triggered)
     Gardez en tête que les paramètres de délai sont comparés au temps passé
     depuis que la donnée du journal de transactions a été reçue par le serveur
     en attente. Du coup, la période de grâce accordée aux requêtes n'est jamais
-    supérieur au paramètre de délai, et peut être considérablement inférieur
+    supérieure au paramètre de délai, et peut être considérablement inférieure
     si le serveur en attente est déjà en retard suite à l'attente de la fin
     de l'exécution de requêtes précédentes ou suite à son impossibilité de
     conserver le rythme d'une grosse mise à jour.
@@ -2376,7 +2376,7 @@ LOG:  database system is ready to accept read only connections
     re-génèreront les fichiers d'information relcache, il n'y a donc pas de morceau de la base
     qui soit réellement en lecture seule en mode hot standby.
     Notez aussi que les écritures dans des bases distantes en utilisant le module
-    <application>dblink</application> , et d'autres opération en dehors de la base s'appuyant sur
+    <application>dblink</application>, et d'autres opération en dehors de la base s'appuyant sur
     des fonctions PL seront toujours possibles, même si la transaction est en lecture seule localement.
    </para>
 
@@ -2446,7 +2446,7 @@ LOG:  database system is ready to accept read only connections
     parce que les informations simples qu'il vérifie existent.
     Le script de supervision <productname>check_postgres</productname> fonctionnera aussi,
     même si certaines valeurs retournées pourraient être différentes ou sujettes à confusion.
-    Par exemple, la date de dernier vacuum ne sera pas mise à jour, puisqu'aucun vacuum ne se déclenche
+    Par exemple, la date de dernier vacuum ne sera pas mise à jour, puis-qu'aucun vacuum ne se déclenche
     sur le standby. Les vacuums s'exécutant sur le primaire envoient toujours leurs modifications
     au standby.
    </para>
@@ -2477,7 +2477,7 @@ LOG:  database system is ready to accept read only connections
     ne fonctionneront pas sur le standby du tout, même s'ils fonctionneront sans problème
     sur le serveur primaire tant que les modifications ne sont pas envoyées sur le serveur standby
     pour y être appliquées. Le rejeu de WAL n'est pas à base de triggers, vous ne pouvez
-    donc pas utiliser le standby comme relai vers un système qui aurait besoin d'écritures supplémentaires
+    donc pas utiliser le standby comme relais vers un système qui aurait besoin d'écritures supplémentaires
     ou utilise des triggers.
    </para>
 
@@ -2581,7 +2581,7 @@ LOG:  database system is ready to accept read only connections
    <title>Avertissements</title>
 
    <para>
-    Il y a plusieurs limitations de Hot Standby.
+    Il y a plusieurs limitations au Hot Standby.
     Elles peuvent et seront probablement résolues dans des versions ultérieures:
 
     <itemizedlist>