Changeset 492

Show
Ignore:
Timestamp:
11/21/06 13:58:53 (2 years ago)
Author:
sas
Message:

Standby -> de secours
Hot standby -> reprise immédiate
Warm standby -> reprise intermédiaire

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/manuel/backup.xml

    r491 r492  
    453453     Si la série de fichiers WAL est fournie en continu à une autre 
    454454     machine chargée avec le même fichier de sauvegarde de base, 
    455      on obtient un système <quote>en veille active</quote> 
     455     on obtient un système <quote>de reprise automatique</quote> 
    456456     (<foreignphrase>hot standby</foreignphrase>)&nbsp;: à tout 
    457457     moment, la deuxième machine peut être montée et disposer d'une copie 
    …… 
    967967   </para> 
    968968 
    969 <!-- ICI /home/sas/documentations/pg82/continuous-archiving.html --> 
    970969   <para> 
    971970    Il est important que la commande retourne un code de sortie différent de 
    …… 
    973972    <emphasis>seront</emphasis> demandés à la commande&nbsp;; elle doit 
    974973    renvoyer autre chose que 
    975     zéro dans ce cas. Ce n'est pas une condition d'erreur. Soyez conscient 
    976     que le nom de base du chemin <literal>%p</literal> sera différent de 
    977     <literal>%f</literal>&nbsp;; ne vous attendez pas à ce qu'ils soient 
    978     interchangeables. 
    979    </para> 
    980  
    981    <para> 
    982     Les segments WAL qui n'ont pas pu être trouvés dans l'archive seront 
     974    zéro dans ce cas. Ce n'est pas une condition d'erreur. Il faut également 
     975    garder à l'esprit que le nom de base du chemin <literal>%p</literal> 
     976    diffère de <literal>%f</literal>&nbsp;; il ne sont pas interchangeables. 
     977   </para> 
     978 
     979   <para> 
     980    Les segments WAL qui ne se trouvent pas dans l'archive sont 
    983981    recherchés dans <filename>pg_xlog/</filename>&nbsp;; cela autorise l'utilisation 
    984     des segments non archivés. Néanmoins, les segments disponibles à partir de 
    985     l'archive seront utilisés de préférence par rapport aux fichiers dans 
    986     <filename>pg_xlog/</filename>. Le système ne surchargera pas le contenu existant 
     982    de segments récents non archivés. Néanmoins, les segments disponibles 
     983    dans l'archive sont utilisés de préférence aux fichiers contenus dans 
     984    <filename>pg_xlog/</filename>. Le système ne surcharge pas le contenu 
    987985    de <filename>pg_xlog/</filename> lors de la récupération des fichiers archivés. 
    988986   </para> 
    989987 
    990988   <para> 
    991     Normalement, la récupération traitera tous les segments WAL disponibles, 
    992     restaurant du coup la base de données à cet instant (ou aussi proche que 
    993     nous le pouvons suivant les segments WAL disponibles). Mais, si vous 
    994     voulez récupérer à un instant particulier (disons, juste avant que 
    995     l'administrateur junior ait supprimé votre table principale de 
    996     transaction), spécifiez simplement le point d'arrêt requis dans 
    997     <filename>recovery.conf</filename>. Vous pouvez spécifier le point d'arrêt, connu 
    998     sous le nom de <quote>cible de récupération</quote>, soit par la date/heure 
    999     soit par l'ID de la dernière transaction. Au moment où nous écrivons ceci, 
    1000     seule l'option date/heure est tout à fait utilisable car il n'existe pas 
    1001     d'outils pour vous aider à identifier avec une certaine précision l'ID de 
    1002     transaction à utiliser. 
     989    Normalement, la récupération traite tous les segments WAL disponibles, 
     990    restaurant du coup la base de données à l'instant présent (ou aussi proche que 
     991    possible, en fonction des segments WAL disponibles). Mais, pour 
     992    récupérer à un instant particulier (disons, juste avant que 
     993    l'administrateur junior aie supprimé la table principale de 
     994    transaction), il suffit de spécifier le point d'arrêt voulu dans 
     995    <filename>recovery.conf</filename>. Ce point d'arrêt, connu 
     996    sous le nom de <quote>cible de récupération</quote> (ou 
     997    <foreignphrase>recovery target</foreignphrase>), peut être indiqué  
     998    soit à l'aide d'une date/heure, soit par l'ID de la dernière transaction. 
     999    Au moment de la rédaction de ce document, 
     1000    seule l'option date/heure est réellement utilisable car il n'existe pas 
     1001    d'outils permettant d'identifier précisément l'ID de transaction à utiliser. 
    10031002   </para> 
    10041003 
    10051004   <note> 
    10061005     <para> 
    1007       Le point d'arrêt doit se situer après l'heure de fin de la sauvegarde 
    1008       de base (le moment de <function>pg_stop_backup</function>). Vous ne pouvez pas 
    1009       utiliser une sauvegarde de base pour récupérer à un tel instant où la 
    1010       sauvegarde était encore en cours (pour récupérer jusqu'à cet instant, 
    1011       vous devez récupérer votre sauvegarde de base précédente et recommencer 
    1012       à partir de là). 
     1006      Le point d'arrêt doit être postérieur à la fin de la sauvegarde 
     1007      de la base (le moment où <function>pg_stop_backup</function> a été 
     1008      exécuté). Une sauvegarde ne peut pas être utilisée pour repartir d'un 
     1009      instant où elle était encore en cours (pour ce faire, 
     1010      il faut récupérer la sauvegarde précédente et rejouer à partir de là). 
    10131011     </para> 
    10141012    </note> 
    10151013 
    10161014   <para> 
    1017     Si la récupération découvre une corruption dans les données WAL, 
    1018     elle se termine à ce point et le serveur ne se lancera pas. Le processus 
    1019     de récupération pourra être ré-exécuté à partir du début en précisant un 
    1020     <quote>recovery target</quote> de façon à ce que la récupération puisse 
    1021     se terminer normalement. Si la récupération échoue pour une raison 
    1022     externe comme un arrêt brutal du système ou que l'archive WAL devient 
    1023     inaccessible, alors la récupération peut être simplement relancée 
    1024     et elle redémarrera pratiquement là où elle a échoué. La récupération 
    1025     relançable fonctionne en écrivant un enregistrement restartpoint dans le 
    1026     fichier de contrôle au premier enregistrement d'un point de contrôle 
    1027     trouvé après <varname>checkpoint_timeout</varname> secondes. 
     1015    Si la récupération découvre une corruption des données WAL, 
     1016    elle se termine à ce point et le serveur ne démarre pas. Le processus 
     1017    de récupération peut alors être ré-exécuté à partir du début en 
     1018    précisant une <quote>cible de récupération</quote> pour permettre à la 
     1019    récupération de se terminer correctement. Si la récupération échoue pour une raison 
     1020    externe (arrêt brutal du système ou archive WAL devenue 
     1021    inaccessible), alors la récupération peut être simplement relancée. 
     1022    Elle redémarre alors pratiquement là où elle a échoué. La récupération 
     1023    peut être redémarrée parce qu'elle enregistre un point de redémarrage dans le 
     1024    fichier de contrôle au niveau du premier enregistrement d'un point de contrôle 
     1025    utilisable trouvé après <varname>checkpoint_timeout</varname> secondes. 
    10281026   </para> 
    10291027 
    …… 
    10321030 
    10331031     <para> 
    1034       Ces configurations peuvent seulement être placées dans le fichier 
    1035       <filename>recovery.conf</filename> et s'appliquent seulement pour la durée de la 
    1036       récupération. Ils doivent être réinitialisés pour toute récupération 
    1037       ultérieure que vous souhaitez réaliser. Ils ne peuvent pas être modifiés 
    1038       une fois que la récupération a commencé. 
     1032      Ces paramètres de configuration ne peuvent être placées que dans le fichier 
     1033      <filename>recovery.conf</filename> et s'appliquent uniquement pour la durée de la 
     1034      récupération. Ils doivent être réinitialisés avant toute récupération 
     1035      ultérieure. Ils ne peuvent pas être modifiés une fois que la récupération a commencé. 
    10391036     </para> 
    10401037 
    …… 
    10481045        série de fichiers WAL. Ce paramètre est requis. Tout <literal>%f</literal> 
    10491046        dans la chaîne est remplacé par le nom du fichier à récupérer à 
    1050         partir de l'archive et tout <literal>%p</literal> est remplacé par le 
    1051         chemin pour le copier sur le serveur. (Le nom du chemin est relatif au 
     1047        partir de l'archive. Tout <literal>%p</literal> est remplacé par le 
     1048        chemin vers le répertoire de copie sur le serveur. (Le nom du chemin est 
     1049        relatif au 
    10521050        répertoire de travail du serveur, c'est-à-dire le répertoire des données 
    1053         du cluster.) Écrivez <literal>%%</literal> pour embarquer un vrai 
     1051        du cluster.) <literal>%%</literal> est utilisé pour écrire le 
    10541052        caractère <literal>%</literal> dans la commande. 
    10551053       </para> 
    10561054       <para> 
    1057         Il est important que la commande renvoie un code de sortie zéro si et 
    1058         seulement si elle a réussi. La commande <emphasis>se verra 
    1059         demander</emphasis> les noms des fichiers absents dans l'archive&nbsp;; elle 
     1055        Il est impératif que la commande ne renvoie un code de sortie zéro 
     1056        que si, et seulement si, elle a réussi. Des noms de fichiers absents 
     1057       de l'archive <emphasis>seront demandés</emphasis>&nbsp;; elle 
    10601058        doit renvoyer une valeur différente de zéro dans ce cas. 
    10611059        Exemples&nbsp;: 
    …… 
    10671065 
    10681066     <varlistentry id="recovery-target-time" xreflabel="recovery_target_time"> 
    1069       <term><varname>recovery_target_time</varname>  
    1070            (<type>timestamp</type>) 
     1067      <term><varname>recovery_target_time</varname> (<type>timestamp</type>) 
    10711068      </term> 
    10721069      <listitem> 
    10731070       <para> 
    1074         Ce paramètre spécifie le temps à partir duquel le serveur doit 
    1075         arrêter la récupération. Au plus un entre 
    1076         <varname>recovery_target_time</varname> et <xref 
    1077         linkend="recovery-target-xid"/> peut être spécifié. Par défaut, la 
    1078         récupération se passe jusqu'à la fin du journal WAL. Le point 
    1079         d'arrêt précis est aussi influencé par <xref 
    1080         linkend="recovery-target-inclusive"/>. 
     1071        Ce paramètre indique l'estampille temporelle au-delà de laquelle 
     1072        la récupération s'arrête. Au plus un des deux paramètres 
     1073        <varname>recovery_target_time</varname> et 
     1074       <xref linkend="recovery-target-xid"/> peut être précisé. Par défaut, la 
     1075        récupération court jusqu'à la fin du journal WAL. Le point 
     1076        d'arrêt précis est aussi influencé par 
     1077       <xref linkend="recovery-target-inclusive"/>. 
    10811078       </para> 
    10821079      </listitem> 
    …… 
    10871084      <listitem> 
    10881085       <para> 
    1089         Ce paramètre spécifie l'ID de transaction où arrêter la récupération. 
    1090         Gardez en tête qu'alors que les ID de transactions sont affectés 
     1086        Ce paramètre précise l'ID de la transaction à laquelle arrêter la récupération. 
     1087        Alors que les ID de transactions sont affectés 
    10911088        séquentiellement au début de la transaction, les transactions peuvent 
    10921089        se terminer dans un ordre numérique différent. Les transactions qui 
    1093         seront récupérées sont celles qui ont été validées avant celle 
    1094         spécifiée (et quelque fois en l'incluant). Au plus un entre 
    1095         <varname>recovery_target_xid</varname> et <xref 
    1096         linkend="recovery-target-time"/> peut être spécifié. La valeur par 
    1097         défaut est de récupérer jusqu'à la fin du journal WAL. Le point 
     1090        sont récupérées sont celles qui ont été validées avant celle 
     1091        indiquée (quelques fois en l'incluant). Au plus un des deux 
     1092        paramètres <varname>recovery_target_xid</varname> et 
     1093       <xref linkend="recovery-target-time"/> peut être indiqué. Par 
     1094        défaut, la récupération court jusqu'à la fin du journal WAL. Le point 
    10981095        d'arrêt précis est aussi influencé par 
    10991096        <xref linkend="recovery-target-inclusive"/>. 
    …… 
    11021099     </varlistentry> 
    11031100 
    1104      <varlistentry id="recovery-target-inclusive"  
    1105                    xreflabel="recovery_target_inclusive"> 
    1106       <term><varname>recovery_target_inclusive</varname>  
    1107         (<type>boolean</type>) 
     1101     <varlistentry id="recovery-target-inclusive" xreflabel="recovery_target_inclusive"> 
     1102      <term><varname>recovery_target_inclusive</varname> (<type>boolean</type>) 
    11081103      </term> 
    11091104      <listitem> 
    11101105       <para> 
    1111         Spécifie si nous stoppons tout de suite après la cible de 
    1112         récupération spécifiée (<literal>true</literal>) ou tout juste avant 
    1113         (<literal>false</literal>). S'applique à <xref 
    1114         linkend="recovery-target-time"/> et <xref 
    1115         linkend="recovery-target-xid"/>, quelque soit celui qui est spécifié 
    1116         pour cette récupération. Ceci indique si les transactions ayant 
    1117         exactement l'instant de validation cible ou l'ID, respectivement, 
    1118         seront inclus dans la récupération. La valeur par défaut est 
     1106        Ce paramètre indique si la récupération doit s'arrêter immédiatement 
     1107        après la cible de récupération précisée (<literal>true</literal>) 
     1108        ou juste avant (<literal>false</literal>). Il s'applique à 
     1109        <xref linkend="recovery-target-time"/> et 
     1110        <xref linkend="recovery-target-xid"/>, en fonction de  celui qui est 
     1111        indiqué pour cette récupération. Il indique si les transactions 
     1112       possédant l'instant cible exact de validation ou l'ID cible, respectivement, 
     1113        sont incluses dans la récupération. La valeur par défaut est 
    11191114        <literal>true</literal>. 
    11201115       </para> 
    …… 
    11221117     </varlistentry> 
    11231118 
    1124      <varlistentry id="recovery-target-timeline"  
    1125                    xreflabel="recovery_target_timeline"> 
    1126       <term><varname>recovery_target_timeline</varname>  
    1127         (<type>string</type>) 
     1119     <varlistentry id="recovery-target-timeline" xreflabel="recovery_target_timeline"> 
     1120      <term><varname>recovery_target_timeline</varname> (<type>string</type>) 
    11281121      </term> 
    11291122      <listitem> 
    11301123       <para> 
    1131         Spécifie la récupération à un timeline particulier. La valeur par 
    1132         défaut est de récupérer suivant le timeline en cours au moment où la 
    1133         sauvegarde de base a été effectuée. Vous aurez seulement besoin de 
    1134         configurer ce paramètre dans les situations complexes de récupération 
    1135         où le besoin de retourner à un état qui a été atteint après une 
    1136         récupération à un temps donné. Voir la <xref 
    1137         linkend="backup-timelines"/> pour des informations. 
     1124        Ce paramètre précise la ligne temporelle  
     1125        (<foreignphrase>timeline</foreignphrase>) à utiliser pour la 
     1126        récupération. Par défaut, la récupération s'effectue en utilisant la 
     1127        ligne temporelle en cours au moment de la sauvegarde. Ce paramètre 
     1128        ne doit être configuré que 
     1129        dans pour les situations de récupération complexes, dans lesquelles 
     1130        il est nécessaire de retourner à un état postérieur à une récupération 
     1131        d'instantané. Voir la <xref linkend="backup-timelines"/> pour plus 
     1132        d'informations. 
    11381133       </para> 
    11391134      </listitem> 
    …… 
    11471142 
    11481143  <sect2 id="backup-timelines"> 
    1149    <title>Timelines</title> 
     1144   <title>Lignes temporelles (<foreignphrase>Timelines</foreignphrase>)</title> 
    11501145 
    11511146  <indexterm zone="backup"> 
    …… 
    11531148  </indexterm> 
    11541149 
    1155    <para> 
    1156     La possibilité de restaurer la base de données à un instant précédent 
    1157     crée une complexité qui sont la base des histoires de science-fiction sur 
    1158     le voyage dans le temps et les univers parallèles. Dans l'historique 
    1159     original de la base de données, vous avez peut-être supprimé une table 
    1160     critique à 17h15 mardi soir. Imperturbable, vous récupérez votre 
    1161     sauvegarde, la restaurez jusqu'à 17h14 mardi soir et êtes de nouveau 
     1150  <indexterm zone="backup"> 
     1151   <primary>ligne temporelle</primary> 
     1152  </indexterm> 
     1153 
     1154   <para> 
     1155    La possibilité de restaurer la base de données à partir d'un instantané 
     1156    crée une complexité digne des histoires de science-fiction traitant 
     1157    du voyage dans le temps et des univers parallèles. Dans l'historique 
     1158    original de la base de données, une table critique a peut-être été 
     1159    supprimée à 17h15 mardi soir. Sans stress, la sauvegarde est récupérée 
     1160    et restaurée jusqu'à 17h14 mardi soir. Tout est de nouveau 
    11621161    fonctionnel. Dans <emphasis>cette</emphasis> histoire de l'univers de la base de 
    1163     données, vous n'avez jamais supprimé la table. Mais, supposez que vous 
    1164     réalisez plus tard qu'après tout, ce n'était pas une si grande idée et 
    1165     que vous voudriez revenir à un point plus lointain dans l'historique 
    1166     original. Vous ne serez plus capable de le faire si, une fois que votre 
    1167     base de donnée était de nouveau fonctionnelle, elle a écrit par dessus 
    1168     certaines des séquences de fichiers segments WAL qui vous aurait permis 
    1169     de récupérer à cet instant. Donc, vous voulez réellement distinguer les 
    1170     séries d'enregistrements WAL générées après la récupération à un instant 
    1171     donné de celles générées dans l'historique originale de la base de 
    1172     données. 
    1173    </para> 
    1174  
    1175    <para> 
    1176     Pour gérer ces problèmes, <productname>PostgreSQL</productname> comprends la notion 
    1177     de <firstterm>timelines</firstterm>. Chaque fois que vous récupérez à un certain 
    1178     instant précédant la fin de la séquence WAL, un nouveau timeline est 
    1179     créé pour identifier les séries d'enregistrements WAL générées après la 
    1180     récupération (néanmoins, si la récupération continue jusqu'à la fin des 
    1181     WAL, nous ne commençons pas une nouvelle timeline&nbsp;: nous étendons 
    1182     celle qui existe). Le numéro d'identifiant de la timeline fait partie  
    1183     des noms des fichiers segment WAL et, du coup, une nouvelle timeline 
    1184     ne réécrit pas sur les données générées par des timelines précédentes. 
     1162    données, la table n'a jamais été supprimée. Or, l'utilisateur 
     1163    réalise peu après que ce n'était pas une si grande idée et veut 
     1164    revenir à un point ultérieur de l'historique. Cela n'est pas possible, 
     1165    si, alors que la base de données est à nouveau fonctionnelle, elle 
     1166    réutilise certaines séquences de fichiers WAL qui permettent de 
     1167    retourner à ce point. Il est donc nécessaire de pouvoir distinguer les 
     1168    séries d'enregistrements WAL engendrées après la récupération de 
     1169    l'instantané de celles issues de l'historique originel de la base. 
     1170   </para> 
     1171 
     1172   <para> 
     1173    Pour gérer ces difficultés, <productname>PostgreSQL</productname> inclut 
     1174    la notion de <firstterm>lignes temporelles</firstterm> (ou 
     1175    <foreignphrase>timelines</foreignphrase>). Chaque fois qu'une 
     1176    restauration d'un instantané antérieur à la fin de la séquence WAL est 
     1177    exécutée, une nouvelle timeline est créée pour identifier les séries 
     1178    d'enregistrements WAL consécutives à la 
     1179    récupération (toutefois, si la récupération s'effectue sur la totalité 
     1180    des WAL, il n'y a pas de nouvelle timeline&nbsp;: celle existant est 
     1181    étendue). Le numéro d'identifiant de la timeline est inclus dans le 
     1182    nom des fichiers de segment WAL. De ce fait, une nouvelle timeline 
     1183    ne réécrit pas sur les données engendrées par des timelines précédentes. 
    11851184    En fait, il est possible d'archiver plusieurs timelines différentes. 
    1186     Bien que cela semble être une fonctionnalité inutile, parfois, cela vous 
    1187     sauve la vie. Considérez la situation où vous n'êtes plus sûr de l'instant 
    1188     jusqu'où récupérer. Du coup, vous devez tester des récupérations à 
    1189     différents instants jusqu'à trouver le meilleur moment dans l'ancien 
    1190     historique. Sans les timelines, ce processus génèrerait un incroyable 
    1191     bazar. Avec les timelines, vous pouvez récupérer à <emphasis>n'importe 
    1192     quel</emphasis> état précédent, ceci incluant les états dans les branches de 
    1193     timelines que vous abandonnerez plus tard. 
     1185    Bien que cela semble être une fonctionnalité inutile, cela peut parfois 
     1186    sauver des vies. Dans une situation où l'instantané à récupérer n'est 
     1187    pas connu avec certitude, il va falloir tester les récupérations de 
     1188    différents instantanés jusqu'à trouver le meilleur. 
     1189    Sans les timelines, ce processus engendre vite un bazar ingérable.  
     1190    Avec les timelines, il est possible de récupérer 
     1191    <emphasis>n'importe quel</emphasis> état précédent, même les états de 
     1192    branches temporelles abandonnées. 
    11941193   </para> 
    11951194 
    11961195   <para> 
    11971196    Chaque fois qu'une nouvelle timeline est créée, 
    1198     <productname>PostgreSQL</productname> crée un fichier d'<quote>historique des 
    1199     timeline</quote> qui montre les timelines, leur branchement et le moment 
    1200     auquel c'est arrivé. Ces fichiers historiques sont requis pour permettre 
    1201     au système de récupérer les bons fichiers segment WAL lors de la 
    1202     récupération à partir d'une archive contenant plusieurs timelines. Du 
    1203     coup, elles sont archivées dans l'aire des WAL comme tous les fichiers 
    1204     segment WAL. Les fichiers historiques sont de simples fichiers texte, 
    1205     donc il est peu coûteux et approprié de les conserver indéfiniment 
    1206     (contrairement aux fichiers segments qui sont gros). Vous pouvez, si 
    1207     vous le souhaitez, ajouter des commentaires au fichier historique pour 
    1208     ajouter vos propres notes sur comment et pourquoi cette timeline 
    1209     est particulièrement intéressante. De tels commentaires seront 
    1210     particulièrement utiles quand vous avez un ticket des différentes 
    1211     timelines comme résultat de l'expérimentation. 
    1212    </para> 
    1213  
    1214    <para> 
    1215     Le comportement par défaut de la récupération est de récupérer parmi la 
    1216     timeline en cours au moment où la sauvegarde de base a été effectuée. Si 
    1217     vous voulez récupérer à une timeline enfant (c'est-à-dire si vous voulez 
    1218     retourner à un état qui a été enregistré après la tentative de 
    1219     récupération), vous avez besoin de spécifier l'ID cible de la timeline 
    1220     dans <filename>recovery.conf</filename>. Vous ne pouvez pas récupérer des 
    1221     timelines qui ont effectué leur branchement plus tôt que le moment où 
    1222     a été effectuée la sauvegarde de base. 
     1197    <productname>PostgreSQL</productname> crée un fichier 
     1198    d'<quote>historique des timelines</quote> qui indique à quelle timeline 
     1199    il est attaché, et depuis quand. Ces fichiers d'historique sont 
     1200    nécessaires pour permettre au système de choisir les bons fichiers de 
     1201    segment WAL lors de la récupération à partir d'une archive qui contient 
     1202    plusieurs timelines. Ils sont donc archivés comme tout fichier 
     1203    de segment WAL. Puisque ce sont de simples fichiers texte, 
     1204    il est peu coûteux et même judicieux de les conserver indéfiniment 
     1205    (contrairement aux fichiers de segment, volumineux). Il est possible 
     1206    d'ajouter des commentaires au fichier d'historique expliquant  
     1207    comment et pourquoi cette timeline a été créée. De tels commentaires 
     1208    s'avèrent précieux lorsque l'expérimentation conduit à de nombreuses 
     1209    timelines. 
     1210   </para> 
     1211 
     1212   <para> 
     1213    Par défaut, la récupération s'effectue sur la timeline en vigueur au 
     1214    cours de la la sauvegarde. Si l'on souhaite effectuer la récupération 
     1215    dans une timeline fille (c'est-à-dire retourner à un état enregistré 
     1216    après une tentative de récupération), il faut préciser l'identifiant de la timeline 
     1217    dans <filename>recovery.conf</filename>. Il n'est pas possible de 
     1218    récupérer dans des timelines antérieures à la sauvegarde. 
    12231219   </para> 
    12241220  </sect2> 
    12251221 
    12261222  <sect2 id="backup-incremental-updated"> 
    1227    <title>Sauvegardes mises à jour par incrément</title> 
    1228  
    1229   <indexterm zone="backup"> 
    1230    <primary>sauvegardes mises à jour par incrément</primary> 
     1223   <title>Sauvegardes actualisées par incrément</title> 
     1224 
     1225  <indexterm zone="backup"> 
     1226   <primary>sauvegardes actualisées par incrément</primary> 
     1227  </indexterm> 
     1228 
     1229  <indexterm zone="backup"> 
     1230   <primary>sauvegardes incrémentales</primary> 
    12311231  </indexterm> 
    12321232 
    …… 
    12361236 
    12371237   <para> 
    1238     La récupération après redémarrage peut aussi être utilisée pour décharger 
    1239     le serveur principal de la réalisation de sauvegardes de base périodiques. 
    1240     Le sauvegarde se fait sur le serveur d'attente. Ce concept est aussi connu 
    1241     sous le nom de sauvegardes mises à jour par incrément 
    1242     (<foreignphrase>incrementally updated backups</foreignphrase>, ou 
    1243     <foreignphrase>log change accumulation</foreignphrase> ou plus simplement 
    1244     <foreignphrase>change accumulation</foreignphrase>). 
    1245    </para> 
    1246  
    1247    <para> 
    1248     Si nous réalisons une sauvegarde des fichiers du serveur alors qu'une 
    1249     récupération est en cours, nous serons capable de relancer la récupération 
    1250     à partir du dernier point de redémarrage. Maintenant, cette sauvegarde 
    1251     a certaines modifications des fichiers d'archive WAL précédents, donc 
    1252     cette version est une version mise à jour de la sauvegarde de base 
    1253     originale. Si nous avons besoin de la récupérer, il sera plus rapide de le 
    1254     faire à partir de la sauvegarde mise à jour par incrément que par celle de 
    1255     la sauvegarde de base. 
    1256    </para> 
    1257  
    1258    <para> 
    1259     Pour utiliser cette possibilité, vous aurez besoin de configurer une base 
    1260     en attente sur un deuxième système comme décrit dans 
    1261     <xref linkend="warm-standby"/>. En réalisant une sauvegarde du serveur en 
    1262     attente alors qu'il est en cours d'exécution, vous aurez construit une 
    1263     sauvegarde mise à jour par incrément. Une fois ceci fait, vous n'aurez plus 
    1264     besoin de réaliser des sauvegardes de base régulièrement à partir du serveur 
    1265     principal&nbsp;: toutes les sauvegardes de base peuvent se faire sur le 
    1266     serveur en attente. Si vous souhaitez le faire, il n'est pas nécessaire 
    1267     d'implémenter les fonctionnalités de <foreignphrase>failover</foreignphrase> 
    1268     d'une configuration <foreignphrase>Warm Standby</foreignphrase> bien que 
    1269     vous puissiez faire les deux. 
     1238    La récupération réactivable (<foreigphrase>restartable 
     1239    recovery</foreignphrase>) peut aussi être utilisée pour décharger 
     1240    le serveur principal de la réalisation de sauvegardes de base 
     1241    périodiques, la sauvegarde des fichiers se faisant alors à partir d'un 
     1242    serveur de secours (<foreignphrase>Standby server</foreignphrase>). Ce 
     1243    concept est également connu 
     1244    sous le nom de sauvegardes actualisées par incrément 
     1245    (<foreignphrase>incrementally updated backups</foreignphrase>), 
     1246    accumulation des modifications de journaux 
     1247    (<foreignphrase>log change accumulation</foreignphrase>) ou plus simplement 
     1248    accumulation de modifications (<foreignphrase>change accumulation</foreignphrase>). 
     1249   </para> 
     1250 
     1251   <para> 
     1252    Si une sauvegarde des fichiers du serveur est réalisé alors qu'une 
     1253    récupération est en cours, il est possible de relancer la récupération 
     1254    à partir du dernier point de redémarrage. Cette sauvegarde contient 
     1255    alors certaines modifications des fichiers d'archive WAL précédents, ce 
     1256    qui fait de cette version une version actualisée de la sauvegarde 
     1257    originale de la base. Si une récupération s'avère nécessaire, elle est 
     1258    plus rapide à partir de la version actualisée qu'à 
     1259    partir de la sauvegarde de la base. 
     1260   </para> 
     1261 
     1262   <para> 
     1263    Pour utiliser cette possibilité, il faut configurer une base 
     1264    de secours sur un deuxième système comme cela est décrit dans 
     1265    <xref linkend="warm-standby"/>. En réalisant une sauvegarde du serveur 
     1266    de secours lorsqu'il est en cours d'exécution, une 
     1267    sauvegarde actualisée par incrément est créée. Lorsque cette 
     1268    configuration est mise en place, il n'est plus nécessaire de réaliser 
     1269    régulièrement des sauvegardes de la base sur le serveur principal&nbsp;; 
     1270    toutes les sauvegardes de la base peuvent être réalisées sur le serveur 
     1271    de secours. Bien qu'il ne soit pas nécessaire 
     1272    d'implanter les fonctionnalités de basculement 
     1273    (<foreignphrase>failover</foreignphrase>) sur une configuration de 
     1274    reprise intermédiaire (<foreignphrase>Warm Standby</foreignphrase>), c'est 
     1275    possible. 
    12701276   </para> 
    12711277 
    …… 
    12731279 
    12741280  <sect2 id="continuous-archiving-caveats"> 
    1275    <title>Avertissements</title> 
    1276  
    1277    <para> 
    1278     Au moment où nous écrivons ces lignes, il existe plusieurs limitations 
    1279     sur la technique de l'achivage continu. Elles seront probablement 
     1281   <title>Chausse-trappes</title> 
     1282 
     1283   <para> 
     1284    Au moment où ces lignes sont écrites, plusieurs limitations 
     1285    de la technique d'achivage continu sont connues. Elles seront probablement 
    12801286    corrigées dans une prochaine version&nbsp;: 
    12811287 
    …… 
    12831289   <listitem> 
    12841290    <para> 
    1285      Les opérations sur des index hachés 
    1286      ne sont pas tracées actuellement dans les WAL, donc ces index 
    1287      ne seront pas mis à jour. Le contournement recommandé est de 
    1288      <xref linkend="sql-reindex" endterm="sql-reindex-title"/>er manuellement 
    1289      chacun de ces index après avoir terminé une opération de récupération. 
    1290     </para> 
    1291    </listitem> 
    1292  
    1293    <listitem> 
    1294     <para> 
    1295      Si une commande <xref linkend="sql-createdatabase" endterm="sql-createdatabase-title"/> 
    1296      est exécutée alors qu'une sauvegarde est en cours, alors la base de données 
    1297      modèle que l'instruction <command>CREATE DATABASE</command> a copié est 
    1298      modifiée alors que la sauvegarde de la base est toujours en cours, il est 
    1299      possible que la récupération sera la cause de la propagation des modifications 
     1291     Les opérations sur les index de hachage 
     1292     ne sont pas tracées dans les WAL. Ces index 
     1293     ne sont donc pas actualisés lorsque la sauvegarde est rejouée. Pour 
     1294     cela, il est recommandé d'utiliser la commande  
     1295     <xref linkend="sql-reindex" endterm="sql-reindex-title"/> sur chacun 
     1296     des index à la fin de la récupération. 
     1297    </para> 
     1298   </listitem> 
     1299 
     1300   <listitem> 
     1301    <para> 
     1302     Si une commande 
     1303     <xref linkend="sql-createdatabase" endterm="sql-createdatabase-title"/> 
     1304     est exécutée alors qu'une sauvegarde est en cours, et que la base de données 
     1305     modèle utilisée par l'instruction <command>CREATE DATABASE</command> 
     1306     est à son tour modifiée pendant la sauvegarde, il est 
     1307     possible que la récupération propage ces modifications 
    13001308     dans la base de données créée. Pour éviter ce risque, il est préférable de 
    1301      ne pas modifier les bases de données modèles lors d'une sauvegarde de base. 
    1302     </para> 
    1303    </listitem> 
    1304  
    1305    <listitem> 
    1306     <para> 
    1307      Les commandes <xref linkend="sql-createtablespace" endterm="sql-createtablespace-title"/> 
    1308      sont tracées dans WAL avec le chemin absolu littéral et seront donc rejouées 
    1309      en tant que créations d'espaces logiques avec le même chemin absolu. Ceci 
    1310      pourrait être indésirable si la trace est rejouée sur la même machine mais 
    1311      dans un nouveau répertoire de données&nbsp;: la ré-exécution surchargera 
    1312      toujours le contenu de l'espace logique original. Pour éviter des problèmes 
    1313      potentiels de cette sorte, la meilleure pratique est de prendre une 
    1314      nouvelle sauvegarde de base après la création ou la suppression d'espaces 
    1315      logiques. 
     1309     ne pas modifier les bases de données modèle lors d'une sauvegarde de base. 
     1310    </para> 
     1311   </listitem> 
     1312 
     1313   <listitem> 
     1314    <para> 
     1315     Les commandes 
     1316     <xref linkend="sql-createtablespace" endterm="sql-createtablespace-title"/> 
     1317     sont tracées dans les WAL avec le chemin absolu et sont donc rejouées 
     1318     en tant que créations de <foreignprase>tablespace</foreignphrase> 
     1319     suivant le même chemin absolu. Ceci 
     1320     peut être indésirable si la trace est rejouée sur une autre machine. 
     1321     Cela peut s'avérer dangereux même lorsque le journal est rejoué sur la 
     1322     même machine, mais dans un répertoire différent&nbsp;: la ré-exécution surcharge 
     1323     toujours le contenu du <foreignphrase>tablespace</foreignphrase> original. 
     1324     Pour éviter de tels problèmes, la meilleure solution consiste à 
     1325     effectuer une nouvelle sauvegarde de la base après la création ou la 
     1326     suppression de <foreignphrase>tablespace</foreignphrase>. 
    13161327    </para> 
    13171328   </listitem> 
    …… 
    13201331 
    13211332   <para> 
    1322     De plus, il devrait être noté que le format actuel des <acronym>WAL</acronym> 
    1323     est extrêmement difficile à gérer car il inclut de nombreuses images des 
    1324     pages disques. Ces images de page sont conçues pour supporter la 
    1325     récupération après un arrêt brutal car nous pouvons avoir besoin de 
    1326     corriger des pages disque partiellement écrites. Suivant le matériel et 
    1327     le logiciel de votre système, le risque d'écriture partielle pourrait être 
    1328     assez faible pour être ignoré, auquel cas vous pouvez réduire 
    1329     significativement le volume total des traces archivées en désactivat les 
    1330     images de page grâce au paramètre <xref linkend="guc-full-page-writes"/> 
     1333    Il faut de plus garder à l'esprit que le format actuel des 
     1334    <acronym>WAL</acronym> est extrêmement difficile à gérer car il inclut 
     1335    de nombreuses images des pages disques. Ces images de page sont conçues 
     1336    pour supporter la récupération après un arrêt brutal. Il peut en effet 
     1337    être nécessaire de corriger des pages disque partiellement écrites. 
     1338    En fonction du matériel et des logiciels composant le système,  
     1339    le risque d'écriture partielle peut être 
     1340    suffisamment faible pour être ignoré, auquel cas le volume total des 
     1341    traces archivées peut être considérablement réduit par la désactivation 
     1342    des images de page à l'aide du paramètre <xref linkend="guc-full-page-writes"/> 
    13311343    (lire les notes et avertissements dans <xref linkend="wal"/> avant 
    13321344    de le faire). Désactiver les images de page n'empêche pas l'utilisation des 
    1333     traces pour les opérations PITR. Un développement possible serait de 
    1334     compresser les données des WAL archivées en supprimant les copies 
     1345    traces pour les opérations PITR. Un piste éventuelle de développements 
     1346    futurs consiste à compresser les données des WAL archivés en supprimant les copies 
    13351347    inutiles de pages même si <varname>full_page_writes</varname> est actif. Entre 
    1336     temps, les administrateurs pourraient souhaiter réduire le nombre 
     1348    temps, les administrateurs peuvent souhaiter réduire le nombre 
    13371349    d'images de pages inclus dans WAL en augmentant autant que possible les 
    1338     paramètres d'intervalle des points de vérification. 
     1350    paramètres d'intervalle entre les points de vérification. 
    13391351   </para> 
    13401352  </sect2> 
    13411353 </sect1> 
    13421354 
     1355<!-- Hot Standby : secours automatique ou reprise immédiate 
     1356     Warm standby : secours semi-automatique ou reprise intermédiaire--> 
    13431357 <sect1 id="warm-standby"> 
    1344   <title>Serveurs <quote>Warm Standby</quote> pour la haute disponibilité</title> 
     1358  <title>Serveurs de secours semi-automatique (<foreignphrase>Warm Standby</foreignphrase>) pour la haute disponibilité</title> 
    13451359 
    13461360  <indexterm zone="backup"> 
    …… 
    13491363 
    13501364  <indexterm zone="backup"> 
     1365   <primary>secours semi-automatique</primary> 
     1366  </indexterm> 
     1367 
     1368  <indexterm zone="backup"> 
     1369   <primary>reprise intermédiaire</primary> 
     1370  </indexterm> 
     1371 
     1372  <indexterm zone="backup"> 
    13511373   <primary>PITR Standby</primary> 
    13521374  </indexterm> 
    13531375 
    13541376  <indexterm zone="backup"> 
     1377   <primary>reprise PITR</primary> 
     1378  </indexterm> 
     1379 
     1380  <indexterm zone="backup"> 
    13551381   <primary>Standby Server</primary> 
    13561382  </indexterm> 
    13571383 
    13581384  <indexterm zone="backup"> 
     1385   <primary>serveur de secours</primary> 
     1386  </indexterm> 
     1387 
     1388  <indexterm zone="backup"> 
    13591389   <primary>Log Shipping</primary> 
    13601390  </indexterm> 
    …… 
    13721402  </indexterm> 
    13731403 
    1374   <para> 
    1375    L'archivage continue peut être utilisé pour créer une configuration 
    1376    de cluster de haute disponibilité avec un ou plusieurs serveurs en 
    1377    attente, prêt à prendre en main les opérations au cas où le serveur 
    1378    principal aurait un problème. Cette capacité est surtout connue sous 
     1404  <indexterm zone="backup"> 
     1405   <primary>Haute Disponibilité</primary> 
     1406  </indexterm> 
     1407 
     1408  <para> 
     1409   L'archivage continu peut être utilisé pour créer une configuration 
     1410   de cluster de haute disponibilité avec un ou plusieurs serveurs de 
     1411   secours, prêt(s) à prendre en main les opérations en cas de défaillance du 
     1412   serveur principal. Cette capacité est surtout connue sous 
    13791413   le nom de <foreignphrase>Warm Standby Log Shipping</foreignphrase>. 
    13801414  </para> 
    13811415 
    13821416  <para> 
    1383    Le serveur principal et le serveur en attente travaillent ensemble pour 
    1384    fournir cette capacité, bien que les serveurs sont très faiblement couplés. 
    1385    Le serveur primaire opère dans le mode de l'archivage continu alors que le 
    1386    serveur en attente opère dans un mode de récupération continue en lisant 
     1417   Le serveur principal et le serveur de secours travaillent ensemble pour 
     1418   fournir cette capacité, bien que les serveurs soient très faiblement couplés. 
     1419   Le serveur principal opère en mode d'archivage continu alors que le 
     1420   serveur de secours opère en mode de récupération continue en lisant 
    13871421   les fichiers WAL du serveur primaire. Aucune modification des tables 
    1388    de la base n'est requise pour activer cette capacité, donc elle coûte peu 
    1389    en administration supplémentaire en comparaison à d'autres approches de 
    1390    réplication. Cette configuration a aussi un impact très faible sur les 
    1391    performances du serveur primaire. 
    1392   </para> 
    1393  
    1394   <para> 
    1395    Déplacer directement les enregistrements des WAL (ou journaux) d'une base à 
    1396    une autre est typiquement décrit comme <foreignphrase>Log Shipping</foreignphrase>. 
    1397    <productname>PostgreSQL</productname> l'implemente à partir de fichiers, 
    1398    signifiant que les enregistrements 
    1399    WAL sont gérés un fichier à la fois. Les fichiers WAL peuvent être envoyés 
     1422   de la base n'est requise pour activer cette capacité. Elle a de ce fait 
     1423   un coût modique en terme d'administration supplémentaire en comparaison à 
     1424   d'autres approches de réplication. Cette configuration a également un impact 
     1425   très faible sur les performances du serveur principal. 
     1426  </para> 
     1427 
     1428  <para> 
     1429   Le déplacement direct des enregistrements des WAL (ou journaux) d'une base à 
     1430   une autre est généralement appelé <quote>transfert de journaux</quote> 
     1431   (<foreignphrase>Log Shipping</foreignphrase>). 
     1432   Sous <productname>PostgreSQL</productname> c'est un transfert de 
     1433   fichiers, de sorte que les enregistrements 
     1434   WAL sont traités fichier par fichier. Les fichiers WAL peuvent être envoyés 
    14001435   facilement et sans surcoût quelque soit la distance, que ce soit sur un 
    14011436   système adjacent, sur un autre système du même site ou sur un autre système 
    14021437   de l'autre côté du globe. La bande passante requise par cette technique 
    1403    varie suivant le taux de transaction du serveur principal. 
    1404    <foreignphrase>Record-based Log Shipping</foreignphrase> est aussi possible 
    1405    avec des procédures personnalisées, discutées dans une section suivante. 
    1406    Des futures développements devraient inclure des options pour les 
    1407    <foreignphrase>synchronous and/or integrated record-based log 
    1408    shipping</foreignphrase>. 
    1409   </para> 
    1410  
    1411   <para> 
    1412    Il devrait être noté que l'envoi des journaux est asynchrone, c'est-à-dire 
    1413    que les enregistrements WAL sont envoyés après une validation de la 
    1414    transaction. Comme résultat, il y a un petit risque de perte de données, 
    1415    si le serveur principal souffre d'un problème catastrophique. 
    1416    Ce problème est minimisé grâce à l'utilisation du paramètre 
    1417    <varname>archive_timeout</varname> qui peut être configuré à quelques secondes 
    1418    si nécessaire. Un paramètrage très bas peut augmenter les besoins de bande 
     1438   varie en focntion du taux de transaction du serveur principal. 
     1439   Le transfert de journaux par enregistrement  
     1440   (<foreignphrase>Record-based Log Shipping</foreignphrase>) est également 
     1441   réalisable, à l'aide de procédures personnalisées, discutées dans une 
     1442   section ultérieure. 
     1443   Il est possible que des développements futurs incluent le transfert de 
     1444   journaux par enregistrement synchrone ou intégré 
     1445   (<foreignphrase>synchronous and/or integrated record-based log 
     1446   shipping</foreignphrase>). 
     1447  </para> 
     1448 
     1449  <para> 
     1450   L'envoi des journaux est asynchrone, c'est-à-dire 
     1451   que les enregistrements WAL sont envoyés après validation de la 
     1452   transaction. De ce fait, il y a un léger risque de perte de données 
     1453   si le serveur principal est l'objet d'une panne catastrophique. 
     1454   Ce problème est minimisé par l'utilisation du paramètre 
     1455   <varname>archive_timeout</varname> qui peut être abaisser à quelques secondes 
     1456   si nécessaire. Un paramètrage très bas peut accroître les besoins de bande 
    14191457   passante pour l'envoi des journaux. 
    14201458  </para> 
    14211459 
    14221460  <para> 
    1423    Le serveur en attente n'est pas disponible en accès car il est en permanence 
    1424    dans le traitement de la récupération. Les performances de récupération 
    1425    sont suffisamment bonnes pour que l'attente ne soit typiquement que de 
    1426    quelques minutes avant une disponibilité complète une fois qu'il a été 
    1427    activé. Nous appelons cela une configuration <foreignphrase>Warm 
    1428    Standby</foreignphrase> qui offre la haute disponibilité. Restaurer un serveur 
    1429    à partir d'une sauvegarde archivée de la base et rejouer les journaux 
    1430    prendront considérablement plus de temps. Seule cette technique offre 
    1431    réellement une solution à la récupération suite à un désastre, mais pas 
     1461   Le serveur de secours n'est pas accessible, car il est en permanence 
     1462   occupé par la récupération. Les performances de récupération 
     1463   sont suffisamment bonnes pour que l'attente ne soit que de 
     1464   quelques minutes avant d'obtenir une disponibilité complète une fois qu'il a été 
     1465   activé. En conséquence, on appelle cela une configuration de reprise intermédiaire ou 
     1466   de secours semi-automatique (<foreignphrase>Warm 
     1467   Standby</foreignphrase>) permettant d'obtenir de la haute disponibilité. 
     1468   La restauration d'un serveur à partir d'une sauvegarde archivée de la 
     1469   base et de la relecture des journaux prend considérablement plus de temps. 
     1470   Cette technique n'offre qu'une solution de récupération suite à une panne, mais pas 
    14321471   de la haute disponibilité. 
    14331472  </para> 
    14341473 
    14351474  <para> 
    1436    Lors de l'exécution du serveur d'attente, les sauvegardes peuvent être 
    1437    réalisées sur ce serveur plutôt que sur le principal, ce qui décharge 
    1438    de la réalisation de sauvegarde basique (voir 
    1439    <xref linkend="backup-incremental-updated"/>) 
    1440   </para> 
    1441  
    1442   <para> 
    1443    D'autres mécanismes de réplication pour haute disponibilité sont disponibles, 
    1444    solutions commerciales et libre. 
    1445   </para> 
    1446  
    1447   <para> 
    1448    En général, l'envoi des journaux entre serveurs fonctionnant avec des 
    1449    niveaux de version différents n'est pas possible. La politique des 
    1450    développeurs PostgreSQL de ne pas faire de modification sur les formats 
    1451    disque lors de mises à jour mineures fait qu'il est possible d'utiliser des 
    1452    serveurs primaire et d'attente fonctionnant à partir de niveaux de 
    1453    versions mineures différents. Néanmoins, aucun support formel n'est offert 
    1454    pour cela et vous êtes avertis de na pas autoriser ceco pendant de longues 
    1455    périodes. 
    1456   </para> 
    1457  
     1475   L'utilisation d'un serveur de secours permet d'y réaliser les sauvegardes 
     1476   plutôt que sur le serveur principal, ce qui évite la réalisation de 
     1477   sauvegarde oériodiques  
     1478   (voir <xref linkend="backup-incremental-updated"/>). 
     1479  </para> 
     1480 
     1481  <para> 
     1482   D'autres mécanismes de réplication en vue d'atteindre une haute disponibilité 
     1483   sont disponibles, à la fois sous la forme de solutions commerciales et et 
     1484   de solutions libres. 
     1485  </para> 
     1486 
     1487  <para> 
     1488   En général, le transfert de journaux entre serveurs de 
     1489   versions différentes n'est pas possible. La politique des 
     1490   développeurs du <quote>PostgreSQL Global Development Group</quote> 
     1491   consiste à ne pas modifier les formats 
     1492   disque lors de mises à jour mineures. De ce fait il est possible d'utiliser des 
     1493   serveurs principal et de secours de versions mineures différentes. 
     1494   Toutefois, aucun support formel n'est offert 
     1495   pour cela. Il est préférable de ne pas considérer cette solution comme 
     1496   pérenne. 
     1497  </para> 
     1498 
     1499<!-- ICI --> 
    14581500  <sect2 id="warm-standby-planning"> 
    14591501   <title>Planification</title> 
    14601502 
    14611503   <para> 
    1462     Sur le serveur en attente, tous les espaces logiques et chemins référeront 
     1504    Sur le serveur de secours, tous les espaces logiques et chemins référeront 
    14631505    aux points de montage noméms de façon similaire. Il est donc important de 
    14641506    créer les serveurs primaire et d'attente de façon identique, au moins 
    …… 
    16041646 
    16051647   <para> 
    1606     Si le serveur principal a un problème, le serveur en attente doit commencer 
     1648    Si le serveur principal a un problème, le serveur de secours doit commencer 
    16071649    la procédure de <foreignphrase>failover</foreignphrase>. 
    16081650   </para>