Changeset 519

Show
Ignore:
Timestamp:
12/08/06 09:46:03 (2 years ago)
Author:
sas
Message:

Relecture des ajouts du passage à la 8.2.0

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/manuel/backup.xml

    r511 r519  
    11<?xml version="1.0" encoding="ISO-8859-1"?> 
    22<!-- $Header: /var/lib/cvs/pgsql-fr/sgml/backup.sgml,v 1.17 2005/09/15 07:03:14 guillaume Exp $ --> 
     3<!-- SAS : 20061208 --> 
    34<chapter id="backup"> 
    45 <title>Sauvegardes et restaurations</title> 
    …… 
    1718  données de <productname>PostgreSQL</productname>&nbsp;: 
    1819  <itemizedlist> 
    19    <listitem><para><acronym>La sauvegarde SQL&nbsp;;</acronym></para></listitem> 
    20    <listitem><para>La sauvegarde au niveau du système de 
     20   <listitem><para><acronym>la sauvegarde SQL&nbsp;;</acronym></para></listitem> 
     21   <listitem><para>la sauvegarde au niveau du système de 
    2122    fichiers&nbsp;;</para></listitem> 
    22    <listitem><para>L'archivage continue.</para></listitem> 
     23   <listitem><para>l'archivage continue.</para></listitem> 
    2324  </itemizedlist> 
    2425  Chacune a ses avantages et inconvénients. 
    …… 
    4041 
    4142  <para> 
    42    <application>pg_dump</application> est un programme client <productname>PostgreSQL</productname> 
     43   <application>pg_dump</application> est un programme client 
     44   <productname>PostgreSQL</productname> 
    4345   classique (mais plutôt intelligent). Ceci signifie que la  
    4446   sauvegarde peut être effectuée depuis n'importe quel ordinateur ayant accès à la base. 
    …… 
    5052 
    5153  <para> 
    52    Pour préciser quel serveur de bases de données <application>pg_dump</application> doit 
    53    contacter, on utilise les options de ligne de commande <option>-h 
    54    <replaceable>serveur</replaceable></option> et <option>-p <replaceable>port</replaceable></option>. 
    55    Le serveur par défaut est le serveur local, ou bien celui spécifié par la  
     54   Pour préciser le serveur de bases de données que  
     55   <application>pg_dump</application> doit 
     56   contacter, on utilise les options de ligne de commande 
     57   <option>-h <replaceable>serveur</replaceable></option> et 
     58   <option>-p <replaceable>port</replaceable></option>. 
     59   Le serveur par défaut est le serveur local ou celui indiqué par la  
    5660   variable d'environnement <envar>PGHOST</envar>. 
    5761   De la même façon, le port par défaut est indiqué par la variable d'environnement 
    5862   <envar>PGPORT</envar> ou, en son absence, par la valeur par défaut précisée  
    59    à la compilation. Le serveur a normalement la même valeur par 
     63   à la compilation. Le serveur a normalement reçu les mêmes valeurs par 
    6064   défaut à la compilation. 
    6165  </para> 
    6266 
    6367  <para> 
    64    Comme tout programme client <productname>PostgreSQL</productname>, <application>pg_dump</application> 
     68   Comme tout programme client <productname>PostgreSQL</productname>, 
     69   <application>pg_dump</application> 
    6570   se connecte par défaut avec l'utilisateur de base de données de même nom que  
    66    l'utilisateur système courant. Pour passer outre, on utilise l'option  
    67    <option>-U</option> ou on donne une valeur à la variable d'environnement 
    68    <envar>PGUSER</envar>. Les connexions de 
     71   l'utilisateur système courant. L'utilisation de l'option 
     72   <option>-U</option> ou de la variable d'environnement 
     73   <envar>PGUSER</envar> permettent de 
     74   modifier le comportement par défaut. Les connexions de 
    6975   <application>pg_dump</application> sont soumises aux mécanismes normaux 
    70    d'authentification des programmes clients (qui sont décrits dans le <xref 
    71    linkend="client-authentication"/>). 
     76   d'authentification des programmes clients (décrits dans le 
     77   <xref linkend="client-authentication"/>). 
    7278  </para> 
    7379 
    7480  <para> 
    7581   Les sauvegardes créées par <application>pg_dump</application> sont cohérentes, ce 
    76    qui veut dire que les modifications effectuées alors que <application>pg_dump</application> 
     82   qui signifie que les modifications effectuées alors que <application>pg_dump</application> 
    7783   est en cours de fonctionnement ne sont pas reprises dans le fichier de résultat. 
    7884   <application>pg_dump</application> ne bloque pas les autres opérations sur la base  
    …… 
    95101 
    96102   <para> 
    97     Les fichiers texte créés par <application>pg_dump</application> sont prévus pour être  
     103    Les fichiers texte créés par <application>pg_dump</application> peuvent être  
    98104    lus par le programme <application>psql</application>. La syntaxe générale  
    99105    d'une commande de restauration est 
    …… 
    119125    restauration échoue pour la création des objets dont ils sont 
    120126    propriétaires ou sur lesquels ils ont des droits (quelque fois, cela 
    121     est souhaitable mais ce n'est pas le cas habituellement). 
     127    est souhaitable mais ce n'est habituellement pas le cas). 
    122128   </para> 
    123129 
    …… 
    155161     Les fichiers de sauvegarde produits par <application>pg_dump</application> sont 
    156162     relatifs à <literal>template0</literal>. Cela signifie que chaque langage, 
    157      procédure, etc. ajoutés à <literal>template1</literal> seront aussi sauvegardés 
     163     procédure, etc. ajouté à <literal>template1</literal> est aussi sauvegardé 
    158164     par <application>pg_dump</application>. En conséquence, si une base 
    159      <literal>template1</literal> modifiée est utilisée, il faut créer la base 
    160      vide à partir de 
     165     <literal>template1</literal> modifiée est utilisée lors de la 
     166     restauration, il faut créer la base vide à partir de 
    161167     <literal>template0</literal>, comme dans l'exemple précédent. 
    162168    </para> 
    …… 
    164170 
    165171   <para> 
    166     Après la restauration d'une sauvegarde, il est conseillé d'exécuter <xref 
    167     linkend="sql-analyze" endterm="sql-analyze-title"/> sur chaque base de 
     172    Après la restauration d'une sauvegarde, il est conseillé d'exécuter 
     173    <xref linkend="sql-analyze" endterm="sql-analyze-title"/> sur chaque base de 
    168174    données pour que l'optimiseur de requêtes dispose de statistiques utiles. 
    169175    Un moyen simple de le faire est d'exécuter <command>vacuumdb -a -z</command>&nbsp;; 
    …… 
    181187 
    182188   <para> 
    183     <application>pg_dump</application> sauvegarde seulement une base de données 
    184     à la fois et il ne sauvegarde pas les informations sur les rôles et les 
    185     tablespaces (car ils sont communs au cluster et non pas par base). Pour 
    186     supporter une sauvegarde simple de contenu entier du cluster, le programme 
    187     <xref linkend="app-pg-dumpall"/> est fourni. 
     189    <application>pg_dump</application> ne sauvegarde qu'une seule base à la 
     190    fois, et ne sauvegarde pas les informations relatives aux rôles et 
     191    <foreignphrase>tablespaces</foreignphrase> (parce que ceux-ci portent 
     192    sur l'ensemble des bases du cluster, et non sur une base particulière). 
     193    Pour permettre une sauvegarde aisée de tout le contenu d'un cluster, le 
     194    programme <xref linkend="app-pg-dumpall"> est fourni. 
    188195    <application>pg_dumpall</application> sauvegarde toutes les bases de données d'un 
    189196    groupe de bases de données <productname>PostgreSQL</productname> (appelé cluster) et 
    190     préserve les données communes au cluster, comme les rôles et tablespaces. 
     197    préserve les données communes au cluster, telles que les rôles et tablespaces. 
    191198    L'utilisation basique de cette commande est&nbsp;: 
    192199<synopsis>pg_dumpall &gt; <replaceable>fichier_de_sortie</replaceable></synopsis> 
    …… 
    194201    <application>psql</application>&nbsp;: 
    195202<synopsis>psql -f <replaceable class="parameter">fichier_d_entree</replaceable> postgres</synopsis> 
    196     (N'importe quelle base de données peut être utiliser pour la connexion  
     203    (N'importe quelle base de données peut être utilisée pour la connexion  
    197204    mais si le rechargement est exécuté sur un cluster vide, il est 
    198205    préférable d'utiliser <literal>postgres</literal>.) 
    …… 
    200207    une sauvegarde faite avec <application>pg_dumpall</application>, afin de 
    201208    pouvoir restaurer les informations sur les rôles et les tablespaces. 
    202     Si vous utilisez des tablespaces, faites attention que les chemins des 
    203     tablespaces dans la sauvegarde sont appropriées pour la nouvelle 
     209    Si les <foreignphrase>tablespaces</foreignphrase> sont utilisés, il faut 
     210    s'assurer que leurs chemins sauvegardés sont appropriés à la nouvelle 
    204211    installation. 
    205212   </para> 
    …… 
    254261 
    255262   <formalpara> 
    256     <title>Utilisation du format de sauvegarde spécial</title> 
     263    <title>Utilisation du format de sauvegarde personnalisé</title> 
    257264    <para> 
    258265     Si <productname>PostgreSQL</productname> est installé sur un système où la  
    259      bibliothèque de compression <application>zlib</application> est disponible, ce format 
    260      de sauvegarde spécial peut être utilisé. Pour les grandes bases de données, 
     266     bibliothèque de compression <application>zlib</application> est 
     267     disponible, le format de sauvegarde personnalisé peut être utilisé pour 
     268     compresser les données à la volée. Pour les bases de données 
     269     volumineuses, 
    261270     cela produit un fichier de sauvegarde d'une taille comparable à celle 
    262271     du fichier produit par 
    263272     <command>gzip</command>, avec l'avantage supplémentaire de permettre de 
    264273     restaurer des tables sélectivement. La commande qui suit sauvegarde une 
    265      base de données en utilisant le format de sauvegarde spécial&nbsp;: 
     274     base de données en utilisant ce format de sauvegarde&nbsp;: 
    266275  
    267276<programlisting>pg_dump -Fc <replaceable class="parameter">base_de_donnees</replaceable> &gt; <replaceable class="parameter">nom_fichier</replaceable></programlisting> 
    268277 
    269      Le format personnalisé de la sauvegarde ne produit pas un script 
     278     Le format de sauvegarde personnalisé ne produit pas un script 
    270279     utilisable par 
    271280     <application>psql</application>. Ce script doit être restauré avec 
    272      <application>pg_restore</application>. Voir les pages de référence de <xref 
    273      linkend="app-pgdump"/> et <xref linkend="app-pgrestore"/> pour plus de 
     281     <application>pg_restore</application>. Voir les pages de référence de 
     282     <xref linkend="app-pgdump"/> et <xref linkend="app-pgrestore"/> pour plus de 
    274283     détails. 
    275284    </para> 
    …… 
    283292 
    284293  <para> 
    285    Une autre stratégie de sauvegarde est de copier les fichiers 
    286    utilisés par <productname>PostgreSQL</productname> pour enregistrer les données. 
     294   Une autre stratégie de sauvegarde consiste à copier les fichiers 
     295   utilisés par <productname>PostgreSQL</productname> pour le stockage des données. 
    287296   Dans la <xref linkend="creating-cluster"/>, l'emplacement de ces 
    288297   fichiers est précisé mais quiconque s'intéresse à cette méthode les a 
    …… 
    305314      (principalement parce que <command>tar</command> et les outils similaires 
    306315      ne font pas une image atomique de l'état du système de fichiers à un 
    307       moment spécifique). Les informations concernant la façon d'arrêter 
    308       le serveur <productname>PostgreSQL</productname> se trouvent dans la <xref 
    309       linkend="server-shutdown"/>. 
     316      moment donné). Les informations concernant la façon d'arrêter 
     317      le serveur <productname>PostgreSQL</productname> se trouvent dans la 
     318      <xref linkend="server-shutdown"/>. 
    310319    </para> 
    311320 
    …… 
    317326    <listitem> 
    318327     <para> 
    319       Qui s'est aventuré dans les détails de l'organisation de la  
     328      Quiconque s'est aventuré dans les détails de l'organisation de la  
    320329      base de données peut être tenté de ne sauvegarder et  
    321330      de ne restaurer que certaines tables ou bases de données particulières.  
    …… 
    323332      contenues dans ces fichiers ne représentent que la moitité de la 
    324333      vérité. L'autre moitié est dans les fichiers journaux de validation 
    325       <filename>pg_clog/*</filename>, qui  
     334      <filename>pg_clog/*</filename> qui  
    326335      contiennent l'état de la validation de chaque transaction. Un fichier de  
    327336      table n'est utilisable qu'avec cette information. Bien entendu, il est  
    …… 
    337346 
    338347  <para> 
    339    Une autre approche à la sauvegarde du système de fichiers est de réaliser 
    340    une <quote>image cohérente</quote> du répertoire des données si le système 
    341    de fichiers supporte cette fonctionnalité (et qu'il peut lui être fait 
    342    confiance). La procédure typique est de faire une 
    343    <quote>image gelée</quote> du volume contenant la base de données, et enfin de 
    344    copier entièrement le répertoire de données (pas uniquement quelques parties, 
     348   Une autre approche à la sauvegarde du système de fichiers consiste à réaliser 
     349   une <quote>image cohérente</quote> du répertoire des données. Il faut 
     350   pour cela que le système 
     351   de fichiers supporte cette fonctionnalité (et qu'il puisse lui être fait 
     352   confiance). La procédure typique consiste à réaliser une 
     353   <quote>image gelée</quote> du volume contenant la base de données et 
     354   ensuite de copier entièrement le répertoire de données (pas seulement 
     355   quelques parties, 
    345356   voir ci-dessus) de l'image sur un périphérique de sauvegarde, puis de 
    346357   libérer l'image gelé. Ceci fonctionne même si le serveur de la base de 
    347    données est en cours d'exécution. Néanmoins, une sauvegarde créée de cette 
    348    façon sauvegarde les fichiers de la base de données dans un état où le 
     358   données est en cours d'exécution. Néanmoins, une telle sauvegarde 
     359   copie les fichiers de la base de données dans un état où le 
    349360   serveur n'est pas correctement arrêté&nbsp;; du coup, au lancement du 
    350361   serveur à partir des données sauvegardées, PostgreSQL peut penser que le 
    …… 
    392403 
    393404 <sect1 id="continuous-archiving"> 
    394   <title>Archivage en continue et récupération d'un instantané (PITR)</title> 
     405  <title>Archivage continu et récupération d'un instantané (PITR)</title> 
    395406 
    396407  <indexterm zone="backup"> 
    …… 
    413424   bases. Ils existent principalement pour se prémunir des suites d'un 
    414425   arrêt brutal&nbsp;: si le système s'arrête brutalement, la base de données 
    415    peut être restaurée dans un état cohérent des données en 
     426   peut être restaurée dans un état cohérent en 
    416427   <quote>rejouant</quote> les entrées des journaux enregistrées depuis le dernier 
    417428   point de vérification. Néanmoins, l'existence de ces journaux rend possible 
    …… 
    426437   <listitem> 
    427438    <para> 
    428      il n'est pas nécessaire de faire une sauvegarde parfaitement cohérente 
     439     Il n'est pas nécessaire de disposer d'une sauvegarde parfaitement cohérente 
    429440     comme point de départ. Toute incohérence dans la sauvegarde est corrigée 
    430441     par la ré-exécution des journaux (ceci n'est pas significativement 
    …… 
    438449    <para> 
    439450     Puisqu'une longue séquence de fichiers WAL peut être assemblée pour 
    440      être rejouée, la sauvegarde continue est possible en continuant 
     451     être rejouée, une sauvegarde continue est obtenue en continuant 
    441452     simplement à archiver les fichiers WAL. Ceci est particulièrement 
    442      intéressant pour les grosses bases de données dont la fréquente 
     453     intéressant pour les grosses bases de données dont une fréquente 
    443454     sauvegarde complète est difficilement réalisable. 
    444455    </para> 
    …… 
    459470     Si la série de fichiers WAL est fournie en continu à une autre 
    460471     machine chargée avec le même fichier de sauvegarde de base, 
    461      on obtient un système <quote>de reprise automatique</quote> 
     472     on obtient un système <quote>de reprise intermédiaire</quote> 
    462473     (<foreignphrase>warm standby</foreignphrase>)&nbsp;: à tout 
    463474     moment, la deuxième machine peut être montée et disposer d'une copie 
    …… 
    705716     superutilisateur et lancer la commande 
    706717<programlisting>SELECT pg_stop_backup();</programlisting> 
    707      Ceci termine le mode de sauvegarde et exécute un basculement automatique 
    708      vers le prochain segment WAL. La raison de ce basculement est de s'arranger 
    709      pour que le dernier segment WAL écrit pendant l'interval de sauvegarde 
    710      soit immédiatement prêt à archiver. 
     718     Cela met fin au processus de sauvegarde et réalise un basculent 
     719     automatique vers le prochain segment WAL. Ce basculement est nécessaire 
     720     pour permettre au dernier fichier de segment WAL écrit pendant la 
     721     sauvegarde d'être immédiatement archivable. 
    711722    </para> 
    712723   </listitem> 
    …… 
    10231034    récupération pour permettre à cette dernière de se terminer correctement. 
    10241035    Si la récupération échoue pour une raison externe (arrêt brutal du système 
    1025     ou archive WAL devenue inaccessible), alors la récupération peut être 
     1036    ou archive WAL devenue inaccessible), la récupération peut être 
    10261037    simplement relancée. Elle redémarre alors pratiquement là où elle a échoué. 
    1027     Le relancement de la récupération fonctionne plus comme les vérifications 
    1028     en opération normale&nbsp;: le serveur force périodiquement tout son état 
    1029     sur disque puis met à jour le fichier <filename>pg_control</filename> pour 
    1030     indiquer que les données WAL déjà traitées n'ont pas besoin d'être de 
    1031     nouveau parcourues. 
     1038    Le redémarrage de la restauration fonctionne comme les points de 
     1039    contrôle du déroulement normal&nbsp;: le serveur force une écriture 
     1040    régulière de son état sur les disques et actualise alors le fichier 
     1041    <filename>pg_control</filename> pour indiquer que les données WAL déjà 
     1042    parcourues n'ont plus à être parcourus. 
    10321043   </para> 
    10331044 
    …… 
    13511362 
    13521363  <indexterm zone="backup"> 
    1353    <primary>Haute Disponibilité</primary> 
     1364   <primary>haute disponibilité</primary> 
    13541365  </indexterm> 
    13551366 
    …… 
    13941405 
    13951406  <para> 
    1396    L'envoi des journaux est asynchrone, c'est-à-dire que les enregistrements 
     1407   L'envoi des journaux est asynchrone, ce qui signifie que les enregistrements 
    13971408   WAL sont envoyés après validation de la transaction. De ce fait, il y a un 
    13981409   léger risque de perte de données si le serveur principal est l'objet d'une 
    1399    panne catastrophique&nbsp;: les transactions non envoyées seront perdues. 
    1400    La quantité de données perdues peut être limitée en modifiant le paramètre 
    1401    <varname>archive_timeout</varname> qui peut être configuré très bas, par 
    1402    exemple quelques secondes si nécessaire. Néanmoins, des paramètres si bas 
    1403    augmenteront de façon substantielle les besoins en bande passante pour le 
    1404    transfert de fichiers. Si vous avez besoin d'une fenêtre de moins d'une 
    1405    minute, il est probablement mieux de se tourner vers le transfert de 
    1406    journaux basés sur les enregistrements. 
     1410   panne catastrophique&nbsp;: les transactions qui ne sont pas encore 
     1411   transmises sont perdues. La taille de la fenêtre des données perdues peut 
     1412   être réduite par l'utilisation du paramètre 
     1413   <varname>archive_timeout</varname>. Celui-ci peut être positionné à une 
     1414   valeur de quelques secondes seulement, si nécessaire. Toutefois, une 
     1415   valeur aussi faible augmente considérablement les besoins en bande 
     1416   passante du transfert de fichiers. Si une valeur aussi basse est 
     1417   nécessaire, il peut être préférable de s'intéresser au transfert de 
     1418   journaux par enregistrement.  
    14071419  </para> 
    14081420 
    …… 
    14101422   Le serveur de secours n'est pas accessible, car il est en permanence 
    14111423   occupé par la récupération. Les performances de récupération 
    1412    sont suffisamment bonnes pour que l'attente ne soit que d'un peu de temps 
    1413    avant d'obtenir une disponibilité complète une fois qu'il a été 
    1414    activé. En conséquence, on appelle cela une configuration de reprise intermédiaire ou 
    1415    de secours semi-automatique (<foreignphrase>warm 
    1416    standby</foreignphrase>) permettant d'obtenir de la haute disponibilité. 
     1424   sont suffisamment bonnes pour que l'attente soit réduite  
     1425   avant d'obtenir une disponibilité complète une fois le serveur de secours 
     1426   activé. En conséquence, on appelle cela une configuration de reprise 
     1427   intermédiaire ou de secours semi-automatique 
     1428   (<foreignphrase>warm standby</foreignphrase>), qui permet d'atteindre la 
     1429   haute disponibilité. 
    14171430   La restauration d'un serveur à partir d'une sauvegarde archivée de la 
    1418    base et de la relecture des journaux prendra considérablement plus de temps. 
     1431   base et de la relecture des journaux prend considérablement plus de temps. 
    14191432   Cette technique n'offre qu'une solution de récupération suite à une panne, 
    14201433   mais pas de la haute disponibilité. 
    …… 
    14251438 
    14261439   <para> 
    1427     Il est généralement conseillé de créer les serveurs primaire et d'attente 
    1428     pour qu'ils soient aussi similaires que possible, au moins du point de 
    1429     vue du serveur de base de données. En particulier, les noms des chemins 
    1430     associés avec les tablespaces seront passés sans modification, donc les 
    1431     serveurs primaire et d'attente doivent avoir les mêmes chemins de montage 
    1432     pour les tablespaces si cette fonctionnalité est utilisée. Gardez en tête 
    1433     que si <xref linkend="sql-createtablespace" 
    1434     endterm="sql-createtablespace-title"/> est exécuté sur le primaire, tout 
    1435     point de montage nécessaire pour ce dernier doit être créé sur le serveur 
    1436     principal et tous les serveurs d'attente avant l'exécution de la commande. 
    1437     Le matériel n'est pas obligatoirement identique mais l'expérience a montré 
    1438     que maintenir deux systèmes identiques est plus facile que maintenir deux 
    1439     systèmes différents pendant toute la durée de vie de l'application et du 
    1440     système. Dans tous les cas, l'architecture du matériel doit être identique 
    1441     &mdash; transférer d'un système 32 bits vers un 64 bits ne fonctionnera pas. 
    1442    </para> 
    1443  
    1444   <para> 
    1445    En général, le transfert de journaux entre serveurs de versions majeures 
    1446    différentes n'est pas possible. La politique des développeurs du 
     1440    Il est généralement préférable de créer des serveurs primaire et de 
     1441    secours aussi semblables que possible, au moins du point de 
     1442    vue du serveur de bases de données. En particulier, les noms des chemins 
     1443    associés aux <foreignphrase>tablespaces</foreignphrase> sont passés tels 
     1444    quels. Les serveurs doivent donc, tous, posséder les mêmes chemins de 
     1445    montage des <foreignphrase>tablespaces</foreignphrase> si cette fonctionnalité 
     1446    est utilisée. Si 
     1447    <xref linkend="sql-createtablespace" endterm="sql-createtablespace-title"/> 
     1448    est exécuté sur le serveur principal, tout nouveau point de montage 
     1449    nécessaire doit être créé à la fois sur le serveur principal et sur tous les 
     1450    serveurs de secours, avant l'exécution de la commande. 
     1451    Le matériel ne doit pas obligatoirement être identique mais l'expérience 
     1452    prouve qu'il est plus facile de maintenir deux systèmes identiques 
     1453    sur la durée de vie de l'application et du système. Dans tous les cas, 
     1454    l'architecture du matériel doit être identique 
     1455    &mdash; le transfert d'un système 32 bits à un 64 bits ne fonctionne pas. 
     1456   </para> 
     1457 
     1458  <para> 
     1459   En général, il n'est pas possible d'effectuer le transfert de journaux 
     1460   entre serveurs de versions majeures différentes. La politique des 
     1461   développeurs du 
    14471462   <quote>PostgreSQL Global Development Group</quote> consiste à ne pas 
    14481463   modifier les formats disque lors de mises à jour mineures. De ce fait, il 
    14491464   est possible d'utiliser des serveurs principal et de secours de versions 
    1450    mineures différentes. Toutefois, aucun support formel n'est offert 
    1451    pour cela. Autant que possible, il est préférable de conserver les serveurs 
    1452    primaire et d'attente au même niveau de version. Lors de la mise à jour 
     1465   mineures différentes. Toutefois, aucune garantie formelle n'est offerte à 
     1466   ce sujet. Il est préférable, dans la mesure du possible, de conserver les 
     1467   serveurs 
     1468   primaire et de secours au même niveau de version. Lors de la mise à jour 
    14531469   vers une nouvelle version mineure, la meilleure politique est de mettre 
    1454    à jour les serveurs en attente en premier &mdash; une nouvelle version 
    1455    mineure a plus de chances de lire les fichiers WAL d'une version mineure 
    1456    précédente plutôt que le contraire. 
    1457   </para> 
    1458  
    1459    <para> 
    1460     Il n'existe pas de mode spécial pour activer un serveur de secours. 
     1470   à jour les serveurs de secours en premier &mdash; il y a plus de chances 
     1471   qu'une version mineure sache lire les fichiers WAL d'une version mineure 
     1472   précédente que le contraire. 
     1473  </para> 
     1474 
     1475  <para> 
     1476    Il n'y a pas de mode particulier requis pour activer un serveur de 
     1477    secours. 
    14611478    Les seules opérations sur les serveurs principal et de secours 
    1462     sont des tâches normales et continuelles d'archivage et de récupération. 
     1479    sont des tâches normales d'archivage continu et de récupération. 
    14631480    Le seul point de contact entre les deux serveurs est 
    1464     l'archive des fichiers WAL qu'ils partagent&nbsp;: le principal les 
     1481    l'archive de fichiers WAL qu'ils partagent&nbsp;: le principal les 
    14651482    écrit, le serveur de secours les lit. Il est impératif que des 
    14661483    archives WAL de serveurs primaires différents ne soient pas mélangées. 
    …… 
    14701487    La magie qui permet à deux serveurs faiblement liés de travailler 
    14711488    ensemble réside dans une simple <varname>restore_command</varname> 
    1472     utilisé sur le serveur en attente qui attend la disponibilité du prochain 
    1473     fichier WAL en provenance du serveur principal. 
    1474     <varname>restore_command</varname> est indiqué 
    1475     dans le fichier <filename>recovery.conf</filename> du serveur de secours. 
    1476     Le traitement usuel de la récupération attend un fichier dans l'archive 
    1477     WAL, indiquant une erreur si le fichier était indisponible. Dans le cas du serveur de 
    1478     secours, il est normal que le fichier suivant n'existe pas. Il ne reste donc 
     1489    utilisée sur le serveur de secours qui attend la disponibilité du 
     1490    prochain fichier WAL en provenance du serveur principal. 
     1491    <varname>restore_command</varname> est indiqué dans le fichier 
     1492    <filename>recovery.conf</filename> du serveur de secours. 
     1493    En fonctionnement normal, le processus de récupération attend un fichier 
     1494    dans l'archive WAL, remontant une erreur si le fichier est indisponible. 
     1495    Dans le cas du serveur de secours, il est normal que le fichier suivant 
     1496    n'existe pas. Il ne reste donc 
    14791497    qu'à attendre son arrivée. Une <varname>restore_command</varname> 
    1480     d'attente peut être obtenue par l'écriture d'un script personnalisé  
     1498    d'attente peut être obtenue par l'écriture d'un script personnalisé 
    14811499    qui boucle sur un test d'apparition du prochain fichier WAL. Il faut 
    14821500    également définir un moyen de déclencher la bascule 
    14831501    (<foreignphrase>failover</foreignphrase>), ce qui interrompt la 
    14841502    <varname>restore_command</varname>, sort de la boucle et retourne une 
    1485     erreur au serveur de secours indiquant que le fichier n'a pas été trouvé. 
    1486     Cela arrête alors la récupération et le serveur de secours deviend un serveur normal. 
    1487    </para> 
    1488  
    1489    <para> 
    1490     Voici un exemple de pseudocode pour <varname>restore_command</varname>&nbsp;: 
     1503    erreur au serveur de secours indiquant que le fichier n'a pas été 
     1504    trouvé. Cela arrête alors la récupération et le serveur de secours devient 
     1505    un serveur normal. 
     1506   </para> 
     1507    
     1508   <para> 
     1509    Un exemple de pseudocode de <varname>restore_command</varname> 
     1510    peut être&nbsp;: 
    14911511<programlisting>triggered = false; 
    14921512while (!NextWALFileReady() &amp;&amp; !triggered) 
    …… 
    15051525    qui permette d'identifier une panne du serveur principal et d'en 
    15061526    notifier le serveur de secours. De nombreux outils de ce type existent 
    1507     et sont bien intégrés à d'autres aspects requis pour un 
    1508     <foreignphrase>failover</foreignphrase> réussi comme la migration d'adresse 
    1509     IP. 
    1510    </para> 
    1511  
    1512    <para> 
    1513     Les moyens pour déclencher un <foreignphrase>failover</foreignphrase> sont 
    1514     une partie importante de la planification et de la conception. 
     1527    et sont bien intégrés à d'autres aspects nécessaires à la réussite du 
     1528    <foreignphrase>failover</foreignphrase>, comme la migration d'adresse IP. 
     1529   </para> 
     1530 
     1531   <para> 
     1532    Le déclenchement du <foreignphrase>failover</foreignphrase> est une partie 
     1533    importante de la planification et de la conception. 
    15151534    <varname>restore_command</varname> est 
    15161535    exécutée complètement pour chaque fichier WAL. Le processus 
    …… 
    15511570       située dans un répertoire du serveur de secours. S'assurer que les deux 
    15521571       paramètres <xref linkend="guc-archive-command"/> et 
    1553        <xref linkend="guc-archive-timeout"/> sont configurés de façon appropriés 
     1572       <xref linkend="guc-archive-timeout"/> sont correctement configurés 
    15541573       sur le serveur principal (voir <xref linkend="backup-archiving-wal"/>). 
    15551574      </para> 
    …… 
    15581577      <para> 
    15591578       Faire une sauvegarde des bases du serveur principal (voir <xref 
    1560        linkend="backup-base-backup"/>) et charger les données sur le serveur en 
    1561        attente. 
     1579       linkend="backup-base-backup"/>) et charger ces données sur le serveur 
     1580       de secours. 
    15621581      </para> 
    15631582     </listitem> 
    …… 
    16321651 
    16331652   <para> 
    1634     Une fois que le <foreignphrase>failover</foreignphrase> survient sur le 
     1653    Au moment où le <foreignphrase>failover</foreignphrase> est mis en place sur le 
    16351654    serveur se secours, un seul serveur est opérationnel. On parle alors 
    1636     d'état dégénéré. L'ancien serveur de secours est devenu serveur principal, 
    1637     l'ancien serveur principal est arrêté et peut le rester. Pour revenir aux 
    1638     opérations normales, il faut désormais recréer un serveur de secours, soit 
     1655    d'état dégénéré. L'ancien serveur de secours est 
     1656    devenu serveur principal, l'ancien serveur principal est arrêté 
     1657    et peut le rester. Il faut désormais recréer un serveur de secours, soit 
    16391658    sur l'ancien système principal, s'il peut redémarrer, soit sur un 
    16401659    troisième, de préférence nouveau, système. Lorsque cela est réalisé, on 
    1641     peut considérer que les deux serveurs ont échangé leurs rôles. Certains 
    1642     choisissent d'utiliser un troisième serveur pour fournir la sauvegarde vers 
    1643     le nouveau primaire jusqu'à ce que le nouveau serveur en attente ne soit 
    1644     recréé. Toutefois, cela complique assurément la configuration du système et 
    1645     les processus opérationnels. 
     1660    peut considérer que les deux serveurs ont échangé leurs rôles. 
     1661   </para> 
     1662   <para> 
     1663    Certains administrateurs choisissent d'utiliser un troisième serveur 
     1664    pour servir de sauvegarde au nouveau serveur principal le temps que le 
     1665    serveur de secours devienne opérationnel. Toutefois, cela complique 
     1666    assurément la configuration du système et les processus opérationnels. 
    16461667   </para> 
    16471668 
    …… 
    16511672    <foreignphrase>failover</foreignphrase>. Une bascule régulière 
    16521673    est encouragée car elle permet l'arrêt régulier de chaque système, 
    1653     pour la maintenance. Cela permet également de tester les mécanismes de 
     1674    arrêt nécessaire pour maintenir la haute-disponiblité. 
     1675    Cela permet également de tester les mécanismes de 
    16541676    <foreignphrase>failover</foreignphrase> pour s'assurer que cela 
    1655     fonctionnera toujours en cas de besoin. 
     1677    fonctionnera toujours en cas de besoin. Il est judicieux de rédiger ces 
     1678    procédures. 
    16561679   </para> 
    16571680  </sect2> 
    …… 
    16621685 
    16631686   <para> 
    1664     Les principales fonctionnalités du transfert de journaux 
    1665     (<foreignphrase>Log Shipping</foreignphrase>) accessibles 
    1666     dans cette version reposent sur le transfert d'après fichier 
    1667     (<foreignphrase>File-based Log Shipping</foreignphrase>) 
    1668     décrit ci -dessus. Le 
    1669     <foreignphrase>Record-based Log Shipping</foreignphrase> peut également 
    1670     être mis en place à l'aide de la fonction 
    1671     <function>pg_xlogfile_name_offset()</function> (voir 
    1672     <xref linkend="functions-admin"/>), mais cela nécessite un développement 
    1673     adapté. 
    1674    </para> 
    1675  
    1676    <para> 
    1677     Un programme externe peut appeler la fonction 
    1678     <function>pg_xlogfile_name_offset()</function> (voir <xref 
    1679     linkend="functions-admin"/>) pour trouver le nom du fichier et le décalage 
    1680     exact en octets de la fin actuelle du WAL. Ensuite, il peut accéder au 
    1681     fichier WAL directement et copier les données depuis la dernière fin 
    1682     connue du WAL jusqu'à la fin actuelle sur le(s) serveur(s) en attente. 
    1683     Avec cette approche, la fenêtre de données perdues correspond au cycle 
    1684     d'interrogation du programme de copie qui peut être vraiment très petit 
    1685     et il n'y a pas de perte de bande passante dû à l'archivage forcé de 
    1686     segments WAL partiellement utilisés. Notez que les scripts 
    1687     <varname>restore_command</varname> des serveurs en attente gèrent toujours 
    1688     les fichiers WAL complets, donc les données copiées de façon incrémentale 
    1689     ne sont pas rendues disponibles aux serveurs en attente. Elles sont 
    1690     seulement utilisées quand le primaire meurt &mdash; alors le dernier fichier 
    1691     WAL partiel est rempli sur le serveur en attente avant de lui permettre 
    1692     d'être disponible. Dans ce cas, une implémentation correcte de ce processus 
    1693     requiert une coopération du script <varname>restore_command</varname> avec 
    1694     le programme de copie des données. 
    1695     copying program. 
     1687    <productname>PostgreSQL</productname> supporte directement le transfert 
     1688    de journaux d'après fichiers (<foreignphrase>file-based 
     1689    log shipping</foreignphrase>) tel que décrit plus haut. Elle est 
     1690    également possible d'implanter le transfert de journaux d'après 
     1691    enregistrements, mais cela demande un développement adapté. 
     1692   </para> 
     1693 
     1694   <para> 
     1695    Un programme externe peut faire appel à la fonction  
     1696    <function>pg_xlogfile_name_offset()</function> (voir à ce propos 
     1697    <xref linkend="functions-admin">) pour trouver le nom du fichier et 
     1698    l'exact décalage en octet dans celui-ci de la fin actuelle du WAL. Il 
     1699    peut alors accéder directement au fichier WAL et copier les données 
     1700    depuis la dernière fin connue des WAL jusqu'à l'actuelle vers le(s) 
     1701    serveur(s) de secours. Par cette approche, la fenêtre de perte de 
     1702    données correspond au temps du cycle d'interrogation du programme 
     1703    de copie. Elle peut alors être très courte. Il n'y a, de plus, pas de 
     1704    surconsommation de la bande passante du fait de l'archivage de fichiers 
     1705    segment partiellement utilisés. Les scripts 
     1706    <varname>restore_command</varname> du serveur de secours continuent de 
     1707    traiter avec l'ensemble des fichiers WAL. De ce fait, les serveurs de 
     1708    secours ne peuvent pas, en fonctionnement normal, disposer des données 
     1709    copiées par incréments. Elles ne deviennent utilisables que lorsque le 
     1710    serveur principal subit une panne &mdash; le dernier fichier WAL partiel 
     1711    est alors chargé dans le serveur de secours avant qu'il puisse démarrer. 
     1712    Un codage correct de cette procédure nécessite une réelle coopération 
     1713    entre le script de <varname>restore_command</varname> et le programme de 
     1714    copie des donneés. 
    16961715   </para> 
    16971716  </sect2> 
    16981717 
    16991718  <sect2 id="backup-incremental-updated"> 
    1700    <title>Sauvegardes mises à jour de façon incrémentale</title> 
    1701  
    1702   <indexterm zone="backup"> 
    1703    <primary>sauvegardes mises à jour de façon incrémentale</primary> 
    1704   </indexterm> 
    1705  
    1706   <indexterm zone="backup"> 
    1707    <primary>accumulation de modifications</primary> 
    1708   </indexterm> 
    1709  
    1710    <para> 
    1711     Dans une configuration <foreignphrase>warm standby</foreignphrase>, il est 
    1712     possible de décharger les dépenses causées par les sauvegardes périodiques 
    1713     de base à partir du serveur primaire&nbsp;; à la place, des sauvegardes de 
    1714     base peuvent être réalisées en sauvegardant les fichiers du serveur en 
    1715     attente. Ce concept est généralement connu sous le nom de sauvegardes mises 
    1716     à jour de façon incrémentale, l'accumulation de modifications des journaux 
    1717     ou, plus simplement, l'accumulation de modifications. 
    1718    </para> 
    1719  
    1720    <para> 
    1721     Si nous prenons une sauvegarde des fichiers du serveur en attente pendant 
    1722     qu'il suit les journaux envoyés du primaire, nous serons capable de recharger 
    1723     les données et relancer le processus de récupération du serveur en attente à 
    1724     partir du dernier point de restauration. Nous n'avons plus besoin de 
    1725     conserver les fichiers WAL depuis le point de redémarrage. Si nous avons 
    1726     besoin de récupérer, il sera plus rapide de récupérer à partir de la 
    1727     sauvegarde mise à jour de façon incrémentale plutôt qu'à partir de la 
    1728     sauvegarde de base originale. 
    1729    </para> 
    1730  
    1731    <para> 
    1732     Comme le serveur en attente n'est pas <quote>en cours d'exécution</quote>, 
    1733     il n'est pas possible d'utiliser <function>pg_start_backup()</function> et 
     1719   <title>Sauvegardes incrémentales</title> 
     1720 
     1721  <indexterm zone="backup"> 
     1722   <primary>incrementally updated backups</primary> 
     1723  </indexterm> 
     1724 
     1725  <indexterm zone="backup"> 
     1726   <primary>sauvegarde incrémentale</primary> 
     1727  </indexterm> 
     1728 
     1729  <indexterm zone="backup"> 
     1730   <primary>accumulation des modifications</primary> 
     1731  </indexterm> 
     1732 
     1733<!-- Le terme accumulation des modifications ne me semble pas très heureux. 
     1734--> 
     1735   <para> 
     1736    Dans une configuration de reprise intermédiaire (<foreignphrase>warm 
     1737    standby</foreignphrase>), il est possible de décharger le serveur 
     1738    principal du coût des sauvegardes régulières des bases. Les sauvegardes 
     1739    des bases peuvent, pour cela, être effectuées en sauvegardant les fichiers 
     1740    d'un serveur de secours. Ce concept prend le nom de sauvegardes 
     1741    incrémentales, accumulation des journaux de modifications ou 
     1742    accumulation des modifications. 
     1743   </para> 
     1744 
     1745   <para> 
     1746    Si une sauvegarde des fichiers du serveur de secours est effectuée alors 
     1747    qu'il retrace les journaux transférés du serveur principal, il est 
     1748    possible de recharger ces données et de redémarrer le processus de 
     1749    restauration sur le serveur de secours à partir du dernier point de 
     1750    redémarrage. Il n'est alors plus nécessaire de conserver les fichiers 
     1751    WAL précédant le point de redémarrage. En cas de restauration, elle sera 
     1752    plus rapide à partir d'une sauvegarde incrémentale qu'à partir de la 
     1753    sauvegarde originale. 
     1754   </para> 
     1755 
     1756   <para> 
     1757    Puisque le serveur de secours n'est pas <quote>actif</quote>, il n'est 
     1758    pas possible d'utiliser <function>pg_start_backup()</function> et 
    17341759    <function>pg_stop_backup()</function> pour gérer le processus de 
    1735     sauvegarde&nbsp;; C'est à vous de déterminer combien de temps conserver les 
    1736     fichiers WAL pour avoir une sauvegarde récupérable. Vous pouvez le faire 
    1737     en exécutant <application>pg_controldata</application> sur le serveur en 
    1738     attente pour inspecter le fichier de contrôle et déterminer l'emplacement 
    1739     du point de vérification du WAL en cours. 
     1760    sauvegarde&nbsp;; c'est à l'utilisateur de déterminer depuis quand il 
     1761    doit conserver les fichiers de segment WAL pour avoir une sauvegarde 
     1762    récupérable. Cela peut se faire en exécutant 
     1763    <application>pg_controldata</application> sur le serveur de secours. 
     1764    Ce programme inspecte le fichier de contrôle pour déterminer 
     1765    l'emplacement du point de contrôle WAL actuel. 
    17401766   </para> 
    17411767  </sect2>