Changeset 494

Show
Ignore:
Timestamp:
11/23/06 10:14:47 (2 years ago)
Author:
sas
Message:

Fin de relecture
fix #28
close #28

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/manuel/backup.xml

    r493 r494  
    14971497  </para> 
    14981498 
    1499 <!-- ICI --> 
    15001499  <sect2 id="warm-standby-planning"> 
    15011500   <title>Planification</title> 
    15021501 
    15031502   <para> 
    1504     Sur le serveur de secours, tous les espaces logiques et chemins référeront 
    1505     aux points de montage noméms de façon similaire. Il est donc important de 
    1506     créer les serveurs primaire et d'attente de façon identique, au moins 
    1507     en ce qui concerne le serveur de bases de données. De puis, tout commande 
    1508     CREATE TABLESPACE sera passée ainsi, donc tout nouveau point de montage 
    1509     doit être créé sur les deux serveurs avant de pouvoir être utilisé sur 
    1510     le serveur principal. Le matériel n'a pas besoin d'être identique mais 
    1511     l'expérience a montré que maintenir deux systèmes identiques est plus 
    1512     facile que maintenir deux systèmes différents sur la durée de vie 
    1513     des applications et du système. 
    1514    </para> 
    1515  
    1516    <para> 
    1517     Il n'existe pas de mode spécial requis pour activer un serveur d'attente. 
    1518     Les opérations qui surviennent sur les serveurs principal et d'attente 
    1519     sont entièrement des tâches d'archivage et de récupération continues. 
    1520     Le point principal de contacte entre les deux serveurs de base est 
     1503    Sur le serveur de secours, tous les espaces logiques et chemins font 
     1504    référence à des points de montage nommés de façon similaire. Il est donc important de 
     1505    créer des serveurs primaire et de secours les plus semblables possible, 
     1506    tout du moins en ce qui concerne la vision qu'en a le serveur de bases 
     1507    de données. De plus, tout commande 
     1508    <xref linkend="sql-createtablespace" endterm="sql-createtablespace-title"> 
     1509    est passée en l'état. Tout nouveau point de montage 
     1510    doit donc être créé sur les deux serveurs avant de pouvoir être utilisé sur 
     1511    le serveur principal. Il n'est pas nécessaire que le matériel soit 
     1512    identique, mais l'expérience montre qu'il est plus facile de maintenir 
     1513    deux systèmes identiques sur la durée de vie des applications et du système. 
     1514   </para> 
     1515 
     1516   <para> 
     1517    Il n'existe pas de mode spécial pour activer un serveur de secours. 
     1518    Les seules opérations sur les serveurs principal et de secours 
     1519    sont des tâches normales et continuelles d'archivage et de récupération. 
     1520    Le principal point de contact entre les deux serveurs est 
    15211521    l'archive des fichiers WAL qu'ils partagent&nbsp;: le principal les 
    1522     écrit, le serveur en attente les lit. Il faut aussi s'assurer que les 
     1522    écrit, le serveur de secours les lit. Il est impératif que des 
    15231523    archives WAL de serveurs différents ne soient pas mélangées. 
    15241524   </para> 
    15251525 
    15261526   <para> 
    1527     Ce qui fait que les deux serveurs faiblement liés travaillent ensemble 
    1528     est simplement un <varname>restore_command</varname> qui attend l'archivage 
    1529     du prochain fichier WAL à partir du serveur principal. 
     1527    La magie qui permet à deux serveurs faiblement liés de travailler 
     1528    ensemble réside dans une simple <varname>restore_command</varname> 
     1529    qui attend l'archivage du prochain fichier WAL en provenance  
     1530    du serveur principal. 
    15301531    <varname>restore_command</varname> est indiqué 
    1531     dans le fichier <filename>recovery.conf</filename> du serveur en attente. 
    1532     Le traitement de la récupération normale demandera un fichier sur le serveur 
    1533     en attente, occasionnant une erreur si le fichier n'est pas disponible. 
    1534     Pour le traitement du serveur en attente, il est normal que le prochain 
    1535     fichier soit indisponible, donc nous devons être patient et attendre 
    1536     son arrivée. Un restore_command en attente peut être écrit avec un 
    1537     script personnalisé qui attend l'arrivée du prochain fichier WAL. Il 
    1538     doit aussi y avoir un moyen pour déclencher le 
    1539     <foreignphrase>failover</foreignphrase>, ce qui interrompra le 
    1540     restore_command, cassera la boucle et renverra une erreur de fichier 
    1541     non trouvé sur le serveur en attente. Puis, cela arrêtera la 
    1542     récupération et le serveur en attente deviendra un serveur normal. 
     1532    dans le fichier <filename>recovery.conf</filename> du serveur de secours. 
     1533    Le traitement usuel de la récupération attend un fichier dans l'archive 
     1534    WAL, une erreur survenant s'il n'existe pas. Dans le cas du serveur de 
     1535    secours, il est normal que le fichier suivant n'existe pas. Il ne reste donc 
     1536    qu'à attendre son arrivée. Une <varname>restore_command</varname> 
     1537    d'attente peut être obtenue par l'écriture d'un script personnalisé  
     1538    qui boucle sur un test d'apparition du prochain fichier WAL. Il faut 
     1539    également définir un moyen de déclencher la bascule 
     1540    (<foreignphrase>failover</foreignphrase>), ce qui interrompt la 
     1541    <varname>restore_command</varname>, sort de la boucle et retourne une 
     1542    erreur au serveur de secours indiquant que le fichier n'a pas été trouvé. 
     1543    Cela arrête alors la récupération et le serveur de secours deviend un serveur normal. 
    15431544   </para> 
    15441545 
    15451546   <para> 
    15461547    Un exemple de code pour une version C de <varname>restore_command</varname> 
    1547     serait&nbsp;: 
     1548    peut être&nbsp;: 
    15481549<programlisting>triggered = false; 
    15491550while (!NextWALFileReady() &amp;&amp; !triggered) 
    …… 
    15591560 
    15601561   <para> 
    1561     <productname>PostgreSQL</productname> ne fournit pas de logiciel requis pour 
    1562     identifier un échec sur le serveur principal et pour notifier le serveur en 
    1563     attente. De nombreux outils de ce type existent et sont bien intégrés avec 
    1564     d'autres aspects dun système en <foreignphrase>failover</foreignphrase>, 
    1565     comme la migration d'une adresse IP. 
    1566    </para> 
    1567  
    1568    <para> 
    1569     Déclencher le <foreignphrase>failover</foreignphrase> est une partie 
    1570     importante de la planification et de la conception. <varname>restore_command</varname> est 
    1571     exécuté complètement une fois pour chaque fichier WAL. Le processus 
    1572     exécutant <varname>restore_command</varname> est du coup créé et meurt pour chaque fichier, 
    1573     donc il n'y a pas de démon ou de processus serveur. Du coup, nous ne 
    1574     pouvons pas utiliser les signaux et un gestionnaire de signal. Une 
    1575     notification plus permanente est requise pour déclencher l'opération 
    1576     de <foreignphrase>failover</foreignphrase>. Il est possible d'utiliser 
    1577     un simple délai, spécialement s'il est utilisé en conjonction avec un 
    1578     paramètre <varname>archive_timeout</varname> connu sur le principal. Ceci peut porter à erreur 
    1579     car un réseau ou un serveur principal occupé pourrait suffire à provoquer 
     1562    <productname>PostgreSQL</productname> ne fournit pas de logiciel  
     1563    qui permette d'identifier une panne du serveur principal et d'en 
     1564    notifier le serveur de secours. De nombreux outils de ce type existent 
     1565    et sont bien intégrés à d'autres aspects de 
     1566    <foreignphrase>failover</foreignphrase> de système, 
     1567    comme la migration d'adresse IP. 
     1568   </para> 
     1569 
     1570   <para> 
     1571    Le déclenchement du <foreignphrase>failover</foreignphrase> est une partie 
     1572    importante de la planification et de la conception. 
     1573    <varname>restore_command</varname> est 
     1574    exécutée complètement pour chaque fichier WAL. Le processus 
     1575    exécutant <varname>restore_command</varname> est du coup créé et meurt 
     1576    pour chaque fichier. Il n'y a, de ce fait, pas de démon ou de processus 
     1577    serveur. Il n'est alors pas possible d'utiliser les signaux et un 
     1578    gestionnaire de signal. Une notification plus permanente est requise pour 
     1579    le déclenchement du <foreignphrase>failover</foreignphrase>. Il est 
     1580    possible d'utiliser un simple dépassement de temps d'attente, 
     1581    spécialement en conjonction avec un paramètre 
     1582    <varname>archive_timeout</varname> défini sur le serveur principal et 
     1583    connu. Cela peut toutefois induire des erreurs, car le réseau ou 
     1584    l'occupation du serveur principal peuvent suffire à provoquer 
    15801585    un <foreignphrase>failover</foreignphrase>. Un mécanisme de notificaton 
    1581     comme la création explicite d'un fichier déclencheur est moins sujet à 
    1582     l'erreur si cela peut être arrangé. 
     1586    tel que la création explicite d'un fichier déclencheur, quand cela est 
     1587    possible, est moins source d'erreur. 
    15831588   </para> 
    15841589  </sect2> 
    15851590 
    15861591  <sect2 id="warm-standby-config"> 
    1587    <title>Implémentation</title> 
    1588  
    1589    <para> 
    1590     Une procédure courte pour configurer un serveur en attente suit. Pour 
    1591     des détails complets de chaque étape, référez-vous aux sections précédentes. 
     1592   <title>Mise en place</title> 
     1593 
     1594   <para> 
     1595    Une procédure courte de configuration d'un serveur de secours est 
     1596    indiquée dans la suite du document. Pour 
     1597    les détails complets de chaque étape, on peut se référer aux sections précédentes. 
    15921598    <orderedlist> 
    15931599     <listitem> 
    15941600      <para> 
    1595        Configurer les serveurs principal et d'attente de façon quasi identique, 
    1596        ceci incluant deux copies identiques de <productname>PostgreSQL</productname>, 
    1597        avec la même version. 
     1601       Configurer les serveurs principal et de secours de façon quasi identique, 
     1602       ce qui inclue deux copies identiques de <productname>PostgreSQL</productname>, 
     1603       dans la même version. 
    15981604      </para> 
    15991605     </listitem> 
    16001606     <listitem> 
    16011607      <para> 
    1602        Configurer l'archivage continue sur le principal vers une archive locale 
    1603        situé dansun répertoire sur le serveur d'attente. Assurez-vous que les deux 
    1604        paramètres <xref linkend="guc-archive-command"/> et <xref 
    1605        linkend="guc-archive-timeout"/> sont configurés (voir 
    1606        <xref linkend="backup-archiving-wal"/>) 
     1608       Configurer l'archivage continu sur le serveur principal vers une archive locale 
     1609       située dans un répertoire du serveur de secours. S'assurer que les deux 
     1610       paramètres <xref linkend="guc-archive-command"/> et 
     1611       <xref linkend="guc-archive-timeout"/> sont configurés (voir 
     1612       <xref linkend="backup-archiving-wal"/>). 
    16071613      </para> 
    16081614     </listitem> 
    16091615     <listitem> 
    16101616      <para> 
    1611        Faites une sauvegarde de base du serveur principal (voir <xref 
    1612        linkend="backup-base-backup"/>) 
     1617       Faire une sauvegarde des bases du serveur principal (voir <xref 
     1618       linkend="backup-base-backup"/>). 
    16131619      </para> 
    16141620     </listitem> 
    16151621     <listitem> 
    16161622      <para> 
    1617        Commencer la récupération sur le serveur en attente à partir de l'archive 
     1623       Commencer la récupération sur le serveur de secours à partir de l'archive 
    16181624       WAL locale en utilisant un fichier <filename>recovery.conf</filename> 
    1619        spécifiant un <varname>restore_command</varname> qui attend (voir 
     1625       qui utilise une <varname>restore_command</varname> d'attente (voir 
    16201626       <xref linkend="backup-pitr-recovery"/>). 
    16211627      </para> 
    …… 
    16251631 
    16261632   <para> 
    1627     La récupération traite l'archive WAL en lecture seule, donc une fois 
    1628     qu'un fichier WAL a été copié sur le système en attente, il peut être 
    1629     copié sur une cassette en même temps qu'il est utilisé par le système 
    1630     en attente pour la récupération. Du coup, exécuter un serveur en 
    1631     attente pour la haute disponibilité peut se réaliser au même temps 
    1632     que le stockage des fichiers à plus long terme en cas de récupération 
     1633    La récupération traite l'archive WAL en lecture seule. Ainsi, dès lors 
     1634    qu'un fichier WAL est copié sur le système de secours, il peut être 
     1635    copié sur une cassette en même temps qu'il est utilisé pour la 
     1636    récupération. De ce fait, un serveur de secours  
     1637    de haute disponibilité peut tourner simultanément 
     1638    au stockage des fichiers à plus long terme en vue d'une récupération 
    16331639    après un désastre. 
    16341640   </para> 
    16351641 
    16361642   <para> 
    1637     Dans un but de tests, il est possible d'exécuter les serveurs principal 
    1638     et d'attente sur le même système. Ceci ne fournit aucune amélioration 
    1639     sur la robustesse du système pas plus qu'il ne pourra être décrit comme 
     1643    Pour les tests, il est possible d'exécuter les serveurs principal 
     1644    et celui de secours sur le même système. Cela n'apporte aucune amélioration 
     1645    sur la robustesse du système, et ne peut pas être présenté comme 
    16401646    de la haute disponibilité. 
    16411647   </para> 
    …… 
    16431649 
    16441650  <sect2 id="warm-standby-failover"> 
    1645    <title>Failover</title> 
    1646  
    1647    <para> 
    1648     Si le serveur principal a un problème, le serveur de secours doit commencer 
     1651   <title>Bascule (<foreignphrase>Failover</foreignphrase>)</title> 
     1652 
     1653   <para> 
     1654    Si le serveur principal rencontre un problème, le serveur de secours doit commencer 
    16491655    la procédure de <foreignphrase>failover</foreignphrase>. 
    16501656   </para> 
    16511657 
    16521658   <para> 
    1653     Si le serveur en attente échoue, alors aucun <foreignphrase>failover</foreignphrase> 
    1654     n'a pas besoin de prendre place. Si le serveur en attente peut être 
    1655     redémarré, même quelques temps après, alors le processus de récupération 
    1656     peut aussi être immédiatement relancé en prenant avantage du 
    1657     <foreignphrase>Restartable Recovery</foreignphrase>. Si le serveur en 
    1658     attente ne peut être redémarré, alors un nouveau serveur en attente 
    1659     devra être créé. 
    1660    </para> 
    1661  
    1662    <para> 
    1663     Si le serveur principal échoue et est immédiatement redémarré, vous devez 
    1664     avoir un mécanisme l'informant qu'il n'est plus le serveur principal. Ceci 
    1665     est connu sous l'acronyme <acronym>STONITH</acronym> (<foreignphrase>Shoot 
    1666     the Other Node In The Head</foreignphrase>), qui est nécessaire pour éviter 
    1667     les situations où les deux systèmes pensent qu'ils sont le principal, ce 
    1668     qui peut amener une certaine confusion et des pertes de données. 
    1669    </para> 
    1670  
    1671    <para> 
    1672     Un grand nombre de systèmes <foreignphrase>failover</foreignphrase> 
    1673     utilisent simplement deux systèmes, le principal et celui en attente, 
    1674     connectés par un mécanisme appelé heartbeat pour vérifier la connexion 
    1675     entre les deux et la viabilité du principal. Il est aussi possible 
    1676     d'utiliser un troisième système appelé serveur témoin pour éviter 
    1677     des problèmes de <foreignphrase>failover</foreignphrase> inapproprié 
    1678     mais la complexité supplémentaire pourrait être inutile sauf s'ils 
    1679     sont configurés avec suffisamment d'attention et testés rigoureusement. 
    1680    </para> 
    1681  
    1682    <para> 
    1683     Au moment où le <foreignphrase>failover</foreignphrase> prend place sur le 
    1684     serveur en attente, nous avons seulement un serveur en opération. C'est 
    1685     connu sous le terme d'état dégénéré. L'ancien serveur en attente est 
    1686     devenu le serveur principal. L'ancien serveur principal est arrêté 
    1687     et pourrait le rester.  
    1688     Nous devons maintenant recréer un serveur en attente, soit sur l'ancien 
    1689     système principal soit sur un troisième système. Une fois terminé, 
    1690     nous pouvons considérer avoir changer de serveur principal et de 
    1691     serveur d'attente. Certaines personnes choisissent un troisième serveur 
    1692     pour fournir une protection supplémentaire au travers de l'interval du 
    1693     <foreignphrase>failover</foreignphrase> bien que cela complique à coup 
    1694     sûr la configuration du système et les processus opérationnelles 
    1695     (et il peut aussi agir en tant que serveur témoin). 
    1696    </para> 
    1697  
    1698    <para> 
    1699     Donc, basculer du principal ou serveur d'attente peut être rapide 
    1700     mais requiert du temps pour re-préparer le cluster en 
    1701     <foreignphrase>failover</foreignphrase>. Un basculement régulier entre 
    1702     le serveur principal et celui d'attente est encouragé bien que cela 
    1703     permette un arrêt habituel pour chaque système qui requiert un HA. 
    1704     Cela agit aussi en tant que test des mécanismes de 
     1659    Si le serveur de secours échoue, alors le  
     1660    <foreignphrase>failover</foreignphrase> n'est plus nécessaire. 
     1661    S'il peut être redémarré, même quelques temps après, alors le 
     1662    processus de récupération peut être immédiatement relancé en tirant 
     1663    parti de la restauration réactivable (<foreignphrase>Restartable 
     1664    Recovery</foreignphrase>). Enfin, s'il ne peut être redémarré, un 
     1665    nouveau serveur de secours doit être créé. 
     1666   </para> 
     1667 
     1668   <para> 
     1669    Si le serveur principal tombe et redémarre immédiatement, il faut 
     1670    disposer d'un mécanisme l'informant qu'il n'est plus le serveur 
     1671    principal. Ce mécanisme, connu sous l'acronyme <acronym>STONITH</acronym> 
     1672    (<foreignphrase>Shoot The Other Node In The Head</foreignphrase>), est 
     1673    permet d'éviter les situations où les deux systèmes pensent qu'ils sont 
     1674    le serveur principal, ce qui peut engendrer une certaine confusion et 
     1675    conduire à des pertes irrémédiables de données. 
     1676   </para> 
     1677 
     1678   <para> 
     1679    Un grand nombre de systèmes de <foreignphrase>failover</foreignphrase> 
     1680    utilisent simplement deux systèmes, le principal et celui de secours, 
     1681    connectés par un mécanisme appelé <quote>heartbeat</quote> qui vérifie 
     1682    en permanence la connectivité entre les deux systèmes et la viabilité 
     1683    du principal. Il est aussi possible d'utiliser un troisième système, 
     1684    appelé serveur témoin pour éviter tout problème de 
     1685    <foreignphrase>failover</foreignphrase> inapproprié. Cependant,  
     1686    la complexité supplémentaire peut s'avérer inutile sauf s'il 
     1687    est configuré avec une attention suffisante et des tests rigoureux. 
     1688   </para> 
     1689 
     1690   <para> 
     1691    Au moment où le <foreignphrase>failover</foreignphrase> est mis en place sur le 
     1692    serveur se secours, un seul serveur est opérationnel. On parle alors 
     1693    d'état dégénéré. L'ancien serveur de secours est 
     1694    devenu serveur principal, l'ancien serveur principal est arrêté 
     1695    et peut le rester. Il faut désormais recréer un serveur de secours, soit 
     1696    sur l'ancien système principal, s'il peut redémarrer, soit sur un 
     1697    troisième, de préférence nouveau, système. Lorsque cela est réalisé, on 
     1698    peut considérer que les deux serveurs ont échangé leurs rôles. 
     1699   </para> 
     1700   <para> 
     1701    Certains 
     1702    choisissent d'utiliser un troisième serveur pour fournir une protection 
     1703    supplémentaire lors de l'interval de 
     1704    <foreignphrase>failover</foreignphrase>. Il peut également servir de 
     1705    serveur témoin. Toutefois, cela complique 
     1706    assurément la configuration du système et les processus opérationnels. 
     1707   </para> 
     1708 
     1709   <para> 
     1710    La bascule entre le serveur principal et celui de secours peut être 
     1711    rapide, mais nécessite quelque temps pour repréparer le cluster de  
     1712    <foreignphrase>failover</foreignphrase>. Une bascule régulière 
     1713    est encouragée car elle permet l'arrêt régulier de chaque système, 
     1714    requis pour maintenir la haute-disponiblité. 
     1715    Cela permet également de tester les mécanismes de 
    17051716    <foreignphrase>failover</foreignphrase> pour s'assurer que cela 
    1706     fonctionnera toujours quand vous en aurez besoin. 
     1717    fonctionnera toujours en cas de besoin. 
    17071718   </para> 
    17081719  </sect2> 
    17091720 
    17101721  <sect2 id="warm-standby-record"> 
    1711    <title>Implémenter le <foreignphrase>Record-based Log Shipping</foreignphrase></title> 
    1712  
    1713    <para> 
    1714     Les principales fonctionnalités de <foreignphrase>Log Shipping</foreignphrase> 
    1715     dans cette version sont basées autour du <foreignphrase>Log Shipping</foreignphrase>. 
    1716     décrit ci -dessus. Ils est aussi possibles d'implémenter 
    1717     <foreignphrase>Log Shipping</foreignphrase> en utilisant la fonction 
    1718     <function>pg_xlogfile_name_offset()</function> (voir <xref 
    1719     linkend="functions-admin"/>), bien que ceci requiert un développement 
    1720     personnalisé. 
    1721    </para> 
    1722  
    1723    <para> 
    1724     Un programme externe peut appeler <function>pg_xlogfile_name_offset()</function> 
    1725     pour trouver le nom du fichier et le décalage en octets du dernier pointeur WAL. 
    1726     Si le programme externe demande régulièrement au serveur, il peut savoir. 
    1727     Si le programme externe interroge souvent le serveur, elle peut trouver 
    1728     comment le pointeur a été déplacé&nbsp;; ensuite, il peut accéder au 
    1729     fichier WAL et copie ces octets. Il peut accèder aux fichiers qui a une copie 
    1730     pas mis à jour) sur un serveur en attente. 
     1722   <title>Mise en place du transfert de journaux d'après les enregistrements 
     1723   (<foreignphrase>Record-based Log Shipping</foreignphrase>)</title> 
     1724 
     1725   <para> 
     1726    Les principales fonctionnalités du transfert de journaux 
     1727    (<foreignphrase>Log Shipping</foreignphrase>) accessibles 
     1728    dans cette version reposent sur le transfert d'après fichier 
     1729    (<foreignphrase>File-based Log Shipping</foreignphrase>) 
     1730    décrit ci -dessus. Le 
     1731    <foreignphrase>Record-based Log Shipping</foreignphrase> peut également 
     1732    être mis en place à l'aide de la fonction 
     1733    <function>pg_xlogfile_name_offset()</function> (voir 
     1734    <xref linkend="functions-admin"/>), mais cela nécessite un développement 
     1735    adapté. 
     1736   </para> 
     1737 
     1738   <para> 
     1739    <function>pg_xlogfile_name_offset()</function> peut être appelée par un 
     1740    programme externe pour trouver le nom du fichier et le décalage en octets 
     1741    au sein de ce fichier du dernier pointeur WAL. 
     1742    Si le programme externe interroge souvent le serveur, il peut trouver 
     1743    comment le pointeur a été déplacé. Il peut alors accéder directement au 
     1744    fichier WAL et transférer ces octets sur une copie moins récente en 
     1745    place sur le serveur de secours. 
    17311746   </para> 
    17321747  </sect2> 
    …… 
    17341749 
    17351750 <sect1 id="migration"> 
    1736   <title>Migration entre les différentes versions</title> 
     1751  <title>Migration entre versions</title> 
    17371752 
    17381753  <indexterm zone="migration"> 
    …… 
    17461761 
    17471762  <para> 
    1748    Cette section discute de la façon de migrer vos données de la base à partir 
    1749    d'une version de <productname>PostgreSQL</productname> vers une autre, plus récente. La 
    1750    procédure d'installation du logiciel <foreignphrase>per se</foreignphrase> n'est pas le 
    1751    sujet de cette section&nbsp;; ces détails sont dans le <xref 
    1752    linkend="installation"/>. 
    1753   </para> 
    1754  
    1755   <para> 
    1756    En règle générale, le format interne des données est modifié entre les  
    1757    différentes versions de <productname>PostgreSQL</productname> (quand le nombre après le 
    1758    deuxième point change). Ceci ne s'applique pas entre les différentes sorties 
    1759    mineures ayant le même numéro de version majeur (quand le nombre après le 
    1760    deuxième point change)&nbsp;; elles ont toujours un format de stockage 
    1761    compatible. 
     1763   Cette section discute de la façon de migrer les données de la base vers 
     1764   une version plus récente de <productname>PostgreSQL</productname>. 
     1765   Le sujet de cette section ne concerne pas la procédure d'installation 
     1766   <foreignphrase>per se</foreignphrase> du logiciel&nbsp;; ces détails sont 
     1767   dans le <xref linkend="installation"/>. 
     1768  </para> 
     1769 
     1770  <para> 
     1771   En règle générale, le format interne des données est sujet à modification d'une 
     1772   version majeure à l'autre (quand le nombre après le premier point change). 
     1773   Ce qui n'est pas le cas pour les versions mineures à l'intérieur d'une 
     1774   même version majeure (quand seul le nombre après le deuxième point change)&nbsp;; 
     1775   elles ont toujours un format de stockage compatible. 
    17621776   Par exemple, les versions 7.2.1, 7.3.2 et 7.4 ne sont pas compatibles, alors 
    1763    que les versions 7.2.1 et 7.2.2 le sont. Lorsque vous mettez à jour entre  
    1764    des versions compatibles, vous pouvez simplement remplacer les exécutables et 
    1765    ré-utiliser le répertoire des données sur le disque. Sinon, vous avez besoin 
    1766    de sauvegarder vos données et de les restaurer sur le nouveau serveur. Ceci 
    1767    doit se faire en utilisant <application>pg_dump</application>&nbsp;; les méthodes de 
    1768    sauvegarde au niveau système de fichiers ne fonctionneront évidemment pas. Il 
    1769    existe des vérifications en place pour vous empêcher d'utiliser un répertoire 
    1770    de données d'une version incompatible version de 
    1771    <productname>PostgreSQL</productname>, donc aucun mal ne sera fait si vous 
    1772    essayez de lancer un serveur d'une mauvaise version dans un répertoire de 
     1777   que les versions 7.2.1 et 7.2.2 le sont. Lorsque la mise à jour concerne 
     1778   des versions compatibles, les exécutables peuvent simplement être 
     1779   remplacés et le répertoire des données sur le disque réutilisé.  
     1780   Dans le cas contraire, il faut sauvegarder les données et les restaurer sur 
     1781   le nouveau serveur. <application>pg_dump</application> doit être utilisé 
     1782   pour cela&nbsp;; les méthodes de 
     1783   sauvegarde au niveau système de fichiers ne fonctionnent évidemment pas. 
     1784   Un certain nombre de vérifications sont automatiquement effectuées pour 
     1785   interdire l'utilisation d'un répertoire de données d'une version 
     1786   incompatible. Il n'y a donc pas grand risque à lancer une mauvaise 
     1787   version de <productname>PostgreSQL</productname> sur un répertoire de 
    17731788   données. 
    17741789  </para> 
    …… 
    17761791  <para> 
    17771792   Il est recommandé d'utiliser les programmes <application>pg_dump</application> et 
    1778    <application>pg_dumpall</application> à partir de la nouvelle version de 
    1779    <productname>PostgreSQL</productname>, pour utiliser les avantages de toutes 
    1780    améliorations effectuées sur ces programmes. Les versions actuelles des 
    1781    programmes de sauvegarde peuvent lire des données à partir des serveurs 
    1782    d'anciennes versions, jusqu'à la 7.0. 
    1783   </para> 
    1784  
    1785   <para> 
    1786    Vous minimiserez la durée d'indisponibilité en installant le nouveau serveur 
    1787    dans un répertoire différent et en lançant l'ancien et le nouveau serveur en  
    1788    parallèle sur des ports différents, puis en utilisant des commandes comme 
    1789   
     1793   <application>pg_dumpall</application> issus de la nouvelle version de 
     1794   <productname>PostgreSQL</productname>. Ceci permet de tirer parti 
     1795   des améliorations de ces programmes. Les versions actuelles des 
     1796   programmes de sauvegarde peuvent lire des données sur des serveurs 
     1797   de versions anciennes, jusqu'à la 7.0. 
     1798  </para> 
     1799 
     1800  <para> 
     1801   La durée d'indisponibilité est minimisée par l'installation de nouveau serveur 
     1802   dans un répertoire différent et par le lancement en parallèle des deux 
     1803   serveurs (ancien et nouveau), sur des ports différents. On peut alors 
     1804   utiliser une commande telle que  
     1805 
    17901806<programlisting>pg_dumpall -p 5432 | psql -d postgres -p 6543</programlisting> 
    17911807 
    1792    pour transférer les données. Ou utilisez un fichier intermédiaire si vous 
    1793    voulez. Vous pouvez alors éteindre le nouveau serveur et démarrer le nouveau 
    1794    sur le port que l'ancien utilisait. Vous devez vous assurer que l'ancienne 
    1795    base de données n'est pas modifiée après que vous ayez lancé  
    1796    <application>pg_dumpall</application>, sans quoi ces modifications seraient évidemment  
    1797    perdues. Référez vous au <xref linkend="client-authentication"/> pour savoir  
    1798    comment interdire l'accès. 
     1808   pour transférer les données. On peut aussi utiliser un fichier 
     1809   intermédiare. L'ancien serveur peut alors être éteint, et le nouveau 
     1810   démarré sur le port utilisé par l'ancien. Il est impératif que la base de 
     1811   données ne soit pas modifiée pendant l'exécution de  
     1812   <application>pg_dumpall</application>. Ces modifications seraient, sans 
     1813   cela, perdues. Le <xref linkend="client-authentication"/> informe sur la 
     1814   façon d'interdire l'accès. 
    17991815  </para> 
    18001816   
    18011817  <para> 
    1802    En pratique, vous voudrez certainement tester votre application sur le 
     1818   En pratique, on souhaite souvent tester son application sur le 
    18031819   nouveau serveur avant de basculer définitivement. C'est une autre raison 
    1804    pour configurer des installations concurrentes avec l'ancienne et la nouvelle 
    1805    version. 
    1806   </para> 
    1807  
    1808   <para> 
    1809    Si vous ne pouvez pas ou ne voulez pas lancer les deux serveurs en  
    1810    parallèle, vous pouvez faire l'étape de sauvegarde avant d'installer la  
    1811    nouvelle version, éteindre le serveur, déplacer l'ancienne version à un autre 
     1820   de configurer des installations concurrentes de l'ancienne et de la nouvelle 
     1821   versions. 
     1822  </para> 
     1823 
     1824  <para> 
     1825   Si n'est pas souhaité, ou pas possible, de lancer les deux serveurs en  
     1826   parallèle, il faut réaliser l'étape de sauvegarde avant d'installer la  
     1827   nouvelle version, éteindre le serveur, déplacer l'ancienne version vers un autre 
    18121828   endroit, installer la nouvelle, la démarrer et enfin restaurer les données. Par 
    18131829   exemple&nbsp;: 
    …… 
    18221838psql -f sauvegarde.sql postgres</programlisting> 
    18231839 
    1824    Vous trouverez les méthodes pour arrêter et démarrer les serveurs, ainsi que  
    1825    d'autres détails dans le <xref linkend="runtime"/>. 
    1826    Les instructions d'installation vous donneront des conseils sur les endroits  
     1840   Toutes les méthodes pour arrêter et démarrer les serveurs, ainsi que  
     1841   d'autres détails sont présentés dans le <xref linkend="runtime"/>. 
     1842   Les instructions d'installation donnent des conseils sur les endroits  
    18271843   stratégiques pour réaliser ces opérations. 
    18281844  </para> 
    …… 
    18301846  <note> 
    18311847   <para> 
    1832     Quand vous <quote>déplacez l'ancienne version à un autre endroit</quote>,  
    1833     l'ancienne installation pourrait ne plus être tout à fait utilisable. 
    1834     Certains des exécutables contiennent les chemins absolus vers les 
    1835     différents programmes et fichiers de données installés. Ceci n'est 
    1836     habituellement pas un gros problème mais si vous planifiez d'utiliser deux 
    1837     installations en parallèle pendant un moment, vous devez leur affecter des 
     1848    Lorsque <quote>l'ancienne installation est déplacée</quote>,  
     1849    il se peut qu'elle ne soit plus correctement utilisable. 
     1850    En effet, certains exécutables contiennent des chemins absolus vers les 
     1851    différents programmes et fichiers de données installés. Ce n'est 
     1852    habituellement pas un problème insurmontable, mais pour utiliser deux 
     1853    installations en parallèle pendant un moment, il faut leur affecter des 
    18381854    répertoires d'installation différents au moment de la construction. (Ce 
    1839     problème est rectifié pour <productname>PostgreSQL</productname> 8.0 et ultérieurs mais 
    1840     vous devez faire bien attention à déplacer les anciennes installations.) 
     1855    problème est rectifié pour <productname>PostgreSQL</productname> 8.0 et 
     1856    suivantes mais une attention particulière doit être portée au 
     1857    déplacement de versions plus anciennes.) 
    18411858   </para> 
    18421859  </note>