Changeset 834

Show
Ignore:
Timestamp:
12/06/07 12:27:25 (10 months ago)
Author:
gleu
Message:

Relecture du chapitre sur les WAL.

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/branches/bv747/manuel/wal.sgml

    r109 r834  
    376376   écrit, la position du point de contrôle est sauvegardée dans le 
    377377   fichier <filename>pg_control</filename>.  Donc, quand la 
    378    restauration doit être faite, le serveur lit en premier 
     378   restauration doit se faire, le serveur lit en premier 
    379379   <filename>pg_control</filename> et ensuite l'entrée du point de 
    380380   contrôle&nbsp;; ensuite, il exécute l'opération REDO en parcourant vers 

  • traduc/branches/bv803/manuel/wal.sgml

    r109 r834  
    337337   écrit, la position du point de contrôle est sauvegardée dans le 
    338338   fichier <filename>pg_control</filename>.  Donc, quand la 
    339    restauration doit être faite, le serveur lit en premier 
     339   restauration doit se faire, le serveur lit en premier 
    340340   <filename>pg_control</filename> et ensuite l'entrée du point de 
    341341   contrôle&nbsp;; ensuite, il exécute l'opération REDO en parcourant vers 
    …… 
    349349  <para> 
    350350   Pour gérer le cas où <filename>pg_control</filename> est corrompu, nous 
    351    devons supporter la possibilité de parcourir des segments de journaux 
    352    existants en ordre inverse &mdash; de plus récent au plus ancien &mdash; pour 
     351   devons permettre le parcours des segments de journaux 
     352   existants en ordre inverse &mdash; du plus récent au plus ancien &mdash; pour 
    353353   trouver le dernier point de vérification. Ceci n'a pas encore été implémenté. 
    354354   <filename>pg_control</filename> est assez petit (moins d'une page disque) 

  • traduc/branches/bv81x/manuel/wal.xml

    r636 r834  
    33 
    44<chapter id="wal"> 
    5  <title>Fiabilité et WAL</title> 
     5 <title>Fiabilité et journaux de transaction</title> 
    66 
    77 <para> 
    8   Ce chapitre explique comment les WAL sont utilisés pour obtenir des 
    9   traitements efficaces et fiables. 
     8  Ce chapitre explique comment les journaux de transaction sont utilisés pour 
     9  obtenir des traitements efficaces et fiables. 
    1010 </para> 
    1111 
    …… 
    1515  <para> 
    1616   La fiabilité est une propriété importante de tout système de base de 
    17    données sérieux. <productname>PostgreSQL</productname> fait tout ce qui est en son 
    18    pouvoir pour garantir des opérations fiables. Un aspect de la fiabilité des 
    19    opérations est que toutes les données enregistrées par une transaction 
     17   données sérieux. <productname>PostgreSQL</productname> fait tout ce qui est 
     18   en son pouvoir pour garantir une fiabilité à toute épreuve. Un des aspects 
     19   de cette fiabilité est que toutes les données enregistrées par une 
     20   transaction 
    2021   validée doivent être stockées dans un espace non volatile, un espace 
    2122   non sensible aux coupures de courant, aux bogues du système d'exploitation 
    …… 
    2324   volatile, bien sûr). Écrire avec succès les données sur le stockage 
    2425   permanent de l'ordinateur (disque dur ou un équivalent) est habituellement 
    25    suffisant pour cela. En fait, même si un ordinateur est suffisamment 
     26   suffisant pour cela. En fait, même si un ordinateur est vraiment 
    2627   endommagé, si le disque dur survit, il peut être placé dans un autre 
    2728   ordinateur avec un matériel similaire et toutes les transactions validées 
    …… 
    7071   il ne peut pas faire grand chose pour s'assurer que les données sont 
    7172   arrivées dans un espace de stockage non volatile. Ce travail incombe à 
    72    l'administrateur&nbsp;: il doit s'assurer que tous les composants de 
     73   l'administrateur&nbsp;: ce dernier doit s'assurer que tous les composants de 
    7374   stockage assurent l'intégrité des données. Évitez les contrôleurs disques 
    74    ne disposant pas de caches protégées par batterie. Au niveau du disque, 
     75   ne disposant pas de caches protégés par batterie. Au niveau du disque, 
    7576   désactivez le cache <quote>write-back</quote> si le disque ne garantie pas 
    7677   que les données seront écrites avant un arrêt. 
    …… 
    8283   secteur de 512 octets généralement. Chaque opération de lecture ou écriture 
    8384   physique traite un secteur entier. Quand la demande d'écriture arrive au 
    84    lecteur, elle pourrait contenir 512 octets, 1024 octets ou 9182 octets et 
     85   lecteur, elle pourrait contenir 512 octets, 1024 octets ou 8192 octets et 
    8586   le processus d'écriture pourrait échouer à cause d'une perte de courant à 
    8687   tout moment signifiant que certains octets pourraient être écrits et les 
    …… 
    161162 
    162163 <sect1 id="wal-configuration"> 
    163   <title>Configuration de <acronym>WAL</acronym></title> 
    164  
    165   <para> 
    166    Il y a plusieurs paramètres de configuration associés à 
    167    <acronym>WAL</acronym> qui affectent les performances de la base de 
    168    de données.  Cette section explique leur utilisation.  Consultez le 
     164  <title>Configuration de journaux de transaction</title> 
     165 
     166  <para> 
     167   Il y a plusieurs paramètres de configuration associés aux 
     168   journaux de transaction qui affectent les performances de la base de 
     169   données.  Cette section explique leur utilisation.  Consultez le 
    169170   <xref linkend="runtime-config"/> pour des détails sur la 
    170171   mise en place de ces paramètres de configuration. 
    …… 
    174175   Dans la séquence des transactions, les 
    175176   <firstterm>points de contrôles</firstterm><indexterm><primary>points de 
    176    contrôle</primary></indexterm> (checkpoints) sont des 
     177   contrôle</primary></indexterm> (appelés 
     178   <foreignphrase>checkpoints</foreignphrase>) sont des 
    177179   points qui garantissent que les fichiers de données ont été mis à 
    178180   jour avec toutes les informations enregistrées dans le journal avant le 
    …… 
    181183   entrée spéciale, pour le point de contrôle, est écrite dans le 
    182184   journal. En cas de défaillance, la procédure de récupération recherche le 
    183    dernier enregistrement d'un point de vérification dans les traces (connu 
    184    comme le <quote>redo log</quote>) à partir duquel il devra lancer l'opération 
     185   dernier enregistrement d'un point de vérification dans les traces 
     186   (enregistrement connus sous le nom de <quote>redo log</quote>) à partir 
     187   duquel il devra lancer l'opération 
    185188   REDO. Toute modification effectuée sur les fichiers de données avant ce point 
    186189   est sûre d'avoir été enregistrée sur disque. Du coup, après qu'un point de 
    187    vérification soit effectué, tous les segments de trace précédant celui 
     190   vérification est réalisé, tous les segments représentant des journaux de 
     191   transaction précédant celui 
    188192   contenant le <quote>redo record</quote> ne sont plus nécessaires et peuvent 
    189    être soit recyclés soit supprimés (quand l'archivage des <acronym>WAL</acronym> 
    190    se fait, les segments de traces doivent être archivés avant d'être recyclés 
    191    ou supprimés). 
    192   </para> 
    193  
    194   <para> 
    195    Le processus d'écriture en tâche de fond lancera automatiquement un point de 
    196    contrôle de temps en temps. Un point de contrôle est créé tous les <xref 
    197    linkend="guc-checkpoint-segments"/> segments de journaux ou dès que <xref 
     193   être soit recyclés soit supprimés (quand l'archivage des journaux de 
     194   transaction est activé, ces derniers doivent être archivés avant d'être 
     195   recyclés ou supprimés). 
     196  </para> 
     197 
     198  <para> 
     199   Le processus d'écriture en tâche de fond lance automatiquement un point de 
     200   contrôle de temps en temps&nbsp,: tous les <xref 
     201   linkend="guc-checkpoint-segments"/> journaux de transaction ou dès que <xref 
    198202   linkend="guc-checkpoint-timeout"/> secondes se sont 
    199    écoulées.  Les paramètres par défaut sont respectivement 3 segments 
    200    et 300 secondes.  Il est également possible de forcer la création 
     203   écoulées.  Les paramètres par défaut sont respectivement de trois journaux 
     204   et de 300 secondes.  Il est également possible de forcer la création 
    201205   d'un point de contrôle en utilisant la commande SQL 
    202206   <command>CHECKPOINT</command>. 
    …… 
    376380   Le but de <acronym>WAL</acronym>, s'assurer que le journal est écrit 
    377381   avant l'altération des entrées dans la base, peut être mis en échec par 
    378    les lecteurs des disques<indexterm><primary>disques durs</primary></indexterm> qui 
    379    faussement rapportent une écriture 
     382   les disques<indexterm><primary>disques durs</primary></indexterm> qui 
     383   rapportent une écriture 
    380384   réussie au noyau quand, en fait, ils ont seulement mis en cache 
    381    les données et ne les ont pas encore stockées sur le disque.  Une 
     385   les données et ne les ont pas encore stockés sur le disque.  Une 
    382386   coupure de courant dans ce genre de situation peut toujours mener à 
    383    la corruption irrécupérable des données.  Les administrateurs 
    384    devraient s'assurer que les disques contenant les journaux 
    385    <acronym>WAL</acronym> de <productname>PostgreSQL</productname> ne 
     387   une corruption irrécupérable des données.  Les administrateurs 
     388   devraient s'assurer que les disques contenant les journaux de 
     389   transaction de <productname>PostgreSQL</productname> ne 
    386390   produisent pas ce genre de faux rapports. 
    387391  </para> 
    …… 
    391395   écrit, la position du point de contrôle est sauvegardée dans le 
    392396   fichier <filename>pg_control</filename>.  Donc, quand la 
    393    restauration doit être faite, le serveur lit en premier 
     397   restauration doit se faire, le serveur lit en premier 
    394398   <filename>pg_control</filename> et ensuite l'entrée du point de 
    395399   contrôle&nbsp;; ensuite, il exécute l'opération REDO en parcourant vers 
    …… 
    403407  <para> 
    404408   Pour gérer le cas où <filename>pg_control</filename> est corrompu, nous 
    405    devons supporter la possibilité de parcourir des segments de journaux 
    406    existants en ordre inverse &mdash; de plus récent au plus ancien &mdash; pour 
     409   devons permettre le parcours des segments de journaux 
     410   existants en ordre inverse &mdash; du plus récent au plus ancien &mdash; pour 
    407411   trouver le dernier point de vérification. Ceci n'a pas encore été implémenté. 
    408412   <filename>pg_control</filename> est assez petit (moins d'une page disque) 

  • traduc/branches/bv82x/manuel/wal.xml

    r715 r834  
    33 
    44<chapter id="wal"> 
    5  <title>Fiabilité et WAL</title> 
     5 <title>Fiabilité et journaux de transaction</title> 
    66 
    77 <para> 
    8   Ce chapitre explique comment les WAL sont utilisés pour obtenir des 
    9   traitements efficaces et fiables. 
     8  Ce chapitre explique comment les journaux de transaction sont utilisés pour 
     9  obtenir des traitements efficaces et fiables. 
    1010 </para> 
    1111 
    …… 
    1515  <para> 
    1616   La fiabilité est une propriété importante de tout système de base de 
    17    données sérieux. <productname>PostgreSQL</productname> fait tout ce qui est en son 
    18    pouvoir pour garantir des opérations fiables. Un aspect de la fiabilité des 
    19    opérations est que toutes les données enregistrées par une transaction 
     17   données sérieux. <productname>PostgreSQL</productname> fait tout ce qui est 
     18   en son pouvoir pour garantir une fiabilité à toute épreuve. Un des aspects 
     19   de cette fiabilité est que toutes les données enregistrées par une 
     20   transaction 
    2021   validée doivent être stockées dans un espace non volatile, un espace 
    2122   non sensible aux coupures de courant, aux bogues du système d'exploitation 
    …… 
    2324   volatile, bien sûr). Écrire avec succès les données sur le stockage 
    2425   permanent de l'ordinateur (disque dur ou un équivalent) est habituellement 
    25    suffisant pour cela. En fait, même si un ordinateur est suffisamment 
     26   suffisant pour cela. En fait, même si un ordinateur est vraiment 
    2627   endommagé, si le disque dur survit, il peut être placé dans un autre 
    2728   ordinateur avec un matériel similaire et toutes les transactions validées 
    …… 
    7071   il ne peut pas faire grand chose pour s'assurer que les données sont 
    7172   arrivées dans un espace de stockage non volatile. Ce travail incombe à 
    72    l'administrateur&nbsp;: il doit s'assurer que tous les composants de 
     73   l'administrateur&nbsp;: ce dernier doit s'assurer que tous les composants de 
    7374   stockage assurent l'intégrité des données. Évitez les contrôleurs disques 
    74    ne disposant pas de caches protégées par batterie. Au niveau du disque, 
     75   ne disposant pas de caches protégés par batterie. Au niveau du disque, 
    7576   désactivez le cache <quote>write-back</quote> si le disque ne garantie pas 
    7677   que les données seront écrites avant un arrêt. 
    …… 
    8283   secteur de 512 octets généralement. Chaque opération de lecture ou écriture 
    8384   physique traite un secteur entier. Quand la demande d'écriture arrive au 
    84    lecteur, elle pourrait contenir 512 octets, 1024 octets ou 9182 octets et 
     85   lecteur, elle pourrait contenir 512 octets, 1024 octets ou 8192 octets et 
    8586   le processus d'écriture pourrait échouer à cause d'une perte de courant à 
    8687   tout moment signifiant que certains octets pourraient être écrits et les 
    …… 
    161162 
    162163 <sect1 id="wal-configuration"> 
    163   <title>Configuration de <acronym>WAL</acronym></title> 
    164  
    165   <para> 
    166    Il y a plusieurs paramètres de configuration associés à 
    167    <acronym>WAL</acronym> qui affectent les performances de la base de 
    168    de données.  Cette section explique leur utilisation.  Consultez le 
     164  <title>Configuration de journaux de transaction</title> 
     165 
     166  <para> 
     167   Il y a plusieurs paramètres de configuration associés aux 
     168   journaux de transaction qui affectent les performances de la base de 
     169   données.  Cette section explique leur utilisation.  Consultez le 
    169170   <xref linkend="runtime-config"/> pour des détails sur la 
    170171   mise en place de ces paramètres de configuration. 
    …… 
    174175   Dans la séquence des transactions, les 
    175176   <firstterm>points de contrôles</firstterm><indexterm><primary>points de 
    176    contrôle</primary></indexterm> (checkpoints) sont des 
     177   contrôle</primary></indexterm> (appelés 
     178   <foreignphrase>checkpoints</foreignphrase>) sont des 
    177179   points qui garantissent que les fichiers de données ont été mis à 
    178180   jour avec toutes les informations enregistrées dans le journal avant le 
    …… 
    181183   entrée spéciale, pour le point de contrôle, est écrite dans le 
    182184   journal. En cas de défaillance, la procédure de récupération recherche le 
    183    dernier enregistrement d'un point de vérification dans les traces (connu 
    184    comme le <quote>redo log</quote>) à partir duquel il devra lancer l'opération 
     185   dernier enregistrement d'un point de vérification dans les traces 
     186   (enregistrement connus sous le nom de <quote>redo log</quote>) à partir 
     187   duquel il devra lancer l'opération 
    185188   REDO. Toute modification effectuée sur les fichiers de données avant ce point 
    186189   est sûre d'avoir été enregistrée sur disque. Du coup, après qu'un point de 
    187    vérification soit effectué, tous les segments de trace précédant celui 
     190   vérification est réalisé, tous les segments représentant des journaux de 
     191   transaction précédant celui 
    188192   contenant le <quote>redo record</quote> ne sont plus nécessaires et peuvent 
    189    être soit recyclés soit supprimés (quand l'archivage des <acronym>WAL</acronym> 
    190    se fait, les segments de traces doivent être archivés avant d'être recyclés 
    191    ou supprimés). 
    192   </para> 
    193  
    194   <para> 
    195    Le processus d'écriture en tâche de fond lancera automatiquement un point de 
    196    contrôle de temps en temps. Un point de contrôle est créé tous les <xref 
    197    linkend="guc-checkpoint-segments"/> segments de journaux ou dès que <xref 
     193   être soit recyclés soit supprimés (quand l'archivage des journaux de 
     194   transaction est activé, ces derniers doivent être archivés avant d'être 
     195   recyclés ou supprimés). 
     196  </para> 
     197 
     198  <para> 
     199   Le processus d'écriture en tâche de fond lance automatiquement un point de 
     200   contrôle de temps en temps&nbsp,: tous les <xref 
     201   linkend="guc-checkpoint-segments"/> journaux de transaction ou dès que <xref 
    198202   linkend="guc-checkpoint-timeout"/> secondes se sont 
    199    écoulées.  Les paramètres par défaut sont respectivement 3 segments 
    200    et 300 secondes.  Il est également possible de forcer la création 
     203   écoulées.  Les paramètres par défaut sont respectivement de trois journaux 
     204   et de 300 secondes.  Il est également possible de forcer la création 
    201205   d'un point de contrôle en utilisant la commande SQL 
    202206   <command>CHECKPOINT</command>. 
    …… 
    207211   <varname>checkpoint_timeout</varname> implique  
    208212   des points de contrôle plus fréquents.  Cela permet une récupération 
    209    plus rapide après défaillance (puisqu'il y a moins de travail à 
    210    récupérer).  Cependant, il faut équilibrer cela avec 
    211    l'augmentation du coût d'écriture des pages de données non propres. 
    212    Si <xref linkend="guc-full-page-writes"/> est configuré (comme la valeur par 
     213   plus rapide après défaillance puisqu'il y a moins d'écritures à 
     214   synchroniser. Cependant, il faut équilibrer cela avec 
     215   l'augmentation du coût d'écriture des pages de données modifiées. 
     216   Si <xref linkend="guc-full-page-writes"/> est configuré (ce qui est la 
     217   valeur par 
    213218   défaut), il reste un autre facteur à considérer. Pour s'assurer de la 
    214219   cohérence des pages de données, la première modification d'une page de 
    215220   données après chaque point de vérification résulte dans le traçage du contenu 
    216221   entier de la page. Dans ce cas, un intervalle de points de vérification 
    217    plus petit augmentera le volume en sortie des traces WAL, dégradant 
    218    partiellement le but d'utiliser un intervalle plus petit et impliquant 
     222   plus petit augmentera le volume en sortie des journaux de transaction, 
     223   diminuant légèrement l'intérêt d'utiliser un intervalle plus petit et 
     224   impliquant 
    219225   de toute façon plus d'entrées/sorties au niveau disque. 
    220226  </para> 
    …… 
    223229   Les points de contrôle sont assez coûteux, tout d'abord parce qu'ils 
    224230   écrivent tous les tampons utilisés, et ensuite parce que cela suscite un 
    225    trafic WAL supplémentaire comme indiqué ci-dessus. Du coup, il est conseillé 
     231   trafic supplémentaire dans les journaux de transaction, comme indiqué 
     232   ci-dessus. Du coup, il est conseillé 
    226233   de configurer les paramètres en relation assez haut pour que ces points de 
    227    contrôle ne surviennent pas trop fréquemment. En tant que simple vérification 
    228    de santé de vos paramètres, vous pouvez configurer le paramètre <xref 
     234   contrôle ne surviennent pas trop fréquemment. Pour une vérification 
     235   rapide de l'adéquation de vos paramètres, vous pouvez configurer le 
     236   paramètre <xref 
    229237   linkend="guc-checkpoint-warning"/>. Si les points de contrôle arrivent plus 
    230    rapidement que <varname>checkpoint_warning</varname> secondes, un message sera 
    231    affiché dans les journaux du serveur recommandant d'accroître 
     238   rapidement que <varname>checkpoint_warning</varname> secondes, un message 
     239   est affiché dans les journaux applicatifs du serveur recommandant d'accroître 
    232240   <varname>checkpoint_segments</varname>. Une apparition occasionnelle d'un 
    233241   message ne doit pas vous alarmer mais, s'il apparaît souvent, alors les 
    234242   paramètres de contrôle devraient être augmentés. Les opérations en masse, 
    235    comme les gros transferts via <command>COPY</command>, pourraient être la cause 
     243   comme les transferts importants de données via <command>COPY</command>, 
     244   pourraient être la cause 
    236245   de l'apparition d'un tel nombre de messages d'avertissements si 
    237246   vous n'avez pas configuré <varname>checkpoint_segments</varname> avec une valeur 
    …… 
    376385   Le but de <acronym>WAL</acronym>, s'assurer que le journal est écrit 
    377386   avant l'altération des entrées dans la base, peut être mis en échec par 
    378    les lecteurs des disques<indexterm><primary>disques durs</primary></indexterm> qui 
    379    faussement rapportent une écriture 
     387   les disques<indexterm><primary>disques durs</primary></indexterm> qui 
     388   rapportent une écriture 
    380389   réussie au noyau quand, en fait, ils ont seulement mis en cache 
    381    les données et ne les ont pas encore stockées sur le disque.  Une 
     390   les données et ne les ont pas encore stockés sur le disque.  Une 
    382391   coupure de courant dans ce genre de situation peut toujours mener à 
    383    la corruption irrécupérable des données.  Les administrateurs 
    384    devraient s'assurer que les disques contenant les journaux 
    385    <acronym>WAL</acronym> de <productname>PostgreSQL</productname> ne 
     392   une corruption irrécupérable des données.  Les administrateurs 
     393   devraient s'assurer que les disques contenant les journaux de 
     394   transaction de <productname>PostgreSQL</productname> ne 
    386395   produisent pas ce genre de faux rapports. 
    387396  </para> 
    …… 
    391400   écrit, la position du point de contrôle est sauvegardée dans le 
    392401   fichier <filename>pg_control</filename>.  Donc, quand la 
    393    restauration doit être faite, le serveur lit en premier 
     402   restauration doit se faire, le serveur lit en premier 
    394403   <filename>pg_control</filename> et ensuite l'entrée du point de 
    395404   contrôle&nbsp;; ensuite, il exécute l'opération REDO en parcourant vers 
    …… 
    403412  <para> 
    404413   Pour gérer le cas où <filename>pg_control</filename> est corrompu, nous 
    405    devons supporter la possibilité de parcourir des segments de journaux 
    406    existants en ordre inverse &mdash; de plus récent au plus ancien &mdash; pour 
     414   devons permettre le parcours des segments de journaux 
     415   existants en ordre inverse &mdash; du plus récent au plus ancien &mdash; pour 
    407416   trouver le dernier point de vérification. Ceci n'a pas encore été implémenté. 
    408417   <filename>pg_control</filename> est assez petit (moins d'une page disque) 

  • traduc/trunk/manuel/wal.xml

    r777 r834  
    33 
    44<chapter id="wal"> 
    5  <title>Fiabilité et WAL</title> 
     5 <title>Fiabilité et journaux de transaction</title> 
    66 
    77 <para> 
    8   Ce chapitre explique comment les WAL sont utilisés pour obtenir des 
    9   traitements efficaces et fiables. 
     8  Ce chapitre explique comment les journaux de transaction sont utilisés pour 
     9  obtenir des traitements efficaces et fiables. 
    1010 </para> 
    1111 
    …… 
    1515  <para> 
    1616   La fiabilité est une propriété importante de tout système de base de 
    17    données sérieux. <productname>PostgreSQL</productname> fait tout ce qui est en son 
    18    pouvoir pour garantir des opérations fiables. Un aspect de la fiabilité des 
    19    opérations est que toutes les données enregistrées par une transaction 
     17   données sérieux. <productname>PostgreSQL</productname> fait tout ce qui est 
     18   en son pouvoir pour garantir une fiabilité à toute épreuve. Un des aspects 
     19   de cette fiabilité est que toutes les données enregistrées par une 
     20   transaction 
    2021   validée doivent être stockées dans un espace non volatile, un espace 
    2122   non sensible aux coupures de courant, aux bogues du système d'exploitation 
    …… 
    2324   volatile, bien sûr). Écrire avec succès les données sur le stockage 
    2425   permanent de l'ordinateur (disque dur ou un équivalent) est habituellement 
    25    suffisant pour cela. En fait, même si un ordinateur est suffisamment 
     26   suffisant pour cela. En fait, même si un ordinateur est vraiment 
    2627   endommagé, si le disque dur survit, il peut être placé dans un autre 
    2728   ordinateur avec un matériel similaire et toutes les transactions validées 
    …… 
    7071   il ne peut pas faire grand chose pour s'assurer que les données sont 
    7172   arrivées dans un espace de stockage non volatile. Ce travail incombe à 
    72    l'administrateur&nbsp;: il doit s'assurer que tous les composants de 
     73   l'administrateur&nbsp;: ce dernier doit s'assurer que tous les composants de 
    7374   stockage assurent l'intégrité des données. Évitez les contrôleurs disques 
    74    ne disposant pas de caches protégées par batterie. Au niveau du disque, 
     75   ne disposant pas de caches protégés par batterie. Au niveau du disque, 
    7576   désactivez le cache <quote>write-back</quote> si le disque ne garantie pas 
    7677   que les données seront écrites avant un arrêt. 
    …… 
    8283   secteur de 512 octets généralement. Chaque opération de lecture ou écriture 
    8384   physique traite un secteur entier. Quand la demande d'écriture arrive au 
    84    lecteur, elle pourrait contenir 512 octets, 1024 octets ou 9182 octets et 
     85   lecteur, elle pourrait contenir 512 octets, 1024 octets ou 8192 octets et 
    8586   le processus d'écriture pourrait échouer à cause d'une perte de courant à 
    8687   tout moment signifiant que certains octets pourraient être écrits et les 
    …… 
    113114   <firstterm>Write-Ahead Logging</firstterm> (<acronym>WAL</acronym>) 
    114115   est une méthode conventionnelle pour s'assurer de l'intégrité des 
    115    données.  Une description détaillée peut être trouvée dans la 
    116    plupart (si ce n'est tous) des livres sur le traitement 
    117    transactionnel. Brièvement, le concept central des 
    118    <acronym>WAL</acronym> est d'effectuer les changements des fichiers de 
    119    données (où résident les tables et les index)  
    120    uniquement après que ces changements ont été écrits dans un journal, 
    121    c'est-à-dire après que l'enregistrement du journal décrivant les changements a 
    122    été écrit vers le 
    123    stockage permanent.  Si nous suivons cette procédure, nous n'avons 
     116   données.  Une description détaillée peut être trouvée dans la plupart 
     117   des livres sur le traitement transactionnel. Brièvement, le concept central 
     118   du <acronym>WAL</acronym> est d'effectuer les changements des fichiers de 
     119   données (donc les tables et les index) uniquement après que ces changements 
     120   ont été écrits de façon sûr dans un journal, appelé journal des 
     121   transactions.  Si nous suivons cette procédure, nous n'avons 
    124122   pas besoin d'écrire les pages de données vers le disque à chaque 
    125123   validation de transaction car nous savons que, dans l'éventualité 
    …… 
    132130 
    133131   <para> 
    134     Utiliser les <acronym>WAL</acronym> permet de réduire de façon 
     132    Utiliser les journaux de transaction permet de réduire de façon 
    135133    significative le nombre d'écritures sur le disque puisque seul le journal 
    136     des transactions a besoin d'être écrit sur le disque pour garantir qu'une 
     134    a besoin d'être écrit sur le disque pour garantir qu'une 
    137135    transaction a été validée plutôt que d'écrire dans chaque fichier de 
    138136    données modifié par la transaction. Ce journal est écrit séquentiellement 
    139     et donc, le coût de synchronisation du journal est largement moindre que 
    140     le coût d'écriture des pages de données. Ceci est spécialement vrai pour 
     137    ce qui fait que le coût de synchronisation du journal est largement moindre 
     138        que le coût d'écriture des pages de données. Ceci est tout spécialement 
     139        vrai pour 
    141140    les serveurs gérant beaucoup de petites transactions touchant différentes 
    142141    parties du stockage de données. De plus, quand le serveur traite plein de 
    143142    petites transactions en parallèle, un <function>fsync</function> du 
    144     journal des transactions devrait suffire pour valider plusieurs 
     143    journal des transactions devrait suffire pour enregistrer plusieurs 
    145144    transactions. 
    146145   </para> 
    147146 
    148147   <para> 
    149     Les <acronym>WAL</acronym> rendent possible le support de sauvegarde 
     148    Les journaux de transaction rendent possible le support de sauvegarde 
    150149    en ligne et de récupération à un moment, comme décrit dans la <xref 
    151     linkend="continuous-archiving"/>. En archivant les données WAL, nous pouvons 
    152     supporter le retour à tout instant couvert par les données disponibles 
    153     dans les WAL&nbsp;: nous installons simplement une ancienne sauvegarde 
    154     physique de la base de données et nous rejouons les journaux WAL jusqu'au 
    155     moment désiré. Qui plus est, la sauvegarde physique n'a pas besoin d'être 
    156     une image instantanée de l'état de la base de données &mdash; si elle a été 
    157     faite pendant une période de temps, alors rejouer les journaux WAL pour 
     150    linkend="continuous-archiving"/>. En archivant les journaux de transaction, 
     151        nous pouvons supporter le retour à tout instant couvert par les données 
     152        disponibles dans les journaux de transaction&nbsp;: nous installons 
     153        simplement une ancienne sauvegarde physique de la base de données et nous 
     154        rejouons les journaux de transaction jusqu'au moment désiré. Qui plus est, 
     155        la sauvegarde physique n'a pas besoin d'être une image instantanée de 
     156        l'état de la base de données &mdash; si elle a été faite pendant une 
     157        grande période de temps, alors rejouer les journaux de transaction pour 
    158158    cette période corrigera toute incohérence interne. 
    159159   </para> 
    …… 
    294294 
    295295 <sect1 id="wal-configuration"> 
    296   <title>Configuration de <acronym>WAL</acronym></title> 
    297  
    298   <para> 
    299    Il y a plusieurs paramètres de configuration associés à 
    300    <acronym>WAL</acronym> qui affectent les performances de la base de 
    301    de données.  Cette section explique leur utilisation.  Consultez le 
     296  <title>Configuration de journaux de transaction</title> 
     297 
     298  <para> 
     299   Il y a plusieurs paramètres de configuration associés aux 
     300   journaux de transaction qui affectent les performances de la base de 
     301   données.  Cette section explique leur utilisation.  Consultez le 
    302302   <xref linkend="runtime-config"/> pour des détails sur la 
    303303   mise en place de ces paramètres de configuration. 
    …… 
    307307   Dans la séquence des transactions, les 
    308308   <firstterm>points de contrôles</firstterm><indexterm><primary>points de 
    309    contrôle</primary></indexterm> (checkpoints) sont des 
     309   contrôle</primary></indexterm> (appelés 
     310   <foreignphrase>checkpoints</foreignphrase>) sont des 
    310311   points qui garantissent que les fichiers de données ont été mis à 
    311312   jour avec toutes les informations enregistrées dans le journal avant le 
    …… 
    314315   entrée spéciale, pour le point de contrôle, est écrite dans le 
    315316   journal. En cas de défaillance, la procédure de récupération recherche le 
    316    dernier enregistrement d'un point de vérification dans les traces (connu 
    317    comme le <quote>redo log</quote>) à partir duquel il devra lancer l'opération 
     317   dernier enregistrement d'un point de vérification dans les traces 
     318   (enregistrement connus sous le nom de <quote>redo log</quote>) à partir 
     319   duquel il devra lancer l'opération 
    318320   REDO. Toute modification effectuée sur les fichiers de données avant ce point 
    319321   est sûre d'avoir été enregistrée sur disque. Du coup, après qu'un point de 
    320    vérification soit effectué, tous les segments de trace précédant celui 
     322   vérification est réalisé, tous les segments représentant des journaux de 
     323   transaction précédant celui 
    321324   contenant le <quote>redo record</quote> ne sont plus nécessaires et peuvent 
    322    être soit recyclés soit supprimés (quand l'archivage des <acronym>WAL</acronym> 
    323    se fait, les segments de traces doivent être archivés avant d'être recyclés 
    324    ou supprimés). 
    325   </para> 
    326  
    327   <para> 
    328    Le processus d'écriture en tâche de fond lancera automatiquement un point de 
    329    contrôle de temps en temps. Un point de contrôle est créé tous les <xref 
    330    linkend="guc-checkpoint-segments"/> segments de journaux ou dès que <xref 
     325   être soit recyclés soit supprimés (quand l'archivage des journaux de 
     326   transaction est activé, ces derniers doivent être archivés avant d'être 
     327   recyclés ou supprimés). 
     328  </para> 
     329 
     330  <para> 
     331   Le processus d'écriture en tâche de fond lance automatiquement un point de 
     332   contrôle de temps en temps&nbsp,: tous les <xref 
     333   linkend="guc-checkpoint-segments"/> journaux de transaction ou dès que <xref 
    331334   linkend="guc-checkpoint-timeout"/> secondes se sont 
    332    écoulées.  Les paramètres par défaut sont respectivement 3 segments 
    333    et 300 secondes.  Il est également possible de forcer la création 
     335   écoulées.  Les paramètres par défaut sont respectivement de trois journaux 
     336   et de 300 secondes.  Il est également possible de forcer la création 
    334337   d'un point de contrôle en utilisant la commande SQL 
    335338   <command>CHECKPOINT</command>. 
    …… 
    340343   <varname>checkpoint_timeout</varname> implique  
    341344   des points de contrôle plus fréquents.  Cela permet une récupération 
    342    plus rapide après défaillance (puisqu'il y a moins de travail à 
    343    récupérer).  Cependant, il faut équilibrer cela avec 
    344    l'augmentation du coût d'écriture des pages de données non propres. 
    345    Si <xref linkend="guc-full-page-writes"/> est configuré (comme la valeur par 
     345   plus rapide après défaillance puisqu'il y a moins d'écritures à 
     346   synchroniser. Cependant, il faut équilibrer cela avec 
     347   l'augmentation du coût d'écriture des pages de données modifiées. 
     348   Si <xref linkend="guc-full-page-writes"/> est configuré (ce qui est la 
     349   valeur par 
    346350   défaut), il reste un autre facteur à considérer. Pour s'assurer de la 
    347351   cohérence des pages de données, la première modification d'une page de 
    348352   données après chaque point de vérification résulte dans le traçage du contenu 
    349353   entier de la page. Dans ce cas, un intervalle de points de vérification 
    350    plus petit augmentera le volume en sortie des traces WAL, dégradant 
    351    partiellement le but d'utiliser un intervalle plus petit et impliquant 
     354   plus petit augmentera le volume en sortie des journaux de transaction, 
     355   diminuant légèrement l'intérêt d'utiliser un intervalle plus petit et 
     356   impliquant 
    352357   de toute façon plus d'entrées/sorties au niveau disque. 
    353358  </para> 
    …… 
    356361   Les points de contrôle sont assez coûteux, tout d'abord parce qu'ils 
    357362   écrivent tous les tampons utilisés, et ensuite parce que cela suscite un 
    358    trafic WAL supplémentaire comme indiqué ci-dessus. Du coup, il est conseillé 
     363   trafic supplémentaire dans les journaux de transaction, comme indiqué 
     364   ci-dessus. Du coup, il est conseillé 
    359365   de configurer les paramètres en relation assez haut pour que ces points de 
    360    contrôle ne surviennent pas trop fréquemment. En tant que simple vérification 
    361    de santé de vos paramètres, vous pouvez configurer le paramètre <xref 
     366   contrôle ne surviennent pas trop fréquemment. Pour une vérification 
     367   rapide de l'adéquation de vos paramètres, vous pouvez configurer le 
     368   paramètre <xref 
    362369   linkend="guc-checkpoint-warning"/>. Si les points de contrôle arrivent plus 
    363    rapidement que <varname>checkpoint_warning</varname> secondes, un message sera 
    364    affiché dans les journaux du serveur recommandant d'accroître 
     370   rapidement que <varname>checkpoint_warning</varname> secondes, un message 
     371   est affiché dans les journaux applicatifs du serveur recommandant d'accroître 
    365372   <varname>checkpoint_segments</varname>. Une apparition occasionnelle d'un 
    366373   message ne doit pas vous alarmer mais, s'il apparaît souvent, alors les 
    367374   paramètres de contrôle devraient être augmentés. Les opérations en masse, 
    368    comme les gros transferts via <command>COPY</command>, pourraient être la cause 
     375   comme les transferts importants de données via <command>COPY</command>, 
     376   pourraient être la cause 
    369377   de l'apparition d'un tel nombre de messages d'avertissements si 
    370378   vous n'avez pas configuré <varname>checkpoint_segments</varname> avec une valeur 
    …… 
    399407 
    400408  <para> 
    401    Il y aura toujours au moins un fichier segment WAL et normalement 
     409   Il y aura toujours au moins un journal de transaction et normalement 
    402410   pas plus de (2 + <varname>checkpoint_completion_target</varname>) * 
    403    <varname>checkpoint_segments</varname> + 1 
    404    fichiers.  Chaque fichier de segment fait normalement 16&nbsp;Mo (bien 
    405    que cette taille puisse être modifiée lors de la compilation du serveur). Vous pouvez 
    406    utiliser cela pour estimer l'espace disque 
    407    nécessaire pour <acronym>WAL</acronym>. D'habitude, quand les vieux fichiers  
    408    segment de journaux ne sont plus nécessaires, ils sont recyclés 
     411   <varname>checkpoint_segments</varname> + 1 journaux. 
     412   Chaque journal fait normalement 16&nbsp;Mo (bien 
     413   que cette taille puisse être modifiée lors de la compilation du serveur). 
     414   Vous pouvez utiliser cela pour estimer l'espace disque nécessaire au 
     415   stockage des journaux de transaction. D'habitude, quand les vieux journaux 
     416   ne sont plus nécessaires, ils sont recyclés 
    409417   (renommés pour devenir les prochains segments dans une séquence 
    410418   numérotée).  S'il y a plus de 3 * <varname>checkpoint_segments</varname> + 1 
    411    fichiers segments à cause d'un pic temporaire du taux d'écriture des journaux, 
     419   fichiers à cause d'un pic temporaire du taux d'écriture des journaux, 
    412420   ceux inutilisés seront effacés au lieu d'être 
    413421   recyclés jusqu'à ce que le système soit en-dessous de cette limite. 
    …… 
    415423 
    416424  <para> 
    417    Il y a deux fonctions <acronym>WAL</acronym> internes couramment 
     425   Il existe deux fonctions <acronym>WAL</acronym> internes couramment 
    418426   utilisées&nbsp;: 
    419427   <function>LogInsert</function> et <function>LogFlush</function>. 
    …… 
    422430   partagée. S'il n'y a plus 
    423431   d'espace pour une nouvelle entrée, <function>LogInsert</function> 
    424    devra écrire (bouger dans le cache du noyau) quelques tampons 
    425    <acronym>WAL</acronym> remplis.  Ceci n'est pas désirable parce que 
     432   devra écrire (autrement dit, déplacer dans le cache du noyau) quelques 
     433   tampons <acronym>WAL</acronym> remplis.  Ceci n'est pas désirable parce que 
    426434   <function>LogInsert</function> est utilisée lors de chaque 
    427    modification bas niveau de la base (par exemple, insertion d'une 
     435   modification bas niveau de la base (par exemple, lors de l'insertion d'une 
    428436   ligne) quand un verrou exclusif est posé sur des pages de données 
    429    affectées, donc l'opération nécessite d'être aussi rapide que 
    430    possible.  Pire encore, écrire des tampons <acronym>WAL</acronym> 
    431    peut aussi forcer la création d'un nouveau segment de journal ce qui 
     437   affectées. À cause de ce verrou, l'opération doit être aussi rapide 
     438   que possible.  Pire encore, écrire des tampons <acronym>WAL</acronym> 
     439   peut forcer la création d'un nouveau journal, ce qui 
    432440   peut prendre beaucoup plus de temps.  Normalement, les tampons 
    433    <acronym>WAL</acronym> devraient être écrits et vidés par une requête 
     441   <acronym>WAL</acronym> doivent être écrits et vidés par une requête 
    434442   de <function>LogFlush</function> qui est faite, la plupart du 
    435443   temps, au moment de la validation d'une transaction pour assurer 
    …… 
    438446   les requêtes de <function>LogFlush</function> peuvent ne pas 
    439447   arriver assez souvent pour empêcher <function>LogInsert</function> d'avoir 
    440    à écrire.  Sur de tels systèmes, on devrait augmenter le nombre de tampons 
     448   à écrire lui-même sur disque.  Sur de tels systèmes, on devrait augmenter le 
     449   nombre de tampons 
    441450   <acronym>WAL</acronym> en modifiant le paramètre de configuration <xref 
    442451   linkend="guc-wal-buffers"/>. Par défaut, le nombre de tampons est de 8.  
    443    Augmenter cette valeur augmentera considérablement l'utilisation de la 
     452   Réhausser cette valeur augmente considérablement l'utilisation de la 
    444453   mémoire partagée. Quand <xref linkend="guc-full-page-writes"/> est configuré 
    445454   et que le système est très occupé, configurer cette variable avec une valeur 
    446    plus importante aidera à avoir des temps de réponse plus réguliers 
     455   plus importante aide à avoir des temps de réponse plus réguliers 
    447456   lors de la période suivant chaque point de vérification. 
    448457  </para> 
    449458 
    450459  <para> 
    451    Le paramètre <xref linkend="guc-commit-delay"/> définit combien de 
    452    micro-secondes le processus serveur dormira après l'écriture d'une 
    453    entrée de validation dans le journal avec 
     460   Le paramètre <xref linkend="guc-commit-delay"/> définit la durée 
     461   d'endormissement en micro-secondes du processus serveur après l'écriture 
     462   d'une entrée de validation dans le journal avec 
    454463   <function>LogInsert</function> avant d'exécuter un  
    455464   <function>LogFlush</function>.  Ce délai permet aux autres 
    456465   processus du serveur d'ajouter leurs entrées de validation dans le 
    457    fichier de journal afin de tout écrire vers le disque avec une seule 
     466   journal afin de tout écrire vers le disque avec une seule 
    458467   synchronisation du journal.  Aucune mise en sommeil n'aura lieu si 
    459468   <xref linkend="guc-fsync"/> n'est pas disponible ou si moins de 
    …… 
    462471   il est improbable qu'une autre session fasse bientôt une 
    463472   validation.  Notez que dans la plupart des plate-formes, la 
    464    résolution d'une requête de sommeil est de 10 millisecondes, donc 
     473   résolution d'une requête d'endormissement est de 10 millisecondes, donc 
    465474   un <varname>commit_delay</varname> différent de zéro et configuré 
    466    entre 1 et 10000 micro-secondes aura le même effet.  Les bonnes 
     475   entre 1 et 10000 micro-secondes a le même effet.  Les bonnes 
    467476   valeurs pour ce paramètre ne sont pas encore claires&nbsp;; les essais 
    468477   sont encouragés. 
    …… 
    470479 
    471480  <para> 
    472    Le paramètre <xref linkend="guc-wal-sync-method"/> détermine comment  
    473    <productname>PostgreSQL</productname> demandera au noyau de forcer les mises 
    474    à jour <acronym>WAL</acronym> sur le disque. Toutes les options devraient 
    475    être les mêmes dans la mesure où la fiabilité ne disparaît pas, 
    476    mais c'est avec des options spécifiques à la plate-forme que ça 
    477    sera le plus rapide.  Notez que ce paramètre est ignoré si 
     481   Le paramètre <xref linkend="guc-wal-sync-method"/> détermine la façon dont 
     482   <productname>PostgreSQL</productname> demande au noyau de forcer les mises 
     483   à jour des journaux de transaction sur le disque. Toutes les options 
     484   ont un même comportement dans la mesure où la fiabilité ne disparaît pas, 
     485   mais c'est avec des options spécifiques à la plate-forme que la rapidité 
     486   la plus importante sera observée.  Notez que ce paramètre est ignoré si 
    478487   <varname>fsync</varname> a été désactivé. 
    479488  </para> 
    480489 
    481   <para> 
    482    Configurer le paramètre <xref linkend="guc-wal-debug"/> avec une 
    483    valeur différente de zéro aura pour résultat d'enregistrer dans les 
    484    journaux du serveur l'appel WAL à chaque <function>LogInsert</function> 
    485    et <function>LogFlush</function>.  En ce moment, il n'est fait 
    486    aucune différence entre les valeurs supérieures à zéro.  Cette 
    487    option pourra être remplacée par un mécanisme plus général dans le 
    488    futur. 
    489   </para> 
    490490   <para> 
    491491   Activer le paramètre de configuration <xref linkend="guc-wal-debug"/> (à 
    492492   supposer que <productname>PostgreSQL</productname> ait été compilé avec le 
    493    support de ce paramètre) résultera dans l'enregistrement de chaque appel 
     493   support de ce paramètre) permet d'enregistrer chaque appel 
    494494   <acronym>WAL</acronym> à <function>LogInsert</function> et 
    495    <function>LogFlush</function> dans les journaux du serveur. Cette option 
     495   <function>LogFlush</function> dans les journaux applicatifs du serveur. 
     496   Cette option 
    496497   pourrait être remplacée par un mécanisme plus général dans le futur. 
    497498  </para> 
    …… 
    499500 
    500501 <sect1 id="wal-internals"> 
    501   <title>Vue interne des WAL</title> 
    502  
    503   <para> 
    504    <acronym>WAL</acronym> est automatiquement disponible&nbsp;; aucune 
    505    action n'est requise de la part de l'administrateur excepté 
    506    de s'assurer que l'espace disque requis par les journaux 
    507    WAL soit présent et que tous les réglages soient faits (regardez 
     502  <title>Vue interne des journaux de transaction</title> 
     503 
     504  <para> 
     505   Le mécanisme <acronym>WAL</acronym> est automatiquement disponible&nbsp;; 
     506   aucune action n'est requise de la part de l'administrateur excepté 
     507   de s'assurer que l'espace disque requis par les journaux de transaction 
     508   soit présent et que tous les réglages soient faits (regardez 
    508509   la <xref linkend="wal-configuration"/>). 
    509510  </para> 
    510511 
    511512  <para> 
    512    Les journaux <acronym>WAL</acronym> sont stockés dans le répertoire 
     513   Les journaux de transaction sont stockés dans le répertoire 
    513514   <filename>pg_xlog</filename> sous le répertoire de données, comme un ensemble 
    514    de fichiers segments, chacun d'une taille de 16&nbsp;Mo généralement. Chaque 
    515    segment est divisé en pages de généralement 8&nbsp;Ko. Les en-têtes de 
     515   de fichiers, chacun d'une taille de 16&nbsp;Mo généralement. Chaque 
     516   fichier est divisé en pages de généralement 8&nbsp;Ko. Les en-têtes de 
    516517   l'entrée du journal sont décrites dans 
    517518   <filename>access/xlog.h</filename>&nbsp;; le contenu de l'entrée dépend 
    518    du type de l'événement qui est enregistré.  Les fichiers segments 
    519    sont nommés avec un chiffre qui est toujours incrémenté et qui 
     519   du type de l'événement qui est enregistré.  Les fichiers 
     520   sont nommés suivant un nombre qui est toujours incrémenté et qui 
    520521   commence à <filename>000000010000000000000000</filename>.  Les nombres ne 
    521522   bouclent pas actuellement, mais cela devrait prendre beaucoup de temps 
    …… 
    524525 
    525526  <para> 
    526    Il est avantageux que le journal soit situé sur un autre disque que 
     527   Il est avantageux que les journaux soient situés sur un autre disque que 
    527528   celui des fichiers principaux de la base de données.  Cela peut 
    528    se réaliser en déplaçant le répertoire 
     529   se faire en déplaçant le répertoire 
    529530   <filename>pg_xlog</filename> vers un autre emplacement (alors que 
    530    le serveur est arrêté, naturellement) et en créant un lien 
     531   le serveur est arrêté) et en créant un lien 
    531532   symbolique de l'endroit d'origine dans le répertoire principal de 
    532533   données au nouvel emplacement. 
    …… 
    536537   Le but de <acronym>WAL</acronym>, s'assurer que le journal est écrit 
    537538   avant l'altération des entrées dans la base, peut être mis en échec par 
    538    les lecteurs des disques<indexterm><primary>disques durs</primary></indexterm> qui 
    539    faussement rapportent une écriture 
     539   les disques<indexterm><primary>disques durs</primary></indexterm> qui 
     540   rapportent une écriture 
    540541   réussie au noyau quand, en fait, ils ont seulement mis en cache 
    541    les données et ne les ont pas encore stockées sur le disque.  Une 
     542   les données et ne les ont pas encore stockés sur le disque.  Une 
    542543   coupure de courant dans ce genre de situation peut toujours mener à 
    543    la corruption irrécupérable des données.  Les administrateurs 
    544    devraient s'assurer que les disques contenant les journaux 
    545    <acronym>WAL</acronym> de <productname>PostgreSQL</productname> ne 
     544   une corruption irrécupérable des données.  Les administrateurs 
     545   devraient s'assurer que les disques contenant les journaux de 
     546   transaction de <productname>PostgreSQL</productname> ne 
    546547   produisent pas ce genre de faux rapports. 
    547548  </para> 
    …… 
    551552   écrit, la position du point de contrôle est sauvegardée dans le 
    552553   fichier <filename>pg_control</filename>.  Donc, quand la 
    553    restauration doit être faite, le serveur lit en premier 
     554   restauration doit se faire, le serveur lit en premier 
    554555   <filename>pg_control</filename> et ensuite l'entrée du point de 
    555556