traduction v14 high-availability.xml

postgresql/high-availability.xml

@@ -199,13 +199,16 @@ ce que les nœuds s'accordent dans un système transactionnel sérialisable.
     <listitem>
 
      <para>
-      A trigger-based replication setup typically funnels data modification
-      queries to a designated primary server. Operating on a per-table basis,
-      the primary server sends data changes (typically) asynchronously to the
-      standby servers.  Standby servers can answer queries while the primary is
-      running, and may allow some local data changes or write activity.  This
-      form of replication is often used for offloading large analytical or data
-      warehouse queries.
+      Une architecture de réplication basée sur des triggers canalise
+      habituellement les requêtes de modification de données vers un serveur
+      primaire précis. Opérant table par table, le serveur primaire envoie alors
+      les données modifiées (généralement) de façon asynchrone vers les serveurs
+      secondaires. Les serveurs secondaires peuvent répondre aux requêtes qu'ils
+      reçoivent alors que le serveur primaire est fonctionnel. Ils peuvent
+      parfois permettre quelques modifications de données localement ou même une
+      activité en écriture. Cette forme de réplication est souvent utilisée pour
+      gérer de grosses requêtes analytiques ou de type
+      <foreignphrase>Data Warehouse</foreignphrase>.
      </para>
 
      <para>
@@ -1831,10 +1834,10 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
    <para>
     Les utilisateurs peuvent déterminer si le Hot Standby est actuellement
     actif pour leur session en exécutant <command>SHOW
-    transaction_read_only</command>.(In server versions before 14, the
-    <varname>in_hot_standby</varname> parameter did not exist; a workable
-    substitute method for older servers is <command>SHOW
-    transaction_read_only</command>.) De plus, un jeu de fonctions
+    in_hot_standby</command>. (Le paramètre <varname>in_hot_standby</varname> 
+    n'existant pas avant la version 14, <command>SHOW
+    transaction_read_only</command> est donc à utiliser sur les serveurs en 
+    version plus anciennes.) De plus, un jeu de fonctions
     (<xref linkend="functions-recovery-info-table"/>) permettent aux
     utilisateurs d' accéder à des informations à propos du serveur de
     standby. Ceci vous permet d'écrire des programmes qui sont conscients de
@@ -2076,9 +2079,11 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
    </para>
 
    <para>
-    Users can control whether a log message is produced when WAL replay is waiting
-    longer than <varname>deadlock_timeout</varname> for conflicts. This
-    is controlled by the <xref linkend="guc-log-recovery-conflict-waits"/> parameter.
+    Les utilisateurs peuvent contrôler si un message doit être écrit dans les 
+    journaux du serveur lorsque le rejeu des journaux de transactions est en 
+    conflit depuis plus longtemps que <varname>deadlock_timeout</varname>.
+    Ce comportement est contrôlé par le paramètre
+    <xref linkend="guc-log-recovery-conflict-waits"/>.
    </para>
   </sect2>
 
@@ -2134,14 +2139,15 @@ LOG:  database system is ready to accept read only connections
    </para>
 
    <para>
-    The settings of some parameters determine the size of shared memory for
-    tracking transaction IDs, locks, and prepared transactions.  These shared
-    memory structures must be no smaller on a standby than on the primary in
-    order to ensure that the standby does not run out of shared memory during
-    recovery.  For example, if the primary had used a prepared transaction but
-    the standby had not allocated any shared memory for tracking prepared
-    transactions, then recovery could not continue until the standby's
-    configuration is changed.  The parameters affected are:
+    Certains paramètres déterminent la taille de la mémoire partagée pour le
+    suivi des identifiants de transaction, des verrous, et des transactions
+    préparées. Ces structures mémoires partagées ne peuvent pas être plus
+    petites sur le standby que sur le primaire pour s'assurer que le standby ne
+    tombera pas à court de mémoire partagée pendant la récupération. Par
+    exemple, si le primaire avait utilisé des transactions préparées mais que le
+    standby n'avait pas alloué de mémoire partagée pour suivre ces transactions
+    préparées, alors la récupération ne pourrait reprendre avant que la
+    configuration du standby ne soit adaptée. Les paramètres concernés sont:
 
     <itemizedlist>
      <listitem>
@@ -2171,36 +2177,39 @@ LOG:  database system is ready to accept read only connections
      </listitem>
     </itemizedlist>
 
-    The easiest way to ensure this does not become a problem is to have these
-    parameters set on the standbys to values equal to or greater than on the
-    primary.  Therefore, if you want to increase these values, you should do
-    so on all standby servers first, before applying the changes to the
-    primary server.  Conversely, if you want to decrease these values, you
-    should do so on the primary server first, before applying the changes to
-    all standby servers.  Keep in mind that when a standby is promoted, it
-    becomes the new reference for the required parameter settings for the
-    standbys that follow it.  Therefore, to avoid this becoming a problem
-    during a switchover or failover, it is recommended to keep these settings
-    the same on all standby servers.
-   </para>
-
-   <para>
-    The WAL tracks changes to these parameters on the
-    primary.  If a hot standby processes WAL that indicates that the current
-    value on the primary is higher than its own value, it will log a warning
-    and pause recovery, for example:
+    La façon la plus simple pour éviter que cela ne devienne un problème est
+    d'avoir tous ces paramètres définis sur les serveurs standbys à des valeurs
+    égales ou supérieures que celles du primaire. C'est pourquoi, si vous voulez
+    augmenter ces valeurs, vous devez le faire d'abord sur tous les serveurs
+    standbys avant de le faire sur le serveur primaire. De la même façon, si
+    vous voulez diminuer ces valeurs, vous devez d'abord le faire sur le serveur
+    primaire, puis sur tous les serveurs standbys. Gardez également à l'esprit
+    que lorsqu'un standby est promu, il devient alors la nouvelle référence des
+    valeurs de ces paramètres pour les standbys qui s'y raccrochent. De ce fait,
+    pour éviter que cela ne devienne un problème lors d'une bascule
+    (<foreignphrase>switchover</foreignphrase> ou
+    <foreignphrase>failover</foreignphrase>), il est recommandé de conserver ces
+    paramètres identiques sur tous les serveurs standbys.
+   </para>
+
+   <para>
+    Les journaux de transactions tracent le changement de ces paramètres sur le
+    serveur primaire. Si un serveur hot standby rejoue un journal de
+    transactions qui indique que la valeur actuelle sur le primaire est plus
+    élevée que la sienne, un message d'avertissement sera écrit dans les traces
+    du serveur et le rejeu mis en pause. Par exemple :
 <screen>
 WARNING:  hot standby is not possible because of insufficient parameter settings
 DETAIL:  max_connections = 80 is a lower setting than on the primary server, where its value was 100.
 LOG:  recovery has paused
 DETAIL:  If recovery is unpaused, the server will shut down.
 HINT:  You can then restart the server after making the necessary configuration changes.
 </screen>
-    At that point, the settings on the standby need to be updated and the
-    instance restarted before recovery can continue.  If the standby is not a
-    hot standby, then when it encounters the incompatible parameter change, it
-    will shut down immediately without pausing, since there is then no value
-    in keeping it up.
+    A ce stade, les paramètres du standby doivent être ajustés et l'instance
+    redémarrée avant que le rejeu ne puisse reprendre. Si le standby n'est pas
+    en mode hot standby alors, lorsqu'il rencontrera un changement de paramètre
+    incompatible, il s'éteindra immédiatement sans pause, puisqu'il serait
+    inutile de rester actif.
    </para>
 
    <para>