[Trad] [svn:pgfr] r1365 - traduc/trunk/slony
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Ven 24 Juil 09:25:07 CEST 2009
Author: daamien
Date: 2009-07-24 09:25:07 +0200 (Fri, 24 Jul 2009)
New Revision: 1365
Modified:
traduc/trunk/slony/faq.xml
Log:
relecture faq.xml (70%)
Modified: traduc/trunk/slony/faq.xml
===================================================================
--- traduc/trunk/slony/faq.xml 2009-07-19 18:34:53 UTC (rev 1364)
+++ traduc/trunk/slony/faq.xml 2009-07-24 07:25:07 UTC (rev 1365)
@@ -836,6 +836,7 @@
</para>
</answer>
+<!--TODO-->
<answer> <para>(Les commentaires de Jan Wieck:) L'ordre des ID des tables
a une importance uniquement lors d'une opération de <xref linkend="stmtlockset"/> en préparation de basculement.
Si l'ordre est différent de celui selon lequel les applications obtiennent des verrous,
@@ -959,97 +960,86 @@
</qandaentry>
</qandadiv>
-<qandadiv id="faqperformance"> <title> &slony1; FAQ: Performance Issues </title>
+<START>
+
+<qandadiv id="faqperformance"> <title> &slony1; FAQ: Problèmes de Performances </title>
+
<qandaentry id="longtxnsareevil">
-<question><para> Replication has been slowing down, I'm seeing
-<command> FETCH 100 FROM LOG </command> queries running for a long
-time, <xref linkend="table.sl-log-1"/> is growing, and performance is,
-well, generally getting steadily worse. </para>
+<question><para> La réplication ralentit, je vois des requêtes <command> FETCH 100 FROM LOG </command> très longues , la table <xref linkend="table.sl-log-1"/> grossit, et les performances se dégradent de manière continue. </para>
</question>
-<answer> <para> Les causes de ce genre de choses sont multiples.
-Il y a une question évoquée par ce genre de pathologie, où le problème d'augmentation du volume dans
+<answer> <para> Il y a beaucoup de causes possibles pour ce genre de choses.
+Il s'agit de même genre de pathologies qui entrainent l'augmentation du volume dans
<link linkend="pglistenerfull">
-&pglistener; est dû au fait que la purge via vaccume n'est pas exécutée.</link>
+&pglistener; lorsque la purge via vacuum n'est pas exécutée.</link>
</para>
-<para> Par rapprochement <quote> on peut avancer </quote>, pour cette augmentation de volume,
-est que une session existante sur le serveur rend le noeud
+<para> Par rapprochement <quote> on peut avancer </quote>, que cette augmentation de volume,
+est due à une session existante sur le serveur rend le noeud
<command>
-IDLE IN TRANSACTION </command> pour une durée infinie. </para>
+IDLE IN TRANSACTION </command> pour une durée très longue. </para>
-<para> La session ouverte peut avoir des effets négatifs,
-entraînant une dégradation de performances.</para>
+<para> Cette transaction ouverte peut avoir de multiples effets négatifs,
+chacun entrainant une dégradation de performances.</para>
<itemizedlist>
<listitem><para> Le fait de lancer un Vacuum sur la totalité des tables,
-&pglistener; y compris, ne va pas nettoyer les tuplets pour les transactions qui sont ouvertes et disponible, car elle
-viennent de démarrer. </para> </listitem>
+&pglistener; y compris, ne va pas nettoyer les tuples morts après après le début de la transaction en attente. </para> </listitem>
-<listitem><para> Le nettoyage des processus ne pourra pas se faire
-sur les entrées dans <xref linkend="table.sl-log-1"/> et <xref
+<listitem><para> Le processus de nettoyage ne pourra pas se supprimer les entrées dans <xref linkend="table.sl-log-1"/> et <xref
linkend="table.sl-seqlog"/>, qui entraîne par conséquence, une croissance
-de volume tant que les transactions persistent. </para>
+de volume tant que la transaction persiste. </para>
</listitem>
</itemizedlist>
</answer>
-<answer> <para> Vous pouvez surveiller, dans la base, ces conditions que si
-dans le fichier d'initialisation de &postgres; <filename> postgresql.conf </filename>
+<answer> <para> Vous pouvez surveiller cette situation, uniquement si
+dans le fichier de configuration de &postgres; <filename> postgresql.conf </filename>
le paramètre <envar>stats_command_string</envar> est positionner à vrai.
Dans ce cas, vous pouvez lancer une intérrogation sql comme suit :
<command> select * from pg_stat_activity where current_query like '%IDLE% in transaction';
-</command> dont le résultat vous donnent les activités relatives. </para> </answer>
+</command> dont le résultat vous donnent les transactions en activités. </para> </answer>
-<answer> <para> Vous devrez également être capable de rechercher
+<answer> <para> Vous pouvez également rechercher
les <quote> idle in transaction </quote> dans la table des processes
-ceux qui détiennent encore des transactions actives.
+ceux qui détiennent encore des transactions anciennes.
</para> </answer>
-<answer> <para> Il est aussi possible (quoique plus rare)que le problème soit causé par
-une transaction, qui pour d’autres raisons, est conservée comme ouverte et ceci pour une longue durée.
-La table <envar> query_start </envar> time in <envar>
-pg_stat_activity </envar> vous présentra les longues requêtes qui sont dans cet état. </para> </answer>
+<answer> <para> Il est aussi possible (quoique plus rare) que le problème soit causé par
+une transaction, qui pour d'autres raisons, est conservée comme ouverte et ceci pour une longue durée.
+La valeur <envar> query_start </envar> dans la table <envar>
+pg_stat_activity </envar> vous présentra les longues requêtes qui s'exécutent depuis longtemps. </para> </answer>
-<answer> <para> Il est prévue que &postgres; aie un paramètre d'expiration de
-délai, <envar> open_idle_transaction_timeout </envar>, qui permettrais
-de venir à bout des transactions dont le temps arrivent à échéance.
+<answer> <para> Il est prévu que &postgres; ait un paramètre d'expiration de
+délai, <envar> open_idle_transaction_timeout </envar>, qui permettrait de venir à bout des transactions après une certaine période.
-Le concept de connexion par pool, engendre ce genre de situation d'erreur.
-Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
-</link> </productname> devrait présenter des meilleurs alternatifs afin de mieux gérer les connexion partagée à
-travers la notion de 'pool'.
-Cela devrez faire diminuer les bugs rencontrés dans les applications
+Les pool de connexions peuvent engendrer ce genre de situation d'erreurs. Il est prévu des amélioration où <productname> <link linkend="pgpool"> pgpool
+</link> </productname> devrait présenter des meilleurs alternatives afin de mieux gérer les connexions partagées.
+Il existe des pools de connexions plus ou moins buggués dans les applications
Java ou PHP;si un nombre restreint de <emphasis> vrai </emphasis>
connections sont conservées dans<productname>pgpool</productname>, ceci va faire croire à la base,
-que en réalité les connexions de l'application reste dans un statut
-disponible et en activité, pour de
-
-J'avis lancé I have been running &slony1; on a node for a while, and am
-s heures durant.
+qu'en réalité les connexions de l'application reste dans un statut disponible et en activité, pendant des heures.
</para> </answer>
</qandaentry>
<qandaentry id="faq17">
-<question><para>Après une suppression de noeud, le fichier journal <xref linkend="table.sl-log-1"/>
-n'est plus purgé.</para></question>
+<question><para>Après une suppression de noeud, la table <xref linkend="table.sl-log-1"/>
+n'est plus purgée.</para></question>
-<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, comme
-le <quote>nettoyage</quote> du prend effet en oubliant les entrées des
- tables &slony1; <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
+<answer><para> Ceci est un scénario commun dans les versions d'avant 1.0.5, en effet
+le <quote>nettoyage</quote> du noeud oublie les vieilles entrées de la table <xref linkend="table.sl-confirm"/>, pour le serveur qui vient de disparaître.</para>
-<para> Le noeud ne s'occupe plus de mettre à jour des confirmations, comme quoi
-syncs vient de s'effectuer sur ce serveur, car il estime qu'il ne peut sans risque supprimer les entrées plus récentes
-que la dernière <xref linkend="table.sl-confirm"/> entrée, qui plutôt
-limite la capacité de purge des anciens fichiers journaux.</para>
+<para> Le noeud n'est plus présent et n'envoie plus les confirmations annonçant les syncs qui viennent de s'effectuer sur ce serveur,
+et le processus de nettoyage estime qu'il ne peut supprimer sans risque les entrées plus récentes
+que la dernière entrée de la <xref linkend="table.sl-confirm"/> , ce qui limite nettement la capacité de purge des anciens journaux.</para>
<para>Diagnostics: Exécuter les requêtes suivantes pour voir si il y a
-un résidus d'entrées en état de <quote>fantôme/obsolète/bloqué</quote> <xref
+un résidus d'entrées en état <quote>fantôme/obsolète/bloqué</quote> dans la table <xref
linkend="table.sl-confirm"/>:
<screen>
@@ -1065,11 +1055,9 @@
(6 rows)
</screen></para>
-<para>En version 1.0.5, la fonction <xref linkend="stmtdropnode"/>
+<para>Dans la version 1.0.5, la fonction <xref linkend="stmtdropnode"/>
purges les données dans <xref linkend="table.sl-confirm"/> pour le noeud qui quitte la configuration.
-Dans les versions plus anciennes, cposés par quelques tables du groupe de réplication ? Cela bloquerait invisiblement That would somewhat-invisibly
-eci demande une exécution manuelle.
-Supposons que l'identifiant du noeud soit 3, alors la requête sera la suivante :
+Dans les versions plus anciennes, il faut faire cela à la main. Supposons que l'identifiant du noeud soit 3, alors la requête serait la suivante :
<screen>
@@ -1083,24 +1071,18 @@
</screen></para>
<para>Une <quote>raisonnable diligence</quote> dicterait de commencer par
-<command>BEGIN</command>, voir le contenu de<command>SYNC</command> de se mettre à jour à l'origine, via le planificateur to be updated on the origin based on a
-
-<xref linkend="table.sl-confirm"/> avant,
+<command>BEGIN</command> et vérifier le contenu des <command>SYNC</command> dans la table <xref linkend="table.sl-confirm"/> avant de les purger, puis de valider l'opération par un <command>COMMIT</command>. Si
+vous supprimer par erreur les données d'un autre noeud, votre journée est perdue le temps de rattraper l'erreur commise.</para>
-Quelque noeud commencent à prendre du retard Some nodes start consistently falling behind
-en veillant à ce que seul les bons enregistrements
-sont purgés, et puis, seulement après avoir vérifier cette suppression, valider l'opération par une <command>COMMIT</command>. Si
-vous supprimer par erreur les données d'un autre noeud, votre journée est perdu le temps de rattraper l'erreur commise.</para>
-
<para>Vous aurez besoin d'exécuter cette opération, sur chaque noeud qui reste...</para>
-<para>A noter que dans la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
-de <xref linkend="table.sl-confirm"/> à deux endroits :
+<para>A noter qu'à partir de la version 1.0.5, ce n'est plus un problème, car il purge les entrées inutiles
+de <xref linkend="table.sl-confirm"/> à deux instants :
<itemizedlist>
<listitem><para> Lorsque un noeud est supprimé</para></listitem>
-<listitem><para> Au démarrage de chaque lancement de
+<listitem><para> Au démarrage de chaque
<function>cleanupEvent</function>, qui est l'évènement qui purge les vieilles données de
<xref linkend="table.sl-log-1"/> et de <xref
linkend="table.sl-seqlog"/></para></listitem> </itemizedlist></para>
@@ -1109,24 +1091,22 @@
<qandaentry>
-<question><para>Le <application>slon</application> se dépense un week-end entier hors de la
-commission [for some reason], et il prend énormément de temps pour exécuter un
+<question><para>Le <application>slon</application> était éteint ce week-end , et désormais il lui faut énormément de temps pour exécuter un
sync.</para></question>
-<answer><para> Vous pourriez jeter un coup d'oeil, sur les tables <xref
+<answer><para> Jetez un coup d'oeil, sur les tables <xref
linkend="table.sl-log-1"/>/<xref linkend="table.sl-log-2"/>,
-et voir brièvement si il y a réellement un énorme &slony1;
-encours d'exécution. Jusqu'au au moins la version 1.0.2, il faut qu'il y ait un
-&lslon; connecté pour que <command>SYNC</command> soit encours.</para>
+ pour voir brièvement si il y a une énorme transaction
+en cours d'exécution. Jusqu'à la version 1.0.2, il faut qu'il y ait un
+&lslon; connecté au noeud origine pour que les événements <command>SYNC</command> soient générés.</para>
-<para>Si cet évènement n'est pas généré, alors toute la mise à jour, et celle-ci jusqu'au prochain évènement va se faire
-à travers un énorme transaction &slony1;.</para>
+<para>Si aucun évènement n'est généré, alors toute les mises à jour jusqu'au prochain évènement seront aggrégées dans une énorme transaction &slony1;.</para>
-<para>Conclusion: Même si il n'y a pas d'abonné en cause,
-vous avez <emphasis>vraiment</emphasis> besoin d'un
-<application>slon</application> en fonctionnement pour entretenir le noeud source.</para>
+<para>Conclusion: Même si il n'y a pas d'abonné dans votre réplication,
+vous avez <emphasis>vraiment</emphasis> mettre en place un
+<application>slon</application> pour qu'il se connecte au noeud origine.</para>
-<para>&slony1; 1.1 fournit une procédure stockée qui permet aux comptes Synchros d'être
+<para>&slony1; 1.1 fournit une procédure stockée qui permet aux SYNCs d'être
mis à jour par le planificateur <application>cron</application>même si <xref
linkend="slon"/> ne tourne pas en tâche de fond.</para> </answer></qandaentry>
@@ -1141,69 +1121,61 @@
fetch 100 from LOG;
</screen></para></question>
-<answer><para> Ceci peut être un exemple type de &pglistener; (la table qui contient les données de
-<command>NOTIFY</command>)avec en abondance, des données obsolètes des tuplets mortes.
+<answer><para> Typiquement ceci peut se produire lorsque &pglistener; (la table qui contient les données de
+<command>NOTIFY</command>) est rempplie de tuple morts.
-Ce qui fait que l'évènement <command>NOTIFY</command> prend du temps,
+Ce qui fait que les évènements <command>NOTIFY</command> prend du temps,
et cause le ralentissement de plus en plus fort du noeud affecté.</para>
<para>Vous avez probablement besoin d'effectuer un <command>VACUUM FULL</command> sur
-&pglistener;, pour le nettoyer vigoureusement, et besoin de purger
+&pglistener;, pour le nettoyer vigoureusement, puis d'effectuer un vacuum simple sur
&pglistener; vraiment fréquemment. Une planification tous les cinq minutes fera l'affaire.</para>
-<para> Le démon Slon fait déjà une purge d'un groupe de table,et
+<para> Les démons Slon font déjà un vacuum sur beaucoup de tables ,et
<filename>cleanup_thread.c</filename> contient une liste de tables à nettoyer fréquemment de manière automatique.
-Dans &slony1; 1.0.2,&pglistener; ceci n'est pas inclus. Dans 1.0.5 et supérieur, il est purgé régulièrement,
+Dans &slony1; 1.0.2,&pglistener; n'est pas inclus. Dans la version 1.0.5 et supérieure, il est purgé régulièrement,
du coup ce problème n'a plus le lieu d'être. Dans la version 1.2,
-&pglistener; sera seulement utilisé quand le noeud reçoit périodiquement l'évènement,
+&pglistener; est seulement utilisé quand le noeud reçoit périodiquement l'évènement,
ce qui signifie que ce problème la plupart du temps disparaître même
en présence des transaction longues et lentes...</para>
<para>Il y a, cependant, toujours un scénario où ceci peut
-<quote>mordre toujours.</quote> Sous MVCC, vacuums ne peut pas supprimer des tuplets qui sont rendus
+<quote>surgir</quote>. Pour respecter le MVCC, les vacuums ne peuvent pas supprimer des tuples qui sont rendus
<quote>obsolètes</quote> à n'importe quel moment après le démarrage de la transaction la plus ancienne
qui reste encore ouverte. Les transactions longues, devront être évitées, car elles sont sources de soucis,
-même sur un serveur abonné.</para> </answer></qandaentry>
+même sur les noeuds abonnés.</para> </answer></qandaentry>
-<qandaentry> <question> <para> J'ai soumis un requête <xref
+<qandaentry> <question> <para> J'ai soumis une requête <xref
linkend="stmtmoveset"/> / <xref linkend="stmtddlscript"/>, et
-elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne mon
+elle semble être coincée, sur mon serveur. Les journaux de &slony1; ne montre aucun avertissement et aucune erreur.
+ </para> </question>
-La <command>restitution depuis LOG</command> procède à lire query will draw
-trent
-pas d'qui est défini dans le fichier which is defined in the
-erreurs ni d'avertissement </para> </question>
-
-<answer> <para> Il est possible que vous soyez en train d'exécuter
-<application>pg_autovacuum</application>, et qu'l soit tombait sur des verrous
-posés par des tables dans le groupe de réplication ? Ceci voudra dire que de manière silencieuse
-ock &slony1; est bloqué d'effectuer des opérations qui exigent l'acquisition des <link
+<answer> <para> Peut-être que
+<application>pg_autovacuum</application> est en cours d'exécution, et qu'il a posé
+des verrous sur des tables dans l'ensemble de réplication ? Ceci entraine manière silencieuse le blocage de &slony1;
+en l'empêchant d'effectuer les opérations qui exigent l'acquisition des <link
linkend="locking"> exclusifs. </link> </para>
-<para> Vous pourriez vérifier ce genre de verrous à l'aide de cette requête :
+<para> Vous pourriez vérifier la présence de ce genre de verrous à l'aide de cette requête :
<command> select l.*, c.relname from pg_locks l, pg_class c
-where c.oid = l.relation ; </command> Un verrous
-<envar>ShareUpdateExclusiveLock</envar> va bloquer les opérations de &slony1;
-qui nécessitent leurs propres verrous exclusifs, qui sont probablement en attentes,
-marqués comme n'étant pas garantis. </para>
+where c.oid = l.relation ; </command> Un verrou
+<envar>ShareUpdateExclusiveLock</envar> peut bloquer les opérations de &slony1;
+qui nécessitent leurs propres verrous exclusifs, et les mettre en en attentes et marquées comme non-validées. </para>
</answer> </qandaentry>
<qandaentry>
-<question><para> Je remarque que dans les journaux d'un &lslon; l'état commute fréquent
-entre le <quote>vote</quote> démarré et arrêt.
-reporté fréquemment <quote>LISTEN - switch from polling mode to use
+<question><para> Je remarque que dans les journaux, qu'un &lslon; change d'état fréquemment : <quote>LISTEN - switch from polling mode to use
LISTEN</quote> et <quote>UNLISTEN - switch into polling
mode</quote>. </para> </question>
<answer><para> Les seuils pour commuter entre ces modes sont commandés par
-le paramètres de configuration <xref
-linkend="slon-config-sync-interval"/> et celui de <xref
+les paramètres de configuration <xref
+linkend="slon-config-sync-interval"/> et <xref
linkend="slon-config-sync-interval-timeout"/>; si la valeur du temps d'expiration
-(par défaut étant à 10000, impliquant 10s) est maintenu bas, facilite la situation pour que
-&lslon; décide de retourner à l'état <quote>listening</quote>.
+(par défaut étant à 10000, impliquant 10s) est maintenu bas, cela encourage le &lslon; à retourner dans l'état <quote>d'écoute</quote>.
Vous devriez augmenter cette valeur d'expiration de temps. </para>
</answer>
</qandaentry>
@@ -1212,26 +1184,25 @@
</qandadiv>
<qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs dans les versions anciennes</title>
<qandaentry>
-<question><para>Le process &lslon; processes entretenant mes abonnés devient énorme en taille
-, mettant en danger la ressource du système en terme de swap ainsi que le risque d'attendre la taille limite
-de 2GB par processe . </para>
+<question><para>Les processus &lslon; gérant mes abonnés devient énorme, mettant en danger la ressource du système en terme de swap ainsi que le risque d'atteindre la taille limite
+de 2GB par processus . </para>
<para> D'ailleurs, les données que je suis en train de répliquer,
ont une taille assez grande. Il y a des enregistrements dont la taille
-dépasse des dizaine de mega octets.Peut-être ceci n'est pas approprié ? </para> </question>
+dépasse des dizaine de megaoctets. Peut-être que c'est lié ? </para> </question>
<answer> <para> Oui, ces enregistrements volumineux sont à la racine du problème.
-L'explication vient du fait que &lslon; normalement procède par paquet de
- 100 enregistrement à la fois, lorsqu'un abonné fait des interrogation depuis le fournisseur.
+Le problème vient du fait que &lslon; normalement procède par paquet de
+ 100 enregistrements à la fois, lorsqu'un abonné charge des données depuis le fournisseur.
Ainsi si la taille moyenne des enregistrements est de
-is 10MB, ceci entraîne des données atteignant 1000MB qui sont en attente de
- <command>INSERT</command> ou de <command>UPDATE</command>
-à procéder par le processe &lslon;.</para>
+is 10MB, ceci entraîne des paquets de données atteignant 1000MB qui sont ensuite transformés en
+ <command>INSERT</command> ou en <command>UPDATE</command>
+dans la mémoire du processus &lslon;.</para>
-<para> Cela mène évidemment à &lslon; d'atteindre des tailles gigantesques. </para>
+<para> Cela mène évidemment &lslon; à des tailles gigantesques. </para>
-<para> Nombre d'enregistrement restitués par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
-défini par le fichier <filename>src/slon/slon.h</filename>. La partie extraite appropriée à ce paramètre est :
+<para> Le nombre d'enregistrement regroupés est controllé par la valeur <envar> SLON_DTA_FETCH_SIZE </envar>,
+définie dans le fichier <filename>src/slon/slon.h</filename>. Voici un extrait de ce fichier contenant ce paramètre :
</para>
<programlisting>
@@ -1247,128 +1218,122 @@
</programlisting>
<para> Si vous rencontrez ce problème, vous devriez définir
- <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être réduit par un facteur de 10
- 10, et de recompiler ensuite &lslon;. Il y a deux
-définitions dont <envar> SLON_CHECK_CMDTUPLES</envar> qui laisse faire une certaine surveillance
-supplémentaire pour s'assurer que le abonnés ne sont pas tombé hors de la
-SYNC en regard du fournisseur. Par défaut, cette option est désactivée, ainsi il faudra prendre la deuxième option,
-afin de modifier la valeur par defeuillé, il faudra changer
-<envar> SLON_DATA_FETCH_SIZE </envar> pour remplacer 10 par 1. </para> </answer>
+ <envar> SLON_DATA_FETCH_SIZE </envar>, peut-être le réduire par un facteur de 10, et recompiler ensuite &lslon;.
+L'activation de <envar> SLON_CHECK_CMDTUPLES</envar> permet de faire une surveillance
+supplémentaire pour s'assurer que les abonnés ne sont pas désynchronisés par
+rapport au fournisseur. Par défaut, cette option est désactivée, donc la modification par défaut consiste réduire la seconde définition de
+<envar> SLON_DATA_FETCH_SIZE </envar> en remplaçant 10 par 1. </para> </answer>
<answer><para> Dans la version 1.2, la configuration des valeurs de<xref
linkend="slon-config-max-rowsize"/> et de <xref
-linkend="slon-config-max-largemem"/> sont associées avec un nouveau algorithme
-qui change la logique des choses, plutôt que de restituer 100
-enregistrements à la fois.</para>
+linkend="slon-config-max-largemem"/> sont associées avec un nouvel algorithme
+qui change la logique des choses. Plutôt que de restituer 100
+enregistrements à la fois :</para>
<itemizedlist>
<listitem><para> La lecture de <command>fetch from LOG</command> se fera
par paquet de 500 enregistrements à la fois, tant que la taille n'excède pas
-<xref linkend="slon-config-max-rowsize"/>. Avec une valeur par défaut, ceci limitera
-ce phénomène de consommation de mémoire à la hauteur de 8MB. </para>
+<xref linkend="slon-config-max-rowsize"/>. Avec les valeurs par défaut, ceci limitera
+ce phénomène de consommation de mémoire à un plafond de 8MB. </para>
</listitem>
-<listitem><para> Les tuplets sont lus jusqu'à ce que la taille n'excède pas
+<listitem><para> Les tuples sont lus jusqu'à ce que la taille n'excède pas
le paramètre <xref linkend="slon-config-max-largemem"/>. Par défaut, cette restriction
-ne consommera pas environ 5MB. Cette valeur n'est pas un seil de limitation stricte;
-si vous avez des tuplets dont la taille est de 50MB, il <emphasis>doit</emphasis> de manière forcée,
-être charger en mémoire. Il n'est pas question de négliger cela.
+ne consommera pas plus de 5MB. Cette valeur n'est pas un seil de limitation stricte;
+si vous avez des tuples dont la taille est de 50MB, il <emphasis>seront</emphasis> forcément chargé en mémoire. Il n'est pas possible d'éviter cela.
Mais &lslon; au moins, n'essayera pas de charger, à la fois 100 enregistrements coûte que coûte, dépassant les 10GB de
mémoire consommée à cet effet.</para> </listitem>
</itemizedlist>
-<para> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont sporadiquement,
-des séries de tuplets très volumineux. </para>
+<para> Ceci devrait alléger des problèmes que les gens avaient éprouvé, quand ils ont chargés sporadiquement,
+des séries de tuples très volumineux. </para>
</answer>
</qandaentry>
<qandaentry id="faqunicode"> <question> <para> Je suis en train de répliquer
les données de type <envar>UNICODE</envar> depuis la version 8.0 de &postgres; à la version 8.1,
-et rencontre des problèmes. </para>
+et je rencontre des problèmes. </para>
</question>
<answer> <para> &postgres; 8.1 est un peu plus strict dans l'usage des codes caractères
UTF-8 et Unicode, comparé à la version 8.0.</para>
-<para> Si vous êtes emmener à utiliser &slony1; pour migrer depuis une plus vieille version à celle 8.1,
-et que au passage vous devrez faire une conversion depuis le format UTF-8, vous auriez une surprise déplaisante.</para>
+<para> Si vous êtes amené à utiliser &slony1; pour migrer depuis une plus vieille version vers la version 8.1,
+et que avez de valeur UTF-8 invalide, vous aurez une surprise déplaisante.</para>
-<para> Permettez de supposer que votre version de base est 8.0, avec l'encodage en UTF-8.
-La base va accepter des séquences <command>'\060\242'</command> en conformité avec UTF-8,
-même si il ne peut vraiment pas. </para>
+<para> Supposons que votre version de base est 8.0, avec l'encodage en UTF-8.
+La base va accepter des séquences <command>'\060\242'</command> comme un valeur UTF-8 conforme, même si ce n'est pas le cas. </para>
-<para> Si vous répliquez dans des instance de &postgres; en version 8.1, il va se plaindre de cela,
-, à la fois lors d'enregistrement d'un abonné, où &slony1; va râler
+<para> Si vous répliquez ceci dans des instances de &postgres; en version 8.1, il va se plaindre,
+, soit lors de l'enregistrement d'un abonné, car &slony1; va râler
à propos des codes caractères invalides qu'il vient de rencontrer durant la COPY des données,
-qui empêcherait que l'enregistrement se fasse, ou, empêchant de rajouter les données,plutard,
-lorsqu'il se reproduira, la réplication tombera en erreur sans possibilité de reprise.
-(Vous pouvez tricher sur le contenu de sl_log_1, mais assez rapidement
-cela deviendra <emphasis>vraiment</emphasis> inintéressante...)</para>
+ce qui empêchera que l'enregistrement se fasse, soit lors de l'ajout de données, plus tard, ce qui brisera irrémédiablement la réplication.
+(Vous pouvez tricher sur le contenu de sl_log_1, mais rapidement
+cela deviendra <emphasis>vraiment</emphasis> intéressant...)</para>
-<para>Il y a déjà eu une discutions sur ce sujet pour savoir ce qu'il faudra faire.
+<para>Il y a déjà eu des discussions sur ce sujet pour savoir ce qu'il faudra faire.
Pour le moment une stratégie attractive ne se dégage pas sur le sujet. </para>
<para>Si vous utilisez Unicode avec la version 8.0 de &postgres;, vous courrez un risque
considérable de corrompre vos données. </para>
<para> Si votre réplication a pour but de convertir une fois pour toutes vos données,
-il y a le risque évoqué; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
+il y a le risque évoqué ci-dessus; si cela vous arrive, il voudra mieux de convertir vos données de la version 8.0
d'abord et de re-essayer après. </para>
-<para> A propos des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
-semble être non pérennene à maintenir et qu'une migration vers 8.1 s'imposera. </para>
+<para> Au regard des risques encourus, exécuter la réplication en mettant en jeu des versions différentes,
+semble être non pérenne à maintenir. </para>
-<para> Pour plus d'information, voir la discutions<ulink url=
+<para> Pour plus d'information, voir la discussion <ulink url=
"http://archives.postgresql.org/pgsql-hackers/2005-12/msg00181.php">
-sur le groupe de discutions postgresql-hackers. </ulink>. </para>
+sur le groupe de discussion postgresql-hackers. </ulink>. </para>
</answer>
</qandaentry>
<qandaentry>
-<question> <para> J'utilise &slony1; 1.1 avec 4+ nouds dans le jeu où il y a deux jeux d'abonnements,
- 1 et 2, qui ne partagent pas d'autre noeuds. Je découvre que la confirmation pour le jeu 1
-n'arrivent jamais pour le noeud souscrivant au jeu 2, et inversement, celles du jeu 2 n'arrivent pas non plus
-au noeud souscrivant au jeu 1. En conséquence, <xref
-linkend="table.sl-log-1"/> crois et grossi et n'est jamais purgée. Ceci est mentionné
-comme &slony1; <ulink
+<question> <para> J'utilise &slony1; 1.1 avec plus de 4 noeuds et deux ensemble de réplication, 1 et 2, qui ne partagent aucun noeuds. Je découvre que les confirmations pour l'ensemble 1
+n'arrivent jamais aux noeuds souscrivant à l'ensemble 2, et inversement, celles de l'ensemble 2 n'arrivent pas non plus
+aux noeuds souscrivant à l'ensemble 1. En conséquence, <xref
+linkend="table.sl-log-1"/> grossit et n'est jamais purgée. Ceci est mentionné dans le bug 1485 :
+ <ulink
url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
-bug 1485 </ulink>.
+</ulink>.
</para>
</question>
-<answer><para> Apparemment le code pour
-<function>RebuildListenEntries()</function> ne suffit pas pour ce cas.</para>
+<answer><para> Apparemment le code de la fonction <function>RebuildListenEntries()</function> ne suffit pas pour résoudre ce cas.</para>
-<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; en version 1.2
+<para> <function> RebuildListenEntries()</function> sera rectifié dans &slony1; version 1.2
avec un algorithme couvrant ce cas. </para>
<para>
-Dans l'intérim, vous voudrez ajouter manuellement quelques entrées <xref linkend="table.sl-listen"/> utilisant <xref
+Dans l'intérim, vous drevez ajouter manuellement quelques entrées dans <xref linkend="table.sl-listen"/> en utilisant <xref
linkend="stmtstorelisten"/> ou <function>storeListen()</function>,
-basé sur les (apparemment pas aussi désuet que nous avons pensé) principes décrits dans <xref linkend="listenpaths"/>.
-
+basé sur les principes décrits dans <xref linkend="listenpaths"/>.
+(apparemment pas aussi désuet que nous avons pensé)
</para></answer>
</qandaentry>
<qandaentry>
-<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, avec outre les derniers caractères truncés. Pourquoi?
+<question> <para> Je trouve que quelques colonnes de multibyte (Unicode, Big5) sont tronqués un peu, il leur manque les derniers caractères. Pourquoi?
</para> </question>
-<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; la manière dont des colonnes étaient capturées par la fonction <function>logtrigger()</function> qui coupait outre les derniers byte d'une colonne représentée dans un format de multibyte. Vérifiez pour voir que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le e patch a été intégré dans la version CVS de 1.34 de ce fichier. </para> </answer>
+<answer> <para> C'était un bug présent jusqu'à la version 1.1.0 de &slony1; ; les colonnes étaient capturées par la fonction <function>logtrigger()</function>, qui coupait les derniers byte d'une colonne représentée dans un format de multibyte. que votre version de <filename>src/backend/slony1_funcs.c</filename> est bien 1.34 ou suppérieur; le patch a été intégré dans la version CVS de 1.34 de ce fichier. </para> </answer>
</qandaentry>
<qandaentry id="sequenceset"><question><para> <ulink url=
"http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1226">
-Bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
-vous faites placer une réplique composée seulement d'ordres.
+Le bug #1226 </ulink> indique une condition d'erreur qui peut survenir si
+vous faites placer une réplication composée seulement de séquences.
</para>
</question>
-<answer> <para> Une brève réponse serait de dire qu'une réplication composée seulement d'ordre, n'est pas une bonne pratique <link linkend="bestpractices">
-.</link> </para>
+<answer> <para> Une réponse courte consiste à dire qu'une réplication composée seulement de séquences, n'est pas une <link linkend="bestpractices">
+bonne pratique.</link> </para>
</answer>
+<STOP>
<answer>
<para> Le problème avec un ensemble d'ordre seulement si vous avez un cas pour lequel les seuls abonnements qui sont en activité pour un abonné particulier vis à vis d'un fournisseur particulier, sont pour les jeux <quote>sequence-only</quote>. Si un noeud entre dans cet état,
la réplique échouera, étant donnée la requête qui collectera les données depuis <xref
Plus d'informations sur la liste de diffusion Trad