Changeset 962

Timestamp:

03/25/08 23:41:54 (10 months ago)

Author:

sas

Message:

Portage des modifications apportées à la branche 8.3

Files:

• traduc/branches/bv82x/manuel/backup.xml (modified) (33 diffs)

traduc/branches/bv82x/manuel/backup.xml

@@ -1 +1 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<!-- $Header: /var/lib/cvs/pgsql-fr/sgml/backup.sgml,v 1.17 2005/09/15 07:03:14 guillaume Exp $ -->
-70921, PG825
+80325, PG827
-<chapter id="backup">
- <title>Sauvegardes et restaurations</title>
@@ -220 +220 @@
-    volumineuses que la taille maximale d'un fichier sur le système de fichiers,
-    sauvegarder une telle table en fichier peut poser des problèmes. 
-Puisqu
+Comm
-    standard, les outils standard d'Unix peuvent être utiliser pour contourner
-    ce problème éventuel.
@@ -328 +328 @@
-      Quiconque s'est aventuré dans les détails de l'organisation de la 
-      base de données peut être tenté de ne sauvegarder et 
-de ne 
+
-      Cela ne fonctionne <emphasis>pas</emphasis> parce que les informations
-      contenues dans ces fichiers ne représentent que la moitité de la
@@ -347 +347 @@
-  <para>
-   Une autre approche à la sauvegarde du système de fichiers consiste à réaliser
-
+
+
-   pour cela que le système
-   de fichiers supporte cette fonctionnalité (et qu'il puisse lui être fait
-   confiance). La procédure typique consiste à réaliser une
-
+
+
-   ensuite de copier entièrement le répertoire de données (pas seulement
-   quelques parties,
-   voir ci-dessus) de l'image sur un périphérique de sauvegarde, puis de
-
+e
-   données est en cours d'exécution. Néanmoins, une telle sauvegarde
-   copie les fichiers de la base de données dans un état où le
-   serveur n'est pas correctement arrêté&nbsp;; du coup, au lancement du
-   serveur à partir des données sauvegardées, PostgreSQL peut penser que le
-ci
+
-   pas un problème, mais il faut en être conscient (et s'assurer d'inclure les
-   fichiers WAL dans la sauvegarde).
@@ -509 +511 @@
-    WAL de 16&nbsp;Mo chacun (en général, mais cette taille peut
-    être modifiée lors de la construction de <productname>PostgreSQL</productname>). Les
-de 
+
-    position dans la séquence abstraite des WAL. Lorsque le système n'utilise
-de 
- segment de
+
+
-    Un fichier segment dont le contenu précède le
-    dernier point de vérification est supposé inutile et peut être recyclé.
@@ -523 +525 @@
-    En fonction de l'application et du matériel disponible, 
-    <quote>sauvegarder les données ailleurs</quote> peut se faire de plusieurs
-de 
+
-    NFS monté sur une autre machine, être écrits sur une cartouche (après
-    s'être assuré qu'il existe un moyen d'identifier le nom d'origine de chaque
- à fait
+e
-    Pour fournir autant de flexibilité que possible à l'administrateur de la
-    base de données, <productname>PostgreSQL</productname> essaie de ne faire aucune
@@ -604 +606 @@
-    archivé tant que la cassette n'est pas changée. 
-    Toute erreur ou requête à un opérateur humain doit être rapportée de façon
-
+e
-    rapidement. Le répertoire <filename>pg_xlog/</filename> continue à se remplir
-    de fichiers de segment WAL jusqu'à la résolution de la situation.
@@ -767 +769 @@
-    alors que <varname>full_page_writes</varname> est désactivé, une perte de
-    performances entre <function>pg_start_backup</function> et
-
-<varname>full_page_writes</varname> est réellemen
+ l'activation du
+paramètre <varname>full_page_writes</varname> es
-    sauvegarde.) Il convient toutefois de s'assurer que ces étapes sont
-    effectuées séquentiellement, sans chevauchement. Dans le cas contraire, la
@@ -810 +812 @@
-    système de fichiers et des segments WAL utilisés
-    pendant celle-ci (comme précisé dans le fichier d'historique des sauvegardes) 
-sont archivés
+est archivée
-    tous les segments WAL archivés de noms numériquement plus
-    petits ne sont plus nécessaires à la récupération de la sauvegarde du
@@ -1030 +1032 @@
-
-   <para>
-découvre
+fait face à
-    elle se termine à ce point et le serveur ne démarre pas. Dans un tel cas,
-    le processus de récupération peut alors être ré-exécuté à partir du début
-vant le
+ntérieure au
-    récupération pour permettre à cette dernière de se terminer correctement.
-    Si la récupération échoue pour une raison externe (arrêt brutal du système
-    ou archive WAL devenue inaccessible), la récupération peut être
-pratique
+quasi
-    Le redémarrage de la restauration fonctionne comme les points de
-    contrôle du déroulement normal&nbsp;: le serveur force une écriture
-    régulière de son état sur les disques et actualise alors le fichier
-    <filename>pg_control</filename> pour indiquer que les données WAL déjà
-parcourues n'ont plus à être parcouru
+traitées n'ont plus à être parcourue
-   </para>
-
@@ -1052 +1054 @@
-      <filename>recovery.conf</filename> et s'appliquent uniquement pour la durée de la
-      récupération. Ils doivent être réinitialisés avant toute récupération
-une fois que la récupération a commencé
+après le démarrage de la récupération
-     </para>
-
@@ -1074 +1076 @@
-        Il est impératif que la commande ne renvoie un code de sortie zéro
-        que si, et seulement si, elle a réussi. Des noms de fichiers absents
-
+ à la commande
-        doit renvoyer une valeur différente de zéro dans ce cas.
-        Exemples&nbsp;:
@@ -1127 +1129 @@
-        ou juste avant (<literal>false</literal>). Il s'applique à
-        <xref linkend="recovery-target-time"/> et
- 
+
-        indiqué pour cette récupération. Il indique si les transactions
-possédant l'instant cible exact de validation ou l'ID cible
+d'instant ou ID cible de validation exact
-        sont incluses dans la récupération. La valeur par défaut est
-        <literal>true</literal>.
@@ -1146 +1148 @@
-        ligne temporelle en cours au moment de la sauvegarde. Ce paramètre
-        ne doit être configuré que
-dans 
+
-        il est nécessaire de retourner à un état postérieur à une récupération
-        d'instantané. Voir la <xref linkend="backup-timelines"/> pour plus
@@ -1174 +1176 @@
-    La possibilité de restaurer la base de données à partir d'un instantané
-    crée une complexité digne des histoires de science-fiction traitant
-
+
+
+
+
-    original de la base de données, une table critique a peut-être été
-
-
-
+
+
+
+
-    données, la table n'a jamais été supprimée. Or, l'utilisateur
-    réalise peu après que ce n'était pas une si grande idée et veut
@@ -1194 +1200 @@
-    <foreignphrase>timelines</foreignphrase>). À chaque fois qu'une restauration
-    d'archive est terminée, un nouveau timeline est créé pour identifier la
-généré
+produit
-    Le numéro d'identifiant de la timeline est inclus dans le
-    nom des fichiers de segment WAL. De ce fait, une nouvelle timeline
@@ -1275 +1281 @@
-     sont tracées dans les WAL avec le chemin absolu et sont donc rejouées
-     en tant que créations de <foreignphrase>tablespace</foreignphrase>
-c
-peut être indésirable si la trace
-C
+la n'est pas forcément souhaitable s
+le journal
+De plus, c
-     même machine, mais dans un répertoire différent&nbsp;: la ré-exécution surcharge
-     toujours le contenu du <foreignphrase>tablespace</foreignphrase> original.
@@ -1290 +1296 @@
-   <para>
-    Il faut de plus garder à l'esprit que le format actuel des
-difficile à gérer
+volumineux
-    de nombreuses images des pages disques. Ces images de page sont conçues
-. Il peut en effe
+, puisqu'il peu
-    être nécessaire de corriger des pages disque partiellement écrites.
-    En fonction du matériel et des logiciels composant le système, 
@@ -1301 +1307 @@
-    (lire les notes et avertissements dans <xref linkend="wal"/> avant
-    de le faire). Désactiver les images de page n'empêche pas l'utilisation des
-s
-s
+
+
-    inutiles de pages même si <varname>full_page_writes</varname> est actif. Entre
-    temps, les administrateurs peuvent souhaiter réduire le nombre
@@ -1366 +1372 @@
-  <para>
-   L'archivage continu peut être utilisé pour créer une configuration de cluster
-ou plusieurs
-s
+(ou plusieurs)
+(s)
-   opérations en cas de défaillance du serveur principal. Cette fonctionnalité
-   est surtout connue sous le nom de
@@ -1381 +1387 @@
-   les fichiers WAL du serveur primaire. Aucune modification des tables
-   de la base n'est requise pour activer cette capacité. Elle a de ce fait
-à
+avec
-   d'autres approches de réplication. Cette configuration a également un impact
-   relativement faible sur les performances du serveur principal.
@@ -1522 +1528 @@
-   <para>
-    <productname>PostgreSQL</productname> ne fournit pas de logiciel 
-
-
-
+
+
+
+
-    <foreignphrase>failover</foreignphrase>, comme la migration d'adresse IP.
-   </para>
@@ -1535 +1542 @@
-    exécutant <varname>restore_command</varname> est du coup créé et meurt
-    pour chaque fichier. Il n'y a, de ce fait, pas de démon ou de processus
-alors
+donc
-    gestionnaire de signal. Une notification plus permanente est requise pour
-    le déclenchement du <foreignphrase>failover</foreignphrase>. Il est
@@ -1545 +1552 @@
-    un <foreignphrase>failover</foreignphrase>. Un mécanisme de notification
-    tel que la création explicite d'un fichier déclencheur, quand cela est
-est moins source
+présente moins de risques
-   </para>
-  </sect2>
@@ -1559 +1566 @@
-     <listitem>
-      <para>
-
+
+
-       ce qui inclut deux copies identiques de <productname>PostgreSQL</productname>,
-       dans la même version.
@@ -1596 +1604 @@
-    copié sur une cassette en même temps qu'il est lu pour la
-    récupération. De ce fait, un serveur de secours 
-simultanément
-au stockage des fichiers à plus long terme en vue d'une récupération
-après un désastr
+en parallèle du
+stockage des fichiers en vue de besoins de reprise sur panne à plus long
+term
-   </para>
-
@@ -1604 +1612 @@
-    Pour les tests, il est possible d'exécuter le serveur principal
-    et celui de secours sur le même système. Cela n'apporte aucune amélioration
-sur
+à
-    de la haute disponibilité.
-   </para>
@@ -1653 +1661 @@
-    serveur de secours, un seul serveur est opérationnel. On parle alors
-    d'état dégénéré. L'ancien serveur de secours est
-
-
+mais 
+intégralement 
-    sur l'ancien système principal, s'il peut redémarrer, soit sur un
-, de préférence nouveau, système
+ système, de préférence nouveau
-    peut considérer que les deux serveurs ont échangé leurs rôles.
-   </para>
@@ -1663 +1671 @@
-    pour servir de sauvegarde au nouveau serveur principal le temps que le
-    serveur de secours devienne opérationnel. Toutefois, cela complique
-l
+d
-   </para>
-
@@ -1695 +1703 @@
-    <function>pg_xlogfile_name_offset()</function> (voir à ce propos la
-    <xref linkend="functions-admin"/>) pour trouver le nom du fichier et
-
+
+
-    peut alors accéder directement au fichier WAL et copier les données
-    depuis la dernière fin connue des WAL jusqu'à l'actuelle vers le(s)
@@ -1706 +1715 @@
-    traiter avec l'ensemble des fichiers WAL. De ce fait, les serveurs de
-    secours ne peuvent pas, en fonctionnement normal, disposer des données
-e deviennent utilisables
+'ont d'intérêt
-    serveur principal subit une panne &mdash; le dernier fichier WAL partiel
-    est alors chargé dans le serveur de secours avant qu'il puisse démarrer.
@@ -1748 +1757 @@
-    restauration sur le serveur de secours à partir du dernier point de
-    redémarrage. Il n'est alors plus nécessaire de conserver les fichiers
-
-
+
+
+
-    sauvegarde originale.
-   </para>
@@ -1801 +1811 @@
-   pour cela&nbsp;; les méthodes de
-   sauvegarde au niveau système de fichiers ne fonctionnent évidemment pas.
-sont automatiquement effectuées
+est automatiquement effectué
-   interdire l'utilisation d'un répertoire de données d'une version
-   incompatible. Il n'y a donc pas grand risque à lancer une mauvaise